# agentic SRE ## 定義 agentic SRE は、本番システムの障害調査・診断・緩和を AI エージェントが実行する取り組みである。一般的なコード生成エージェントと異なり、マルチモーダルなオブザーバビリティデータ、運用ツール、実行時にしか結果が見えない緩和操作、安全な権限委譲を扱う必要がある。([[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) 本ページは親ページとして、評価・安全・自律度・主要失敗モードの地図を持つ。RCA 詳細は [[根本原因分析]]、緩和詳細は [[障害緩和]]、安全仕様は [[エージェント運用安全性]] と [[Transactional No-Regression]] に分ける。 ## 横断的知見 - **AIOps と agentic SRE は重なるが視点が違う**: [[AIOps]] は IT 運用タスクの AI 化を能力別に整理し、agentic SRE は SRE 実務の調査・緩和ループをエージェントとしてどう動かすかに焦点を置く。 - **主要な失敗モードは情報取得と仮説管理に集中する**: AIOpsLab は不要な tool call とテレメトリ過消費を、SREGym は最初のもっともらしい異常への固着を報告する。([[@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]] の [[Transactional No-Regression]] は、巻き戻し可能な試行で緩和探索を安全にする。単発の修正生成ではなく、実行・検証・undo を含む制御ループが必要になる。([[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - **産業実装はカバー範囲で分化する**: Google の AI Operator は自律緩和やアクチュエーションまで踏み込む一方、Datadog の Bits AI SRE は調査・RCA に注力する。([[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]], [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]]) - **SRE Book は前史である**: エラーバジェット、トイル削減、自動化ヒエラルキー、Effective Troubleshooting は、agentic SRE が自動化しようとしている作業構造を先に定義している。([[@2016__OReilly__SRE Book - Chapter 1 Introduction]], [[@2016__OReilly__SRE Book - Chapter 7 Automation at Google]]) - **自律 SRE エージェントの初期実用化は、緩和よりも診断補助で始まっている**: [[RCAgent]] は Alibaba Cloud の Flink OoD ジョブ診断で、人間 SRE に RCA 結果を渡すフィードバック機構として統合された。[[Bits AI SRE]] も調査・RCA 特化であり、[[Stratus]] や Google AI Operator のように実行・緩和まで踏み込む系統とは権限面が異なる。agentic SRE は「人間診断を速くする読み取り中心エージェント」と「システムを変更する書き込み権限付きエージェント」に分けて評価すべきである。(Source: [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]], [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - **agentic SRE のスコープは RCA に閉じず SDLC 全体に広がる**: 学術ベンチが「RCA/mitigation の成功率」に閉じていたのに対し、Google SRE は SRE AI の適用領域を (1) reliability design(プレイブックの利用実態に基づく継続改善とインシデントからの新規生成)・(2) anomaly detection & alerting(時系列基盤モデル [[TimesFM]] による静的閾値の脱却 + autonomous alert handlers)・(3) incident management(IMAG への agentic orchestration layer: コミュニケーション監視/SRE 間ハンドオフ文書/ポストモーテム下書き/内外通信)・(4) incident investigation(自律調査・緩和)・(5) insights & risk management([[AI Insights]] による過去事例の連続知識化 + risk category 注釈)の 5 領域に広げる。学術ベンチ([[SREGym]]/[[AIOpsLab]])の評価軸を「SDLC 全体の自動化度」へ拡張する必要を示唆する。(Source: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]], [[SRE AI Autonomy Levels]]) - **本番 agentic SRE スタックの「外向き表記」が一次資料として固定された**: Google SRE AI の本番スタックが Gemini(社内ファインチューン版を含む)+ [[Gemini Enterprise Agent Platform]](旧 Vertex AI、リブランドが本ブログで一次確認)+ [[Agent Development Kit]](ADK)+ MCP servers + BigQuery + vector DB と明示された。これは whitepaper が社内コードネーム([[Detectr]]/[[AI Operator]]/[[Actus]])で語っていた同じシステムを、**外部開発者が真似て構築できる公開製品名で**示し直す位置にある。agentic SRE の研究と外部実装に「再現可能な部品リスト」が初めて公式情報として開示された。(Source: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) - **エージェント導入は緩和対象を減らすだけでなく、複雑性を足す**: Brush は、AIOps が解の一部である一方、非決定的に振る舞う別システムを既存システムに足すため、元のシステムより複雑になると警告する。これは Google SRE AI の段階的自律度設計や Stratus の TNR が示す「書き込み権限付きエージェントには検証・巻き戻し・ゲートが必要」という安全設計と同じ方向で、agentic SRE を単なる自動化ではなく複雑性管理の問題として扱うべきことを補強する。(Source: [[@2026__SREcon26 Americas__Taming the Unpredictable - Reliability in Chaos]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - **産業実装ではユーザー共感とツール集約が AI 統合の前提条件になる**: Databricks の [[Storax]] 事例では、AI エージェントを導入する前に社内 on-call エンジニアへのインタビューと同行観察を行い、バラバラなツールとコンテキストを集中化した。最初のイテレーションは AI をほぼ使わなかった。AI エージェントは「技術的に正しいアーキテクチャ」だけでは採用されない——ユーザーとの信頼関係とエージェントが依拠する情報基盤の整備が先行条件になるという示唆は、[[RCAgent]](Alibaba)や [[Bits AI SRE]](Datadog)の「診断補助から始める」段階論と重なる。(Source: [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]], [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]], [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]]) - **承認ゲートの粒度設計が産業実装の安全性を決める**: [[Storax]] は Temporal ワークフローで DB 操作に2人目承認ゲートを設ける設計を採る。[[Stratus]] の Transactional No-Regression が「モデル内部仕様で書き込みを安全にする」方向と違い、Storax は「LLM が実行判断→Temporal が実行制御→人間が最終承認」という外付けワークフローで安全性を保証する。同一の問題意識に対して、モデル内部仕様と外付けワークフローエンジンという異なる解を産業実装が採っていることが確認できる。(Source: [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - **実務導入の入口は「本番変更を任せる」より「SRE 判断を下支えする」段にある**: Yoshikawa の資料は、SLI/SLO 候補提案、PRC 観点レビュー、障害対応中の状況要約、ポストモーテム下書きという、書き込み権限より前の SRE 判断支援を具体例に置く。これは Storax や Bits AI SRE が診断補助から始めるパターンと整合し、agentic SRE の普及経路が L1-L2 の人間承認付き補助から始まることを補強する。(Source: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]], [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]], [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]]) - **調査エージェントから修正エージェントへの拡張が産業製品レベルで始まった**: [[Bits AI SRE]] の Bits AI Dev Agent（プレビュー）は、根本原因を特定した後にコード修正を提案し PR を生成する。これは「読み取り中心の診断エージェント → 書き込み権限付きの修正エージェント」への最初の公開産業実装であり、[[AI Operator]]（Google）がアクチュエーションまで踏み込む方向と異なり、PR レビュー・マージという人間ゲートを維持する保守的な拡張パターンを採る。(Source: [[@2025__Datadog__Introducing Bits AI SRE]]) - **プロアクティブ調査トリガーが産業製品で明示された**: アラート（リアクティブ）に加え、合成 API テスト・APM Watchdog ストーリー（プロアクティブ）を調査起動点とする設計が [[Bits AI SRE]] のプレビューで示された。これは agentic SRE の評価軸を「インシデント後の RCA 精度」から「障害顕在化前の潜在リスク検知」へ広げる動きであり、[[@2025__arXiv__ARGOS - Agentic Time-Series Anomaly Detection with Autonomous Rule Generation via Large Language Models|ARGOS]]（LLM ルール生成によるプロアクティブ異常検知）と方向性が一致する。(Source: [[@2025__Datadog__Introducing Bits AI SRE]], [[@2025__arXiv__ARGOS - Agentic Time-Series Anomaly Detection with Autonomous Rule Generation via Large Language Models]]) - **調査間の文脈記憶が産業実装の継続改善を担う**: Bits AI SRE は調査ごとに記憶を蓄積し、エンジニアのフィードバックで性能ループを形成する。学術ベンチは単発の成功率を測るが、産業実装では「複数インシデントを経て性能が向上するか」が実用的な評価軸となる。この知識蓄積の仕組みは [[RCAgent]] の human feedback 機構と同じ方向にあり、agentic SRE の評価は「単発精度」から「反復改善速度」を加えた多軸に移行する可能性を示す。(Source: [[@2025__Datadog__Introducing Bits AI SRE]], [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]]) - **評価駆動開発が「オンコール補助エージェント」の産業実装で具体化した**: [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]] は、チケット説明と期待仮説を対にしたベンチマークデータセットを構築し、Promptfoo によるオフライン評価とユーザーフィードバック(サムズアップ/ダウン)をフライホイールとして回す。これは Bits AI SRE の反復改善パターンや Storax のユーザー共感先行論と同じ「診断補助から始めて継続的にプロンプトを鍛える」路線であり、agentic SRE の評価軸を「単発精度」から「反復改善速度」へ拡張する具体例をもう一件加える。(Source: [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]], [[@2025__Datadog__Introducing Bits AI SRE]], [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]]) - **時系列データを画像として渡す方が、CSV/JSON で渡すより異常検知の推論精度が高い**という DeepMind の知見を根拠に、Amazon の実装は Grafana の image renderer プラグインでダッシュボードを画像化してエージェントに渡す設計を採る。同一グラフに対し人間が「10分の低下」、エージェントが「12分の低下」と近い水準で推論できた例を示しており、マルチモーダル入力が human-agent の共通理解を成立させる具体的な設計判断として、agentic SRE のオブザーバビリティデータ取り扱いに新しい選択肢を加える。(Source: [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]]) - **統制実験による多モデル比較が「モデル選定は単一指標では決まらない」ことを定量化した**: [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] は Red Hat OpenShift 上の [[ReAct]] エージェントに同一ツール・同一プロンプトで 10 モデルを接続し、精度・レイテンシ・トークン消費量を独立 3 軸として評価した。GPT-3.5 Turbo が LangChain 統合の内部例外でゼロトークン完了しつつ計測可能な応答時間を示した例は、[[RCAgent]] のツール足場設計や本ページの「情報取得と仮説管理の失敗モード」知見に、フレームワーク統合層固有の失敗という新しいカテゴリを追加する。(Source: [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] §4, §5.2) - **メモリの有無が SRE エージェントの正確性を左右する具体例が実証された**: 時間的再計算を要するクエリ(タイムスタンプ計算等)で明示的メモリが古い/誤適用された文脈保持により性能を劣化させたため、著者らは精度優先でメモリを無効化した。これは [[エージェントメモリ]] が扱う「継続性 vs 精度」のトレードオフを、AIOps エージェントの実運用判断として裏付ける一次資料である。(Source: [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] §5.1) - **「調査補助に用途を絞り、判断と実行は人間に残す」というスコープ限定は、産業実装が段階的に到達した知見であると同時に、ゲスト著者による観察としても独立に再確認される**: [[@2026__OReilly__Observability Engineering 2E - Chapter 10 The Role of AI Agents for Observability]] は、インシデント対応の最良実装が end to end 自動化を狙わず、調査の機械的な部分をエージェントに任せ判断・実行は人間に残す設計だと述べる。これは本ページが既に集約している「読み取り中心の診断エージェント([[RCAgent]]・[[Bits AI SRE]])から始まり、書き込み権限は Storax の二人承認ゲートや Stratus の Transactional No-Regression のような外付け/内部安全機構でしか拡張されない」という産業実装の収束パターンと一致する。学術ベンチ・産業事例に続き、書籍という第三の情報源(SRE 専業ではなくオブザーバビリティ実務者の視点)が同じスコープ限定に独立に到達したことで、この知見の頑健性が増す。 - **コンテキストなしクエリの4つの失敗モードは、本ページの「情報取得と仮説管理」失敗モードを具体化する**: 本ページはAIOpsLabの不要なtool call・SREGymの最初のもっともらしい異常への固着を失敗モードとして挙げてきたが、書籍第10章はこれをより一般化し、(1)エージェントが自分の知識の欠落に気づけない、(2)`user-service`/`users-svc`のような命名の氾濫に正準マップがない、(3)毎分数百万スパンに達するデータ表面の大きさ、(4)相関と因果の混同、の4点に整理する。特に(2)の命名問題は学術ベンチ(制御された環境で命名が整備済み)には現れにくく、本番の混沌とした環境固有の失敗モードとして本ページに新しい観点を加える。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 10 The Role of AI Agents for Observability]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **自由形式のReAct推論を依存グラフで明示的に制約すると、精度とトークン効率を同時に改善できる**: 本ページの失敗モード知見(AIOpsLabの不要なtool call、SREGymの最初のもっともらしい異常への固着)は、いずれもReAct型エージェントがLLMの自己回帰的推論だけに頼ることに起因する。[[@2026__DSN__PRAXIS - Integrating Program Analysis with Observability for Root-Cause Analysis|PRAXIS]](Cui+, DSN 2026)は、[[ITBench]]由来のReAct型SRE-Agentをベースラインに、サービス依存グラフ(SDG)とプログラム依存グラフ(PDG)へのLLM駆動グラフトラバーサルへ置き換えることで、根本原因推論精度を6.3倍・トークン消費を5.3倍改善したと報告する。これは「エージェントの自由度を上げる」方向とは逆に、「グラフ構造で推論経路を制約する」ことが精度・効率の両方に効くという、本ページの失敗モード議論に対する具体的な処方箋を加える。ITBenchの設計者([[Saurabh Jha]])自身がPRAXISの共著者でもあり、ベンチマーク作者がベースライン限界の是正策も提示する構図は、本ページが既に指摘する「ベンチマーク作者がエージェントも作る近接コミュニティ」パターン([[STRATUS]]の項を参照)をコード知識強化の軸でもう一件加える。(Source: [[@2026__DSN__PRAXIS - Integrating Program Analysis with Observability for Root-Cause Analysis]] §VI-A, Table III) - **明示的な指示があってもコードツールの呼び出し率が半分以下にとどまる、というツール呼び出しの脆弱性は、本ページの失敗モード分類に「ツール不使用」という新しいカテゴリを加える**: PRAXISの評価によれば、コード取得・検査ツールを追加したSRE-Agent+CTは、明示的な指示にもかかわらずコード分析が必要な実行の46%でしかそのツールを呼び出さなかった。これはAIOpsLabの「不要なtool call」やRed Hat OpenShift実験報告([[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]])の「フレームワーク統合層固有の失敗」とも異なる、「呼ぶべきツールを呼ばない」という第3の失敗モードであり、ツールをワークフローの必須ステップとして構造的に組み込む(PRAXISのようにPDGトラバーサルをエージェントの主経路そのものにする)ことが、プロンプト指示だけに頼るより頑健である可能性を示す。(Source: [[@2026__DSN__PRAXIS - Integrating Program Analysis with Observability for Root-Cause Analysis]] §VI-A) - **SRE の役割変化(responder → supervisor → specifier)は、本ページが集積してきた承認ゲート事例に理論的な理由づけを与える**: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]] §6.1 は、STRATUS のようなエージェントが前線対応を引き受けるにつれ SRE の役割がランブック実行者から agent behavior の仕様策定者(specifier)へ移ると論じ、TNR の安全保証が「人間が定義した health condition の網羅性」に条件づけられる(仕様漏れがあれば no-regression と認定されつつ実質的には悪化しうる)と明言する。これは本ページが既に集積している Storax の二人承認ゲートや Bits AI Dev Agent の PR レビューゲートのような「産業実装が書き込み権限の前に人間ゲートを置く」パターンに、「なぜそのゲートが必要か」という理論的根拠を与える。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]] §6.1, [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]]) - **決定論的な状態機械による task-based 編成が、会話・討議型の role-based 編成より agentic SRE に適することが定量比較で裏付けられた**: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] は「マルチエージェントの会話・討論は安全性推論と即時性を要する SRE には不適」と設計判断のみ述べていたが、[[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.6 はこれを AutoGen ベースの role-based 設計(Application Developer/Platform Engineer/System Administrator/Team Manager のロールで会話するエージェント)との直接比較で実証する: role-based 設計は AIOpsLab 48 問中 10 問しか解けず(STRATUS の task-based 設計の成功率を大きく下回る)、単純な検知問題ですら 893 秒と STRATUS の 25 倍の時間を要した。原因は各エージェントが部分的なシステム観のまま過剰に対話し、ラウンドロビン方式の話者選択が毎ステップ全エージェントを発言させ冗長なテレメトリ再検証を招いたことにある。[[Transactional No-Regression]] の writer exclusivity(A1)が要求する「単一 writer による直列実行」という安全制約が、そのまま「task-based 編成の方が速く・多く解ける」という性能上の利点にも転化しており、agentic SRE のマルチエージェント設計では**安全設計と性能設計が同じ選択(タスクで役割を切り、対話でなく状態機械で統率する)に収束する**ことを示す一次実証である。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.6, [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - **agentic SRE の評価方法論は「対話型エージェント」と「非対話型アルゴリズム」で意図的にプロトコルを分岐させ、速度対精度のトレードオフを可視化する**: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] §5.8 が明かす AIOpsLab の評価設定では、LLM ベースエージェント(GPT-w-Shell/ReAct/FLASH)は Orchestrator とのセッションを通じてライブ環境と対話するのに対し、比較対象の非LLM古典的 AIOps アルゴリズム(MKSMC/RMLAD/PDiagnose)はオフラインエクスポートされたテレメトリを直接与えられるだけで環境とは対話しない。この設計により古典的アルゴリズムは1〜2秒で実行が終わる一方、対応タスクでLLMエージェントに精度で大きく劣後する(検知: MKSMC 15.38% 対 FLASH 100%)。単一の評価基準でエージェントを並べるのではなく、評価対象の性質(対話型/非対話型)に応じてプロトコルを分岐させることで速度と正確性のトレードオフを意図的に可視化する、という評価設計上の判断が確認できる。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] §5.8) - **評価オラクルは「単一正解との完全一致」と「システム全体の健全性判定」を使い分ける**: 同章 §5.3 は、AIOps 問題の期待解 S(オラクル)についてタスクごとに設計が異なると明記する。箇所特定のような問題は障害注入対象そのものとの厳密一致(is_exact_match)で採点する一方、緩和のように複数の解き方がありうる問題では、注入対象のリソースだけでなく全サービスが稼働しているかというシステム全体の健全性を評価する——緩和作業中に他のサービス・リソースが意図せず影響を受けうるためである。これは AIOpsLab の評価が「唯一の正解ラベル」と「状態全体の健全性」という2種類のオラクル設計を、タスクの性質に応じて明示的に使い分けていることを示し、[[Transactional No-Regression]] が緩和の安全性を「health condition の網羅性」で判定する設計と同じ発想の評価版として読める。加えて、正誤ベースのオラクルは「誤った理由で正解する」ケース(二択検知で異常を正しく特定しつつ無関係な正常ワークロードを説明に引用する等)を見逃しうるため、オプションの LLM-as-Judge による軌跡レベル評価が併用される。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] §5.3, §5.9) - **管理エージェントの評価軸は、障害対応の正確性だけでなく、PRレビューや保守を含む成果単位のコスト・品質・処理量へ拡張される**: Uber はコードレビュー、CI障害の自己修復、アラート処理、コード保守を管理エージェント群のライフサイクルに置き、成果当たりコスト、リバート率・F1・MTTR、処理量を同時に追跡する。agentic SRE を本番障害対応だけでなく、ソフトウェア開発ライフサイクル全体の信頼性作業へ広げる測定単位が示される。(Source: [[@2026__Uber__Running a Software Factory Efficiently at Uber Scale]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - [[XiHe]](物理ネットワーク向け根本原因分析マルチエージェント、Alibaba Cloudで12ヶ月本番運用)は、単一エージェントのメモリ飽和をデバイス/アラート信号単位の分割で回避しつつ、分割が生む部分観測性を[[Networked Agent Memory]](軽量プリミティブREQ/CONF/BCSTによるトポロジ制約付きピア間通信)で解消するという、マルチエージェントSREの「分割してもグローバル文脈を失わない」設計の具体例を提供する。誤診断の削減はメモリ共有機構(NAM)導入で36.2%、検証付き因果統合(NCR)追加でさらに21.1%と、要因ごとに定量分離されている。(Source: [[@2026__SIGCOMM__Networked Agent Memory and Causality Representation - Experiences towards Interpretable Cloud-Scale Root-Causing]]) - [[XiHe]]の運用経験は、静的で網羅的なプロンプト(全ルールの前もった注入)がむしろ未到着アラートの捏造(幻覚)を誘発するとし、アラート到着時にのみ該当ルールを注入するjust-in-timeコンテキスト管理へ転換したと報告する。これはBiAnの知見とも符合し、エージェント型SREにおける「プロンプトは長いほど良いわけではない」という論点を補強する。(Source: [[@2026__SIGCOMM__Networked Agent Memory and Causality Representation - Experiences towards Interpretable Cloud-Scale Root-Causing]]) ## 未解決の問い - 学術ベンチの成功率と産業実装の MTTM/TTR 改善は、どうすれば同じ物差しで比較できるか。 - LLM エージェントに複数仮説の並行検証と明示的な停止条件をどう実装するか。 - 緩和が「たまたま直った」ケースと、正しい診断に基づく修復をどう区別して評価するか。 - 自律度を上げるためのガードレールは、モデル内部の仕様(TNR)と外付けゲート(Actus/verification wall)をどう組み合わせるべきか。 - RCAgent の H-Helpfulness は 2.92/5 で「中程度の支援」にとどまる。読み取り中心の診断エージェントは、どの有用性閾値を超えたときにオンコールの標準ワークフローへ組み込むべきか。 - エージェントがコードベース全体から低コストにリスクを発見・修正できるとき、agentic SRE の評価は「重大インシデントを直せるか」だけでなく「小さな潜在リスクを継続的に減らせるか」をどう測るべきか。 - 多段ツール連鎖の信頼性(単発ツール精度から独立して劣化しうる)は、どのモデルファミリー・どのフレームワーク(LangChain/LangGraph 等)の組み合わせで最も安定するか。抽象化フレームワーク層の実装差(バージョン依存・言語バインディング差)がエージェント性能に与える影響は体系的に検証されていない。([[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] §6) - マルチエージェント・マルチモデル協調の効率化: エージェント間の過剰・無秩序な通信を避けつつ同期する仕組み、レイテンシに敏感な場面で大規模モデルと小規模モデルを動的に切り替える仕組みは未解決である。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]] §6.2) - [[Transactional No-Regression]] をロールバック可能な undo に限らず、rollback-aware な実行と、行動後の健全性を継続評価して再試行/reflect/エスカレーションを判断する validation oracle を含む、より広いクラスのエージェント駆動アクションへどう拡張するか。(Source: 同上 §6.2) - 自律エージェントが重要インフラで損害を引き起こしたとき、運用者・配備組織・モデルベンダーのいずれが答えるべきかという説明責任・法的責任の所在は未確立である。(Source: 同上 §6.1) - task-based(状態機械)設計が role-based(対話)設計に勝る 10/48 対 STRATUS という差は AIOpsLab の 48 問サンプルのみで確認された。この優位はより多くのエージェント(3体超)・より対話が必要なタスク(複数チーム間の合意形成を要する障害等)でも一貫するか、それとも role-based 設計が有利になる SRE タスクの領域は存在するか。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.6) - 対話型 LLM エージェントと非対話型の古典的アルゴリズムを、同一の正解率指標だけで比較してよいか。評価プロトコル自体が異なる(前者はライブ環境と対話、後者はオフラインテレメトリを一括受領)ため、速度対精度のトレードオフを踏まえた正規化指標が必要ではないか。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] §5.8) - 管理エージェントの成果当たりコストを、障害緩和の安全性・再発率・人間のレビュー負荷と結合した評価へどのように拡張するか。([[@2026__Uber__Running a Software Factory Efficiently at Uber Scale]]) ## 関連 - 子/隣接 concept: [[SRE Benchmark]] / [[エージェント運用安全性]] / [[SRE AI Autonomy Levels]] / [[Transactional No-Regression]] / [[根本原因分析]] / [[障害緩和]] / [[自動化のアイロニー]] / [[データベース O&M]] - 産業実装 entity: [[Storax]] (Databricks) / [[Bits AI SRE]] (Datadog) / Google AI Operator - 親/周辺: [[AIOps]] / [[SRE]] / [[NetOps]] - ソース: [[@2026__SpeakerDeck__Reliability in the Age of AI - Engineering for AI Velocity]] / [[@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__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] / [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] / [[@2026__SREcon26 Americas__Taming the Unpredictable - Reliability in Chaos]] / [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]] / [[@2025__Datadog__Introducing Bits AI SRE]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 10 The Role of AI Agents for Observability]] / [[@2026__DSN__PRAXIS - Integrating Program Analysis with Observability for Root-Cause Analysis]] / [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] / [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] / [[@2026__SIGCOMM__Networked Agent Memory and Causality Representation - Experiences towards Interpretable Cloud-Scale Root-Causing]] ## 出典 - [[@2026__DSN__PRAXIS - Integrating Program Analysis with Observability for Root-Cause Analysis]](§VI-A ベースライン比較、Table III・IV、ReAct型SRE-Agentに対するグラフ制約推論の効果) - [[@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__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] - [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]](SDLC 全体のスコープ、本番スタック公開製品名、AI Insights、TimesFM、IMAG agentic orchestration layer) - [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]] - [[@2016__OReilly__SRE Book - Chapter 1 Introduction]] - [[@2016__OReilly__SRE Book - Chapter 7 Automation at Google]] - [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]] - [[@2026__SREcon26 Americas__Taming the Unpredictable - Reliability in Chaos]] - [[@2026__SREcon26 Americas__How We Debug 1000s of Databases with AI]](産業実装、Storax、ユーザー共感先行論、承認ゲート設計) - [[@2025__Datadog__Introducing Bits AI SRE]](GA 発表、Bits AI Dev Agent プレビュー、調査トリガー拡大、文脈記憶) - [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]](§3 ReAct エージェント実装、§4 多モデル比較、§5.1 メモリの影響) - [[@2026__OReilly__Observability Engineering 2E - Chapter 10 The Role of AI Agents for Observability]](インシデント対応・テレメトリ説明・計装品質改善の3用途、コンテキストなしクエリの4失敗モード、調査補助へのスコープ限定論) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]](§6.1 SREの役割変化・TNRの仕様網羅性への条件づけ・社会的含意、§6.2 マルチエージェント協調・TNR拡張) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]](§4.6 task-based 対 role-based マルチエージェント設計の定量比較) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]](§5.3 オラクル設計の使い分け、§5.8 対話型/非対話型エージェントの評価プロトコル分岐)