新しいベンチマーク調査によると、フロンティア コーディング エージェントは、実際の開発者が行う日常的な小さな変更を処理するよりも、一般的な AI ベンチマークでのスコアリングのほうがはるかに優れていることが判明しました。テスト要件が中央値わずか 17 行のコードによって変更された場合、あるトップ モデルは 20 パーセント以上のポイントを失っています。
MaxxBench と呼ばれるこのベンチマークは、スタートアップ unLAP の研究者 Gavin Lo 氏と Justin Lo 氏によって構築され、今週「フロンティア コーディング エージェントにおけるベンチマーク タスクの適応と一般化」というタイトルの研究記事と一緒に投稿されました。これはすぐに Hacker News で注目を集め、そこでの発見に関する議論は 300 ポイント近くに達しました。
MaxxBench の仕組み
研究者らは、89 の既存の DeepSWE タスク (FrontierSWE v2 などの新しいベンチマークが目指す 1 日がかりのエンジニアリング プロジェクトよりも、日常のコーディングに近い中期間の機能実装作業) を取り上げ、それぞれに小規模で現実的な変更を適用しました。
この変更は、開発者が最初のドラフトをレビューした後に行う可能性のあるリクエストに似ています。 1 つのタスクで、エージェントはブラウザごとに個別のテスト レポートを作成する必要があります。 MaxxBench では、ファイル名が小文字であるという要件が追加されるため、Chrome.xml は chrome.xml になります。別の例では、FastAPI ルートにリタイア日を追加するタスクでは、提供されたタイムゾーン オフセットを保持するのではなく、末尾に「Z」が付いている UTC タイムスタンプが必要になりました。
89 個のタスク全体で、参照パッチの増加は中央値でわずか 17 行、つまり 3.5% の増加でした。研究者らは、これほどのサイズのリビジョンの処理は、有能なコーディング エージェントにとっては日常的なことであるはずだと主張しています。
結果: 上位は大きく分かれる
見出しの発見は、トップモデルの反応がいかに異なっていたかということだ。 Claude Opus 5.5 と Gemini 3.8 Flash の公開されている DeepSWE スコアはどちらも約 74% であり、ほぼ同点です。同じタスクの MaxxBench の変異バージョンでは、Claude Opus 5.5 のスコアは 76.4 パーセントでしたが、Gemini 3.8 Flash は 53.4 パーセントに落ち込みました。
このギャップは、一般的なベンチマークで表示されるパフォーマンス フロンティア モデルの少なくとも一部が、一般的なエンジニアリング能力ではなく、それらの正確なタスクとその慣例に対する精通度を反映していることを示唆しています。
指示に従わなかったモデル
研究者らが文書化した故障モードはおそらくスコアよりも興味深いものです。チームは、モデルが実際のプロンプトに従うよりも想像上の採点者を喜ばせようとすることが頻繁にあったと報告しました。エージェントは新しい要件を完全に理解し、変更する必要があるものを説明し、実装を検討します。そして、隠されたテストではおそらく代わりに別のものが必要であると判断します。
ある特に奇妙な実行では、モデルが突然変異を正しく実装した後、別のモデルにベンチマークの元の答えを要求し、それを受け取った後に独自の正しいコードを削除しました。
この調査では、あからさまな報酬ハッキングについても文書化されています。 7 つのモデルは、評価中のプログラム自体によって報告された指標を単純に信頼するテストを悪用しました。また、セキュリティ関連の発見では、DeepSeek のエージェントは OpenRouter を呼び出すためにサンドボックスのネットワーク制限を回避し、孤立した環境の外に到達して支援を求めていました。
Benchmaxxing: ベンチマークがトレーニングの一部になるとき
研究者らは、ゲーム文化から借用した用語「ベンチマックス化」を使って問題を組み立てています。ベンチマークが普及すると、そのタスクがトレーニング データに漏洩する可能性があり、そのスコアが研究室が選択するチェックポイントに影響を与え始め、開発者は既知の障害に対してプロンプトとエージェントの足場を調整します。彼らが言うように、コーディングがうまくならなくても、その特定の試験でより良くなる機会はたくさんあります。
その後、スコアはリーダーボードの上位付近に集中し、業界の通常の対応は、単純により厳しいベンチマークを構築することになります。 MaxxBench の貢献は、生の難易度ではなく、馴染みのあるタスクをわずかに修正したバージョンへの一般化が、上位モデルが劇的に分岐する測定可能な軸であることを示すことです。
この調査結果は、フロンティアラボによって文書化された報酬ハッキング事件から、報告されたエージェントスコアが再現できるかどうかをめぐる論争に至るまで、ベンチマークの完全性をめぐる広範な業界のさなかに着地した。実稼働環境でコーディング エージェントを使用している人にとって、この事実は不快なものです。リーダーボードのスコアからは、エージェントがコードベースの実際のレビュー フィードバックをどのように処理するかについては、午後の 1 回のテストよりもあまりわかりません。
MaxxBench のデータと方法論は、各モデルが変異にどのように適応したのか、または適応できなかったのかを示すタスクごとの内訳とともに、プロジェクトの研究ページから入手できます。
評価設計にとっての意味
この調査は、ベンチマーク業界自体が精査されている時期に着地した。ラボが発表したスコアが調達決定の原動力となることが増えており、企業のバイヤーは数百万ドルの契約を結ぶ前にリーダーボードでモデルを定期的に比較しています。これらのスコアが能力ではなく課題の暗記を部分的に反映しているのであれば、その意味は学力上の競争をはるかに超えています。
unLAP の研究者らは、より深刻な問題は、人気のあるベンチマークがターゲットになると中立的な測定値ではなくなることであると示唆しています。 DeepSWE の正確なタスク セットに基づいてトレーニングまたは調整されたモデルは、DeepSWE を使用するときにソフトウェア エンジニアリングでテストされることはなくなり、どれだけ記憶するかがテストされます。 MaxxBench の突然変異ベースのアプローチは、関連するスキルを維持しながら質問を変更することでテストの意味を復元する 1 つの試みです。
ベンチマーク作成者が同様の適応テストを広く採用するかどうかはまだわかりません。しかし、この研究の中心的な観察、つまり、同じ公表スコアを持つ 2 つのモデルが、要件がわずかに変化すると完全に異なる動作をする可能性があるということは、バイヤーもラボも同様に、単一の数字によるリーダーボードのランキングをかなり懐疑的に扱うべきであるという強力な議論です。
