# インフラノイズを消すエージェント評価基盤設計

> Terminal-Bench 2.0の実験ではリソース設定差だけでスコアが最大6ポイント動きました。エージェント評価のインフラノイズを見分け、抑える設計手順を解説します。

- Canonical: https://kuucorp.com/blog/agentic-eval-infrastructure-noise-variance-design/
- Date: 2026-09-04
- Last modified: 2026-09-04
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
社内のagentic codingベンチマークで、モデルを差し替えていないのにスコアが数ポイント揺れた経験はないでしょうか。原因をモデルの非決定性だと決めつけて調査を打ち切ると、実際にはコンテナのリソース設定というインフラ側の要因を見逃していることがあります。Anthropicの実験では、モデル・ハーネス・タスクセットを完全に固定したままリソース配分だけを変えると、スコアが最大6ポイント動くことが確認されています。[エージェントガバナンス](/ai-governance/)の評価レイヤーでは、この「インフラノイズ」を測定対象として切り分ける設計が欠かせません。

## エージェント評価のスコア差はモデル差かインフラ差か

> 同一モデル・同一ハーネスでもリソース配分だけでスコアが変わり、この変動を「インフラノイズ」と呼びます。

Anthropicはagentic codingベンチマークTerminal-Bench 2.0を用い、モデル・評価ハーネス・タスクセットを完全に同一にしたまま、コンテナのリソース配分だけを6段階（強い制限〜無制限）で変える実験を行いました。結果、最もリソースが厳しい設定と最も緩い設定の間でスコアが6ポイント(p<0.01)動きました。これは多くのリーダーボードでモデル間の差として報告される幅と同等かそれ以上です。Anthropicは「文書化・整合の取れたインフラ設定を伴わない3ポイント未満のリーダーボード差は、不確実なものとして扱うべきだ」と述べています。SWE-benchでも同様の実験を行い、RAMを5倍にした条件で1.54ポイントの変動を確認しており、リソース感度の大きさはタスクの重さに依存する構造だと分かります。

## インフラノイズはどこから生まれるか

> コンテナランタイムの保証割当と強制終了しきい値が同一値だと、突発的なメモリ使用増でOOM killが発生します。

インフラノイズの主要因はコンテナのリソース強制（resource enforcement）の設計です。コンテナランタイムは「保証割当（guaranteed allocation）」と「強制終了しきい値（hard kill threshold）」という2つのパラメータを持ちますが、この2つを同一値に固定すると、一時的なメモリスパイクを吸収する余地がなくなり、本来失敗すべきでないタスクが不可解なOOM(Out of Memory)終了で失敗します。実測では、リソースを厳格に制限した設定でインフラ起因のエラー率が5.8%に達した一方、無制限設定では0.5%まで低下しました。API呼び出しのレイテンシ変動、クラスタの健全性、ハードウェア仕様、同時実行数、egress帯域といった要因も同様にノイズ源になり得ます。

## リソース配分の余白はどこまで確保すべきか

> per-taskのリソース仕様に対しヘッドルームを約3倍確保すると、インフラエラー率が5.8%から2.1%まで下がります。

Anthropicの実験では、タスクごとのリソース仕様に対して強制終了しきい値を約3倍まで引き上げると、インフラ起因のエラー率が5.8%から2.1%に下がり、スコア自体は統計的なノイズの範囲内（p=0.40）で安定しました。3倍を超えてさらに余白を広げても、成功率の伸び（約4ポイント改善)がインフラエラーの減少ペースを上回るようになるため、際限なく緩めればよいわけではありません。単一の固定値ではなく、タスクごとに「保証割当（フロア）」と「強制終了しきい値（シーリング）」を分けて設定し、突発的なメモリスパイクを吸収できる余地を持たせることが、ノイズを抑える設計の起点になります。

## インフラノイズを継続的に抑える運用設計とは

> リソース設定を実験変数として文書化し、複数日にまたがる複数回実行で時間依存ノイズを平均化します。

継続運用では3点が有効です。第一に、リソース配分をプロンプト形式やサンプリング温度と同様に「実験変数の一つ」として明文化し、evalの実行条件と一緒に記録すること。第二に、評価を異なる時間帯・日にまたがって複数回実行し、API側のトラフィック変動や一時的なクラスタ負荷を平均化すること。第三に、[エージェント評価のCI/CDパイプライン](/blog/agent-evaluation-cicd-pipeline-automation/)にリソース仕様の変更履歴を組み込み、モデル更新とインフラ設定変更を同時に行わないこと。これにより「スコアが下がったのはモデルの退行か、直前のインフラ変更か」を切り分けやすくなります。なお、[エージェント評価の非決定性・再現性設計](/blog/agent-eval-flaky-nondeterminism-reproducibility-design/)で扱う温度やツール選択の揺らぎはモデル側の変動要因であり、インフラノイズとは発生源が異なります。両者を混同せず別々に監視することが、[マルチエージェントシステムの評価設計](/blog/multi-agent-system-evaluation-design/)のようなスケールの大きい評価基盤ほど重要になります。エンタープライズ規模の評価基盤構築は、Kuuの[RDE](https://kuucorp.com/services/rde/)で伴走しています。

## 参考

- Anthropic「Quantifying infrastructure noise in agentic coding evals」 https://www.anthropic.com/engineering/infrastructure-noise
- Anthropic「Demystifying evals for AI agents」 https://anthropic.com/engineering/demystifying-evals-for-ai-agents

## まとめ

エージェント評価のスコア差は、モデルの実力差だけでなく、コンテナのリソース配分に起因するインフラノイズでも生まれます。

1. リソース配分だけでスコアが最大6ポイント動くことを前提に、3ポイント未満の差は設定を揃えない限り不確実だと扱う
2. 「保証割当」と「強制終了しきい値」を分け、per-taskの仕様に対して約3倍のヘッドルームを確保する
3. リソース設定を実験変数として文書化し、複数日にまたがる複数回実行で時間依存ノイズを平均化する
4. モデル側の非決定性（温度・ツール選択の揺らぎ)とインフラノイズを別々に監視し、CI/CDでモデル更新とインフラ変更を同時に行わない

評価基盤の設計・運用を本番規模で構築したい場合は、Kuuの[RDE](https://kuucorp.com/services/rde/)にご相談ください。