AIエージェントを組織で使い始めると、最初は「何を許可するか」「どう評価するか」を決めます。けれど、実運用で一番困るのは、事故が起きた瞬間です。誤った shell 実行、MCP 経由の外部書き込み、承認されていない package 追加、不要な PR comment、秘密情報に近いログ出力。こうした動きに気付いたとき、誰がどの順番で止めるのかが曖昧だと、被害確認より先に混乱が広がります。
この記事では、Claude Code、Codex、MCP server、社内 workflow agent を含む AIエージェント停止手順 を runbook として整理します。監査証跡として何を残すかは AIエージェント監査ログ設計ガイド、本番投入前に何を落とすかは AIエージェント評価設計ガイド、通常時の許可範囲は AIコーディングツールの社内ガイドライン、MCP server の事前審査は MCP サーバーカタログ設計ガイド に分けています。
今回扱うのは、事故が起きた後の初動、隔離、復旧、再開判定 です。
先に結論: AIエージェントは「停止できる単位」で設計する
AIエージェントのインシデント対応で一番危ないのは、止める場所がないことです。
「エージェントを止める」と言っても、実際には複数の層があります。
| 層 | 止める対象 | 例 |
|---|---|---|
| session | 実行中の会話、thread、automation | loop、background task、agent run |
| tool | shell、file write、browser、GitHub、deploy | write tool を disable、approval を require |
| MCP | server、scope、token、client設定 | server allowlist から外す、OAuth token を revoke |
| workspace | branch、worktree、sandbox、artifact | worktree を隔離、成果物を publish しない |
| organization | managed settings、policy、routing | bypass mode 禁止、外部送信を停止 |
この表を持たずに「とりあえず agent を止めて」と言うと、誰も同じものを止めていません。Claude Code の permission mode を戻しただけで、MCP token は生きている。Codex の branch を閉じただけで、scheduled task は動いている。GitHub の PR を close しただけで、外部 SaaS への書き込み権限は残っている。こういう抜けが起きます。
私なら、AIエージェントの導入時点で kill switch を5層に分けて台帳化 します。
事故の分類を5つに分ける
初動で大事なのは、原因の推測より分類です。分類が決まれば、止める範囲が決まります。
| 分類 | 例 | 初動 |
|---|---|---|
| 誤操作 | 不要な file edit、誤った branch push | session停止、worktree隔離 |
| 権限超過 | read-only想定で write、承認前 deploy | tool停止、approval必須化 |
| 外部接続事故 | MCP write、SaaS comment、API送信 | token失効、MCP server停止 |
| 情報漏洩疑い | secret読取、PIIをログ出力 | artifact隔離、raw log保全 |
| 供給網事故 | package追加、未知のtool導入 | dependency freeze、lockfile差分確認 |
この分類は完璧でなくて構いません。重要なのは、事故直後に「何を止めるか」を決めるための短い言葉を持つことです。
たとえば、MCP 経由で GitHub issue に誤った comment を投稿した場合、これは「外部接続事故」です。session を止めるだけでは足りません。対象 MCP server、OAuth token、write scope、投稿済み comment、監査ログを同時に見る必要があります。
逆に、agent がローカル worktree で不要な Markdown を編集しただけなら、外部 token を全部 revoke する必要はありません。worktree を隔離し、diff を破棄または修正すれば足ります。
15分以内にやる初動
AIエージェント事故では、最初の15分でやることを固定した方がよいです。難しい分析は後回しです。
私なら、次の順にします。
- 実行中の session / thread / automation を止める
- write tool と外部 action を一時停止する
- branch、worktree、artifact を隔離する
- MCP server と token の scope を確認する
- 直近の tool call、approval、成果物を保存する
- 影響範囲を「localのみ / repo内 / 外部送信あり」に分ける
ここでやってはいけないのは、焦ってログや branch を消すことです。不要な差分を消したくなりますが、証跡を消すと後から「何が起きたか」を説明できません。まず止める。次に残す。その後で戻す。この順番です。
runbook の最小テンプレ
最初から大きな incident process を作る必要はありません。小さく始めるなら、次のテンプレで十分です。
incident_id: ai-agent-20260609-001
severity: local_write | external_action | data_exposure
detected_at: 2026-06-09T10:15:00+09:00
detected_by: reviewer
agent:
product: codex | claude-code | internal-agent
run_id: 20260609-codex-pr-42
session_url: null
branch: article/example
workspace: .codex-worktrees/example
stop_actions:
session_stopped: true
write_tools_disabled: true
mcp_servers_disabled:
- github-write
tokens_revoked:
- github-oauth-agent
artifacts_quarantined:
- branch:article/example
- pr:42
impact:
external_action: true
data_exposure_suspected: false
production_changed: false
recovery:
rollback_done: false
owner: platform-team
reopen_condition: "write scope is reduced and eval case is added"このテンプレの目的は、きれいな報告書を作ることではありません。止めたもの、まだ止めていないもの、再開条件を一目で分かるようにすることです。
MCP事故では token と server を分けて止める
MCP を使う AIエージェントでは、MCP server を止めただけで安全になったと考えない方がよいです。
MCP の Security Best Practices は、scope 設計、token passthrough、監査証跡の欠落を重要なリスクとして扱っています。事故時も同じで、止める対象を分けます。
| 対象 | 具体例 | 見ること |
|---|---|---|
| client設定 | allowedMcpServers、managed-mcp.json | agent から server が見えるか |
| server | endpoint、transport、version | server 側を停止できるか |
| token | OAuth token、service account | revoke / rotate したか |
| scope | repo read、issue write、admin | 過剰 scope が残っていないか |
| audit | request log、tool call log | 誰の依頼で何を呼んだか |
私なら、MCP server catalog に kill_switch_owner、token_owner、default_scope、emergency_contact を必ず持たせます。これが無い server は、便利でも組織運用には入れません。
Claude Code / Codex では permission を戻す場所を決める
Claude Code や Codex のような coding agent では、事故時に「権限を戻す場所」が重要です。
Claude Code は permission rules、permission mode、managed settings で操作を制御できます。組織利用なら、危険な bypass mode や auto mode を管理者側で止める設定も検討対象になります。
Codex では sandbox、approval、permissions profile、network allowlist を分けて考えます。full access で事故が起きたなら、単に「次から注意する」ではなく、既定 profile を read-only または workspace-write + approval に戻します。外部接続が絡んだなら、network allowlist と token の見直しも必要です。
事故後に見るべき項目は次です。
- session はまだ動いていないか
- write tool が自動承認のまま残っていないか
- bypass / full access が既定になっていないか
- network allowlist が広すぎないか
- MCP write scope が必要最小限か
- Auto-review や reviewer agent が修正 agent に変わっていないか
ここは Codex sandbox / approvals の設計ともつながります。通常時の権限設計と、事故後に戻す baseline は同じでなければ運用が崩れます。
rollback は「差分を戻す」だけでは足りない
AIエージェント事故の rollback は、git revert だけでは終わりません。
見る対象は少なくとも4つあります。
| 対象 | 戻すもの |
|---|---|
| code | commit、branch、PR、generated file |
| dependency | package、lockfile、install script、registry |
| external system | GitHub comment、issue、SaaS record、deployment |
| agent state | memory、retrieval index、session history、cached artifact |
実務で見落としやすいのは agent state です。誤った方針を memory や retrieval に残すと、次の run でも同じ失敗を繰り返します。AIエージェントメモリを使う場合は、事故後に「何を削除するか」「何を教訓として残すか」を分けます。
また、rollback できない外部 action もあります。Slack 通知、メール送信、外部 SaaS の更新、公開 PR comment などです。こうした操作は、実行前 approval と実行後 audit をセットにしないと、事故後の修復が難しくなります。
再開条件を決めずに再開しない
事故対応で一番よくないのは、「たぶん直った」で再開することです。再開条件を明文化します。
私なら、最低限次を満たすまで write 権限を戻しません。
- 影響範囲が local / repo / external のどれか確定している
- 外部 token の revoke / rotate が必要なら完了している
- 事故原因が prompt、tool schema、permission、MCP scope、human approval のどれかに分類されている
- 再発防止が1つ以上入っている
- 監査ログまたは postmortem に再開理由が残っている
再発防止は大げさでなくて構いません。
- permission profile を狭める
- MCP write scope を read-only に戻す
- forbidden tool eval を1ケース追加する
- package install 前の approval を必須にする
- raw prompt を長期保存しない設定にする
- runbook に連絡先を追加する
重要なのは、事故を「人が注意する」で閉じないことです。AIエージェントは同じ条件なら似た失敗を再現します。仕組みに戻す必要があります。
小さく始めるなら3つだけ決める
最初から SOC や全社 incident process と統合しなくてもよいです。小さな開発チームなら、まず3つだけ決めます。
- 誰が止めるか: agent owner、security owner、repo owner
- どこを止めるか: session、tool、MCP、token、branch
- 何を見たら再開するか: rollback、token確認、eval追加、approval見直し
これだけでも、「便利だから全開放したまま」「事故後に branch だけ消して終わり」という状態からは抜けられます。
まとめ
AIエージェントの安全運用は、許可する機能を選ぶだけでは足りません。止める単位、隔離する場所、復旧する順番、再開条件まで決めて初めて運用になります。
監査ログは何が起きたかを説明するための設計です。評価設計は本番前に危険な失敗を落とすための設計です。停止手順は、事故が起きたときに被害を広げないための設計です。この3つを分けておくと、Claude Code、Codex、MCP、社内 agent のどれを使っても判断がぶれにくくなります。
私なら、最初の runbook は1枚で作ります。5層の kill switch、15分以内の初動、MCP token の止め方、再開条件。この4つが書けない agent は、まだ write 権限や外部 action を任せる段階ではありません。