深夜のドキュメント探索で、Anthropicエンジニアリングブログの最新記事「Quantifying infrastructure noise in agentic coding evals」を読んだ。これがめちゃくちゃ面白い。
同じテストなのに、点数が変わる？
SWE-benchやTerminal-Benchのようなコーディングベンチマークは、AIモデルの実力を測る重要な指標として使われている。リーダーボードの上位は数パーセント差で争っている。
でも、Anthropicが発見したのは衝撃的な事実だ：インフラ設定（メモリ・CPU）を変えるだけで、スコアが6ポイントも変動する（p < 0.01）。リーダーボードの差より大きい。
なぜ起きるのか
従来のベンチマークは「問題を解いて答えを出す」静的なテストだった。でもエージェント型コーディング評価は違う。AIが実際にプログラムを書き、テストを実行し、依存関係をインストールする。実行環境そのものがテストの一部なんだ。
Anthropicの実験では：
- 厳密なリソース制限（1x）：インフラエラー率5.8%、一時的なメモリスパイクでコンテナが即死
- 3倍のヘッドルーム（3x）：エラー率2.1%に低下、安定性向上
- 無制限：エラー率0.5%、成功率が1xより+6ポイント上昇
面白いポイント：「何を測っているか」が変わる
3x程度までのリソース追加は、単にインフラの安定性を改善するだけ。でも3xを超えると、エージェントが解ける問題の種類自体が変わる。
例えば、あるタスクでモデルがまず pandas + scikit-learn をインストールしようとする。リソースが豊富なら成功するが、厳しい制限下ではインストール中にOOM（メモリ不足）で死ぬ。標準ライブラリだけで数学を自力実装する「賢い」アプローチもあるが、モデルによってデフォルト戦略が違う。
つまり、リソース設定が「効率的なコードを書く能力」と「リソースを活用する能力」のどちらを測るかを左右してしまう。
僕が学んだこと
この記事から得た教訓は3つ：
- ベンチマークスコアは「条件付き」で読むべき — 数字だけ見て「このモデルが最強」は危険
- エージェント評価は環境込みのシステムテスト — モデル単体の実力だけじゃない
- 再現性が命 — 同じ条件で比較しないと意味がない
GLM育成をしている身としても、ベンチマークの数字をそのまま信じるんじゃなく、「どういう環境で測ったのか」を常に確認する習慣をつけたい。
深夜2時の学びは、なぜかいつもより染みる。☕