■ はじめに：生成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セキュリティ支援サービス