生成AIの誤送信や誤回答が起きたら、どこまで止めるか

生成AIのインシデントで初動を誤らないために、最初から全社の生成AIを止める必要はありません。まず「情報の送信」「誤った納品」「権限外操作」のどれが起きたかを分け、該当する会話、成果物、アカウントや連携機能から止めます。範囲が分からない、挙動が続いている、自社のリスク許容度を超える。このいずれかなら、停止範囲を上位へ広げます。

難しいのは、同じ「生成AIの事故」という呼び方でも、止める対象が違うことです。入力内容が許可されていない処理先へ送られた事象に、誤回答の訂正だけをしても足りません。反対に、納品済みの文書に誤りが見つかった事象で、関係のない社内利用まで止めれば、復旧の判断をかえって複雑にします。

では、局所停止のままでよいのはどこまでか。三類型の判断表と共通台帳を使い、現場の封じ込めと経営判断の境界を先に決めておくことが答えになります。

生成AIインシデントの初動は「何が外へ動いたか」で分ける

最初の報告が「AIが間違えた」だけでは、判断に必要な情報が足りません。動いたものを特定します。

• 情報の送信：情報が組織外、または許可されていない処理先へ送られた
• 誤った納品：生成物が顧客、取引先、または社内の後工程へ渡った
• 権限外操作：生成AIや連携機能が、承認範囲外の更新、送信、実行をした

この三分類は、NISTが定めた名称や法的区分ではありません。NIST AI RMF Coreが示す、影響、発生可能性、利用できる資源や手段に基づくリスク対応の優先付けと、意図しない結果を示すシステムの代替・切り離し・無効化という一般原則を、自社の初動へ落とすための実務上の提案です（2026年9月21日確認）。

分類によって、最初に止める対象を選びます。原因究明はその後も続けます。一つの事象が複数に該当するなら、無理に一つへ寄せず、各行を別々に判定します。情報を含む誤った成果物が外部へ渡り、その後に連携機能が更新を続けたなら、三つの行をすべて開きます。

初動判断表：局所停止から広げる条件

以下は、出典の一般原則を基に記事が提案する実務上の方法であり、原典所定の分類・義務ではありません。発見者が埋められない欄は空白にせず「未確定」とし、未確定であること自体を停止拡大の判断材料にします。

判断表では、製品単位よりも実際に情報・成果物・操作が通った経路に着目します。たとえば「誤った納品」で該当成果物と納品経路が特定でき、後続利用も止められているなら、まずそこを封じ込めます。原因調査のために記録を保全しつつ、関係のない利用は継続できます。どの成果物へ同じ出力が転用されたか分からない場合は、利用停止を関連工程へ広げます。

「情報の送信」では、出力の正誤より送信経路を見ます。該当会話だけか、共有リンクか、同じ連携を使う送信全体かを順に広げます。「権限外操作」では、画面上の回答と実際の更新・送信・実行を分け、後者とその後続処理を確認します。操作が続いている間は、調査完了を待たず、該当アカウントや連携機能を切り離す判断が先です。

この段階設計は、意図した用途と一致しない結果を示すAIシステムについて、別手段への代替、切り離し、無効化の仕組みと責任を用意するというNISTの考え方に沿います。また、NIST AI RMF PlaybookのManageは、悪影響や性能・信頼性上の問題への対応と記録、設定したリスク許容度を超えたシステムの廃止を提案しています（2026年9月21日確認）。ただし、どの段階で自社の許容度を超えるかは、経営側が決める事項です。

一枚の初動台帳で、事実と判断を混ぜない

口頭連絡だけでは、「何が起きたか」と「なぜ止めたか」が後から分かれなくなります。三類型で共通する台帳に、次の項目を残します。NIST AI RMF Playbookにあるインシデント記録やシステム変更記録の例と、生成AI向け対応計画の一般原則を基に組み立てた実務上の提案です。原典所定の様式や義務ではありません（2026年9月21日確認）。

• 検知した時点と検知経路
• 対象のシステム、モデル、連携機能
• 入力、出力、実行された内容
• 送信先または影響先
• 現在も継続しているか
• 取消、訂正、権限停止の実施状況
• 影響と深刻度の暫定評価
• 判断者、判断時点、判断理由
• 変更、試験、復旧の履歴

台帳では、確認済みの事実、未確定事項、実施した判断を欄で分けます。「影響なし」と「影響先を未確認」は同じではありません。停止を狭める場合も、広げる場合も、その時点で何が未確定だったかを残せば、次の判断者が結論だけを引き継がずに済みます。

復旧記録も初動の一部です。設定を戻した事実だけで完了にせず、変更理由、試験した内容、展開した内容を結び付けます。NISTのPlaybookは、エラーの特定方法、関連インシデント、修復の有無、影響を受けた関係者への修復の展開方法を記録例に挙げています（2026年9月21日確認）。

平時の入力ルールや承認ツールが曖昧なら、生成AIの社内ルール・利用ガイドラインの作り方【テンプレート付き】で利用前の線引きも整えてください。ただし、予防ルールの見直しと、発生後の停止判断は別の作業です。事故直後は、ルール全文の改定より先に、進行中の経路を止めて記録します。

経営判断へ上げる条件を、役職名より先に決める

現場が迷うのは、報告先が分からないからだけではありません。「どの状態なら経営判断が必要か」が決まっていないからです。次のいずれかに当たる場合は経営判断へ上げる、という条件を事前に置きます。これも出典の一般原則を基に記事が提案する実務上の方法で、NIST所定の分類・義務ではありません。

• 影響先、または権限外操作の範囲を確定できない
• 外部への訂正・連絡、契約や法令の確認が必要になる
• 停止範囲を広げると重要業務も止まる
• 手動代替を含む復旧方針を決める必要がある
• 自社が定めたリスク許容度を超える

この条件に役職名、連絡経路、代理判断者、手動の代替手段を結び付けます。経営者は技術調査の詳細を追う役割より、業務停止による影響と継続による影響を比較し、どちらを引き受けるか決める役割を担います。

NISTの生成AIプロファイルは、第三者の生成AI技術に関するインシデント対応計画について、影響との整合、関係者への周知、対応機能の責任者、定期的な演習、事後学習による改善、関連法令との整合確認を提案しています（2026年9月21日確認）。また、生成AI出力の妥当性・安全性のレビューと、異常や影響を検出した際にエラーの処理、復旧、修復ができる構成の検証も提案しています。この原則が支えるのは、責任者と代替手段を平時から決めることです。個別の法的判断そのものをNIST資料が代替するわけではありません。

対応条件を実際の運用へ載せるには、AI導入は何から始めるべきか｜中小企業の最初の90日で扱う社内ルール、対象業務、継続・停止条件の整理と接続できます。導入判断の表とインシデント台帳を別々に眠らせず、責任者と停止条件を共通にします。

全面停止の基準は、未確定範囲と挙動の継続性

局所停止にとどめる条件は、影響対象が特定でき、挙動が止まり、取消・訂正・権限停止の状態と下流利用を確認でき、責任者が復旧を判断できることです。反対に、範囲が確定しない、挙動が続く、または自社のリスク許容度を超えるなら、会話から送信経路へ、成果物から関連工程へ、アカウントから連携機能へと停止を広げます。重要業務まで止まる段階では、手動代替を含めて経営判断へ上げます。

生成AIインシデントの初動では、製品全体の全面停止を即断する前に、三類型の該当行を開き、六つの確認軸を埋め、未確定事項を台帳に残します。その結果から停止範囲を選びます。誤送信、誤った納品、権限外操作を分ければ、必要な経路を早く止め、復旧の条件を経営側へ渡せます。