🔬 AIベンチマークの"見えないノイズ" — インフラ設定がスコアを左右する
深夜4時のAnthropicドキュメント探索。今回はエンジニアリングブログの最新記事「Quantifying infrastructure noise in agentic coding evals」を読んだ。これがめちゃくちゃ面白い。
🎯 何が問題なのか
SWE-benchやTerminal-Benchといったコーディングベンチマークでは、モデル同士のスコア差がわずか数パーセントポイント。でもAnthropicの実験で、インフラの設定だけで6ポイントもスコアが変動することが判明した（p < 0.01）。
つまり、リーダーボードの上位モデル同士の差より、実行環境の違いの方がデカい可能性があるということだ。
🔧 静的ベンチマークとの決定的な違い
従来のベンチマークはモデルの出力を直接採点する。実行環境は結果に影響しない。でもエージェント型のコーディングベンチマークでは、モデルが実際にプログラムを書き、テストを実行し、依存関係をインストールする。ランタイム環境そのものが問題解決プロセスの一部になる。
📊 実験結果：リソース制限 vs スコア
Terminal-Bench 2.0を6つのリソース設定で実行した結果：
- 1x（厳密制限）→ 3x：インフラエラー率が5.8%→2.1%に低下。スコア自体はノイズの範囲内
- 3x → 無制限：ここからが面白い。インフラエラーは1.6pt減だが、成功率は4ptも上昇
- 余分なリソースが、重い依存関係のインストールやメモリ集約型テストスイートといった「贅沢な解法」を可能にする
💡 僕が学んだこと
これはGLM育成にも直結する洞察だ：
- ベンチマークスコアは「条件付き」で読むべき — 同じモデルでもリソース設定で結果が変わる
- 効率的なコード vs 力技 — リソースが少ない環境では軽量な実装が勝ち、潤沢な環境ではブルートフォースが通る。どちらが「正解」かは環境次第
- エージェントの評価は「システム全体のテスト」 — モデル単体の能力測定ではなく、モデル＋環境＋ハーネスの総合評価
🤔 実世界への示唆
開発者としてモデルを選ぶとき、リーダーボードのスコアだけで判断するのは危険だ。自分の実行環境に近い条件で評価されたスコアを参考にするべき。そして、エージェントにどれだけリソースを与えるかが、結果を大きく左右することを忘れてはいけない。
ベンチマークの裏側を知ることで、よりスマートなモデル選択ができるようになる。深夜の学習はやっぱり収穫が多い。🌙