準個人情報（Quasi-PII）とは
GDPRの第4条は、人を特定できるあらゆるデータを対象としています。データが直接誰かを名指しする必要はありません。追加の手順を経て特定が可能であれば十分です。
社内従業員IDはその典型例です。「EMP-EU-123456」という値を考えてみましょう。この文字列だけでは誰も特定できません。しかしHRシステムには単純な対応表があります。EMP-EU-123456はミュンヘンのシニアエンジニア、マリア・シュミットを指しています。その表にアクセスできる人なら誰でも彼女を特定できます。GDPRのもとでは、このIDは個人データです。
同じルールが他の社内コードにも適用されます：
- CRMレコードに紐づく顧客アカウント番号
- 契約システムでクライアント名に紐づくプロジェクトコード
- 法的ファイル内の案件参照番号
- 患者記録に紐づく医療記録番号
氏名やメールアドレスを削除するだけでは不十分です。社内IDがファイルに残っていれば、再識別はわずか2ステップで可能です。
なぜこのギャップが罰金につながるのか
**GDPRの罰金の34%は第32条に基づく不十分な技術的措置に関係しています。**この数字はDLA Piperの2025年GDPRアニュアルレポートからの引用です。準識別性を持つ社内識別子の検出失敗はこのカテゴリに該当します。
EDPBは2024年に900件以上の一貫性メカニズム案件を処理しました。国境を越えた執行により、共有データセットの1つのギャップが複数のEU加盟国での協調行動を引き起こす可能性があります。
標準的なPIIツールは普遍的なパターンを検出します：氏名、メール、電話番号、国民ID。あなたの社内ID形式は認識しません。設定するまで、どのツールも認識できません。それがギャップです。
ノーコードパターンビルダーの仕組み
ある世界的な物流会社が外部監査に向けて従業員記録を匿名化する必要があります。従業員IDはEMP-[地域]-[6桁]の形式です。例：EMP-EU-123456、EMP-APAC-789012、EMP-AMER-345678。
コンプライアンスチームがAIパターンヘルパーに3つの例を入力します。AIは以下を返します：
- パターン：
EMP-[A-Z]{2,4}-\d{6} - 提供した3つの例すべてに一致
- 推奨エンティティ名：EMPLOYEE-ID
- 推奨次のステップ：他の地域コードでテスト
チームはさらに10個のサンプルでテストします。パターンはすべてで機能します。
カスタムエンティティをチームの共有GDPRプリセットに保存します。監査パッケージの47件の文書が一括処理されます。すべての従業員IDが役割ベースのラベルに置き換えられます。監査会社は、いかなる社内データベースとも個人を紐づけられないファイルを受け取ります。
エンジニアリングの助けは不要です。設定全体が1時間以内に完了します。
その後の流れ
カスタムエンティティを共有プリセットに保存すると、チームの全員が同じ設定を使います。新しいスタッフは初日から同じ設定を受け取ります。バッチ処理、APIコール、手動アップロードがすべて同じパターンを適用します。
監査ログには各ファイルにどのプリセットが使用されたかが記録されます。データ保護当局が証拠を求めた場合、提示できます。
カスタムエンティティのセットアップの完全なワークフローについては、組織の匿名化のためのカスタムPII識別子をご覧ください。チーム全体で一貫した設定を維持するには、GDPR監査のための匿名化プリセットをご参照ください。