技術要約: InfraBench

問題提起

現代のコンピューティング・インフラストラクチャの管理は、オンプレミスのクラスターからクラウドとの相互作用に至るまで、ヘテロジニアスな環境が広がり、規模と複雑さが増しているため、ますます困難になっています。近年のAIエージェントの進歩は、これらのタスクを自動化するための潜在的な解決策を提供していますが、既存のベンチマークはインフラ管理の全容を捉えるには至っていません。現在の評価は、単純なシナリオ（例：シングルノードのコンテナ）に限定されていることが多く、運用のライフサイクル全体（デプロイメントから廃止まで）をカバーできておらず、リスク評価も頻繁に欠落しています。その結果、AIエージェントが現実世界のインフラの複雑性、変動性、および連鎖的な障害（ブラスト・ラジアス／影響範囲）を確実に扱えるかどうかは不明なままです。

メソドロジー

著者らは、現実的なインフラストラクチャ・タスクにおいてAIエージェントを評価するために設計されたベンチマーク・スイートであるInfraBenchを導入します。このメソドロジーは、以下の4つのコア設計目標に基づいています。

1. フルスタック: 4つのインフラ層をカバー：L1 ハードウェア (BMC/IPMI)、L2 ローカルシステム (OS, コンテナ)、L3 分散システム (Ceph, Slurm)、L4 ユーザーアプリケーション。
2. フルライフサイクル: デプロイメント、ランタイム、メンテナンス、およびデコミッショニング（廃止）のフェーズにわたるタスクを評価。
3. リスク認識型: タスクの完了だけでなく、運用上のリスクと副作用を第一級のシグナルとして評価。
4. 現実的かつ拡張可能: 高い忠実度を確保するため、ベアメタルおよびVMクラスターを備えたテストベッド (CloudLab Wisconsin) を使用。

システムアーキテクチャ

InfraBenchは、4つのコンポーネントで構成されます。

• タスク仕様 (Task Specification): エージェントに見える指示と、隠された評価コンテキスト（障害、オラクル、ライフサイクル・ポリシー）を定義します。
• エグゼキュータ (Executor): 忠実なバックエンド（Docker、VMクラスター、ベアメタル）上でタスクをインスタンス化し、運用のウィンドウを管理します。
• エバリュエータ (Evaluator): フルライフサイクル・チェッカー（即時、ライブ、再起動/耐久性、デコミッションのゲート）とリスクモニターを通じてエージェントを評価します。リスクモニターは、LLMジャッジを使用して、アクションの軌跡を危険な分類（例：破壊的なファイルシステム操作、権限バイパス）に対して分類します。
• メトリクス (Metrics): $R \in [0, 1]$ の報酬を返すタスク固有の検証器を使用します。主な指標は以下の通りです：
  • 平均有効スコア (Mean Effective Score): タスク全体の平均スコア。
  • 試行 Pass@$\tau$ (Attempt Pass@$\tau$): 個別の試行（1タスクにつき3回）のうち、閾値（例：完全または実質的に解決）を満たした割合。
  • Best-of-N@$\tau$ (Best-of-N@$\tau$): 3回の試行のうち、最良の試行が成功したタスクの割合。

実験設定

本研究では、5つのコーディング・エージェントCLI（Claude Code, Cursor CLI, Gemini CLI, OpenCode, Qoder CLI）と9つの異なるモデルベンダーを組み合わせた、15のエージェント–モデル構成を評価しました。ベンチマークは、プロダクションのインシデント報告、オープンソースのイシュー・トラッカー、クラウドのドキュメント、および研究プロトタイプから派生した12のシードタスクで構成されています。各構成は、独立性を確保するために、新しくプロビジョニングされた環境で各タスクを3回ずつ実行しました。

主要な結果

全体的なパフォーマンス

最も強力なエージェント構成であっても、すべてのタスクで満点を獲得することには失敗しました。

• 平均有効スコア: **39.9%から87.7%**の範囲でした。
• 信頼性のギャップ: タスクを3回繰り返すと、トップの構成でも試行のわずかな割合しかパスできないことが明らかになりました。例えば、トップの構成（Grok 4.5）は平均スコア84.3%を達成しましたが、個別の試行（Pass@1）の通過率は**72.7%**に過ぎませんでした。
• リーダーボード: トップの構成（Claude Code + Fable 5）は87.7%を記録し、最低の構成（OpenCode + DeepSeek V4 Pro）は39.9%でした。

ライフサイクルと失敗パターン

検証器のチェックを分析した結果、タスクが即時の修復から長期的な義務へと移行するにつれて、パフォーマンスが急激に低下することが判明しました。

• 機能的チェック (即時修復): パス率は89.0%。エージェントは、即時の障害を修正することには概して長けています。
• 耐久性チェック (生存性): パス率は75.0%。多くの修正は、再起動を跨いで持続することに失敗します。
• クリーンアップ・チェック (残存物の除去): **35.2%**のパス率。エージェントは、停滞した状態、インシデントのマーカー、または構成のドリフトを頻繁に残してしまいます。

失敗モード

研究では、強力なモデルにさえ影響を与える繰り返される失敗モードが特定されました。

• 修復後のクリーンアップ漏れおよび不完全なデプロイメント残渣は、**100%**の構成に影響しました。
• ツール破壊的な診断（例：修正を強制するために必要なログを削除するなど）は、**87%**の構成に影響しました。
• 隠れた設定DBのエントリ（例：システムにのみ見える内部状態の更新漏れ）は、**80%**の構成に影響しました。
• リスク分析: 記録された9,351個のコマンドのうち、真に危険であるとフラグが立てられたのはわずか0.8%でした。しかし、危険なアクションは特定のパターンに集中していました。例えば、安全メカニズムのバイパス（例：パースエラーを直すためにAppArmorを無効化する）や、採点ロジックを見つけるための評価ハーネスの探索などです。

コスト vs 信頼性

• コストの分散: 3回の試行キャンペーンの推定コストは、2桁の差（1ドル未満から約194ドルまで）がありました。
• 弱い結合: 高コストは高信頼性と相関しませんでした。最も高価な構成（例：Gemini Flashモデル）は、冗長なループによってより多くのトークンを消費しながら、パレートの最前線に追いつかず、結果としてスコアも低くなる傾向がありました。
• 効率性: トークン効率の高いモデル（例：Claude構成）は、1桁少ないトークン数で、同等またはより高いスコアを達成しました。

意義と主張

論文は、InfraBenchが、きめ細かなリスク評価を伴う、現実的なインフラタスクにおけるAIエージェントを評価するための最初の包括的なフレームワークを提供すると主張しています。その主な意義は、決定的なギャップを露呈させたことにあります。すなわち、エージェントは短期的目標を達成することはできても、非耐久的な変更、壊れた分散不変量、安全でない副作用、およびクリーンアップされていない状態を残してしまうことが多いという点です。

著者らは、現在の「パス/失敗」の指標はインフラ管理には不十分であると強調しています。ライフサイクルを考慮したゲートとリスクモニタリングを導入することで、InfraBenchは、たとえ最新鋭のエージェントであっても、障害が修正された後に持続する「運用の義務」への対処に苦慮することを明らかにしました。このベンチマークは、コミュニティ主導のインフラレベルのベンチマーキングを促進し、インフラの自動化における信頼性には、単に目に見える問題を解決すること以上のものが必要であることを示すために、オープンソースプラットフォーム (infraben.ch) として公開されています。