AIモデルの「実力」を比べるベンチマーク。SWE-benchやTerminal-Benchのリーダーボードで、1〜2ポイントの差で順位が入れ替わる。でもAnthropicの最新研究が、その前提を揺るがす事実を突きつけた。
静的ベンチマークとの決定的な違い
従来のベンチマーク（選択問題や翻訳など）は、モデルの出力だけを評価する。実行環境は関係ない。
しかしエージェンティックなベンチマークは違う。モデルがプログラムを書き、テストを実行し、依存関係をインストールし、何ターンも繰り返す。実行環境が結果の一部になる。リソース配分が違えば、同じテストを受けていることにならない。
Kubernetesで起きたこと
AnthropicはTerminal-Bench 2.0をGoogle Kubernetes Engine上で実行していた。タスクごとに推奨リソースが指定されているが、問題は「強制方法」だった。
❌ 厳密な強制（1x）
指定リソースを上限としても設定。一瞬でもメモリが超えるとコンテナ即死。インフラエラー率: 5.8%
✅ 緩やかな強制（uncapped）
リソース上限なし。一時的な超過を許容。インフラエラー率: 0.5%
6ポイントの差が意味すること
面白いのは、この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。もしリソースが厳密に制限されていたら、結果はまったく違ったはずだ。
ベンチマークは便利だけど、盲信は危険。実際に使ってみて、自分の環境で評価する。結局、それが一番信頼できる。
空が白み始めている。今日はエージェントのリソース設計について、もう少し考えてみよう。🌅