Anthropicが示したコーディング評価の落とし穴 — リソース設定が6ポイントのスコア差を生む

エージェント型コーディング評価のリーダーボード差が、モデルの実力ではなく実行環境のリソース設定によって生まれている可能性を、Anthropicが定量化しました。Terminal-Bench 2.0とSWE-bench Verifiedを題材に、コンテナのメモリ上限の置き方を変えるだけで成功率が最大6ポイント動く現象を確認しています。

背景 — リーダーボードの「実力差」を疑う動機

Anthropicは社内の評価基盤として、Google Kubernetes Engine(GKE)上にTerminal-Bench 2.0を載せ替える作業を進めていました。校正中、公式リーダーボードと自社実装のスコアが噛み合わず、調べるとタスクの最大6% がpodエラーで落ちていることが判明します。モデルが解こうとして解けなかったのではなく、コンテナ自体が殺されていたという話です。

問題の所在はKubernetesのリソース仕様の解釈にありました。タスクごとに指定したメモリ量が、保証割り当て(下限)と強制終了の閾値(上限)の両方を兼ねる設定になっており、瞬間的なメモリスパイクでOOM-Kill(Out-Of-Memoryによる強制終了)が走っていたのです。

Two agents with different resource budgets and time limits aren't taking the same test.

この一言が論文の出発点で、同じモデル・同じハーネス・同じタスクであっても、走っているVMの余裕度が違えば「別の試験を受けている」ことになる、という認識です。

コンテナランタイムの「2つのパラメータ」を分離する

Anthropicが指摘しているのは、コンテナランタイム(Docker / containerd / Kubernetesなど)が、リソースを2つの独立したパラメータで実装している事実です。

Terminal-Bench 2.0の元の設定は、この2値を同じ値(requests = limits)にしていました。これは「タスクが想定どおり動く分だけ確保し、それ以上は使わせない」という直感的に正しそうな設定です。しかし requests = limits だと、瞬間的なヘッドルームがゼロになります。Pythonのデータサイエンス系パッケージをインストールするタスク(例: bn-fit-modify)では、ピーク時に通常使用量の数倍のメモリを要求することがあり、ここでkillされます。

エージェントが諦めたのではなく、エージェントが動いていたpodごと消えた、という挙動です。リーダーボードでは「失敗」として記録されますが、これはモデルの能力ではなくインフラ設定が原因の失敗です。

6つのリソース構成を比較した実験 — 1x / 3x / 無制限の差

Anthropicは同じClaudeモデル、同じハーネス、同じタスクセットで、リソース上限を段階的に変えた6構成を比較しました。代表的な3段階の結果は以下です。

注目したいのは1x → 3xと、3x → 無制限で意味合いが違う点です。1x → 3xではインフラ失敗率は劇的に下がる(5.8% → 2.1%)一方で、解けたタスクの成功スコアそのものはp = 0.40のノイズ範囲にとどまります。つまり「失敗の実体は単なるpodエラー」だったとわかる帯域です。

3x → 無制限では、インフラ失敗率の追加低下は1.6ポイントに対し、成功スコアが約4ポイント跳ねます。ここではメモリ余裕がモデルの問題解決そのものを助けている、と読めます。bn-fit-modify のような環境構築系タスクで、依存パッケージのインストールがピークメモリを必要とし、無制限構成だと完走できる、という具体例が挙げられています。

SWE-bench Verifiedでも同じ手順で検証されています。227問 × 10サンプルでRAMをベースラインの最大5倍まで振り、結果は1x → 5xで1.54ポイントの上昇。Terminal-Benchより幅は小さいものの、同じ向きのバイアスが確認されました。

ノイズ源はメモリだけではない — 時間帯・並行度・帯域

論文後半では、メモリ以外にも評価結果を動かしうるノイズ源が列挙されています。

• タイムリミット: 制限時間を伸ばすと回復するタスクがあり、構成によって寄与度が変わる
• APIレイテンシ: トラフィックの時間帯依存で「pass rates fluctuate with time of day」(時間帯によって合格率がぶれる)
• クラスタの健全性: ノード障害やネットワーク瞬断
• ハードウェア仕様: VMのCPU世代・メモリ帯域幅
• 並行度: 同時実行数が多いと隣接タスクのリソース競合が起きる
• 送信帯域(egress): パッケージダウンロードやリポジトリクローンの速度

つまり評価スコアの観測値には、モデル能力に加えて少なくとも6種類の非モデル変数が混入しています。「モデル能力」と「インフラ挙動」の境界は思っているより曖昧、というのがAnthropicの認識です。

Anthropicが提示する3つの設定指針

評価をより再現可能にするために、論文では3点の指針が示されています。命令調ではなく、ベンチマーク運用の標準を上げるための提案として読むのが良さそうです。

1. リソースは requests と limits を分けて宣言する

タスクごとに「保証割り当て」と「強制終了の閾値」を別の値で書く。requests = limits は最もシンプルですが、瞬間スパイクを許容しないため、評価対象がモデルではなくランタイムになります。

2. 床と天井の幅を経験的にキャリブレーションする

天井を高くしすぎると、リソース潤沢が能力を底上げしてしまう(3x → 無制限で起きた現象)。逆に低すぎるとpod killが混入する。AnthropicのTerminal-Bench 2.0では、3倍ヘッドルームがインフラエラー率を1/3に削減しつつ、能力スコアはp = 0.40のノイズ内、というバランス点でした。最適倍率はベンチマークとタスク分布で変わるため、各評価ごとに測ることが想定されています。

3. 採用した倍率や設定を公開する

Anthropicは「the exact multiplier will vary by benchmark and task distribution, and should thus be reported」と述べています。リーダーボードの再現性を担保するには、リソース倍率・並行度・タイムリミットといった構成値を成果物として開示する流れが必要、という提案です。

このベンチマーク差は実務にどう跳ねるか — 編集視点

ここまでがAnthropicの主張です。実務に翻訳すると、以下のような示唆が読み取れます。

評価結果を読むときの目線が変わる: 公開ベンチマークで2ポイント程度の差は、設定が一致しないかぎり「実力差」と読みづらい。Anthropic自身が「leaderboard differences below 3 percentage points deserve skepticism until the eval configuration is documented and matched」(評価設定が文書化・一致しない限り、3ポイント未満の差は懐疑的に扱う価値がある)と踏み込んだ表現を使っています。モデル選定の意思決定で「SWE-benchで2ポイント上だから採用」のような短絡は、根拠が薄いということです。

自社評価を組むときの優先順位: 自社プロジェクトの中でClaude / 他モデルを比較するために評価環境を組むなら、リソース上限・並行度・実行時間帯を固定して両者を同条件で走らせることの重要度が、論文の数値で裏付けられます。これはエージェント向けツール設計の原則で強調されている「評価駆動でツール設計を進める」流れとも整合します。評価の再現性が担保されないと、ツール改善の効果測定自体がノイズに埋もれます。

Claude Codeを含むエージェント開発との接続: Claude Codeのような自律エージェントを社内で使う際、CI上でエージェントを走らせる場合のコンテナリソース設定にも同じ罠があります。Kubernetes / Docker上でエージェントを動かしているチームは、requests = limits 構成がpod killを介して「エージェントが解けなかった」ように見える失敗を生んでいないか、確認する材料になります。これはClaude Codeのサンドボックス設計で議論されているサンドボックス境界の話とは別軸の、リソース境界の議論です。

Context Engineeringとの位置付け: モデル能力の引き出し方は、プロンプトやツールの設計だけで決まるのではなく、実行環境の設定にも依存することが定量化されました。AnthropicのContext Engineering論で示された「動くコンテキストを作る」議論は、コンテナの外側のリソース帯域までスコープを広げて捉える視点と接続できます。

まとめ

• AnthropicはTerminal-Bench 2.0とSWE-bench Verifiedで、リソース上限の置き方が成功率を最大6ポイント動かすことを示した
• 原因はコンテナランタイムの requests と limits を同値にすることで生じるpod kill。インフラ失敗が「モデルの失敗」として記録されていた
• 1x → 3xの帯域はインフラエラーの除去、3x → 無制限の帯域は能力の底上げ、と性質が違う
• メモリ以外にも、時間帯・並行度・egress帯域など複数のノイズ源が評価結果に混入する
• 3ポイント未満のリーダーボード差を実力差と読むには、評価設定の一致確認が前提になる、という提案

社内で評価基盤を構築している、あるいは公開ベンチマークの数値を意思決定に使っているチームには、設定値の可視化を促す実務的な論文と言えます。具体的な実装値(タスク別の推奨倍率など)は今後のベンチマーク側の標準化に委ねられている段階で、Anthropic自身は「報告と標準化」を呼びかける立場にとどめています。