生成AI事故対応の机上演習｜誤回答・情報漏えい・誤実行を90分で検証する

生成AIから機密情報が漏れた疑いがあるとき、誰が利用を止め、誰が影響を調べるのでしょうか。訓練では、こうした判断を机上で一度たどります。CISAの演習資料にある役割分担を参考に、生成AIを対象とした90分の進行例を示します。

米CISAの演習資料は、担当者の役割を分けている

“roles and responsibilities for exercise planners, facilitators / evaluators, and participants”

CISAの原文は、計画者、進行・評価担当、参加者の役割を分けています。続く自社図は役割表ではなく、初報、追加情報、対外説明、再開、振り返りを90分で進める例です。

生成AIの机上訓練では、何を練習しますか？

検知、一次連絡、利用停止、影響確認、対外判断、再開の責任分担を練習します。

CISAのTabletop Exercise Packageが示す計画者、進行役、参加者の役割分担を参照し、生成AI固有の事象へ置き換えます。

生成AI事故の机上演習は、どんな手順で進めますか？

役割を集め、入口を一つに絞り、90分を検知から復旧まで進め、詰まった手順を改善台帳へ移します。

進行記録は、追加情報を示した時刻、確認できた事実、未確認の項目、停止範囲、判断者、再開前の試験を別欄にします。47件と12件は架空の演習値のまま扱い、実際の事故件数として記録しません。

1. 参加者を、事故時の役割で集めます。担当者だけでも、経営だけでも、演習は止まります。役割の一覧は、比較表にまとめます。ENISAの2026年版手引きも、演習目的に合う役割と関係者を参加させる考え方を示しています[4]。
2. 事故の入口を一つに絞ります。三つを同時に投げると、混乱だけが残ります。最初の90分は一つに絞り、途中で新しい情報を小分けに提示します。CISAのCTEPには、演習計画、進行役、参加者の振り返り、事後報告のひな型が用意されています[6]。
3. 90分を、検知、封じ込め、説明、復旧の順で進めます。以下は、編集部による進行案です。各段階の判断と振り返りまでを、一つの枠に収めます。
4. 点数をつけず、詰まった箇所を改善台帳へ移します。見るのは知識量ではなく、どの情報を根拠に誰が判断したかという記録です。
5. 責任者と期限を決め、手順を直した後に再演します。同じ論点を、別の想定で再演します。

手順3の90分は、次のとおり進めます。

• 0〜20分：初報を受け、対応開始の判断者と記録の取得先を確認する。
• 20〜40分：追加情報から影響を調べ、利用停止の範囲を決める。
• 40〜60分：未確認事項を分け、顧客・経営への説明案を作る。
• 60〜75分：再開前の試験、承認者、監視方法を決める。
• 75〜90分：詰まった手順を振り返り、改善担当者と期限を決める。

開始時に示すのは、「顧客から、AIが引用した資料が見つからないと連絡があった」という一報だけです。参加者は、誰が事故対応を開始し、出力と送信履歴をどこから取るかを答えます。

正解を当てる試験ではありません。現在の手順で、必要な事実へ辿り着けるかを見る時間です。

20分後に、「同じ指示文のひな型を使った回答が47件あり、うち12件が外部送信済み」と追加します。ここでは、利用停止の範囲を決めます。AI機能を全面停止するのか、該当ひな型だけを止めるのか、顧客対応を人手へ切り替えるのかです。停止の判断者と実行者が別なら、連絡が届くまでの時間も記録します。

次に、「入力文書へ個人情報が含まれ、提供事業者の記録への保存可否が未確認」と伝えます。個人情報、契約、セキュリティの担当が、何を確認しないと報告要否を決められないかを挙げます。

最後に、再開条件を決めます。指示文を直した、という説明だけでは足りません。誤答を再現する試験、送信前確認、影響を受けた47件の再確認、再発監視が必要です。

演習後は、参加者の発言を点数化するより、詰まった箇所を改善台帳へ移します。たとえば、次のような詰まりです。

• 最初の報告先が分からなかった。
• AI提供事業者側の記録保持期間が分からなかった。
• 送信済み顧客を一覧にできなかった。
• 停止権限が個人アカウントにしかなかった。

どれも計画の穴です。NIST SP 800-84は、机上演習を、計画が緊急時に実行可能か確かめる討議型の手段と位置づけます[2]。

評価表には、事故対応開始までの時間、影響対象を数えられたか、停止判断者へ届いたかを残します。対外文へ未確認事項を混ぜなかったか、改善項目に責任者と期限が付いたかも確認します。

生成AI事故の机上演習で、うまくいかない例にはどんなものがありますか？

三つの事故を同時に投げる、役割がそろわない、改善が意識の話で終わる、防御機能の証明と考える、が典型です。

• 三つの事故を同時に投げる。混乱だけが残ります。
• 担当者だけ、または経営だけで集まる。担当者だけを集めても、停止承認や顧客説明の判断で演習が止まります。経営だけでは、どの記録を見れば事実が分かるかを試せません。
• 改善項目を「意識を高める」で終わらせる。変更へ落とします。次のような例です。AI回答の送信履歴を顧客IDで検索できるようにする。提供事業者との契約と保存設定の責任者を決める。緊急停止手順を運用担当以外にも渡す。
• 再開条件を「指示文を直した」だけにする。誤答の再現試験や再発監視が抜けます。
• 机上演習を、防御機能が動く証明と考える。机上演習は事故対応計画を検証します。防御機能そのものが動くかは証明しません[7]。記録が取得できるか、権限を実際に止められるか、バックアップから戻せるかは、別の技術訓練で確かめます。
• 答えを知っている参加者で、夜間の対応を想定する。夜間や担当者不在時に、同じ速度で動けるとは限りません。
• 初回から、実在顧客の情報を使う。初回は、架空の案件と模擬記録で行います。
• 海外機関の定義を、日本の判断として使う。海外機関の定義・手順は、日本の報告義務や契約上の判断を置き換えません。公開前に、自社の契約、個人情報、事故報告の要件へ戻って確認してください。

90分が終わっても、研修は完了しません。見つかった穴が閉じたときに終わります。

演習の参加者は、それぞれ何を担いますか？

業務、AI運用、セキュリティ、法務、広報、最終責任者の6つの役割が、それぞれ別の判断を持ち寄ります。

次の一歩は何から始めればよいですか？

誤回答、情報漏えい、誤実行のうち一つを選び、架空の案件で90分の演習を1回行うことから始めます。

1. 事故の入口を一つ選び、架空の案件と模擬記録を用意します。
2. 6つの役割の参加者を決め、90分の枠を取ります。
3. 演習後に改善台帳をつくり、責任者と期限を決めます。

演習の設計や進行は、TechWorkerが一緒に整理します。ご相談ください。

出典と確認範囲

資料確認日：2026年10月6日。本文中の手順例は編集部の提案で、導入効果の実測値ではありません。