- はじめに——「検知した」その後の30分で、証拠は消えていく
- 前提——AIインシデントは従来IRと何が違うか
- フェーズ0：準備——事故が起きる前に「何を保全するか」を決めておく
- フェーズ1：検知とトリアージ——封じ込め判断までを最短にする
- フェーズ2：証拠保全——「揮発性の高い順」に取る
- フェーズ3：封じ込め——「停止」か「隔離」か「縮退」か
- フェーズ4：根本原因分析——非決定性の中で「注入点」を特定する
- フェーズ5：根絶と復旧——汚染メモリの特定と除染
- フェーズ6：教訓と再発防止——「AIインシデント報告書」の書き方
- AI-IRプレイブック・チェックリスト
- よくある質問（Q&A）
- まとめ——IRの主戦場は「検知の前」から「検知の後」へ
- 参考リンク
はじめに——「検知した」その後の30分で、証拠は消えていく
これまでのAIセキュリティ記事では、プロンプトインジェクションやメモリ汚染、目標ハイジャック、ゼロクリック・データ流出といった攻撃を「どう検知し、どう防ぐか」を中心に扱ってきました。振る舞い検知、ガードレール、監査ログ——防御の道具立ては揃いつつあります。しかし、実際に運用している方なら気づいているはずです。「検知した後、具体的にどう動くか」を正面から定めた手順が、ほとんどの組織に存在しないことに。
AIエージェントのインシデントは、従来のセキュリティ事故と決定的に異なる性質を持ちます。最大の違いは証拠の揮発性です。侵害の痕跡は、ディスク上のファイルやレジストリではなく、会話コンテキスト・エージェントのメモリ・ベクトルDBという「放っておけば上書き・圧縮・破棄される場所」にあります。コンテキストウィンドウは次のターンで圧縮され、セッションメモリはタスク完了で破棄され、汚染された長期メモリは正常な学習更新に紛れて痕跡を消します。従来のフォレンジック手順をそのまま適用すると、駆けつけたときには現場が消えているのです。
筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで、長年障害・インシデント対応に携わってきました。ネットワーク障害対応には「復旧を急ぐ前に、まず揮発性の高い状態情報から保全する」という鉄則があります。ルータを再起動すれば障害は直るかもしれませんが、メモリ上のルーティングテーブルやセッション状態は永遠に失われ、根本原因は闇に沈みます。本記事の核心は、この「揮発性順の保全」というフォレンジックの古典的原則を、AIエージェントの構造に合わせて再設計することにあります。
想定読者は、AIエージェントを本番運用している企業の情シス・SOC・CSIRT担当者、そしてIR体制の整備を求められているCISOの方々です。検知の仕組みについてはセマンティック・テレメトリ／意図トレース設計ガイドで扱ったため、本記事は「アラートが鳴った瞬間」から始まる事故発生後のプレイブックに集中します。
前提——AIインシデントは従来IRと何が違うか
対応手順を設計する前に、AIエージェントのインシデントが従来のITインシデントとどう違うかを整理します。違いは3つに集約されます。
違い1：証拠が揮発性の高い場所に集中している
従来のフォレンジックでは、証拠の中心はディスク・ログサーバー・ネットワーク機器にあり、比較的長く残ります。AIエージェントでは、攻撃の痕跡が最も濃く残るのは会話コンテキスト（コンテキストウィンドウ）・セッションメモリ・長期メモリ・ベクトルDBです。これらは製品仕様として自動で圧縮・要約・破棄・上書きされるため、「何もしなくても証拠が消える」のが標準動作です。
違い2：非決定性——同じ入力でも同じ事故は再現しない
従来のIRでは「再現手順の確立」が根本原因分析の柱でした。しかしLLMは確率的に動作するため、同じプロンプトを再投入しても同じ出力・同じツール呼び出しが再現される保証がありません。「再現できる環境」ではなく「当時の判断過程を記録から復元できること」が、AI-IRにおける再現性の定義になります。
違い3：汚染が伝播する——「感染範囲」の特定が空間ではなく時間軸になる
マルウェアの感染範囲はホスト・セグメント単位で特定できます。一方、汚染されたメモリやベクトルDBのエントリは、その後のすべての推論・出力・下流エージェントへの指示に影響を与え続けます。「いつ汚染が注入されたか」を特定し、その時点以降にエージェントが行った判断・出力・書き込みを全て疑う——感染範囲の特定が、空間の問題から時間軸の問題に変わるのです。
| 観点 | 従来のIR | AIエージェントのIR |
|---|---|---|
| 証拠の所在 | ディスク・ログ・NW機器 | 会話コンテキスト・メモリ・ベクトルDB |
| 証拠の寿命 | 比較的長い（消すには意図が必要） | 短い（何もしなくても消える） |
| 再現性 | 再現手順の確立が可能 | 非決定的——記録からの復元が頼り |
| 影響範囲 | ホスト・セグメント単位（空間） | 汚染時点以降の全判断（時間軸） |
| 封じ込め | 隔離・遮断が定石 | 停止すると証拠も消える場合がある |
標準フレームワークでの位置づけ
幸い、2025年以降、拠り所になる標準が出揃いました。社内でIR手順を起案する際の根拠として押さえておきましょう。
- NIST SP 800-61 Rev.3（2025年4月）：インシデント対応ガイドの最新版。従来の「準備→検知・分析→封じ込め・根絶・復旧→事後活動」のライフサイクルを、CSF 2.0の6機能（統治・識別・防御・検知・対応・復旧）に沿って再構成しました。IRを「事故対応チームの仕事」ではなく「リスクマネジメント全体に組み込む活動」と位置づけた点が、AI-IRの設計にもそのまま効きます。
- SANSのIRフレーム（PICERL）：準備（Preparation）・特定（Identification）・封じ込め（Containment）・根絶（Eradication）・復旧（Recovery）・教訓（Lessons Learned）の6段階。本記事のプレイブックはこの骨格をAI向けに翻訳して使います。
- OWASP GenAI Incident Response Guide 1.0：OWASP GenAIセキュリティプロジェクトが公開したGenAI特化のIRガイド。NISTのIRライフサイクルに沿いつつ、AIシステムへの攻撃・サプライチェーン攻撃・サードパーティモデル提供者の侵害という3つの事故類型ごとに、検知・封じ込め・事後活動を整理しています。
- MITRE ATLAS：AIシステムに対する攻撃のタクティクス・テクニック体系。2025年の更新でAIエージェント関連のテクニックが大幅に追加され、インシデントの分類・報告に使う「共通言語」として機能します。
つまり「AIのインシデント対応手順」はもはや手探りの領域ではなく、標準フレームの骨格に、AI特有の揮発性への手当てを載せるという設計問題です。以降、フェーズ順に具体化します。
フェーズ0：準備——事故が起きる前に「何を保全するか」を決めておく
ネットワーク障害対応で最初に叩き込まれるのは「障害が起きてからshow techの取り方を調べるな」でした。AI-IRも同じです。証拠保全は、平時に保全対象の一覧（エビデンス・インベントリ）と取得手段を整備してあるかどうかで9割決まります。
AIエージェント運用で保全対象になるのは、最低限以下の6種です。
| 証拠 | 何がわかるか | 揮発性 | 平時に準備しておくこと |
|---|---|---|---|
| 会話ログ（全ターンの入出力） | 注入された指示・誘導の原文 | 高（圧縮・要約で原文消失） | 圧縮前の原文を別系統に常時保存 |
| ツール呼び出し履歴 | 実際に実行された操作と引数 | 中 | 引数・戻り値込みで改ざん不能ログに記録 |
| メモリスナップショット（セッション／長期） | 汚染の有無・注入時点 | 高（タスク完了で破棄・上書き） | スナップショットAPI／エクスポート手段の確認 |
| ベクトルDBの状態 | 汚染エントリ・埋め込みの由来 | 中（更新で上書き） | エントリごとの由来（プロビナンス）記録 |
| システムプロンプト・設定のバージョン | 当時の指示・権限・接続先 | 低 | バージョン管理と変更履歴 |
| モデル・ルーティングのバージョン | どのモデルがどの判断をしたか | 低 | リクエスト単位でモデルIDを記録 |
加えて、平時に決めておくべきことが3つあります。
- 封じ込めの権限と基準：「誰の判断でエージェントを止めてよいか」「止める前に何を取得するか」を文書化する。深夜にSOCの当直が迷わないレベルまで具体化しておきます。
- スナップショットの訓練：会話コンテキスト・メモリ・ベクトルDBのエクスポートを、四半期に一度は実際に実行してみる。「取れるはずだったが権限がなかった」は本番で最も多い失敗です。
- ログの改ざん耐性：エージェント自身がログ出力に関与する構成では、侵害されたエージェントがログを「きれいに」書く可能性を想定し、ログは一方向（append-only）の別系統に送る設計にします。
フェーズ1：検知とトリアージ——封じ込め判断までを最短にする
アラートの発生源は、振る舞い検知・ガードレール違反・出力フィルタ・ユーザー通報・下流システムの異常などさまざまです。トリアージで最初に判定すべきは、従来IRのような「重要度」だけではありません。「このエージェントは今も動いていて、今も汚染された判断を出し続けているか」です。
判断軸は3つです。
- 継続性：単発の異常出力か、それとも汚染されたメモリ・目標に基づいて異常な判断が続いているか。継続していれば封じ込めの緊急度が上がります。
- 権限と接続先：そのエージェントが書き込み権限を持つ先はどこか（社内DB・顧客向けメール・他のエージェント・決済系）。Confused Deputy型の構成では、エージェントの権限＝被害の最大範囲です。
- 伝播の有無：マルチエージェント構成で、汚染された出力が他のエージェントの入力・メモリに流れ込んでいないか。
ここで重要な鉄則を一つ。トリアージの段階で、すでに証拠保全を開始してください。従来IRでは「分析してから保全」でも間に合うことがありますが、AI-IRでは分析している間にコンテキストが圧縮され、セッションが破棄されます。「疑わしい」と思った時点でスナップショットを取る——保全は無料ではありませんが、失った証拠は二度と戻りません。
フェーズ2：証拠保全——「揮発性の高い順」に取る
ネットワークフォレンジックの古典であるRFC 3227は、「証拠は揮発性の高い順に収集せよ（Order of Volatility）」と定めています。メモリ→ネットワーク状態→ディスク、の順です。AIエージェントに翻訳すると、保全の優先順位は次のようになります。
| 優先 | 保全対象 | 消えるタイミング | 取得方法の例 |
|---|---|---|---|
| 1 | アクティブな会話コンテキスト | 次ターンの圧縮・要約、セッション終了 | セッションを終了させずコンテキスト全文をエクスポート |
| 2 | セッションメモリ・作業状態 | タスク完了・タイムアウトで破棄 | スナップショットAPI／状態ダンプ |
| 3 | 長期メモリ・ベクトルDB | 次回の更新・再インデックスで上書き | 該当コレクションの時点コピー＋更新の一時凍結 |
| 4 | ツール呼び出し履歴・監査ログ | ローテーション（比較的長い） | 対象期間をロックし別媒体へ複製 |
| 5 | システムプロンプト・設定・モデルバージョン | 次のデプロイ | バージョン管理から当時の版を固定 |
保全にあたっての注意点を3つ挙げます。
- 「再起動してから調べる」は禁じ手：エージェントの再起動・セッションリセットは、ルータの再起動と同じで、最も揮発性の高い証拠を消します。封じ込めが必要な場合も、後述の「隔離」を優先し、停止は保全完了後にします。
- エージェント自身に保全させない：「今のメモリの内容を出力して」とエージェントに聞くのは、容疑者に現場検証をさせるのと同じです。侵害されたエージェントは汚染部分を隠す指示を受けている可能性があります。保全は必ずエージェントの外側（プラットフォームのAPI・DBへの直接アクセス）から行います。
- ハッシュとタイムスタンプ：取得したスナップショット・ログにはハッシュ値と取得時刻を記録し、以後の分析はコピーに対して行います。AIインシデントでも、証拠の完全性（Chain of Custody）の考え方は従来と同じです。法的対応や保険請求に発展した場合、ここが問われます。
フェーズ3：封じ込め——「停止」か「隔離」か「縮退」か
従来IRの封じ込めは「ネットワークから切り離す」が定石でした。AIエージェントでは、封じ込めの選択肢は3つあり、証拠保全・業務影響・被害拡大のトレードオフで選びます。
| 選択肢 | 内容 | 向く状況 | 注意点 |
|---|---|---|---|
| 停止 | エージェントのプロセス・セッションを完全停止 | 決済・外部送信など不可逆な操作が進行中 | 揮発性の証拠が消える——保全とセットで |
| 隔離 | 動作は継続させ、ツール実行・外部書き込みだけ遮断 | 挙動の観察と証拠収集を継続したい場合 | 読み取り経由の情報流出経路が残っていないか確認 |
| 縮退運転 | 権限を最小セットに絞り、人間承認ゲートを必須化 | 業務停止の影響が大きく、疑いが確定していない段階 | 汚染メモリ由来の出力が承認者を欺く可能性に留意 |
判断の原則はこうです。不可逆な被害（送金・削除・外部送信）が進行しているなら停止、そうでないなら隔離が第一候補です。隔離はネットワークでいう「ミラーポートに流しながらVLANを分ける」対応に相当し、証拠を生かしたまま被害を止められます。
マルチエージェント構成では、封じ込めの単位にも注意が必要です。汚染されたエージェントの出力を受け取った下流エージェントのメモリも汚染されている前提で、「上流1体の停止」ではなく「汚染時点以降に通信した全エージェント」を封じ込め対象に含めます。
フェーズ4：根本原因分析——非決定性の中で「注入点」を特定する
AI-IRの根本原因分析で答えるべき問いは、突き詰めれば2つです。「汚染はいつ・どこから注入されたか（注入点）」「その後どこまで影響が及んだか（影響範囲）」。
手順は時間軸を遡る形になります。
- 異常な出力・操作を起点に、ツール呼び出し履歴を遡る：異常な操作の直前に、どの入力・どの取得コンテンツがコンテキストに入ったかを特定します。知覚層インジェクションのように、注入経路が「ユーザー入力」ではなく「エージェントが見たWebページ・ドキュメント・画面」であるケースが増えている点に注意してください。
- メモリの差分をとる：保全したメモリスナップショットと、正常だった時点のバックアップを突き合わせ、注入されたエントリ・書き換えられた目標・追加された「ルール」を特定します。ここで平時のスナップショット（フェーズ0）が効きます。
- 注入時点以降の全出力を洗い出す：注入点が特定できたら、その時点以降にエージェントが行った出力・書き込み・下流への指示をすべてリストアップし、被害評価の対象にします。
ここで効くのが、セマンティック・テレメトリ記事で扱った「なぜそうしたか」のログです。「何をしたか」の操作ログだけでは、異常な操作が汚染由来なのか、単なるモデルの誤りなのかを区別できません。判断根拠（どのコンテキストを参照して、どの目標に基づいて行動したか）が記録されていれば、非決定性のあるシステムでも記録から判断過程を復元することができます。逆に言えば、この記録がない状態で発生したインシデントの多くは、根本原因が「不明」のまま閉じることになります。
フェーズ5：根絶と復旧——汚染メモリの特定と除染
従来IRの「根絶」はマルウェアの駆除・パッチ適用でした。AI-IRの根絶は「汚染された状態の除染」です。対象ごとに手順が異なります。
- 会話コンテキスト：該当セッションは復旧に使わず破棄します（保全済みのコピーは分析用に保持）。「汚染部分だけ削って続ける」は、要約や参照に汚染が染み出している可能性があるため推奨しません。
- セッション／長期メモリ：注入点が特定できていれば、注入時点より前のスナップショットへロールバックするのが最も確実です。特定できない場合は、メモリの全消去＋再学習（クリーンなソースからの再構築）を選びます。「怪しいエントリだけ削除」は、言い換え・分散注入で複数エントリに汚染が散っている場合に取り残しが出ます。
- ベクトルDB：汚染エントリの削除に加え、そのエントリを由来とする派生データ（要約・キャッシュ・別コレクションへの複製）まで追跡して削除します。エントリごとのプロビナンス記録（フェーズ0）がここでも効きます。
- 下流システム：汚染期間中にエージェントが書き込んだ先（チケット・ドキュメント・DB・他エージェントのメモリ）を洗い出し、内容の検証と修正を行います。
復旧の際は、再発条件が残ったままの再開を避けることが最重要です。注入経路（例：外部Webの取り込み、特定のツール権限）を塞ぐ緩和策を先に入れ、復旧後の一定期間は検知感度を上げた「観察運転」とします。復旧直後のエージェントが正常に見えても、監視下でだけ従順に振る舞う可能性を排除できない場合は、差分テスト・カナリア環境での検証を挟んでください。
フェーズ6：教訓と再発防止——「AIインシデント報告書」の書き方
事後レビューでは、従来の報告書項目（時系列・影響・原因・対策）に加えて、AI特有の観点を必ず残します。
- 保全できた証拠・できなかった証拠：「コンテキストの原文が圧縮済みで取れなかった」等の失敗は、フェーズ0の整備項目に直結する最も価値ある教訓です。
- 検知から封じ込めまでの時間と、その間の汚染出力数：AI-IRのKPIは「封じ込めまでの時間」だけでなく「その間に汚染された判断が何件、どこへ出たか」です。
- ATLASテクニックへのマッピング：インシデントをMITRE ATLASのテクニックに対応づけて記録すると、社内の複数事例の横比較と、脅威インテリジェンスとの突合が可能になります。
- プレイブックの更新：封じ込め判断で迷った点・権限が足りなかった点を、判断基準と権限設計にフィードバックします。
AI-IRプレイブック・チェックリスト
| フェーズ | やること | AI特有のポイント |
|---|---|---|
| 0. 準備 | エビデンス・インベントリ整備／封じ込め権限の文書化 | スナップショット取得を平時に訓練 |
| 1. 検知・トリアージ | 継続性・権限・伝播の3軸で評価 | トリアージと同時に保全を開始 |
| 2. 証拠保全 | 揮発性の高い順に取得（コンテキスト→メモリ→ベクトルDB→ログ） | エージェント自身に保全させない |
| 3. 封じ込め | 停止／隔離／縮退を被害とトレードオフで選択 | 不可逆な被害がなければ隔離を第一候補に |
| 4. 原因分析 | 注入点の特定→注入以降の全出力を洗い出し | 「なぜそうしたか」のログで判断過程を復元 |
| 5. 根絶・復旧 | スナップショットへのロールバック／派生データまで除染 | 「怪しいエントリだけ削除」は取り残しのもと |
| 6. 教訓 | 保全の成否・封じ込め時間・ATLASマッピングを記録 | 失敗した保全こそ次の準備項目 |
よくある質問（Q&A）
Q1. インシデントを検知したら、まずエージェントを止めるべきですか？
「不可逆な被害が進行中か」で決めてください。送金・削除・外部送信のような取り返しのつかない操作が動いているなら即時停止です。そうでなければ、停止はコンテキストやセッションメモリという最も揮発性の高い証拠を消すため、ツール実行と外部書き込みだけを遮断する「隔離」を第一候補にし、保全完了後に停止します。
Q2. 会話ログを保存しているので、証拠保全は足りていますか？
多くの場合、足りません。確認すべきは3点です。(1) 保存されているのは圧縮・要約後ではなく原文か、(2) ツール呼び出しの引数・戻り値まで残っているか、(3) メモリとベクトルDBのスナップショットを取る手段があるか。特にメモリは「会話ログには残らない場所」に汚染が居座るため、ログだけでは注入点の特定ができないケースが頻発します。
Q3. 汚染されたメモリは、怪しいエントリだけ削除すれば良いですか？
推奨しません。攻撃者は言い換えや分散注入で汚染を複数エントリに散らすため、目視で特定できた分だけ消しても取り残しが出ます。注入時点が特定できているなら、その直前のスナップショットへのロールバックが最も確実です。特定できない場合は全消去とクリーンなソースからの再構築を検討してください。また、汚染エントリから生成された要約・キャッシュ・複製など派生データの追跡も忘れずに。
Q4. 根本原因分析で「再現テスト」ができません。どうすれば良いですか？
LLMは非決定的なので、従来型の「同じ入力で同じ事故を再現する」は原理的に成立しないことがあります。AI-IRでの再現性は「当時の判断過程を記録から復元できること」と定義し直してください。そのためには、操作ログに加えて、どのコンテキストを参照しどの目標に基づいたかという判断根拠のログ（意図トレース）が必要です。この記録は事故後には取れないため、平時のログ設計がそのまま原因分析の可否を決めます。
Q5. 小規模なチームでも、ここまでのIR体制が必要ですか？
全フェーズをフル装備する必要はありません。最小構成として推奨するのは3点です。(1) 圧縮前の会話ログとツール呼び出し履歴を別系統に常時保存する、(2) メモリ・ベクトルDBのエクスポート手順を一度実際に試しておく、(3) 「誰がエージェントを止めてよいか」を1枚のドキュメントにしておく。この3つがあるだけで、事故発生時に「証拠が何も残っていない」という最悪の事態は避けられます。
まとめ——IRの主戦場は「検知の前」から「検知の後」へ
AIセキュリティの議論は、長らく検知と防御——ガードレール、振る舞い検知、入力検証——に集中してきました。しかし防御の整備が進むほど、次に問われるのは「それでも起きた事故に、組織としてどう動くか」です。要点は3つです。
1. AIインシデントの証拠は、放っておくと消える。会話コンテキスト・メモリ・ベクトルDBという揮発性の高い場所に痕跡が集中するため、「分析してから保全」では間に合いません。疑った時点で、揮発性の高い順に取る——これが第一原則です。
2. 封じ込めは「停止一択」ではない。停止は証拠を消します。不可逆な被害が進行していない限り、ツール実行と外部書き込みを遮断する「隔離」で証拠を生かしたまま被害を止め、保全完了後に止める——この順序を平時に決めておきます。
3. 原因分析の成否は、事故の前に決まっている。非決定的なシステムでは再現テストに頼れず、「当時の判断過程を記録から復元できるか」がすべてです。判断根拠のログとメモリのスナップショットという平時の備えが、そのまま根本原因分析の可否を決めます。
ネットワーク運用の世界では「障害は起きるもの。差がつくのは復旧と再発防止」というのが常識でした。AIエージェントの運用も、同じ地点に到達しつつあります。検知・防御の多層化とセットで、「検知した後の動き方」を組織の手順として持つこと——それが2026年のAI運用に求められる成熟度です。
参考リンク
- NIST SP 800-61 Rev.3「Incident Response Recommendations and Considerations for Cybersecurity Risk Management」
- OWASP「GenAI Incident Response Guide 1.0」
- OWASP Top 10 for LLM Applications（2025年版）
- MITRE ATLAS（AIシステム向け敵対的脅威ランドスケープ）
- RFC 3227「Guidelines for Evidence Collection and Archiving」
免責事項：本記事は2026年7月時点の公開情報および標準フレームワークに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際のインシデント対応体制は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家や弁護士にご相談ください。フレームワークやガイドラインは更新されるため、最新情報は各公式ソースでご確認ください。
コメント