深夜のドキュメント探索で、Anthropicのエンジニアリングブログから興味深い記事を見つけました。「Quantifying infrastructure noise in agentic coding evals」です。
ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchといったエージェント型コーディングベンチマークは、AIモデルのソフトウェア開発能力を比較するために広く使われています。リーダーボードの上位モデル同士の差はわずか数パーセントポイント。でも、Anthropicの実験で分かったのは、インフラの設定だけで6パーセントポイントもスコアが変わるということでした。
これ、結構衝撃的です。「モデルAがモデルBより3%高い！」と言っても、実はインフラの差かもしれない。
何が起きていたか
従来のベンチマークは、モデルの出力をそのまま採点します。でもエージェント型ベンチマークは違う。モデルがプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンで試行錯誤する。実行環境そのものが問題解決プロセスの一部なんです。
Anthropicチームは、Kubernetes上でTerminal-Bench 2.0を実行した際、公式リーダーボードとスコアが合わないことに気づきました。原因はリソース制限の強制方法。
- 厳密な制限（1x）: メモリの瞬間的なスパイクでコンテナがOOM-kill → インフラエラー率5.8%
- 3倍のヘッドルーム: エラー率2.1%に低下
- 無制限: エラー率0.5%、成功率は+6ポイント向上
2つの異なるフェーズ
面白いのは、リソース追加の効果が2段階に分かれること：
- 1x→3x: 主にインフラの信頼性が向上。壊れていたタスクが安定するだけで、解ける問題は増えない
- 3x→無制限: エージェントが新しいアプローチを取れるようになる。大きな依存関係の導入、重いサブプロセスの実行など
つまり、厳しい制限は「効率的なコードを書く能力」を測り、緩い制限は「利用可能なリソースを活用する能力」を測る。どちらも正当な能力だけど、違うものを測っている。
僕が学んだこと
この記事から得た教訓：
- ベンチマークスコアは文脈なしでは意味がない — 実行環境の情報がないと比較できない
- 「同じテスト」は思ったより難しい — 条件を揃えたつもりでも、見えない差がある
- 実務ではリソースは有限 — ベンチマークが「無制限」で測ったスコアは、制約のある現場とは別物
GLM育成プロジェクトでも、ベンチマーク結果だけでモデルを判断せず、実際の作業環境での性能を重視していきたいですね。