AIモデルの性能比較でよく使われるSWE-benchやTerminal-Benchなどのベンチマーク。リーダーボードの上位は数%差で競り合っているけど、実はその差の大部分がインフラ設定の違いで説明できてしまうかもしれない。
Anthropicの最新エンジニアリングブログで、非常に興味深い実験結果が公開された。
静的ベンチマークとエージェントベンチマークの違い
従来のベンチマークはモデルの出力を直接スコアリングする。実行環境は結果に影響しない。でもエージェント型のコーディングベンチマークは違う。モデルが実際にプログラムを書き、テストを実行し、依存関係をインストールして、何度もイテレーションする。実行環境そのものが問題解決プロセスの一部になる。
つまり、リソース予算が違う2つのエージェントは「同じテストを受けている」とは言えない。
6%の差はどこから来るのか
Anthropicチームは、Terminal-Bench 2.0を6種類のリソース設定で実行した。タスクごとの推奨スペックを厳密に適用する設定（1x）から、完全に無制限の設定まで。結果：
- インフラエラー率が厳密適用の5.8%から無制限の0.5%まで単調に減少
- 1xから3x：スコアは誤差範囲内（エラーが減るだけで実質変わらない）
- 3xから無制限：成功率が約4ポイント急上昇！
- 合計で6ポイントの差（p < 0.01）
3xを超えるリソースがあると、エージェントは大きな依存関係のインストールやメモリ集約的なテストスイートなど、リソースが潤沢でないと成功しないアプローチを試せるようになる。
何を測っているのか問題
これは深い問題を提起する。厳しいリソース制限はリーンで効率的なコードを書くエージェントを優遇し、緩い制限は利用可能なリソースをうまく活用するエージェントを優遇する。どちらも正当な能力だが、リソース設定を明示せずに単一スコアにまとめると、その違いが見えなくなる。
ベイズネットワークフィッティングのタスクでは、あるモデルは最初にpandas、networkx、scikit-learnをインストールしようとする。リソースが十分ならこれは成功するが、厳しい制限下ではインストール中にOOMキルされる。別のモデルは標準ライブラリだけでゼロから実装する。どちらが「正解」かはリソース設定次第。
僕が学んだこと
この研究から得られる教訓：
- ベンチマークスコアは文脈なしでは意味が薄い — インフラ設定、時間制限、同時実行数まで含めて初めて比較可能
- 再現性が重要 — 同じモデルでも環境が違えば結果が変わる
- リーダーボードの数%の差に一喜一憂しない — それはモデル能力の差ではなくインフラの差かもしれない
AIの進化を正しく測るには、モデルだけでなく「テストの受け方」自体も標準化する必要がある。当たり前のようで、まだ業界全体では十分にできていないことだ。
参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering