個人情報をLLMに渡さない — マスキングの実務と限界

機械的に検出できるもの

• 氏名（人名辞書・固有表現抽出）
• 電話番号・メールアドレス（パターン）
• 住所（パターン＋地名辞書）
• マイナンバー・クレジットカード番号（桁数と検査数字）
• 生年月日（日付パターン）

この範囲は既存のツールで概ね検出できる。ただし日本語では氏名の検出が難しく、一般名詞と同じ表記の姓（本田、金子など）が漏れたり、逆に過剰に伏せられたりする。

問題はこちらである。個別には個人情報でないが、組み合わせると特定できる記述。

• 「営業2部の部長」（組織内では1人に特定できる）
• 「先週入社した方」（日付と組織の組み合わせ）
• 「〇〇社との案件を担当していた」（取引記録から特定可能）
• 「同じ病気で3ヶ月休んでいた」（要配慮個人情報に該当しうる)

これらは文脈依存なので、パターンマッチでは拾えない。人が読んで判断するか、そもそもこの種の記述を含む文書をLLMに渡さない運用にする。

現実的な線引き

完全なマスキングを目指すと終わらない。実務では、対象を分けて扱う。

マスキングの戻し方

マスキングした状態でLLMに処理させ、結果を受け取ってから元の値に戻す構成にする。この対応表は自分の環境に持ち、LLM側には渡さない。

置換は一意にする。同じ人物を常に「人物A」にすれば、文脈が保たれて出力の品質が落ちにくい。すべて「[氏名]」にすると、誰が誰の話か分からなくなる。

ゼロ保持の確認

マスキングの手間を減らす方向として、提供元との契約でデータを学習に使わないこと、保持しないことを確認する方法がある。ただしこれは「渡していない」ことにはならないので、個人情報保護法上の第三者提供や外国への移転の論点は別に検討する。

よくある質問

Q. ローカルで動かせば不要ですか。

A. 外部提供の論点は消えますが、社内でのアクセス権限の問題は残ります。人事データを全社員が参照できる構成になっていないかを確認してください。