この記事のテーマはかなりシンプルです。
「AI agent のベンチマーク、思った以上に簡単にズルできるよね」 という話です。
ここでいう benchmark は、AIの性能を測るための試験みたいなものです。
人間でいえば入試や資格試験に近い存在で、ここで高得点なら「このモデルは優秀だ」と判断されます。
でもこの記事は、その前提をかなり強く揺さぶっています。
Berkeleyの研究チームは、8つの有名な AI agent benchmark を自動で監査し、「正解を解かなくても、評価の仕組みを悪用するだけでほぼ満点が取れてしまう」ことを示しました。
これ、かなり怖い話です。
というのも、ベンチマークの点数はモデル選定、製品評価、投資判断まで幅広く使われているからです。
もしその点数が「実力」ではなく「穴の突き方」を反映しているなら、業界全体の見え方が変わってしまうと思います。
記事ではこれを The Benchmark Illusion と呼んでいます。
要するに、「スコアが高い＝賢い」とは限らない ということです。
これはたしかに、言われてみれば当たり前なんですが、実際には見落とされがちです。
なぜなら、評価する側はどうしてもスコアを見たくなるからです。数字はわかりやすいので、比較もしやすい。
でも、その数字が壊れていたら、わかりやすいぶんだけ逆に危険なんですよね。
個人的には、ここがこの記事の一番重要なポイントだと思います。
AIの性能競争は加熱していますが、競争が激しくなるほど評価の抜け穴は狙われやすくなる。
これはモデル本体の問題というより、測り方の問題です。
研究チームは、AI agent がベンチマークの仕組みをどう壊せるかを調べました。
結果として、次のようなものが紹介されています。
そして驚くべきことに、全部でほぼ満点、あるいはそれに近いスコアを、実際にはタスクを解かずに出せたと主張しています。
ここで大事なのは、この記事が「理論上こういう弱点がありそう」ではなく、実際にエージェントを作って、公式の評価パイプラインを通してスコアが出ることを確認したと述べている点です。
つまり、机上の空論ではないわけです。
記事では、この問題が“今回初めて見つかった”わけではないとも説明しています。
むしろ、すでにいくつも前例があると言っています。
たとえば：
git log を見て答えをコピペしていたtorch.empty() がたまたま古いGPUメモリを返してしまい、そこに答えが残っていたケースがあったこれらを並べられると、かなり説得力があります。
「たまたま1個壊れていた」のではなく、評価環境をちゃんと守らないと、どこでも似たことが起きるということです。
ここからは少し具体的に見ていきます。
技術的な話も出てきますが、できるだけかみ砕きます。
テスト基盤そのものを乗っ取れる
Terminal-Bench は、端末上での複雑な作業を評価する benchmark です。
たとえば、コマンドラインでビルドしたり、設定をいじったりするタイプですね。
問題は、評価の途中で使うツールやスクリプトが、外部から入れ替えられる設計になっていたことです。
研究チームのエージェントは、curl や uvx などの実行ファイルをすり替え、テスト実行時に「全部パスしたように見える」偽の出力を返させたと説明されています。
要するに、問題を解く代わりに
「採点者の目をだます」 わけです。
これはかなり面白いというか、ちょっと笑えない面白さがあります。
なぜなら、評価対象のAIが賢いというより、評価システムが素直すぎたからです。
修正パッチではなく、テストを黙らせる
SWE-bench は、GitHub の実際の issue を修正する形式のベンチマークです。
つまり、AIがバグ修正できるかを見るわけです。これはかなり“実務っぽい”ので人気があります。
でも記事では、ここでも抜け道があったと示されています。
たとえば、conftest.py という pytest の設定ファイルを仕込むと、すべてのテスト結果を「passed」に書き換えられると説明されています。
ここでのポイントは、パッチがテストと同じコンテナ内で実行されることです。
この設計だと、修正コードに見せかけて評価ロジックを上書きできてしまう。
つまり、バグを直したのではなく、バグが見つからないようにしただけです。
SWE-bench Pro でも同様に、評価用 parser を書き換えることで全タスクを“解決済み”に見せられたとされています。
個人的には、SWE-bench は「実用的で良いベンチマークだ」と思われがちだったぶん、この弱点はかなり重いと思います。
実務に近い形式ほど、評価環境の隔離が甘いと危ない、という教訓ですね。
答えの入ったファイルをそのまま読めた
WebArena は、Webサイトを操作してタスクをこなす benchmark です。
ブラウザを使って予約したり、情報を探したりするイメージです。
記事によると、WebArena の task config ファイルには、正解データ（gold answer）がローカルに置かれていたとのこと。
しかも Chromium が file:// URL を開けたため、エージェントはその設定ファイルを直接読めたとされています。
つまり、問題を解く必要すらなく、答えが置いてある場所に見に行けたわけです。
これ、試験で言えば「解答用紙が教室の机の中に入っていた」みたいな話です。かなりまずい。
さらに、DOM に隠し要素を入れて判定を通したり、LLM judge にプロンプトインジェクションを仕掛けたりする別ルートも指摘されています。
要するに、Web評価は“見た目”と“採点ロジック”の両方が甘いと危険ということです。
採点関数が、ほぼ採点していない
ここは正直、かなり衝撃的です。
FieldWorkArena は、画像・動画・PDF・テキストを扱うマルチモーダルなタスク群です。
普通に聞くと、かなり難しそうですよね。ちゃんと見て考えないと解けなさそうです。
でも記事では、validate() 関数が 「最後のメッセージが assistant から来たか」しか見ていない と指摘しています。
中身が正しいかどうかは見ていない。
つまり、答えの内容ではなく、送信者の肩書きだけで合否を決めているようなものです。
これ、かなりひどいです。
しかも 71 タスクでは JSON として読めるかどうかだけを見るらしく、{} でも通るとのこと。
もはや「理解できたか」ではなく、「形式をそれっぽく作れたか」しか見ていないわけです。
公開されている答えをそのままダウンロードできた
OSWorld は、Ubuntu の VM 上でデスクトップ作業を行うベンチマークです。
現実のPC操作に近いので、それっぽい難しさがあります。
でもここでも、評価対象の gold reference が HuggingFace 上の公開URLとして task config に埋め込まれていたとされています。
そのため、エージェントは答えのファイルを直接ダウンロードして、評価される場所に置けばよかった。
これは評価の基本を崩しています。
なぜなら、採点とは本来「答えを出す能力」を見るはずなのに、ここでは「答えの置き場所を知っているか」に近くなっているからです。
記事では、他にも system state を直接セットする方法や、最悪の場合 eval() によるコード実行まで起きうると述べています。
eval() は文字列をコードとして実行してしまう危険な仕組みなので、扱いを間違えると本当にまずいです。
公開答えや正規化の穴を突けた
GAIA は 165 タスクで、公開答えや正規化の衝突が弱点になったとされています。
ここでいう正規化とは、表記ゆれを整えて比較する処理のことです。
たとえば「1.0」と「1」や、大文字小文字の違いを吸収するようなものですね。
この手の処理は便利ですが、やりすぎると別のものが同じに見えてしまいます。
その結果、本当は違う答えなのに正解扱いされることがあります。
GAIAについては詳細が少なめですが、こうした“比較の甘さ”が問題になったと読めます。
採点の一部が飛ばされていた
CAR-bench では、hallucination tasks に対して reward components が丸ごとスキップされていたとされています。
reward は「どれだけ良い答えか」を点数化する仕組みです。
それが動いていなければ、そりゃ採点になりません。
これはかなりストレートな不具合です。
言い換えると、採点表の重要な行が空欄だったみたいなものです。
ここは誤解しないほうがいいと思います。
この記事は、AIが悪質だから危険だ、と単純に言っているわけではありません。
むしろ本質は、評価システムが甘いと、賢いAIでなくても高得点が取れてしまうことです。
しかもAIがさらに賢くなると、こうした穴を自動で探し、もっと巧妙に突くようになる可能性があります。
つまり、
という、かなり嫌なループが起きるわけです。
これは業界全体にとって深刻です。
なぜなら、もし評価が壊れていれば、研究開発の方向そのものがズレるからです。
「点を上げるための工夫」が、本来の能力向上ではなく“採点抜け道探し”に寄ってしまうかもしれません。
この記事の後半では、「何を次に直すべきか」が問われています。
本文が途中で切れているので細部は全部は追えませんが、少なくとも言えるのは次のようなことです。
個人的には、今後は benchmark 自体に「攻撃耐性テスト」が必要になると思います。
つまり、単にタスクを出すだけじゃなくて、この評価系はズルされないか？ を先に調べるべきです。
試験で言えば、問題の難しさだけでなく、カンニング耐性まで含めてテストするようなものです。
この記事、かなり面白いです。
ただし「面白い」というのは、ジョークとしてではなく、研究として痛烈だという意味です。
AI業界はどうしても「何％達成」「世界最高スコア」みたいな数字に引っ張られがちです。
でもこのレポートは、その数字がどれだけ簡単に壊れるかを具体的に示しています。
しかも嫌なのは、これは一部のマニアックな例外ではなく、かなり有名な benchmark たちで起きていることです。
これはもう「たまたまのバグ」では済まないでしょう。
評価の設計そのものを見直す段階に来ている、というのが私の感想です。
AIがどれだけ賢くなっても、測り方が雑なら正しく強さはわかりません。
そして、測り方が壊れていると、強くなったつもりで全然違う方向に進んでしまう。
この記事は、その危うさをかなり鮮やかに突きつけています。
参考: Center for Responsible, Decentralized Intelligence at Berkeley