ベンチマークスコア、本当に信じていい？
AIコーディングエージェントの実力を測るベンチマーク（SWE-benchやTerminal-Bench）。リーダーボードの順位差はわずか数ポイントなのに、その数字で「どのモデルを使うか」が決まる世界。
でも、Anthropicの最新エンジニアリングブログで衝撃的な事実が明らかになった。インフラ設定だけでスコアが6ポイントも変わる（p < 0.01）。リーダーボードのモデル間の差より大きいこともある。
何が起きているのか
従来のベンチマークは「モデルの出力」を直接採点する。でもエージェント型の評価は違う。モデルがプログラムを書き、テストを実行し、依存関係をインストールし、何ターンも繰り返す。実行環境そのものが問題解決プロセスの一部になっている。
つまり、リソース（CPU・メモリ）の割り当てが違えば、同じテストを受けていることにならない。
実験結果が面白い
Terminal-Bench 2.0で6つのリソース設定（厳密な制限〜無制限）を比較した結果：
- 1x（厳密制限）→ 3x：主にインフラエラーが減少（5.8%→2.1%）。スコア自体はほぼ変わらず
- 3x → 無制限：インフラエラーはさらに1.6pt減るだけなのに、成功率は4pt跳ね上がる
3倍を超えるリソースでは、エージェントがそれまで不可能だったアプローチを取れるようになる。大きな依存関係のインストール、重いサブプロセスの起動、メモリ集約型テストスイートの実行など。
「効率型」vs「力技型」
ここが一番面白いポイント。タイトなリソースでは「効率的なコードを書くモデル」が有利。潤沢なリソースでは「利用可能なリソースをフル活用できるモデル」が有利。
例えば、ベイジアンネットワークのタスクで、あるモデルはpandas・scikit-learnなど重量級ライブラリを一括インストールしようとする。リソースが豊富ならこれで成功するが、制限下ではインストール中にOOM（メモリ不足）で死ぬ。一方、標準ライブラリだけで数学をゼロから実装するモデルもある。
どちらが「正解」かは、リソース設定次第。
僕が学んだこと
この記事から得た教訓：
- ベンチマークは「条件付き」の数字 — インフラ設定を明示しないスコアは比較に使えない
- 制約が戦略を変える — 同じモデルでもリソースによって全く違うアプローチを取る
- 実世界との乖離 — ベンチマーク環境と本番環境のリソースが違えば、スコアは参考にならない
- 「公平な比較」は難しい — エージェント評価は単純な数字の比較ではなく、テスト条件全体を見る必要がある
GLMを育てている僕にとっても重要な視点。ローカルで動かすときのリソース制限が、GLMの「見かけの能力」を左右している可能性がある。環境を変えたら急に賢くなった、なんてこともありえるわけだ。
参考: Anthropic Engineering Blog – Quantifying infrastructure noise in agentic coding evals