AIインシデント対応フローの作り方｜連絡体制とキルスイッチ

「AIが顧客情報を混ぜて回答してしまった」「生成AIのチャットボットが誤った案内を続けている」——生成AIを業務に組み込むほど、こうした“事故”は「起きるかどうか」ではなく「起きたとき、どれだけ早く止められるか」の問題になります。ところが多くの企業では、情報漏えいや設備事故の対応手順はあっても、AIインシデント専用の対応フローがありません。誰に一報を入れ、誰の判断で使用を止めるのかが決まっていないと、対応は現場の即興任せになり、被害が広がります。

この記事では、AIインシデント対応フローの作り方を、国際標準のNIST AI RMF（特に対応を担う「MANAGE」機能）と、国のAI事業者ガイドライン（総務省・経済産業省）に沿って解説します。検知から復旧・再発防止までの6ステップ、被害拡大を止めるキルスイッチ（利用停止権限）の設計、連絡体制とログ・監査まで、担当者がそのまま着手できる形でまとめました。

この記事は、企業向けAIセキュリティ研修「AIガバナンス大学」の教材知見をもとに構成しています。インシデント対応は、平時のガイドラインと同じく「基準を作る側・監査する側」の視点で設計すると、抜け漏れが一気に減ります。本記事もその観点を反映しています。

AIインシデントとは何か（主な3類型）

AIインシデントとは、AIの利用に起因して、情報・権利・業務・信用に損害を与える（またはそのおそれがある）事象を指します。従来のシステム障害と違い、「動いているのに間違っている」「悪意ある入力で挙動が変わる」という、AI特有の壊れ方をするのが特徴です。まずは自社で起こりうる型を押さえます。

このほか、著作権を侵害する生成物の公開、差別的・不適切な出力なども含まれます。共通するのは、「気づくのが遅れるほど被害が拡大する」という性質です。だからこそ、事後の対応フローを平時に決めておく価値があります。

AIインシデント対応フローの作り方（6ステップ）

対応フローは自己流で並べるより、国際標準の型に沿うのが近道です。NIST AI RMFは、AIリスク管理を GOVERN（統治）／MAP（把握）／MEASURE（測定）／MANAGE（対応） の4機能で整理しており、インシデント発生後の対応・復旧・関係者への連絡は最後のMANAGEに位置づけられています（4機能の全体像は「NIST AI RMFとは」の記事で解説します）。これを実務の時系列に落とすと、次の6ステップになります。

ポイントは、③初動を④原因究明より先に置くことです。原因が完全にわかる前でも、「まず止めて被害を広げない」判断を優先します。原因究明を待ってから止めていては、その間ずっと漏えいや誤情報が拡散し続けるからです。「止める→調べる→直す」の順番を、フローとして固定しておきます。

キルスイッチ（利用停止の権限と判断者）

対応フローの心臓部がキルスイッチ、すなわち「危ないと判断したら、該当AIの利用を即時停止する権限と手順」です。技術的な停止ボタンだけでなく、誰の判断で・どうやって止めるかという運用の取り決めまでを指します。

設計で決めておくのは、次の4点です。

• 判断者（誰が止める）：一次判断はインシデント責任者、責任者不在時は情シス管理者、というように代行者まで決めます。「誰も判断できず止まらない」を防ぐためです。
• 停止の手段（どう止める）：アカウント停止、API連携の遮断、該当機能のオフ、社内周知による利用中止など、ツールごとに具体的な止め方を用意します。
• 発動基準（いつ止める）：「機密情報の漏えいが疑われる」「誤情報を外部に発信中」など、迷わず発動できる基準を例示します。迷ったら止めるを原則にします。
• 再開の条件（どう戻す）：原因の特定と対策後、誰の承認で再開するか。止めることと同じくらい、安全な再開手順も重要です。

監査の観点では、「禁止事項が書いてあるか」よりも「破られたときに気づき、止められる仕組みがあるか」までがガバナンスの本体です。キルスイッチは、その“止められる仕組み”を担保する要になります。

キルスイッチと入力禁止事項は、平時のAI利用ガイドラインに項目として組み込んでおくと、いざというとき機能します。

連絡体制とエスカレーション

初動を速くする決め手は、「誰に一報を入れればいいか」が全社員に共有されていることです。報告先が曖昧だと、現場は「大ごとにしたくない」と抱え込み、発覚が遅れます。次の3層で経路を単純化します。

1. 発見者 →（第一報）→ 一次受付窓口：情シスやAI推進担当など、窓口を一本化。メール・チャットなど手段も指定。
2. 窓口 →（判断）→ インシデント責任者：影響度を評価し、キルスイッチ発動や次のエスカレーションを判断。
3. 責任者 →（重大時）→ 経営層・関係部門・外部：個人情報漏えいなど重大な場合は、経営層・法務・広報、必要に応じて監督官庁や本人への通知・報告へ拡大。

判断を速くするため、影響度に応じたレベル分け（例：軽微＝現場対応／中＝責任者対応／重大＝経営層招集）をあらかじめ用意します。AI事業者ガイドラインでも、インシデント情報の適切な共有・報告と、関係者との連携が重視されています。「隠すと評価が下がり、早く上げると評価される」という文化づくりも、体制と同じくらい重要です。

ログ取得と監査（後から追える状態をつくる）

「いつ・誰が・何を入力し・どんな出力が出たか」のログがなければ、原因究明も影響範囲の特定もできません。NIST AI RMFのMANAGEでも、インシデントの追跡・対応・記録の重要性が示されています。最低限、次を残せる状態にします。

• 利用ログ：利用者、日時、使用ツール、入出力の記録（機密のマスキング方針も併せて決める）
• 対応ログ：検知・第一報・停止・復旧の各時刻と判断者、対応内容
• 監査：ログを定期的に点検し、禁止情報の入力やヒヤリハットを早期に発見。インシデントは記録として蓄積し、再発防止と教育に回す

ログは「取っておく」だけでなく、責任者が読める形で残すことが肝心です。復旧後には、原因・影響・対応・再発防止をまとめた記録を残し、次に活かします。

平時の備え（起きてから作らない）

対応フローは、インシデントが起きてから作っても間に合いません。平時に次を準備しておきます。

• 対応フロー・連絡体制・キルスイッチを文書化し、ガイドラインに組み込む
• 年1回以上の訓練（机上演習）：「漏えいが起きた」想定で、通報〜停止〜復旧を実際に手を動かして確認
• 全社教育：類型と通報先を全社員が知っている状態に。特に「迷ったらすぐ報告」を徹底
• 窓口と代行者の周知：担当が不在でも回る体制に

よくある失敗

• 止める権限を決めていない：誰も止められず、被害が拡大。判断者と代行者を必ず先に決める。
• 原因究明を待って止めない：調べている間に漏えい・誤情報が拡散。「まず止める」を初動に固定する。
• 報告先が曖昧で抱え込みが起きる：窓口を一本化し、早期報告を評価する文化にする。
• ログを取っていない：後から何も追えず、影響範囲すら不明。利用開始と同時にログ設計する。
• 作って訓練しない：フローが紙のまま。年1回の演習で“動くフロー”にする。

よくある質問

Q1. AIインシデントは、通常のシステム障害対応（CSIRT）とは別に用意すべきですか？ A. ゼロから作る必要はありません。既存のインシデント対応体制をベースに、AI特有の論点（誤情報・プロンプトインジェクション・キルスイッチ・入出力ログ）を追記するのが現実的です。窓口や連絡体制は共通化できます。

Q2. キルスイッチは、技術的に自動停止できないと意味がないですか？ A. いいえ。まずは「誰の判断で・どの手順で止めるか」という運用の取り決めがあれば機能します。アカウント停止や社内周知による利用中止でも十分に被害拡大を止められます。自動化は次の段階で検討すれば構いません。

Q3. 中小企業でも対応フローは必要ですか？ A. 必要です。むしろ専任部署がない中小企業ほど、1ページの簡潔なフロー（通報先・止める人・手順）を決めておく効果が大きいです。本記事の6ステップを絞り込めば、小さく始められます。

Q4. 誤情報の発信（ハルシネーション）も「インシデント」として扱うのですか？ A. はい。顧客や社外に誤った情報を発信した時点で、信用や取引に損害を与えうる立派なインシデントです。訂正・通知・原因記録まで、漏えいと同じフローで扱います。予防はHuman-in-the-loop（人による最終確認）が基本です。

Q5. 監督官庁や本人への報告は、どんなときに必要ですか？ A. 個人情報の漏えい等では、法令に基づく本人通知や監督機関への報告義務が生じる場合があります。重大インシデントでは早い段階で法務・専門家に相談し、報告要否を判断する経路をフローに組み込んでおくと安全です（具体的な要否は事案ごとに要確認）。

まとめ

AIインシデントは「起きる前提」で備えるものです。要点を整理します。

• AIインシデントの主な型は情報漏えい・誤情報の拡散・不正操作。共通点は「気づくのが遅れるほど被害が拡大する」こと。
• 対応フローは検知→第一報→初動（封じ込め）→原因究明→復旧→再発防止の6ステップ。「まず止めてから調べる」順番を固定する。
• 心臓部はキルスイッチ。判断者・代行者・止め方・発動基準・再開条件を決めておく。
• 連絡体制は3層で単純化し、早期報告を評価する文化にする。ログがなければ究明も影響特定もできない。
• フローは平時に作り、年1回の訓練で動くフローにする。

自社がどの類型に弱く、止める権限が誰にあるのかは、一社ごとに異なります。まずは現在地の把握から始めてみてください。