GDPRに対応した多言語PII検出
2026年更新版
GDPRの隠れたギャップ
GDPRには言語の優先順位がありません。第4条(1)は「個人データ」を、それが現れる言語への言及なしに定義しています。ドイツのSteuer-IDは米国の社会保障番号と同様に保護されます。フランスのNIRは英国の国民保険番号と同様に規制されています。
ほとんどのPII検出ツールは英語専用に構築されています。
ACL 2024の研究では、ハイブリッドNLPツールが欧州ロケールでF1スコア0.60〜0.83を達成することが示されました。英語専用ツールは、非英語の国別ID形式ではほぼゼロのスコアになります。そのギャップは深刻です。ツールは英語のPIIの95%を検出できます。しかし同じファイル内のドイツ語、フランス語、ポーランド語、またはオランダ語のPIIの40〜60%を見逃します。これは深刻な問題です。企業をリスクにさらします。
これは実際のGDPRギャップです。英語中心のリダクションツールを使用しているほぼすべてのグローバル企業に影響します。詳細については、GDPRガイドをご覧ください。
PIIがロケール固有である理由
PII検出には2つの部分があります。
最初はパターンベースの検出です。税番号や電話形式などの構造化IDをカバーします。
2番目はNERベースの検出です。名前や住所などの文脈的エンティティをカバーします。
両方の部分がロケールに依存しています。
構造化IDは国によって異なる
| 国 | 税ID | 形式 | 検証 |
|---|---|---|---|
| ドイツ | Steuer-ID | 11桁 | モジュロ11 |
| フランス | NIR | 15桁+2桁のキー | INSEE |
| スウェーデン | Personnummer | 10桁 | Luhn |
| ポーランド | PESEL | 11桁 | モジュロ10 |
| オランダ | BSN | 9桁 | Elfproef |
| スペイン | DNI/NIE | 8桁+文字 | モジュロ23 |
| イタリア | Codice Fiscale | 16文字 | カスタムチェックサム |
英語専用のSSN用正規表現（NNN-NN-NNNN）はこれらの形式のいずれにも一致しません。それぞれに独自の正規表現が必要です。それぞれに独自のチェックサムロジックも必要です。
NERにはネイティブモデルが必要
ドイツ語の名前は英語の名前と異なります。「Hans-Dieter Müller」はネイティブドイツ語モデルには明確です。英語でトレーニングされたモデルはそのような名前を見逃すことが多いです。
偽陽性も問題です。Microsoft Presidioのイシュートラッカーには、ドイツ語の単語が英語のPIIとして誤って分類されている例が記録されています。「Null」（ドイツ語でゼロ）という単語はその一例です。英語でトレーニングされたモデルで誤った名前検出を引き起こします。本番環境では、エラー率は実際のエンティティ1件につき偽陽性3件まで膨れ上がります（Alvaro et al., 2024）。
規制上のリスク
EUのデータ保護当局はこの問題を認識しています。複数の国家DPAがガイダンスを発行しています。
ドイツBfDI: GDPRの第5条(1)(f)はすべての記録に適用されます。サードパーティのツールで処理された非英語データもカバーします。
フランスCNIL: CNIL 2024年次報告書は懸念を表明しました。フランス語ロケールのPII検出なしにフランス語の記録を処理するAIツールを指摘しました。
EU DPA全体: GDPR第25条（プライバシー・バイ・デザイン）は、実際に処理されるデータに適した保護措置を要求しています。これにはグローバルな展開における非英語PIIが含まれます。
リスクは明確です。企業はGDPR監査で英語コンテンツのPII検出が95%であることを示せます。しかし同じツールでドイツ語、フランス語、ポーランド語の記録も扱っているなら、ギャップが現れます。監査人は気づきます。罰金が科される可能性があります。対応方法についてはセキュリティページをご覧ください。
3層アーキテクチャ
研究と実運用は、3層ハイブリッド設計が最善のアプローチであることで一致しています。
第1層: ネイティブspaCyモデル
spaCyは25のロケールに対してトレーニング済みモデルを提供します。ドイツ語、フランス語、スペイン語、ポルトガル語、イタリア語、オランダ語、ロシア語、中国語、日本語、韓国語、ポーランド語が含まれます。各モデルはネイティブテキストでトレーニングされます。各ロケールの構文とエンティティパターンを学習します。これは重要です。ネイティブトレーニングにより、より高い再現率と少ない偽陽性が実現します。
ドイツ語の場合: de_core_news_lgは複合名詞とドイツ語名前パターンを処理します。
フランス語の場合: fr_core_news_lgはフランス語エンティティ、タイトル、地名、組織を処理します。
ネイティブモデルは、高リソースロケールの名前検出において言語横断モデルを上回ります。
第2層: より多くのロケールのためのStanza
StanfordのStanzaライブラリはspaCyにないロケールをカバーします。クロアチア語、スロベニア語、ウクライナ語が含まれます。これにより、spaCyがカバーしていないEU話者グループへのリーチが拡大されます。Stanzaは無料でオープンソースです。残りのスタックとよく統合されます。
第3層: 広いリーチのためのXLM-RoBERTa
spaCyとStanzaがNERモデルを持たないロケールでは、XLM-RoBERTaがギャップを埋めます。100のロケールにわたるCommon Crawlテキストでトレーニングされています。PII検出において91.4%の言語横断F1を達成します（HuggingFace 2024）。コードスイッチングもうまく処理します。これは重要な機能です。ドキュメントが複数のロケールのテキストを含む場合に重要です。
多言語ボリュームに合わせたAPI呼び出しのスケーリングについては、トークンシステムドキュメントをご覧ください。
ロケール固有のエンティティタイプ
モデルだけでは不十分です。GDPRへの準拠には、国別IDのエンティティタイプのカバレッジも必要です。
国別EUの国民ID:
- DE: Steuer-ID, Sozialversicherungsnummer, Personalausweisnummer
- FR: NIR, SIREN, SIRET
- PL: PESEL, NIP, REGON
- NL: BSN
- SE: Personnummer, Samordningsnummer
- ES: DNI, NIE, NIF, CIF
- IT: Codice Fiscale, Partita IVA
電話形式: EU各国には固有のプレフィックス構造があります。+49、+33、+48にはそれぞれ独自の検証ロジックが必要です。
住所形式: 郵便番号は大きく異なります。ドイツのPLZは5桁を使用します。フランスのコードは5桁（01〜99の範囲）を使用します。英国の郵便番号は英数字です。スペインのコードは5桁（01000〜52999）を使用します。
実際のケース: スイスの製薬企業
スイスの企業が雇用契約を処理しています。各契約にはドイツ語、フランス語、英語のテキストが混在しています。スイスには4つの公用語があります。ツールはドイツ語のみ設定されていました。フランス語セクションのPIIをすべて見逃していました。
ジュネーブ在住の従業員の契約書には、フランス語のAVS番号（13桁）、スイスの銀行IBAN、フランス語形式の名前が含まれていました。ドイツ語のみのツールはフランス語形式の名前を見逃しました。フランス語のAVS番号を見つけられませんでした。ドイツ語のAHV-Nummer形式は異なります。IBANのみ部分的に検出されました。
3層アプローチはドキュメント全体を処理します。テキストセグメントごとにロケールを検出します。各部分に適切なNERモデルを適用します。正しい国固有のロジックで各国民IDを検証します。
混合ロケールドキュメント
最も難しいケースはドキュメント内でのロケール混在です。例:
- ドイツ人従業員の記録（名前、税ID）を含む、ドイツ企業の英語契約書
- 英語のプライバシー抜粋を含む、フランス語のGDPR同意フォーム
- エージェントが英語で返答し、顧客がアラビア語で書いているチャット
XLM-RoBERTaはこれをネイティブに処理します。明示的なロケール宣言は必要ありません。事前のセグメンテーションなしに混合ロケールテキストを処理します。これにより時間が節約されます。不正なスプリットによるエラーも防ぎます。
本番使用では、自動ロケール検出（文レベル）とXLM-RoBERTa推論の組み合わせが混合ロケールドキュメントを堅牢に処理します。
実践的なステップ
ツールのリーチを監査してください。 リダクションベンダーに特定のロケールのF1スコアを求めてください。「20言語をサポート」とは、ツールがまず機械翻訳を通じてテキストをルーティングすることを意味することが多いです。これはネイティブ検出ではありません。
記録をロケールにマッピングしてください。 ロケール分布を含む記録の調査を実施してください。英語70%、ドイツ語20%、フランス語10%のグローバル企業は異なるリスクに直面します。英語95%の企業とは状況が異なります。
国民IDサンプルでテストしてください。 業務に関連する国民ID（Steuer-ID、NIR、PESEL、BSNなど）の10例ずつのテストセットを作成してください。検出率を検証してください。完全なF1テストより速いです。
DPIAを見直してください。 ロケールスコープが含まれているか確認してください。英語のみの記録を想定した不完全なDPIAはアップデートが必要かもしれません。今すぐ行動してください。監査でギャップを発見するのを待わないでください。
エンティティタイプの完全な定義については、エンティティリファレンスとFAQを参照してください。プランとAPI呼び出し料金については、料金をご覧ください。
anonym.legalのPII検出エンジンは3層多言語アプローチを使用しています。ネイティブspaCyモデルで25の高リソースロケールをカバーします。Stanzaが追加のロケールリーチを提供します。XLM-RoBERTa言語横断トランスフォーマーがスコープを48ロケールに拡張します。すべてのEU加盟国の国別エンティティタイプが含まれています。