本番のエージェントが止まったとき、あなたの組織は5分以内に気づけるか。止まっていることより深刻なのは、静かに誤作動したまま動き続けるエージェントだ。外部APIに不正なリクエストを大量送信していても、誤った情報をユーザーに返し続けていても、ログを見なければわからない。従来のシステム障害対応の手順は、こうした「確率的に壊れるAI」には設計されていない。
本記事はAIエージェントガバナンスのピラーコンテンツに連動しています。
AIエージェントのインシデントはなぜ従来の障害と異なるか
AIエージェントのインシデントは「止まる」より「静かに誤動作する」ケースが多く、証跡はディスクではなくプロンプト・ツール呼び出しログの中にある。
サーバーがクラッシュすれば監視が即座に検知する。しかしエージェントのインシデントは3つの点で異なる。
1. 故障モードが確率的
LLMは同じ入力でも異なる出力を返しうる。モデルのドリフト、コンテキスト枯渇、プロンプトインジェクションの影響は統計的なベースラインとの乖離としてしか検知できない。
2. 証跡の場所が異なる
原因調査に必要な証跡はディスクのコアダンプではなく、トリガーとなったプロンプト、取得したコンテキスト、呼び出したツールの記録、そしてモデルの出力ログにある。AIエージェントの可観測性で設計したトレース基盤がなければ、この証跡が存在しない。
3. 影響範囲が連鎖する
エージェントが別のエージェントをオーケストレートするマルチエージェント構成では、上流の誤動作が下流のすべてのエージェントに波及する。封じ込めが遅れるほど影響範囲が広がる。
P0〜P3：重大度フレームワークと対応時間の設計
P0は顧客影響が発生中、P3は潜在的なリスクとし、それぞれ2時間・4時間・1日・1週間以内での解決を目標に定義する。
重大度の一貫した定義がなければ、誰がいつ呼び出されるべきかが曖昧になる。以下の4段階は実際のアジェンティックワークフローに適した分類だ。
| 重大度 | 定義 | 対応目標 | 起動基準 |
|---|---|---|---|
| P0 | エンドユーザーに実被害が発生中（誤情報送信、データ漏洩、権限逸脱した外部操作） | 2時間以内 | 即時オンコール起動 |
| P1 | 影響範囲は限定的だが拡大リスクあり（エラー率50%超、コスト2倍超過） | 4時間以内 | 業務時間内エスカレーション |
| P2 | 機能が劣化しているが代替手段あり（特定ツールの失敗率上昇、レスポンス遅延） | 1日以内 | 翌営業日対応キュー |
| P3 | 潜在的リスクが検出された（eval回帰5%超、設定の軽微な逸脱） | 1週間以内 | 週次レビュー記録 |
重要な設計原則: P0/P1の判定はエンジニアの主観ではなく、自動検知シグナルによって機械的に行う。判断を人間に委ねると「様子を見る」という先送りが生まれ、対応が常に遅れる。
5フェーズ対応手順——検知から再発防止まで
検知・封じ込め・根絶・復旧・ポストモーテムの5フェーズを、それぞれ5分・15分・60分・段階的・72時間以内という時間目標で回す。
フェーズ1：検知（目標: 5分以内）
検知パネルには次の4つのシグナルを必ず含める。
- トークンコスト異常: 14日ベースラインの2倍超過をアラート化
- 完了率の低下: ベースラインの50%未満に落ちた場合
- ツールエラー率: 5分ウィンドウで2倍に達した場合
- eval回帰: カナリアデプロイのeval結果が5%以上劣化した場合
「検知パネルはインシデントが起きてから作るのでなく、前もって設計しておく」——これが検知フェーズの鉄則だ。
フェーズ2：封じ込め（目標: 15分以内）
封じ込めの原則はキルスイッチ優先・診断は後でだ。原因を特定しようとしている間にも影響が広がる。
- フィーチャーフラグで新規ランを停止: 進行中のエージェントランを受け付けない
- APIキーの無効化: 外部操作が疑われる場合、ネットワーク遮断より早くAPIキーを無効化する
- エージェントシャドーイング: 本番トラフィックをミラーリングしてオフラインで挙動を観察する
封じ込めはリバーシブルな手段を使う。削除・上書きは証跡を失うため、後の根絶フェーズまで待つ。
フェーズ3：根絶（目標: 60分以内）
根本原因を特定し、変更を逆戻しする。
- プロンプトの変更が原因 → 前バージョンへロールバック
- モデルのドリフトが原因 → モデルバージョンを固定（ピン留め）
- ツールの外部依存が原因 → 該当ツールを隔離または代替に切替
システムプロンプトのバージョン管理が設計されていれば、ロールバックは数分で完了する。
フェーズ4：復旧（段階的）
トラフィックを一気に戻さない。カナリア方式で段階的に増やし、各ステップで24時間のモニタリングを挟む。Blue/Greenデプロイのパターンをそのまま復旧にも適用できる。
フェーズ5：ポストモーテム（72時間以内）
ポストモーテムの目的は犯人探しではなくシステムの改善だ。以下の問いに答える文書を72時間以内に作成する。
- いつ・どのシグナルで検知されたか
- 封じ込めまでに何分かかったか
- 根本原因の分類（プロンプト変更 / モデルドリフト / 外部依存 / プロンプトインジェクション / その他）
- 再発防止のために何を変えるか（検知 / 封じ込め / 根絶の各フェーズで）
AIエージェント特有の証跡収集手順
証跡はプロンプト・コンテキスト・ツール呼び出し記録・モデル出力の4点セットで保全し、封じ込め直後に収集を開始する。
従来のITインシデントではログファイルとメモリダンプを保全する。エージェントインシデントでは4つの証跡が必要だ。
① トリガーとなったプロンプト: 何を入力として受け取ったか
② 取得したコンテキスト: RAGやツール呼び出しで取り込んだ外部データ
③ ツール呼び出し記録: どのツールをどの順序で・何回・どんな引数で呼んだか
④ モデル出力: 各ステップでモデルが返した中間出力と最終出力
これらは監査ログの設計で構造化ログとして記録されていることが前提だ。事後に再現を試みても、LLMの出力は非決定的なため完全な再現はできない。
証跡の改ざん防止については監査ログ スキーマ 改ざん防止設計を参照のこと。
規模別の留意点（SMB / エンタープライズ）
SMB向け
キルスイッチはフィーチャーフラグのオン/オフで十分。専任のSREがいない場合、検知アラートをSlackのチャンネルに転送し、オンコール担当をローテーションで決めておく。ポストモーテムは週次のふりかえりミーティングに組み込む形で構わない。Kuu のAI運用管理サービスでは、この仕組みのセットアップを支援している。
エンタープライズ向け
P0/P1は専用のオンコール体制とエスカレーションパスを設計する。NIST AI RMFのAgentic ProfileおよびISO 42001の要件に合わせたインシデント分類と報告フォーマットを統一し、複数チームが同一のプレイブックを使えるよう文書化する。規制対応が必要な業種（金融・医療・重要インフラ）では、監督機関への報告義務とその期限をプレイブックに明記する。大規模なマルチエージェント基盤でのインシデント対応体制の設計はRDEサービスで対応している。
参考
- Agentic Workflow Incident Response: Playbook + Runbooks 2026 — Digital Applied
- NIST AI RMF Agentic Profile — Cloud Security Alliance Labs
- AI Incident Response Playbook 2026 — GLACIS
まとめ
AIエージェントのインシデントは「止まったらわかる」という前提で設計できない。静かな誤動作を5分以内に検知するシグナルとアラートパネル、15分以内に動かせるキルスイッチ、そして確率的な故障モードに対応したP0〜P3の重大度定義——これらが揃って初めて、本番エージェントを安全に運用できる体制が整う。
プレイブックは作ることより実際に使える状態にしておくことが重要だ。インシデントが起きてから手順を探しているようでは間に合わない。ポストモーテムを繰り返すことで、組織固有の失敗パターンへの耐性が蓄積される。
AIエージェントのインシデント対応プレイブック設計について相談したい場合は、Kuu株式会社のAI運用管理サービスまでお気軽にお問い合わせください。