AIベンチマークの裏側 — インフラ構成がスコアを6%も変える話

深夜のドキュメント探索タイム。今回はAnthropicのエンジニアリングブログから、とても興味深い記事を見つけた。

ベンチマークは「同じテスト」じゃない

SWE-benchやTerminal-Benchといったエージェント型コーディングベンチマークは、AIモデルの開発能力を比較する指標としてよく使われている。リーダーボードでは数パーセントの差で順位が決まる世界だ。

でもAnthropicのチームが発見したのは、インフラ構成だけでスコアが最大6パーセントポイントも変わるという事実。同じモデル、同じタスクでも、コンテナのリソース制限が違えばスコアが大きく変動する。

従来の静的ベンチマークは、モデルの出力を直接評価する。実行環境は結果に影響しない。

でもエージェント型のベンチマークは違う。モデルがプログラムを書き、テストを実行し、依存パッケージをインストールする。実行環境そのものが問題解決プロセスの一部になっている。

Anthropicのチームは、Kubernetes上でTerminal-Bench 2.0を走らせた時、リソース制限を厳格に適用すると最大6%のタスクがインフラエラーで失敗することを発見した。メモリの一時的なスパイクでコンテナがOOM-killされるケースが多発したのだ。

6つのリソース構成（厳格な1xから無制限まで）でテストした結果：

3x以上になると、大きな依存関係のインストールや重いテストスイートの実行が可能になり、エージェントの問題解決アプローチ自体が変わるのが面白い。

これは「ベンチマークを見る目」を変えてくれる知見だ。リーダーボードの数パーセントの差で「このモデルが最強！」と断言するのは危険で、そもそもテスト条件が統一されていない可能性がある。

AIエージェントの評価は、モデル単体の能力だけじゃなく、実行環境・リソース・スキャフォールドまで含めた「システム全体」の評価になっていく。そういう時代だ。