論文「LLM-Redactor: プライバシ保護型 LLM リクエストのための 8 手法の実証的評価」の技術的概要

この論文は、クラウド LLM API へのリクエストに含まれる機密情報（個人情報、組織情報、機密コード、認証情報など）の漏洩リスクに対処するため、8 つのプライバシ保護技術を体系的に実装・評価した研究です。著者らは、既存のネットワーク暗号化や DLP（データ損失防止）では不十分であるとし、リクエストパイプライン自体で動作するオープンソースの「シム（shim）」ツール「LLM-Redactor」を開発し、1,300 件のサンプルを用いたベンチマーク評価を行いました。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細をまとめます。

---

1. 問題定義と背景

• 現状の課題: 開発者や AI エージェントは、コード、顧客情報、API キー、組織の内部文書などを含むプロンプトを毎日数百万回クラウド LLM に送信しています。これらのデータはベンダーによってログ記録、トレーニング、法廷提出のために保持されるリスクがあります。
• 既存ツールの限界:
  • TLS 暗号化: 通信経路の盗聴は防げますが、ベンダー側からのアクセスは防げません。
  • 組織レベルの DLP: 保存データやバージョン管理システムに焦点が当てられており、トランザクション中の API リクエスト内容のリアルタイム保護には対応していません。
  • シークレットスキャナー: コミット時の検出は可能ですが、ライブなリクエストトラフィックの検査はできません。
• 目的: プロンプトの内容そのものを保護し、ベンダーや第三者への漏洩を防ぐための体系的なフレームワークと参考実装の提供。

2. 評価対象となる 8 つの手法

著者らは、プライバシー特性、ユーティリティコスト、実用性に基づき 8 つの手法を分類・評価しました。

手法	概要	実用性
A: ローカル推論	機密性を保つため、ローカルモデル（例：Ollama）で完結させる。複雑なタスクのみクラウドへ。	高 (実用可能)
B: 置換によるマスキング	NER（固有表現認識）や正規表現で機密部分を特定し、プレースホルダー（例：<EMAIL_1>）に置換。レスポンス時に復元。	高 (実用可能)
C: 意味的言い換え	ローカルモデルを用いて、識別情報を含まないまま技術的な意図を維持するようにプロンプトを書き換える。	高 (実用可能)
D: TEE 推論	信頼実行環境（TEE、例：AWS Nitro Enclaves）内で推論を実行。平文をエンクロージャ内で処理。	中 (限定的)
E: スプリット推論	モデルの一部をローカル、残りをクラウドで実行。中間活性化値のみを送信。	低 (研究段階)
F: 準同型暗号 (FHE)	暗号化されたデータのまま推論を実行。	低 (研究段階・非現実的)
G: 秘密共有 (MPC)	複数のサーバー間でデータを秘密共有し、推論を分散実行。	低 (研究段階)
H: 差分プライバシー (DP) ノイズ	単語レベルに統計的なノイズを加え、残存信号をぼかす。	中 (ニッチ)

3. 研究方法とシステム設計

• システム「LLM-Redactor」:
  • MCP（Model Context Protocol）および OpenAI 互換 HTTP API に対応するオープンソースのシム。
  • 各ステージ（検出、置換、言い換え、ノイズ付与、ルーティング）を独立して有効化/無効化可能。
  • パイプライン:
    1. ローカル/クラウドの分類（A）。
    2. 機密スパンの検出（正規表現 + Presidio NER）。
    3. 置換（B）または意味的言い換え（C）。
    4. DP ノイズ付与（H）。
    5. クラウドへのルーティング（TEE、スプリット等を含む）。
    6. レスポンスのプレースホルダー復元。
• 評価ベンチマーク:
  • データセット: 4 つのワークロードクラス、計 1,300 サンプル、4,014 件のアノテーション。
    1. WL1 (PII 重視): 名前、メール、住所などが含まれる自然言語。
    2. WL2 (シークレット重視): API キー、パスワード、設定ファイル。
    3. WL3 (暗黙的アイデンティティ): 特定の個人や組織を直接名指しせず、役割や関係性で特定される記述（例：「競合他社で働く妻を持つ CFO」）。
    4. WL4 (独自コード): 内部関数名、スキーマ、プロジェクトコードネームを含むコード。
  • 指標: 完全漏洩率（Exact Leak）、部分漏洩率、レイテンシ、コスト、ユーティリティ（品質低下度）。

4. 主要な結果と知見

4.1 単一手法の限界と組み合わせの優位性

• 単一手法では不十分: どの手法もすべてのワークロードで優位性を示すことはありませんでした。
• 最良の実践的組み合わせ (A+B+C):
  • 戦略: リクエストがローカルで処理可能ならローカル推論（A）を行い、それ以外はマスキング（B）と意味的言い換え（C）を適用。
  • 結果:
    • WL1 (PII): 結合漏洩率 0.6%、500 サンプル中 完全漏洩 0 件。
    • WL2 (シークレット): 結合漏洩率 6.4%。
    • WL4 (コード): 結合漏洩率 31.3%。
  • A+B (C なし) の場合: PII 漏洩は 1.2% に留まりますが、コード（WL4）では 38.1% と劣ります。言い換え（C）がコードの文脈維持に重要であることが示されました。

4.2 暗黙的アイデンティティ（WL3）の課題

• 最大の課題: 「暗黙的アイデンティティ」（WL3）は、最も保護が困難なカテゴリでした。
• 結果: 最良の組み合わせ（A+B+C）でも、結合漏洩率は 43.6% にとどまりました。
• 原因: 意味的言い換えモデルは、プロンプトの構造や関係性（例：「競合他社の妻を持つ役員」）を維持する必要があり、これらを除去するとプロンプト自体が機能しなくなるためです。
• 解決策: このケースでは、ローカル推論（A）か TEE（D）でのみ完全に保護可能です。

4.3 性能とコスト

• レイテンシ:
  • マスキング（B）のみ：+50ms 未満。
  • 言い換え（C）追加：+1〜2 秒（ローカル 3B モデルの呼び出しによる）。
  • ローカル分類（A）：+300ms 程度。
• トークンコスト: マスキング（B）は、長い機密情報を短いプレースホルダーに置換するため、送信トークン数が 4〜12% 減少し、コスト削減効果もあります。
• 品質（ユーティリティ）: 評価モデルによる判断では、非加工プロンプトに対する回答の好まれる割合が 75〜80% でしたが、プライバシー優先ワークロードでは許容範囲と判断されました。

4.4 研究段階の手法

• TEE (D): ハードウェアレベルの証明により、暗号化なしで平文を保護可能。実用化は可能だがインフラ要件が高い。
• FHE (F) / MPC (G): 理論的には完全なプライバシーを保証するが、推論速度が現実的ではない（1 万〜10 万倍の遅延）ため、現時点では実用不可。

5. 実践への指針（意思決定ルール）

著者らは、脅威モデルの許容漏洩率（$\lambda$）に基づいた意思決定ルールを提案しています。

1. $\lambda = 0$ (完全ゼロ許容):
   • ローカルで処理可能なものはすべてローカル推論（A）。
   • 残りは TEE（D）を使用するか、リクエストを拒否する。
2. $\lambda \le 0.05$ (厳格):
   • A + B + C を採用。ローカルルーティング、マスキング、言い換えを組み合わせる。
3. $\lambda \le 0.25$ (標準):
   • B (NER 付き) のみ。最もコスト効率が良く、実用的な保護を提供。
4. レイテンシ最優先:
   • B (NER) のみ（+50ms 未満）。

6. 意義と貢献

• 体系的な比較: 8 つの異なるアプローチを共通のベンチマークで初めて比較評価しました。
• オープンソース実装: MCP および OpenAI 互換 API に対応した実用的なツール「LLM-Redactor」を公開し、開発者がすぐに導入・評価できる基盤を提供しました。
• 限界の明確化: 「内容レベルの変換（マスキングや言い換え）」には限界があり、特に「暗黙的アイデンティティ」の保護には、ローカル推論や TEE といった構造的なアプローチが必要であることを実証しました。
• 将来展望: TEE の普及や FHE/MPC の性能向上に伴い、より高度なプライバシー保護が現実的になると予測しています。

結論

LLM リクエストのプライバシ保護において、単一の「銀の弾丸」は存在しません。最も実用的で効果的な戦略は、**「可能な限りローカルで処理し、クラウドへ送る必要がある場合はマスキングと意味的言い換えを組み合わせる（A+B+C）」**という多層的なアプローチです。特に、暗黙的な個人特定を含むコンテンツについては、TEE の活用が不可欠であることが示されました。