技術要約：BeSpec – コード生成のための振る舞いレベルの仕様アライメント

問題提起

大規模言語モデル（LLM）は、自然言語による記述（意図）からの自動コード生成を高度化させてきた。しかし、既存の手法は主に「生成して、その後洗練する（generate-then-refine）」パラダイムに従っている。すなわち、候補となるプログラムを生成し、テストに対して実行し、フィードバックに基づいてコードをパッチ修正するという流れである。このワークフローは、LLMによる意図の初期解釈が正しいということを暗黙のうちに仮定している。実際には、プログラミングタスクの記述は曖昧であったり、記述不足であったりすることが多い。その結果、LLMは「誤った意図」に対して論理的に整合性のある実装を出力してしまう可能性がある。現在の洗練パイプラインは、コードの修復に焦点を当て、根本的な仕様の明確化には焦点を当てていないため、この「仕様のミスマッチ」を検出できないことが多い。さらに、既存の仕様アライメント手法（SpecineやSpecFixなど）は、テストレベルのエビデンス（出力と期待される結果との比較）に依存している。このアプローチは、複雑なタスクに対してテストオラクルを生成することが困難であること、また、テストの失敗が、どの特定の振る舞いの期待（例：インデックス規則、境界条件）が乖離の原因となったのかを特定できない粗い信号しか提供しないという点において限界がある。

手法：BeSpec

BeSpecは、振る舞いレベルの仕様アライメントアプローチを導入する。テスト出力のみに頼るのではなく、意図されたソリューションを、検証可能な「振る舞いの期待値」へと分解する。本フレームワークは以下のパイプラインを通じて動作する：

1. 仕様抽出（Specification Extraction）： LLMは、入出力形式、制約、正当性ルール、エッジケース、および解決された解釈のための専用フィールドを含む、構造化された仕様へと自然言語の意図を再構成する。
2. 予測振る舞いパイプライン（Predicted Behavior Pipeline）： LLMは、構造化された仕様に基づき、$m$ 個の意図された振る舞い（$B$）を予測する。これらは完全なソリューションではなく、以下のような特定の特性を検証する実行可能なPython関数（check(input, output)）である：
   • ゴールド・ビヘイビア（Gold behaviors）： 提供されたサンプル入出力ペアを満たす。
   • 出力ビヘイビア（Output behaviors）： 構文およびフォーマットの制約（例：出力は "YES" または "NO" でなければならない）。
   • 入力ビヘイビア（Input behaviors）： ルールが適用される条件（例：境界ケース）。
   • 意味的ビヘイビア（Semantic behaviors）： ルールの論理的帰結（例：「要素が削除された場合、インデックスは再計算される」）。
3. 観測振る舞いパイプライン（Observed Behavior Pipeline）：
   • プローブ・シナリオ生成（Probe Scenario Generation）： システムは、予測された振る舞いを検証するために設計された、多様な有効な入力シナリオ（$X$）を生成する。
   • 候補コード生成（Candidate Code Generation）： 構造化された仕様から、$n$ 個の候補プログラムのプールを生成する。
   • 振る舞いの観測（Behavior Observation）： 候補プログラムをプローブ・シナリオ上で実行する。システムは、これらのプローブに対して事前定義された期待出力を必要とせずに、観測された振る舞い（$\hat{B}$）を記録する。
4. 不整合の特定（Misalignment Identification）： システムは、候補プールの全域にわたって、予測された振る舞い（$B$）と観測された振る舞い（$\hat{B}$）を比較する。
   • すべての候補が予測と一致する場合、その振る舞いはアライメントされているとみなされる。
   • 候補間で不一致や逸脱が生じた場合、システムは**不整合（misalignment）**を特定し、その仕様が特定の振る舞いに関して曖昧であるか、あるいは記述不足であることを示す。
5. 仕様の修正（Specification Fixing）： 不整合が検出されると、LLMは（コードではなく）仕様を修復し、欠落している、あるいは曖昧なルールを明示的に記述する（例：削除後の再インデックス規則の明確化）。このプロセスは反復され、精緻化された仕様から新しい候補が生成され、振る舞いが再チェックされる。
6. 振る舞いに基づく選択（Behavior-Grounded Selection）： アライメントが達成されるか、予算（予算内の試行回数）を使い切った時点で、最適な候補を選択する。この選択では、単なるテスト通過を超えたエビデンスとして、最も多くの予測された振る舞いを満たし、かつ公開サンプルに合格するプログラムを優先する。

主な貢献

1. 振る舞いレベルのアライメント： 本論文は、仕様アライメントを、粗いテストレベルのエビデンスから、振る舞いレベルの推論へと進化させた。これは、予測された振る舞い、観測された振る舞い、そして曖昧または欠落している仕様の部分へと、検証可能な振る舞いの期待値を追跡するものである。
2. BeSpec フレームワーク： 構造化された仕様抽出、振る舞いの予測、プローブ入力による候補の実行、自動的な仕様修復、および振る舞いに基づく選択を統合した具体的なパイプラインを提供する。
3. 包括的な評価： 3つのLLM（Qwen3-Coder, GLM-4, GPT-5-Mini）および4つのベンチマーク（CodeContests, xCodeEval, APPS, および汚染のないLiveCodeBench）にわたる6つの設定を用いて評価を行った。
4. 失敗分析： アライメント後、残存するエラーの大部分は、仕様の誤解ではなくアルゴリズムの難易度に起因していることを示す詳細な分析を行う。

結果

• パフォーマンス： BeSpecは、すべての設定において最高のPass@1および平均合格率（APR）を達成し、9つのベースライン（SpecineやSpecFixを含む）を上回った。
  • 最強のベースラインに対する相対的な改善幅は、3つのLLMにおいて、Pass@1で8.1%〜25.3%、APRで**8.7%〜28.7%**であった。
  • 汚染のないLiveCodeBenchにおいて、BeSpecはベストなベースラインに対してPass@1を**15.8%〜17.7%**向上させた。
• 効率性： BeSpecは単純なプロンプティングよりもトークン数と時間のコストがかかるが、SpecFixよりはトークン効率が高く、Specineと同等である。このコストは、精度が重視されるワークロードにおいては許容範囲内と考えられる。
• アブレーション研究：
  • 振る舞いモデルを削除した場合（振る舞いのチェックを行わず、構造化された仕様のみに依存した場合）、パフォーマンスが大幅に低下した（例：CodeContestsではPass@1が約55%低下）。これにより、振る舞いモデルの重要性が確認された。
  • 候補プールのサイズが大きくなるほど精度は向上したが、プールサイズが10を超えると収穫逓減が見られた。
• 失敗分析： アライメント後、BeSpecの残存する失敗は、主に遵守の失敗（アルゴリズム/ロジックのエラー、ランタイムクラッシュ、タイムアウト）であり、弱い仕様によるエラーではなかった。失敗の極僅かな割合（例：GPT-5-Miniにおける184件中4件）のみが、弱い仕様に起因していた。これは、アライメントプロセスが意図の曖昧さをほぼ完全に解決したことを示唆している。

意義と主張

本論文は、仕様のミスマッチがLLMのコード生成における中心的なボトルネックであり、現在の洗練手法はコードレベルで動作しているためにこれに対処できていないと主張している。BeSpecは、焦点を振る舞いレベルの推論へとシフトさせることで、コード生成を進める前に、意図における曖昧さを特定し修復するための、よりきめ細かな信号を提供する。

著者らは、失敗モードの変化が示す通り、BeSpecが仕様を効果的に明確化していると断言している。アライメントが行われると、残された課題は主にアルゴリズムの実装上の困難さとなり、タスク要件の誤解ではない。これは、BeSpecのようなアライメント技術が用いられている場合、複雑なタスクのコード生成における将来の改善は、意図の解釈をさらに精緻化することよりも、アルゴリズムの問題を解決することに依存する可能性があることを示唆している。本手法は、テストオラクルが利用できない、あるいは生成が困難なシナリオにおいて特に重要である。なぜなら、完全なテストスイートではなく、検証可能な振る舞いの特性に依存しているからである。