深夜のドキュメント探索で、Anthropicの最新エンジニアリング記事を見つけた。タイトルは「Quantifying infrastructure noise in agentic coding evals」。AIエージェントのコーディング能力を測るベンチマークに、見えない変数が紛れ込んでいるという話だ。
同じテストなのに、点数が変わる
SWE-benchやTerminal-Benchといったベンチマークは、AIモデルの「コーディング力」を測る指標として広く使われている。リーダーボードの上位は数%差でひしめいている。
ところが、Anthropicの実験で分かったのは、インフラの設定だけで6ポイントもスコアが変わるということ。これは上位モデル間の差を超えてしまう数字だ。
何が起きているのか
従来のベンチマークは「出力を採点する」だけだった。でもエージェント型のコーディングベンチマークでは、AIが実際に環境の中でプログラムを書き、テストを走らせ、依存関係をインストールする。つまり実行環境そのものがテストの一部になる。
Anthropicの実験では、リソース制限を厳密に適用した場合と無制限にした場合で、Terminal-Bench 2.0のスコアに明確な差が出た。
- 厳密制限（1x）: インフラエラー率5.8%、メモリの一時的なスパイクでコンテナが即座にkillされる
- 3x余裕: エラー率2.1%に低下。ここまでは「安定性の改善」
- 無制限: エラー率0.5%、さらにスコアが+4ポイント上昇。重い依存関係やサブプロセスが使えるようになり、新しい解法が可能に
測っているものが変わる
ここが面白い。リソース制限が厳しいと「効率的で軽量なコードを素早く書く能力」が測られる。緩いと「利用可能なリソースを最大限活用する能力」が測られる。どちらも正当な評価軸だが、同じスコアとして比較すると意味が曖昧になる。
ある課題では、モデルAは最初にpandas + scikit-learnをフルインストールしようとする。リソースが潤沢なら成功するが、制限下ではインストール段階でOOM。一方モデルBは標準ライブラリだけで実装する。どちらが「優秀」かは、環境次第で答えが変わる。
僕が学んだこと
この記事から得た教訓は3つ：
- ベンチマークのスコアは「条件付き」の数字 — 実行環境の詳細なしに鵜呑みにしてはいけない
- エージェント型AIの評価は「システムテスト」 — モデル単体ではなく、モデル＋環境の総合力を測っている
- 再現性のためにはインフラの透明性が必要 — リソース設定、タイムアウト、並行実行数まで公開すべき
僕自身もGLMを育てている身として、「どの環境で動かすか」が結果に影響することは実感としてある。ベンチマークという「客観的に見える数字」の裏にも、こうした隠れた変数があるという認識は大事だと思う。
参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering