初動でやるべきこと：停止、隔離、権限剥奪

インシデント対応は初動がすべて、と言っても言い過ぎではない。特にエージェントの場合、放置すれば自動で被害が増える可能性がある。まず優先すべきは「これ以上の実行を止める」ことで、原因究明はその後でよい。止め方を事前に用意していない組織ほど、現場が混乱し、結果的に被害が拡大する。

最初の手段は、エージェント自体の停止である。実行中のジョブキューを止める、スケジューラを止める、トリガーとなるイベント（受信メール、Webhook、チケット起票）を遮断する。エージェントが複数ある場合は、当該エージェントだけを止める仕組みが必要になる。全停止しかできない設計だと、事故は止められても業務も止まり、復旧判断が遅れる。最小単位で止められることは、運用の現実性に直結する。

次にやるべきは権限の剥奪だ。エージェントはツールを通じて動くので、ツール権限を止めれば被害は止まる。SaaS連携のトークン失効、APIキーのローテーション、OAuthアプリの無効化、サービスアカウントの一時停止。どれをどこで止めるかが分かっていないと、現場は「とにかくサーバ落とす」みたいな原始的対応になり、別の被害を生む。したがって、エージェントが使う認証情報の一覧と失効手順は、平時から整備しておく必要がある。

そして隔離である。エージェントが参照するデータソースや、出力先の経路を一時的に遮断する。例えば外部送信が起きたなら、送信経路（メールゲートウェイ、Webhook送信先、共有リンク発行）を止める。RAGが原因の疑いがあるなら、参照インデックスを切り離し、読み取りだけにする。キューに残っている未処理タスクが危険なら、実行せず保全しておく。隔離の目的は「被害を止める」と同時に「証拠を壊さない」ことでもある。

ここで重要になるのが、止める手順を“迷わない形”にしておくことだ。インシデントは往々にして深夜や休日に起きる。担当者が変わっても止められるように、止める手順を権限者の役割とセットで決めておく。さらに、止めることで二次被害が出る領域（例えば顧客対応が完全停止する）もあるので、停止の粒度と代替手順（手動対応へ切り替えるなど）を用意しておくと現実的になる。

原因究明の難しさ：なぜそう判断したかを追う

被害が止まったら、次に必要なのは原因究明である。ただしエージェントの原因究明は、従来のアプリより難しくなりがちだ。なぜなら、単一のバグではなく、入力・推論・実行が連鎖して結果が出るため、「どこで判断が歪んだか」を追う必要があるからだ。ここでありがちな失敗は、会話ログだけを見て「プロンプトが悪かった」で終わらせてしまうことだ。それでは再発防止にならない。

原因究明でまず集めるべき証拠は、入力の全体像である。エージェントが受け取ったユーザー指示だけでなく、参照したメール本文、チケット内容、PDF、Webページ、検索結果、RAGで引いた文書など、実際にモデルへ渡った材料を揃える必要がある。エージェントは「外部からの指示」に誘導されることが多いので、どの材料に誘導が混ざっていたかが最重要になる。もし参照元が外部Webなら、その時点のページ内容を保存しておかないと、後で内容が変わって再現できなくなることもある。

次に追うのは実行の履歴である。どのツールを、どんな引数で、どの順序で呼び、結果がどう返ったか。ここが欠けると、何が起きたかの説明ができない。例えば誤送信なら、宛先、送信内容、添付、送信時刻、送信トリガー。誤更新なら、更新対象、変更前後、更新を引き起こした条件。過剰取得なら、取得件数、取得範囲、どこへ渡ったか。この情報は、アプリのログとツール側の監査ログの両方から突き合わせる必要がある。エージェント側だけにログがあっても、ツール側の実行証跡がなければ確証が取れない。

そして最も難しいのが「なぜその判断になったか」を追う部分だ。これは人間の頭の中を覗くような話に聞こえるが、エージェントでは実装として手がかりを残せる。どのプロンプトテンプレが使われたか、モデルのバージョンは何か、システムメッセージやポリシー判定の結果はどうだったか、ツール実行前の意図説明はどうだったか。もし実行前に安全ゲートやポリシーエンジンがあるなら、「なぜ許可されたのか」「なぜブロックされなかったのか」のログが重要になる。逆に言えば、ここが残っていない設計だと、事故が起きても改善ポイントが見えない。

この段階での目標は、犯人探しではなく再現可能な因果関係を作ることだ。入力のどこに問題があったのか、制約のどこが弱かったのか、検証はなぜすり抜けたのか。これが言語化できれば、再発防止策は設計できる。言語化できないなら、ログと証跡の設計から見直す必要がある。

再発防止の打ち手：人間承認、制約、テスト、監視

原因が分かったら再発防止だが、ここでもエージェント特有の罠がある。再発防止が「プロンプトを強くする」だけに寄ると、次の別パターンで破られる。再発防止の中心は、実行系の改善に置くべきだ。具体的には、人間承認、制約、テスト、監視の四つで固めると現実的に効く。

まず人間承認である。すべてを承認にする必要はないが、事故につながった操作が高リスクなら、そこは承認必須に寄せたほうがよい。外部送信、共有リンク公開、個人情報の取り扱い、請求や決済、権限変更、破壊的変更。これらは一度のミスで影響が大きい。承認の設計で重要なのは、承認者が判断できる情報をエージェントが提示することだ。何を、なぜ、どこに、どんな影響で実行するのか。根拠となる参照元は何か。承認は“最後の砦”だが、砦が形骸化しないように情報設計が必要になる。

次に制約である。ツール実行をスキーマ固定し、引数を検証し、許可リストで範囲を絞る。事故が起きたということは、どこかの制約が緩いか、無いか、すり抜けたかのいずれかだ。外部送信なら、宛先ドメインの制限や送信数上限、添付の種類制限、機密検知。データ取得なら、件数上限や属性の最小化、検索範囲の制限。更新操作なら、二重確認や差分レビュー、ロールバックの用意。制約はモデルの賢さに依存しないので、最も堅牢な再発防止になる。

三つ目はテストである。エージェントの再発防止は、回帰テストに落とし込まないと崩れる。プロンプトやモデル、ツールが変わるたびに挙動が変わり得るからだ。実際に事故を起こした入力や、類似の悪用シナリオをテストケースとして保存し、変更のたびに通す。特に、信頼できない入力に誘導文が混ざるケース、RAGが汚染されるケース、ツール実行が危険方向に誘導されるケースは、パターンとして増やしていく価値がある。エージェントは学習ではなく設計で守るが、テストはその設計が効いているかを保証する手段になる。

四つ目は監視である。事故は完全には避けられないので、早期に検知して止める仕組みが必要だ。いつもより大量のデータ取得、外部送信の急増、通常は触らないシステムへのアクセス、深夜の権限変更、異常な失敗率の増加。こうした兆候をログから検知し、アラートを出し、キルスイッチにつなげる。監視は「起きた後の対応」ではなく、「起きる前に止める」ための仕組みとして設計するほうが効果が高い。

最後に、インシデント対応そのものを改善する。今回止められたか、証拠は残ったか、関係者への連絡は適切だったか、顧客への説明はできるか。ここを振り返って手順を更新し、演習しておくと、次回の被害は確実に減る。AIエージェントのインシデントは、技術だけでなく運用の成熟度が結果を左右する。

AIエージェントが暴走したときに重要なのは、「モデルが悪い」で終わらせないことだ。止める仕組み、権限の制御、証拠の設計、そして再発防止の運用。これらが揃って初めて、エージェントは業務に耐える存在になる。自律性を手に入れるなら、封じ込めと再発防止も自動化の対象にする。そこまで含めて設計できたとき、AIエージェントはリスクではなく、組織の信頼できる戦力になる。