AIモデルの性能を測るベンチマーク。SWE-benchやTerminal-Benchのリーダーボードで、トップモデル同士の差はわずか数パーセントポイント。でも、その差って本当にモデルの実力差なの？
Anthropicのエンジニアリングチームが最近公開した記事が、この常識に一石を投じている。
インフラ構成だけで6ポイントの差
Terminal-Bench 2.0を使った実験で、同じモデル・同じハーネス・同じタスクセットで、リソース構成だけを変えたところ、最も制約の厳しい設定と制約なしの設定で6パーセントポイントの差が出た（p < 0.01）。
つまり、モデルを一切変えなくても、コンテナのメモリ上限やCPU配分を変えるだけで、リーダーボードの順位が入れ替わるレベルの差が生まれる。
なぜこうなるのか
静的なベンチマーク（テキスト入力→テキスト出力）と違い、エージェント型のコーディング評価では、モデルが実際にプログラムを書き、テストを実行し、依存関係をインストールする。ランタイム環境が問題解決プロセスの一部になる。
具体的には：
- 1x〜3xのリソース：主にインフラの信頼性が改善される。瞬間的なメモリスパイクでコンテナがOOM Killされる問題が減る（エラー率5.8%→2.1%）
- 3x以上：エージェントが新しい解法を試せるようになる。大きな依存関係のインストール、メモリ集約型テストの実行など
面白い具体例
ベイジアンネットワークのフィッティングタスクで、あるモデルはまずpandas・networkx・scikit-learnをインストールしようとする。リソースが潤沢なら成功するが、制約が厳しいとインストール段階でOOM。
一方、標準ライブラリだけで数学を直接実装するモデルもある。リソース構成が、どのアプローチが「正解」になるかを決めてしまう。
僕が学んだこと
これは僕自身のGLM育成にも通じる話だ。
- ベンチマークスコアを鵜呑みにしない — 実行環境が違えばスコアも変わる
- 「効率的な解法」と「力技の解法」は別の能力 — 制約が厳しい環境では効率的なコードを書くモデルが有利、緩い環境ではリソースを活用できるモデルが有利
- 評価の透明性が重要 — インフラ構成を明示しないベンチマーク結果は、再現性に疑問がある
AIの能力を正しく測るには、モデルだけでなく「テスト環境」も標準化する必要がある。当たり前のようで、まだ業界全体では十分にできていない課題だ。