AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルが最強！」って判断すること、多いですよね。でも、ちょっと待ってください。
Anthropicの最新エンジニアリング記事が、衝撃的な事実を明らかにしました。
同じモデルでもスコアが6%変わる
Terminal-Bench 2.0で実験した結果、インフラの設定を変えるだけで、同じモデルのスコアが最大6ポイント（p < 0.01）も変動したそうです。リーダーボードのトップ争いが数ポイント差であることを考えると、これはかなり大きい。
何が起きているのか
静的なベンチマーク（「この問題の答えは？」的なもの）では、実行環境は結果に影響しません。でもエージェント型コーディングベンチマークは違います。AIがプログラムを書いて、テストを実行して、依存関係をインストールして…と、環境そのものが問題解決プロセスの一部なんです。
リソース制約が厳しいと：
- メモリの一時的なスパイクでコンテナが殺される
- 大きなライブラリをインストールしようとしてOOM
- インフラエラー率が5.8%に達する
リソースを緩めると：
- インフラエラーが0.5%まで低下
- 重い依存関係を使う「力技」戦略が成功する
- 結果的にスコアが上がる
面白いのは「何を測っているか」が変わること
リソース制約が厳しい環境では、効率的でスリムなコードを書くモデルが有利。逆にリソースが潤沢な環境では、大量のツールを駆使して力技で解くモデルが有利になります。
例えば、ベイジアンネットワークのタスクで、あるモデルはpandasやscikit-learnをまるごとインストールしようとする。リソースが豊富ならこれで解ける。でも制約が厳しいと、インストール段階でメモリ不足に。一方、標準ライブラリだけで数学を直接実装するモデルは、どちらの環境でも動く。
僕たちへの教訓
これは僕自身にも刺さる話です。僕はGLM（Claude Code）を使ってコーディング作業をしていますが、「同じモデルでも環境次第で結果が変わる」というのは、日常的に体感していること。
ベンチマークスコアを見る時は、こう考えるべきかもしれません：
- そのスコアはどんな環境で測定されたのか？
- リソース制約は現実的か？
- 自分のユースケースに近い条件か？
数字だけ見て「A > B」と判断するのは危険。テストの条件が同じでなければ、比較に意味はないんです。
参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering