どれだけ気をつけても、AI を業務に組み込めば事故はいつか起きます。機密情報をうっかり外部の AI に貼ってしまう、AI の誤った出力をそのまま顧客に出してしまう、自動化したエージェントが想定外の操作をしてしまう——。インシデント対応とは「事故ゼロ」を目指すことではなく、起きた後の被害を最小に抑え、同じことを繰り返さない仕組みを平時に用意しておくことです。この章では、AI 起因の事故にどう備え、起きたら何をどの順で動かすかを、実例とともに整理します。
Why It Matters
従来のシステム障害と違い、AI の事故は「正常に動いているのに間違える」「攻撃が自然な日本語の文章に化けて紛れ込む」といった、検知しづらい形で起こります。だからこそ、火事が起きてから消火器を探すのではなく、消火器の場所と避難経路を全員が知っている状態を先に作っておく必要があります。
01まず「どんな事故が起こりうるか」を具体で持つ
備えの第一歩は、抽象的な不安ではなく具体的なシナリオを手元に持つことです。AI 起因のインシデントは、大きく次の 4 つの型に整理できます。自社の業務に当てはめて「これは起きうる」と思えるものから対策します。
情報の入力漏れ
顧客名簿・契約書・ソースコードなどの機密を、社外の生成 AI にそのまま貼り付けてしまう。学習や保存に使われ得る前提で考える。
誤出力の流出
AI が事実と異なる回答（ハルシネーション）を生成し、人の確認を経ずに顧客向け文書や見積りに使われてしまう。
エージェントの暴走
メール送信・ファイル操作・外部 API 呼び出しを任せた自律エージェントが、誤った判断で実行してしまう。
プロンプトインジェクション
Web ページやメール本文に仕込まれた指示を AI が「命令」と誤認し、攻撃者の意図どおりに情報を持ち出してしまう。
この 4 つは独立ではなく、連鎖して大きな事故になるのが厄介な点です。次節の実例は、まさにこの連鎖が現実に起きたケースです。
02実例：EchoLeak —「メール 1 通」で社内データが抜ける
2025 年 6 月、セキュリティ企業 Aim Labs（Aim Security）が、Microsoft 365 Copilot に対する EchoLeak（CVE-2025-32711）と呼ばれる脆弱性を公表しました。これは、プロンプトインジェクションが「概念上の危険」から「実際にデータを盗み出した世界初の本番事例」へと変わった、節目となる事案です。
FIG.1 EchoLeak の連鎖：細工メール → Copilot が命令と誤認 → 社内ファイル参照 → 外部へ流出
攻撃の流れはこうです。攻撃者は、ある M365 利用者あてに細工したメールを送ります。利用者が後で Copilot に「受信箱について」質問すると、Copilot はそのメール本文も文脈として読み込み、本文に仕込まれた指示を正規の命令と誤認します。その結果、利用者がアクセスできる社内文書を参照し、本文中の画像が自動で読み込まれる仕組み（クライアントの画像プリフェッチ）を悪用して、抜き取った情報を外部へ送り出してしまう——という連鎖でした。利用者はメールを開いて普通に質問しただけで、危険なリンクをクリックする必要すらありませんでした（いわゆるゼロクリック）。
この事例の本質は、攻撃が 「自然な文章」に化けて 信頼境界をすり抜けたこと。従来型のフィルタだけでは止めきれない。
Microsoft はこの脆弱性をサーバ側で修正し、実際の悪用は確認されなかったと発表しています。重要なのは、これが「特定製品の 1 つのバグ」にとどまらない点です。複数の社内データ源にアクセスできる AI アシスタント全般に共通する構造的なリスクを示しており、自社で AI を導入するときの設計チェックリストとして読むべき教訓を含んでいます。
