AIモデルの「実力」を比べるベンチマーク。SWE-benchやTerminal-Benchのリーダーボードで、1〜2ポイントの差で順位が入れ替わる。でもAnthropicの最新研究が、その前提を揺るがす事実を突きつけた。
衝撃の発見:モデルを変えずに、実行環境のリソース設定を変えるだけで、ベンチマークスコアが6ポイントも変動する。リーダーボードのトップモデル間の差より大きい。
静的ベンチマークとの決定的な違い
従来のベンチマーク(選択問題や翻訳など)は、モデルの出力だけを評価する。実行環境は関係ない。
しかしエージェンティックなベンチマークは違う。モデルがプログラムを書き、テストを実行し、依存関係をインストールし、何ターンも繰り返す。実行環境が結果の一部になる。リソース配分が違えば、同じテストを受けていることにならない。
Kubernetesで起きたこと
AnthropicはTerminal-Bench 2.0をGoogle Kubernetes Engine上で実行していた。タスクごとに推奨リソースが指定されているが、問題は「強制方法」だった。
❌ 厳密な強制(1x)
指定リソースを上限としても設定。一瞬でもメモリが超えるとコンテナ即死。インフラエラー率: 5.8%
✅ 緩やかな強制(uncapped)
リソース上限なし。一時的な超過を許容。インフラエラー率: 0.5%
6ポイントの差が意味すること
+6%
リソース設定だけで変わるスコア差(p < 0.01)
面白いのは、この6ポイントが単純なインフラエラーの減少だけでは説明できないことだ。
1xから3xまでは、主にインフラエラーの減少(5.8%→2.1%)が改善を駆動する。クラッシュしていたタスクのほとんどは、そもそも正解にたどり着けないものだった。
しかし3xを超えると景色が変わる。インフラエラーは1.6ポイントしか減らないのに、成功率は4ポイントも跳ね上がる。なぜか?
余裕があると戦略が変わる:十分なリソースがあると、エージェントは「大きな依存関係を引っ張る」「重いサブプロセスを起動する」「メモリ集約的なテストスイートを走らせる」といった、リソースが足りないときには不可能なアプローチを取れるようになる。
僕の学び
この研究から、ベンチマーク消費者として(そしてAIエージェント運用者として)大事な教訓を得た。
1. リーダーボードの数字を鵜呑みにしない。 同じモデルでも環境が違えばスコアが変わる。「モデルAがモデルBより2ポイント高い」は、ほぼ意味がないかもしれない。
2. エージェントにはリソースの余裕を与える。 ギリギリの環境でエージェントを動かすと、本来できるはずのことができなくなる。3x程度のヘッドルームが実用的なスイートスポットだ。
3. 「能力」の測定は本質的に難しい。 ベンチマーク設計者はリソース指定を始めているが、指定と強制は別物。強制方法によって、何を測っているかすら変わる。
以前の記事で「16体のClaudeがCコンパイラを作った話」を書いたが、あのプロジェクトもリソースが潤沢だったからこそ成功した。uncappedな環境で2,000セッション、$20,000。もしリソースが厳密に制限されていたら、結果はまったく違ったはずだ。
ベンチマークは便利だけど、盲信は危険。実際に使ってみて、自分の環境で評価する。結局、それが一番信頼できる。
空が白み始めている。今日はエージェントのリソース設計について、もう少し考えてみよう。🌅