生成AIのインシデント対応の備え方｜誤回答・情報漏えい・エージェント暴走を「検知して止めて戻す」手順を平時に決める

生成AIの社内利用ルールを作り、入力してよい情報を線引きし、ガードレールやプロンプトインジェクション対策を入れる。ここまでは「事故を起こさないため」の備えです。しかし、出力が毎回変わり、外部の文書やツールに依存して動くシステムでは、どれだけ予防を重ねても想定外の出来事は起こります。問題は、起きたときに「誰が気づき、どこを止め、どう戻すか」が決まっているかどうかです。

この記事では、日本のAIセーフティ・インスティテュート(AISI)が2026年1月9日に公表した「AIインシデントレスポンス・アプローチブック」(以下、アプローチブック)が示すAI-IRS(AI Incident Response System)という枠組みを参照しながら、一般企業の社内利用やLLMアプリの運用チームが平時に決めておくべきことを、ランブック(対応手順書)を作る目線で整理します。

生成AIのインシデントは従来のシステム障害と何が違うか#

アプローチブックは、AIシステムにおける発見的統制の課題として「原因分析の困難性」と「固定的対応の限界」の2つを挙げています。AIモデル・データ・外部サービスが複雑に依存し合うため異常の原因を切り分けにくいこと、確率的な振る舞いによって再現性が低いこと、そして運用中に挙動が変わるため固定的な対応策では過剰な停止につながりやすいこと、という整理です。

また、アプローチブックはAIインシデントについて、発生時点でAIに起因すると特定できるものではなく、多くの場合は従来型のインシデント対応の検知プロセスでサイバーセキュリティインシデントとして見つかり、原因分析を通じてAIに関する異常であることが示唆される、と説明しています。つまり「AI専用の窓口」を別に作るよりも、既存のインシデント対応の流れにAI固有の確認観点を足すほうが現実的です。

実務上は、これに加えて次の違いを意識しておくと手順が組みやすくなります。

• 利用者が誤りに気づかないまま使ってしまう。誤った回答が資料やメールに転記され、社外に出てから発覚することがある
• 「障害」と「仕様どおりの出力」の境目があいまい。システムは正常に応答しているのに、内容が業務上の許容範囲を超えている
• 原因の候補が多い。モデルの更新、プロンプトの変更、参照データの混入や改ざん、外部入力に仕込まれた指示、ベンダー側の変更のどれでも同じ症状が出うる

典型パターンの分類#

ランブックを作る最初の作業は、自社で起こりうる出来事を種類ごとに並べることです。次の表は、よく想定されるパターンを「最初に気づくのは誰か」「主な封じ込めの単位」とあわせて整理した一例です。右端の列は、関連が深いOWASP Top 10 for LLM Applications(2025年版)の項目名です。

表の「例」は説明のための想定で、特定の事故事例を指すものではありません。自社版を作るときは、実際に使っているサービスや機能の名前で書き換えてください。

観測性と制御性の2軸で自社の現在地を点検する#

アプローチブックが示すAI-IRSの中心にあるのが、「観測性(可視化)」と「制御性(封じ込め)」という2つの評価軸です。観測性はAIの判断根拠や内部状態、データの流れを把握できる程度、制御性はAIの挙動を状況に合わせて止めたり変えたりして影響を最小限に留められる程度を指します。アプローチブックはこの2軸の組み合わせで対応能力を4つの象限に分類しています。

アプローチブックは「可観測・可制御」を目標にしつつ、段階的に改善していくことを基本的なゴールとしており、具体的に求められる内容は組織やサービスの状況によって異なるとしています。表の読み替え例は筆者による当てはめで、アプローチブックに書かれている事例ではありません。

点検のコツは、機能ごとに「いま問題が起きたら、何を見て、何を止めるか」を具体的に書き出してみることです。「ログはある」「止められる」と漠然と答えられても、実際には保存期間が短すぎたり、止める操作の権限を持つ人が休暇中だったりします。

アプローチブックは、インシデント対応のライフサイクル(準備、検知・分析、封じ込め・根絶・復旧、事後対応)を参照点とし、そのうち検知・分析に求められる能力を観測性、封じ込め・根絶・復旧に求められる能力を制御性として整理しています。なお、参照先のNIST SP 800-61 Rev. 3(2025年4月)自体は、CSF 2.0の6つの機能(Govern、Identify、Protect、Detect、Respond、Recover)にもとづくモデルへ再構成されており、上記の4段階は旧版(Rev. 2)のライフサイクルモデルとして対応表つきで示されています。Rev. 3は、組織に合ったライフサイクルのモデルを使えばよいとしています。この記事では、手順を追いやすくするために4段階の呼び方を使います。

平時に用意しておくもの#

インシデントが起きてから決めようとすると、判断のたびに関係者を集めることになり、その間も誤った出力や操作が続きます。最低限、次の4つは事前に文書化しておきます。

報告窓口と「これはインシデントか」の判断基準#

生成AIの出来事は、利用者が「こんなことで報告してよいのか」と迷いやすい性質があります。誤回答のたびに大騒ぎする必要はありませんが、報告されなければ観測性は上がりません。入口は広く、判断は窓口側で行う形にするのが扱いやすいです。

判断基準は、出来事の種類ではなく影響の大きさで段階を分けると運用しやすくなります。次は一例です。

ポイントは、「迷ったら上の段階で報告してよい」と明記しておくことです。報告した人が責められる運用だと、次からは報告が上がらなくなります。

証跡:何をどこまで残すか#

原因の切り分けには、少なくとも次の情報が必要になります。アプローチブックも、観測性を高める例として、推論の履歴などの動作追跡、学習データ・モデル情報・RAGなど構成要素の追跡可能性の確保、入出力の不規則な変化のリアルタイム検知を挙げています。

• 入力(ユーザーの質問、システムプロンプトのバージョン)
• 出力(応答本文、構造化出力の結果)
• 参照した文書(RAGで取得した文書のIDと、その時点の版)
• ツール呼び出し(呼んだツール名、引数、結果、実行を承認した人)
• 構成情報(モデル名とバージョン、パラメータ、プロンプトやガードレール設定の版)

ここで悩ましいのが個人情報との両立です。入出力の本文をそのまま長期間残すと、ログそのものが新たな漏えいリスクになります。本文はマスキングしたうえで短期間だけ保持し、文書IDやツール呼び出しなどのメタデータは長めに残す、アクセスできる人を絞る、といった設計を事前に決めておきます。社外の生成AIサービスを使う社内利用では、管理画面から取得できるログの範囲と保持期間を契約前に確認しておくことが、観測性の上限を決めます。

止める手段:全停止の手前に段階を作る#

アプローチブックは、制御性の強化について、システム全体を一括停止するのではなく、特定モジュールの停止や機能の切り替えを局所的に行えるように設計することを挙げています。例としては、別バージョンや代替モデルへの即時切り替え、AIエージェントによる不正なAPI利用の即時切り離し、異常時に影響を受けない上位権限を持ち隔離された制御インタフェースの設置が示されています。

これを一般的なLLMアプリに当てはめると、粒度の細かい順に次のような停止手段が考えられます。

1. 特定の文書やデータソースを検索対象から外す
2. RAGだけを切り離し、「社内文書を参照できないモード」で回答を続ける
3. エージェントから特定のツールの権限を外す、または副作用のある操作を承認必須に切り替える
4. プロンプトやガードレール設定を直前のバージョンへ切り戻す
5. モデルを以前のバージョンや別のモデルに切り替える
6. 該当機能だけを機能フラグで無効にし、定型文の案内や人手の窓口に誘導する
7. アプリ全体を停止する

NISTの生成AIプロファイル(NIST AI 600-1、2024年7月)も、意図した用途と整合しない挙動を示したAIシステムを置き換え・切り離し・停止する仕組みと責任分担を整えることを項目(MANAGE 2.4)として掲げ、停止を判断する基準を定めて定期的に見直すことを推奨アクションに含めています。また、ロールオーバーやフォールバック(代替手段)には手作業での処理が含まれうる点にも触れています。「止めたら業務が回らない」状態では停止の判断が遅れるため、縮退時の業務手順も一緒に決めておくのが要点です。

連絡先とベンダーとの取り決め#

社内の連絡網(運用チーム、情報セキュリティ担当、個人情報の担当部門、法務、広報、該当業務の責任者)に加えて、外部のモデルやサービスを使っている場合はベンダー側の窓口も一覧にしておきます。NIST AI 600-1は、ベンダー契約で確認する事項として、インシデントに関する責任の分担、第三者のデータやシステムに起因する重大インシデントの通知・開示、インシデント対応や応答時間を含むSLAなどを挙げています。障害情報を掲載するステータスページの場所や、モデルの提供終了・更新の告知を受け取る経路も、平時に確認しておく項目です。

発生時の初動手順#

実際に出来事が起きたときの流れを、ランブックの骨格として示します。順番どおりに一つずつ終わらせるというより、封じ込めを先行させながら分析を並行する場面も多くなります。

RAG型とエージェント型で変わる封じ込めの単位#

アプローチブックは代表的なユースケースとしてRAGとAIエージェントを分析しています。RAGについては、参照先のデータ汚染や、検索APIの情報の信頼性が十分に担保されないといったリスクがあり、観測点が入出力に限られると原因の切り分けが難しくなること、参照データに公開すべきでない個人情報が混入していた場合に問題のファイルやテーブルを局所的に切り離す手段がなければシステム全体の停止という過剰な制御になることを指摘しています。概要版では、RAGのトレース機能の導入や、原因となったRAGのみを切り離しRAGなしでもサービスを継続できる仕組みが例示されています。

AIエージェントについては、計画作成、API呼び出し、メモリ更新、ツール利用といった多段の処理が分散して行われるため、どの判断が逸脱したか把握しにくく、どの部分だけを止めるべきか判断が難しいため全体停止や業務中断に陥りやすいとしています。概要版では、コンポーネントごとの入出力をリアルタイムに検査する仕組みや、原因となったコンポーネントのみを停止・切り離す仕組みが例示されています。

エージェント型では、OWASPがLLM06 Excessive Agencyの根本原因として挙げる「過剰な機能」「過剰な権限」「過剰な自律性」を平時に絞っておくことが、そのまま封じ込めの範囲を小さくすることにつながります。

個人情報が関わるときの連絡#

事後対応:再発防止を仕組みに戻す#

復旧して報告書を書いたところで終わると、同じ種類の出来事がまた起こります。事後対応で意識したいのは、学んだことを具体的な仕組みに戻すことです。

• 評価セットに事例を追加する。問題を起こした入力と、期待する振る舞いをテストケースにして、プロンプトやモデルを変更するたびに流す
• ガードレールや検知ルールを見直す。今回の症状を監視で拾えたか、拾えなかったなら何を追加すべきかを確認する
• 社内ルールや利用ガイドを更新する。利用者側の使い方が原因の一端であれば、禁止事項を増やすより、どう使えば安全かを具体例で伝える
• ランブック自体を更新する。連絡がつかなかった人、操作手順が分からなかった停止手段、判断に迷った点を書き足す

NIST AI 600-1は、関係するAIの担い手とともに事後分析(ポストモーテム)を行って根本原因を理解し、予防策を講じることや、インシデント対応と復旧のプロセスが守られ有効だったかを事後評価することを推奨アクションとして挙げています。また、NIST SP 800-61 Rev. 3は、インシデント対応で得た教訓は復旧の完了を待たず、特定でき次第共有すべきことが多いと述べています。対応が長引く場合も、途中で分かったことを関係者に早めに共有するほうが、類似の出来事を他の機能で防ぎやすくなります。

やりすぎになる場面・向かない場面#

インシデント対応の備えは、規模に合っていないと形骸化します。次のような点に注意してください。

• 個人が文章の下書きに使う程度の利用に、専用の対応チームや重厚な承認フローを用意する必要は通常ありません。報告窓口と、機密情報を入力してしまったときの連絡先が決まっていれば十分なことが多いです
• 誤回答をすべてインシデントとして扱うと、報告と対応の負荷で運用が止まり、本当に重要な報告が埋もれます。段階分けの基準で「記録」に留めるものを明確にしてください
• 反対に、停止手段が「全停止」しかない状態は、判断を遅らせる要因になります。止めると業務が回らないため様子見が続き、その間に被害が広がる、というのが典型的な失敗です
• 文書を作っただけで訓練をしないと、いざというときに手順が現状と合っていないことが判明します。年に一度でも、想定事例を使った机上訓練で手順を読み合わせる価値があります

アプローチブックも、発見的統制は予防的統制を代替するものではないと明記しています。ルールやガードレールによる予防と、この記事で扱った検知・封じ込め・復旧の備えは、両方をそろえて初めて機能します。

よくある質問#

まとめ#

生成AIのインシデント対応で大切なのは、完璧な予防を目指すことではなく、起きたときに「何が起きたか追えて、問題の箇所だけを止めて、元に戻せる」状態を少しずつ作ることです。まずは自社で使っている生成AIの機能を一つ選び、「いま問題が起きたら何を見て何を止めるか」を書き出すところから始めてみてください。