AIインシデント対応チェックリスト｜情シスが最初の30分でやること、止める基準、復旧前確認

AIの誤回答、機密情報の入力、権限外データの参照、自動送信の誤作動が起きたとき、情シスが最初にやるべきことは「全部止める」ではありません。まず必要なのは、証跡を消さずに残し、影響範囲を仮判定し、止める範囲を段階的に決めることです。

AIインシデントは、通常のシステム障害と違い、原因がモデル、プロンプト、参照データ、権限設定、外部API、利用者操作のどこにあるか切り分けにくいのが特徴です。さらに、個人情報や顧客情報が関係する場合は、社内調査だけで終わらず、報告・本人通知・法務判断が必要になる可能性があります。

総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」は、AIに関する重要な取組事項として、安全性、プライバシー、セキュリティ、透明性、アカウンタビリティ、AIガバナンス等を示しています。AIインシデント対応も、単なる障害対応ではなく、AIガバナンスの一部として設計する必要があります。

まず決める：AIインシデントとして扱う範囲

現場が迷うのは、「AIが少し変な回答をしただけ」なのか、「インシデントとして情シスへ上げるべき事象」なのかの境目です。判断を早くするには、発生事実が確定する前でも、次のどれかに当てはまれば一次受付するルールにします。

ポイントは、「AIが間違えたか」だけでなく、外部影響、情報保護、業務継続、説明責任で見ることです。疑いの段階で証跡を残し、問題でなければクローズすればよい、という運用にした方が初動は安定します。

最初の30分でやること：原因究明ではなく、証跡保全と仮判定

最初の30分で完全な原因特定を目指すと、かえって対応が遅れます。30分のゴールは、原因断定ではなく、次の5点です。

• 報告内容をチケット化し、連絡先と時刻を残す
• 入力、出力、画面、添付ファイル、送信先を保存する
• AI利用ログ、監査ログ、アクセスログ、外部連携ログを保全する
• 影響範囲を「社内限定」「特定部署」「顧客影響あり」「不明」に仮分類する
• 監視継続、限定停止、機能停止、全体停止のどれにするかを決める

NIST SP 800-61 Revision 3は、インシデント対応をサイバーセキュリティリスク管理全体に組み込む考え方を示し、検知、対応、復旧を継続的改善につなげることを重視しています。AIインシデントでも、初動、復旧、レビューを分けず、平時のガバナンス改善に戻す設計が必要です。

止める基準：全停止ではなく4段階で判断する

AI機能を止めるかどうかは、感覚ではなく基準で決めます。特に、証跡が不十分なまま全停止すると、再現確認ができず、復旧判断が難しくなることがあります。一方で、情報漏えいや外部誤送信が継続している疑いがあるなら、限定停止では足りません。

停止判断では、利用しているAIサービスの契約プラン、SLA、DPA、管理者権限、ログ保存期間、ログ取得方法をランブックに記載しておきます。特に、誰が管理画面で操作できるか、どのログをいつまで確認できるか、APIキーやコネクタを誰が停止できるか、復旧時にどの設定へ戻すかを明確にしておくことが重要です。

契約条件やログ保存期間が確認できていない場合は、全社展開や自動実行を急がず、限定利用の範囲で停止・復旧手順を確認してから段階的に広げます。

個人情報が関係する場合：情シスだけで判断しない

AIへの入力や出力に個人データが含まれる疑いがある場合、情シスだけで「問題なし」と判断しないでください。個人情報保護委員会は、漏えい等報告が必要な場合や報告期限を公表しています。報告期限については、発覚後まず速やかに速報を行い、確報は原則30日以内、不正目的のおそれがある場合は60日以内とされています。

また、要配慮個人情報が含まれる個人データ、不正利用により財産的被害が生じるおそれがある個人データ、不正目的のおそれがある行為による漏えい等、本人の数が1,000人を超える個人データの漏えい等は、報告対象として示されています。AIインシデントでこの可能性がある場合は、一次判定の段階で法務・個人情報保護担当へ連絡します。

証跡保全チェックリスト：スクリーンショットだけで終わらせない

スクリーンショットは重要ですが、それだけでは不十分です。AIインシデントでは、入力、出力、モデル・機能、参照データ、権限、外部連携、最終利用先をつなげて説明できる状態にします。

• 発生日時、報告日時、利用者、部署、対象業務
• AIツール名、機能名、モデル名、ワークフロー名
• 入力プロンプト、添付ファイル、参照ファイル、出力全文
• リクエストID、セッションID、チケットID、URL、ファイルID
• 監査ログ、アクセスログ、管理者操作ログ、コネクタログ、APIログ
• 最終送信文、公開資料、顧客連絡履歴、承認履歴
• 保全担当者、保存先、保存時刻、アクセス権設定

証跡の保存先は、個人PCや誰でも見られる共有フォルダにしないでください。証跡自体に機密情報や個人情報が含まれる可能性があります。平時から、証跡の保存先、アクセスできる担当者、保存期間、ファイル命名規則、削除・上書き防止の方法を決めておきます。保全後は関係者以外の閲覧を制限し、調査が完了するまで証跡を削除・更新しない運用にします。

社内一次連絡テンプレート

初動連絡では、確定情報と未確定情報を分けます。原因を断定せず、現場にやってほしいことだけを明確にします。

件名：［一次連絡］AI利用に関する確認対応について（AI-INC-YYYY-XXX）

関係者各位

現在、以下のAI利用について確認対応を開始しています。現時点では原因・影響範囲を調査中です。

・発生日時：YYYY/MM/DD HH:MM頃
・対象業務：〇〇業務
・対象AIツール：〇〇
・確認中の事象：誤回答／情報漏えい疑い／権限外参照疑い／自動処理誤作動
・現時点の影響範囲：調査中／対象部署のみ／社外影響確認中

お願い事項：該当画面、出力、チケット、メール、添付ファイルを削除しないでください。情シスから案内があるまで、同じ操作の再実行、顧客・取引先への個別回答、設定変更は控えてください。

次回更新予定：YYYY/MM/DD HH:MM

復旧前チェック：戻す前に「何を直したか」を残す

原因らしきものが見つかっても、すぐ全社復旧しないでください。復旧前には、原因仮説、修正内容、回帰テスト、承認者、監視項目を残します。

NIST AI RMF 1.0は、AIリスク管理の機能としてGovern、Map、Measure、Manageを示しています。復旧後レビューでは、単に「直った」で終わらせず、どのリスクを把握し、何を測定し、どの統制を管理対象に戻すのかまで記録します。

復旧後レビュー：再発防止策を技術対策と運用対策に分ける

レビューでは、責任追及よりも、次に早く検知し、早く止め、説明できる状態を作ることを目的にします。最低限、次の観点で確認してください。

• 検知：誰が、どの時点で、どの経路で気づいたか
• 証跡：プロンプト、出力、ログ、承認履歴が残っていたか
• 判断：停止範囲、承認者、連絡タイミングは妥当だったか
• 原因：データ、権限、プロンプト、モデル、外部連携、教育のどこに問題があったか
• 再発防止：技術設定、運用ルール、教育、監査、契約確認のどれを更新するか

AIインシデント対応のランブックには、最後に「更新先」を書きます。たとえば、AI利用ルール、禁止入力例、承認フロー、アクセス権棚卸し、ログ保持ポリシー、DLP設定、教育資料、委託先確認項目などです。ここまで戻して初めて、インシデント対応はAI運用の改善につながります。

そのまま使えるランブック最小構成

• AIインシデントの定義と重大度分類
• 最初の30分の受付・保全・仮判定手順
• 証跡保存先、命名規則、アクセス権、保存期間
• 監視継続、限定停止、機能停止、全体停止の判断表
• 法務・個人情報保護担当・広報・経営へのエスカレーション条件
• 社内一次連絡テンプレート、社外連絡の作成責任者
• 復旧前チェック、復旧承認者、復旧後監視項目
• 復旧後レビューと、AI利用ルール・教育・技術設定への反映先

AIインシデントで重要なのは、初動で慌てて止めることではありません。証跡を残し、影響範囲を切り分け、止める範囲を段階化し、復旧後にルールへ戻すことです。最初の30分をランブック化しておけば、担当者が変わっても、説明可能な対応に近づけます。