技術要約：コード生成における大規模言語モデルのセキュリティ・キャリブレーションに関する実証的研究

1. 問題提起

大規模言語モデル（LLM）は、コード生成やバグ修正などのタスクにおいて、ソフトウェア開発ワークフローへの統合が進んでいる。しかし、そのセキュリティクリティカルな文脈でのデプロイメントは、根本的な問いを投げかける：モデルは、自身が生成したコードが安全でないことを正確に把握できているのか？

既存のベンチマーク（例：HumanEval、MBPP、SWE-Bench）は機能的な正当性を評価しているが、セキュリティ特性についてはほとんど無視している。最近のセキュリティ指向のベンチマークは、コードに脆弱性が含まれているかどうかを評価しているが、モデルが自身の出力のセキュリティを自己評価できるかどうかを測定できていない。このギャップは、モデルが脆弱なコードに対して高い信頼度を割り当ててしまう**「偽りの信頼（False Trust）」**現象を引き起こす。開発者は、これらの信頼シグナルを信頼することで、精査することなく不安全な出力を受け入れてしまい、本番環境のシステムに脆弱性を波及させる可能性がある。

先行研究では、セキュリティ・キャリブレーション（モデルが表明する出力の安全性に対する信頼度と、実際の出力の安全性の間の整合性）を体系的に測定していない。さらに、孤立した自己完結型のプログラムで見られるキャリブレーションのパターンが、現実的なマルチファイルのリポジトリ・コンテキストに一般化できるのか、あるいはキャリブレーションのシグナルが自動的な脆弱性修復を効果的にガイドできるのかも不明である。

2. 手法

著者らは、初の大規模なセキュリティ・キャリブレーションの実証的研究を提示し、3つの最先端モデル（GPT-4o-mini、Gemini-2.0-Flash、Qwen3-Coder-Next）を評価している。本研究は、2つの補完的なベンチマークと4つの研究課題（RQ）にわたる多段階の評価を採用している。

データセットとコンテキスト

• 自己完結型プログラム (RQ1): 100個のセキュリティクリティカルなPythonタスクで構成されるSALLMベンチマークを利用。各タスクは、外部依存関係から隔離された、入力、期待される出力、およびセキュリティ要件を提供する単一のプロンプトを提供する。
• リポジトリレベルのコンテキスト (RQ2): 4つの言語（C、Java、PHP、Python）と29のCWEを特徴とする125のプロンプトを含むAICGSecEvalベンチマークを利用。これらのタスクは、クロスファイル依存関係、ビルド構成、および外部APIを含む、既存のマルチファイル・リポジトリ内でのパッチ生成を要求する。

実験設定

• モデルとパラメータ: 各モデルは6つの温度設定（0.0から1.0）にわたってテストされ、各タスクにつき20個のサンプルを生成した。
• 信頼度の推定: 以下の4つの手法を比較した：
  1. トークン確率の集計: （GPT/Gemini用の）ロジット確率への直接アクセス。
  2. 言語化された信頼度: モデルに、信頼度スコア（0–1）と推論を含むJSONを出力させるプロンプト。
  3. サンプリングに基づく一貫性: 20個のサンプルのうち検証を通過した割合として信頼度を推定。
  4. 自己一貫性プロンプティング: 信頼度を報告する前に思考の連鎖（Chain-of-Thought: CoT）による推論を行う。
• 検証: コードは隔離されたDockerコンテナ内で実行された。セキュリティラベルは $y_{sec} = y_{func} \land \neg y_{vuln}$ と定義された。つまり、コードはすべての機能テストに合格し、かつすべての脆弱性エクスプロイトテストに失敗しなければ、安全であると見なされない。
• 指標: 期待キャリブレーション誤差（ECE）、ブライア・スコア、過信ギャップ（Overconfidence Gap）、および偽りの信頼（FT）率（高信頼度だが不安全な予測）。

修復および緩和戦略 (RQ3 & RQ4)

• キャリブレーション誘導型修復: 低い校正信頼度（$p_{sec} < 0.5$）を持つサンプルをフィルタリングして反復的な修復を行うクローズドループ・システム。結果は脆弱性のタイプ別に分類された：シンク置換（Sink Replacement: SR）（API変更を必要とする）および制約強制（Constraint Enforcement: CE）（バリデーションロジックを必要とする）。
• 緩和実験:
  1. 実行ゲーティング（Execution Gating）: セキュリティ信頼度を引き出す前に、機能的に誤ったコードをフィルタリングする。
  2. 許可された破壊的修復（Authorized-Breaking Repair）: SR脆弱性を修正するために、後方互換性を壊すこと（例：pickleをjsonに置き換える）を明示的に許可する。
  3. Few-Shot プロンプティング: 安全なコードの例を提供する。
  4. Few-Shot + CoT: Few-shotの例に推論ステップを追加する。

3. 主な結果

RQ1: 自己完結型生成におけるキャリブレーション

• 系統的な過信: すべてのモデルが深刻な過信を示している。GPT-4o-miniとQwen3-Coder-Nextは高いECE（それぞれ0.46–0.48および0.41–0.42）を示し、Gemini-2.0-Flashはより良好ではあるものの、依然として過信している（ECE 0.25–0.26）。
• 偽りの信頼: 信頼度の閾値を0.8とした場合、False Trust率は驚くほど高く（例：GPT-4o-miniで33.5%、Qwen3-Coder-Nextで40.3%）、高信頼度の出力が頻繁に不安全であることを示している。
• 機能 vs セキュリティのキャリブレーション: 逆説的だが、機能的なキャリブレーションはセキュリティのキャリブレーションよりも一貫して悪い（$\Delta ECE < 0$）。モデルは、機能的な正当性よりもセキュリティの成否に関して、より誤校正されている。これは、モデルが機能的な正当性よりもセキュリティの結果をより信頼性高く推定していることを示唆しており、おそらく機能的な正当性は複雑で隠れた実行挙動に依存するためである。
• 信頼度手法: トークン確率の集計は、低いキャリブレーション（ECE $\approx$ 0.80）をもたらす。サンプリングに基づく一貫性は、ほぼゼロのECEを示すが、サンプルごとの識別力に欠ける。言語化された信頼度が、ダウンストリーム分析において最も実用的なシグナルである。

RQ2: リポジトリレベルでの劣化

• キャリブレーションの崩壊: 自己完結型のタスクからリポジトリレベルのコンテキストへ移行すると、キャリブレーションは著しく悪化する。ECEはおよそ3倍から4倍に上昇する（例：GPT-4o-miniのECEは0.41から0.70へ上昇）。
• False Trustの急増: False Trust率は、自己完結型タスクの約17%から、リポジトリ設定では80%以上に跳ね上がる。
• 分解要因: 劣化は2つの要因によって引き起こされる：ビルドの脆弱性（コードがコンパイル/実行に失敗する）とクロスファイル（ファイル間）の複雑性。ビルドの脆弱性はエラーの大部分（GPTでは最大82%）を占めるが、パッチが正常にビルドされた場合でも、真のクロスファイル複雑性が重要な要因として残る。

RQ3: キャリブレーション誘導型修復

• 限定的な有効性: キャリブレーションのシグナルを用いて修復をガイドしても、セキュリティの改善は最小限であり、しばしば機能性を低下させる。
• 構造的障壁: **シンク置換（SR）の脆弱性（APIの入れ替えを必要とする）は、全モデルを通じて修復成功率0%**であった。モデルは不安全なAPIを置き換えることができず、代わりに脆弱性を維持するか、表面的な修正を導入してしまう。
• 機能的退行: 修復の試みは頻繁に機能的な正当性を損なう（破壊率 >60%）。これにより、全体的な安全率が低下する。キャリブレーションはリスク層別化のシグナルとしては機能するが、構造的な脆弱性に対する効果的な自動修復を駆動することはできない。

RQ4: 緩和戦略

• 実行ゲーティング: 最も効果的な緩和策である。セキュリティ信頼度を求める前に機能的に誤ったコードをフィルタリングすることで、モデル全体のECEを31〜39%削減できる。ただし、これは46〜86%のサンプルを破棄するという高いコストを伴う。
• 許可された破壊的修復: APIの変更を明示的に許可することで、GPTとGeminiにおける脆弱性の除去が改善する（35〜42%）が、依然として高い機能的破壊率と低い厳格な成功率をもたらす。
• プロンプティング技術: Few-shotプロンプティングは脆弱性を約61〜65%除去するが、構造的な統合の不一致により、厳格なハーネス評価をパスすることは稀である。Chain-of-Thought（CoT）による推論を追加すると、キャリブレーションが悪化し、厳格な成功率は0%に低下する。

4. 主な貢献

1. 初の大規模研究: 3つのモデル、6つの温度設定、2つの異なる開発コンテキストにわたり、36,000個のサンプルを対象とした、LLM生成コードのセキュリティ・キャリブレーションに関する初の経験的研究。
2. キャリブレーション劣化の分析: 自己完結型の関数から現実的なリポジトリレベルのコンテキストへ移行する際に発生する深刻なキャリブレーションのペナルティを定量化し、クロスファイル依存関係のリスクを浮き彫りにした。
3. 修復の限界: キャリブレーション・シグナルが、モデルが構造的な変換を実行できないという「硬直性の障壁」のために、特にシンク置換の脆弱性に対して信頼できない修復を実現できないことを示した。
4. 緩和策の評価: 構造的な介入（実行ゲーティング）とプロンプトレベルの介入を体系的に評価し、実行ゲーティングがFalse Trustを減らす上で最も効果的な戦略である一方で、高い拒絶コストを伴うことを特定した。

5. 意義と主張

本論文は、キャリブレーションこそが、セキュリティクリティカルな設定におけるLLMの主要な評価基準となるべきであると主張している。研究結果は、「セキュリティはLLMにとってより難しい」という仮定に異議を唱えている。むしろ、本研究は機能的なキャリブレーションの方がセキュリティのキャリブレーションよりも悪いことを明らかにしており、これは誤校正がセキュリティ知識の欠如ではなく、主に隠れた実行時の制約（実行の脆さ）に起因することを示唆している。

著者らは以下のことを主張している：

• 自己報告された信頼度は信頼できない: 高信頼度の出力は頻繁に不安全であり、体系的なFalse Trustのリスクを生み出す。
• コンテキストが重要である: 自己完結型のプログラムに基づくベンチマークは、リポジトリレベルの設定ではキャリブレーションが劇的に低下するため、デプロイメントのリスクを著しく過小評価する。
• 修復は万能薬ではない: キャリブレーションのシグナルは人間によるレビューの優先順位付けには役立つが、構造的な脆弱性に対して信頼できる自動修復を駆動することは現在できない。
• 実務家へのガイダンス: セキュリティ評価は、実行ゲーティング（機能テスト）の後に行われるべきであり、実行の不確実性による汚染を避けるために、セキュリティと機能性の信頼度シグナルは個別に抽出されるべきである。

本研究は、LLMはセキュリティの自己評価能力をある程度示しているものの、その過信と構造的修復の能力不足により、特に複雑なマルチファイル開発環境においては人間の監視が必要であると結論付けている。