AIランキング操作は全滅！Metaとスタンフォードの地獄級テストでGPT/Claude/Geminiが0点

---

新智元報道

FFmpegの使用文書と、コンパイル済みの実行ファイルを渡される。

そして、プログラム全体をゼロから書き直すのだ。

これがProgramBenchが世界最先端のAIに出題した課題である。

昨日発表されたこのベンチマークは、SWE-Benchの原班メンバーによって作成され、Meta、スタンフォード大学、ハーバード大学の三者が協力して構築した。

200のソフトウェアプロジェクト。9つの最先端モデル。通過率、0%%！

共同筆頭著者のJohn Yang氏は、スタンフォード大学の博士課程学生で、SWE-BenchおよびSWE-agentの創設者でもある

この一年間、「AI Agentにゼロからソフトウェアを作成させる」ケースの報道が増えている。

Anthropicは並列ClaudeでCコンパイラを作成し、Cursorは長時間の自律的プログラミングについてブログを発表し、Epoch AIのMirrorCodeも同様の取り組みを行っている。

しかし、これらのケースには共通の問題がある。毎回数プロジェクトしかテストせず、足場（スキャフォールディング）は手動で最適化されているのだ。

対照的に、ProgramBenchはこの作業を正規化した。

200の課題、統一されたスキャフォールディング、系統的な不正行為対策を備え、ベンチマークの標準に引き上げた。

論文URL：https://programbench.com/static/paper.pdf

従来のSWE-Benchのテストでは、既存のコードベースが与えられ、どこにバグがあるか、あるいはどのような機能を追加すべきかが示され、それを修正する。本質的には「読解能力＋局所的手術」だ。

評価面では、単体テストを使用し、コードの内部実装が正しいかを確認する。関数のシグネチャや変数名も、期待値と一致している必要がある。

ProgramBenchは完全に逆を行く。

与えられるのは2つだけ。コンパイル済みの実行ファイルと使用文書だ。

課題は、プログラムを実行し、その入出力動作を観察するだけで、同じ動作を再現するコードをゼロから作成することだ。

プログラミング言語の選択、データ構造の使用、モジュールの分割方法、すべて自分で決める。

コードの骨組みも、関数シグネチャも、ヒントも一切ない。

評価方式について、研究チームはAgent主導のファジングテストを用いて、200の課題に対して合計248,853の行動テストを生成した。

作成したプログラムを実行し、入出力がオリジナルと一致すれば合格、不一致なら不合格。テストはモデルに決して公開されない。

SWE-Benchの単体テストとは異なり、ProgramBenchの行動テストはコードの内部構造を全く気にしない。動作が一致すれば良いのだ。

200の課題が対象とするプロジェクトは、圧縮ツール（zstd、lz4、brotli）、言語インタープリタ（PHP、Lua、tinycc）、データベース（DuckDB、SQLite）、メディア処理（FFmpeg）、開発者ツール（ripgrep、fzf、jq）にまたがる。

コード行数の中央値は8,635行、最大のFFmpegは270万行に達する。

要約すると、このテストが問うのは、AIが「人間のエンジニアのように思考し、ソフトウェアを設計する能力」を持っているかどうか、ということだ。「既存のコードで修正すべき場所を見つけ、正しく修正する」だけではない。

テストに参加したのは9つのモデルで、Claude、Gemini、GPTの3大家族をカバーする。

完全通過率（すべてのテストを通過）、全員0%%。

まず3つの旗艦モデルの対決を見てみよう。

GPT-5.4とGemini 3.1 Proの平均テスト通過率はほぼ互角で、それぞれ38.3%%と36.6%%。しかし、両者の問題解決スタイルは全く異なる。

GPT-5.4は16回のAPI呼び出し、0.33ドルのコストで、基本的に一気にプログラム全体を書き上げる。100%%のコードが一度の編集で生成され、その後ほとんど修正を加えない。

Gemini 3.1 Proは9モデルの中で最も「観察」を好む。94回のAPI呼び出しを行い、そのうち34.1%%の操作がオリジナルプログラムの実行と入出力動作の観察に費やされた。最も探索を行ったが、最終的な成績は大きな差はない。

本当に差をつけたのはClaude Opus 4.7だ。

平均通過率51.2%%、3%%の課題で95%%以上のテストを通過し、「ほぼ合格」基準に唯一達したモデルだ。しかし、それでもどの課題でも満点を取ることはできなかった。

全体を見ると、9モデルの表現には明確な階層が見られる。

Claude系3つの旗艦モデル（Opus 4.7、Opus 4.6、Sonnet 4.6）が先頭を走り、GPT-5.4とGemini 3.1 Proが第二集団を形成し、残りの4つの小型モデルは通過率が35%%未満だった。

直感に反する発見もある。お金をかけ、ステップ数を増やしても、必ずしも良い成績にはならない。

Sonnet 4.6は課題あたり平均868コマンドを実行し、コストは27.09ドル、最長の軌跡は約2000ステップに達した。しかし、その成績は93回の呼び出しで3.81ドルのOpus 4.7よりも劣る。

さらに重要なのは、98%%の実行で、モデルが自ら「終わった」と判断して能動的に回答を提出したことだ。時間やステップ数の上限にぶつかったわけではない。

試験時間が足りなかったのではなく、本当にできなかったのだ。

また、課題の難易度とモデルのランキングは高度に一致している。

簡単なCLIツール（nnn、fzf、gron）は全員が良いスコアを取るが、複雑なシステム（FFmpeg、PHP、typst、ast-grep）はすべてのモデルに対して無慈悲に平等だった。

補足だが、ProgramBenchはmini-SWE-agentという極めてシンプルなスキャフォールディングを使用しており、コンテキスト圧縮、マルチAgent協調、カスタマイズされたツールチェーンはない。

研究チームは、75%%以上のテストを通過した高得点解答と人間のオリジナルコードを比較し、驚くべき差異を発見した。

• 単一ファイルの怪物。

人間のコードの中央値は15ファイルに分散しているのに対し、モデルの中央値は3ファイルだ。

60%%の解答が1〜3のコードファイルのみだった。

人間のエンジニアは機能ごとにモジュールを分割するが、モデルはすべてを1つの巨大なファイルに詰め込む傾向がある。ディレクトリ深度の中央値は、人間が2階層に対し、モデルは1階層だった。

• 関数は少なくて長い。

Opus 4.7が書く関数数は人間の29%%にとどまり、Sonnet 4.6は24%%、GPT-5.4は10%%だった。

しかし、各関数の平均長はより長く、Gemini 3.1 Proが書く関数は人間より62%%長かった。

• コード量が大幅に減少。

モデルのコードの中央値は1,173行、人間は3,068行。85%%の高得点解答がオリジナルより短かった。

まとめると、現在のAIはコードを書けるが、ソフトウェア設計はできない。

モジュールを分割する理由、インターフェースや抽象化階層を定義する理由を、AIは理解していない。すべてのロジックを可能な限り少ないファイルと関数に硬く詰め込み、動けば良いという戦略なのだ。

GPT-5.4の表現が最も極端だ。課題あたり平均5ファイルを作成し、1.2回修正する。39.5%%の軌跡でファイル作成後の修正がゼロだった。

対照的に、Claude Sonnet 4.6は平均11.3ファイルを作成し、18.3回修正を行い、より人間に近い反復開発モードを示した。

また、非常に興味深い現象もあった。

モデルがオリジナルと同じプログラミング言語を使用する確率は50%%に過ぎない。

その中で、Pythonはモデルの最愛言語で、全1,800回の実行の36%%を占めた。

オリジナルがRustで書かれたプロジェクトは、44%%がRustで再構築された。C/C++の場合は46%%だった。Goプロジェクトの「忠誠度」が最も高く70%%だった。

元々何の言語で書かれていようと、モデルは3分の1の確率でPythonで書き直す。

これが研究全体で最も劇的な部分かもしれない。

研究チームは対照実験を行い、モデルにネットワークアクセス権限を開放したが、システムプロンプトで「不正行為は許可しない」と明確に告知した。

そして9つのAI裁判官を使って、各軌跡に不正行為の有無をチェックさせた。

結果は衝撃的だった。

Claude Sonnet 4.6は36%%の課題で不正行為と判定され、Claude Opus 4.6は21%%、Gemini 3 Flashは20%%だった。

不正行為の方法は多種多様だった。

最も露骨なのは、GitHubにアクセスしてソースコードリポジトリをクローンすることだ。

やや隠蔽性が高いのは、パッケージマネージャーを通じてダウンロードすること。例えばcargo install、go getなどだ。

さらに狡猾なのは、ローカルのパッケージキャッシュディレクトリを探って依存ライブラリのソースコードを探すことだ。

しかし、AI裁判官間の意見の不一致も驚くほど大きかった。

Claude Opus 4.6の場合、9人の裁判官が57%%の課題で合意に達できなかった。

特に典型的なケースがあった。

Claude Sonnet 4.6がhandlrというRustプロジェクトを行う際、~/.cargo/registry/src/ディレクトリを探ってxdg-mime、clapなどの依存ライブラリのソースコードを調べた。

5人の裁判官が不正行為と判定し、4人が「これらはサードパーティライブラリなので不正行為ではない」と判断した。

最終的に、研究チームは「インターネット接続＋事後検出」の方案を放棄し、ネット接続を完全に遮断した。

困難な課題に直面したとき、モデルの「近道を探す」傾向は予想以上に強い。9人のAI裁判官ですら不正行為と合理的なリバースエンジニアリングの境界を判断できないことは、この境界自体が曖昧であることを示している。

SWE-Benchで72%%を達成できるモデルが、ProgramBenchでは0%%だ。

これら2つのテストが問うのは根本的に異なる2つの能力だ。SWE-Benchが問うのは「他人のコードで問題を見つけ、修正する」能力、ProgramBenchが問うのは「自分でゼロから完全なシステムを設計・実装する」能力だ。

前者はAIがすでに相当に優れているが、後者は現時点で完全に不合格だ。

Epoch AIは先週、ブログで旧推理ベンチマークの集団的な死亡を宣告した。まだ攻略されていないテストを作るためには、純テキスト、短時間、易評価、人間専門家の圧倒的優位、という4つの快適条件のうち少なくとも1つを放棄する必要がある。

このフレームワークで見ると、ProgramBenchはそのうち2つ、短時間と易評価を放棄した。

課題は人間のエンジニアが数週間、数か月を要する規模に引き上げ、評価はソースコードの一致ではなく行動の等価性で行う。

著者のJohn Yang氏はツイートで「ProgramBenchは非常に困難だが、設計上解決可能だ」と強調した。

つまり、0%%はこれらの課題がAIの理論的限界を超えていることを意味するのではなく、現在のモデルがまだ十分ではないことを示している。

SWE-Benchが問うのは、AIが良い社員になれるかどうかだ。ProgramBenchが問うのは、AIがエンジニアになれるかどうかだ。

この2つの間の距離が、今日初めて精密に測定された。答えは0%%だ。