技術的概要：SREGym – AI SRE エージェントのためのライブベンチマーク

1. 問題定義

本論文は、**サイト信頼性エンジニアリング（SRE）**における AI エージェントの評価に存在する重大なギャップに取り組む。AI エージェントが生産環境の障害の診断と軽減のためにますます展開される一方で、既存のベンチマークは以下の 3 つの主要な理由により不十分である。

• 過度の単純化: 現在のベンチマーク（例：静的な Q&A データセット、異常検知タスク）は、現実世界のインシデント対応の動的かつ多段階的な性質を捉えきれていない。これらは、エンドツーエンドの解決ではなく、静的なデータや孤立した症状に基づいてエージェントを評価することが多い。
• 忠実度の欠如: 既存のライブベンチマーク（例：AIOpsLab、ITBench）は障害をシミュレートするが、生産環境の複雑さを欠いている。これらは通常、アプリケーション層の問題に焦点を当て、「環境ノイズ」（無関係な一時的な事象）を無視し、メタステーブルな状態や相関する障害のような複雑な障害モードをモデル化できていない。
• 拡張性の問題: 多くのベンチマークは、新しいシナリオの構成、分散イベントの調整、または問題空間のスケーリングを困難にする、専用でハードコードされたスクリプト（例：Ansible）に依存している。

さらに、AI 生成コードの台頭は新たな信頼性の課題をもたらしており、AI コードは人間が書いたコードに比べてはるかに多くの欠陥を導入し、テストをより頻繁に回避しているという報告がある。これにより、コーディングを超えてリアルタイムの軽減を含む堅牢なエージェント型 SRE 能力が必要とされる。

2. 手法：SREGym フレームワーク

著者は、実世界のクラウドネイティブシステムスタック（Kubernetes）の上に構築された高忠実度のライブベンチマークであるSREGymを提示する。静的なデータセットとは異なり、SREGym はエージェントが標準化されたインターフェースを介して稼働中のシステムと対話できるライブ環境を提供する。

コアアーキテクチャ

• システム環境: SREGym は、Kubernetes オペレーターによって管理されるクラウドネイティブアプリケーション（例：DeathStarBench、TrainTicket、Astronomy Shop）とバックエンドシステム（MongoDB、TiDB、Kafka）のカタログを展開する。
• エージェントインターフェース: エージェントは**モデルコンテキストプロトコル（MCP）**を介して対話し、メトリクス（Prometheus）、ログ（Loki）、トレース（Jaeger）、およびクラスター制御（kubectl）のためのツールにアクセスする。
• 障害とノイズの注入: フレームワークは、以下のシミュレーションを行うモジュール式の注入器セットを使用する。
  • 障害: eBPF によるハードウェア障害、OS カーネル障害、設定ミス、コードのバグ、オペレーターエラーなど、スタック全体にわたる根本原因。
  • ノイズ: 対象の障害とは無関係な、自己回復する一時的な擾乱（例：ポッドのクラッシュ、パケットの損失）。これは、エージェントが信号とノイズを区別する能力をテストするように設計されている。
• 問題定義: 問題は、環境、エージェントインターフェース、障害/ノイズ、オラクルからなるタプル $P = (E, I, F, O)$ として定義される。
• 評価オラクル:
  • 診断オラクル: 自然言語による診断を評価するために、構造化されたチェックリスト（故障局所化、故障特性、失敗範囲の 3 つの次元にわたる 9 つの Yes/No 質問）を用いたLLM-as-a-Judgeアプローチを採用する。これにより、壊れやすい文字列マッチングを回避し、ニュアンスのある評価を可能にする。
  • 軽減オラクル: 対象の障害が解決され、システムが健全な状態に戻ったかどうかを、クライアント側（リクエスト成功率）とシステム側の観測性の両方を用いてプログラム的に検証する。

主要な設計原則

1. 症状ではなく障害をシミュレートする: システムは、クラッシュしたポッドなどの症状ではなく、欠落した環境変数などの根本原因を注入する。これにより、エージェントは潜在的な欠陥について推論することを要求される。
2. 構成可能性: Python ベースのランタイムが障害とノイズの注入器をオーケストレーションし、メタステーブルな障害（自己維持的な劣化）や同時/相関する障害のような複雑なシナリオを可能にする。
3. 拡張性: フレームワークは問題作成を「プッシュボタン」式にするように設計されており、研究者が既存のシナリオを変更したり、API を介して新しいものを作成したりすることを可能にする。

3. 主要な貢献

• SREGym ベンチマーク: ハードウェア、OS、アプリケーション層にまたがる90 の現実的で困難な SRE 問題を含む、ライブかつオープンソースのベンチマーク。
• 高忠実度な障害モデリング: 以前ベンチマークで扱われていなかった複雑な障害モードの導入。
  • メタステーブルな障害: 一時的な事象に応答して劣化し、特定の介入なしには回復しないシステム。
  • 同時障害: 複数の独立した障害が同時に発生すること。
  • 相関する障害: 共有された根本原因により複数のコンポーネントが故障すること。
• 環境ノイズのシミュレーション: エージェントが関連のないデータをフィルタリングすることを要求する、一時的で低影響な擾乱を注入する能力。
• 堅牢な評価プロトコル: 大規模なデータセットにスケーリングしながら、人間の専門家との高い合意度（$\kappa = 0.90$）を達成する、チェックリストベースの LLM 評価手法。

4. 実験結果

著者は、最先端モデル（Sonnet-4.6、GPT-5.4、Kimi K2.5）を搭載した 3 つのエージェント、Stratus（専門的な SRE エージェント）、Claude Code、およびOpenAI Codexを評価した。

全体的なパフォーマンス

• 成功率: 診断成功率は**38.9% から 72.6%の範囲で、軽減成功率は57.3% から 78.5%**の範囲であった。
• エンドツーエンド（E2E）パフォーマンス: E2E 成功率（正しい診断＋正しい軽減）は大きく変動し、エージェントとモデルのペア間で最大**40%**の差があった。
• ノイズの影響: ノイズの存在は、すべてのエージェントにおいて診断成功率を一貫して低下させた。軽減はより堅牢であったが、依然として影響を受けた。

主要な知見

1. 層固有の弱点: エージェントはアプリケーション層の問題ではよく機能したが、OS やハードウェアなど下位層に根ざした障害や複雑なパターンでは大きく苦労した。例えば、ハードウェア障害シナリオ（ディスクセクタエラー）では、エージェントはハードウェアの根本原因を特定できず、しばしばアプリケーションロジックに誤って帰属させた。
2. メタステーブルな障害への課題: エージェントはアプリケーションレベルのトリガーを特定できたが、メタステーブルな状態を解決するために必要なインフラの制約（例：リソースクォータ）とそれらを結びつけることが頻繁に失敗した。
3. 貪欲な診断: 繰り返し現れる失敗モードは「貪欲なアプローチ」であり、エージェントは最初の妥当な異常（多くの場合ノイズや無関係な問題）に固執し、さらに調査を行わず、誤った根本原因の帰属に至った。
4. トークン効率: 専門的な SRE エージェント（Stratus）は、観測データを前処理することで、コーディングエージェント（Claude Code、Codex）に比べて約 3 倍少ないトークンを使用し、E2E 成功率を犠牲にすることなく、はるかにトークン効率が高かった。
5. 診断と軽減の相関: 正しい診断は成功した軽減と強く相関していた（$P(M|D) \approx 0.69\text{--}0.88$）。ただし、エージェントはシステムを反復的に観測して調整することで、誤った診断であっても障害を軽減できる場合があったが、これは効率が低かった。

5. 意義と主張

本論文は、SREGym を生産準備完了型のアージェント型 SREへの基礎的なステップとして位置づける。

• 現実性: 生産環境の「ノイズの多い」かつ「出来事豊富な」性質をシミュレートすることにより、SREGym は静的ベンチマークよりも、エージェントの現実世界への展開準備度をより正確に測定する。
• コミュニティリソース: オープンソースかつ拡張可能なフレームワークとして、多様なエージェントアーキテクチャやモデルを評価するための共通基盤を提供し、研究を加速することを目指している。
• 限界: 著者は、超大規模生産システムと比較した展開アプリケーションの規模の小ささ、単純化されたノイズモデル、および現時点ではわずか数組のエージェントとモデルのペアのみが評価されていることなど、限界を謙虚に認めている。彼らは、SREGym での高得点は生産安全性にとって必要だが十分条件ではないことを強調している。

結論として、SREGym は、最先端の AI エージェントが SRE タスクにおいて有望な成果を示している一方で、高忠実度、多層化、ノイズの多い障害シナリオの処理において依然として大きなギャップが残っていることを示しており、アージェント型信頼性エンジニアリングの継続的な開発の必要性を浮き彫りにしている。