AIコーディングベンチマークはもう信じられない？
POINT
- SWE-bench、WebArenaなど主要AIコーディングベンチマーク8本が、10行のコードや偽のcurlラッパーで満点を取れることをバークレーの研究者が実証した。公表スコアをそのまま信じる時代は終わった。
- E2EDevはBDD（振る舞い駆動開発）の原則で実ユーザーの操作を模倣し、「コードが書けるか」ではなく「ソフトウェアが動くか」を問う新しい評価軸を提案している。
- API経由で使うモデルが本当に公称どおりかを統計的に確認する手法（ランクベース一様性テスト）が登場し、開発者が自衛できる方向性が研究段階で確立されつつある。
ベンチマークはどう壊されたか
バークレーの研究チームが自動スキャンエージェントを使い、8本の主要ベンチマークを監査した。結果は衝撃的だった。How We Broke Top AI Agent Benchmarks: And What Comes Nextによれば、SWE-bench Verified（500タスク）、SWE-bench Pro（731タスク）、WebArena（812タスク）、Terminal-Bench（89タスク）、FieldWorkArena（890タスク）など、ほぼすべてで満点またはそれに近いスコアを得たという。
手口は拍子抜けするほどシンプルだ。Terminal-Benchでは89タスクのうち82タスクが検証時にインターネット経由でcurlを使ってuvを取得する。研究チームはそのcurlをラッパーに差し替え、uvxをトロイ化し、pytestの出力を偽の合格に書き換えた。それだけで89/89、100%。SWE-bench Verifiedでは、Dockerコンテナ内にconftest.pyを10行置くだけで全テスト結果をpassedに書き換えられる。WebArenaはさらに単純で、タスク設定がconfig_files/{task_id}.jsonというローカルファイルに平文で保存されており、ChromiumがFile:// URLへアクセスできるため、回答ファイルを直接読めてしまう。
これはモデルの能力とは無関係な、評価パイプラインの構造的欠陥だ。研究チームが「エクスプロイト（脆弱性の悪用）」と呼ぶゆえんである。
スコア操作は「研究上の問題」では済まない
実際の市場でも同種の問題はすでに起きている。IQuest-Coder-V1はSWE-benchで81.4%を主張したが、git logを調べると24.4%の軌跡が回答を複製していたことが判明し、補正後のスコアは76.2%に下がった。OpenAIは内部監査でSWE-bench Verifiedの審査対象問題の59.4%に欠陥テストがあると判断し、同ベンチマークを取り下げた。
FieldWorkArenaの問題はより根深い。validate()関数がchat_messagesの最終roleがassistantかどうかだけを確認し、メッセージの内容は比較しない。llm_fuzzy_matchという関数はimportされているが実際には呼ばれない、いわゆるdead code（使われないコード）だ。「最後に返事をしたか」しか評価していないに等しい。
こうした欠陥を踏まえると、モデル選定でベンチマーク順位を第一根拠にする判断は再考が必要だ。代替の評価軸はどこに求めるべきか。
「コードが書けるか」より「ソフトウェアが動くか」を問うE2EDev
2025年10月にarXivに投稿され、ACL 2026 mainに採択されたE2Edev: Benchmarking Large Language Models in End-to-End Software Development Taskは、E2ESDベンチマーク「E2EDev」を提案している。既存のE2ESDベンチマークが「粗い粒度の要求仕様」と「信頼できない評価プロトコル」に縛られているという指摘が出発点だ。
E2EDevの設計は三層構造になっている。実際のユーザーが求める操作単位で書かれたきめ細かな要求仕様、各要求に対応するPythonのステップ実装を伴うBDD（振る舞い駆動開発）テストシナリオ、そしてBehaveフレームワークによる完全自動のテストパイプラインだ。BDDの肝は「ユーザーがこの画面でこのボタンを押したとき、こう動く」という振る舞いの記述にある。コードが構文的に正しいかではなく、実ユーザーの操作を模倣したときにソフトウェアが期待どおり動くかを問う。注釈作業の品質を保つためにHITL-MAA（人間参加型マルチエージェント注釈フレームワーク）も採用している。
複数のE2ESDフレームワークとLLMを評価した結果、上位モデルでさえタスクを継続的に解くことが難しいと分析されている。既存ベンチマークで高スコアを誇るモデルが苦戦するという事実は、E2EDevがより高い識別力を持つことを示している。
APIの向こうのモデルは本当に公称どおりか
Claude CodeやCursorのようなツールを日常的に使う開発者が見落としがちな問題がある。APIを通じて呼ぶモデルが、本当にプロバイダの宣伝するモデルかどうかを確認する手段がほぼ存在しない点だ。量子化による品質劣化、意図的なファインチューニング、あるいはモデルの完全な置換は、外部から気づきにくい。
Auditing Black-Box LLM APIs with a Rank-Based Uniformity Test（arXiv:2506.06975）は、このギャップに対処するランクベース一様性テストを提案する。ローカルに展開した真正モデルの出力分布と、APIの出力分布を統計的に比較し、両者が等しいかを検証する手法だ。設計上の工夫は三点ある。クエリパターンが検出されにくい設計になっており、プロバイダが迂回や混合で応答を操作しようとしても頑健に機能し、クエリ数が限られた状況でも既存手法より高い統計的パワーを発揮する。量子化、ファインチューニング、ジェイルブレーク用プロンプト、モデルの完全置換といった実運用に近い脅威シナリオで評価されている。
現時点でこのテストをCursorのAPIに直接適用するのは現実的ではない。ただ、「信頼できるモデルを使っているか」を検証可能にする方向性が研究段階で確立されつつあることは、開発者として把握しておく価値がある。
まとめ
ベンチマークスコアは「その評価パイプラインにおける最高値」に過ぎず、モデルの実力を直接示さない。モデル選定の根拠にするなら、どんなサンドボックスか、検証ロジックが何を見ているか、評価方法の詳細まで確認する習慣が必要だ。E2EDevのようなBDD型評価や、API監査の研究動向を追うことで、「動くソフトウェアを作れるか」という本質に近い判断軸を自分の手に持てる。ベンチマークを読む技術は、コードを書く技術と同じくらい、今の開発者に求められている。