■ はじめに：生成AI時代の「個人情報リスク」は“人の操作”では防げない
生成AIが業務に入り込むと、次のようなシーンはあっという間に発生します。
・ユーザーがチャットにうっかり名前を書いてしまう
・FAQボットが社内文書の人名をそのまま回答
・問い合わせログに個人情報がそのまま記録されている
こうした“意図せぬ漏洩”が増えていることから、各国のガイドラインでは 「PIIは人の注意に頼らず、自動マスキングすべし」 という流れが明確になりつつあります。
本記事では、生成AIアプリケーションに必須となる 入力・出力・ログの3段階で行うPIIマスキングの実務パターン を整理します。
1. PIIマスキングが必要な理由
PII（Personally Identifiable Information）は以下を含む情報です：
- 氏名
- 住所・電話番号・メール
- 生年月日
- アカウントID
- 組織名＋役職名の組み合わせ など
これらが LLM にそのまま渡ると、次のようなリスクが発生します。
◆ ① 外部サービスに送信される（クラウドリスク）
匿名化せずに送れば、クラウドに“痕跡”が残る可能性があります。
◆ ② モデル出力による“逆漏洩”
モデルが後の質問に応じて、うっかり再生成してしまうことがある。
◆ ③ ログ・監査データに残り続ける
もっとも多い事故は「ログにPIIが残っていた」ケース。
これらを避けるための現実的な解決策が “入力・出力・ログの三段階マスキング” です。
2. 入力データのマスキング（User → Model）
もっとも重要なのが “LLMに渡す前の段階で削る” という考え方です。
◆ 実装方式
以下の3レイヤを併用すると精度が上がります。
① 正規表現（Regex）による確定パターン検知
電話番号、メールアドレス、郵便番号などはRegexでほぼ確実に検知できます。
例：
-
\d{2,4}-\d{2,4}-\d{3,4}（電話番号） -
[a-zA-Z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}（メール）
→ マッチした箇所を <PHONE> や <EMAIL> に置換。
② 辞書ベース＋ルールベース人名検出
人名はパターンが多いため、
- 日本人名辞書
- 組織内名簿（Hash化）
- 役職辞書
を併用して検知します。
③ NLP（NERモデル）による文脈ベース判定
2024–2025は NER（固有表現抽出）モデルの精度が向上し、「氏名らしき単語」「住所らしいフレーズ」などの判定が容易に。
Azure AI Language / HuggingFace モデルなどが利用可能。
◆ 変換パターン
- 氏名 →
<NAME> - メール →
<EMAIL> - 住所 → 「東京都＊＊区」
- 取引先名 → 「A社（伏せ字）」
“特定できない表現” に変換するのが重要。
3. 出力データのマスキング（Model → User）
モデルは、意図せずPIIを再生成することがあります。
◆ よくあるパターン
- RAGで取り込んだ社内文書の人名をそのまま出す
- ハルシネーションで実在人物名を生成
- 問い合わせ内容から特定できる情報を補完
そのため、結果をユーザーに返す前の“出口フィルタ” が必須になります。
◆ マスキングの例
① 伏字化
- 「鈴木太郎 → 鈴木＊＊」
- 「東京都渋谷区 → 東京都＊＊区」
② 汎化（generalization）
- 「営業部の佐藤 → 担当者」
- 「〇〇様 → お客様」
③ 削除（必要に応じて）
- 住所やIDは一律削除
- 不要なPIIが含まれる段落そのものを除外
◆ RAGとの併用
RAG + LLM の構成では、検索結果（chunks）にPIIが入っているため、 RAG側のデータ整備（前処理マスキング） も合わせて必要です。
4. ログのマスキング（Audit / Tracing）
忘れられがちですが、最も事故が起きやすいのはログです。
◆ ログで起きがちな事故
- 会話ログに生の個人情報が残っていた
- トレーシング（OpenTelemetry）に住所が記録されていた
- セキュリティ担当が閲覧可能な状態で数ヶ月放置
◆ 実装のポイント
- ログ保存前にマスキングフィルターを適用
- 入力と出力と同じマスキングルールを使う
- どうしても必要な場合は暗号化・Tokenization
- 監査権限を分離（最小権限化）
“開発者が見ているログにPIIが残っていた”という事故が2024〜2025で多発しています。ログマスキングはガバナンスの必須項目です。
5. 多層マスキングの実装アーキテクチャ（最新傾向）
2025年時点では、以下の構成がベストプラクティスになりつつあります。
User Input
↓（PII検出・置換）
Input Masking Layer
↓
LLM / RAG Engine
↓（出力マスキング）
Output Filtering Layer
↓
User Output
↓（マスクして保存）
Log Storage (PII-redacted)
◆ 特徴
- “3段階すべてマスクする”ことで漏えいリスクを最小化
- 検出器は Regex＋辞書＋NER のハイブリッド方式
- マスキングルールを1箇所に集約し、再利用性を高める
- Azure AI Content Safety や AWS Guardrails と組み合わせる企業が増加
まとめ：PIIマスキングは AI ガバナンスの“第一関門”
生成AIを業務利用する企業では、 PIIマスキングは“導入前に必ず整備すべき基盤” と言えます。
- 入力で守る（LLMに渡さない）
- 出力で守る（ユーザーに返さない）
- ログで守る（後に残さない）
この3つを仕組み化することで、事故がほぼゼロに近づき、AI活用が一段と進みます。
本記事は、ナレッジコミュニケーションによる生成AIセキュリティ支援の実務知見をもとに執筆しています。
安全にAIを活用するための導入支援・運用設計をご希望の方は、ぜひご相談ください。
👉 AIセキュリティ支援サービス