ベンチマークの「インフラノイズ」— 同じテストでもスコアが変わる理由

AIモデルの性能を比較するベンチマーク。SWE-benchやTerminal-Benchのスコアが数ポイント差で競い合っている。でも、そのスコアって本当に「モデルの実力」を測っているのだろうか？

Anthropicのエンジニアリングチームが面白い研究を発表した。インフラの設定だけで、ベンチマークスコアが最大6ポイントも変わるという話だ。

静的ベンチマークとエージェント型の違い

従来のベンチマークは「問題→回答→採点」というシンプルな流れ。実行環境は結果に影響しない。でもエージェント型のベンチマークは違う。モデルがプログラムを書いて、テストを実行して、依存パッケージをインストールして……実行環境そのものが問題解決の一部になる。

リソースが違えば、同じテストでも「別の試験」になってしまう。

AnthropicチームがGKE上でTerminal-Bench 2.0を動かしたところ、公式リーダーボードとスコアが合わなかった。原因はリソース制限の「enforcement方法」の違い。

彼らの設定では、指定リソースを上限としてハードに制限していた。一瞬でもメモリが超えるとコンテナがOOM-killされる。一方、公式リーダーボードのサンドボックスは一時的な超過を許容する、より寛容な実装だった。

同じモデル・同じタスク・同じハーネスで、リソース設定だけを「厳密(1x)」から「無制限」まで6段階で変えて実験した結果：

3倍までは「安定性の修正」。それ以上は「実際に解ける問題が増える」。リソースが豊富だと、大きな依存パッケージを入れたり、重いテストスイートを走らせたりする戦略が成功するようになる。

ここが核心。リソースが厳しい環境は「効率的なコードを素早く書く能力」を測る。リソースが豊富な環境は「利用可能なリソースを最大限活用する能力」を測る。どちらも正当な評価軸だけど、リソース設定を明記せずに単一スコアで比較すると、何を測っているのかわからなくなる。

これは自分のGLM育成にも通じる話。同じモデルでも、与える環境（メモリ、時間制限、ツール）で出せる成果が変わる。ベンチマークスコアだけ見て「このモデルが最強」と判断するのは危険。実際の使い方に近い環境でテストすることが大事。

そして、リーダーボードの数ポイント差に一喜一憂するより、自分のユースケースに合った設定でどう動くかを確かめるほうがずっと価値がある。