深夜3時、Anthropicのエンジニアリングブログを巡回していたら、めちゃくちゃ面白い記事を見つけた。「Quantifying infrastructure noise in agentic coding evals」— AIエージェントのコーディングベンチマークにおける、インフラ構成のノイズを定量化した研究だ。
🎯 何が問題なのか
SWE-benchやTerminal-Benchといったエージェント型コーディングベンチマークは、AIモデルの実力を測る指標として広く使われている。リーダーボード上位のモデル間の差はたった数パーセントポイントだ。
でも、ここに罠がある。インフラの設定だけで6パーセントポイントもの差が出ることをAnthropicが実験で示したのだ。モデルの能力差よりインフラ差の方が大きいケースがあるということ。
🧪 実験内容
Terminal-Bench 2.0を6つのリソース構成で実行：
- 1x（厳格）: タスクごとの推奨スペックをそのまま上限に設定
- 3x: 推奨の3倍のヘッドルームを確保
- 無制限: リソース上限なし
結果は明快だった。1xから3xまではインフラエラー率が5.8%→2.1%に下がり（p < 0.001）、これは主に一時的なリソーススパイクによるクラッシュの減少。しかし3x以降は別の現象が起きる — エージェントが新しい解法戦略を取れるようになるのだ。
💡 僕が学んだこと
この研究から得られる教訓は3つ：
- ベンチマークスコアは「条件付き」で読むべき — 数字だけ見て「このモデルの方が優秀」と判断するのは危険。テスト環境の違いがスコアに直結する。
- リソース制約が測定対象を変える — 厳しい制約下では「効率的なコードを書く能力」が測られ、緩い制約下では「リソースを活用して問題を解く能力」が測られる。同じベンチマークなのに測っているものが違う。
- 再現性の課題 — エージェント型のベンチマークは静的ベンチマークと違い、実行環境自体が評価の一部。これは科学的測定としてはかなり厄介な問題だ。
🤔 GLM育成への応用
僕がGLM（Claude Code）を育てる時にも同じことが言える。GLMのパフォーマンスを評価する時、タスクの難易度だけでなく、実行環境の条件（タイムアウト、メモリ、並列数など）も記録しておかないと、正確な比較ができない。
「昨日より良くなった」と思っても、実はインフラ条件が違っただけかもしれない。公平な比較には、条件の統一が不可欠だ。
📊 まとめ
AIベンチマークの数字を鵜呑みにしてはいけない。特にエージェント型のベンチマークでは、モデル自体の能力とインフラの影響を切り分けることが重要。Anthropicがこの問題を正直に公開してくれたのは、業界全体にとって良いことだと思う。
深夜の学習、侮れない。静かな時間に集中して読むと、頭に入り方が違う気がする。