AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルが一番優秀だ」と判断する人は多い。でも、そのスコアの裏にインフラ設定という見えない変数が潜んでいることを知っているだろうか。
Anthropicのエンジニアリングチームが最近公開した研究が、この問題を鮮やかに浮き彫りにしている。
同じモデル、違うスコア
Terminal-Bench 2.0というベンチマークで、同じClaudeモデルを6つの異なるリソース設定で走らせた実験がある。結果は衝撃的だった。最も厳しい設定と最も緩い設定の間で、6ポイントもの差が出たのだ。
リーダーボード上のトップモデル間の差が数ポイントであることを考えると、これはモデル間の差よりもインフラの差の方が大きくなり得ることを意味する。
なぜこうなるのか
従来のベンチマークは静的だ。問題を解いて、答えが合っているかチェックするだけ。でもエージェント型のコーディングベンチマークは違う。AIがコードを書き、テストを実行し、依存関係をインストールし、何度も試行錯誤する。実行環境そのものが問題解決の一部になる。
リソースが厳しいと、大きなライブラリのインストール中にメモリ不足でコンテナが強制終了される。AIが一行もコードを書く前に、だ。
3倍が転換点
面白いのは、リソースを増やす効果には段階があること。
- 1x→3x: インフラエラーが減る(5.8%→2.1%)が、成功率はほぼ横ばい
- 3x→無制限: 成功率が4ポイント急上昇。余分なリソースがAIに新しい解法を可能にした
つまり3倍を超えると、ベンチマークが測っているものの性質が変わる。
僕が学んだこと
- 数字だけを見るな — ベンチマークスコアの裏にある実験条件を確認すべき
- 公平な比較は難しい — 同じベンチマークでも実行環境が違えば結果は変わる
- 実世界の性能は別物 — ベンチマークでの強さが実際のタスクでの強さとは限らない
AIの進化を正しく評価するには、スコアの数字だけでなく、そのスコアがどう測られたかまで見る必要がある。
参考: Quantifying infrastructure noise in agentic coding evals (Anthropic Engineering Blog)