生成AIへ誤って顧客情報を送信してしまった、あるいは社外秘資料の共有リンクを外部に公開してしまった――。
こうしたインシデントが発生した際、最初にとるべき行動は「送信・共有の停止」「責任者への報告」「記録の保全」の3点です。
本記事では、中小企業の経営者、管理職、AI推進担当者に向けて、社内報告から利用停止、影響調査、再発防止策までの実務フローをわかりやすく解説します。そのまま活用できる第一報の文例や、外部報告・利用再開を判断するためのチェックリストもまとめました。
現在進行形で情報漏洩の懸念がある場合は、原因究明を待たずに初動対応を開始してください。以下の対応は、担当者間で分担し、並行して進めることが重要です。
1. 初動の全体像と役割分担
「どこまで調査してから上司に報告すべきか」と迷うかもしれませんが、判断に時間をかけている間にも共有リンク経由で情報が閲覧されたり、自動処理によって送信が続いたりするリスクがあります。
まずは速やかに役割を分担し、対応を開始しましょう。
| 対応フェーズ | 主な担当者 | 具体的な着手内容 |
|---|---|---|
| 社内報告 | 発見者・直属の上司 | 判明している事実を速やかに社内責任者へ共有する |
| 利用停止・記録保全 | 利用者・システム管理者 | 送信・共有を即座に止め、履歴やログ、設定情報を保全する |
| 影響調査・対外報告判断 | 対応責任者・管理者・専門家 | 漏洩した情報の種類、範囲、閲覧状況を確認し、報告要否を判断する |
| 再発防止・利用再開 | 経営陣・業務責任者・AI推進担当 | 原因に応じた対策を講じ、利用再開の基準を策定する |
社内に専任の情報システム部門がない場合は、経営陣や管理部門が中心となって対応責任者を定め、契約先のIT保守会社など外部パートナーへ協力を仰ぎます。
全体を統括する「指揮担当」と、システムを調べる「技術担当」を明確に切り分けることがポイントです。
※本記事では具体例として、「営業担当者が個人用AIアカウントに添付した資料の別シートに、顧客約30名分の氏名・連絡先が含まれていた」というケースを想定に解説します。
2. 社内報告と第一報の文例
送信後に別シートの個人情報に気づいた場合、現時点で第三者に閲覧されたかどうかが不明であっても、ただちに社内の指定窓口や上司へ報告します。第一報で求められるのは、現時点で把握できている事実の迅速な共有です。
「現在確認中である」という状況自体も、重要な報告内容となります。
以下の6項目を整理して伝えます。すべての情報が揃っていなくても、報告を先送りにしてはいけません。
- 発生・発見日時：発見した時刻、判明している送信・共有時刻
- 利用サービス：サービス名、アカウント種別（個人用／法人用）
- 操作内容：テキスト入力、ファイル添付、共有リンク発行、API連携など
- 対象情報の内容：情報の種類、おおよその対象件数・人数
- 現在の状況：通信や共有の停止有無、実施した遮断措置
- 保全されている記録：プロンプト履歴、添付ファイル、設定画面キャプチャ、ログの有無
第一報の文例
件名：【第一報】生成AIへの顧客情報誤送信について 本日10時05分、サービスA（個人アカウント）へ添付した営業資料の別シートに、顧客約30名分の氏名および連絡先が含まれていたことが判明いたしました。送信時刻は10時00分です。 すでに対象サービスへの追加入力は停止しており、会話履歴および添付ファイルは削除せず保持しています。現時点で共有リンクの作成有無や第三者による閲覧の有無については調査中です。今後の対応についてご指示をお願いいたします。
第一報は要点のみを簡潔に伝え、詳細なログや対象データは閲覧権限を限定した安全な場所で管理します。社内チャットのパブリックチャンネルに顧客情報を再掲したり、報告書作成のために別の生成AIへ入力したりすると、二次被害を招く恐れがあるため厳禁です。
なお、報告を受けた管理職側は、報告者を責めるのではなく「速やかに共有してくれて助かった。まずは状況を一緒に確認しよう」と受け止める姿勢が欠かせません。心理的安全性を確保し、隠蔽や報告遅延を防ぐ環境づくりも初動対応の一環です。
3. 利用停止と記録の保全
利用停止の目的は、外部への情報流出経路を完全に遮断することです。
チャット画面への入力だけでなく、クラウド連携、自動実行スクリプト、共有リンクなども確認対象となります。
単にブラウザのタブを閉じるだけでは処理が停止しないケースもあるため注意が必要です。
停止すべき対象
状況に応じ、利用者と管理者が連携して以下の措置を講じます。
- 該当AIへのテキスト入力・ファイル添付・自動連携処理の停止
- 意図しない公開範囲になっている共有リンクの無効化、アクセス権限の剥奪
- 問題が発生したアカウントに紐づく外部サービス連携やデータ取得権限の解除
- APIキーやパスワードなどの認証情報を誤送信した場合は、直ちに鍵を無効化（リボーク）して再発行し、不正アクセスの有無を確認
停止すべき範囲の判断に迷う場合は、自己判断で限定せず、責任者の判断のもとで一時的に広範囲を遮断した上で調査を進めます。その際、影響を受ける業務の代替手段も併せて検討してください。
保全すべき記録
焦りからチャット履歴やアカウントごと削除してしまうケースが見られますが、データを消してしまうと「具体的に何が、どの範囲で送信されたか」の追跡が困難になります。
管理権限を持つ担当者が、プロンプト（入力文）、添付ファイル、AIの出力結果、タイムスタンプ、共有設定、アクセスログを確実に保全します。
ただし、リアルタイムで情報流出が続いている場合は、証拠保全よりもアクセスの遮断を最優先してください。遮断と保全を並行して行い、いつ、どの設定を変更したかも記録しておきます。
4. 影響範囲の調査
「学習に利用されない設定（オプトアウト）にしていたから安全」とは言い切れません。モデルの学習利用の有無は調査項目の一つにすぎず、「外部サーバーへの送信」「事業者側でのログ保持」「第三者によるアクセス可能性」はそれぞれ個別に検証する必要があります。
| 調査項目 | 具体的な確認事項 |
|---|---|
| 情報の性質 | 個人情報、取引先の機密情報、インサイダー情報、認証情報が含まれているか |
| 対象の範囲 | 影響を受ける件数・人数。非表示行・別シートなどに意図しないデータが含まれていないか |
| 流出経路 | 手入力、ファイル添付、Web共有リンク、API連携など、どの経路で送信されたか |
| 規約・保存条件 | 利用規約、プラン内容、事業者側の保持期間、学習利用の有無、削除ポリシー |
| アクセスの有無 | 外部からアクセス可能な状態だったか。実際の閲覧ログ・取得記録が存在するか |
調査結果は「確認された事実」「推測されるリスク」「現時点で未確認の事項」の3つに分類して整理します。閲覧ログが残らない仕様の場合、「ログに閲覧記録がないから漏洩していない」と断定することはできません。
また、AIチャット画面上で「このデータは外部に漏れましたか？」とAI自身に質問しても、正確な回答は得られません。必ず管理コンソールやプロバイダの公式ドキュメント、サポートへの問い合わせを通じて客観的な事実を確認してください。
5. 対外報告と本人通知の判断
調査と並行して、監督官庁（個人情報保護委員会など）への報告や、影響を受ける本人・取引先への通知要否を検討します。
日本の個人情報保護法において、以下のような事態（またはそのおそれ）が発生した場合は、個人情報保護委員会への報告および本人への通知が義務付けられています。
- 要配慮個人情報（病歴・信条など）が含まれる漏洩
- 不正利用により財産的被害が発生するおそれがある漏洩（クレジットカード情報など）
- 不正アクセスなど、悪意ある意図による漏洩
- 対象となる本人の数が1,000人を超える漏洩
今回の例のように「対象が約30名だから報告義務はない」と安易に判断せず、データの性質や漏洩経路を考慮して法的な報告基準に該当するかを確認する必要があります。
報告期限の目安
- 速報：事態を把握してから概ね3〜5日以内（把握している事実のみで速やかに提出）
- 確報：事態を把握した日から30日以内（不正アクセス等の場合は60日以内）
- 本人通知：状況に応じて速やかに実施（通知が困難な場合は公表等の代替措置を検討）
取引先から受託したデータである場合は、契約書に定められたインシデント発生時の通知期限や連絡窓口も確認してください。法務担当者や顧問弁護士と連携し、事実関係、実施済みの措置、今後の対応予定を整理した上で誠実な説明を行います。
6. 再発防止と利用再開に向けた基準
事態が収束した後は、単に「個人の不注意」として片付けず、運用プロセスやシステムの構造的な原因を検証します。
実効性のある入力ガイドラインの策定
「社外秘は入力禁止」といった抽象的なルールでは現場での判断が難しいため、実際の業務フローに落とし込んだ基準を設けます。
- そのまま入力してよい情報（公開情報、社内規定など）
- 加工・マスキングを行えば利用できる情報（顧客名・固有名詞をダミーに置換した文章）
- 入力してはならない情報（個人特定情報、非公開の財務情報、認証鍵）
ファイルを添付する際は、元データを直接アップロードせず、必要なシートやカラムだけを抽出した「AI投入専用の作業ファイル」を作成する手順を標準化するといった対策が有効です。
権限管理とアカウントの適正化
会社が認可した法人向けプラン（Enterprise等）を利用し、個人アカウントでの業務利用（シャドーIT）を禁止します。また、サービス選定時には監査ログの取得可否、学習拒否設定（オプトアウト）、退職時のアカウント一元管理（SSO等）が可能かどうかを必ず確認してください。
インシデント対応の社内シミュレーション
策定したルールが機能するか、架空のシナリオを用いた演習を定期的に実施します。「誰に連絡し、誰がシステム権限を止め、誰がログを保全するか」を実際に確認することで、「夜間・休日に管理者が不在で対応できない」「連絡先が周知されていない」といった組織課題を事前に洗い出すことができます。
利用再開のチェックポイント
- 漏洩原因となった経路の遮断および設定修正・動作確認が完了しているか
- 影響範囲の整理と、必要な対外報告・通知が完了（または着手）しているか
- 現場の利用者が新しい運用ルールや手順を十分に理解しているか
- 再開後の監視体制（定期的なログチェック等）が整っているか
安全性が担保された業務から段階的に再開し、継続的にモニタリングを行いましょう。
まとめ：平時に決めておくべき「3つの担当」
インシデント発生時に迅速に行動できるよう、自社で以下の役割があらかじめ決まっているか確認してください。
- 報告窓口：「漏洩したかもしれない」と気づいた社員が、最初に連絡を入れる担当者
- 遮断担当：共有リンクやアカウント連携、APIなどを即座に停止できる権限保持者
- 代理担当：メイン担当者が不在の際に、判断と操作を代行できる担当者
役職名だけでなく、具体的な氏名と緊急連絡先を社内に周知しておくことが重要です。
迅速な報告と初動対応ができる体制を整えることこそが、組織として生成AIを安全かつ効果的に活用し続けるための前提条件となります。
この記事の執筆・監修
執筆
山下 敏樹IT企業勤務。Web制作会社で社内業務改善・DX推進に携わり、code4bizで学んだAIコーディングを活用してさまざまな業務を自動化。半年間の取り組みで、年間約2,500時間相当の業務削減を実現。その後、IT/AIコンサルタントへ転身。DX現場での経験をもとに、AI活用・業務改善・DX・システム開発に関する知識やノウハウを、読者の成果につながる形で発信しています。
生成AI業務整理DX
