# SRE Benchmark ## 定義 SRE Benchmark は、AI の SRE エージェントが本番相当の障害を診断・緩和できるかを測る評価基盤。静的な Q&A や異常検知/RCA 用の静的データセットと異なり、稼働中(live)のシステム環境を公開し、エージェントが反復的にシステムをプローブ・観測しながら障害を解決する過程を評価する系統が近年の主流である([[AIOpsLab]]・[[ITBench]]・[[SREGym]])。静的データセットは緩和タスクを支えられないため、稼働環境が要件となる。([[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) ## 横断的知見 - **評価の分解とエンドツーエンド**: [[AIOpsLab]] は障害を検知 / 箇所特定 / RCA / 緩和の 4 つの独立した部分問題に分解して個別採点する。[[SREGym]] は同じライフサイクルをエンドツーエンドの単一ループで包括的に評価する。能力の切り分け(AIOpsLab)か現実の障害対応への忠実度(SREGym)かで設計思想が分かれる。(Source: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **診断オラクルの設計**: [[AIOpsLab]] は箇所特定の成功を「障害マイクロサービス名のラベル厳密一致(is_exact_match)」で判定し脆い。[[SREGym]] はこの脆さを避けチェックリストに基づく LLM-as-a-judge(人間と κ=0.90)を採る。オラクルは厳密一致 → トポロジーを考慮した照合([[ITBench]] の NTAM=Normalized Topology-Aware Metric。一次論文で root cause/fault propagation chain をトポロジーで 0–1 採点と確認)→ チェックリストに基づく LLM judge と進化している。(Source: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]], [[@2025__ICML2025__ITBench - Evaluating AI Agents across Diverse Real-World IT Automation Tasks]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **障害の注入機構**: [[AIOpsLab]] は症状を [[ChaosMesh]] で、根本原因を独自の機能障害ライブラリで注入するが、アプリケーション/仮想化層が中心。[[SREGym]] は「症状でなく障害を注入する」を設計原則に掲げ、OS/ハードウェアカーネル・誤操作層まで拡張し環境ノイズ(ambient noise)も加える。カオスエンジニアリングツールの位置づけがベンチマーク間で分かれる。(Source: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **問題の拡張機構**: [[AIOpsLab]] は `LocalizationTask` 等を拡張して問題を追加(エージェント登録 <100 行)。[[SREGym]] は 50 の障害プリミティブ × 139 サービス = 3,623 の実行可能な (fault, target) ペアという組み合わせで問題を量産(キュレーション済みの 90 問は ~2.5%)。両者ともプログラム的な拡張を志向するが、SREGym は組み合わせ爆発を明示的な乗数として設計に取り込む。(Source: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **複数ベンチマーク横断の評価が標準化しつつある**: [[Stratus]] 一次論文は単一ベンチでなく [[AIOpsLab]] と [[ITBench]] の**両方**で緩和成功率を測り、SOTA を各種モデルで少なくとも 1.5 倍上回ると主張する。エージェント論文が複数の SRE ベンチで横断評価する慣行が立ちつつあり、ベンチ間の比較可能性(タスク定義・オラクル・成功判定の差)が次の論点になる。なお [[ITBench]] の主導著者 [[Saurabh Jha]] は Stratus 共著者でもあり、ベンチ作者とエージェント作者が近接している。(Source: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **「緩和だけ」を切り出す専門ベンチの登場**: [[AIOpsLab]]・[[SREGym]] はライフサイクル全体(検知→…→緩和)をカバーするが、[[MicroRemed]] は診断レポートを所与として**緩和段だけ**を「実行可能な Ansible playbook の生成(E2E-MR)」として切り出す。箇所特定/RCA から緩和を切り離すことで緩和能力を純粋に測れる反面、診断誤差の伝播という現実は捨象する(設計の分化は [[障害緩和]] に詳述)。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **カオスエンジニアリングツールの位置づけがさらに分岐**: 「障害の注入機構」の知見に [[MicroRemed]] が第 3 の立場を加える。[[SREGym]] は [[ChaosMesh]] を「症状しか注入しない」と避けるが、MicroRemed は逆にカオス注入([[ChaosMesh]])をリソース/ネットワーク系障害の主たる注入手段として積極採用し、設定系は構成の注入で補う。緩和(回復できたか)を測るなら症状の注入で足りるが、RCA(根本原因を当てたか)を測るなら不十分、という評価対象の違いが立場の差を生む。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **実行ベース / 状態ベースの検証の合流**: [[MicroRemed]] は注入した障害のみを標的に検査して回復を判定し検証精度 100% を主張、[[SREGym]] はアラート抑制でなく状態ベースで緩和成功を判定して報酬ハッキングを防ぐ。緩和の成功判定が「出力のもっともらしさ」から「実環境の状態回復」へ統一されつつある。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **LLM-as-a-Judge が学術・産業の双方で評価機構になった**: [[SREGym]] は診断成功をチェックリストに基づく LLM-as-a-judge(人間と κ=0.90)で判定し厳密一致の脆さを避ける。[[Google]] も本番の自律的なアクションを **LLM-as-a-Judge** で Golden Data(人間応答)と比較し、失敗に対する批評と実装計画を自動生成する。オラクルが厳密一致 → トポロジーを考慮した照合 → LLM-as-a-judge と進化する流れが、研究ベンチだけでなく産業の継続的評価でも同じ機構に収束している。(Source: [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **固定ベンチの一発評価と産業の継続的評価**: 学術ベンチがキュレーション済みの固定問題集([[SREGym]] 90 問・[[AIOpsLab]] 48 問)で一発評価するのに対し、[[Google]] は実インシデントの更新され続けるデータセットに対する **Continuous Nightly Evals** を回し、評価データを Bronze(自動ラベラー)/ Silver(プログラム生成・Gold に較正)/ Gold(人間検証)の品質 3 階層で管理し、True vs Observed Precision で不完全な訓練データを統計的に較正する。評価軸が「固定ベンチでの能力比較」から「本番に追随し続ける継続評価とデータ品質管理」へ広がっている。(Source: [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **カバー範囲の軸の分岐:単一ペルソナ(SRE)の深掘りと IT 運用横断**: [[AIOpsLab]]・[[SREGym]] は SRE(障害の診断・緩和)に特化して障害注入の忠実度や評価粒度を深掘りするのに対し、[[ITBench]] 一次論文は SRE(42)に加え **CISO**(コンプライアンス評価、50)と **FinOps**(コスト管理・異常検知、10)まで計 102 シナリオで IT 運用を横断的にカバーする(水平方向の拡張を設計に内包)。「SRE をどこまで難しくするか」(SREGym/AIOpsLab)と「IT 運用のペルソナをどこまで広げるか」(ITBench)はベンチ設計の直交軸で、後者では SRE が 3 ペルソナの 1 つに相対化される。(Source: [[@2025__ICML2025__ITBench - Evaluating AI Agents across Diverse Real-World IT Automation Tasks]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **報告される「能力の天井」がベンチ間で桁違い**: 同じ SRE 障害解決でも報告値が大きく食い違う。[[AIOpsLab]] は最高 ~59%(検知/箇所特定/RCA/緩和を分解採点)、[[SREGym]] は最高 6 割前後、[[ITBench]] は GPT-4o の SRE 緩和が **11.43%**・難問の緩和は全モデル 0%(エンドツーエンドのインシデント解決)。分解採点とエンドツーエンド、シナリオ難易度、オラクルの厳しさの差が天井を桁単位で動かすため、「○○ベンチで何%」は単独では能力を表さず、ベンチ横断の正規化([[Stratus]] の「少なくとも 1.5 倍」も同じ問題)が前提になる。(Source: [[@2025__ICML2025__ITBench - Evaluating AI Agents across Diverse Real-World IT Automation Tasks]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **観測データの有無が成功率を左右することの定量的な裏付け**: [[ITBench]] 一次論文のアブレーションはトレースデータを外すと GPT-4o の診断 pass@1 が 13.81%→9.52%、緩和が 11.43%→2.86% に急落すると示す。ベンチが「オブザーバビリティの質」を制御変数として操作でき、それが SRE エージェントの性能を直接左右するという、これまで [[agentic SRE]] で定性的に言われてきた「テレメトリの選別が鍵」を、ベンチ側から定量化した例。(Source: [[@2025__ICML2025__ITBench - Evaluating AI Agents across Diverse Real-World IT Automation Tasks]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **産業の評価は「実インシデントの保存済みテレメトリ + LLM judge」に収束**: [[Datadog]] は [[Bits AI SRE]] を **数百件の実本番インシデント**で評価し、対応者がラベル付けした実インシデントの保存済みテレメトリをエージェントに供給して再生し、LLM judge が結論を採点(pass/fail で人間判断と整合)、バージョン横断で改善を追う。これは [[Google]] の更新され続けるデータセットへの継続的評価 + LLM-as-a-Judge と同じ骨格で、産業の 2 例がともに「合成された障害でなく**過去の実インシデントを再生**し、LLM judge で人間整合の pass/fail を出す」評価に収束している。学術ベンチが合成された障害の稼働環境への注入([[SREGym]]・[[AIOpsLab]])で再現性と難易度制御を取るのと対照的に、産業は手元の実インシデント資産を保存済みテレメトリとして再利用する。(Source: [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) - **ブラウザ可視層の追加という第四の証拠軸**: 既存ベンチマーク([[AIOpsLab]]・[[ITBench]]・[[SREGym]]・[[Cloud-OpsBench]]・[[OpenRCA]])はすべてバックエンドテレメトリ（メトリクス・ログ・トレース）のみで評価し、ユーザーが実際に見るブラウザ可視証拠（スクリーンショット・DOM・コンソール・ネットワーク要求）を欠落させていた。[[CUJBench]] はこの空白を埋め、Critical User Journey(CUJ)の障害診断においてブラウザ可視層とバックエンド可観測性のクロスモーダル統合を評価する初のベンチマークを提供する。[[Cloud-OpsBench]] の State Snapshot Paradigm（決定論的スナップショット）と同じ再現性設計を継承しつつ、評価可能な証拠空間をブラウザ層まで拡張した。(Source: [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]) - **ツールアクセス拡大が精度を下げるという反直感的結果**: [[CUJBench]] は 6 モデル × 3 ベースライン評価で、ブラウザ限定エージェント（A@1=28%）がフルツールセットエージェント（A@1=19.9%）を集計で上回ることを示した。証拠アクセスの拡大が改善された統合でなく焦点を絞らない探索を引き起こす。Gemini 3.1 Pro ではブラウザ限定から Full に移行すると SR が 92%→40%・A@1 が 52%→12% に急落。「多くの証拠が使えるほど良い」という直感が崩れ、適切な証拠の絞り込み能力が診断品質を左右することを定量化した。(Source: [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]) - **「証拠発見ではなく統合」がクロスモーダル診断のボトルネック**: [[CUJBench]] の Evidence Recall(ER)と A@1 の解離——Claude Sonnet 4.6 (agent-full) で ER=0.648・A@1=0.440——が示すとおり、エージェントは決定的証拠を検索できているが正しくコンポーネントに属性付けできない。この「統合ボトルネック」は 6 モデル全員で構造的に一致しており、モデルスケールとツール数の増加では解決しない。[[Cloud-OpsBench]] が「結果は当たっても過程は破綻（A@1=0.73 vs ZTDR=0.32）」を示したのと異なり、CUJBench は「証拠は取れても結果は外れる（ER>A@1）」という別の乖離を定量化した。(Source: [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]) - **形式不安定性がモデル能力の上限を決める**: [[CUJBench]] で Llama-4-Scout(35/36 非提出)・Qwen3-VL(37/44 非提出)は有効なツール呼び出し形式を維持できず、分析能力があっても提出できない。プレーンテキストの推論は一貫しており障害は形式遵守のみ。GPT-5.4 のゼロ非提出がこの形式不安定性をモデル固有の制限と確認する。PCW=0.725 という高い部分得点を示しながら A@1 が極めて低いという「能力と提出の解離」を生む。(Source: [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]) - **大規模競技検証がデータセットの信頼性の根拠として機能する**: [[@2026__arXiv__A Multi-Dataset Benchmark for Evaluating LLM Agents in Microservice Failure Diagnosis]]（AIOps2025+RCA100）は AIOps2025 を 2025 CCF AIOps Challenge（561チーム）、RCA100 を Alibaba Tianchi 2025（5,532チーム）の競技データセットとして外部検証することで「ベンチ作者が作って採点する」循環を破る設計を採用した。学術ベンチ（[[SREGym]]・[[AIOpsLab]]・[[ITBench]] など）は競技規模の外部検証を持たず、この大規模競技は RCA データセットの実用性検証として前例がない規模。ただし競技の具体的な精度スコア分布は論文に記載されておらず、達成可能な性能上限は依然不明。(Source: [[@2026__arXiv__A Multi-Dataset Benchmark for Evaluating LLM Agents in Microservice Failure Diagnosis]] §4.5, §5.5) - **評価環境の第三の型(ライブと純静的の中間)**: このページは「静的データセットは緩和を支えられない → 稼働環境が要件」と論じ、ライブ環境([[AIOpsLab]]・[[SREGym]]・[[ITBench]])を主流に据えてきた。[[OpenRCA]](335 障害・68.5GB の保存済みテレメトリに対する QA。クエリは GPT-4 で合成、候補 component/reason を事前提示)と [[Cloud-OpsBench]](メトリクス・ログ・コントロールプレーン設定・データプレーン状態を凍結した決定論的なデジタルツイン + モック接面、State Snapshot Paradigm)は、ライブ環境の非決定性・高コストと純静的データセットの低忠実度の中間に位置する RCA 特化の設計を示す。とくに [[Cloud-OpsBench]] は State Snapshot を「ライブの非決定性 vs 静的人工物」の二分を埋める第三の型と明示する。RCA だけを切り出すなら、再現性のためにライブを捨てる選択肢があることを、2 本が別アプローチ(静的 QA / デジタルツイン)で示している。(Source: [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]], [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - **能力の天井は RCA に限れば桁違いに低い(結果指標と過程指標でも食い違う)**: 既存「能力の天井がベンチ間で桁違い」スレッドに RCA 特化の新データ点を足す。[[OpenRCA]] は最良の Claude 3.5 Sonnet でも RCA-agent 11.34%、Hard(originating component / start time / failure reason の 3 要素)は全モデル 0.00%、Easy→Mid で半減する。[[Cloud-OpsBench]] は結果指標 A@1=0.73 と高いのに、過程指標(IAC=0.40・RAR=0.11・ZTDR=0.32)は低い。緩和込みのライフサイクルベンチ(最高 6 割前後)とは別物の難易度で、RCA を厳密に問うと最高 1 割([[OpenRCA]])、結果は当たっても過程は破綻しうる([[Cloud-OpsBench]])という二様の低さを示す。(Source: [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]], [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - **診断オラクルに「過程」軸が加わる(第四の型)**: 既存「診断オラクルの設計」スレッド(厳密一致 → トポロジーを考慮した照合 [[ITBench]] NTAM → チェックリストに基づく LLM judge [[SREGym]])に、[[Cloud-OpsBench]] の**結果でなく推論過程を採点するホワイトボックス評価**(IAC=Investigation Action Coverage / RAR / ZTDR。論文初の過程評価)を第四の型として接続する。結果が当たっても過程が破綻しうること(A@1=0.73 に対し ZTDR=0.32)を定量化し、A@k 偏重への対抗を示す。オラクルは「最終回答の正否」から「軌跡の整合」へと評価対象を広げつつある。(Source: [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) ## 未解決の問い - 高忠実度の指標とは何か。SREGym はノイズ・低位層の障害・メタステーブル/同時/相関の障害モードを「忠実度」の軸に置くが、忠実度を定量化する合意された尺度はあるか。([[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - 診断オラクル: ラベルの厳密一致(脆い)→ トポロジーを考慮した照合(高コスト)→ チェックリストに基づく LLM-as-a-judge と進化したが、LLM-as-a-judge の安定性・公平性をどこまで担保できるか(SREGym は人間と κ=0.90)。 - 報酬ハッキング対策(障害注入面の隠蔽、アラート抑制でなく状態ベースの緩和判定)はどこまで一般化できるか。既存ベンチの「pod の再起動で 44% 解ける」問題をどう恒久的に塞ぐか。 - カオスエンジニアリングツールは「症状」を注入するため SRE 評価には不適とされる。では「障害(根本原因)」を注入する注入器のカバレッジを実世界の障害分布にどう合わせるか。 - ステップ/予算の設定: [[AIOpsLab]] は環境フィードバックによる自己修復が 5〜20 ステップで頭打ちになると示す(図5)。ベンチマークはステップ上限やトークン予算をどう設定すればエージェントの能力差を公平に測れるか。([[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - 複数ベンチ横断の「少なくとも 1.5 倍」([[Stratus]])のような主張をベンチ間で比較するには、タスク定義・成功オラクル・モデル設定の差をどう正規化すればよいか。ベンチ作者がエージェント作者を兼ねる場合([[Saurabh Jha]])の評価の独立性をどう担保するか。 - 緩和を診断から切り離す([[MicroRemed]] は診断レポートを所与にプレイブック生成を測る)のと、診断→緩和をエンドツーエンドで測るのとでは、どちらが現実の SRE 緩和能力を妥当に評価するか。診断誤差の伝播を含めない評価は緩和を過大評価しないか。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]]) - カオス注入(症状)で足りるか、障害注入(根本原因)が要るかは「何を測るか」に依存する([[MicroRemed]] は緩和にカオス注入を採用、[[SREGym]] は RCA のため避ける)。緩和専門ベンチでカオス注入を使うことの妥当性と限界(症状だけ消して根本原因が残る緩和を成功と誤判定しないか)。 - 学術ベンチのスコア(SREGym/AIOpsLab で最高 6 割前後)と [[Google]] の本番での自律緩和(L2/L3 稼働)の実績は、どうすれば同じ土俵で比較できるか。固定問題集の正答率と、本番の更新され続けるデータセットでの継続的評価(自律度・MTTM 削減)は別の量を測っており、産業の主張を学術ベンチで再現/反証する方法論はあるか。([[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) - 過程中心の評価(IAC/RAR/ZTDR)は結果指標(A@k)とどこまで相関し、どこで乖離するか。過程の正しさを要求する評価は、結果だけを当てるショートカット(A@1=0.73 でも ZTDR=0.32)を排除できるか。([[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - [[OpenRCA]] のように候補(component/reason)を事前提示し GPT-4 合成クエリで問う静的 QA は、ライブ環境ベンチ([[SREGym]]・[[AIOpsLab]])の実難易度をどれだけ忠実に代理できるか。RCA を再現性のためライブから切り離す代償(実ユーザー報告でない・候補提示で実難易度を過小評価しうる)は何か。([[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]]) - [[CUJBench]] でブラウザ限定エージェントがフルツールセットエージェントを上回る原因は「情報の過多による焦点の拡散」とされるが、これは選択的証拠アクセスをエージェントに促す設計（例: 関連性スコアでツールをフィルタ）で改善できるか。ツールの「ノイズ対信号比」をどうベンチマーク設計に織り込むか。([[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]) - クロスモーダル統合（ブラウザ証拠をバックエンドコンポーネントに属性付けする）はモデルスケールとツール数の増加では改善しない([[CUJBench]])。どのような学習・推論設計（クロスモーダル事前学習・ツール使用制限・Chain-of-Thought 強化）が有効か。([[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]) ## 関連 - ソース: [[@2026__arXiv__A Multi-Dataset Benchmark for Evaluating LLM Agents in Microservice Failure Diagnosis]] / [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]] / [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] / [[@2025__ICML2025__ITBench - Evaluating AI Agents across Diverse Real-World IT Automation Tasks]] / [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]] / [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] / [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]] / [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]] / [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]] / [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]] - 概念: [[agentic SRE]] / [[AIOps]] / [[根本原因分析]] / [[障害緩和]] / [[SRE AI Autonomy Levels]] - エンティティ: [[SREGym]] / [[AIOpsLab]] / [[ITBench]] / [[Stratus]] / [[MicroRemed]] / [[Google]] / [[Bits AI SRE]] / [[DeathStarBench]] / [[ChaosMesh]] / [[Train-Ticket]] / [[Online-Boutique]] / [[CUJBench]] / [[OpenTelemetry Demo]] / [[Tractor Store]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] / [[LLM4SRE - MOC]] / [[SRE論文紹介リスト]] ## 出典 - [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]](§1, §2, §4 Related Work, Appendix B) - [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]](§2 Design, §3 Evaluation, Table 1–4) - [[@2025__ICML2025__ITBench - Evaluating AI Agents across Diverse Real-World IT Automation Tasks]](§2 Related Work Table 1, §3 framework, §4 Results Table 4–6, §4.2 trace ablation) - [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]](Abstract) - [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]](§3.1–3.3, §5, Table 1) - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]](Evaluation Data and Memory) - [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]](Evaluation & Benchmarking) - [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]](§タスク定義 7 goal/3 要素・難易度勾配、能力天井 Claude 3.5 Sonnet 11.34%・Hard 0.00%) - [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]](§3.2 State Snapshot Paradigm、表2 障害 40 種・7 カテゴリ、表4 IAC/RAR/ZTDR・A@1=0.73、表5 ICL>RAG/CoT) - [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]](§I Gap 1-3、§II-B 設計決定、§III-D 全体パフォーマンス、§III-E 行動分析、§III-F 障害モード 3 つ) - [[@2026__arXiv__A Multi-Dataset Benchmark for Evaluating LLM Agents in Microservice Failure Diagnosis]](§4.5 AIOps2025 大規模検証 561チーム、§5.5 RCA100 大規模検証 5,532チーム、§6 限界)