生成AIを使っていて、入れてはいけない情報を入力してしまった、意図しない範囲に文書が公開された、エージェントが想定と違う操作を実行した──こうした事態に最初に気づくのは、セキュリティの専門担当ではなく、その場で作業していた本人であることがあります。この記事は、気づいた直後に何をするかだけに絞って整理します。扱うのは、止めること、事実を残すこと、連絡することの三つです。
フォレンジック（証跡の科学的な解析）の手法、CSIRT の設計、法令上の通知期限、法的な評価、侵害の確定、根本原因の断定は扱いません。いずれも初動の後で、権限と情報を持つ人が判断する領域です。攻撃の手口そのものはプロンプトインジェクション攻撃の実務リスク、平時の権限設計はAIエージェントの権限設計で扱っています。
1. 「異常」「事故」「インシデント」を早い段階で決めつけない
生成AIの画面で見慣れない挙動が出たとき、それが設定の誤りなのか報告すべき事象なのかは、その場では分かりません。NIST の SP 800-61 Rev.3 は、原因を問わず負の結果を伴う事象を adverse event（有害事象）と呼び、「有害なサイバーセキュリティ事象がインシデントの発生を示すかどうかの判断には、追加の分析が必要になることが多い」と述べています。異常については 「異常には無害な原因によるものも、悪意によるものもある」とも記しています。
インシデントとして宣言するかどうかについては、同文書が 「分析した活動の既知および推定される特徴にインシデント基準を当てはめ、既知の誤検知も考慮して、インシデントを宣言すべきかを判断する」と述べています。宣言は基準に照らした判断であり、気づいた人の直感で決まるものではありません。
気づいた人が行うのは、「異常に気づいた」という事実を伝えるところまでです。自分で打ち切ることも、重大だと断定することも避けてください。
2. 時刻・利用者・サービス・事象を一次窓口へ伝える
最初に連絡する相手は社内の一次窓口です。SP 800-61 Rev.3 は、法執行機関や規制当局への通知について 「Notify law enforcement agencies and regulatory bodies of incidents based on criteria in the incident response plan and management approval. Designated individuals should contact these parties...」（インシデント対応計画の基準と経営層の承認に基づいて、法執行機関や規制当局へ通知する。指定された個人がこれらの相手へ連絡すべきである）と述べています。外部への連絡は、計画で指定された人が基準と承認に基づいて行うものであり、気づいた本人が直接行う前提にはなっていません。
受け取る側の動きも同文書に示されています。第一報を受けた側が予備的なレビューを行い、重大度と対応に必要な緊急度を見積もり、必要に応じてインシデントごとの責任者を指名します。見積もりは気づいた人が単独で確定するものではなく、組織の基準と役割に沿って行われます。
第一報に入れる項目は、本記事では次の4つを最小構成として提案します。
- 気づいた時刻と、事象が起きたと思われる時刻（分かる範囲で構いません）
- 操作していた利用者と、その所属
- サービス名と、利用していた環境（社内契約か、個人の利用か）
- 見えたままの事象。原因や深刻度は書き添えない
3. 停止・切断・失効を、影響と可逆性で選ぶ
SP 800-61 Rev.3 は封じ込めについて 「封じ込めとは、インシデントの拡大を防ぐことを指す」と定義し、「ほとんどのインシデントは何らかの封じ込めを必要とする」と述べています。
一方で、広く止めるほど良いわけではありません。同文書は、迅速な復旧と徹底した調査の必要性を両立させて戦略を選ぶとし、「Every response strategy decision has trade-offs.」（あらゆる対応戦略の決定にはトレードオフがある）と記しています。封じ込め策には緊急・一時的・恒久という存続期間の違いも例示されています。
| 止める対象 | 主に抑えられること | 元に戻しやすさ |
|---|---|---|
| 業務ワークフローの一時停止 | 同じ誤りの再発生 | 戻しやすい |
| 共有リンク・共有範囲の停止 | 閲覧できる人の増加 | 戻しやすいが、既に見られた分は戻らない |
| 外部サービス連携（integration）の切断 | 他システムへの波及 | 再接続の手順が必要 |
| アクセストークン・APIキーの失効 | 第三者による継続利用 | 再発行が必要。関係のない業務も止まりうる |
| 利用者アカウントの停止 | 誤操作・不正利用の継続 | 業務への影響が大きい |
この5つの分類は本記事の実務整理です
SP 800-61 Rev.3 に「トークン失効」「連携切断」という語はありません。最も近い記述は、同文書が根絶（eradication）の例として挙げる 「disabling breached user accounts」（侵害された利用者アカウントの無効化）と、NIST AI 600-1 が停止・切り離しの手順に含める 「user access removal」（利用者アクセスの削除）です。
止める操作そのものは、あらかじめ権限を持つと決めた人が行います（節8）。気づいた人が独断で失効させると、無関係の業務まで止まることがあります。
4. 入出力・操作・設定・ログと時系列を残し、不用意に再実行しない
止める作業と並行して、後から確かめられる形を残します。SP 800-61 Rev.3 は 「インシデント中に起きた事象の順序と、各事象に関与した資産・資源を特定する」と述べています。時系列は、後続の評価の土台になります。
残す候補は、入力内容と出力、実行された操作、共有 URL と公開範囲、アカウントと権限、変更した設定、サービス側のログ、気づいた時刻を含む時系列です。この列挙は本記事の実務整理であり、SP 800-61 Rev.3 が項目を規定しているわけではありません。
確認のつもりで同じ指示を再実行することは避けてください。出力の上書き、履歴の増加、外部作用がある場合の影響拡大につながりうるためです。同文書も、痕跡を探す作業を省略したり表面的に行ったりすると規模を過小評価しかねないと述べています。
「消してはいけない」ではなく「不用意に触らない」
SP 800-61 Rev.3 は、正式な chain-of-custody（証拠保全の連鎖）の手続きが 「might not be performed for every incident」（すべてのインシデントで行われるとは限らない）としつつ、収集したデータは依然として証拠とみなされると述べ、証拠の収集・保持は 「in accordance with the organization's evidence preservation procedures and data retention policies」（組織の証拠保全手順とデータ保持方針に従って）行うとしています。本記事も「必ず保全せよ」とは書きません。判断は自社の手順に従ってください。
記録の扱いには制約もあります。同文書は、インシデント対応の記録について機密性と完全性を守り、権限を持つ者だけがアクセスできるようにすることを挙げています。また、共有すべきものとして挙げられているのは 「ログ分析の結果」であり、生ログをそのまま配って回すことではありません。総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」も、ログの記録・保存にあたって「事故等の原因究明、再発防止策の検討、損害賠償責任要件の立証上の重要性」を踏まえ、記録方法・頻度・保存期間を検討するとしています。
5. データ、相手、公開範囲、実行結果、継続中かを評価する
SP 800-61 Rev.3 は、リスク評価の要素の例として asset criticality（資産の重要度）、functional impact（業務機能への影響）、data impact（データへの影響）、stage of observed activity（観測された活動の段階）、threat actor characterization（脅威主体の特徴づけ）、recoverability（復旧可能性） の6つを挙げています。優先順位については 「範囲、想定される影響、時間的な切迫度、資源の空き状況に基づいて、対応の速さの優先度を決める」と述べています。
生成AIの事象では、次の5点に置き換えると評価しやすくなります。この置き換えは本記事の整理です。
| 見るところ | 具体的な問い | 近い評価要素 |
|---|---|---|
| データ | 何が入力・出力されたか。機密度はどの区分か | data impact |
| 相手 | 誰の目に触れたか。社内か、社外か | data impact |
| 公開範囲 | どこまで見える状態になり、いつからか | 対応する明文なし（本記事の整理） |
| 実行結果 | 実際に動いた操作はあるか。取り消せるか | functional impact / recoverability |
| 継続中か | いまも同じ状態が続いているか | stage of observed activity |
「継続中か」を飛ばさないことは、同文書が明示している論点です。痕跡の確認を怠ると 「組織が気づかないまま、他の対象で無期限に事象が続くことを許してしまう」と述べています。
なお同文書は、意思決定について 「プライバシー、業務、安全、評判、AI といった他の種類のリスクにも踏まえた判断とし、サイバーセキュリティのリスクだけを切り離して見ない」とも述べています。生成AIの事象は、セキュリティの枠だけでは評価しきれません。
6. 引き継ぐ──調整・復旧・振り返り
評価が進んだら関係者を巻き込みます。SP 800-61 Rev.3 は、組織の内外の適切な相手と調整すること、共有は供給者との契約を含む取り決めに沿うこと、重大な事象では経営層へ状況を更新することを挙げています。
外部サービスとして生成AIを使っている場合、提供者は調整先の一つです。NIST AI 600-1 は、第三者の生成AI技術に関する対応計画について、関係者へ計画を伝えること、対応機能の所在（ownership）を定めること、下流の関係者と連絡するための連絡窓口・連絡先・通知の書式を計画に含めることを挙げています。契約におけるインシデント通知やサポートの扱いも項目にありますが、これらは同文書が示す Suggested Action（推奨される行動）であり、義務規定ではありません。また、これらは高リスクと判断された第三者のデータまたはAIシステムを対象とする項目です（この限定は次節の切り戻しにも同じくかかります）。
通知の期限は、この記事では決められません。
SP 800-61 Rev.3 は、通知を 「組織の業種、所在地、顧客の所在地に関係する、現行の通知関連の法令に従って」行うとし、「Incident notification is an evolving topic, and new laws and regulations are being established frequently.」（インシデント通知は変化の途上にある主題であり、新しい法令が頻繁に整備されている）と述べています。何時間以内に誰へ届け出るかは、自社に適用される法令と契約に基づいて、権限を持つ人が判断する事項です。
代替手段で業務を戻す
止めた業務をどう回すかは、止める判断と同時に考える論点です。NIST AI 600-1 は、生成AIシステムの停止・切り離しの過程について、関係者へ 「reasons, workarounds, user access removal, alternative processes, contact information」（理由、回避策、利用者アクセスの削除、代替のプロセス、連絡先）を含めて伝える連絡計画を整備・維持することを挙げています。止めた事実だけを流すのではなく、「今日はどうやって業務を進めるか」まで含めて伝える、ということです。
同文書はまた、切り戻し（rollover）と代替（fallback）に関するリスクを試験・管理する方針と手順について、「rollover and fallback may include manual processing」（切り戻しや代替には手作業による処理が含まれうる）と認めたうえで整備することを挙げています。これも推奨される行動であり、代替手段を必ず用意せよという義務規定ではありません。あわせて、手作業に切り替えれば影響がなくなるわけでもありません。処理の速度、記録の粒度、担当者の負荷は変わります。
原因分析と振り返りへ渡す
原因を特定するのは、ここからです。SP 800-61 Rev.3 は分析の推奨事項として 「根底にある、あるいは組織的な根本原因を見つけるためにインシデントを分析する」を挙げています。初動の段階でこれを行おうとすると、断定が早まり、事実の収集が止まります。
区切りの成果物として、同文書は 「インシデントそのもの、実施した対応・復旧の行動、そして得られた教訓を記録した事後報告書を作成する」を挙げています。NIST AI 600-1 も、生成AIシステムのインシデントについて事後評価（after-action assessments）を行い、対応・復旧の手順が守られ、有効だったかを検証することを挙げています。
訓練は再発を防ぐ保証ではありません。 演習や振り返りは、計画の穴と連絡経路の詰まりを見つけるための手段です。実施したことをもって、同じ事象が起きないとは言えません。AI 600-1 は、報告された誤り、ヒヤリハット（near-misses）、負の影響を記録・追跡する方針と手順を整えることも挙げています。事故に至らなかった事例こそ、次の設計材料になります。
7. 4つの場面で、初動はどう変わるか
以下は、初動の違いを説明するための仮想例です。発生の頻度や、これで場面を網羅していることを示すものではありません。
| 場面と最初に確かめること | 止める候補 | 残すもの | 引き継ぐ相手 |
|---|---|---|---|
| 機密情報を入力した ／何を、どの環境へ | 会話・履歴の共有停止、保存や学習に関する設定の確認 | 入力した内容の控え、時刻、利用者、画面 | 情報管理の担当、必要に応じて法務 |
| 意図しない範囲へ公開した ／どの URL がいつから誰に | 共有リンクの停止、公開範囲の縮小 | 公開 URL、公開していた期間、アクセス記録の有無 | 業務オーナー、広報、法務 |
| 想定外の操作が実行された ／何が実行され取り消せるか | 該当ワークフローの停止、連携の切断、トークンの失効 | 実行の記録、与えた指示、対象データの変更前後 | システム管理、業務オーナー |
| インジェクションの疑い ／どの外部資料を読ませたか | 当該資料の利用停止、外部取得の停止 | 読み込ませた資料、出力、実行された操作 | セキュリティ担当、サービス提供者 |
表の「引き継ぐ相手」は、社内で情報を渡す先です。 提供者を含む社外への連絡は、節2 のとおり計画上の基準と承認を経て、指定された人が行います。気づいた人が直接連絡する前提ではありません。
4つ目については、NIST AI 600-1 が、指示を直接入力する型と、取得されるデータに指示を仕込む型を区別しています（手口そのものはプロンプトインジェクション攻撃の実務リスクで扱っています）。いずれの場面でも、この段階で「攻撃を受けた」と確定させる必要はありません。 確定は、事実がそろってから権限を持つ人が行います。
8. チェックリストとまとめ
役割と連絡経路を事前に決めておくと、初動を進めやすくなります。使い始める前に、次の3つだけは決めておいてください。
- 一次窓口を誰にし、どの手段で届けるか
- サービスと連携を止める権限を持つのは誰か
- 事実を残す担当と、その保存先はどこか
3つとも空欄のまま運用しているなら、そこが最初の作業です。小さな会社のAI利用ルールの作り方で扱った A4 一枚の枠に、この3つを書き足す形でも構いません。
発覚後の順序は、本記事では次のように整理しました。これは読者向けの再構成であり、NIST が定めた固定の手順ではありません。
- 決めつけずに、気づいた事実を記録する
- 一次窓口へ第一報を入れる
- 影響と可逆性で、止める範囲を選ぶ
- 事実を残し、不用意に再実行しない
- データ、相手、公開範囲、実行結果、継続中かを評価する
- 提供者と社内の関係部門へ調整する
- 代替手段で業務を戻す
- 原因分析と振り返りへ引き継ぐ
この並びをそのまま使う必要もありません。SP 800-61 Rev.3 は、各計画を 「組織固有の要件、任務、規模、構造、機能に基づいて」作ることを挙げています。人数の少ない会社では、一次窓口と停止権限が同一人物になることもあります。兼務する場合は、権限が一人に集中することと、不在時の代理をどう置くかを自社の事情に応じて確認してください。
同文書は冒頭で 「インシデント対応はサイバーセキュリティのリスク管理の重要な一部であり、組織の業務全体にわたって統合されるべきである」と述べています。生成AIの事象も同じです。止める・残す・連絡するの三つを、AIの担当者だけの話にせず、業務の側の手順として置いてください。そして初動でやらないこと──侵害の確定、法的な評価、根本原因の断定──を、あらかじめ決めておくことが、結果的に時間を確保しやすくなります。
引用元・参考文献
- NIST『Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile』（NIST SP 800-61 Rev. 3、2025年4月／確認日：2026年8月15日）：有害事象とインシデントの区別、宣言基準、封じ込めと根絶、証拠の取り扱い、影響評価、調整と通知、復旧、事後報告・演習：原文
- NIST『Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile』（NIST AI 600-1、2024年7月26日／確認日：2026年8月15日）：第三者の生成AIに関する対応計画、停止・切り離し時の連絡、切り戻しと代替、事後評価、ヒヤリハットの記録、プロンプトインジェクションの区別：原文
- 総務省・経済産業省『AI事業者ガイドライン（第1.2版）』（令和8年3月31日／確認日：2026年8月15日）：ログの記録・保存にあたって考慮する事項：原文
NIST AI 600-1 の各項目は "Suggested Action"（推奨される行動）であり、義務ではありません。SP 800-61 Rev. 3 は CSF 2.0 のコミュニティプロファイルであり、認証規格でも法的なセーフハーバーでもありません。本記事は上記資料を確認日（2026年8月15日）時点で参照しています。