全LLMがスコア0%——その事実が、コード生成AIの現在地を正確に示している。
Meta Superintelligence Labsを中心にStanfordやHarvardの研究者らが参加するチームは2026年5月5日、新しいコーディングベンチマーク「ProgramBench」を公開した。9つのモデルを評価した結果、完全解決(Fully Resolved)を達成したモデルは一つもなかった。
この記事でわかること:
- ProgramBenchがどんなタスクを課すのか
- 既存のコーディングベンチマークと何が違うのか
- なぜすべてのLLMが0%になるのか
- 各モデルの「ほぼ解決」スコアの比較
コンパイル済みバイナリだけを渡し、ソースを書かせる
ProgramBenchの課題設定はシンプルだ。エージェントは「実行ファイル」と「ドキュメント」だけを受け取り、その実行ファイルと同じ動作をするプログラムをゼロから書く。
制約は厳格で、ソースコードは渡されない。逆コンパイルもできない(バイナリは実行権限のみで、objdump や strings も使えない)。インターネットへの接続も禁止されている。すべてのコードはエージェントが自分で設計し、言語を選び、アーキテクチャを決め、ビルドスクリプトまで書く。
対象プログラムの幅は広い。コマンドラインツールの jq、ripgrep、fzf のような数千行規模から、SQLite、FFmpeg、PHPコンパイラのような大規模プロジェクトまで、全200タスクが用意されている。テストは24万8,853件。エージェント主導のファジングで生成した行動テストで評価し、すべてのテストをパスした場合のみ「完全解決」として計上する。
SWE-benchやHumanEvalとの決定的な違い
SWE-benchは「既存コードのバグを修正する」タスクだ。HumanEvalは「関数シグネチャとドキュメントから実装を埋める」タスクだ。どちらも何らかの構造やヒントが与えられている。
ProgramBenchは違う。メソッドのシグネチャもなく、クラスの雛形もなく、ファイル構造の指示もない。何を抽象化するか、どうモジュールに分割するか、どのインターフェイスを設けるか——すべてをモデル自身が決める。これは従来のベンチマークが意図的に省いてきた「ソフトウェア設計能力」そのものを問うている。
評価ハーネスにも一貫性がある。特定タスクへのチューニングを避け、200タスク全体に同じ汎用エージェント(mini-SWE-agent)を使う。一部の先行研究はごく少数のタスクに合わせてハーネスを最適化していたが、それでは全体的な性能を過大評価するという考えからだ。
不正対策も徹底されている。初期の試行では、モデルがGitHubからソースコードをクローンしたり、パッケージマネージャからコードを取得したりする回避策を見つけた。現在はサンドボックスコンテナ内で実行し、ネット接続なし・逆コンパイル不可・バイナリは実行権限のみという条件で管理されている。
9モデル全員が0%——「ほぼ解決」での差
公開されたリーダーボードには9モデルが掲載されている。完全解決(Fully Resolved)はどのモデルも0%で横並びだ。
「ほぼ解決(Almost Resolved、テストの95%以上が通過)」のスコアを見ると、Claude Opus 4.7 が 3.0% でトップ、Claude Opus 4.6 が 2.5%、Claude Sonnet 4.6 が 1.0% と続く。GPT 5.4、Gemini 3.1 Pro、Gemini 3 Flash は「ほぼ解決」でも 0.0% だった。
論文著者らはスコアが低い理由として、構造なしでの設計難易度、ハーネスの非チューニング、不正防止の徹底の3点を挙げている。コンテキストウィンドウや時間制限は余裕を持って設定されており、モデルが制限に引っかかったケースはほぼない。低スコアの原因はインフラ側ではなく、モデルの能力そのものにある。
「暗記なのでは?」という批判への回答
X上では「ffmpeg や SQLite を再現させるのはソフトウェアエンジニアリングではなく暗記では」という指摘もある。著者のDeedy氏は「SWE-benchも同じようにオーバーフィットや暗記は可能で、どのベンチマークも同じ問題を抱えている」と応じている(参考)。
ProgramBenchはエージェントがバイナリを実行して動作を探索するしかない設計で、モデルが記憶に頼るだけでは正確な動作を再現しにくい構造になっている。
設計能力の空白地帯を可視化した
コード補完や既存コードの修正では、現在のLLMはすでに実用レベルに達している。ProgramBenchが問うのは、何もない状態から「何をどう作るか」を自ら決める能力だ。
「全モデルが0%」というスコアは、単なる難易度の高さではなく、現在のLLMがまだ持っていない設計・判断の能力を可視化している。論文は近くarXivで公開される予定で、GitHubリポジトリ(facebookresearch/ProgramBench)からデータセットとコードを入手できる。