AIエージェントrollback設計ガイド - 外部副作用を戻せる単位で任せる

AIエージェントに作業を任せると、最初は「失敗したら戻せばよい」と考えがちです。けれど、戻す対象が local patch だけなら簡単でも、GitHub comment、issue 更新、MCP write、Slack 通知、deploy、権限変更が混ざると話は変わります。agent が外部へ一度書いたものは、git revert だけでは戻りません。

この記事では、AIエージェントの rollback 設計 を扱います。失敗後に同じ作業をやり直す設計は AIエージェント再実行設計ガイド、事故後に止めて復旧する runbook は AIエージェント停止手順ガイド、tool の危険度分類は AIエージェント tool risk tier 設計ガイド、実行直前の人間承認は AIエージェント承認フロー設計ガイド に分けています。

今回の論点は、外部副作用を持つ作業を、戻せる単位に切ってから AIエージェントへ渡すことです。

先に結論: rollback は後始末ではなく実行前の契約

AIエージェントの rollback は、失敗した後に慌てて考えるものではありません。実行前に rollback_plan を持たせます。

agent_action:
  action_id: run-20260701-pr-comment-01
  action: "github_pr_comment"
  target: "nidoneko/HP#203"
  risk_tier: T4
  forward:
    summary: "build結果と確認事項をPRへコメントする"
    marker: "<!-- ai-agent:run-20260701-pr-comment-01 -->"
  rollback_plan:
    rollback_type: "compensating_action"
    steps:
      - "同じ marker の comment を検索する"
      - "誤投稿なら削除ではなく訂正コメントを追記する"
      - "削除が必要なら repo owner 承認へ戻す"
    evidence_required:
      - "comment URL"
      - "body hash"
      - "approval_id"

ここで大事なのは、rollback を「何かあったら戻す」ではなく、forward action と同じ粒度で定義することです。外部 action には、元に戻す操作、訂正する操作、無効化する操作、事故対応へ上げる操作が混ざります。全部を rollback と呼ぶと運用で壊れます。

既存記事との役割分担

近いテーマが増えているので、責務を明確にします。

近いテーマ	扱うこと	この記事で扱うこと
再実行設計	retry、checkpoint、idempotency、RunState	外部副作用を戻す手順と戻せない操作の扱い
停止手順	事故後の kill switch、隔離、再開条件	事故にする前の rollback plan
承認フロー	実行直前に approve / reject する	承認者が見る rollback plan
tool risk tier	read / write / external action の分類	tier ごとの rollback 必須度
監査ログ	実行後の証跡	rollback できるかを説明する証跡

つまり、rollback 設計は incident response の一部ではありません。通常運用の設計です。AIエージェントが外部 write をするなら、成功時の手順と同じくらい、戻し方を先に決めます。

rollback を4種類に分ける

実務では、rollback という言葉を1つにしない方が安全です。

種類	例	方針
revert	commit、設定ファイル、生成物	git revert / patch 破棄で戻す
restore	DB row、設定値、feature flag	直前 snapshot や previous value に戻す
compensate	comment、通知、外部 ticket	訂正、close、追加説明で打ち消す
revoke	token、scope、権限、公開 URL	無効化し、必要なら再発行する

local code は revert で済みます。けれど、MCP 経由の issue comment や Slack 通知は、消しても受信者の記憶や通知履歴までは戻りません。こういう操作は compensate です。誤った権限付与や token 発行は、restore ではなく revoke に寄せます。

AIエージェントに外部 action を任せる前に、操作ごとにこの4種類のどれかを割り当てます。割り当てられない操作は、原則として自動実行させません。

rollback が必要な境界を先に決める

私なら、AIエージェントの操作を次の境界で分けます。

操作	rollback 要件
read / inspect	原則不要。ただし secret や PII を読んだ疑いがあれば incident 扱い
draft	draft artifact を破棄できれば十分
local write	branch、base commit、changed files が必須
repo write	PR、commit、label、comment の URL と戻し方が必須
SaaS write	target resource、payload hash、訂正手順が必須
deploy / publish	rollback owner、previous version、影響範囲が必須
permission / token	revoke 手順、owner、再発行条件が必須

この表を持たないまま agent に「必要ならPRにコメントして」「問題なければデプロイして」と渡すのは危険です。人間なら文脈で止まるところを、agent は作業完了を優先して進めることがあります。

承認リクエストには rollback plan を入れる

承認画面で payload だけを見せても不十分です。承認者は「失敗したらどう戻すか」も見たいからです。

approval_request:
  approval_id: apr-20260701-004
  policy_version: agent-policy-2026-07-01
  requested_action: mcp.github.create_issue_comment
  risk_tier: T4
  target: repo:nidoneko/HP issue:#203
  payload_summary: "再実行設計記事のbuild結果を追記する"
  rollback_plan:
    type: compensate
    owner: repo-owner
    steps:
      - "comment URL を監査ログに保存"
      - "誤りがあれば訂正 comment を同 thread に追加"
      - "削除が必要なら repo-owner approval を取る"
  reject_behavior:
    - "local draft に戻す"
    - "PR body にだけ残す"

OpenAI Agents SDK の human-in-the-loop は、sensitive tool call を一時停止し、承認または却下後に state から再開できます。これは便利ですが、承認者に rollback 情報がなければ、実務上の判断材料は足りません。pause / resume の仕組みと、業務上の rollback plan は別に設計します。

MCP write は server 単位で戻せない

MCP では、server を allowlist に入れるだけでは rollback 設計になりません。同じ server でも、read tool、write tool、delete tool、外部通知 tool が混ざります。

MCP Security Best Practices は、scope、token handling、session hijacking、local server compromise などを個別のリスクとして扱っています。rollback でも同じで、server ではなく tool と target で考えます。

mcp_tool_rollback:
  server_id: github-mcp
  tools:
    - tool: create_issue_comment
      rollback_type: compensate
      required_fields:
        - target_issue
        - comment_marker
        - body_hash
        - approval_id
      forbidden_targets:
        - "security-advisory"
        - "customer-private-repo"

    - tool: add_label
      rollback_type: restore
      required_fields:
        - target_issue
        - previous_labels
        - applied_labels

create_issue_comment は訂正で打ち消す操作です。一方、add_label は previous labels を持っていれば restore できます。merge_pull_request や delete_release のような操作は、rollback が重いので forbidden か人間専用に寄せます。

idempotency と rollback を混同しない

idempotency は「同じ操作を複数回実行しても結果が変わらない」設計です。rollback は「実行済みの操作をどう打ち消すか」です。似ていますが、役割は違います。

Temporal の Activity docs でも、retry され得る Activity は idempotent に設計することが推奨されています。AIエージェントでも、外部 action には idempotency key や marker を持たせます。ただし、idempotent だから rollback 不要とはなりません。

たとえば、同じ GitHub comment を二重投稿しない仕組みがあっても、投稿内容が間違っていた場合の訂正手順は別に必要です。deploy API が同じ release id を再利用できても、誤った version を公開したときの rollback owner は別に必要です。

観点	防ぐもの	必要な情報
idempotency	二重実行	key、marker、target state
rollback	誤実行の影響	previous state、compensation、owner
incident response	被害拡大	kill switch、token revoke、証跡保全

この3つを分けると、AIエージェントの失敗対応がかなり読みやすくなります。

rollback evidence を残す

rollback plan があっても、証跡がなければ戻せません。最低限、外部 action には次を残します。

rollback_evidence:
  action_id: run-20260701-deploy-01
  agent_run_id: run-20260701-release
  policy_version: agent-policy-2026-07-01
  approval_id: apr-20260701-009
  tool_name: deploy.production
  target: service:blog
  previous_state:
    version: "2026.06.30-2"
    config_hash: "sha256:old..."
  desired_state:
    version: "2026.07.01-1"
    config_hash: "sha256:new..."
  result:
    status: success
    external_url: "https://example.com/deploy/123"

監査ログは「何が起きたか」を説明するためのものですが、rollback evidence は「戻せるか」を説明するためのものです。重ねてもよいですが、目的は分けます。

rollback できない操作は自動化しない

外部 action の中には、実質的に戻せないものがあります。

• 顧客や社外への通知
• billing、refund、課金 plan の変更
• production data の削除
• package publish
• secret や credential の表示
• 権限の昇格
• 法務・人事・契約に関わる送信

これらは、AIエージェントが draft を作るところまでは任せられます。しかし実行は人間専用に寄せるか、専用 workflow の承認と監査に載せます。AIエージェントに任せる範囲を狭めることは、能力を低く見積もることではありません。失敗時の責任境界を明確にすることです。

rollback drill を小さく回す

設計だけでは足りません。小さな rollback drill を回します。

最初の対象は、影響が小さい外部 action で十分です。

1. GitHub issue comment を agent が draft する
2. 承認後に marker 付きで投稿する
3. 誤りがある想定で訂正 comment を出す
4. audit log と rollback evidence を確認する
5. rollback_plan に足りない項目を直す

次に label 変更、PR 作成、feature flag、staging deploy のように段階を上げます。本番 deploy や顧客通知から始めてはいけません。

NIST AI RMF は、AI リスク管理を Govern / Map / Measure / Manage の継続的な活動として整理しています。rollback drill は Manage 側の運用ですが、実際には Govern のルール、Map の影響範囲、Measure の証跡が揃っていないと回りません。

実務での導入順

小さく始めるなら、次の順で十分です。

1. T4 external action だけを対象にする
2. 承認リクエストへ rollback_plan を必須にする
3. GitHub comment / label / PR 作成の3種類だけ先に定義する
4. MCP catalog に rollback_type と owner を足す
5. rollback_evidence を監査ログへ保存する
6. 月1回、実際に訂正・restore・revoke を試す
7. rollback できない操作を forbidden tier に移す

最初から全社 workflow engine を作る必要はありません。むしろ、最初に必要なのは「この action は戻せるのか、訂正しかできないのか、そもそも自動化しないのか」を揃えることです。

まとめ

AIエージェントの rollback 設計は、派手な機能ではありません。けれど、外部 write を任せるなら避けて通れません。

再実行設計は、失敗後にどこからやり直すかを決めます。停止手順は、事故後に止めて復旧するための runbook です。rollback 設計はその前段で、外部副作用を持つ action を戻せる単位に切り、戻せない action を自動化から外すための設計です。

私なら、rollback plan が書けない tool call は T4 以上に上げます。rollback evidence が残らない外部 action は自動実行させません。AIエージェントに強い権限を渡すほど、成功手順より先に戻し方を設計するべきです。

参考にした一次情報

• OpenAI Agents SDK - Human-in-the-loop
• OpenAI Agents SDK - Results / RunState
• Model Context Protocol - Security Best Practices
• Temporal documentation - Activity Definition / Idempotency
• NIST AI Risk Management Framework