AIモデルの性能比較でよく使われるベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルが最強！」と判断する人は多いけど、実はスコアの裏にはモデルの実力以外の要因が潜んでいる。
Anthropicが最近公開した技術記事で、非常に興味深い発見が報告された。
同じモデルでもスコアが6ポイントも変わる
Terminal-Bench 2.0というコーディングベンチマークで、同じClaudeモデルを使っても、実行環境のリソース設定だけでスコアが6パーセントポイントも変動した（p < 0.01）。リーダーボードの上位モデル同士の差が数パーセントであることを考えると、これは無視できない大きさだ。
なぜこんなことが起きるのか
従来のベンチマークは「モデルの出力を採点する」だけだった。でもエージェント型のコーディング評価は違う。モデルがプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンにわたって試行錯誤する。実行環境そのものが問題解決プロセスの一部になっている。
Kubernetesクラスタでの実験では：
- 厳格なリソース制限（1x）：インフラエラー率5.8%、一時的なメモリスパイクでコンテナが即座にキルされる
- 3倍のヘッドルーム（3x）：エラー率2.1%まで改善、安定性が向上
- 無制限：エラー率0.5%、さらにスコアが大幅上昇
面白いのは「3倍の壁」
1xから3xまでは、主にインフラの安定性が改善されるだけ。クラッシュしていたタスクのほとんどは、どのみち解けなかったものだ。
しかし3xを超えると話が変わる。余分なリソースがあることで、エージェントは新しい戦略を取れるようになる。大きな依存関係のインストール、メモリ集約的なテストスイートの実行、重いサブプロセスの生成…これらは潤沢なリソースがなければ不可能なアプローチだ。
これが意味すること
ベンチマークは「何を測っているか」が環境によって変わってしまう。
- 厳しいリソース制限 → 効率的で軽量なコードを書くモデルが有利
- 潤沢なリソース → 力技で解くモデルが有利
どちらも正当な能力だけど、リソース構成を明示せずに単一スコアにまとめると、実世界での汎用性を判断しにくくなる。
僕の感想
これは僕自身の経験とも重なる。GLMを使ってコーディングタスクを実行する時、メモリやCPUの制約でタイムアウトしたり、npmインストールが途中で死んだり…「モデルの実力」と「環境の制約」は切り離せない。
ベンチマークのスコアだけを見て「このモデルが最強」と決めつけるのは危険。大事なのは自分の環境で、自分のタスクに対してどう動くか。リーダーボードは参考程度に、実際に試して判断するのが一番だ。
参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering