はじめに——「予防」は完璧だった。それでもインシデントは起きる
AIの利用ガイドラインを作った。社内研修もやった。プロンプトインジェクション対策もした。——それでも、AIインシデントは起きます。
「社員がChatGPTに顧客の個人情報を入力してしまった」「AI搭載のカスタマーサポートが誤った解約手順を案内し、顧客が損害を被った」「社外向けAIチャットボットがプロンプトインジェクション攻撃を受け、内部情報を回答してしまった」——これらは架空の話ではなく、すでに世界各地の企業で実際に発生しているタイプのインシデントです。
問題は、多くの企業が「予防」には投資しているが、「起きてしまった後の初動対応」を準備できていないことです。インシデントの被害を最小化するのは、予防策ではなく、発覚後30分〜24時間の初動対応の質です。
この記事は、当サイトの「AIリスク管理3部作」の締めくくりとして、AIインシデントが発生した瞬間に何をすべきかを、分類・初動対応・報告・再発防止まで体系的にまとめた実務ガイドです。
この記事の位置づけ——AIリスク管理3部作:
- 第1部:AI導入の稟議・承認フロー(予防的ガバナンスの構築)
- 第2部:AI運用トラブル対応ガイド(日常運用のリスク管理)
- 第3部(本記事):AIインシデント対応計画(起きた後の初動対応と復旧)
この記事はこんな方に向けて書いています:
- 自社でAIを業務利用しており、インシデント対応計画が未整備の管理職・経営者
- 情報システム部門でAI関連のセキュリティを担当している方
- 社内のAIガイドラインに「インシデント対応」の章を追加したい方
- 取引先からAIリスク管理体制について質問を受けている方
- 万が一に備え、報告書テンプレートや対応フローを準備しておきたい方
AIインシデントの3分類——何が起きたかで初動が変わる
AIインシデントと一口に言っても、その性質によって対応の優先順位や関係者が大きく異なります。まず、3つのタイプに分類して理解しましょう。
分類一覧
| 分類 | 典型的なシナリオ | 主な原因 | 影響範囲 | 緊急度 |
|---|---|---|---|---|
| Type A:情報漏洩型 | 社員がAIに顧客の個人情報・社内機密を入力 / AIチャットの会話履歴が第三者に閲覧可能に | 人的ミス、設定不備、AI提供元のバグ | 顧客・取引先・法的(個人情報保護法) | 🔴 最高 |
| Type B:誤情報拡散型 | AIが誤った回答を生成し、それを根拠に顧客対応・社外文書を作成 / AI搭載サービスが事実と異なる情報を回答 | ハルシネーション、検証不足、プロンプト設計の不備 | 顧客・ブランド信頼・場合により法的 | 🟡 高 |
| Type C:外部攻撃型 | プロンプトインジェクションでAIの挙動が操作される / AIシステムを経由した不正アクセス | セキュリティ対策不足、脆弱性 | システム全体・顧客データ・事業継続 | 🔴 最高 |
Type A:情報漏洩型の具体例
シナリオ1(人的ミス):営業担当が、取引先との契約交渉メールをChatGPTに貼り付けて要約を依頼。メール内に取引先の未公開の経営情報、担当者の個人メールアドレスが含まれていた。
シナリオ2(設定不備):社内向けAIチャットボットのアクセス権限が正しく設定されておらず、一般社員が経営会議の議事録データにアクセスしてAIに質問できる状態だった。
シナリオ3(サービス提供元の問題):利用しているAIサービスにバグが発生し、自社のチャット履歴が他のユーザーから閲覧可能な状態になった(2023年のChatGPT事例と同型)。
Type B:誤情報拡散型の具体例
シナリオ4:カスタマーサポートがAIの回答を検証せずにそのまま顧客に送信。AIが生成した「解約手数料は無料」という誤情報により、顧客が損害を受けたとしてクレーム→損害賠償請求に発展。
シナリオ5:AIが生成したプレスリリースの草案に、競合他社に関する事実と異なる記述が含まれていた。そのまま配信され、競合企業から抗議を受ける。
Type C:外部攻撃型の具体例
シナリオ6:自社Webサイトに設置したAIチャットボットがプロンプトインジェクション攻撃を受け、システムプロンプト(内部命令)や内部データの一部を攻撃者に回答してしまった。
シナリオ7:AIが参照する外部データ(商品レビュー等)に悪意のある命令が埋め込まれており、AIがその命令に従って顧客情報を外部に送信した(間接プロンプトインジェクション)。
最初の30分でやること——初動対応フロー
インシデント発生直後の30分は、被害の拡大を防ぐために最も重要な時間帯です。考える前に、まず止める。
共通の初動対応(全タイプ共通)
【0〜5分】 止める
| # | アクション | 具体的な内容 |
|---|---|---|
| 1 | 問題のAI利用を即時停止 | 該当のAIツール・チャットボット・API連携を停止。「原因特定中」ではなく「まず止める」 |
| 2 | 証拠を保全 | チャット履歴・ログ・スクリーンショットを保存。削除しない。後の調査と報告に必須 |
| 3 | インシデント責任者に連絡 | 事前に決めた「AIインシデント対応責任者」に即連絡。決まっていなければ情報セキュリティ担当→上長の順 |
【5〜15分】 把握する
| # | アクション | 具体的な内容 |
|---|---|---|
| 4 | インシデントのタイプを特定 | Type A(情報漏洩)/ Type B(誤情報拡散)/ Type C(外部攻撃)のどれか。複合の場合もある |
| 5 | 影響範囲の初期評価 | 漏洩した情報の種類と量、影響を受けた人数、社外への拡散の有無を概算 |
| 6 | 現在も進行中かどうかを確認 | 漏洩・攻撃が「進行中」か「すでに終了」かで対応の緊急度が変わる |
【15〜30分】 エスカレーションする
| # | アクション | 具体的な内容 |
|---|---|---|
| 7 | 経営層への第一報 | 「何が起きたか」「現時点の影響範囲」「止めた措置」の3点を簡潔に報告 |
| 8 | 法務・コンプライアンス部門への連絡 | 個人情報漏洩の場合、個人情報保護委員会への報告義務(72時間以内)の判断が必要 |
| 9 | 対応チームの招集 | IT / 法務 / 広報 / 事業部門の担当者を集め、対応方針を決定 |
タイプ別の追加対応
| タイプ | 追加で必要な初動対応 |
|---|---|
| Type A(情報漏洩) | 漏洩した情報の特定と一覧化 / AI提供元への削除要請 / 個人情報保護法の報告義務の判断 / 該当する顧客・取引先への通知準備 |
| Type B(誤情報拡散) | 誤情報の特定と正しい情報の確認 / 誤情報が送信された相手の特定 / 訂正連絡の準備 / 誤情報に基づく意思決定がなされていないか確認 |
| Type C(外部攻撃) | 攻撃経路の特定とブロック / AI以外のシステムへの波及確認 / 必要に応じてCSIRT・外部セキュリティベンダーへの連絡 / 攻撃の証拠保全(フォレンジック) |
24時間以内にやること——被害確定と関係者対応
初動対応で出血を止めた後、24時間以内に以下を進めます。
被害の確定と影響評価
| 確認項目 | 確認内容 | 確認方法 |
|---|---|---|
| 漏洩 / 影響を受けた情報の特定 | 具体的にどの情報が漏洩・誤送信されたかをリスト化 | AIの入出力ログ、チャット履歴、APIログの調査 |
| 影響を受けた人数 | 個人情報漏洩の場合、該当者数の確定 | 入力されたデータの分析 |
| 社外への拡散状況 | 漏洩情報が社外に流出したか、SNS等で拡散されていないか | ネットモニタリング、AI提供元への確認 |
| 二次被害の有無 | 漏洩情報を使った不正利用の兆候がないか | 該当システムのアクセスログ確認 |
| 法的報告義務の判断 | 個人情報保護法に基づく報告義務(速報:3〜5日以内 / 確報:30日以内)の該当有無 | 法務部門・外部弁護士と協議 |
個人情報保護法に基づく報告の要否判断
2022年改正個人情報保護法により、一定の要件に該当する個人データの漏洩等が発生した場合、個人情報保護委員会への報告と本人への通知が義務づけられています。
報告義務が発生するケース:
- 要配慮個人情報(健康情報・信条等)が含まれる漏洩
- 不正アクセスによる漏洩のおそれ
- 財産的被害のおそれがある漏洩
- 1,000人を超える本人のデータに関わる漏洩
報告の期限:速報は事態を知った日から3〜5日以内、確報(詳細な調査結果)は30日以内(不正アクセスの場合は60日以内)です。
AIインシデントの場合、「AIサービスに入力した個人情報がAI提供元のサーバーに保存された」こと自体が漏洩に該当するかどうかの判断は、利用規約やデータ処理契約の内容によります。法務部門または外部弁護士と速やかに協議してください。
報告テンプレート集——そのまま使える実務文書
インシデント発生時に一から文書を作成している時間はありません。以下のテンプレートを事前に準備し、空欄を埋めるだけで使える状態にしておきましょう。
テンプレート①:社内第一報(経営層向け)
件名:【緊急】AIインシデント発生報告(第一報)
■ 発生日時:20XX年XX月XX日 XX:XX
■ 報告者:【氏名・部署】
■ インシデント分類:Type A(情報漏洩)/ Type B(誤情報拡散)/ Type C(外部攻撃)
■ 事象の概要:
【何が起きたかを3行以内で簡潔に記載】
例:「営業部のXXが、取引先A社との契約交渉に関するメール全文をChatGPTに入力し要約を依頼。メール内に含まれていたA社の未公開の業績情報および担当者2名の個人メールアドレスがAIサービスに送信された。」
■ 現時点の影響範囲(推定):
- 漏洩した情報の種類:【例:取引先の未公開経営情報、個人メールアドレス2件】
- 影響を受ける人数:【例:2名(取引先担当者)】
- 社外への拡散:【例:現時点では確認されていない / 確認中】
■ 実施済みの対応:
1. 該当社員のChatGPT利用を即時停止
2. チャット履歴のスクリーンショットを保全
3. AI提供元のデータ削除ポリシーを確認中
■ 今後の対応方針:
1. 【XX時まで】影響範囲の確定調査
2. 【XX時まで】法務部門と報告義務の判断
3. 【XX時まで】取引先への連絡要否の判断
■ 次回報告予定:本日XX:XX(第二報)
テンプレート②:取引先・顧客への報告文(情報漏洩型)
件名:弊社におけるAIツール利用に関する情報管理についてのお詫びとご報告
XX株式会社
XX部 XX様
平素より大変お世話になっております。
株式会社〇〇の△△でございます。
このたび、弊社社員が業務効率化のためにAIツールを利用した際、
XX様に関する以下の情報を意図せずAIサービスに入力してしまったことが判明いたしました。
深くお詫び申し上げます。
■ 入力された情報:
【具体的に記載。例:XX様のメールアドレス、および20XX年XX月XX日付の打ち合わせ内容の一部】
■ 発生日時:20XX年XX月XX日
■ 現時点の状況:
- 該当のAIサービスにおいて、入力されたデータの削除手続きを完了しております
- 当該データがAIの学習に使用されない設定であることを確認しております
- 現時点で、第三者への情報流出は確認されておりません
■ 原因:
弊社のAI利用ガイドラインに対する当該社員の理解不足により、
機密情報を含むデータがAIツールに入力されました。
■ 再発防止策:
1. 全社員へのAI利用ガイドラインの再研修を【XX月XX日まで】に実施します
2. 機密情報を検出するDLP(Data Loss Prevention)ツールの導入を進めます
3. AI利用時の入力内容チェック体制を強化します
改めまして、このたびのご迷惑とご心配をおかけしましたことを
心よりお詫び申し上げます。
今後の経過につきましても、随時ご報告させていただきます。
ご不明な点がございましたら、下記までお問い合わせください。
【担当者名・部署・電話番号・メールアドレス】
テンプレート③:顧客への報告文(誤情報拡散型)
件名:弊社からのご案内内容の訂正とお詫び
XX様
平素よりお引き立ていただき、誠にありがとうございます。
株式会社〇〇の△△でございます。
20XX年XX月XX日にお送りいたしました【メール / チャット / 文書】の内容に
一部誤りがあることが判明いたしました。
誤った情報をお伝えしてしまい、深くお詫び申し上げます。
■ 誤りの内容:
【誤】「〇〇の手数料は無料です」
【正】「〇〇の手数料は△△円です(20XX年XX月時点)」
■ 原因:
弊社の業務支援にAIツールを活用しておりますが、AIが生成した回答内容に
事実と異なる情報が含まれていたにもかかわらず、十分な確認を行わず
そのままご案内してしまいました。
■ お客様への対応:
上記の誤りにより、お客様に不利益が生じた場合は、
誠意をもって対応させていただきます。お心当たりがございましたら、
下記連絡先までお知らせください。
■ 再発防止策:
1. AIが生成した回答の人間による確認プロセスを必須化しました
2. 価格・手数料・契約条件に関する回答は、必ず公式データベースと照合する手順を追加しました
【担当者名・部署・電話番号・メールアドレス】
再発防止報告書の書き方——「原因」と「対策」を構造化する
インシデント収束後、再発防止報告書を作成します。この報告書は社内の記録であるだけでなく、取引先や監査への説明資料にもなります。
再発防止報告書テンプレート
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AIインシデント 再発防止報告書
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 報告日:20XX年XX月XX日
■ 作成者:【氏名・部署】
■ 承認者:【氏名・役職】
■ インシデント番号:AI-INC-20XX-001
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. インシデント概要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 発生日時:
■ 発覚日時:
■ 分類:Type A(情報漏洩)/ Type B(誤情報拡散)/ Type C(外部攻撃)
■ 事象の概要(5W1H):
- What(何が起きたか):
- When(いつ):
- Where(どのシステム・ツールで):
- Who(誰が関与したか):
- Why(なぜ起きたか):
- How(どのように発生したか):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. 影響範囲
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 漏洩 / 誤送信された情報:
■ 影響を受けた人数:
■ 社外への影響:
■ 金銭的損害(推定):
■ 法的影響:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. タイムライン
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| 日時 | 事象・対応 |
|------|----------|
| XX:XX | インシデント発生 |
| XX:XX | 発覚(経緯:〇〇) |
| XX:XX | AI利用停止 |
| XX:XX | 証拠保全完了 |
| XX:XX | 経営層への第一報 |
| XX:XX | 法務部門との協議 |
| XX:XX | 影響範囲の確定 |
| XX:XX | 関係者への通知 |
| XX:XX | インシデント収束宣言 |
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. 根本原因分析
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 直接的な原因:
【例:社員がAI利用ガイドラインを認識しておらず、機密情報を入力した】
■ 根本的な原因(なぜ直接原因が発生したか):
【例1:AI利用ガイドラインの研修が入社時の1回のみで、継続的な教育がなかった】
【例2:AIツールへの入力内容を技術的にチェックする仕組み(DLP等)がなかった】
【例3:インシデント対応手順が文書化されておらず、発覚から初動までに時間を要した】
■ 組織的・制度的な要因:
【例:AI利用に関するガバナンス体制(責任者・ルール・監査)が未整備だった】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. 再発防止策
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| # | 対策 | 担当 | 期限 | 区分 |
|---|------|------|------|------|
| 1 | 【例:全社員向けAI利用ガイドライン再研修の実施】 | 人事部 | XX月XX日 | 人的対策 |
| 2 | 【例:DLP(Data Loss Prevention)ツールの導入】 | IT部門 | XX月XX日 | 技術的対策 |
| 3 | 【例:AI利用時の入力内容の上長承認フローの導入】 | 各部門 | XX月XX日 | 運用的対策 |
| 4 | 【例:AIインシデント対応手順書の整備・全社展開】 | IT部門 | XX月XX日 | 制度的対策 |
| 5 | 【例:四半期ごとのAI利用状況監査の実施】 | 監査部 | XX月XX日 | 監査体制 |
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. 残存リスクと今後の監視計画
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 対策後も残存するリスク:
■ 継続的な監視項目:
■ 次回レビュー日:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AIインシデント対応体制の構築——事前に決めておくべきこと
インシデントが起きてから「誰が対応するか」を決めるのでは遅すぎます。以下の体制を平時のうちに構築しておきましょう。
対応体制の基本構成
| 役割 | 担当者(例) | 責任範囲 |
|---|---|---|
| インシデント対応責任者 | 情報システム部門長 or CISO | 対応方針の最終決定、経営層への報告 |
| 技術調査担当 | IT部門・セキュリティ担当 | 原因調査、証拠保全、システム復旧 |
| 法務・コンプライアンス | 法務部門 | 法的報告義務の判断、顧客対応の法的助言 |
| 広報・対外コミュニケーション | 広報部門 | メディア対応、プレスリリースの準備 |
| 事業部門連絡窓口 | 該当部門の管理職 | 影響を受けた顧客・取引先の特定と連絡 |
平時に準備しておくべき5つのもの
1. AIインシデント対応手順書——本記事の内容を自社の体制に合わせてカスタマイズし、文書化しておく
2. 連絡網——インシデント発生時に誰が誰に連絡するかのエスカレーションフロー。休日・夜間の連絡手段も含む
3. 報告テンプレート——本記事のテンプレートを自社用にカスタマイズし、共有フォルダに配置しておく
4. AI利用ログの保存設定——入出力ログ・アクセスログが一定期間保存される設定を確認。ログがなければ調査ができない
5. AI提供元の連絡先とSLA——利用しているAIサービスの緊急連絡先、データ削除依頼の方法、データ処理契約の内容を事前に確認
インシデント対応のタイムライン全体像
| 時間軸 | フェーズ | 主なアクション |
|---|---|---|
| 0〜30分 | 初動対応 | 止める → 証拠保全 → 責任者連絡 → タイプ特定 → エスカレーション |
| 30分〜4時間 | 影響評価 | 被害範囲の確定 → 法的報告義務の判断 → 対応チーム招集 → 対応方針決定 |
| 4〜24時間 | 関係者対応 | 顧客・取引先への通知 → 社内周知 → 必要に応じてメディア対応 → AI提供元への対応要請 |
| 1〜3日 | 原因調査 | 詳細なログ分析 → 根本原因の特定 → 法的報告(速報)の提出 |
| 1〜2週間 | 復旧と再発防止 | 再発防止策の策定と実行 → 再発防止報告書の作成 → AI利用の再開判断 |
| 1ヶ月以内 | 事後レビュー | 法的報告(確報)の提出 → インシデント対応の振り返り → 対応手順の改善 |
よくある質問(Q&A)
Q1. 社員がChatGPTに機密情報を入力した場合、それは「情報漏洩」に該当する?
法的にはケースバイケースです。ChatGPTの場合、API経由の利用ではデフォルトで入力データがモデルの学習に使用されない設定ですが、無料のWeb版では利用規約上、入力データが学習に使用される可能性があります。入力データがAI提供元のサーバーに送信・保存された時点で「社外への情報提供」に該当する可能性があり、個人情報保護法上の「漏洩」に当たるかは、データの性質と利用規約の内容により判断が分かれます。法務部門と速やかに協議してください。
Q2. AIの誤回答で顧客に損害が出た場合、法的責任はどうなる?
現時点の日本の法律では、AIの出力に対する責任はAIを利用した企業に帰属するのが原則です。「AIが勝手に回答した」は免責事由にはなりません。AIの出力を顧客対応に使用した場合、その内容の正確性を確認する責任は利用企業にあります。損害賠償のリスクを軽減するためには、AI出力の人間によるレビュープロセスの必須化と、AIを利用している旨の顧客への開示が重要です。詳細は弁護士にご相談ください。
Q3. 中小企業でCSIRTがない場合、誰がインシデント対応するべき?
専任のセキュリティチームがない中小企業では、「情報システム担当者」+「経営者」+「顧問弁護士(外部)」の3者で対応するのが現実的です。最も重要なのは、インシデント発生時の連絡先と判断権限者を事前に決めておくことです。対応手順を文書化し、年に1回はシミュレーション(机上演習)を行っておくと、実際のインシデント時の対応速度が大きく向上します。
Q4. AI提供元(OpenAI等)にデータの削除を依頼できる?
主要なAIサービス提供元は、入力データの削除に関するポリシーを公開しています。ただし、削除の範囲や確認方法はサービスによって異なります。利用開始時にデータ処理契約(DPA)を確認し、インシデント発生時の削除手続きを把握しておくことが重要です。API利用の場合は、データ保持期間や学習利用の有無を契約時に確認してください。
Q5. インシデント対応訓練(机上演習)はどうやればいい?
最もシンプルな方法は、本記事のインシデントシナリオ(Type A / B / Cの具体例)を1つ選び、対応チームのメンバーで「もしこれが自社で起きたら」という想定で議論することです。所要時間は60〜90分程度で十分です。初動対応フローに沿って「誰が何をするか」を確認し、不明点や不備があれば手順書を更新します。年1〜2回の実施が推奨されます。
まとめ——「準備していた企業」と「していなかった企業」の差は、最初の30分に出る
この記事のポイントをまとめます。
1. AIインシデントは3タイプに分類される。情報漏洩型(Type A)、誤情報拡散型(Type B)、外部攻撃型(Type C)——タイプによって初動対応と関係者が異なるため、まずタイプを特定することが出発点です。
2. 最初の30分の鉄則は「止める → 保全する → エスカレーションする」。原因究明は後回しでいい。まずは被害の拡大を止め、証拠を保全し、判断権限者につなぐことが最優先です。
3. 報告テンプレートは「事前に」準備しておく。本記事の社内第一報テンプレート、取引先報告テンプレート、再発防止報告書テンプレートをカスタマイズし、いつでも使える状態にしてください。
4. 個人情報保護法の報告義務(速報3〜5日以内)を忘れない。個人情報漏洩に該当する場合、法定期限内に個人情報保護委員会への報告が必要です。法務部門との早期連携が不可欠です。
5. 平時の準備がインシデント時のすべてを決める。対応体制の構築、連絡網の整備、ログ保存の設定、年1回の机上演習——これらを「平時のうちに」やっておくかどうかで、インシデント発生時の被害規模が決定的に変わります。
AIリスク管理3部作の第1部(稟議・承認)と第2部(運用トラブル対応)と合わせて、予防→日常運用→インシデント対応の全サイクルをカバーする体制を構築してください。
参考リンク
免責事項: 本記事は2026年3月時点の公開情報に基づく情報提供であり、法的助言ではありません。実際のインシデント対応においては、必ず弁護士・法務部門に相談のうえ、自社の状況に応じた判断を行ってください。個人情報保護法の報告義務に関する記載は概要であり、具体的な判断は個別の事案に応じて法務専門家にご確認ください。本記事のテンプレートはあくまで雛形であり、自社の状況・業界・規模に合わせてカスタマイズしてご利用ください。

コメント