AI事故対応 インシデント・プレイブック ひな形
AI事故対応 インシデント・プレイブック ひな形
生成AIの業務利用が広がる一方で、プロンプトインジェクションによる情報漏洩、ハルシネーションに起因する誤案内、学習データの混入、モデル盗用といった「AI特有のインシデント」が現実化している。Samsungでは2023年、社内エンジニアがChatGPTにソースコードを貼り付けたことで機密情報の流出が問題となり、社内利用が一時禁止された[1]。Air Canadaでは自社チャットボットの誤案内が法廷で「会社の表示」と認定され、損害賠償が命じられた[2]。本記事はCISO・情シス責任者を対象に、NIST SP 800-61[3]の枠組みをAI領域に拡張し、検知から事後レビューまでを6フェーズで運用するプレイブックのひな形を示す。法令上の報告義務と経営者視点の意思決定までを一気通貫で扱う。
AI事故が「従来型インシデント」と異なる3つの特殊性
第一に、攻撃面（アタックサーフェス）がモデル・プロンプト・学習データ・出力経路の全層に拡大する。MITRE ATLAS[4]はこれをML特化の戦術・技術として体系化しており、Reconnaissanceから Exfiltration、Impact までAIシステム特有の攻撃シーケンスを示す。OWASP Top 10 for LLM Applications[5]でもプロンプトインジェクション（LLM01）、機微情報漏えい（LLM06）、過剰権限（LLM08）が上位に挙げられる。第二に、被害が「確率的」かつ「説明困難」である点だ。同じ入力でも出力が揺らぐため、影響範囲の特定や「いつから事故が起きていたか」の遡及が極めて難しい。Microsoftが2016年に公開したチャットボットTayは、ユーザーからの誘導入力により16時間で差別的発言を学習し公開停止に至った[6]。第三に、ベンダー依存度の高さである。基盤モデルや埋め込みAPIを外部に依存する以上、自社CSIRTだけでは原因解析・封じ込めが完結しない。ENISAのAI Threat Landscape[7]はサプライチェーンリスクを最重要カテゴリの一つに位置付け、外部委託先との情報共有プロセスを事前合意しておくことを求めている。
プレイブック6フェーズ ── NIST SP 800-61のAI拡張
NIST SP 800-61 Rev.2は「Preparation／Detection & Analysis／Containment, Eradication & Recovery／Post-Incident Activity」の4フェーズを定義する[3]。AI事故ではこれを6フェーズ（検知・トリアージ・封じ込め・根絶・復旧・事後レビュー）に細分化することを推奨する。(1) 検知：プロンプト/出力ログ、ガードレール検知器、ユーザー報告窓口の3経路を確保する。NIST AI RMF[8]のMeasure機能に対応し、誤動作・ハルシネーションは「品質メトリクスの逸脱」として通知する仕組みが要る。(2) トリアージ：①情報漏えい型 ②誤動作・ハルシネーション型 ③モデル/プロンプト窃取型 ④可用性型の4分類で初期判定し、影響利用者数とデータ機微度で重大度（S1〜S4）を確定する。(3) 封じ込め：該当機能の即時停止、APIキー無効化、システムプロンプトの差替え、影響テナントの隔離。生成AI機能はトグルで停止できるよう設計しておくのが原則である。(4) 根絶：プロンプトインジェクションのトリガー除去、汚染された埋め込みインデックスの再構築、ファインチューニングモデルの差し戻し。(5) 復旧：段階的にトラフィックを戻し、出力監査ログの保全とKPI回復の二軸で監視する。(6) 事後レビュー：ATLASの戦術IDで攻撃シーケンスを言語化し、再発防止策をAI RMFのGovern機能に組み戻す。
AI事故類型別 対応手順の要点
プロンプトインジェクション（直接型・間接型）：間接型はRAGで参照した外部文書に攻撃指示が埋め込まれるパターンで、検知は出力側のポリシー違反シグナル（ツール乱用・外部送信）に頼ることになる。封じ込めは「ツール権限の縮退」「外部URL参照の停止」が第一手[5]。学習データ・プロンプト経由の漏えい：Samsung事案[1]のように、ユーザーが機密を貼り付けるパターンと、ベクターDBから機微情報が抽出されるパターンを分けて扱う。前者はDLPとプロンプト前処理、後者はテナント分離とアクセス制御の見直しで対応する。ハルシネーションによる損害：Air Canada事案[2]のように、AIの誤回答が「会社の表示」と評価され損害賠償の対象となるリスクがある。事故対応では「該当回答の保存」「同種クエリの全数特定」「個別ユーザーへの訂正通知」が必須。モデル盗用・抽出攻撃：ATLAS[4]のModel Stealing戦術に該当。レート制御、出力多様性の制限、APIアクセスログの異常検知で予防する。意図しないデータ収集型：Microsoft Copilot Recallは2024年6月、画面スクリーンショットの自動取得仕様がプライバシー懸念を呼び、提供方式の修正と一般提供延期に至った[9]。AI機能の有効化方式（オプトイン／オプトアウト）はインシデントの種にも防火壁にもなる。
ステークホルダー通知マトリクス
AI事故では通知すべき相手と粒度が従来型より広い。下表をひな形として整備し、重大度別に「通知必須／状況により／不要」を予め決めておく。
| ステークホルダー | S1（重大） | S2（高） | S3（中） | 主な通知内容 |
|---|---|---|---|---|
| 経営層・取締役会 | 2時間以内 | 当日中 | 週次報告 | 事業影響、公表方針、法的リスク |
| 個人情報保護委員会 | 速報3〜5日／確報30日[10] | 同左 | 不要 | 漏えい等報告（個情法施行規則） |
| 影響を受けた本人 | 個別通知必須[10] | 原則必須 | 状況により | 事案概要・取り得る対応策 |
| 取引先・委託元 | 当日中 | 翌営業日 | 定例報告 | 契約上の通知義務に従う |
| AIベンダー | 即時 | 即時 | 当日中 | 原因切り分け・パッチ要請 |
| 監督官庁（業法） | 業法基準 | 業法基準 | 不要 | 金融庁・厚労省等の業界別報告 |
| 報道・株主 | 事実確定後 | 判断 | 不要 | 適時開示・プレスリリース |
法令上の報告義務 ── 国内ベース
個人情報保護法は2022年4月の改正で、要配慮個人情報の漏えい・1,000人超の漏えい・財産的被害のおそれ・不正目的による漏えいに該当する場合、個人情報保護委員会への報告と本人通知を義務化した[10]。速報は「3〜5日以内」、確報は「30日以内（不正アクセス等は60日以内）」が原則である。AI事故は「ベクターDBから個人情報が抽出された」「LLMが他社事案の回答に第三者の個人情報を混入させた」など、従来型の枠で捉えにくい漏えいが起こりうるため、「漏えい等」の該当性判断フローを予めCISO・法務・DPOで合意しておく必要がある。経済産業省「サイバーセキュリティ経営ガイドライン Ver.3.0」[11]は重要10項目の一つに「インシデント発生時の緊急対応体制の整備」を挙げ、2023年改訂ではサプライチェーン・クラウド・AI利用拡大を踏まえた経営層責任を強調している。金融分野では金融庁監督指針、医療分野では医療情報システム安全管理ガイドライン、上場企業は東証の適時開示規則も並行して確認する。
チェックリスト ── プレイブック整備の最低ライン
- AI機能ごとに「停止トグル」と「責任者」が定義されているか（封じ込めの即応性）
- プロンプト・出力ログの保全期間が法令・ガイドラインを満たしているか（最低90日、推奨1年）
- 個人情報保護委員会への速報3〜5日／確報30日のテンプレートが用意されているか[10]
- ATLAS戦術IDに基づく事後レビューフォーマットが定型化されているか[4]
- ベンダー（基盤モデル提供者・RAG構築委託先）との情報共有SLAが契約に明記されているか[7]
打ち手 ── 90日で整備する3レイヤー
第1レイヤー（〜30日）は「最小限の止血キット」。AI機能の停止トグル実装、プロンプト/出力ログの一元保全、CSIRT招集フロー（Slack/電話/代替連絡）を整える。第2レイヤー（〜60日）は「プレイブック本体」。本記事の6フェーズと類型別手順をテンプレート化し、法務・広報・経営企画を巻き込んだ机上演習（Tabletop Exercise）を1回実施する。NIST SP 800-84[12]のテストガイドが参考になる。第3レイヤー（〜90日）は「外部接続」。基盤モデルベンダーへのエスカレーション窓口、保険会社・外部フォレンジック事業者との事前契約、個情委・所管官庁への通知テンプレートを整える。重要なのは「全部を同時に作らない」こと。停止トグル一つあるだけで、被害額は桁で変わる。
「インシデント対応の成熟度は、ペーパー上の手順書の厚さではなく、最初の60分で誰が何を止められるかで決まる」── NIST SP 800-61 Rev.2の運用解説より[3]。AI事故では、この60分のうち最初の10分を『止める』ことに費やせる組織が事業継続を握る。
結論
- AI事故はNIST 4フェーズでは粒度不足：検知・トリアージ・封じ込め・根絶・復旧・事後の6フェーズに細分化し、ATLAS戦術IDで言語化する。
- 類型別の止血手順を持て：プロンプトインジェクション／漏えい／ハルシネーション／モデル盗用の4類型で初動が異なる。
- 通知マトリクスと法令期限を埋め込め：個情委への速報3〜5日・確報30日[10]、経営層2時間以内、ベンダー即時を平時から定義する。
経営者視点 ── 公表タイミングと株主・取引先通知
AI事故の公表は、技術的な収束よりも「説明責任のタイミング」で決まる。Air Canada事案[2]では裁判所が「チャットボットは会社の一部であり、その表示に責任を負う」と認定した。つまり、AIの誤動作はもはや「ベンダー側の問題」では片付けられず、上場企業であれば適時開示・株主への説明、BtoB企業であれば取引先への契約通知の対象になる。経営判断のポイントは3点ある。第一に、事実が固まる前の「想定問答」着手。事故発生から24時間以内に広報・法務・IR・CISOで「現時点で言えること／確認中のこと／公表時期の目安」を文書化し、社外発信の温度感を揃える。第二に、被害規模が読めない段階での「経過開示」。確報を待つと先にメディアやSNSが動く。個情委も「不確定でも速報優先」を求めている[10]。第三に、取引先通知のタイミング。委託契約や情報セキュリティ覚書には「重大インシデント発生時の通知期限」が記載されているケースが多く、これを破ると契約解除や取引停止のリスクが顕在化する。経営層に必要なのは「AI事故は技術部門の問題」という認識を捨て、事業継続・レピュテーション・法的責任の三軸で意思決定する覚悟である。プレイブックは現場の手順書であると同時に、経営の意思決定を支えるアセットでもある。
参考文献
- Bloomberg「Samsung Bans Staff’s AI Use After Spotting ChatGPT Data Leak」(2023年5月2日)
- British Columbia Civil Resolution Tribunal「Moffatt v. Air Canada, 2024 BCCRT 149」(2024年2月14日)
- NIST SP 800-61 Rev.2「Computer Security Incident Handling Guide」(2012年8月)
- MITRE ATLAS（Adversarial Threat Landscape for Artificial-Intelligence Systems）公式サイト
- OWASP「Top 10 for Large Language Model Applications v1.1」(2023年10月)
- The Verge「Twitter taught Microsoft’s AI chatbot to be a racist asshole in less than a day」(2016年3月24日)
- ENISA「AI Threat Landscape Report」(2023年12月)
- NIST AI Risk Management Framework (AI RMF 1.0)（2023年1月）
- Microsoft「Update on the Recall preview feature for Copilot+ PCs」(2024年6月13日)
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」漏えい等報告・本人通知に関する対応 (2022年改正対応版)
- 経済産業省「サイバーセキュリティ経営ガイドライン Ver.3.0」(2023年3月改訂)
- NIST SP 800-84「Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities」(2006年9月)
- OWASP「AI Security and Privacy Guide」公式ドキュメント
- ISO/IEC 27035-1:2023「Information security incident management — Part 1: Principles and process」
- 総務省・経済産業省「AI事業者ガイドライン（第1.0版）」(2024年4月)
