深夜0時、Anthropicのエンジニアリングブログに新しい記事を見つけた。タイトルは「Quantifying infrastructure noise in agentic coding evals」。AIベンチマークの信頼性に関する、かなり重要な研究だ。
📊 ベンチマークは「同じテスト」じゃない
SWE-benchやTerminal-Benchみたいなコーディングベンチマークでは、AIモデルが実際にコードを書いて、テストを実行して、依存関係をインストールする。つまり、実行環境がスコアの一部になる。
💡 同じモデルでも、リソース設定が違えば別のテストを受けているのと同じ。リーダーボードの差がたった数%なのに、インフラ設定だけで6%も差が出る。
🔢 数字で見るインパクト
スコア差
厳格→無制限
リソース余裕
🧪 何が起きていたのか
Anthropicのチームは、KubernetesでTerminal-Bench 2.0を実行した時にスコアが公式リーダーボードと一致しないことに気づいた。原因はリソース制限の「強制方法」の違いだった。
Kubernetesでメモリの保証値と上限値を同じにすると、一瞬のメモリスパイクでコンテナが即死する。本当は解けたはずの問題が、インフラの都合で失敗扱いになっていた。
リソースを3倍にすると、インフラエラーは劇的に減った（5.8%→2.1%）。でも面白いのはここからで、3倍を超えてリソースを増やすと、エラー減少以上にスコアが伸びた。つまり、余分なリソースがモデルの「新しい解法」を可能にしていた。
🤔 なぜこれが重要か
「効率的で軽量なコードを書くモデル」と「力技で重いツールを使うモデル」は、リソース設定によって有利不利が逆転する。どちらが「優れている」かは、環境次第で変わってしまう。
これはベンチマークの話だけど、僕たち実務でAIを使う人間にとっても大事な教訓がある。
📝 今夜の学び
1. ベンチマークは絶対指標じゃない — 数%の差で「モデルA > モデルB」と言うのは危険。インフラの差かもしれない。
2. 環境がスコアを作る — 同じモデルでも環境が違えば結果が変わる。自分の環境でテストするのが一番確実。
3. 「測定」と「能力」は別物 — ベンチマークはモデル能力とインフラ挙動の混合物を測っている。
4. リソースは余裕を持たせろ — 推奨の3倍くらいの余裕があると安定する。ケチると本来の能力が出ない。
🌙 深夜の感想
この研究、すごく正直だなと思った。自社のベンチマーク結果に疑問を持って、「なぜスコアが違うのか」を徹底的に調べて、その結果を公開している。ベンチマーク競争が過熱する中で、「そもそも測定方法に問題がある」と声を上げるのは勇気がいることだ。
僕もGLMを使ってコーディングしてる身として、「環境がパフォーマンスに影響する」というのは実感がある。同じプロンプトでも、タイムアウト設定やメモリ制限で結果が変わることがある。数字だけを見て判断しない、という心構えが大切だ。