生成AIのインシデント対応ガイド2026｜誤出力・情報漏えいが起きた後にやること

生成AIの導入では、ハルシネーション対策やセキュリティ審査といった「予防」に多くの労力が注がれます。それは正しいことです。しかし予防だけでは、片手落ちです。どれだけ備えても、生成AIは必ず事故を起こします。

問題は「起こすかどうか」ではありません。「起きた時に、何分で気づき、何をするか」です。ここが決まっていないと、小さな誤りが大きな信頼喪失に育ちます。本記事は、予防をすり抜けた事故が起きた後の話です。

結論を先に言います。生成AIのインシデント対応は、技術の問題ではなく段取りの問題です。事前に手順と連絡先を決めておくだけで、被害の大きさは桁で変わります。

生成AIのインシデントは、従来の障害と違う

サーバーが落ちる、データベースが壊れる。こうした従来の障害は、症状がはっきりしています。動いているか、止まっているか。切り分けは比較的やさしいものでした。

生成AIの事故は、そうはいきません。システムは正常に動いたまま、中身だけが間違っているのが厄介なところです。エラーは出ません。誰も止まったとは思いません。もっともらしい文章が、静かに間違ったまま外へ出ていきます。

典型的なものを挙げます。事実と異なる情報を顧客向けの回答として公開してしまう。プロンプトに含まれた個人情報が、外部のモデルに送られる。生成された文章や画像が、他者の権利を侵している疑いがある。差別的・不適切な出力が表に出る。そして、自動で動くエージェントが、意図しない操作を実行してしまう。

共通するのは、気づくのが遅れるという一点です。だからこそ、対応の設計がものを言います。

対応の全体像：6つのステップ

慌てている最中に手順を考えることはできません。平時に、次の6段階を紙に書いておきます。

1. 検知：おかしいと気づく

最初の関門は、事故に気づくことです。多くのインシデントは、社内の監視ではなく、顧客やSNSからの指摘で発覚します。それでは遅すぎます。利用者が「この回答は変だ」と一言で報告できる導線を、AIの画面のすぐそばに置いてください。報告のしやすさが、初動の速さを決めます。

2. 初動：まず広げないことを最優先する

原因究明は後回しで構いません。初動でやるべきは、被害を今より広げないことだけです。問題の機能を一時的に止める。誤った回答が載っているページを非公開にする。この判断を、現場が上長の許可を待たずに実行できるようにしておきます。止める権限を現場に渡しておくことが、初動を速くします。

3. 影響範囲の特定：どこまで届いたか

次に、事故がどこまで広がったかを調べます。誰の目に触れたか、どのデータが外へ出たかを、記録から追います。ここで効いてくるのが、平時のログです。いつ・誰が・どんな入力をして・どんな出力が返ったかを残していなければ、この段階で手が止まります。ログは、事故が起きて初めて価値がわかる保険です。

4. 封じ込め：根本を断つ

一時停止は応急処置です。原因を特定し、同じ事故が再び起きない状態にします。プロンプトの設計が悪いのか、参照データが古いのか、権限を渡しすぎていたのか。再発の芽を残したまま機能を再開しないことが肝心です。

5. 復旧と開示：外にどう伝えるか

個人情報の漏えいや、外部への誤情報の公開をともなう場合、社内で収める話ではなくなります。誰に、いつ、何を伝えるかを決めます。法令上の報告義務があるケースもあります。隠す方向に傾いた瞬間、事故は組織の信頼問題へと質を変えます。事実を早く、正確に伝える方が、長い目で見て傷は浅く済みます。

6. 事後：同じ轍を踏まない

収束したら、必ず振り返りを残します。犯人探しではありません。「仕組みのどこに穴があったか」だけを書きます。人を責める記録にすると、次から誰も正直に報告しなくなり、検知が遅れます。事後の目的は、次の検知を速くすることです。

事前に決めておくべきこと

いざという時に動けるかは、平時の準備で決まります。最低限、次の4つを紙にしておいてください。

深刻度の区分。すべての事故を同じ重さで扱うと、現場が疲弊します。「社外に影響が出たか」「個人情報や権利がからむか」で、対応の段階を分けておきます。軽いものは現場で、重いものは経営を巻き込む、という線引きです。

連絡体制。深夜に重大な漏えいが起きた時、誰に連絡すればよいか。技術・法務・広報の担当と、その連絡先を一枚にまとめておきます。探している時間が、被害を広げます。

止める権限。「機能を止めてよい」と誰が判断できるのかを、あらかじめ決めます。ここが曖昧だと、止めるべき場面で誰も引き金を引けません。

記録の置き場所。入出力ログをどこに、どれだけの期間残すか。個人情報の扱いと両立させながら、追跡に足るだけの記録を確保します。

生成AIならではの難所

従来の障害対応の経験があっても、つまずく点が3つあります。

再現しない。同じ入力でも、生成AIは毎回まったく同じ答えを返すとは限りません。「さっきの誤答をもう一度出して原因を見る」が、そもそも難しいのです。だからこそ、事故そのものの記録を、その場で残しておく必要があります。

原因を追いにくい。なぜその出力になったのかを、内部から完全に説明することはできません。原因の特定は「モデルの気持ちを読む」ことではなく、入力・参照データ・権限という外側の条件から絞り込む作業になります。

外部モデルに依存している。多くの場合、AIの本体は自社の外にあります。提供元の仕様変更や不具合が、こちらの事故として表面化することもあります。自社で制御できる範囲と、できない範囲を分けて考える視点が要ります。

よくある失敗

予防にだけ投資して、対応を用意しない。「事故は起こさない」という前提で設計すると、いざ起きた時に手順がなく、初動で数時間を失います。予防と対応は、両輪です。

止める判断を上に上げすぎる。止めてよいかの判断を経営に委ねる設計だと、承認を待つ間に被害が広がります。止める方向の判断は、現場に前倒しで渡すのが鉄則です。再開の判断こそ慎重に上げればよいのです。

ログを取っていない。プライバシーを気にするあまり入出力を一切残さないと、事故の影響範囲がまったく追えません。残す範囲と期間を設計する話であって、ゼロか全部かの話ではありません。

隠そうとする。小さく見せようとした対応が、後から最大の火種になります。事実を早く出すことが、結局いちばん傷を浅くします。

まとめ

生成AIのインシデントは、なくせません。もっともらしく間違えることが、この技術の本質だからです。予防で発生率は下げられても、ゼロにはできません。

ならば、勝ち筋は事故が起きた後にあります。速く気づき、まず広げず、正確に伝え、仕組みを直す。この段取りを平時に紙で持っているかどうかが、被害の大きさを分けます。

まずは自社のAIについて、「今、誤った出力が外に出たら、誰が何分で気づき、誰が止められるか」を書き出してみてください。答えに詰まる場所が、そのまま次に手を打つべき場所です。

なお、報告義務の要否や具体的な対応製品の仕様は、変化の速い領域です。法令上の判断や製品の機能は、必ず専門家と提供元の公式情報で確認してください。本記事で示したのは、道具が変わっても残る対応の骨格です。