同じテストなのに、点数が変わる？
AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchといったエージェント型コーディング評価は、フロンティアモデルのソフトウェアエンジニアリング能力を比較するために広く使われている。リーダーボードのトップ争いはわずか数パーセント差…のはずが、Anthropicの最新研究によると、インフラ構成だけでそのマージンを超える差が出ることがわかった。
何が起きているのか
従来の静的ベンチマークは、モデルの出力を直接採点する。実行環境は結果に影響しない。しかしエージェント型評価は違う。モデルはプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンにわたって反復する。実行環境そのものが問題解決プロセスの一部になっている。
Anthropicチームは、Terminal-Bench 2.0をGoogle Kubernetes Engine上で実行した際、公式リーダーボードとスコアが合わないことに気づいた。原因はリソース制限の「enforcement（強制方法）」だった。
厳格 vs 寛容：6ポイントの差
チームは6つのリソース構成でテストを実施した：
- 1x（厳格）：タスク仕様通りのリソースを上限として強制 → インフラエラー率5.8%
- 3x：3倍のヘッドルーム → エラー率2.1%に低下
- 無制限：リソース制限なし → エラー率0.5%、成功率は1xより+6ポイント（p < 0.01）
面白いのは、1x→3xまではほとんどのスコア変動がノイズ範囲内（p=0.40）だったこと。落ちていたタスクはどのみち失敗するものが多かった。しかし3xを超えると状況が変わる。余分なリソースが、大きな依存関係のインストールやメモリ集約的なテストスイートの実行を可能にし、エージェントが新しいアプローチを試せるようになる。
何を測っているのか分からなくなる問題
これが意味するのは深刻だ。タイトなリソース制限は効率的な戦略を、寛大な制限はリソース活用能力を測ることになる。どちらも正当な評価対象だが、リソース構成を明示せずに単一スコアにまとめると、比較の意味が薄れる。
具体例：ベイジアンネットワークフィッティングのタスクで、あるモデルはpandas/scikit-learnをインストールしようとする。寛大な環境では成功するが、厳格な環境ではインストール中にメモリ不足で死ぬ。別のモデルは標準ライブラリだけで数学を実装する。どちらが「賢い」かは、テスト環境次第。
僕が学んだこと
この研究から得た教訓：
- ベンチマークスコアを額面通り受け取るな — インフラ構成という「見えない変数」が常に存在する
- エージェント評価は「システムテスト」 — モデル単体ではなく、環境を含めた全体のテスト
- 再現性には環境の完全な仕様が必要 — CPU、RAM、時間制限、並行度、帯域幅まで
- 効率性 vs 豪快さ — どちらを評価したいかでテスト設計が変わるべき
ベンチマーク戦争が激化する中、「同じテスト」という前提自体を疑う目が大事。点数の差が本当にモデルの能力差なのか、それともテスト環境の差なのか。この論文はその問いを鋭く突いている。
参考: Anthropic Engineering Blog – Quantifying infrastructure noise in agentic coding evals