技術要約: PromptMark

問題の定義

ソフトウェア開発における大規模言語モデル（LLM）の普及は、AIが生成したソースコードの起源と作成者を検証する能力、すなわち**コードのプロベナンス（由来）**に対する決定的なニーズを生み出しました。ウォーターマーキングはデジタルコンテンツにおける標準的な技術ですが、ソースコードに適用するには特有の課題があります：

1. 構造的剛性: 自然言語とは異なり、ソースコードは構文的に厳格であり、わずかな修正がコンパイルエラーを引き起こしたり、プログラムのロジックを変化させたりする可能性があります。
2. ブラックボックスの制約: ほとんどの開発者は、APIを介して商用LLMを利用しており、モデルの内部（ロジットやデコーディング戦略）にはアクセスできません。既存のウォーターマーキング手法の多くは、トークンの確率を操作するために「ホワイトボックス」へのアクセスを必要とするため、実世界のデプロイメントにおいては非現実的です。
3. バランスの維持: 効果的なウォーターマーキングは、コードの機能的な正当性や可読性を損なうことなく、検出可能な信号を埋め込む必要があります。

本論文が取り組む核心的な問題は、モデルの内部にアクセスすることなく、目に見えず統計的に検出可能な信号をソースコードに埋め込みつつ、コードの機能を維持できるブラックボックス型のプロンプト誘導型ウォーターマーキング・フレームワークを設計することです。

手法: PromptMark

著者らは、LLMの指示追従能力を活用して、生成を特定のパターンへと誘導する3フェーズのフレームワークであるPromptMarkを提案しています。

1. 暗号学的グリーンリストの構築

ロジットを操作する代わりに、PromptMarkはシステムプロンプトを通じてモデルにバイアスをかけます。

• グリーンリスト／レッドリスト: 本フレームワークは、「グリーンリスト」（識別子やコメントの開始文字として許可される文字）と「レッドリスト」（禁止される文字）を定義します。
• 頻度に基づく層化: 自然さを確保するため、グリーンリストは人間が書いたコード（MBPPおよびHumanEvalデータセットを使用）における識別子の初期文字の頻度分布から派生されます。システムは、候補プールを形成するために、最も頻度の高い上位$K$個の文字（$K \in [10, 12]$）を選択します。
• 暗号学的派生: 予測可能性を防ぐため、グリーンリストの具体的なサイズと構成は、SHA-256ハッシュ関数とフィッシャー・イェーツのシャッフルを用いて、128ビットの秘密鍵から決定論的に派生されます。これにより、セキュリティを維持しながら、検出のための再現性を確保します。

2. 反復フィードバックループ

単一のプロンプトでは、機能的に正しく、かつ十分にウォーターマークが施されたコードが得られるとは限らないため、PromptMarkは反復プロセスを採用しています。

• 生成: LLMに対し、識別子やコメントにグリーンリストの文字を使用するよう指示するシステムプロンプトに基づき、コードを生成させます。
• 評価: 出力は2つの指標で評価されます：
  • 機能的正当性 ($c_i$): ユニットテストの実行（パス／失敗）によって決定されます。
  • ウォーターマークの忠実度 ($p_i$): グリーンリストの文字頻度が期待されるベースラインからどの程度逸脱しているかを測定する統計的p値。
• フィードバック: コードがテストに失敗した場合、エラーログがフィードバックされます。コードはパスしているがウォーターマークが弱い場合は、グリーンリストへの遵守をより厳格にするようプロンプトが更新されます。このループは、両方の基準が満たされるか、最大反復回数に達するまで継続されます。

3. 統計的検出

検出は片側検定として扱われます：

• 帰無仮説 ($H_0$): コードはキーに関する知識なしに生成された（グリーンリストの頻度 $\le$ ベースライン）。
• 対立仮説 ($H_1$): コードにはウォーターマークが施されている（グリーンリストの頻度 $>$ ベースライン）。
• 適応型p値: 検出器は適応型p値を計算し、短いコード（$N < 30$）の場合は正確な二項検定を、長いコード（$N \ge 30$）の場合は正規近似を切り替えて使用します。コードは、機能的に正しく、かつp値が有意水準を下回った場合にのみ、ウォーターマークが施されていると判定されます。

主な貢献

1. ブラックボックス型ウォーターマーキング・フレームワーク: PromptMarkは、プロンプトエンジニアリングのみを使用して、モデルの内部を必要とせずに信頼性の高いゼロビット・ウォーターマーキングをソースコードに対して実現できることを示した最初のフレームワークです。
2. 反復フィードバックメカニズム: 単一パスのプロンプティングで見られるトレードオフに対処するため、ウォーターマークの強度とコードの正当性を動的にバランスさせる自己洗練ループを導入しました。
3. 適応型グリーンリスト戦略 (AGL): ウォーターマーク・トークンを高頻度の人間による識別子初期文字から派生させることで、コードのセマンティックな自然さを維持し、開発者による検出や可読性の低下を招く「強制された」外観を回避します。
4. 暗号学的セキュリティ: 秘密鍵を使用して決定論的にグリーンリストを生成することで、検証のための再現性を確保しつつ、キーなしでの予測に対する安全性を担保しています。

実験結果

フレームワークは、Gemini 2.5 FlashおよびClaude Sonnet 4を用い、MBPPおよびHumanEvalデータセットを用いて評価されました。

• 有効性 (RQ1):

  • PromptMarkは強力な検出力を達成し、構成全体で0.90から0.99のAUROCスコアを記録しました。
  • Iterative-AGL（適応型グリーンリスト）バリアントが最も優れた性能を示し、Gemini/MBPPで0.994、Claude/MBMBPで0.987のAUROCを達成しました。
  • 低い偽陽性率（1%～5%）において、真陽性率は90%を超え、好ましい設定では95%以上に達しました。
  • SWEET（ホワイトボックス）のようなベースライン手法はコードの正当性を著しく低下させた一方、反復を行わないインコンテキスト・ウォーターマーキング（ICW）は、低い検出力（AUROC ~0.51）を示しました。

• コード品質 (RQ2):

  • 機能的正当性: PromptMarkは高いPass%を維持し、非ウォーターマークのベースラインと同等の**HumanEvalで約97%、MBPPで約99%**を達成しました。
  • 構造的類似性: CodeBLEUスコアは非ウォーターマークのコードと安定して一致しており、ウォーターマーキングのプロセスが制御フローやデータ依存関係を歪めていないことを示しています。

• 堅牢性:

  • ウォーターマークはコメントの削除に対して耐性を示しました（AUROCの低下は約3.8%のみ）。
  • しかし、自動パラフレーズ（変数名の変更）は大幅な劣化を引き起こし（AUROCが約0.71に低下）、自然さと、積極的な意味保存攻撃に対する堅牢性の間のトレードオフを浮き彫りにしました。

意義と主張

本論文は、PromptMarkがソースコードのウォーターマーキングをプロンプト誘導型のタスクへと再定義することに成功し、商用のブラックボックス型LLMへの適用を可能にしたと主張しています。

• 実用性: モデルの内部にアクセスできない環境における属性特定のための実行可能なソリューションを提供し、ホワイトボックス限定の研究が残した空白を埋めています。
• バランス: 反復フィードバックメカニズムは、高いウォーターマーク強度と高いコード品質が排他的ではないことを証明しています。フレームワークは動的な洗練を通じてその両方を達成できます。
• 属性特定: 現在の実装はゼロビット検出（存在または不在）をサポートしていますが、著者らは、異なるキーを異なるモデルに割り当てることで、モデル固有の属性特定が可能になるという暗号学的キー分離の可能性についても言及しています。

著者らは、本アプローチがゼロビット・ウォーターマーキングの基礎を確立した一方で、ブラックボックス設定におけるマルチビット符号化可能なウォーターマークの開発、およびマルチチャネル埋め込み戦略を通じた体系的なリネーミング攻撃に対する堅牢性の強化に向けた今後の課題が必要であると結論付けています。