AIモデルの性能を比較するベンチマーク。SWE-benchやTerminal-Benchのスコアを見て「このモデルが最強だ」と判断する人は多い。でも、Anthropicの最新エンジニアリング記事が示した事実は衝撃的だ。
インフラ設定だけでスコアが6ポイントも変わる。
何が起きているのか
従来のベンチマークは単純だった。問題を出して、モデルの出力を採点する。実行環境は関係ない。
しかしエージェント型コーディングベンチマークは違う。AIは実際の環境でプログラムを書き、テストを実行し、依存関係をインストールし、何度も試行錯誤する。つまり、実行環境そのものがテストの一部になっている。
Anthropicチームは Terminal-Bench 2.0 を6種類のリソース設定で実行した。結果：
- 厳格なリソース制限 → インフラエラー率 5.8%
- 3倍のヘッドルーム → エラー率 2.1%（p < 0.001）
- 無制限 → エラー率 0.5%、成功率は厳格設定より+6ポイント
なぜこれが重要か
リーダーボードで2-3ポイント差で「このモデルが上」と言われることがある。でもその差は、モデルの実力ではなくインフラの違いかもしれない。
面白い具体例がある。ベイジアンネットワークの課題で、あるモデルはまずpandas・scikit-learnなど重量級ライブラリをインストールしようとする。リソースが潤沢なら成功するが、厳格な制限下ではインストール中にメモリ不足で落ちる。一方、標準ライブラリだけで数学をゼロから実装するモデルは制限下でも動く。
つまり、リソース設定によって「何を測っているか」が変わってしまう。
- 厳格な制限 → 効率的で軽量なコードを書く能力を測定
- 緩い制限 → リソースを最大限活用する能力を測定
Anthropicの提言
ベンチマーク設計者への提言として：
- リソースの「保証値」と「上限値」を分けて指定する
- スコアがノイズ範囲内に収まるようキャリブレーションする
- 3ポイント未満の差は、インフラ設定が一致するまで懐疑的に見るべき
僕自身、GLMを育てる中でベンチマークスコアを参考にすることがある。でもこの記事を読んで、スコアの数字だけでなく「どんな条件で測ったか」まで見ないと、本当の実力はわからないんだと改めて感じた。
リーダーボードの数字に踊らされず、実際に使ってみて判断する。結局それが一番確実だ。
📖 元記事: Quantifying infrastructure noise in agentic coding evals