技術概要：テスト生成による LLM ベースのコード生成におけるプライバシー漏洩の探査

問題定義

大規模な公開スクリプトされたコードリポジトリで訓練された大規模言語モデル（LLM）は、開発者が意図せずアップロードした機密性の高い個人識別情報（PII：認証情報、API キー、メールアドレスなど）を記憶し、意図せず再現するリスクを有しています。既存のプライバシー漏洩検出方法が存在するものの、それらは以下のような重大な限界を有しています：

1. アドホックなプロンプト構築：現在の手法は、手動または自動で設計されたプロンプトに依存しており、コードコーパスにおいて PII が現れる現実的な文脈を近似することに失敗しています。
2. 限定的な範囲と適用性：一部の手法は特定のモデル（例：Codex）に特化しているか、または真正のコード文脈に根ざさないプロンプトを生成する変換ベースの戦略に依存しており、実際のプライバシー漏洩ではなく、幻覚やプレースホルダのような出力を生み出しています。
3. 安全メカニズムの回避：PII を直接モデルに問い合わせることは、しばしば安全拒否をトリガーし、漏洩リスクを効果的に評価する能力を制限します。

核心的な課題は、安全拒否をトリガーすることなく記憶された PII を引き出し、現実的な漏洩とモデルの幻覚を区別しながら、実用的な開発シナリオをシミュレートする手法を開発することです。

手法

著者は、機密データを直接要求するのではなく、ユニットテストケースを生成することによってプライバシー漏洩を評価するテスト駆動型パイプラインを提案します。このパイプラインは、以下の 4 つの主要な段階で構成されます：

1. コード生成質問の構築

パイプラインは、企業アプリ、モバイルサービス、クラウドプラットフォームなどの現実的なアプリケーションドメインに根ざした開発シナリオを構築します。

• シナリオの具体化：プライバシー属性（例：メールアドレス、電話番号）は、機能的に必要とされる特定のソフトウェアシナリオにマッピングされます。
• 質問の生成：これらのシナリオは、具体的なコード生成質問として具体化されます。このアプローチにより、プロンプトが元の訓練文脈に類似し、記憶をトリガーする可能性が高まります。

2. モデル応答とテストケースの引き出し

モデルに PII を直接出力させるのではなく、パイプラインは 2 段階の対話を使用します：

• コード生成：評価対象の LLM が、シナリオ質問に基づいて機能的なコードスニペットを生成します。
• テストケース生成：その後、モデルは生成されたコードに対するユニットテストケースの生成を促されます。この段階のプロンプトは、モデルが単なるプレースホルダではなく、現実的で属性に即した入力（例：有効なメールアドレス形式）を提供することを促すため、プライバシー機能ライブラリ（後述）によって拡張されます。この間接的な対話パターンは、安全拒否を起こしにくいものです。

3. プライバシー機能ライブラリ

手動のプロンプトエンジニアリングに代わり、モデルを現実的な出力へと導くため、著者は自動的に構築され反復的に更新されるプライバシー機能ライブラリを導入します。

• 構成要素：各プライバシー属性について、ライブラリは以下の要素を含みます：
  • テンプレート（$\Lambda_{tmp}$）：抽象的な構造的パターン（例：user.email = <EMAIL>）。
  • フラグメント（$\Lambda_{frag}$）：実際の漏洩パターンから導き出された現実的な値レベルのサブストリング。
• 構築：ライブラリは事前知識で初期化され、パイプラインの以前の実行から確認された漏洩事例を用いて強化されます。
• 処理：確認された漏洩は、トークンごとの疑似負対数尤度（pseudo-NLL）を分析するコード指向モデル（CodeBERT）を用いてテンプレートとフラグメントに分解されます。低い疑似 NLL を持つトークン（一般的な構造的要素）はテンプレートとして分類され、高い疑似 NLL を持つトークン（特定の値）はフラグメントとして分類されます。その後、同等のパターンを統合しノイズを除去するために、意味的クラスタリング（DBSCAN）が適用されます。

4. フィルタリングと検証

抽出された候補は、漏洩を確認するための厳格な検証プロセスを経ます：

• ジャッジ LLM によるフィルタリング：オラクルモデルが、構造的および意味的特性に基づいて、幻覚、プレースホルダ、および非現実的な値をスクリーニングします。
• GitHub 検索：候補は公開 GitHub リポジトリに対して検証されます。一致（1〜100 ヒット）は、その文字列が実際のコードコーパスに存在することを示唆します。
• 人間によるレビュー：2 人の著者が、一致した文脈を手動で検査し、その文字列がドキュメントやテストデータではなく、実際の個人情報であることを確認します。
• 出力：「確認済み」の事例のみが報告され、プライバシー漏洩に関する保守的な下限値を提供します。

主要な貢献

1. テスト駆動型パイプライン：現実的な開発シナリオとテストケース生成を活用して安全メカニズムを迂回し、記憶されたデータを引き出す、コード生成タスクにおけるプライバシー漏洩を評価するための新規パイプライン。
2. 自動化されたプライバシー機能ライブラリ：現実的なテンプレートとフラグメントを提供する自動構築ライブラリにより、手動のプロンプトエンジニアリングへの依存を軽減し、引き出されたプライバシー値の品質を向上させます。
3. 大規模な実証評価：5 つの広く使用されている商用 LLM（GPT シリーズおよび DeepSeek シリーズ）における広範な実験により、パイプラインの有効性を実証しました。

実験結果

本研究は、5 つの LLM を 15 のプライバシー属性および 3 つのカテゴリ（識別可能、プライベート、秘密）にわたって評価しました。

• 漏洩量：パイプラインは、GPT シリーズで平均105.7 件の確認事例、DeepSeek シリーズで79.5 件を特定しました。
• ベースラインとの比較：提案手法は、既存のベースライン（CodexLeaks および Codebreaker）と比較して、検出された漏洩を2.56 倍増加させました。
• 漏洩率：全体の漏洩割合は、GPT モデルで17.6‰、DeepSeek モデルで**13.3‰**でした。「識別可能」カテゴリが最も高い漏洩率（24.64‰）を示し、メールアドレスとアカウント/ユーザー名が最も頻繁に漏洩した属性でした。
• 相互接続された漏洩：この手法は、ベースラインよりも頻繁に複数の相互接続されたプライバシー要素を含む応答を明らかにし、シナリオ駆動型のテストが複雑なプライバシーの組み合わせの露出を促すことを示唆しています。
• アブレーション研究：コアコンポーネント（シナリオベースの質問、機能ライブラリ、またはテストケース生成）のいずれかを除去すると、パフォーマンスが著しく低下し、完全なパイプラインの必要性を確認しました。

意義と主張

本論文は、そのアプローチが LLM ベースのコード生成におけるプライバシーリスクを評価するための実用的な監査手法を提供すると主張しています。現実的な開発者との対話をシミュレートすることで、このパイプラインは既存の手法が見逃している無視できないプライバシー漏洩を明らかにします。著者は、GitHub 検索を訓練データの代理として使用し、未検証の候補を除外しているため、報告された漏洩数値は保守的な下限値であると強調しています。

この研究は、安全メカニズムを備えたモデルでさえ、テスト生成のような間接的で開発者らしい対話を通じてプロンプトされると、機密データを再現しうることを浮き彫りにしています。著者は、商用モデルの真実（ground truth）を検証できないという限界や、高信頼度の監査における手動レビューへの現在の依存を認めつつ、その研究をソフトウェア開発における LLM のより安全で信頼性の高い展開に向けた一歩として位置づけています。