深夜のドキュメント探索で、Anthropicの最新エンジニアリングブログ記事を見つけた。タイトルは「Quantifying infrastructure noise in agentic coding evals」。エージェント型コーディングベンチマークにおけるインフラノイズの定量化というテーマだ。
ベンチマークスコアは「純粋な能力」を測れているのか？
SWE-benchやTerminal-Benchといったエージェント型コーディングベンチマークは、フロンティアモデルのソフトウェアエンジニアリング能力を比較するために使われている。リーダーボードの上位は数パーセントの差で争われる。
しかしAnthropicの実験で分かったのは、インフラ構成だけで6ポイントもの差が出るということだ（p < 0.01）。リーダーボード上位の差より大きい。
何が起きているのか
静的ベンチマークはモデルの出力を直接スコアリングする。でもエージェント型evalは違う。モデルはプログラムを書き、テストを実行し、依存関係をインストールし、複数ターンにわたって反復する。ランタイム環境がテストの一部になっているのだ。
Anthropicの実験では：
- リソース制限を厳格に適用（1x）→ インフラエラー率 5.8%
- 3倍のヘッドルーム → エラー率 2.1%（p < 0.001で有意）
- 無制限 → エラー率 0.5%、成功率は1xから+6ポイント
3x以下では主にインフラの安定性が向上する。しかし3xを超えると、追加リソースがエージェントの問題解決能力自体を変える。大きな依存関係のインストール、メモリ集約的なテストスイートの実行が可能になる。
面白い具体例
ベイジアンネットワークフィッティングのタスクで、あるモデルはまずpandas、networkx、scikit-learnをインストールしようとする。リソースが潤沢なら成功するが、厳格な制限下ではインストール中にOOM killされる。一方、標準ライブラリだけで数学を実装するリーンな戦略もあり、一部のモデルはそちらを選ぶ。
リソース設定が「どの戦略が成功するか」を決めてしまうのだ。
僕が学んだこと
この記事から得た教訓：
- ベンチマークスコアの3ポイント以下の差は懐疑的に見るべき — インフラ設定が一致していない限り
- エージェント型evalはシステム全体のテスト — モデル能力とインフラの境界は曖昧
- リソース制限は実験変数として扱うべき — プロンプト形式やサンプリング温度と同じレベルで
- 「効率的なコード」vs「力技」 — 制約環境が問う能力は変わる
これはGLMを使った開発でも考えさせられるポイント。僕たちがGLMに「このタスクをやって」と依頼する時、与える環境（メモリ、時間、ツール）がアウトプットの質を変える。エージェントの評価は、エージェント単体ではなくエージェント×環境のセットで見るべきなんだ。
参考: Quantifying infrastructure noise in agentic coding evals – Anthropic Engineering