インシデント対応:AI 起因の事故への備え

AI Navigate Original / 2026/5/16

共有:

要点

  • 漏洩・誤出力・暴走に備えた対応手順を用意する
  • 骨子は検知報告→初動→保全→範囲特定→連絡→再発防止
  • 停止手順と責任者を事前決定、責めない文化、段階展開
  • ガバナンス核は機密規則・インジェクション対策・保護・審査・対応

どれだけ気をつけても、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)と呼ばれる脆弱性を公表しました。これは、プロンプトインジェクションが「概念上の危険」から「実際にデータを盗み出した世界初の本番事例」へと変わった、節目となる事案です。

細工メール 指示を仕込む Copilot 命令と誤認 社内ファイル 外部サーバへ流出 利用者は「メールを開いて質問しただけ」——クリックすら不要(ゼロクリック)

FIG.1 EchoLeak の連鎖:細工メール → Copilot が命令と誤認 → 社内ファイル参照 → 外部へ流出

攻撃の流れはこうです。攻撃者は、ある M365 利用者あてに細工したメールを送ります。利用者が後で Copilot に「受信箱について」質問すると、Copilot はそのメール本文も文脈として読み込み、本文に仕込まれた指示を正規の命令と誤認します。その結果、利用者がアクセスできる社内文書を参照し、本文中の画像が自動で読み込まれる仕組み(クライアントの画像プリフェッチ)を悪用して、抜き取った情報を外部へ送り出してしまう——という連鎖でした。利用者はメールを開いて普通に質問しただけで、危険なリンクをクリックする必要すらありませんでした(いわゆるゼロクリック)。

この事例の本質は、攻撃が 「自然な文章」に化けて 信頼境界をすり抜けたこと。従来型のフィルタだけでは止めきれない。

Microsoft はこの脆弱性をサーバ側で修正し、実際の悪用は確認されなかったと発表しています。重要なのは、これが「特定製品の 1 つのバグ」にとどまらない点です。複数の社内データ源にアクセスできる AI アシスタント全般に共通する構造的なリスクを示しており、自社で AI を導入するときの設計チェックリストとして読むべき教訓を含んでいます。

この実例から引き出せる平時のチェックポイント

  • 外部から取り込むテキストは「信頼できない入力」として扱う。Web・メール・添付など、外から来た文章をそのまま AI への命令として通さない。
  • エージェントの「出力・送信系」アクションは承認 or 監査ログ必須にする。メール送信・外部 API 呼び出し・ファイル持ち出しは、たとえ「自分宛」「内部宛」に見えても無条件で許さない。
  • 外部画像や未署名 URL を既定でブロックする。本文中の画像読み込みが情報流出の経路になり得る。
  • 事前認証付きの共有リンク発行は権限とログでガードする。便利な機能ほど、悪用時の被害も大きい。

03事故が起きたときの対応手順 —— 6 つのステップ

いざ事故が起きたら、慌てて場当たり的に動くのが一番危険です。順番を決めておけば、当事者が動揺していても抜け漏れなく対処できます。下の 6 ステップを、自社の連絡先・責任者名まで埋めた「手順書」として用意しておきます。

01

検知・報告

気付いた人がためらわず報告できる窓口を一つに決める。「とりあえず報告」を歓迎する文化が、初動の速さを決める。

02

初動(被害拡大の停止)

連携の一時停止、API キーの失効、公開ページの取り下げなど、まず「これ以上広がらない」状態を作る。原因究明より先。

03

証拠の保全

ログ・チャット履歴・出力を消さずに保全する。「とりあえず消す」は厳禁。後の影響範囲特定と再発防止の土台になる。

04

影響範囲の特定

何の情報が・誰に・どこまで届いたかを、保全したログから逆算する。過小評価も過大報告も避け、事実で詰める。

05

連絡

社内の関係者へ、必要なら顧客・取引先・当局へ。誰がいつ何を伝えるかを事前に決めておく(次節の法的義務に注意)。

06

再発防止

原因を個人の責任で終わらせず、ルール・設計・チェック体制に反映する。手順書そのものも更新する。

この 6 ステップは、サイバーセキュリティの標準的なインシデント対応(NIST SP 800-61 など)の考え方を AI 向けに具体化したものです。特別に新しいことをするわけではなく、「止める → 残す → 調べる → 伝える → 直す」を順番どおりに回すのが核心です。

04「いつ・どこへ報告するか」は法令も関わる

影響が大きい事故では、社内対応だけで完結しないことがあります。とくに EU 向けにサービスを提供する場合、EU AI Act(AI 規則)の重大インシデント報告義務が関わってきます。ガイダンスの最終版は 2026 年 8 月 2 日から適用される見込みで、高リスク AI システムの提供者には、当局への報告に期限が課されます。

状況報告までの目安(EU AI Act ドラフトガイダンス)
重大インシデント(一般)把握してから 15 日以内
広範囲・特に深刻なもの2 日以内
死亡を伴うもの10 日以内

初回は不完全な報告でも提出し、後から詳細を補えるとされています。報告義務を怠った場合の制裁は重く、ドラフト段階では最大 1,500 万ユーロ、または全世界年間売上高の 3% のいずれか高い方とされています。これらの数値・期限・適用日はドラフト段階のものであり変動し得るため、実際に対象となるかも含め、必ず最新の公式情報と自社の法務で確認してください。日本国内向けの事業でも、個人情報保護法の漏えい報告など、別の枠組みで報告義務が生じる場合があります。

05平時の備え —— 事故対応力は「準備」で決まる

対応手順を書いた紙があっても、実際に火がついたときに動けなければ意味がありません。平時に仕込んでおく備えを、技術・運用・文化の三方向で整理します。

Kill Switch & Blast Radius

「すぐ止められる」を設計に組み込む

最大の防御は、事故が起きても数秒で止められること。AI 連携・エージェントには、最初から「停止スイッチ」と「被害が広がる範囲(ブラスト半径)の制御」を組み込んでおきます。下図のように、機能フラグを切れば即座に止まり、段階展開(カナリア)で一部にだけ先行公開しておけば、問題が出ても影響は最小で済みます。

機能フラグ ON(稼働中) OFF=数秒で全停止 段階展開(カナリア) まず一部 問題なければ拡大 被害範囲を 最小化

FIG.2 機能フラグ=即停止、段階展開=先行公開で影響を局所化

本番に影響する変更は段階展開・ロールバック前提で出す。「全部いったん止めて、前のバージョンに戻す」が数分で確実にできる状態を保っておけば、未知の問題に出くわしても時間を稼げます。

運用と文化の備え

  • 停止手順と責任者を事前に決める。「誰が止める権限を持つか」が曖昧だと、夜間や休日に誰も動けない。
  • 「責めない報告文化」をつくる。報告した人を罰すると隠蔽が生まれ、発見が遅れる。早く言えたことを評価する。
  • ログを最初から残す設計にする。誰が・何を入力し・何が返ったかを後から追えないと、影響範囲が永遠に分からない。
  • 年に数回、机上訓練をする。「もし顧客に誤出力が届いたら」を実際に通しでやってみると、手順書の穴が見える。
検知 停止 調査 連絡 再発防止 手順書へ 反映

FIG.3 検知 → 停止 → 調査 → 連絡 → 再発防止 → 手順書更新、と学びが一周する

06本章のまとめ —— ガバナンスの 5 本柱

このシリーズで見てきた AI ガバナンスは、突き詰めると次の 5 点に集約されます。インシデント対応は、その最後の安全網です。

  • 機密ルール:何を AI に入れてよいか/いけないかの線引き
  • インジェクション対策:外部入力を「信頼できない命令」として扱う設計
  • データ保護:権限・マスキング・ログによる情報の囲い込み
  • 審査体制:人による確認と承認のプロセス
  • インシデント対応:起きた後に被害を抑え、学びに変える仕組み

AI 活用のスピードは、安全網の整備とセットで初めて持続します。事故をゼロにはできなくても、「すぐ止められる・すぐ調べられる・隠さず学べる」状態を平時に作っておくことが、長く AI を味方につけ続けるための土台になります。