生成AIと個人情報|個人情報保護法に沿った入力ルールと実務対策

- 既定の設定で入力内容がモデルの改善(学習)に使われる場合がある
- 学習の停止は利用者ごとの設定(オプトアウト)に任される
- 管理者による利用状況の確認や監査ログの取得ができない
- 個人データの入力は原則として禁止の対象になる
- 入力・出力データを既定で学習に使わないことが規約に書かれている
- データの保持期間や処理地域を契約で確認できる
- SSOや管理コンソールでアカウントと権限を一元管理できる
- 社内ルールに沿って限られた範囲で個人データを扱う選択肢になる
- 1. データを分類する個人データ・要配慮個人情報・機密情報・公開情報の4区分で、入力できる範囲を決める
- 2. 利用目的を確認する公表済みの利用目的の範囲内で生成AIを使うかを確認し、必要ならプライバシーポリシーを改定する
- 3. サービスを審査する学習への利用有無、データの保存期間、サーバーの所在国を規約と契約で確認する
- 4. 技術的な対策を入れるマスキング、入力フィルタ、SSO、監査ログで人為的なミスを仕組みで防ぐ
- 5. 教育と見直しを続ける従業員研修と定期点検を行い、法改正やサービス規約の変更に合わせてルールを更新する
生成AIに個人情報を入力すると何が問題になるのか?
入力した個人情報が事業者側で保存されたり学習に使われたりすると、目的外利用や漏えいとして法的責任を問われるおそれがあります。
ChatGPTやClaude、Geminiなどの生成AIは便利な反面、プロンプトに入れた情報が「社外のサーバーに送られる」という点を忘れがちです。顧客名簿の整理や問い合わせメールの要約など、日常業務で個人情報を含むテキストを貼り付ける場面は多くあります。リスクを正しく把握しないまま利用が広がると、後から問題を把握して止めるのは難しくなります。
入力したデータはどこに流れるのか?
プロンプトは提供事業者のサーバーで処理され、一定期間保存されます。契約や設定によってはモデルの学習に使われることもあります。
生成AIサービスに送ったデータの扱いは、おおむね次の3段階に分けて考えると整理しやすくなります。
- 処理:推論のために事業者のサーバー(多くは国外)へ送信される
- 保存:不正利用の監視や履歴表示のため、一定期間保持される
- 学習:利用規約や設定によっては、モデル改善のための学習データに使われる
特に注意が必要なのは3の「学習」です。学習に使われた情報は、ほかの利用者への出力に現れる可能性をゼロにはできません。個人向けの無料プランでは、学習への利用が初期設定でオンになっているサービスもあります。現場を見ていると、従業員が私物アカウントで業務データを扱う、いわゆる「シャドーAI」が最大の抜け穴になっていることが多いと感じます。
起こり得るトラブルにはどんな類型があるのか?
主なリスクは目的外利用、意図しない第三者提供、漏えい、誤った出力による権利侵害の4つで、それぞれ関係する条文が違います。
| リスク類型 | 想定される場面 | 主に関係する個人情報保護法の規定 |
|---|---|---|
| 目的外利用 | 採用応募者の情報を、本人に通知していない用途の分析に使う | 第18条(利用目的による制限) |
| 意図しない第三者提供 | 学習に使われる設定のまま顧客データを入力する | 第27条(第三者提供の制限)、第28条(外国にある第三者への提供) |
| 漏えい・安全管理の不備 | 共有リンクや履歴から他部署・社外に情報が見えてしまう | 第23条(安全管理措置)、第26条(漏えい等の報告) |
| 不正確な出力 | 実在の人物について事実と異なる内容を生成し、それを利用する | 第22条(データ内容の正確性の確保等)、名誉毀損等の民事責任 |
個人情報保護法は生成AIの利用をどう規制しているのか?
生成AIだけを対象にした条文はありません。利用目的、第三者提供、安全管理措置といった既存のルールが、そのまま生成AIの利用にも当てはまります。
個人情報保護法(個人情報の保護に関する法律)は技術に中立な法律です。生成AIを使うかどうかではなく、「個人情報をどの目的で、誰に、どう扱わせるか」によって適法かどうかが決まります。そのため、生成AIを使う場面を既存の条文に当てはめて確認するのが実務の基本になります。
個人情報保護委員会はどんな注意喚起を出しているのか?
個人情報保護委員会は2023年6月2日、生成AIサービスの利用について、事業者・行政機関・一般の利用者それぞれに向けた注意喚起を公表しています。
事業者向けの要点は次の2つです。
- 個人情報を含むプロンプトを入力する場合は、特定した利用目的を達成するために必要な範囲内であることを十分に確認すること
- 本人の同意を得ずに個人データを入力し、その個人データが応答の出力以外の目的(機械学習など)で取り扱われる場合、個人情報保護法に違反するおそれがあるため、提供事業者がそうした取扱いをしないことを十分に確認すること
あわせて同委員会は、OpenAIに対し、要配慮個人情報を本人の同意なく取得しないことなどを求める注意喚起も行っています。社内ルールを作るときは、この公表資料を一次資料として参照するのが確実です。
押さえておくべき条文と実務上の論点は何か?
実務で特に問題になるのは、利用目的、第三者提供、外国移転、安全管理、漏えい報告の5つです。
| 条文 | 規定の内容 | 生成AI利用での論点 |
|---|---|---|
| 第17条・第18条 | 利用目的の特定と、その範囲内での利用 | プライバシーポリシーに記載した目的の範囲内での入力か |
| 第23条〜第25条 | 安全管理措置、従業者の監督、委託先の監督 | アカウント管理・ログ取得・ベンダー評価ができているか |
| 第26条 | 漏えい等の報告・本人通知 | 要配慮個人情報や1,000人を超える漏えいなどは個人情報保護委員会への報告義務の対象 |
| 第27条 | 第三者提供には原則として本人同意が必要 | 生成AI事業者への入力が「提供」にあたるか、「委託」と整理できるか |
| 第28条 | 外国にある第三者への提供の制限 | 国外サーバーで処理されるサービスで、同意・体制整備・情報提供が必要か |
「委託」と「第三者提供」はどう区別するのか?
事業者が入力データを自社の目的で利用しない契約になっていれば、委託やクラウド利用として整理できる余地があります。学習に使われる場合は、第三者提供にあたるおそれが高まります。
個人情報保護委員会のガイドラインやQ&Aでは、クラウドサービス事業者が個人データを取り扱わないこととなっている場合は「提供」にあたらない、という考え方が示されています。また、委託(第27条第5項第1号)であれば本人同意は不要ですが、委託先の監督義務(第25条)がかかります。
一方で、入力データが事業者のモデル学習に使われる場合は、事業者が自らの目的でデータを利用していることになるため、委託の範囲を超えるおそれがあります。どちらに整理するかは利用規約やデータ処理契約(DPA)の文言によって変わるため、法務部門と一緒に条項を確認することをおすすめします。
個人情報を守る生成AIサービスの選び方は?
学習に使われないこと、保存期間、データの保管場所、管理機能の4点を契約で確認できる法人向けプランを選ぶのが基本です。
機能や回答の精度だけで選ぶと、法務・情報システム部門の審査で止まり、導入が数カ月遅れることも珍しくありません。最初からデータの取扱いを選定基準に入れておくほうが、結果的に早く導入できます。
確認すべきチェック項目は何か?
最低限、次の6項目を利用規約・DPA・セキュリティ資料で確認します。担当者の口頭説明ではなく、文書で裏付けを取ることが重要です。
- 学習への利用:入力・出力データがモデル学習に使われないことが規約で明記されているか
- 保存期間:不正利用の監視などのための保存期間と、保存しない設定(ゼロデータ保持など)の有無
- データの保管場所:処理・保存が行われる国や地域。第28条の外国移転への対応にかかわる
- 管理機能:シングルサインオン(SSO)、利用者管理、監査ログ、利用状況のレポート
- 第三者認証:ISO/IEC 27001、SOC 2 Type 2などの取得状況
- 再委託先:サブプロセッサの一覧と、変更されたときの通知方法
個人向けプランと法人向けプランは何が違うのか?
最も大きな違いはデータの扱いです。法人向けプランやAPIは初期設定で学習に使わない方針のものが多い一方、個人向けプランは設定しだいで学習に使われることがあります。
| 比較項目 | 個人向けプラン(無料・個人有料) | 法人向けプラン・API |
|---|---|---|
| 学習への利用 | 初期設定で学習に使われる場合がある(オプトアウトが必要) | OpenAI・Anthropic・Microsoft・Googleの主要な法人向け製品は、原則として学習に使わない方針を公表 |
| 管理者による統制 | なし(利用者まかせ) | SSO・権限管理・監査ログあり |
| 契約上の保証 | 利用規約のみ | DPAなど、個別の契約条件を結べる場合がある |
| 社内データとの連携 | 限定的 | Microsoft 365 CopilotやGemini for Google Workspaceのように、既存の権限体系の中で動作するものがある |
各社の方針は改定されることがあります。たとえば、個人向けサービスの学習方針は2025年にも変更された例があります。契約時だけでなく、年に1回程度は規約を見直すことをおすすめします。
社内で個人情報を扱う生成AIの運用ルールはどう作るのか?
情報を「入力禁止・条件付きで可・入力可」に区分し、承認済みのツールと技術的な制御を組み合わせて運用するのが現実的です。
「個人情報は一切入力禁止」というルールは分かりやすい反面、業務で使えない場面が増えるため、かえってシャドーAIを招きがちです。守れるルールにすることを優先し、区分と例外の手続きを明確にしておくことが、結果的に統制を強めます。
入力してよい情報をどう区分するのか?
要配慮個人情報やマイナンバーは原則禁止とし、一般的な個人情報は承認済みツールに限って許可する3段階方式が運用しやすいでしょう。
| 区分 | 該当する情報の例 | ルール |
|---|---|---|
| 入力禁止 | 要配慮個人情報(病歴・犯罪歴・信条など)、個人番号(マイナンバー)、クレジットカード番号、認証情報 | どのツールにも入力しない |
| 条件付きで可 | 顧客・従業員の氏名、連絡先、取引履歴など | 学習に使われないことを確認した承認済みの法人向けツールに限り、利用目的の範囲内で入力する |
| 入力可 | 公開情報、匿名化・仮名化したデータ、個人に関係しない社内文書 | 承認済みツールで自由に利用できる |
なお、氏名を伏せただけのデータでも、ほかの情報と照らし合わせて個人を特定できる場合は個人情報にあたります。「仮名化したから安全」と考えず、どこまで加工するかの基準もルールに書いておくとよいでしょう。
策定から定着までの手順は?
現状把握から始めて、規程の策定、ツールの承認、研修、モニタリングまでを1つのサイクルとして回します。
- 現状把握:部署ごとの生成AIの利用実態とシャドーAIの有無をアンケートやアクセスログで確認する
- リスク評価:扱う個人情報の種類と業務を対応づけ、高リスクの業務を特定する
- 規程の策定:入力区分、承認済みツールの一覧、例外申請の手続き、違反時の対応を定める
- プライバシーポリシーの確認:生成AIを使った処理が、公表している利用目的の範囲内かを確認し、必要に応じて改定する
- 研修:具体的なNG例とOK例を使った短い研修を全従業員に実施する
- モニタリングと見直し:監査ログを定期的に確認し、半年から1年ごとに規程を更新する
このうち実務で抜けやすいのは4です。プライバシーポリシーの利用目的が「サービス提供のため」など漠然とした書き方になっていると、生成AIを使った分析が目的の範囲内か判断しにくくなります。
技術的なガードレールは何を入れるべきか?
ルールの周知だけでは入力ミスは防げません。データ損失防止(DLP)、自動マスキング、利用できるツールの制限を組み合わせ、人の注意に頼らない仕組みにします。
- DLP(データ損失防止):プロンプトに含まれるマイナンバーやカード番号などのパターンを検知し、送信をブロックまたは警告する
- マスキング用の中継サーバー(ゲートウェイ):社内からのAPI呼び出しを中継し、氏名や電話番号を自動で置き換えてから送信する
- アクセス制御:未承認の生成AIサービスへの接続をプロキシやCASBで制限する
- ログの保管:誰が何を入力したかを追跡できるようにし、漏えいが疑われるときの調査に備える
RAGやAIエージェントで個人データを扱う際の注意点は?
RAGでは検索対象の文書のアクセス権限を引き継ぐこと、AIエージェントでは実行できる操作と参照できるデータを最小限に絞ることが要点です。
チャットに手で入力する段階から、社内データベースと連携するRAG(検索拡張生成)や、自律的に操作を行うAIエージェントへ進むと、個人データを扱う量も経路も一気に増えます。入力ルールだけでなく、システムの設計段階でプライバシーを組み込む必要があります。
RAGでは何に気をつけるべきか?
最大のリスクは、本来は閲覧権限のない社員が、RAG経由で人事評価や顧客情報を引き出せてしまうことです。
RAGは社内文書をベクトルデータベースに取り込み、質問に関係する部分を検索して生成AIに渡します。このとき元の文書のアクセス権限を引き継がないと、たとえば一般社員が「〇〇さんの評価は?」と聞くだけで人事情報が出力されてしまいます。
| 設計上の論点 | 対策 |
|---|---|
| アクセス権限の継承 | 検索時に、質問した社員の権限で絞り込む(ドキュメント単位のアクセス制御) |
| 取り込み対象の選別 | 要配慮個人情報を含むフォルダを取り込み対象から除外する |
| 削除への対応 | 本人から削除を求められたときに、ベクトルデータベースからも確実に削除できるようにする |
| 出力の記録 | 誰がどの文書を参照したかをログに残す |
AIエージェントでは何に気をつけるべきか?
AIエージェントはメールの送信やデータベースの更新を自律的に行えるため、権限を最小限にし、外部への送信の前には人が承認する仕組みが欠かせません。
AIエージェントには、外部のWebページやメールに仕込まれた指示に従ってしまう「プロンプトインジェクション」というリスクがあります。顧客データへのアクセス権と外部への送信権を同時に持たせると、攻撃者の指示で個人データが外部に送られる経路ができてしまいます。現場では次の原則を設計の前提にするのが安全だと考えます。
- 参照できるデータは業務に必要な範囲だけにする(最小権限の原則)
- メール送信や外部APIへの書き込みなど、元に戻せない操作の前に人が確認する
- MCP(Model Context Protocol)などで外部ツールと連携する場合は、接続先ごとに権限を審査する
漏えいが起きたときはどう対応するのか?
要配慮個人情報の漏えいや1,000人を超える漏えいなどは、個人情報保護委員会への報告と本人への通知が義務です。報告フローは事前に決めておきます。
個人情報保護法第26条と施行規則では、漏えいなどを知ってから「速やかに」(目安として3〜5日以内)速報を出し、原則30日以内(不正な目的による漏えいなどの場合は60日以内)に確報を出すことが求められています。RAGやAIエージェントの不具合で権限外の閲覧が起きた場合も、漏えいにあたるかどうかの判断が必要になります。ログがなければ影響範囲を特定できず、報告の内容も固まりません。システムを設計する段階で、ログの設計とインシデント対応の手順を必ずセットで用意しておくことが、生成AI活用を止めないための最も確実な備えです。
本記事の法令解説は、個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」(2023年6月2日)、個人情報保護法ガイドライン(通則編)およびQ&Aにもとづいています。個別の事案は専門家にご相談ください。





