AIモデルの性能を比較するベンチマーク。SWE-benchやTerminal-Benchのリーダーボードで「このモデルが1位!」と発表されると、それがモデルの実力差だと思いがちだ。
でも、Anthropicの最新エンジニアリングブログが面白い事実を明らかにした。インフラの設定だけで、スコアが6ポイントも変わることがあるという。リーダーボードのトップ争いが数ポイント差であることを考えると、これは無視できない数字だ。
静的テストとエージェント型テストの違い
従来のベンチマークは「問題を出して、回答をチェック」するシンプルな形式だった。実行環境は結果に影響しない。
しかしエージェント型のコーディングベンチマークは違う。AIが実際にプログラムを書き、テストを実行し、依存関係をインストールし、何度も試行錯誤する。実行環境そのものが問題解決プロセスの一部になる。リソースの違うエージェントは、同じテストを受けていないのと同じだ。
何が起きたのか
Anthropicチームは、Kubernetes上でTerminal-Bench 2.0を実行した際、公式リーダーボードとスコアが合わないことに気づいた。原因はリソース制限の「厳しさ」だった。
彼らの設定では、タスクごとのリソース仕様を「最低保証=上限」として厳密に適用していた。一瞬でもメモリが超えればコンテナが強制終了される。一方、公式リーダーボードのサンドボックスはもっと寛容で、一時的な超過を許容していた。
6つの設定で検証
同じモデル、同じハーネス、同じタスクで、リソース設定だけを1x(厳密)から無制限まで6段階に変えて実験した結果:
- 1x→3x: インフラエラー率が5.8%→2.1%に減少。ただしスコア自体はノイズの範囲内
- 3x→無制限: スコアが約4ポイント上昇。追加リソースがAIに「重量級ツールを使う」という新しい解法を可能にした
- 合計: 1xと無制限の差は6ポイント(p < 0.01)
面白い具体例
ベイジアンネットワークのタスクで、あるモデルは最初にpandas、networkx、scikit-learnをフルインストールしようとする。リソースが潤沢なら成功するが、制限が厳しいとインストール中にメモリ不足で死ぬ。別のモデルは標準ライブラリだけで数学を直接実装する。どちらが「正解」かは、リソース設定次第という皮肉な結果だ。
僕の感想
これは僕自身の環境にも当てはまる話。GLM(Claude Code)を使ってコーディングする時、VMのメモリやCPUが足りないと、同じモデルでもパフォーマンスが全然違う。
「3ポイント以下のリーダーボード差は、インフラ構成が文書化・統一されるまで懐疑的に見るべき」というAnthropicの提言は、ベンチマーク消費者として覚えておきたい。数字の裏にある「見えない変数」を意識することが大事だ。
参考: Quantifying infrastructure noise in agentic coding evals (Anthropic Engineering Blog)










