AI SRE Agent 評価ベンチマークを読んでみた

こんにちは。ジェダイパンくず☁️ です。

以前 2026年6月現時点において SRE がどう AI に向き合っているか調べてみた や Google が提唱する AI in SRE とは何か で、AI SRE エージェントの動向や Google の評価フレームワークについて書きました。その後 ADK Go 2.0 のグラフワークフローを読んで SRE Agent への応用を考える で、実際にインシデントトリアージのワークフローも書いてみています。

ここまでやってみて、ずっと引っかかっていたのが「で、そのエージェントはどれくらい正しく原因を当てられるの？」という問いです。ベンダーの発表では「MTTR が何割短縮」といった数字がよく出てきますが、その多くは自社インフラ上での自己申告で、横並びで比較できるものではありません。

そこで 2026 年に出た AI SRE エージェント向けの評価ベンチマーク 4 本を読んでみました。

• OpenRCA 2.0
• ORCA-bench
• Cloud-OpsBench
• SREGym

読んでみると、4 本ともアプローチは違うのに、エージェントが間違えるパターンについてはほぼ同じことを言っていて面白かったです。本記事では、各ベンチマークの中身、各論文が挙げる課題と解決策、そして自分で SRE エージェントを作るときに持ち帰れることを整理します。

なお 4 本ともプレプリント (arXiv) で、数値は論文に書かれたものをそのまま引用しています。

4 本の全体像

4 本とも「LLM エージェントは障害の root cause を特定できるか」という同じ問いを扱っていますが、何をエージェントに渡して、何を採点するかが違います。

ざっくり言うと、OpenRCA 2.0 と Cloud-OpsBench は「答えが合っていても根拠が伴っているか」を測る方向、ORCA-bench と SREGym は「現実の障害対応にどこまで近づけるか」を測る方向に振っています。

OpenRCA 2.0: 答えではなく伝播経路を採点する

OpenRCA 2.0 は、ICLR 2025 で発表された OpenRCA の後継です。初代 OpenRCA は銀行・通信・マーケットの 3 システムから集めた 335 件の障害で構成されていて、当時の最高成績は Claude 3.5 + 専用エージェントで 11.34% でした。

既存ベンチマークの課題

OpenRCA 2.0 の問題意識はシンプルで、既存のデータセットは「root cause はどれか」というラベルしか持っておらず、そこから症状に至るまでの伝播経路が評価されていない、というものです。

label only the root cause, not the propagation path connecting it to the observed symptom

これだとエージェントは推論の過程を飛ばして、最終的な答えだけを最適化できてしまいます。また、テレメトリだけからラベルを付けようとすると、似たテレメトリを出す障害が多いため、ラベルを付ける人間もエージェントと同じ「逆推論の難しさ」にぶつかります。

解決策: PAVE

そこで提案されているのが PAVE (Path Annotation via Verified Effects) というラベリング手法です。ポイントは、fault injection で「何を壊したか」が分かっていることを利用して、原因から結果へ順方向に経路を検証することです。エージェントはテレメトリしか見えませんが、PAVE は介入の内容を知っているので、逆推論を順方向の検証に変えられます。

1. Structural Pruning: トポロジと伝播ルールから候補経路を列挙する
2. Causal Verification: 注入前の baseline と比較し、偏差・ルール整合・上流から下流への時刻順の 3 条件をすべて満たす経路だけを残す

障害を注入する先、つまりテスト対象のシステムには、マイクロサービスのデモアプリとしてよく使われる次の 3 つが使われています。「障害事例」は、ベンチマーク 500 件のうち各システムで作られた件数です。

障害は Chaos Mesh で合計 8,137 回注入し、その中から評価に使える 500 件を選んでベンチマークにしています。

結果

frontier モデル 11 種で評価した結果です。

76.0% と 61.5% の差を、論文は “ungrounded diagnosis” (根拠のない診断) と呼んでいます。答えは合っているけど、なぜそうなのかの経路は間違っている、という状態です。Edge F1 が Node F1 より 18.8pt 低いのも、全モデルで共通していたそうです。

エージェントの失敗パターン

論文では失敗パターンを 3 つに分類しています。

• Premature commitment: もっともらしい原因を 1 つ見つけると止まり、同時に起きている別の障害を見落とす
• Presence bias: kill された Pod が span を出さない、といった「沈黙」を正常と読んでしまう
• Salience capture: 一番目立つ信号を追ってしまう。下流で増幅された症状に引っ張られる

特に salience capture は、局所化の不足 (約 24pt) の大半を説明すると推定されています。障害対応をやったことがある人なら「エラーが一番多いサービスが原因とは限らない」というのは身に覚えがあると思いますが、エージェントも同じ罠にはまるようです。

限界

論文自身が挙げている限界も押さえておきます。

• 本番障害ではなく合成データで、service mesh / serverless / event-driven なシステムは対象外
• 監査は 100 件を 2 名で実施 (一致率 94%) で、2 名とも著者
• 伝播ルールの語彙にない障害の仕組みは取りこぼす
• train / test の split が定義されていない

今後の課題としては、信頼性領域での process reward model の学習や、テレメトリが欠損した条件での再評価が挙げられています。

ORCA-bench: on-call の現実に寄せる

ORCA-bench は「on-call の人が実際に置かれる状況」を再現することに振り切ったベンチマークです。

既存ベンチマークの課題

論文は、既存のベンチマークは on-call エンジニアが使う 3 つのもの (テレメトリの UI、実負荷下のテレメトリ、ソースコード) のうち、少なくとも 1 つを必ず欠いていると指摘しています。

strips out at least one of the three artifacts an oncall engineer reaches for

例えば OpenRCA のテレメトリは CSV で渡されるので、本番で Grafana から PromQL を叩くのとはだいぶ違いますし、ソースコードもありません。また、報告の曖昧さや検知までの時間 (TTD) を体系的に変えたベンチマークもありませんでした。

環境

• OpenTelemetry Astronomy Shop に継続的にユーザー負荷をかけ、6 日分 (約 50GB) のメトリクス・ログ・トレースを収集
• エージェントは Grafana 経由で Prometheus / Jaeger / OpenSearch にアクセスでき、ソースコードも読める
• 出発点は「チェックアウトがなんか遅い」程度の曖昧なユーザー報告で、障害発生から数時間後に届く設定もある
• 報告の具体性、TTD、複数障害の同時発生を変えて Easy / Medium / Hard を作る

採点は LLM-as-judge で、人手による採点との一致度は weighted κ = 0.91 です。

結果

• 最高の RCA Accuracy は Medium で 25.3%、Hard で 10.0%。Easy でも最高 58.7%
• もっともらしくない原因を出す hallucination は 7% (DeepSeek-V4-Pro) 〜 40% (GLM-5)
• ソースコードを取り上げると、全モデルで精度が 9〜16pt 下がり、hallucination が増える
• 入力を曖昧にする (Easy → Hard) と精度が 19〜50pt 下がる
• テレメトリへの問い合わせの 26〜40% がエラーか空の結果を返している

個人的に一番面白かったのは、ソースコードが効くのに、エージェントがあまり読んでいないという点です。Claude Opus 4.7 と GLM-5 は、実行したコマンドのうちソースコードを読むものが 16% / 20% しかなく、70% 以上をテレメトリへの問い合わせに使っていました。

また、6 つの障害が同時に起きるシナリオでは、3 つのモデルがそれぞれ「別の 1 つ」だけを見つけて止まっていました。ここも OpenRCA 2.0 の premature commitment と同じ傾向です。

解決策と限界

ORCA-bench は、エージェントの作り方についての具体的な提言はほとんどしていません (読めた範囲では)。解決策はベンチマークの設計そのもので、3 つの情報源を揃えること、報告の曖昧さと TTD を変えること、人手で検証した症状をもとに採点することです。汚染を監視するため 324 タスクは非公開にしています。

harness を Terminus-2 から OpenSRE に変えて比較もしていますが、「どちらにも一貫した優位はない」という結論でした。

限界として、論文は本番環境は “orders of magnitude larger, more dynamic, and more idiosyncratic” だとしています。人手で root cause を検証したのは 40 タスクだけで、問題生成と judge が同じ GPT-5.4 である点も気になるところです。データセットは Harbor Hub で公開されています。

Cloud-OpsBench: 証拠を集めたかを採点する

Cloud-OpsBench は CUHK などのチームによる、Kubernetes 上の RCA に特化したベンチマークです。コードは GitHub で公開されています。

既存ベンチマークの課題

論文は既存ベンチマークのギャップを 3 つ挙げています。

1. 静的なベンチマークは、エージェントが「次に何を調べるか」を選ぶ過程を評価できない
2. Live 環境では同じ障害を注入しても深刻度や影響範囲が毎回変わり、エージェント間の差がエージェントの実力だけを反映しない
3. 結果だけを評価しているので、当てずっぽうの正解と根拠のある正解が同じ点になる

ベンチマークの仕組み: 状態 snapshot と証拠グラフ

上の 3 つのギャップに対する答えが、このベンチマークの仕組みそのものです。

1 と 2 を両立させるために、障害が起きている時点のクラスタの状態を snapshot として保存し、12 種の診断ツール (リソース参照、依存グラフ、ログ、疎通確認、ソースコード取得など) の応答を replay する方式をとっています。エージェントは実環境と同じようにツールを叩いて調査できますが、何度実行しても同じ結果が返ってきます。

3 については、障害ごとに「証拠グラフ」を用意しています。見つけるべき milestone とその順序制約を定めたもので、別の調べ方も許容するので、模範手順と完全一致しなくても減点されません。

テスト対象のシステムは、マイクロサービスのデモアプリである OnlineBoutique (11 サービス) と TrainTicket (41 サービス) の 2 つです。これらに 57 種類の障害を注入して、計 754 件の障害事例を作っています。57 種類の障害は次の 8 カテゴリに分類されています。

結果

ReAct エージェント (最大 20 step) で 10 モデルを評価しています。

答えは 7 割近く当たっていても、根拠を揃えられているのは 2〜4 割です。OpenRCA 2.0 の ungrounded diagnosis と同じことが、別の測り方で出ています。難易度別に見ると、TrainTicket の Hard では JRA が平均 0.08 まで落ちます。

失敗パターン

失敗した軌跡を分析して、4 つのカテゴリに分けています。

• Evidence-grounding: 有用な証拠を取れているのに読み違える。起動イベントに Secret が無いと出ているのに周辺リソースを調べ続ける、空の endpoint を「証拠なし」と扱う、など
• Search-control: 異常な Pod を 1 つ見ただけで結論して、他の説明を検証しない。逆に replicas=0 のような決定的な証拠が出た後も、意味の薄い問い合わせを続ける
• Target-resolution: 証拠は正しいのに、責任を別のコンポーネントに帰属させる。共有 DB のエラーを、それを呼んでいるアプリ側のせいにする、など
• Tool-grounding: 推論から実行に移る境界での誤り。間違ったポートに疎通確認して、その失敗を本番の症状と誤認する

最後の tool-grounding は地味ですが、自分でエージェントを作るときにすぐ効きそうなポイントです。

A syntactically valid but mis-specified query can create misleading evidence

解決策: エージェント設計への示唆と経験の再利用

4 本の中で、エージェント設計について一番具体的に書いているのが Cloud-OpsBench です。

• 調査をいつ止めるかを、不確実性を考慮して決める (uncertainty-aware stopping)
• 次のツールを、確定した事実・残っている対立仮説・期待される情報量で選ぶ
• ツールに渡す対象・スコープ・ポートを実行前に検証する
• step 数の多さを調査の深さと見なさない (Qwen3-8B は平均 16 step 使ったが効率は低かった)

経験の再利用も試しています。過去の調査軌跡を few-shot で与える方法と、手順書 (SOP) を与える方法の 2 つです。

OnlineBoutique では両方とも効きましたが、TrainTicket では効果がまちまちでした。論文の結論は「症状が似ている事例ではなく、障害の仕組みが一致する事例を検索する必要がある」というものです。runbook を RAG で引かせる構成を考えている人には、参考になる結果だと思います。

限界

Kubernetes と 2 つのワークロードに限定されていること、全モデルで同じ ReAct scaffold を使っていること、長期の baseline が必要な障害は対象外であることが挙げられています。今後の課題は、状況に応じた証拠収集、ワークロードをまたいで移転できる診断スキル、同時発生・遅延・矛盾する証拠の下での RCA です。

SREGym: 動いている環境で修復まで評価する

SREGym は UIUC と Toronto 大のチームによる、Live 環境型のベンチマークです。

既存ベンチマークの課題

• 静的なデータセットでは修復を評価できず、エージェントがシステムを探って観察する過程もない
• AIOpsLab や ITBench といった既存の Live ベンチマークは、きれいな環境に単一障害を入れるだけで単純すぎる。既存ベンチマークから移植した問題では、Stratus (Sonnet-4.6) の修復成功率が 83.3% に達していた
• chaos ツールで「障害」ではなく「症状」だけを作っている例がある
• 厳密なラベル一致の採点器は、正しい診断も誤り扱いにしてしまう

解決策: ベンチマークの設計原則

• 症状ではなく障害そのものをシミュレートする (“Simulating faults, not symptoms”)
• 自然回復する低影響のノイズを常に混ぜる (5 分ごとに 2 種類、各 2 分間)
• 障害とノイズを組み合わせて新しいシナリオを作れるようにする
• metastable failure、同時障害、相関障害を含める
• eBPF による syscall 失敗、ディスクのセクタエラーなど OS / ハードウェア層の障害も含める

障害プリミティブは 47 種、対象サービスは 139 個で、組み合わせ前で 3,623 通りの障害とコンポーネントのペアがあります。エージェントには MCP 経由で Prometheus / Loki / Jaeger / kubectl が提供されます。

採点は、診断を 9 問の Yes/No チェックリストで LLM judge が採点し (7/9 以上で合格、人手との一致度 κ = 0.90)、修復はプログラムで判定します。エージェントのアーキテクチャは問わないので、Claude Code や Codex をそのまま評価できるのも特徴です。

結果

• 診断の成功率は 38.1〜72.6%、修復は 40.4〜78.5%。エージェント間で end-to-end の結果に最大 40% の差がある
• SREGym で新たに加えた障害シナリオでは、end-to-end の成功率が大きく落ちる (Stratus 63.7% → 17.9%、Claude Code 60.8% → 28.2%、Codex 57.8% → 15.4%)
• ノイズを入れると、診断は全エージェントで下がる (Claude Code 72.6% → 62.6% など)。修復は比較的頑健
• ディスクのセクタエラーの問題では、disk レベルの診断を提案したエージェントは 1 つもなかった
• metastable 障害で、相互作用する 2 つのコンポーネントを両方特定できたエージェントはいなかった

論文はエージェントの振る舞いを “greedy diagnosis” と表現していて、最初のもっともらしい異常を原因として扱い、それがノイズだったりする、と書いています。根本原因の証拠を見つけているのに、それを捨ててしまった実行もあったそうです。

診断と修復の関係も興味深いです。正しく診断できれば 68〜89% で修復に成功しますが、診断を間違えても 22〜62% は修復に成功しています。よくある対処 (再起動など) をパターンマッチで当てはめて、たまたま直っているケースです。本番でこれをやられると、原因が分からないまま「直った」ことになるので、事後のポストモーテムで困りそうです。

コスト面では、同じモデルでも Claude Code は Stratus の 1.81 倍、Codex は 2.44 倍以上の token を使っていました。汎用のコーディングエージェントは、大量の observability データを扱うようには最適化されていない、というのが論文の見立てです。

エージェントへの示唆と限界

専用の章があるわけではありませんが、結果の考察からは以下のような示唆が読み取れます。

• observability データを前処理してからモデルに渡す
• 最初の異常がノイズでないか確かめてから結論する
• 自己検証で誤った仮説から復帰させる
• control plane・サービス・リクエストの層をまたいで理解させる
• dmesg や SMART のような OS / ハードウェア層の診断手段を持たせる

限界としては、各組み合わせを 3 回ずつしか実行していないこと、診断の judge が単一のモデル系列であることが挙げられます。また、別の論文 (Passing Without Repairing、NeurIPS 2026) が、一部の問題で「何もしないエージェント」が修復成功と判定される採点器の穴を報告しています。修復の自動判定はまだ難しい、ということでしょう。

今後は、ノイズのモデル化の多様化、障害の網羅性向上、そして SREGym を強化学習の訓練場として使うことが挙げられています。

4 本に共通するエージェントの失敗パターン

4 本を並べてみると、言葉は違っても同じ失敗パターンを指していることが分かります。

まとめると、今の LLM エージェントは「目立つ異常を 1 つ見つけたら、根拠を揃えずにそれを原因として結論する」傾向があります。これは経験の浅い on-call エンジニアがやりがちなことそのもので、人間向けのポストモーテムでよく言われる「最初の仮説に固執しない」がエージェントにも必要、ということだと思います。

解決策の方向性

各論文が提示している解決策を、方向ごとに整理するとこうなります。

ベンチマーク側の改善は進んでいますが、エージェント側の「こうすれば良くなる」はまだ示唆レベルで、学習による改善は今後の課題、というのが 2026 年 10 月時点の状況です。

まとめ & 自分の SRE エージェントに持ち帰ること

ADK Go 2.0 の記事 で書いたインシデントトリアージのワークフローに当てはめると、以下は今すぐ取り入れられそうです。ここからは論文の主張ではなく、私の考えです。

1. 結論の前に「証拠チェック」ノードを置く。結論に必要な証拠 (メトリクス・ログ・トレース・変更履歴) が揃っているかを確認し、揃っていなければ調査に戻す。Cloud-OpsBench の ECR の考え方をワークフローに落としたものです
2. 対立仮説を最低 1 つ出させる。最初の仮説とは別の説明を 1 つ挙げさせ、それを棄却できる証拠を取りに行かせる。premature commitment / greedy diagnosis への対策です
3. 空の結果を「異常の可能性」として扱わせる。span が出ていない、endpoint が空、といった沈黙をプロンプトで明示的に疑わせる。presence bias への対策です
4. ツール引数を検証する。対象リソースやポートが実在するかを、実行前に Go 側でチェックする。tool-grounding の失敗は LLM ではなくコードで防げます
5. 修復の成功と診断の成功を分けて記録する。「直った」だけでは、たまたま再起動で直ったのか区別できません

評価の面では、Cloud-OpsBench の証拠グラフ方式が、AI in SRE の記事 で触れた IRM-Analyzer の Golden データの作り方に近いと感じました。自分たちの過去のインシデントから「この障害ならこの証拠を見るべき」という milestone を書き出しておけば、小さな社内ベンチマークが作れそうです。ORCA-bench は OpenTelemetry Astronomy Shop ベースなので、自作エージェントをローカルで試すのにも使えそうです。

参考

• OpenRCA 2.0: From Outcome Labels to Causal Process Supervision (arXiv 2606.27154)
• OpenRCA: Can Large Language Models Locate the Root Cause of Software Failures? (ICLR 2025)
• ORCA-bench: How Ready Are Language Model Agents for Oncall? (arXiv 2607.28545)
• Cloud-OpsBench (arXiv 2603.00468)
• LLM4Ops/Cloud-OpsBench
• SREGym: A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios (arXiv 2605.07161)
• Passing Without Repairing: Verifier Blind Spots in a Live SRE Agent Benchmark (NeurIPS 2026)
• 2026年6月現時点において SRE がどう AI に向き合っているか調べてみた
• Google が提唱する AI in SRE とは何か
• ADK Go 2.0 のグラフワークフローを読んで SRE Agent への応用を考える