生成AIへの個人情報の入力は漏えい報告の対象か｜判断と初動【2026】

「社員が顧客リストをChatGPTに貼って要約させていた」——この報告を受けたとき、社内で最初に割れるのが「これは個人情報の漏えいとして届け出が要るのか」という判断です。答えを持たないまま数日が過ぎ、報告期限だけが進んでいく、というのが実際によくある事故の形です。この記事では、生成AIへの個人情報の入力が漏えい報告の対象になるのかを、個人情報保護法の条文と個人情報保護委員会の資料に沿って整理し、発覚直後にやることを時系列で並べます。

結論として、「AIに入力した」こと自体が自動的に漏えい報告の対象になるわけではありません。報告義務がかかるのは、個人情報保護法第26条と同法施行規則第7条が定める4類型に当たる場合です。ただし個人情報保護委員会は、本人の同意なく個人データを含むプロンプトを入力し、それが「応答結果の出力以外の目的で取り扱われる場合」には法違反となる可能性があると明示しています。つまり争点は「漏えいしたか」より先に、そのサービスが入力内容を機械学習などに使う設定・契約になっていたかにあります。ここが判断の起点です。

まず、どの条文の話なのかを固定する

社内の議論が空回りする最大の理由は、「漏えい」「報告」「通知」がすべて別々のルールなのに、ひとまとめに語られることです。関係する条文は次の3層に分かれています。

法第26条第1項は「その取り扱う個人データの漏えい、滅失、毀損その他の個人データの安全の確保に係る事態であって個人の権利利益を害するおそれが大きいものとして個人情報保護委員会規則で定めるものが生じたとき」に報告義務が生じると定めています。ポイントは、「規則で定めるもの」に限定されている点です。すべての事故が報告対象ではありません。

報告対象となる4類型（規則第7条）

施行規則第7条は、報告対象を次の4つに限定しています。いずれも「発生した」場合だけでなく「発生したおそれがある事態」を含みます。

• ①要配慮個人情報が含まれる個人データの漏えい等（高度な暗号化その他の必要な措置を講じたものを除く）
• ②不正に利用されることにより財産的被害が生じるおそれがある個人データの漏えい等
• ③不正の目的をもって行われたおそれがある行為による個人データの漏えい等
• ④本人の数が1,000人を超える漏えい等

健康・病歴・信条などの要配慮個人情報が1件でも含まれれば①に当たり得ます。クレジットカード番号を含む決済情報であれば②が視野に入ります。逆に、社員の氏名と社内メールアドレスだけを50件貼った、というケースは、この4類型のどれにも形式的には当てはまらないことが多くなります。AIに入力してはいけない情報の分類を先に決めておくと、事故のたびにゼロから議論せずに済みます。

「AIに入力した」は漏えいなのか

ここが最も判断の割れるところです。個人情報保護委員会は、令和5年6月2日の「生成AIサービスの利用に関する注意喚起等」で、個人情報取扱事業者向けに次の2点を挙げています（原文の要点）。

• 個人情報を含むプロンプトを入力する場合は、特定された利用目的を達成するために必要な範囲内であることを十分に確認すること
• あらかじめ本人の同意を得ることなく個人データを含むプロンプトを入力し、当該個人データが「当該プロンプトに対する応答結果の出力以外の目的で取り扱われる場合」、個人情報保護法の規定に違反することとなる可能性がある。そのため、提供事業者が当該個人データを機械学習に利用しないこと等を十分に確認すること

この文言が示しているのは、判断の分岐が「入力したかどうか」ではなく「入力した先で、応答を返す以外のことに使われる状態だったか」にあるということです。したがって事故対応の一次調査は、次の順で行うのが実務的です。

1. 使われたサービスと契約形態を特定する（個人アカウントか、会社契約か、APIか）
2. そのプランで入力内容が学習に使われる設定だったかを、提供元の公式ドキュメントと管理画面の設定履歴で確認する
3. 会話履歴が他者から閲覧可能な状態になっていなかったか（共有リンクの発行、共有アカウントの使い回し）を確認する
4. 入力されたデータの中身と件数を特定し、4類型に照らす

注意したいのは、個人情報保護委員会の注意喚起は「入力＝漏えい」と述べているわけではなく、利用目的の範囲と個人データの取扱いの観点から違反の可能性を指摘している点です。個々の事案が法第26条の報告対象に当たるかどうかは、事実関係次第の個別判断になります。この記事は一般的な整理であり、実際の届出要否は弁護士や所管当局への確認を前提にしてください。判断に迷う材料が残るなら、報告しない理由を探すより先に、次の時系列を動かすほうが安全です。

発覚してからの時系列

報告義務がかかった場合、期限は「知った後」から進みます。施行規則第8条の定めと、個人情報保護委員会が公開している解説の目安を並べると次のようになります。

速報の段階では、その時点で把握している範囲で構いません。規則第8条第1項も報告事項を「報告をしようとする時点において把握しているものに限る」としています。「全部わかってから出す」のではなく、わかっている範囲で出して、確報で埋めるのが制度の建て付けです。ここを誤解して調査完了を待つと、速報の目安を過ぎます。

報告する内容は9項目に決まっている

規則第8条第1項が定める報告事項は次の9つです。社内のインシデント記録シートをこの9項目と同じ見出しで作っておくと、報告時に転記するだけで済みます。

• ①概要／②漏えい等が発生し、又は発生したおそれがある個人データの項目／③本人の数
• ④原因／⑤二次被害又はそのおそれの有無及びその内容／⑥本人への対応の実施状況
• ⑦公表の実施状況／⑧再発防止のための措置／⑨その他参考となる事項

本人への通知は、このうち①概要・②項目・④原因・⑤二次被害・⑨その他参考事項を、本人の権利利益を保護するために必要な範囲で伝える形と定められています（規則第10条）。通知文を一から悩む必要はなく、報告様式の一部を抜き出す設計になっています。

発覚直後の初動チェックリスト

実際に「入力してしまった」報告が上がってきた最初の1時間でやることを、順番に並べます。

• 1. 追加入力を止める：本人に即座に利用を停止させます。慌てて会話を削除させないこと。削除すると、何を入力したかの特定ができなくなります。
• 2. 画面を保全する：入力したプロンプト、会話履歴、共有リンクの有無、アカウント種別（個人／法人）をスクリーンショットで残します。これが後の報告事項②③④の根拠になります。
• 3. 契約と設定を確認する：そのサービスのプランで学習利用の既定値がどうなっているかを、提供元の公式ドキュメントで当日時点で確認します。設定の変更履歴が管理画面に残っていれば併せて取得します。
• 4. 拡散経路を潰す：共有リンクが発行されていれば無効化し、共有アカウントであれば全利用者の会話履歴を確認します。
• 5. 4類型に照らす：要配慮情報の有無、財産的被害のおそれ、不正目的の有無、本人数1,000人超をひとつずつ確認して記録します。該当しないと判断した場合も、その判断根拠を文書で残します。
• 6. 判断者を上げる：報告要否の最終判断は現場ではなく責任者が行い、必要なら外部の専門家に確認します。

本人に「削除させない」ことだけは、事前に周知しておく価値があります。事故の隠蔽ではなく調査のためだと説明しておかないと、善意の削除で事実関係が消えます。

同じ事故を繰り返させない設計

この種の事故は、規則を厳しくしても再発します。実際に効くのは、入力してよい環境をあらかじめ用意しておくことです。

• 学習に使われない契約に寄せる：個人情報保護委員会の注意喚起が求める「機械学習に利用しないこと等の確認」は、法人向けの契約に寄せることで組織単位に片付きます。個人アカウントのまま業務で使っている状態が最大のリスク源です。設定レベルの対処はAI学習オプトアウト設定の手順にまとめています。
• 「貼ってよい形」を配る：顧客名を記号に置き換えたテンプレート、社内で共有する匿名化のルールを配ります。禁止だけを配ると、隠れて使われます。
• ルールを1枚にする：分厚い規程は読まれません。判断基準と連絡先を1枚に収めます。雛形は生成AIの社内ルールのテンプレートが使えます。
• 本当に出せない情報は外に出さない：どうしても外部サービスに載せられない領域があるなら、社内専用のAI環境を構築するか、ローカルLLMが成立する条件の検討に進みます。
• 技術面の対策を並行する：入口の制御と監視は生成AI利用の情報漏洩対策で整理しています。規制の全体像は日本のAI規制の現在地を参照してください。

事故の当日に判断できるかどうかは、事故が起きる前に何を決めていたかで決まります。「うちは4類型のどれに当たり得るデータを持っているか」を先に棚卸ししておくだけで、当日の議論は数時間短縮できます。ルールの整備や社内向けの運用設計でつまずいている場合は、Mihataでも相談を受けています。