生成AIに機密情報を入力してしまったら？初動対応と報告手順

まず結論：追加送信を止め、秘密を貼り直さずに報告する

生成AIに顧客情報、社内資料、認証情報を入力してしまったら、まず追加の入力・アップロード・共有を止め、社内のセキュリティ窓口へ連絡してください。報告するのは、利用サービス、アカウント、送信時刻、情報の種類です。機密文書の全文やAPIキーを、別のチャットへ貼り直す必要はありません。入力しただけで「全世界に公開された」とは断定できませんが、「学習オフだから問題なし」とも決められません。有効なAPIキーや秘密鍵が含まれる場合は、送信先の調査と並行して、発行元の管理者に失効・交換を相談します。

本記事は、個別の漏えい事件を報じるものではなく、誤入力に気付いた利用者と、報告を受ける情シス・開発者・SaaS管理者向けの実務ガイドです。2026年5月18日以前に公開された一次資料を参照し、2026年10月2日に再確認しました。製品の保持期間や設定画面を過去時点で再現したものではありません。実際の対応では、送信時点に適用されていた契約・設定と、現在の提供元の公式案内を照合してください。

「AIに入力した」と「外部に公開された」は何が違う？

最初に、次の4つを分けて調べます。一つが確認できても、残りまで確認できたことにはなりません。

確認すること	確認先・記録する内容
送信と保存	入力・添付の送信成否、会話ID、提供元での保持条件。エラー表示だけで未送信とは決めない
学習などへの利用	対象プラン、契約、送信時点の設定、例外条件。現在のスイッチだけで過去の取扱いを推定しない
他の人への共有	会話の共有リンク、ワークスペースの閲覧範囲、出力を転記した文書やチケット
連携先への転送	接続したストレージ、外部ツール、自動処理の実行履歴と送信先

NCSCの解説は、入力をモデルがその場で学習することと、提供元による情報の取扱いを区別し、規約・プライバシーポリシーの確認を重視しています。2023年の解説なので、そこにある当時の製品挙動を、現在の全サービスへ当てはめないでください。

本記事でいう「漏えい疑い」は調査の入口です。社内ルール違反、提供元への送信、第三者による閲覧、法令上の漏えい等への該当性は、別々に評価します。

誰が何を担当するか

読者・役割	最初の担当範囲
個人・一般利用者	追加操作を止め、分かる範囲を報告。会社の情報なら私用アカウントでの入力でも社内窓口へ連絡する
情シス・セキュリティ担当	受付番号を付け、影響範囲・証跡・封じ込めの担当者を決める
SaaS管理者	契約プラン、組織管理の有無、共有設定、監査ログ、提供元への問い合わせを確認する
開発者・システム所有者	ログやソースに認証情報が含まれたかを確認し、対象の失効・交換と利用状況調査を行う
データ所有者・法務・個人情報保護担当	情報の機密性、契約上の制約、必要な報告・通知と期限を判断する

会社のメールアドレスで登録したことと、会社が管理する契約の中で使ったことは同じではありません。サービス名だけでなく、実際に利用した組織・ワークスペースまで確認します。

まず確認すること：誤入力後のチェックリスト

分からない項目は「未確認」として報告し、全項目が埋まるまで連絡を待たないでください。

利用先：公式サービス名・ドメイン・アプリ名、ブラウザ拡張や連携アプリを経由したか。
利用主体：私用か組織管理か、アカウント、組織・ワークスペース、契約プラン。
時刻と操作：送信日時とタイムゾーン、貼り付け・添付・画像・自動連携のどれか、繰り返し送信したか。
情報の種類：個人情報、契約書、未公開資料、ソースコード、ログ、認証情報など。秘密の実値ではなく分類を記録する。
範囲：対象ファイル、人数・件数・期間の概算。確認できた範囲と、これから調べる範囲を分ける。
継続性：一度の手入力か、フォルダ連携・定期ジョブ等による継続送信か。
共有と転記：会話リンクを作ったか、生成された要約や回答を誰かへ送ったか。
証拠の所在：会話ID、リクエストID、監査ログ、契約・設定変更履歴、参照権限を限定した原本の保管先。

「名前を消したから個人情報ではない」と即断しないことも重要です。顧客番号、職歴、問い合わせ内容などの組合せで個人を特定できる可能性があります。分類に迷ったら、データ分類の基本とデータ所有者の判断を使います。

初動対応：利用者がすること・しないこと

やること

追加送信を止める。 同じ資料を別のAIへ渡して安全性を判定させない。継続連携が疑われる場合は管理者に停止を依頼する。
社内窓口へ短く報告する。 「何を、どのサービスへ、いつ送ったか」「今も送信や共有が続くか」を優先する。上司だけへの連絡で終わらず、組織のインシデント報告経路につなぐ。
必要最小限の証跡を残す。 会話IDや時刻、操作履歴を記録する。画面や原本が必要なら、機密情報を扱える保管先・閲覧者を担当者と決める。
不用意な共有を止める。 自分に権限があれば、不要な公開・共有リンクを無効化し、その時刻と対象を記録する。詳細な証拠収集を待って共有を放置しない。

やってはいけないこと

報告を避けるために会話・アカウント・監査ログをまとめて消す。
全社員向けチャット、公開リポジトリ、一般の問い合わせ欄に原文やキーを貼る。
AIの「保存しません」「漏えいしていません」という回答を調査結果として扱う。
安全確認のために同じ機密情報を再入力する、他人のアカウントから出力を試す。

チャット削除自体を禁止するわけではありません。担当者が最低限の証跡、共有停止、提供元の削除手続を整理して実施します。緊急の拡散防止と証跡保全は並行して進めます。

管理者の初動：封じ込めと影響確認を並行する

以下は一次資料の一般原則を踏まえたCyberLensの運用例です。提供元が全項目を回答・実行できるとは限らず、自社の対応計画を優先してください。NIST SP 800-61 Rev. 3は、インシデント対応を検知・対応・復旧だけでなく組織のリスク管理全体につなげる位置付けを示しています。

1. 送信経路と広がりを確定する

申告内容を、利用可能な監査ログや処理履歴と突き合わせます。AIサービスだけでなく、連携ツール、共有リンク、生成物の保存先も調査対象にします。ログに本文がない、保持期間を過ぎたなど、記録の限界も残してください。「記録がない」と「送信されていない」は別です。

未承認の接続から送信が続く場合は、対象連携の停止や権限の制限を検討します。全社のサービスを一括停止するのではなく、追加流出の可能性と業務影響を踏まえ、責任者が停止範囲を決めます。

2. 認証情報が含まれた場合は、発行元で対処する

有効なAPIキー、アクセストークン、秘密鍵、パスワードが承認されていない相手へ送信された可能性があるなら、漏えい疑いの認証情報として扱います。発行元の管理者と対象・権限・依存処理を確認し、失効・交換、必要に応じたセッション無効化を進めてください。

緊急時は旧認証情報の無効化を優先し、停止する処理への代替策も用意します。新しいキーを作っただけで旧キーが有効なままなら、封じ込めは完了していません。調査では対象IDの利用時刻、接続元、操作記録を確認します。AIサービス側のパスワード変更だけでは、入力した別サービスのキーは失効しません。

GitHubの認証情報なら、具体的な確認項目はGitHub secret leak対応チェックリストへ進んでください。

3. 提供元へ、対象を特定して取扱いを確認する

公式のサポート・セキュリティ窓口へ、会話ID・送信時刻・対象アカウント等を伝え、原文の再送が必要か先に確認します。問い合わせでは、次を分けます。

対象データの保持条件、閲覧可能な主体、外部連携先への転送の有無。
送信時点の契約・設定で、学習やサービス改善に利用される条件。
会話、添付、共有コピー等の削除対象と手続、反映時期、バックアップや保存義務等の例外。
回答できない事項と、追加確認の窓口・見込み。

「削除を依頼した」「受付された」「対象と範囲が確認できた」は異なる状態として記録します。画面上から消えたことを、すべての保存先から即時に消えた証明にはしません。

4. 個人情報・契約上の機密は専門担当へつなぐ

個人情報保護委員会の注意喚起では、個人情報を含む入力の利用目的や、個人データが機械学習等に利用される条件の確認が求められています。これを「学習オフなら法的問題が一切ない」という意味に読み替えないでください。

個別の事案で必要な報告・本人通知・取引先連絡と期限は、情報の種類、契約、状況、適用される制度によって判断が必要です。利用者だけで要否を断定せず、法務・個人情報保護担当へ早めにつなぎます。本記事は個別事案の法的判断を代替しません。

優先度・エスカレーションの判断基準

次の表は社内で対応順を決めるための例であり、法令上の区分や一律の報告期限ではありません。件数だけでなく、悪用可能性・拡散の継続・取り消し可能性を見ます。

状況	優先する対応
有効な認証情報、公開中の共有リンク、継続中の未承認連携がある	緊急の社内連絡経路へ。共有・送信の停止や失効を担当者に依頼し、調査を並行する
顧客の個人情報、未公開の契約・設計情報を送信した、または対象範囲が不明	データ所有者・情シスへ速やかに連絡。機密性、閲覧範囲、契約条件を確認し、法務等へ引き継ぐ
公開済み情報だけで、承認された用途・契約内の利用だと確認できた	根拠と確認者を記録し、通常業務へ戻せるか責任者が判断する

例えば、障害ログに本番用APIキーが混ざっていた場合、氏名がなくても優先度は高くなります。一方、公開済みの製品説明を承認済みサービスで要約したケースは、同じ「AIへの入力」でも扱いが異なります。未確認を低リスクに置き換えないことが判断の要点です。

そのまま使える初動報告テンプレート

秘密の値や個人情報の本文は記入せず、必要な原本はアクセスを限定した別の保管先で管理します。

件名：生成AIへの機密情報入力の疑い／初動報告
発見日時・送信日時（タイムゾーン）：
利用サービス・アプリ・連携経路：
対象アカウント・組織・契約プラン：
入力した情報の種類・概算の範囲（秘密の値は書かない）：
操作方法・会話ID等の識別情報：
現在も続く送信・共有の有無：
確認できた事実と根拠：
未確認事項：
実施した停止・失効等と実施時刻：
証跡の保管先・閲覧可能な担当者：
対応責任者・次の確認事項・次回報告予定：

受付後の調査・復旧まで管理する場合は、漏えい疑い初動テンプレートへ転記します。完了条件は「会話を消した」ではなく、追加送信が止まり、対象の取扱いと残る不確実性を整理し、必要な失効・連絡を終えて責任者が判断できることです。

よくある誤解

学習をオフにすれば、以前送った情報も取り消せる？

その設定が過去の送信分にも適用されるか、保存や共有まで止めるものかは別に確認が必要です。変更した時刻と、提供元の説明を残してください。

有料プランや会社のメールアドレスなら報告しなくてよい？

料金やメールアドレスだけでは判断できません。会社が承認した契約、対象データ、目的、実際の利用環境が一致するかを確認します。未承認利用はシャドーAIとして、把握できていない経路も見直します。

チャットを削除し、AIに「忘れて」と頼めば十分？

会話内の指示は、提供元の正式な削除手続の代わりにはなりません。添付、共有コピー、連携先を含め、何が削除対象になるかを公式窓口で確認します。

報告するには、漏えいした証拠をそろえる必要がある？

疑いの段階で構いません。「送信したことは確認済み、外部閲覧は未確認」のように分けて伝えます。受付側も責任追及より初動を優先し、報告をためらわせない運用にします。

再発防止と、次に読むページ

再発防止では「AI利用禁止」の一言で終わらせず、利用可能なサービス・入力できる情報・相談先を一緒に定めます。ログや文書の実データを渡す前に、必要な部分だけに絞り、機密情報を除いた架空の例で目的を達成できないか確認してください。

入力可否を決める：データ分類とDLPの始め方で、情報の区分を入力ルールへつなげます。
検知・制御の役割を分ける：DLPとCASBの違いで適用範囲を確認します。ツールの導入だけで全経路を防げるとは考えません。
共有と権限を見直す：SaaS権限棚卸しチェックリストを使い、利用者・連携・共有範囲を確認します。
自動処理を安全に設計する：AIエージェント利用ルールで、所有者・権限・停止手順を決めます。
対応の基本を学ぶ：インシデントレスポンスのレッスンで全体像を学び、用語クイズで関連概念を復習できます。

公式情報・参考情報

以下の資料を2026年10月2日に確認しました。いずれも2026年5月18日以前の公表資料です。確認表・報告テンプレート・優先度の例はCyberLensによる実務向け整理で、各機関が定めた生成AI誤入力専用手順ではありません。

個人情報保護委員会：生成AIサービスの利用に関する注意喚起等（PDF） — 2023年6月2日。個人情報を入力する際の利用目的、機械学習への利用、規約の確認について。
NCSC: ChatGPT and large language models: what’s the risk? — 2023年3月14日。入力情報の機密性と提供元での取扱いを考えるための解説。当時の製品仕様を現在の仕様として扱わない。
NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management — 2025年4月。組織のリスク管理にインシデント対応を組み込むための一般的な推奨事項。