SolidCoder: 具体的な実行による LLM によるコード生成における「メンタル - リアリティギャップ」の解消

本論文は、大規模言語モデル（LLM）によるコード生成における根本的な限界である「メンタル - リアリティギャップ（Mental-Reality Gap）」を特定し、それを解消するための新しいフレームワーク「SolidCoder」を提案しています。以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳細にまとめます。

1. 問題定義：メンタル - リアリティギャップ

既存の最先端のコード生成フレームワーク（例：CodeSIM）は、LLM がコードの正しさを検証する際に「メンタルシミュレーション（頭の中での実行トレース）」に依存しています。しかし、著者らはこのアプローチに以下の根本的な欠陥があることを指摘しています。

• メンタル - リアリティギャップ: モデルが実際のプログラム動作とは異なる「実行トレース」を幻覚（ハルシネーション）として生成し、バグのあるコードであっても正しく動作すると自信を持って検証してしまう現象です。
• ギャップの 2 つの次元:
  1. 仕様ギャップ（Specification Gap）: 計画段階でエッジケース（境界値、空入力など）を見落とし、アルゴリズム設計が不完全になること。
  2. 検証ギャップ（Verification Gap）: 欠陥のあるコードに対して、メンタルシミュレーションが「正しい動作」を幻覚し、バグを検出できないこと。

従来のアプローチは、これらのギャップの一方を修正しても他方が残るため、完全な解決には至っていませんでした。

2. 手法：SolidCoder と S.O.L.I.D. アーキテクチャ

SolidCoder は「想像するのではなく、実行せよ（Don't imagine—execute）」という原則に基づき、メンタルシミュレーションに代わってサンドボックス環境での具体的なコード実行を生成ループに統合します。このアーキテクチャは「S.O.L.I.D.」という 5 つのコンポーネントで構成されています。

1. Shift-left Planning (S):

   • 目的: 仕様ギャップの解消。
   • 手法: アルゴリズムの計画を立てる前に、LLM に「ナイーブな解決策を破る最悪のケース（エッジケース）」を特定させます。これにより、設計段階からロバストなアルゴリズムを構築します。

2. Oracle-based Assertions (O):

   • 目的: 正解出力（Ground Truth）が不明な問題での検証を可能にする。
   • 手法: 具体的な出力値を予測するのではなく、「出力の長さが入力と同じである」「結果は入力の順列である」といった**プロパティ（性質）**に基づいたアサーション（断言）を生成します。これにより、オラクル問題（正解がわからない状態でのテスト生成）を回避します。

3. Live Execution (L):

   • 目的: 検証ギャップの解消。
   • 手法: LLM に実行を想像させるのではなく、生成されたコードをサンドボックス環境（5 秒のタイムアウト、ネットワーク遮断など）で実際に実行します。実行結果やアサーションの失敗をフィードバックとして利用し、メンタルシミュレーションの誤りを物理的に検出します。

4. Intermediate Simulation (I):

   • 目的: コスト効果の高い事前フィルタリング。
   • 手法: コード生成直後に、LLM にサンプル入力での実行トレースを行わせます。これは最終的な判定ではなく、明らかな翻訳エラーを早期に発見するための補助的なフィルターとして機能します。

5. Defensive Accumulation (D):

   • 目的: 回帰（Regression）の防止。
   • 手法: 実行中に発見された失敗したテストケースを蓄積し、コードの修正後にすべての蓄積されたテストを再実行させます。これにより、バグ A を修正した際にバグ B が再発することを防ぎます。

3. 主要な貢献

• ギャップの定式化: コード生成における失敗を「仕様ギャップ」と「検証ギャップ」という 2 つの直交する次元として特定し、既存のマルチエージェントフレームワークの根本的な限界を明らかにしました。
• SolidCoder の提案: S.O.L.I.D. アーキテクチャを通じて、両方の次元を同時に解決するフレームワークを提案しました。特に、プロパティベースのオラクルとライブ実行の組み合わせにより、正解出力が不明な状況でも自律的な検証が可能になりました。
• SOTA 性能の達成: GPT-4o を使用した場合、以下のベンチマークで SOTA（State-of-the-Art）を記録しました。
  • HumanEval: 95.7% (+0.6%p)
  • CodeContests: 77.0% (+4.3%p)
  • APPS: 26.7% (+3.4%p)
  • また、RL 事後学習モデル（GPT-OSS-120B, Grok-4.1-Fast）に対しても同様の改善が見られ、手法の汎用性が確認されました。

4. 実験結果と分析

• アブレーション研究:
  • Shift-left Planning (S) の除去は CodeContests で -23.7%p の性能低下をもたらしました。これは、アルゴリズム競合問題において「エッジケースの盲点」が主要な失敗要因であることを示しています。
  • Live Execution (L) の除去は -7.9%p の低下をもたらしました。これは、仕様改善だけでは検出できない「メンタルシミュレーションによる幻覚」が原因のバグを、実行ベースの検証が捉えていることを意味します。
  • 両方のコンポーネントは相補的であり、組み合わせることで最大の効果が発揮されます。
• 効率性:
  • 簡単な問題（HumanEval）ではトークン使用量が増加しますが、LLM が苦手とする中難易度（CodeContests）や高難易度（APPS）の問題では、追加のコストに見合う大幅な性能向上が得られました。
  • 難易度に応じたルーティング（簡単な問題は軽量パス、難しい問題はフル検証ループ）の導入が今後の課題として示唆されています。

5. 意義と結論

SolidCoder は、LLM によるコード生成の次のボトルネックが「生成能力」そのものではなく、「自己評価（自己検証）の信頼性」にあることを示しました。

• 実用的な価値: 単なる理論的な改善ではなく、実際のサンドボックス実行を通じてバグを物理的に排除するため、より信頼性の高い自律的コード生成システムの実現に寄与します。
• 将来の展望: 本研究は関数レベルのベンチマークに焦点を当てていますが、その原理（実行ベースの検証とプロパティチェック）は、リポジトリレベルのタスク（SWE-bench など）や、より複雑なソフトウェア工学タスクへも拡張可能です。

結論として、SolidCoder は「想像」に頼る従来のパラダイムから、「実行」に根ざした新しいパラダイムへの転換を促し、LLM によるコード合成の信頼性を飛躍的に高める重要なステップとなりました。