PII コンプライアンスにおけるマルチフォーマット問題
2026年版に更新済み
コンプライアンス担当者に、DSARの回答でどのフォーマットを匿名化するか聞いてみましょう。答えはいつも同じです。Wordの契約書、PDFの請求書、Excelの顧客データ、CSVのエクスポート、JSONのログです。
次に、どのツールを使うか聞いてみましょう。答えは大抵、3〜5種類の異なるツールです。各ツールはエンティティのカバレッジが異なります。設定も異なります。監査ログの形式も異なります。
これがフォーマットの断片化です。これは実際のコンプライアンスの欠陥を生み出します。
断片化が起きる理由
すべての本番フォーマットを同じ品質で処理できる単一のツールはありませんでした。各フォーマットに特化したツールが生まれました。PDFには一つ。スプレッドシートには一つ。CSVにはマクロ。それぞれが独自のエンティティリストを持っています。監査証跡を共有するものはありません。
結果は予測可能です。DSAR回答は複数のファイルタイプにまたがります。複数のツールが処理します。各ツールは異なる基準を使います。エンティティXはPDFで検出されますが、Excelファイルでは見逃されます。DPAの監査はこの不整合を明らかにします。
フォーマット固有の技術的課題
各フォーマットは独自の検出問題を生み出します。
PDFには2種類あります。ネイティブテキストと画像ベースのスキャンです。スキャンされたPDFはまずOCRが必要です。OCRはエラーを引き起こします。ネイティブPDFは各単語を別々のテキストオブジェクトとして保存することが多いです。これにより単語の境界をまたぐエンティティ検出が中断されます。多段組レイアウトは分析前に読み取り順序の再構築が必要です。
Word (DOCX)
DOCXファイルはXMLにテキストを保存します。しかしヘッダー、フッター、コメント、変更履歴、テキストボックスにも存在します。ページヘッダーのレターヘッドアドレスはPIIです。ほとんどのツールはこれを見逃します。変更履歴には削除されたPIIが含まれていることがあります。そのテキストはレンダリングされた表示では見えませんが、ファイルには存在します。
Excel (XLSX)
Excelは何百もの列と何千もの行の任意のセルにPIIを保存します。「SSN」や「Email」などの列ヘッダーは、NERモデルが生のテキストから得られないコンテキストを提供します。日付やSSNは数値として保存されることが多いです。「マネージャーメモ」などの自由テキストフィールドには非構造化PIIが含まれます。列ベースのツールはこれらのフィールドをスキップします。
CSV
CSVにはExcelの構造がありません。「メモ」列の自由テキストフィールドはPIIと他のコンテンツが混在します。エンコーディングの問題（UTF-8対Latin-1）により、欧州の名前や住所の非ASCII文字で検出が失敗します。
JSON
ネストされたJSONはPIIを深くに埋め込みます（user.address.street.line1）。配列はイテレーションが必要です。同じフィールド名が異なるオブジェクトで異なるデータ型を持つことがあります。良い検出にはスキーマの認識とコンテンツ分析の両方が必要です。
不整合は法的リスクです
GDPRのDSARの具体的なシナリオを見てみましょう。
データ主体が自分に関するすべての個人データを要求します。コンプライアンスチームはこれらのファイルを見つけます。
- Word文書3件（契約書、往来書簡）
- PDF文書2件（請求書、サポート記録）
- Excelスプレッドシート1件（顧客アカウントデータ）
- CSVエクスポート1件（システムアクセスログ）
PDFにはツールA。WordにはツールB。XLSXにはマクロ。CSVには手動レビュー。各ツールはエンティティのカバレッジが異なります。
データ主体は匿名化されたパッケージを受け取ります。Excelの「マネージャーメモ」列は処理されていませんでした。Wordのレターヘッドアドレスは見逃されていました。どちらもデータ主体が匿名化を要求したPIIを含んでいます。
GDPRの第15条（アクセス権）または第17条（削除権）の下で、これは不完全なDSAR回答です。データ主体または規制当局が欠陥を発見した場合、不整合なツールの使用は記録された原因の一つとなります。
一貫した基準の必要性
堅固なDSARコンプライアンスは、どのPIIタイプを匿名化するかを列挙するだけではありません。回答セットのすべてのフォーマットに同じ基準が必要です。
それはつまり：
- Word、PDF、Excel、CSV、JSONで同じエンティティタイプを確認する。
- すべてのファイルに同じ信頼度しきい値を適用する。
- 同じ置換トークンを使用する。「田中一郎」が3つの文書に現れる場合、一つのトークンがすべての3つでその名前を置換する。
- すべてのフォーマットをカバーする一つの監査証跡。
単一プラットフォームのソリューションはプリセットを通じてこれを可能にします。一つの「DSAR EU Individuals」プリセットが同じ32種類のエンティティタイプを確認します。PDF契約書、Excelレコード、CSVログで実行されます。同じエンジンがすべてを処理します。
バッチジョブでのプリセットの動作については、GDPRのDSARバッチ処理のガイドをご覧ください。
混在フォーマットセットのバッチ処理
大規模なDSARコンプライアンスは、混在フォーマットのフォルダを一つの単位として処理することを意味します。
入力： 一人のデータ主体に関するすべてのデータを含む15ファイルのフォルダ（PDF、DOCX、XLSX、CSV）。
処理ステップ：
- 各ファイルのフォーマットを検出する。
- 適切なパーサーを適用する。PDFテキスト抽出。DOCX XML解析。XLSXセルのイテレーション。CSVフィールド解析。
- すべてのファイルから抽出されたテキストに同じNLPパイプラインを実行する。
- バッチ内のすべてのファイルに同じプリセットを適用する。
- 共有トークンプールを使用する。15ファイル全体で同じ名前が同じ置換トークンを受け取る。
出力：
- 元のフォーマットで15ファイルすべての匿名化バージョン。
- クロスフォーマット監査レポート一件。検出されたすべてのエンティティ、そのソースドキュメント、信頼度スコア、実施されたアクションを示します。
その監査レポートがコンプライアンス文書です。15ファイルすべてが同じ基準で処理されたことを証明します。DPA監査では、断片的なツールよりはるかに強力です。
統合パイプラインの既知の制限
フォーマットの統合は断片化を解決します。しかし独自の制約をもたらします。
変換の忠実度： DOCXを処理フォーマットに変換して戻すと、変更履歴が失われたり、埋め込みオブジェクトが破損したりする可能性があります。法的文書は処理後に追加の検証が必要です。
フォーマット別のメンテナンス： 構造化CSVのエンティティ認識機能はスキャンされたフォームのものとは異なります。「統合された」パイプラインでもフォーマット別の前処理が必要です。その前処理はフォーマットの進化に合わせて更新が必要です。
一般的でないフォーマットの精度： ほとんどのNLPモデルはWebテキストと一般的なオフィス文書でトレーニングされています。レガシーフォーマット（古いEDIファイル、カスタムXMLスキーマ、CADメタデータ）はベンチマークが示すよりも検出精度が低くなることがよくあります。
再構築できないフォーマット： 一部のPDFタイプと画像のみのファイルはその場で匿名化できません。ビジュアル編集が必要です。ビジュアル編集は機械可読構造を破壊します。匿名化後の検索やインデックス作成が必要な場合、これでは不十分な場合があります。
実践的なDSARワークフロー
定期的なDSARボリュームを持つコンプライアンスチームの場合：
- データ主体のすべての文書を収集する
- DSARバッチを作成する（フォーマットに関係なくすべてのファイルをドラッグする）
- 「DSAR EU Individuals」プリセットを選択する
- バッチを実行する
- 匿名化された出力と統合監査レポートをダウンロードする
- 出力から2〜3件の文書をスポットチェックする
- データ主体への回答のために匿名化文書をパッケージ化する
- 監査レポートをDSARケースレコードに添付する
ステップ1（手動収集）が主な時間コストです。ステップ2〜8は典型的なバッチで10分以内です。ステップ5の監査レポートはGDPRの説明責任の原則を満たします。
anonym.legalはDOCX、PDF、XLSX、CSV、JSONを処理します。すべてのファイルは同じプリセットを使用します。一つの監査レポートがバッチ全体をカバーします。