第8章 — RAGパイプラインにおけるデータ匿名化
LLM Primer III: RAGで強化するエンタープライズAI を章ごとに紹介していくウォークスルー、第8回です。データはモデルが見る前に匿名化するのか、それともユーザーが出力を見る前にするのか。答えはパイプラインのすべてを変えますし、規制レジームがその答えをこちらの代わりに選ぶことが多くあります。
この章がなぜあるのか
第7章は 誰が 何を 見られるかに答えました。ゲートをかけるべき何かがあることを前提にしていました。けれど第6章は、埋め込みが一方向関数ではないことも示しました — ベクトルストアはソースのぼやけたコピーであり、アクセス制御はあくまで外側の層です。コーパスに社会保障番号、診療記録、顧客名、専有のコードパスが含まれているなら、問いは「誰が引き出せるか」だけではありません。そもそもその形で埋め込んでよかったのか、です。
それが匿名化の問いで、RAG 展開でいちばん工学的に重いセキュリティ判断です。選択はアルゴリズムである前に「位置」の問題です — 機微な内容がどの段で変換されるのか。
8.1 生成前 vs 生成後
生成前 匿名化は、埋め込まれて保存される前にデータを変換します。ベクトルストアは元の機微値を含まず、モデル層を全面的に侵害されても、そこになかったものは取り出せません。HIPAA 対象の医療RAG や、GDPR が課される法務系の多くで指定されるアーキテクチャです。代償は検索品質: クエリは「Acme Corp」と言うのに、コーパスは埋め込み前に「[ORG_47]」になっていて、もっとも情報量の高いトークンで密類似度が落ちます。
生成後 匿名化はモデルの出力に対して動きます。検索品質は保たれ、プライバシー保証は弱くなる — 機微データがインデックス内に残るからです。脅威モデルがユーザー向け漏洩のほうでインフラ向け漏洩ではないなら適切です。本番のほとんどは ハイブリッド に落ち着きます — 直接識別子と規制重みの高いカテゴリは生成前で扱い、より軽い運用上の機微はユーザーの認可プロファイルに応じて出力でマスクする。実装規律が2つ重要です: 匿名化はチャンキングの前に走らせる(後ろだと、チャンカーが検出器の必要な文脈を壊します)。そして 脱トークン化ボールト を別の、アクセス制御された対応表として保ち、適切なロールを持つ医師がインデックスのマスクした患者識別子をなお見られるようにする。
8.2 マスキング、合成置換、差分プライバシー
技法は単一のダイヤル上の3つの族に分かれます。PII マスキング はエンティティを検出し(OSS でもっとも展開されているのは Microsoft Presidio)、プレースホルダで置き換えます。難しい問題は再現率 — 10% の名前を取りこぼす検出器は、攻撃者が埋め込み類似度で見つけられる伏字文書を作ります — と過剰マスキングで、語彙を潰して検索を傷つけます。規律は二重計測です: ラベル集合に対する再現率と、オフラインの検索品質ベンチマーク。
合成置換 はプレースホルダではなく、もっともらしい偽値で置きます — 「John Smith」は [NAME] ではなく「Alex Romano」になる。埋め込みはよく分布したままで、モデルにも自然に読めます。対応は決定的 — 実エンティティから偽値への鍵付きハッシュ — で、同じ実体はコーパス全体で同じ偽値になり、鍵はボールトに棲みます。合成置換も補助情報を持つ敵対者には漏れますが、検索品質が重要な場面ではマスキングからの意味のある改善です。
差分プライバシー は、本物の数学的保証を提供する族です — メカニズムが ε-DP であるとは、どの1レコードを足し引きしても出力分布が exp(ε) 倍以内にしか変わらないこと。DP-Prompt はプロンプトに選ばれたチャンクを撹乱、DP-MLM はマスク言語モデルの埋め込みパスを撹乱、1-Diffractor は DP と意味保持書き換えを組み合わせます。DP はスイッチではなく予算で、各クエリが少しずつ消費します。運用規律はおもに予算管理です。3つの族は合成可能で、適切な展開ではたいてい重ねます。
8.3 有用性とプライバシーのトレードオフ
もっとも匿名化する価値のあるトークンは、匿名化することで検索をもっとも傷つけるトークンです。この非対称は不本意ですが、交渉できません。緩和は部分的です: 合成置換はプレースホルダより信号を残し、型タグ付きプレースホルダ([PERSON named Alex] vs [PERSON])はさらに残しますが、マスキングは弱くなります。匿名化したコーパスは、しなかったコーパスより少し大きめのチャンクが向く傾向にあります — マスキング損失が、残った内容のなかでより薄まるからです。
誠実な構図は、トレードオフが単一軸のダイヤルではなく、2次元の面だ、ということです — システムが違法になる規制の床、ユーザーが見限る有用性の床、両者の間の動作領域。差が広いことも狭いこともあり、空のこともある。空のときは、規制の床が有用性の床の上にあり、設計フェーズでいちばん価値があるのは、建てられないシステムに労力を投入する前にそれを認識することです。
8.4 エンタープライズ統合と設計の選び方
Zilliz Cloud は匿名化を、パーサーと埋め込み器のあいだのパイプライン変換として公開し、4つのチェックポイント(取り込み、検索、脱トークン化、出力)にフックを置けます。PII Masker は逆の形 — 集中したブロックで、チームが自分のパイプラインに組み合わせる。成熟した展開ではしばしば、中央化された匿名化サービスを建て、4つの操作を持たせます: パース済み文書の匿名化、認可コンテキスト下での脱トークン化引き当て、出力文字列の残存機微内容スキャン、消費したプライバシー予算の報告。
設計判断はアルゴリズムではなく規制から始まります。HIPAA Safe Harbor は18カテゴリの固定リストで PII マスキングにきれいに対応します。PCI DSS はトークン化 — 合成置換+ボールト — で満たされます。GDPR のデータ最小化原則は、もっとも機微なカテゴリに対して生成前を押します。差分プライバシーはどの主要規制も義務化していませんが、脅威モデルに補助データを持つ高度な敵対者が含まれていて、再識別された場合に規制報告対象になるレコードがコーパスに含まれるなら、それが正解です。
第8章を踏まえて
第7章と第8章で第IV部が完結します。アクセス制御は「誰が何を見られるか」に答え、匿名化は「そもそも何があるのか」に答えます。両者はパイプラインの残りが尊重するべきインフラ判断で、両者ともパース・チャンキングの時点で行われた、後から安く戻せない選択に依存します。システムが設計され守られたら、次の問いは「動いているか」 — それを測る方法が要ります。
次回 — 第9章: RAG評価トライアド。 コンテキスト関連性、グラウンデッドネス、回答関連性 — 検索で失敗しているのか、生成で失敗しているのか、その間の結合で失敗しているのかを、運用者に教えてくれる3つの独立した信号。
