「個人情報はAI禁止」で止まっている組織へ
生成AI（文章や画像などを作り出すAI）の社内導入でいちばん多い足止めが、「個人情報を含む業務では使えない」という一文です。安全側に倒した判断として理解できますが、問い合わせ対応・採用・人事・営業記録・医療や士業の実務など、個人情報が関わらない業務のほうがむしろ少数です。結果として「禁止だが現場は個人のスマホで使っている」という、最悪の状態に落ち着きがちです。
本当に必要なのは禁止か許可かの二択ではなく、どこまでなら入れてよいかの線引きと、入れた後の記録です。この記事では、法令の建て付けを踏まえつつ、明日から着手できる最低限の設計を具体的に書きます。
まず押さえる用語と、データの分類
日本の個人情報の保護に関する法律（個人情報保護法）は、似た言葉を細かく区別しています。ここを曖昧にしたまま社内ルールを作ると、必ず運用が破綻します。
| 用語 | かみ砕いた説明 | AI利用での注意 |
|---|---|---|
| 個人情報 | 生存する個人を特定できる情報。氏名、顔写真、他の情報と照合して特定できるものを含む | 「氏名を消せば個人情報ではない」は誤り。社員番号や顧客IDでも照合可能なら該当しうる |
| 個人データ | データベース化され検索できる状態の個人情報 | 安全管理措置や第三者提供の制限は、主にここにかかる |
| 要配慮個人情報 | 病歴、障害、犯罪歴、人種、信条など、取扱いに特に配慮を要するもの | 取得に原則本人同意が必要。健康診断結果や休職理由の要約などは扱いを別枠にする |
| 仮名加工情報 | 他の情報と照合しない限り特定できないよう加工したもの | 社内分析の自由度は上がるが、第三者提供は原則不可 |
| 匿名加工情報 | 特定も復元もできないよう加工したもの | 加工基準や公表義務があり、「なんとなく伏せ字」では該当しない |
設計の第一歩は、この区分を自社の実データに当てはめた一覧表を作ることです。「顧客問い合わせメール全文＝個人データ」「商談メモ＝個人情報を含みうる」「製品マニュアル＝非該当」といった粒度で十分です。この一枚があるだけで、現場の判断が揃います。
AIサービスへの入力は「第三者提供」なのか
実務でよく論点になるのが、クラウド型のAIサービスに個人データを入力する行為の位置づけです。個人情報保護委員会は、クラウドサービス提供者が当該個人データを取り扱わないこととなっている場合（契約上そう定められ、適切にアクセス制御されている等）には第三者提供に該当しないという考え方を、Q&Aの形で示しています。いわゆる「クラウド例外」と呼ばれる整理です。
ここから導かれる実務上のポイントは次の通りです。
- 利用規約と契約の確認が先、ツール選定は後。入力データを提供者側が学習や改善に利用する設定になっていないか、オプトアウト（利用しない設定）が可能かを確認する
- 同じ提供者でも、一般向けのチャット画面と、APIや法人向けプランでは扱いが異なることがある。社内で許可するのは後者に限る、という線引きは現実的
- 提供者がデータを取り扱う前提のサービスなら、委託として委託先の監督義務が生じる。再委託先まで把握できるかを見る
- サーバーが国外にある場合、個人情報保護法の外国にある第三者への提供に関する規律や、安全管理措置の一つである外的環境の把握（所在国の制度を踏まえた対応）を検討する必要がある
なお、EUの一般データ保護規則（GDPR）や、EUで成立した人工知能に関する規則（EU AI Act、いわゆるEU AI法）は、域内の個人データや域内向けサービスに関わる場合に影響します。海外拠点や越境サービスがある企業は、国内法だけで完結しない点を前提に設計してください。詳細な適用時期や条文は、必ず原文と公的な解説で確認することをおすすめします。
最低限の設計：5つの決めごと
ここからが本題です。完璧な規程を作る前に、以下の5点だけ決めれば運用は始められます。
1. 入力前の最小化を既定にする
AIに渡すのはタスクに必要な最小限。氏名・住所・電話番号・口座番号・顧客IDは、原則として置換してから渡します。たとえば次のような場面です。クレーム対応メールの要約をAIに頼むとき、氏名を「顧客A」、住所を「〇〇県内」に置き換えたテキストを渡す。要約の精度はほとんど落ちませんが、万一ログが外部に残っても被害は段違いに小さくなります。
手作業に頼らず、置換を前処理の仕組みにしておくのがコツです。正規表現で電話番号やメールアドレスを検出して伏せるスクリプト、あるいは社内ツールのフォーム側で該当欄を送信対象外にする設計で足ります。
2. 利用目的を特定し、AI利用を目的の範囲に収める
個人情報保護法は利用目的の特定と、目的の範囲を超えた取扱いの制限を定めています。「問い合わせ対応のために取得した情報を、AIで営業リスト作成に使う」といった転用は、目的外利用になりうる典型です。プライバシーポリシーの記載と実際のAI利用がずれていないかを、導入前に照合してください。
3. 用途ごとに「可・条件付き可・不可」を決める
全社一律のルールは守られません。業務単位で表にします。
| 区分 | 例 | 運用 |
|---|---|---|
| 可 | 公開情報の要約、文章校正、社内マニュアル作成 | 自由利用。承認不要 |
| 条件付き可 | 問い合わせ対応文の下書き、議事録要約 | 仮名化・マスキング後に限る。指定ツールのみ |
| 不可 | 要配慮個人情報、採用の合否決定そのもの、与信の最終判断 | AIへの入力・AIによる決定を禁止。人が判断 |
4. 人間の確認を挟む工程を明文化する
個人に不利益が生じうる判断（採否、取引可否、契約解除など）をAIの出力だけで確定させないこと。AIは候補出しや整理までとし、決定は人が行い、その記録を残す。これは法令対応であると同時に、誤り（もっともらしい嘘を生成するハルシネーション）への実務的な防御でもあります。
5. ログ・保存期間・事故時の手順を先に決める
誰が・いつ・どのツールに・どんな種類のデータを入れたかの記録がないと、漏えいの疑いが生じたときに影響範囲を特定できません。個人情報保護法では、一定の漏えい等が生じた場合に個人情報保護委員会への報告と本人への通知が求められる場面があります。報告要否を判断するのは事故発生後ですが、判断材料を用意するのは平時の設計です。
明日からできる三つの着手
- データ分類表を1枚作る：自社で扱う主要なデータを10〜20行書き出し、個人情報か、要配慮か、AI入力の可否を埋める。30分で初版はできます
- 入力禁止リストを掲示する：マイナンバー、口座情報、健康情報、未公表の取引条件など、具体的な項目名で列挙する。「機密情報」といった抽象語だけでは機能しません
- 使っているAIサービスの設定を確認する：入力データの学習利用の有無、オプトアウトの可否、ログ保持期間、データの所在国。確認日と結果をスプレッドシートに残し、半年ごとに見直す
加えて、シャドーIT（会社が把握していないツールの私的利用）対策として、「申請すれば使える安全な選択肢」を先に用意することが効果的です。禁止だけを強めると利用は地下に潜り、ログが一切残らない状態になります。
まとめ
個人情報を含む業務でAIを使うための最低限の設計は、難解な法解釈ではなく、次の積み重ねです。
- データを分類し、何が個人データかを社内で共有する
- 入力前にマスキング・仮名化を既定の手順にする
- 利用目的の範囲内か、プライバシーポリシーと照合する
- 用途ごとに可・条件付き可・不可を表で示す
- 重要な判断は人が行い、記録を残す
法令の具体的な要件や解釈は、個人情報保護委員会が公表しているガイドラインおよびQ&A、生成AIの利用に関する注意喚起などの一次情報で必ず確認してください。本記事は実務設計の見取り図であり、個別の適法性判断は、自社の契約内容とデータの性質を踏まえて専門家とともに行う必要があります。
それでも、最初の一歩は重くありません。データ分類表と入力禁止リストの2枚。これだけで、「禁止」で止まっていた議論は「どう安全に使うか」に変わります。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
