この記事は、SWE-Bench や Terminal-Bench のようなエージェント型コーディングのベンチマークが、モデルの能力だけを測っているわけではないと論じている。モデルの出力を直接採点する静的なベンチマークと異なり、エージェント型の評価はモデルに完全な環境を与え、モデルはその中でプログラムを書き、テストを実行し、依存関係をインストールし、反復する。そのため実行環境が問題解決プロセスの一部になる——「リソース予算と制限時間が異なる 2 つのエージェントは、同じテストを受けているわけではない」。Anthropic の報告によれば、社内実験では Terminal-Bench 2.0 において最もリソースの多い構成と最も少ない構成の差は 6 パーセントポイント（p < 0.01）であり、これはリーダーボード上でトップモデル同士を隔てる差を上回りうると記事は指摘している。
この発見は、Google Kubernetes Engine クラスタ上で Anthropic 自身の Terminal-Bench 2.0 環境を調整する過程で得られた。そこではスコアが公式リーダーボードと一致せず、最大 6% ものタスクが Pod のエラーで失敗していた。記事はその結果生じる交絡要因——このウィキで インフラストラクチャノイズ と呼ぶもの——に名前を与え、「数ポイントのリードは本当の能力差を示しているのかもしれないし、単に VM が大きいだけなのかもしれない」という一文で締めくくっている。
要点
- コンテナランタイムは、2 つの別々のパラメータでリソースを強制する。事前に確保される保証割り当てと、それを超えるとコンテナが強制終了されるハードリミットである。Anthropic の Kubernetes 環境では両方をタスクごとの仕様値に設定していたため、一時的なスパイクに対する余裕がなかった。一方、Terminal-Bench のリーダーボードでは、一時的な過剰割り当てを許容する、より寛容な別のサンドボックス提供元が使われていた。
- Anthropic は、Claude モデル、ハーネス、タスクセットを固定したまま、タスクごとの仕様を厳密に強制する設定（1x）から完全に上限なしまで、6 つのリソース構成で Terminal-Bench 2.0 を実行した。
- インフラエラー率は余裕が増すにつれて単調に低下し、厳密な強制時の 5.8% から上限なしでの 0.5% まで下がった。1x から 3x への低下（5.8% から 2.1%）は p < 0.001 で有意だった。
- 1x から 3x までは、成功スコアはノイズの範囲内で推移した（p = 0.40）。1x でクラッシュしたタスクの大半は、いずれにせよ失敗していたはずのものだった。
- およそ 3x を超えると、成功率はインフラエラーの減少よりも速く上昇した——3x から上限なしの間で、インフラエラーの 1.6 ポイント減に対して成功率は約 4 ポイント上昇——。これは、追加のリソースによって、大きな依存関係を取り込んだりメモリ集約的なテストスイートを実行したりといった、潤沢な割り当てがあって初めて機能するアプローチをエージェントが試せるようになるためである。1x から上限なしまでの上昇幅は合計 6 パーセントポイント（p < 0.01）だった。
- 記事の解釈では、約 3x までは追加リソースは信頼性の問題を解消するが、それを超えると評価が測るもの自体を変えてしまう。厳しい制限は無駄のない効率的な戦略を有利にし、緩い制限は利用可能なリソースをすべて使い切るエージェントを有利にする。その例が
bn-fit-modifyタスクで、標準的な Python データサイエンススタックのインストールは緩い制限下では成功するが、厳しい制限下ではメモリ不足に陥る。 - この効果は Anthropic の複数のモデルで再現され、方向は一貫していたが大きさは異なっていた。記事は、他社のモデルでも同じ傾向が当てはまるようだが、厳密には検証していないと述べている。
- SWE-bench でのクロスオーバー実験では、227 問それぞれについて 10 サンプルずつ、利用可能な RAM を最大 5x まで変化させたところ、同じ単調な効果がより小さな規模で見られた。5x では 1x より 1.54 パーセントポイント高かった。
- 隠れた変数はリソースだけではない。制限時間も影響しうるし、Anthropic は、正式に定量化はしていないものの、おそらく API のレイテンシが変動するために、時間帯によって合格率が変動することを経験的に観察したと報告している。
- 記事は、評価ではタスクごとに単一の固定値ではなく、保証割り当てとハードな強制終了しきい値の両方を指定し、下限と上限でのスコアが互いにノイズの範囲内に収まるようにその幅を調整することを推奨している。Terminal-Bench 2.0 では、3x の上限によってスコアの上昇をノイズの範囲内に保ちつつ、インフラエラーをおよそ 3 分の 2 削減できた。
- 結論として、リソースに関する方法論が標準化されるまでは、リーダーボード上の 3 パーセントポイント未満の差は、評価設定が文書化され揃えられるまで懐疑的に扱うべきだとしている。
背景
この記事は、自社のモデルが比較される対象であるベンチマークについて、モデル開発者が行う評価方法論上の議論である。数値は Anthropic が自社インフラ上で行った社内実験によるものであり、記事は自らの証拠の限界を明示している。時間帯の影響は経験的な観察にとどまり、Claude 以外のモデルでの結果は厳密には検証されていないと説明されている。記事は提言を 3 つの読者層に向けて示している。ラボは、リソース構成を第一級の実験変数として扱うべきだとされる。ベンチマークの管理者にとっては、Terminal-Bench 2.0 が行っているように推奨リソース仕様を公開することが大きな前進であり、強制の方法論まで指定すればギャップは埋まるとされる。そしてベンチマーク結果の利用者にとっては、エージェント型評価における小さなスコア差は、報告されている精度が示唆する以上の不確実性を伴うとされる。