顧客、従業員、問い合わせなどの情報を生成AIで処理する前に、何を、誰が、どの目的で、どのサービスへ送り、どこへ保存し、いつ削除するかを可視化します。「法人planだから安全」「学習されない設定だから問題ない」と一項目だけで判断してはいけません。
この記事では、個人情報保護委員会とAI事業者ガイドラインの公式情報を確認しながら、社内の利用可否を検討するチェックリストと台帳を作ります。
免責：本記事は一般的な確認手順であり、個別案件の法的助言ではありません。判断が難しい場合は処理を開始せず、個人情報保護管理者、法務、資格ある専門家へ確認してください。
情報確認日：2026年7月18日（日本時間）
結論：入力前に目的・データ・契約・保存・事故対応を承認する
- AIへ渡るデータフローを項目単位で描く
- 個人を識別する必要性と代替方法を確認する
- service・plan・契約・設定を証拠付きで確認する
- 入力・出力・logを最小権限で管理する
- 誤入力時の停止・報告・削除手順をテストする
AIへ送る個人情報の流れを可視化する
取得元
顧客フォーム / CRM / 社内名簿
↓
前処理
必要項目の抽出 / masking / access check
↓
AIサービス
prompt / 添付file / API request
↓
保存され得る場所
会話履歴 / provider log / app log / feedback / backup
↓
出力先
担当者画面 / CRM / email下書き / 集計表
↓
削除・監査
retention満了 / 利用終了 / 事故対応promptだけでなく、file、system log、feedback、評価dataset、backupにも情報が残り得ます。利用者が見る画面だけで判断せず、処理を担う全システムを記録します。
| 項目 | 記録例 |
|---|---|
| 取得元 | 問い合わせform |
| 入力者 | support担当 |
| AI事業者 | service・plan・API名 |
| 処理データ | 問い合わせ本文、顧客IDの有無 |
| 保存先 | provider、社内app、監査log |
| 出力先 | 返信下書き、担当者のみ |
| 削除責任者 | system管理者 |
利用目的と必要性を確認する
個人を識別する必要があるか
「問い合わせ要約」が目的なら、氏名、email、電話、住所、会員番号をmodelへ渡さずに済む可能性があります。必要な業務結果から逆算し、入力項目を減らします。
目的: 問い合わせを5分類へ分ける
必要:
- 問い合わせ本文の問題部分
- 製品category
不要な可能性:
- 氏名
- email
- 電話番号
- 住所
- 注文番号の全文
- 署名欄匿名化・仮名化・集計で代替できるか
単に氏名を顧客Aへ置換すれば常に匿名になるとは限りません。本文、注文内容、日時などの組み合わせで個人を識別できる場合があります。用語の法的該当性は社内管理者・専門家へ確認してください。
サービス・契約・設定を確認する
個人情報保護委員会は、生成AIへ入力した情報が提供者の学習データとして利用される予定か、利用規約等を確認するよう注意喚起しています。学習利用以外も含め、次を確認します。
- 入力・出力をmodel改善や学習へ利用するか
- 保存期間と削除方法
- subprocessorと国外での処理・保存
- 法人契約、DPA、監査報告、security資料
- 管理者のretention・sharing・log設定
- APIとconsumer UIで条件が違うか
- 契約終了後の返却・削除
- incident通知と問い合わせ窓口
証拠を保存：「学習されない」という営業説明だけでなく、契約条項、公式privacy資料、管理画面設定、確認日を利用申請へ添付します。条件変更時は再審査します。
入力前後の安全管理を決める
入力前のマスキング
| 種類 | 処理例 | 復元対応表 |
|---|---|---|
| 氏名 | [PERSON_001] |
必要な場合だけ別の保護領域 |
[EMAIL] |
通常不要 | |
| 電話 | [PHONE] |
通常不要 |
| 注文ID | 末尾だけ、またはtoken化 | 業務system内で解決 |
maskingの前後で意味が変わっていないかtestします。元データと対応表を同じ場所へ保存すると効果がなくなるため、分離とaccess controlが必要です。
出力・log・再利用の制限
- 出力を別目的へ再利用しない
- 生成結果に個人情報が再出力されていないか確認する
- 会話共有URLや外部公開を禁止・制限する
- 監査logにも生データを残さない
- 評価datasetへ転用する場合は再承認する
- download・copy・export権限を最小化する
API keyの保管はAI APIキーの管理方法も参考になります。
利用前チェックリスト
□ 利用目的とownerを記載した
□ AIが必要な理由と非AI代替を比較した
□ 入力するfieldを最小化した
□ 個人情報・個人データ等の該当性を担当者が確認した
□ masking後の再識別riskを確認した
□ service・plan・API単位で契約を確認した
□ 学習利用・保存・削除・処理地域を確認した
□ access・log・sharing設定を確認した
□ outputの人間reviewを決めた
□ retentionと削除ownerを決めた
□ 誤入力時の連絡・停止・削除手順をtestした
□ 法務・専門家reviewの要否を判断したマスキング・保存・削除台帳
record_id,purpose,data_category,masking,service,storage,retention,delete_method,owner,status
PD-001,問い合わせ分類,本文,氏名等を置換,service-plan,app-log,30日,admin削除,support,approved
PD-002,品質評価,会話sample,未設計,service-plan,dataset,未定,未定,qa,blocked保存期間が未定、削除方法が未確認、ownerが空欄の処理は開始しません。削除操作が実際にprovider・app・backupへ反映されるか、test dataで確認します。
事故時の停止・報告・削除
- 追加の入力、共有、公開、連携を停止する
- 日時、利用者、service、入力範囲、出力先を保全する
- 社内の個人情報保護管理者・security・法務へ連絡する
- service側の削除・incident窓口を確認する
- 必要な報告・本人対応は担当者と専門家が判断する
- 原因と再発防止を記録し、再開承認を得る
利用者が自己判断で履歴を消すと調査に必要な証拠を失う場合があります。社内incident手順に従います。
よくある質問
氏名を消せば入力してよいですか？
一律には判断できません。本文や他の項目で識別できる可能性、利用目的、契約、保存、アクセスを含めて確認します。
法人版なら個人データを入力できますか？
plan名だけでは判断できません。契約、DPA、設定、処理地域、保存・削除、社内の利用承認を確認してください。
出力だけ保存する場合は安全ですか？
出力に入力情報が再掲される可能性があります。出力も同じ分類とaccess controlの対象にします。一般的な安全利用はAIを安全に使う方法を参照してください。
まとめ
生成AIで個人情報を扱う前に、promptだけでなくfile、provider log、app log、feedback、backupまで含むデータフローを描きます。個人を識別する必要がないなら、入力前にfieldを削減・maskingしてください。
service・plan単位の契約と設定、保存・削除、access control、incident対応を確認し、未確認項目があれば処理を開始しません。AIの基本から確認したい場合は生成AI初心者ガイドも参考になります。