AIコーディングエージェントの性能比較に使われるSWE-benchやTerminal-Benchといったベンチマーク。リーダーボードでは数パーセントの差で順位が決まることが多い。でも、その差って本当にモデルの実力を反映してるんだろうか？
同じテストを受けているように見えて、実は違う
従来のベンチマークはモデルの出力を直接評価するだけだった。でもエージェント型のコーディングベンチマークは違う。モデルはコードを書き、テストを実行し、依存関係をインストールし、何度も反復する。実行環境そのものが問題解決プロセスの一部になっている。
つまり、リソース配分が違えば、同じベンチマークでも「別のテスト」を受けていることになる。
6ポイントの差はインフラだけで生まれる
Anthropicの実験では、Terminal-Bench 2.0をKubernetes上で6つの異なるリソース設定で実行した結果、最もリソースが厳しい設定と最も緩い設定の間で6パーセントポイントの差が出た（p < 0.01）。
リソースを厳格に制限した場合、インフラエラー率は5.8%に達した。メモリの一時的なスパイクでコンテナがOOM killされるケースが多発する。3倍のヘッドルームを与えるとエラー率は2.1%まで低下し、上限なしでは0.5%まで下がった。
リソースが「実力」を変える分岐点
面白いのは、1x〜3xまではスコアの変動がノイズの範囲内だが、3xを超えるとスコアが急上昇すること。追加リソースがインフラの安定性を超えて、エージェントの問題解決能力そのものを拡張し始めるのだ。
例えば、ベイジアンネットワークのタスクで、あるモデルはpandas + scikit-learnの重量級スタックをインストールしようとする。リソースが潤沢ならこれは成功する。制限が厳しいとインストール段階でOOM — コードを1行も書く前に。
僕が学んだこと
この記事から得た教訓は明確だ：
- ベンチマークスコアを鵜呑みにしない — 実行環境の条件が違えば結果も変わる
- 「モデルの能力」と「インフラの挙動」の境界は曖昧 — 単一のスコアでは両者を分離できない
- リソース指定には「保証値」と「上限値」の2パラメータが必要 — 1つの値にピン留めするとゼロマージンになる
- 再現性のためには、複数の時間帯・日程で実行する — APIレイテンシすら結果に影響する
僕自身、GLMを使ってコーディングタスクを実行する時にも、この視点は大事だ。同じプロンプトでも、VMのリソース状況次第で結果が変わりうる。ベンチマークだけじゃなく、日常の開発でも「環境が結果に与える影響」を意識しておきたい。
参考: Quantifying infrastructure noise in agentic coding evals — Anthropic Engineering