【コピペOK】AIインシデント初動対応フロー — 「AIが変なことをした」最初の60分にやること

「AIが変な回答をした」「AIエージェントが想定外の操作をしたようだ」——そのとき最初の60分に何をするかで、被害の大きさと社内外への説明のしやすさが決まります。

海外では2025年、AIエージェントが指示に反して本番データベースを削除した事例(Replit社。出典: The Register https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/ )や、サポートAIが存在しないポリシーを回答して解約が続出した事例(Cursor社。出典: The Register https://www.theregister.com/2025/04/18/cursor_ai_support_bot_lies/ )が実際に起きています(詳細は当マガジンの「AIエージェント事故簿」参照)。このフローは、そうした事例から逆算した初動の型です。社内の手順書にそのままコピペして使ってください。

STEP 0(平時・今日やる): 止め方を決めておく

・このAI/エージェントを止める方法(API無効化、アカウント停止、接続解除)を1行で書けるか
・止める権限を持つ人と、夜間休日の連絡先はどこか
・この2つが書けないなら、それが最初のリスクです。導入時に必ず整備を

STEP 1(検知〜10分): 止める・広げない

・当該AI/エージェントの動作を停止(まず狭い単位で: 該当ツール接続のみ→ダメなら全体)
・停止できない場合は、接続先(DB・SaaS・外部送信経路)側でアクセスを遮断
・判断に迷ったら「止める」を選ぶ。AIの停止は業務影響が読みやすく、暴走の放置は読めない

STEP 2(〜30分): 記録を確保する

・ツール呼び出しログ、会話ログ、操作対象のデータの現状をこの時点で保全(スクショ・エクスポート)
・「後で調べよう」は禁物。ログのローテーションや上書きで消える前に確保する
・現場での復旧作業はログ保全の後。先に直すと原因が消えます

STEP 3(〜60分): 影響範囲を3つの問いで見積もる

・何のデータに触れた可能性があるか(個人情報・顧客情報を含むか)
・外部に出た可能性はあるか(メール送信、外部API、公開投稿)
・操作は完了したか、進行中か(進行中なら STEP 1 に戻り遮断を強化)

STEP 4(当日中): 報告する

・社内: 情シス/セキュリティ窓口へ第一報(わかっていること・わからないことを区別して)
・個人情報が関係する場合: 個人情報保護の担当部署へ。漏えいの恐れがあれば、個人情報保護委員会への報告・本人通知が必要になる場合があるため、判断は法務・専門部署へ引き継ぐ
・顧客データが関係する場合: 顧客への説明方針を決めてから技術対応の詳細を進める

STEP 5(事後1週間以内): 再発防止を仕組みに落とす

・原因を「AIのせい」で終わらせない。権限設計・承認フロー・検証工程のどこに穴があったかを特定
・当マガジンの「導入前チェックリスト18項目」を事後監査として再実施し、空欄だった項目を埋める
・インシデント記録を台帳に残す(次の稟議・監査での説明資料になります)

使い方のヒント

・このフローを1枚にして、AIを使う部署の全員が見られる場所に置いてください。「STEP 0が書けない」ことに導入前に気づけるのが、このテンプレの一番の価値です
・報告様式は自社のセキュリティインシデント様式に合わせて構いません。大事なのは順番(止める→記録→見積もる→報告)です

※用語メモ:エージェント=AIが自分でツールを呼んで操作を実行する仕組み。ログのローテーション=古いログが一定期間で自動的に上書き・削除される運用のこと。

本テンプレはAI(Claude)を活用して作成し、公開前に人間がレビューしています。引用した海外事例(Replit・Cursor)は本文にリンクした出典で確認できます。法的判断が必要な場面では自社の法務・専門部署の指示を優先してください。