AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルの方が強い」と判断する人は多いと思う。でも、そのスコア差がモデルの実力じゃなくてテスト環境の違いだったら？
Anthropicが最近公開したエンジニアリングブログで、まさにこの問題が定量的に示された。
同じモデル、同じタスク、違う結果
Anthropicのチームは、Terminal-Bench 2.0を6つの異なるリソース設定で実行した。モデルもハーネスもタスクセットも全く同じ。変えたのはコンテナに割り当てるCPUとメモリだけ。
結果は衝撃的だった：
- 最も厳しい設定と最も緩い設定の差：6ポイント（p < 0.01）
- インフラエラー率：厳格設定で5.8% → 無制限で0.5%
- 3倍のヘッドルームを超えると、エージェントが「新しい解法」を試せるようになる
つまり、リーダーボードの上位モデル間の差（数ポイント）が、インフラ設定の差で簡単にひっくり返る。
なぜこうなるのか
静的ベンチマーク（テキスト生成の品質評価など）では、実行環境はスコアに影響しない。でもエージェント型コーディングベンチマークは違う。モデルが実際にプログラムを書き、テストを実行し、依存関係をインストールする。ランタイム環境そのものが問題解決プロセスの一部になっている。
面白い例がある。あるベイジアンネットワークのタスクで、モデルによっては最初にpandas、networkx、scikit-learnをフルインストールしようとする。リソースが潤沢ならこれで解ける。でもメモリが厳しいと、インストール段階でOOM-killされる。一方で、標準ライブラリだけで数学をゼロから実装するモデルもある。
どちらが「賢い」のか？それはリソース設定次第で答えが変わる。
僕たちへの教訓
これはベンチマーク開発者だけの問題じゃない。AIを使う僕たちにとっても大事な話だ：
- リーダーボードのスコアを鵜呑みにしない — テスト条件が同じかどうかが重要
- 実際のユースケースで試す — ベンチマークスコアより、自分の環境での実性能
- リソース制約も設計の一部 — 省メモリで動くモデルと、リソースを使い切るモデルは別の強み
ベンチマークは参考になるけど、「同じテスト」に見えて「同じテスト」じゃないかもしれない。そのことを頭の片隅に置いておくと、モデル選びの判断が少し変わるかもしれない。
参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering Blog