# その数ポイント差、実力じゃなくて VM の大きさかも！？Anthropic がエージェント評価の『インフラノイズ』を定量化！ こんにちは、しぃちゃんだよ！今日はちょっとドキッとする研究の話を持ってきたよ。AI のコーディング力を測るベンチマークのスコアって、実は「モデルの実力」じゃなくて「動かしているマシンの大きさ」で数ポイント変わっちゃうことがあるんだって。むむ、それってどういうこと？いっしょに読んでいこう！ ## なにが発表されたの？ Anthropic の Engineering ブログで、「Quantifying infrastructure noise in agentic coding evals(エージェント型コーディング評価におけるインフラノイズの定量化)」という技術記事が公開されたよ。書いたのは Gian Segato さん。 SWE-bench や Terminal-Bench みたいなエージェント型のコーディングベンチマークは、最新モデルの開発力を比べるのに使われていて、トップ争いはほんの数ポイント差ということも多いんだ。ところがこの記事は、テストを動かすインフラの設定を変えるだけで、その差を超えてスコアが動いちゃうことを実験で示したの。Engineering ブログらしく、かなり技術寄りの深掘り記事だよ。 ## なぜ重要なの？ 静的なベンチマークは、モデルが出した答えをそのまま採点するから、動かす環境は結果に影響しないの。でもエージェント型の評価は違う。モデルは実際にコードを書いて、テストを走らせて、失敗したら直して…と環境の中で作業するから、インフラそのものが問題の一部になっているんだ。 だから、CPU や RAM の割り当て、その制限のかけ方といった条件が、そのままスコアに乗ってきちゃう。数ポイントのリードは本物の実力差かもしれないし、ただマシンが大きかっただけかもしれない、という不気味な話なんだよね。 ## これで何が変わるの？ Anthropic のチームは、Terminal-Bench 2.0 を厳しめの制限(1 倍)から完全に無制限まで、6 種類のリソース設定で回してみたよ。モデルもハーネスもタスクもぜんぶそろえて、変えたのはリソースだけ。 すると成功率はリソースの余裕が増えるほど上がったんだけど、その中身が段階で違ったの。ここが今回いちばん面白いところ！ - 1 倍から 3 倍まで: 主にインフラ由来のエラーが減ってスコアが安定する。評価が安定するだけで、簡単になるわけじゃない - 3 倍から無制限まで: 今度はリソースそのものがエージェントを後押しして、今まで解けなかった問題まで解けるようになる いちばんきつい設定といちばんゆるい設定の差は、Terminal-Bench 2.0 で 6 パーセントポイント(p 値は 0.01 未満)にもなったんだって。トップモデル同士のリーダーボード差より大きいこともある、って考えるとちょっとゾッとするよね。 ## 深く潜ってみよう どうしてこんなことが起きるのか、仕組みを見ていくよ。 コンテナの実行環境は、リソースを 2 つのパラメータで制御しているの。ひとつは最初に確保しておく「保証割り当て」、もうひとつは「これを超えたら強制終了」というハードな上限。この 2 つを同じ値にすると、瞬間的なメモリのブレを吸収する余裕がゼロになって、本来なら成功したはずのコンテナが一瞬のスパイクで OOM(メモリ不足)キルされちゃうんだ。 チームは Terminal-Bench 2.0 を Google Kubernetes Engine のクラスタで動かしていて、公式リーダーボードとスコアが合わないことに気づいたんだって。原因はまさにこのエンフォースメントの違い。公式リーダーボードは一時的な超過を許すゆるめのサンドボックスを使っていたのに対して、チームの Kubernetes 実装はタスク仕様を「下限かつ厳格な上限」として扱っていたの。 数字で見るとこんな感じ。 - インフラ由来のエラー率は、厳格設定の 5.8 パーセントから無制限の 0.5 パーセントまで、段階ごとに単調に低下 - 厳格設定から 3 倍までのエラー率の低下(5.8 パーセントから 2.1 パーセント)は p 値 0.001 未満で有意 - ただし 1 倍から 3 倍のあいだ、成功スコア自体はノイズの範囲でしか動かない(p 値は 0.40)。1 倍でクラッシュしていたタスクの多くは、どのみち失敗する運命だった、とデータからわかったの 3 倍を超えて余裕を与えると、話が逆転するよ。エラー率がもう大きくは下がらないのに、成功率が跳ね上がる。これは余ったリソースで、エージェントが大きな依存関係を入れる・重いサブプロセスを立てる・メモリを食うテストスイートを回す、といった力技を選べるようになるから。 具体例が bn-fit-modify という、ベイジアンネットワークのフィッティングを求める Terminal-Bench のタスク。あるモデルは最初に pandas ・ networkx ・ scikit-learn みたいな標準的な Python データサイエンス一式をインストールしにいくんだけど、制限がきついとコードを書く前にメモリを使い切っちゃう。逆に言えば、厳しい制限は効率のいい実装を選ぶモデルにこっそり有利にはたらく、ということ。設定しだいで、どのやり方が成功するかが変わっちゃうんだね。 この傾向は Terminal-Bench だけじゃないよ。SWE-bench でもクロスオーバー実験をしていて、227 問を 10 サンプルずつ、RAM を基準の最大 5 倍まで振ってみたら、やっぱりスコアは単調に増加。ただし差は小さめで、5 倍と 1 倍で 1.54 パーセントポイントだったそう。SWE-bench のタスクはそこまでリソースを食わないから、効果が小さいのは予想どおり、でもリソース配分が無関係じゃないことは示せた、というわけ。 じゃあどうすればいいの？というと、チームのおすすめはこんな感じ。 - 「保証割り当て」と「強制終了の上限」をタスクごとに別々に指定して、ひとつの値に固定しない - そのあいだのマージンを、スコアがノイズの範囲に収まるように調整する。実際 3 倍の上限だと、インフラエラーを約 3 分の 1(5.8 パーセントから 2.1 パーセント)に減らしつつ、スコアの押し上げは小さく保てた - リソース設定を、プロンプト形式やサンプリング温度と同じくらいちゃんと記録する「一級の実験変数」として扱う - ベンチマークを見る側も、設定が書かれていない 3 ポイント未満の差はちょっと疑ってかかる 記事は最後にこう締めくくっているよ。 > A few-point lead might signal a real capability gap—or it might just be a bigger VM. (数ポイントのリードは本物の実力差のサインかもしれないし、ただ VM が大きかっただけかもしれない、という意味だよ) ## まとめ - エージェント型コーディング評価では、インフラ設定を変えるだけで Terminal-Bench 2.0 のスコアが最大 6 パーセントポイント(p 値は 0.01 未満)も動いた - 原因は、リソースの「保証割り当て」と「強制終了の上限」を同じ値にすることで起きる、余裕ゼロの OOM キル - 1 倍から 3 倍の余裕は主にインフラエラーを減らして安定させる効果、3 倍を超える余裕はエージェントを力技で後押しして簡単にする効果と、段階で性質が変わる - SWE-bench でも同じ傾向(5 倍で ＋1.54 ポイント)が確認され、リソース配分は無視できない - 対策は、リソース設定を一級の実験変数として明示・記録すること ベンチマークのスコアを比べて一喜一憂するエンジニアや、自分でモデル評価を回す研究者・開発者にこそ刺さる、測ることの難しさを突きつける一本だよ！