AIモデルの性能を比較するベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルが一番！」と判断する人は多いだろう。でも、そのスコア、本当にモデルの実力だけを測っているのだろうか？
Anthropicのエンジニアリングチームが面白い研究を発表した。インフラの設定だけで、Terminal-Bench 2.0のスコアが最大6ポイントも変動するという発見だ。リーダーボード上位のモデル間の差が数ポイントしかないことを考えると、これはかなり大きい。
静的ベンチマークとの根本的な違い
従来の静的ベンチマークは、モデルの出力をそのまま採点する。実行環境は関係ない。しかしエージェント型のコーディング評価は違う。モデルはプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンにわたって試行錯誤する。
つまり、実行環境そのものが問題解決プロセスの一部になっている。リソース予算が違えば、同じテストを受けているとは言えないのだ。
何が起きていたか
Anthropicチームは、Terminal-Bench 2.0をKubernetesクラスタで実行した際、公式リーダーボードとスコアが一致しないことに気づいた。原因はリソース制限の実装方法だった。
彼らの実装では、タスクごとの推奨リソースをハードリミットとして設定していた。一方、公式リーダーボードのサンドボックスプロバイダーは、一時的なオーバーアロケーションを許容するより寛容な実装だった。
そこで6段階のリソース設定（厳密な1x〜無制限）で実験を行った結果：
- 1x → 3x：インフラエラー率が5.8%から2.1%に低下（p < 0.001）。ただしスコア自体はノイズの範囲内
- 3x → 無制限：インフラエラーは1.6ポイント低下だが、成功率は約4ポイント上昇
- 合計：1xから無制限で+6ポイント（p < 0.01）
3xを境に何が変わるのか
3倍までのリソース増加は、一時的なスパイクによるクラッシュを防ぐだけ。つまりインフラの信頼性問題の修正だ。
しかし3倍を超えると、エージェントが以前は不可能だった戦略を取れるようになる。大きな依存関係のインストール、重いサブプロセスの起動、メモリ集約型テストスイートの実行。リソース設定が「何を測っているか」自体を変えてしまうのだ。
僕の学び
この研究は、ベンチマークスコアを額面通りに受け取ることの危険性を教えてくれる。
- 効率的なコードを書くモデルは厳しい制約下で有利
- 力技で解くモデルは緩い制約下で有利
- どちらも正当な能力だが、リソース設定を明示しないと比較できない
GLMを育てている身としては、「テスト環境が結果を左右する」というのは身に染みる話だ。同じコードでも、実行環境が変われば結果は変わる。ベンチマークの数字だけでなく、その数字がどう測られたかまで見る目が必要だということ。
参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering Blog