SSN以外の個人情報：組織内部IDの匿名化
GDPRツールはメールアドレスを削除します。電話番号も削除します。名前も削除します。サポートチケットのエクスポートをツールにかけます。その後、結果をアナリティクスチームと共有します。
しかし、顧客アカウント番号はすべてのチケットに残ったままです。注文IDも残っています。内部ユーザーIDも同様です。
これらのIDは単独では無害に見えます。参照テーブルがなければ、個人を特定できません。しかし、アナリティクスチームにはそのテーブルがあります。CRMにもあります。サポートデータベースにもあります。アクセス権のある人なら、数秒で個人を特定できます。
これはGDPRの仮名化の失敗です。ツールが壊れたのではありません。ツールに対して、あなたのIDを探すよう設定されていなかっただけです。
標準的なPIIツールが検出するもの
標準的なPIIツールは、汎用的なフォーマットをカバーしています。どの組織でも使われているものを検出します。
標準ツールが検出するもの：
- 社会保障番号（米国SSN、英国NINO、EU各国のIDフォーマット）
- メールアドレス
- 電話番号
- クレジットカード番号
- 氏名
- パスポートおよび運転免許証番号
標準ツールが検出しないもの：
- EMP-XXXXX形式の従業員ID
- ACC-XXXXXXXX-XX形式の顧客アカウント番号
- ORD-XXXXXXX形式の注文ID
- UUIDまたはカスタム形式の内部ユーザーID
- パートナー固有の参照コード
標準ツールは汎用パターンを見つけます。組織内部のIDは汎用的ではありません。検出されるには、カスタム設定が必要です。
再識別リスク
ある企業が品質レビューのためにサポートチケットをエクスポートします。標準的なPII除去で名前・メール・電話番号が削除されます。ACC-XXXXXXXX-XX形式のアカウント番号は処理されません。
エクスポートデータはアナリティクスチームへ渡ります。アナリストがアカウント番号でチケットテーブルと顧客データベースを結合します。個人はすぐに特定されます。特別な技術は不要です。通常のSQL結合です。
GDPRの第4条第5項は仮名化を「追加情報なしには特定の個人に帰属させることができないよう処理すること」と定義しています。アカウント番号はこのテストに合格しません。追加情報（顧客データベース）は組織の中にすぐあります。
「匿名化された」エクスポートは、匿名ではありませんでした。
カスタムエンティティパターンの作成
カスタムエンティティの設定は素早くできます。コンプライアンスチームはエンジニアリングの助けなしに行えます。
ステップ1：IDフォーマットを一覧化する。
各フォーマットを書き出します。例：アカウントACC-XXXXXXXX-XX、注文ORD-XXXXXXX、従業員EMP-XXXXX。
ステップ2：フォーマットをわかりやすい言葉で説明する。
「アカウント番号はACCで始まり、次にダッシュ、8桁の数字、ダッシュ、2つの大文字アルファベット。」
AIによるパターン生成が返す結果：ACC-\d{8}-[A-Z]{2}
ステップ3：サンプルデータでテストする。
20〜30件のドキュメントをアップロードします。すべての件が検出されることを確認します。誤検知がないことを確認します。
ステップ4：手法を選ぶ。
分析でレコードを紐付ける結合キーとして使われるIDの場合：
- 仮名化する。 ACC-00123456-ABを毎回ACC-99876543-XYに置き換えます。同じ入力は常に同じ出力を返します。結合は引き続き機能します。元の値はキーなしでは復元できません。
分析に不要なIDの場合：
- 削除する。 **[REDACTED]**に置き換えます。シンプル。不可逆的。
ステップ5：共有プリセットとして保存する。
カスタムエンティティ（または複数）を共有プリセットに保存します。設定はすべての処理に適用されます：バッチアップロード、API呼び出し、ブラウザインターフェース。新しいチームメンバーはすぐに完全な設定を使えます。
事例紹介：18万件のサポートチケット
ある企業がアナリティクスウェアハウスに18万件のサポートチケットを発見しました。名前とメールは削除されていました。アカウント番号は削除されていませんでした。各チケットにはACC-XXXXXXXX-XXの値が残ったままでした。
解決のタイムライン：
- コンプライアンス担当者がACCパターンを定義 — 15分
- 30件のサンプルチケットでテスト — 20分
- 精度を確認 — 10分
- 18万件を夜間バッチで処理
- ウェアハウスのテーブルをクリーン版に差し替え
コンプライアンス担当者の合計時間：45分。カスタムエンティティのサポートがなければ、エンジニアリングチケット・コードレビュー・デプロイが必要でした。それは数週間かかります。
カスタムIDがAIサポートツールでどのようなリスクを生むかは、GDPRとサポートAIガイドを参照してください。
内部IDが広がる場所
内部IDは、ほとんどのチームが想定するよりも多くの場所に現れます。
社内文書：
- アカウント番号や注文IDが含まれる会議メモ
- 顧客案件に関するメールのやり取り
- 事例データを含むプレゼンテーション
第三者との共有：
- 参照番号を含む規制当局への報告書
- 顧客参照が含まれる監査書類
- 顧客IDを持つ取引先ファイル
調査・分析：
- カスタマージャーニーのデータセット
- サポート品質レビューのエクスポート
- 社内MLモデルのトレーニングデータ
どのコンテキストでも、真に匿名なデータを生成するには、同じカスタムエンティティ設定が必要です。
仮名化と匿名化の違い
GDPRは明確な線引きをしています。
仮名化はIDを代替値に置き換えます。参照テーブルを持つ人が再度個人を特定できます。このデータは依然として個人データです。リスクは低下します。しかし、GDPRの義務はなくなりません。
匿名化は再識別の可能性を排除します。匿名データは個人データではありません。GDPRは適用されません。
参照テーブルが存在する場合、アカウント番号と注文IDは仮名です。固定の代替値に置き換えてもリスクは低下しますが、GDPRは引き続き適用されます。ランダムトークンに置き換え（キーを削除）するとGDPRの義務はなくなりますが、結合ベースの分析は機能しなくなります。
参照テーブルを持たない第三者への共有には、仮名化で十分な場合があります。社内分析には、完全な匿名化または厳格なアクセス管理が必要です。法令遵守ガイドでは、処理記録に向けた各アプローチの文書化方法を解説しています。
まとめ
このギャップはツールの失敗ではありません。設定のギャップです。あなたのアカウント番号フォーマットを教えない限り、どのツールも知ることができません。
カスタムエンティティの設定で、数時間でギャップを埋められます。コンプライアンスチームがフォーマットを定義し、サンプルデータでテストし、すべての処理モードに適用します。エンジニアリングのサポートは不要です。
削除されていなかった18万件のアカウント番号は、ツールが失敗したから残っていたのではありません。ツールに探すよう設定されていなかっただけです。