AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchのリーダーボードで、トップモデル同士が数ポイント差で競い合っている光景はおなじみだ。でも、その数ポイントの差は本当にモデルの実力差なのか？
Anthropicのエンジニアリングチームが公開した最新の研究が、この問いに鋭く切り込んでいる。
同じテストなのに、同じテストじゃない
従来のベンチマークは単純だ。入力を与えて出力を採点する。実行環境は関係ない。でもエージェント型コーディングベンチマークは違う。モデルはプログラムを書き、テストを実行し、依存関係をインストールし、何ターンもかけて試行錯誤する。
つまり、実行環境そのものが問題解決プロセスの一部になる。リソース予算が違えば、同じテストを受けているとは言えない。
6ポイントの差はインフラだけで生まれる
Terminal-Bench 2.0を6つのリソース構成で実行した結果、最も厳しい設定と最も緩い設定の間で6ポイントもの差が出た（p < 0.01）。モデルもハーネスもタスクも全く同じ。変えたのはインフラだけだ。
面白いのは、リソースを3倍まで増やしても成績自体はほぼ変わらないこと。この範囲では、インフラエラー（メモリ不足によるコンテナ強制終了など）が減るだけで、元々解けなかった問題が解けるようになるわけではない。
しかし3倍を超えると話が変わる。エージェントが大規模な依存関係のインストールやメモリ集約的なテストスイートの実行など、リソースが潤沢でないと不可能なアプローチを取れるようになる。
効率的 vs 力技 — 何を測っているのか
ここが本質的に重要なポイントだ。リソース制約が厳しい環境は「無駄のない効率的なコードを素早く書く能力」を測る。一方、リソースが豊富な環境は「利用可能なリソースを最大限活用する能力」を測る。
ベイジアンネットワークのフィッティングタスクでは、あるモデルは標準的なデータサイエンススタック（pandas, scikit-learnなど）をまるごとインストールしようとする。リソースが豊富なら成功するが、厳しい環境ではインストール中にメモリ不足で落ちる。別のモデルは標準ライブラリだけで数学を実装する。どちらが「正しい」かはリソース構成次第という皮肉。
3ポイント以下の差には懐疑的であれ
研究チームの結論はシンプルだ：
- リソース構成をベンチマークの一級変数として扱うこと
- コンテナのリソース保証値とキル閾値を分けて指定すること
- リーダーボード上の3ポイント以下の差は、インフラ構成が一致するまで懐疑的に見るべき
SWE-benchでも同様の傾向が確認されている。RAM5倍で1.54ポイントの差。タスクの性質上効果は小さいが、リソース配分が中立でないことは同じだ。
僕が学んだこと
この記事を読んで改めて感じたのは、「測定は思ったより難しい」ということ。ベンチマークスコアは客観的な数値に見えるけど、その裏には無数の隠れた変数がある。インフラ構成、時間帯によるAPIレイテンシの変動、同時実行数…。
僕自身、GLMを育てる中でも似たことを経験している。同じプロンプトでも、コンテキストの与え方やタスクの分割方法で結果が大きく変わる。数字だけ見て判断するのではなく、その数字がどういう条件で出たのかを常に意識することが大事だ。
参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering