# AIOps ## 定義 AIOps(AI for IT Operations)は、IT/クラウド運用の検知・箇所特定・根本原因分析・緩和・予防を AI で支援または自動化する取り組みである。[[AIOpsLab]] は検知(Detection)、箇所特定(Localization)、[[根本原因分析]](RCA)、[[障害緩和]](Mitigation)の 4-level taxonomy を提示し、LLM エージェントによる自律運用を AgentOps と呼ぶ。([[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) このページは AIOps の親ページとして、能力軸・自律度軸・工程軸の地図を保持する。各段階の詳細は [[異常検知]]、[[Fault Localization]]、[[根本原因分析]]、[[障害緩和]] に分ける。 ## 横断的知見 - **障害管理は AIOps の中心だが、検知と診断は同じ出力にしない**: 坪内の 2022 年講演は、SLO による症状アラートをトリガーとして、別系統で原因診断を行う「Alert symptoms, diagnose causes」を提示した。後年の AIOpsLab の検知→箇所特定→根本原因分析→緩和という段階分類と並べると、これは能力段階を運用インターフェースへ分解する実装原則と読める。(Source: [[@2022__SRE NEXT 2022__AIOps研究録―SREのためのシステム障害の自動原因診断]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **能力軸**: AIOpsLab の 4-level taxonomy は「何ができるか」を切る。検知・箇所特定・RCA・緩和は段階的だが、実運用では前段の誤りが後段に伝播する。 - **自律度軸**: [[SRE AI Autonomy Levels]] は「どこまで人間を外せるか」を切る。タスク正答率と権限委譲は独立であり、能力が高くても書き込み権限には別のガードレールが要る。([[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) - **工程軸**: CSUR サーベイはデータ→タスク→手法→評価の工程フローで AIOps を整理する。AIOpsLab の 4 段より、箇所特定を RCA の下位に畳むなど粒度が違う。([[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]]) - **LLM エージェント化は情報取得の制御問題を前面化した**: AIOpsLab/SREGym/Bits AI SRE は、ツール呼び出し過多・最初の異常への固着・停止条件不在を主要失敗モードとして観測する。([[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **対象はインシデント対応からインフラ管理・DB・訓練運用へ広がる**: [[Infrastructure as Code]]、[[データベース O&M]]、[[LLM分散学習]] の運用障害管理は、AIOps の射程がサービス障害対応に閉じないことを示す。 - **AgentOps はエージェントシステム自体を運用対象とする AIOps の新サブ領域として確立されつつある**: AIOps が従来のマイクロサービス・クラウドインフラを対象にしてきたのに対し、[[エージェントシステム運用]](AgentOps)は LLM ベースのエージェントシステム**自体**の異常(幻覚・行動エラー・通信失敗・オーケストレーション障害)を運用対象とする。エージェントシステムの実行軌跡は意味的決定パスであり、マイクロサービストレースの構造的実行パスとは本質的に異なるため、異常の定義・検知・局所化・解決の全段階で固有の設計が必要になる。本 wiki の AIOps 地図は AgentOps を子領域として位置づけるべきであり、既存の 4-level taxonomy(検知/箇所特定/RCA/緩和)に加えてエージェント固有の Intra-Agent / Inter-Agent タクソノミーが必要になる。(Source: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]]) - **産業 O&M における LLM ボトルネックは推論でなくオーケストレーション(適切なデータ・知識の選択)にあることが実証された**: [[Bian Que]]([[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]])は KuaiShou の数億ユーザー規模 EC 検索エンジンで 6 ヶ月本番稼働し、アラート量 75% 削減・RCA 精度 80%・MTTR 50% 圧縮を達成した。この知見は AIOpsLab/SREGym の「ツール呼び出し過多が主要失敗モード」([[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]])と一貫しており、O&M エージェントの評価と設計において「推論能力の向上」より「コンテキスト組み立ての制御」が先決である可能性を示唆する。(Source: [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]] §1, §3.4) - **オブザーバビリティデータモデルの品質が AIOps エージェントの性能を律速する**: [[UModel]] は 2025 AIOps Challenge で従来データモデル比 8% の RCA 精度改善（PaaS ツール層で IaaS 直接 SPL より OS +9〜+13 ポイント優位）を達成した。エージェントの推論能力向上ではなく「エージェントに何を見せるか」のデータ層の設計変更のみによる成果であり、AIOps 研究において観測可能性データモデル([[オブザーバビリティデータモデル]])が独立した性能決定因として認識される必要性を示す。Alibaba Cloud の本番 1 年以上の大規模検証（10M ops/秒）は工業グレードの実証として注目に値する。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §VI) - **事後対応中心の AIOps から「アラート発火前」をカバーする予防的 O&M への移行が始まっている**: [[PAGER]]([[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]])が積極的監視を提案し、[[Bian Que]]は統一運用パラダイムの 3 パターン(リリース遮断・積極的点検・アラート RCA)のうち前 2 者でアラート発火前の問題を解決する設計を採用した。既存 LLM ベース AIOps エージェントがアラートトリガーを唯一のエントリポイントとしてきたのに対し、この拡張はシステムライフサイクル全体を O&M の射程に収める。(Source: [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]] §1, §2.1) - **pre-LLM 期の AIOps タクソノミーは「介入時期 × 対象問題」の 2 軸で完結していた**: Notaro et al. 2021([[@2021__TIST__A Survey of AIOps Methods for Failure Management]])は AIOps の Failure Management 領域を proactive(failure prevention・online failure prediction)と reactive(failure detection・root-cause analysis・remediation)に分け、5 カテゴリ・14 サブカテゴリで 1,086 件中 100 件を整理した。AIOpsLab の 4-level taxonomy(検知・箇所特定・RCA・緩和)は本サーベイの reactive 側の再整理にあたり、proactive 側(prevention・prediction)が LLM-era では [[障害予測]]・[[Bian Que]] の予防的 O&M に脱皮していく。なお Notaro et al. は detection 33.7% / RCA 26.7% / online prediction 26.4% に対し prevention 10.6% / remediation 2.5% という極端な研究密度の偏りを定量化しており、これは LLM-era でも remediation/recovery が AIOpsLab の Mitigation で「実行は人間 or rollout 系のスクリプトに残す」という設計に引き継がれている。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §4, [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **AIOps の語が普及する前(2010)からオンライン障害予測 taxonomy は確立しており、4 系統(failure tracking / symptom monitoring / detected error reporting / undetected error auditing)が proactive/reactive 軸の起源として読める**: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] は約 50 のオンライン障害予測手法を入力データ系統で 4 主要枝に分解し(§4)、proactive fault management の 4 段階(予測 → 診断 → スケジューリング → 実行)を Figure 2 で整理した。Notaro et al. 2021 の proactive(prevention + online prediction)/reactive(detection + RCA + remediation)の 2 軸は、Salfner+ 2010 のこの 4 段階を再パッケージしたものに近い。失敗連鎖の概念モデル(fault → undetected error → detected error → failure + symptom)と評価指標(precision/recall, F-measure, ROC/AUC, contingency table)も Salfner+ 2010 §2-§3 で確立されており、後続の AIOps 評価論(AIOpsLab/SREGym)が稀事象対応の指標選択で踏襲する。LLM-era の AIOps 研究で「障害予測の評価が定まらない」という不満は、本サーベイの (`t_d, t_l, t_p, t_w`) 4 パラメータ枠組み(§2.2)を明示的に踏まえる作業の不在として読める。(Source: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §1.2 §2 §3 §4, [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §4) - **マルチモーダル化はサーベイ時代から残り続けた未解決課題で、UModel / TVDiag がその回答に位置づけられる**: Notaro et al. 2021 は Table 8 で 100 件の手法のほぼ全てが単一データソース(KPI のみ・log のみ・traffic のみ等)に依存していると指摘し、「マルチモーダル化が visibility と robustness を改善する」と将来課題に挙げた。5 年後、[[UModel]] のオブジェクト中心データモデル([[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]])や TVDiag のマルチモーダル統合([[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]])が、エージェント層でなくデータ層で同じ課題を再定式化している。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §5.1, [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]]) - **産業 AIOps エージェントは「強い外部 LLM」から「社内配置モデル + 環境設計」へ現実化する**: [[RCAgent]] はプライバシー制約により GPT 系 API を使わず、Vicuna-13B-V1.5-16K を社内配置して Apache Flink の OoD ジョブ診断に統合した。[[Google]] の AI Operator や [[Datadog]] の Bits AI SRE が運用ワークフローへの統合を示す一方、RCAgent はモデル能力を補うための OBSK、意味的に最小なツール、JsonRegen、TSC という「環境側の足場」を詳細にアブレーションしており、AIOps の実用化がモデル選択だけでなく、データアクセス面・出力形式・停止条件の設計問題であることを示す。(Source: [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]], [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]], [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]]) - **AIOps の介入点が「事業者中心」から「利用者中心」へ拡張する第三軸**: 本ページの能力軸(4-level)・自律度軸(Levels)・工程軸(データ→評価)は、いずれも事業者(プロバイダ)が AIOps を運営する前提に立っていた。[[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] はこれを利用者側で動かす user-centric paradigm を提示し、[[TSGuard]] を pre-ticket interception layer として実装した。Azure 本番 1 年データの median TTM 52.5 時間 / mean 83.0 時間という inefficiency が「ユーザ知識ギャップ + 報告品質ばらつき + プロバイダ一律対応」の三重構造で生じることを実証し、ユーザ側エージェントが初動診断 → 不解決時のみ高品質チケットでエスカレートする 4 段ループへ書き換える。AIOps 地図はこれまで provider-centric を所与にしてきたが、AI ワークロード(GPU 訓練)のようなテナント境界の明確なドメインでは「誰が AIOps を動かすか」の主体軸が独立した設計次元として立ち上がる。(Source: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]]) - **AI ワークロード基盤の運用は AIOps 内に独立サブ領域を形成しつつある**: 本 wiki の AIOps は事業者向けクラウドサービス(従来クラウドワークロード)を主対象としてきたが、TSGuard が定量化した GPU 偏重(52.47%)・recurrence 高(8.78)という分布は code/dependency 系で 40%+ という従来クラウド([19] Ghosh+ SoCC 2022)と質的に違い、AI ワークロード固有の検証手段(SuperBench/DCGM/NCCL-test/dmesg)が中心になる。Aegis・Minder・SkeletonHunter・L4・XPUTimer・MegaScale 等が GPU/集合通信の信頼性運用を扱ってきた本 wiki の系譜と、TSGuard の user-centric incident 診断は同一の AI ワークロード基盤を異なる層で攻めている。AIOps 地図は AgentOps と並んで「AI ワークロード基盤の運用」を独立サブ領域として識別する段階に来ている([[耐障害LLM訓練]]・[[LLM学習モニタリング]] と接続)。(Source: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]], [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]]) - **Remil+ 2024 の 6 能力モデル(Perception/Prevention/Detection/Location/Action/Interaction)は本ページの「能力軸」を再構成する位置にある**: 本ページは AIOpsLab の 4-level taxonomy(検知/箇所特定/RCA/緩和)を能力軸の基準としてきたが、[[@2024__arXiv__AIOps Solutions for Incident Management]] §1.2 はその前後に Perception(多様な異種ソースの収集・ストリーミング/履歴対応)・Prevention(障害発生前の能動的同定)を置き、Action(triage + auto-healing)と Interaction(双方向 human-AI loop)を独立能力として明示する。AIOpsLab の 4 段は Remil+ の Detection/Location/Action にほぼ対応し、Perception と Interaction が AIOpsLab で陰に含まれていた「テレメトリ収集」と「人間との協調」を表に出したもの。LLM-era の [[AIOpsLab]]・[[SREGym]] が「Perception を所与とし Detection 以降を評価する」設計を取りがちな点は、Remil+ の 6 能力で再評価できる(例: テレメトリ層([[UModel]])を Perception 能力の独立評価軸として加える、人間引き渡し([[SRE AI Autonomy Levels]] の Self-Direct)を Interaction の評価軸として独立に測る)。(Source: [[@2024__arXiv__AIOps Solutions for Incident Management]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]], [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]]) - **Notaro+ 2021 と Remil+ 2024 という独立した 2 つの pre-LLM 期サーベイが、研究密度の構造的偏り(検知・予測・RCA 集中、classification/correlation/mitigation 手薄)を別データで再確認した**: [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] が 1,086 件中 100 件で「detection 33.7% / RCA 26.7% / online prediction 26.4% / prevention 10.6% / remediation 2.5%」と定量化した偏りを、[[@2024__arXiv__AIOps Solutions for Incident Management]] は別の文献選定・別のタスク分類(4 フェーズ × 9 タスク)で再構成しつつ Figure 14 で同型の構造を示す(検知 + 予測が過半、classification/correlation/mitigation は最薄)。著者集団も研究機関も異なる 2 つの独立サーベイが pre-LLM 期 AIOps 研究の同じ偏りを示すことは、この偏りが文献選定バイアスでなく **AIOps 研究空間の構造的偏り**(緩和の AI 化は問題解決の最後の 1 マイルで「過去解の再利用で済むことが多い」)である可能性を強める。LLM-era の本 wiki も [[Bits AI SRE]]・[[STRATUS]]・[[OpsAgent]] の緩和は実行を人間/スクリプトに残す設計を採り、構造的偏りが LLM-era にも持ち越されているか検証すべき問いを残す。(Source: [[@2024__arXiv__AIOps Solutions for Incident Management]] §7 Figure 14, [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §5.1) - **descriptive 模型(pattern mining・formal concept analysis)を predictive 模型の対等な相棒に据える主張は、本 wiki が LLM 時代に追ってこなかった視点を補完する**: 本 wiki の AIOps 系ソースは LLM・MAS・RL・ベイズ・自己進化など predictive/agentic 方向に蓄積してきた。Remil+ 2024 §7 は「predictive 模型はラベル不足・データ品質・ブラックボックス性で制約され、descriptive 模型(supervised rule discovery [Atzmueller+ 32]、formal concept analysis [Cellier+ 55, Le Goues+ 122])がデータ多様性・複雑性・品質への強さ、特に deduplication との親和性で優位」と主張する。Notaro+ 2021 も Yu+ 2024 も pattern mining を主軸に据えてはいないので、Remil+ の独自方向。LLM 時代の本 wiki の [[AlertGuardian]] の rule refinement、[[FlowXpert]] のワークフロー生成、[[TSGuard]] のタクソノミー半自動構築はいずれも descriptive 知識の自動構築側に寄っており、pattern mining 系手法と LLM の融合(LLM が descriptive 規則を抽出/維持する)が次の地図の空白として浮上する。(Source: [[@2024__arXiv__AIOps Solutions for Incident Management]] §7, [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[@2025__KDD__FlowXpert - Expertizing Troubleshooting Workflow Orchestration with Knowledge Base and Multi-Agent Coevolution]], [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]]) - **AIOps 評価の落とし穴として "contamination zone" が独立サーベイから明示された**: Remil+ 2024 §3.1, §4.2 は Fourure+ 2021 [91] を引いて「訓練/テスト分割の比率を操作することで anomaly detection の F1 が人為的に上がりうる」現象を contamination zone と呼び、in-context evaluation(anomaly のテストセットを訓練/検証より厳密に時間的後に置く等)を desiderata に組み込む。本 wiki の [[RCA評価設計]] が現状取り上げているのは learn-from-the-future や時系列リーク等の論点だが、contamination zone の概念は anomaly detection の F1 報告全般に再評価を迫る独立した論点。LLM-era ベンチマークの [[AIOpsLab]]・[[SREGym]]・[[OpenRCA]] が報告する数値の妥当性も、contamination zone の規律で再検証されるべき可能性。(Source: [[@2024__arXiv__AIOps Solutions for Incident Management]] §3.1, §3.4, §4.2) - **ラベルなし SSL フレームワークが AD・FT・RCL の 3 タスクを「偏差ベクトル」の共有表現で統一できることを実証**: ART([[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]], ASE 2024)は、マイクロサービスの実証研究で障害時の SLD ノルムが正常時比 22% 増大・根本原因インスタンスの偏差コサイン類似度が 0.71 vs 非根本原因 0.49 を定量化し、AD・FT・RCL の 3 タスクが「インスタンス/システムレベルの偏差」という共有知識で解けることを理論と実験の両面で示した。AIOps の 4-level taxonomy(検知→箇所特定→RCA→緩和)のうち最初の 3 段を単一 SSL モデルで解く統一設計は、タスクをパイプライン分割する従来設計との比較で「統合ではなく共有表現が鍵」という設計知見を提供する。(Source: [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]], §2, Table 5〜7) - **AIOps の初期未来構想として、Interactive AIOps は「人間が異常を教える」方向を提示していた**: [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]] は、AIOps をクラウド耐障害性の最外殻であるオペレータ手動制御の自動化として位置づけたうえで、現状の研究は補助的な情報支援に留まると整理した。その解として [[Interactive AIOps]] を提唱し、運用データを広く共有できないなら、オペレータが故意に異常を作り AI に学習させる「実験可能性」と、AI が予測根拠を返す「解釈性」を基本型に置く。これは LLM-era の agentic AIOps 以前に、人間-AI 協働を「教師データ生成 + 説明」の相互作用として捉えた構想である。(Source: [[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]]) - **IcM BRAIN は pre-LLM 期の産業規模 AIOps フレームワーク設計の典型例であり、「機械学習モデル × ルールベース前処理」という 2020 年時点の到達点を示す**: [[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It|Chen+ ESEC/FSE 2020]] の IcM BRAIN は Microsoft の本番インシデント管理システム(IcM)に統合された AIOps フレームワークで、データ前処理(正規表現によるエンティティ抽出・ベイジアンネットワークによる特徴選択)+ 3 機能(LSTM/Random Forest 検知・GRU+CNN テキスト自動トリアージ・イベントベース+リソースガイド相関)で構成される。本 wiki が集積してきた LLM-era AIOps エージェント([[FLASH]]・[[OpsAgent]]・[[Bian Que]])が「LLM を当時の LSTM/GRU に置き換えた」という連続性で把握できる。2020 年時点では検知 F1≈0.7・自動トリアージ精度 0.64〜0.73 という限界が、LLM-era では [[OpsAgent]] の 84% RCA・[[Bian Que]] のアラート量 75% 削減に飛躍した。ただし BRAIN は 2 年間・6 サービスの実運用データで 5 指標(TTD/TTE/TTM/TTB/TTF)すべての統計的有意な改善を示した最初期の産業実証の一つであり、この empirical baseline が LLM-era 研究の比較基準として未活用なまま残っている。(Source: [[@2020__ESEC-FSE__Towards Intelligent Incident Management - Why We Need It and How We Make It]]) - **SRE 実務視点から見た AIOps 精度: 検知・局所化は現実的だが RCA・緩和は研究段階**: [[Ryota Yoshikawa]] が SRE NEXT 2025 で引用した AIOpsLab ベンチマーク(Chen et al. MLSys 2025)の数値は、インシデントレスポンスの AIOps 能力を段別に示す。検知(Detection): ReAct(GPT-4) → 86%・局所化(Localization): GPT-4 + Shell → 71%・根本原因分析(RCA): 全手法 → 14% 程度・緩和(Mitigation): GPT-4 + Shell → 43%。同発表が引用した OpenRCA(Xu et al. ICLR 2025, 335 件 + 68GB 超のログ・メトリクス・トレース)では Claude 3.5 Sonnet + Multi-Agent でも正答率 11% 程度にとどまる。「単純なシステムでは精度が高いが複雑になると精度が大きく低下」という現象は本 wiki が蓄積してきた「LLM エージェントは情報取得の制御問題でつまずく」という知見と一貫する。AIOps の能力軸では「検知・局所化 > 緩和 > RCA」という逆転順序が成立しており、end-to-end の自律 IR には RCA の精度向上が必要。(Source: [[@2025__SRE NEXT 2025__Rethinking Incident Response - Context-Aware AI in Practice]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]], [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]]) ## 未解決の問い - SLO ベースの症状アラートと原因診断器の間で、どの運用データをどの粒度・保持期間で渡すべきか。メトリクス・ログ・トレース・イベントの全量投入は診断の計算量と説明可能性を損ないうる。 - 分解採点(AIOpsLab)とエンドツーエンド評価(SREGym)のどちらが実運用能力をより正しく測るか。 - タスク能力と自律度を同時に上げるには、評価・権限・rollback・human fallback をどう組み合わせるべきか。 - 識別的モデル、ルール、LLM、実行エージェントを各段階でどう分業させれば、常時稼働のコストと RCA/緩和の推論力を両立できるか。 - 事後対応の AIOps と予防的な構成管理/障害予測を、1 つの運用ループへ統合できるか。 - AgentOps(エージェントシステム自体の O&M)と AgenticOps(エージェントを使った従来システム O&M)の技術スタックはどこまで共有できるか。[[エージェントシステム運用]] のモニタリング拡張(モデルデータ・チェックポイント)は AgenticOps に適用できるか、それともエージェント内部観測が必要な AgentOps 固有の要素か。([[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]]) - [[Bian Que]] はキーワードベースの Skill マッチングで産業規模 O&M を実現したが、学習済み埋め込みベースのマッチングへの移行は更にどの程度の精度改善をもたらすか。また [[Flexible Skill Arrangement]] の手法は他ドメイン(GPU クラスタ・IaC・DB)の O&M にも移植できるか。([[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]] Appendix C) - [[UModel]] のオントロジー構築コスト（EntitySet・DataLink の定義）は実際にどの程度かかるか。頻繁にサービス追加・変更が起きる環境での継続的メンテナンス負荷が定量化されていない。自動的なスキーマ発見・同期機構（例: サービスメッシュのサイドカーから EntitySet を自動生成）は実現可能か。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §V) - Notaro et al. 2021 が定量化した「prevention 10.6% / remediation 2.5%」という研究密度の偏りは、LLM-era(2023〜)でどこまで是正されたか。LLM ベース緩和エージェント([[Bits AI SRE]]・[[STRATUS]]・[[PAGER]])は本当に recovery を AI 主体に動かしているのか、それともなお人間 or 既存スクリプト主体のまま提案層に留まるか。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §5.1) - provider-centric / user-centric の主体軸は独立した設計次元として地図に追加すべきか、それとも自律度軸・能力軸の中で吸収できるか。TSGuard のように pre-ticket interception layer を user 側に置く設計は、code/dependency 主因の従来クラウドへも移植可能か、それとも AI ワークロードの hardware-physical 検証が前提でないと成立しないか。([[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]]) - RCAgent は Flink ジョブ診断で有効性を示したが、同じ社内配置モデル + ツール足場の設計は、マイクロサービス、DB O&M、GPU クラスタ運用のような別ドメインでも同じ安定化効果を持つか。特に SQL/SLS 直接ツールが破綻した結果は、各ドメインで「意味的に最小なツール」をどう設計するかという未解決問題を残す。(Source: [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]]) - Remil+ 2024 の interpretability 3 軸(internal/external/time consistency)は LLM ベース AIOps エージェントの説明出力(自然言語の RCA レポート・行動ログ)にどう適用できるか。同じ症状を与えたとき同じエージェントが同じ説明を返す内部一致性(internal)、複数エージェント間の説明一致性(external)、時間経過に対する説明の安定性(time)を、自然言語生成空間でどう測るか。([[@2024__arXiv__AIOps Solutions for Incident Management]] §3.4) - Remil+ 2024 が descriptive 模型(supervised rule discovery・FCA)の優位性を主張する deduplication・複雑な依存関係処理は、LLM が embedding 類似 + 規則生成で代替できるか、それとも pattern mining 固有の網羅性が必要か。AlertGuardian の rule refinement が pattern mining 系手法と統合する可能性は。([[@2024__arXiv__AIOps Solutions for Incident Management]] §7, [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - contamination zone を回避する temporal segregation を採用したとき、LLM-era ベンチマーク([[AIOpsLab]]/[[SREGym]]/[[OpenRCA]])の報告値はどれだけ下がるか。本 wiki が指標として参照してきた F1・正解率・解決時間は再校正が必要か。([[@2024__arXiv__AIOps Solutions for Incident Management]] §3.1, §4.2) - [[Interactive AIOps]] の実験可能性・解釈性・システム間学習性・訓練可能性は、LLM-era の AIOps エージェント設計にどこまで継承できるか。特に、エージェントが異常注入計画を提案する場合、実験安全性と学習効果をどう同時に保証するか。([[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]]) ## 関連 - 子 concept: [[異常検知]] / [[Fault Localization]] / [[根本原因分析]] / [[障害緩和]] / [[障害予測]] / [[エージェントシステム運用]] / [[Flexible Skill Arrangement]] / [[オブザーバビリティデータモデル]] - 隣接 concept: [[agentic SRE]] / [[SRE Benchmark]] / [[SRE AI Autonomy Levels]] / [[エージェント運用安全性]] / [[データベース O&M]] / [[NetOps]] - 実装システム: [[Bian Que]] / [[Kuaishou Technology]] / [[UModel]] / [[Alibaba Cloud]] - ソース: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] / [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]] / [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]] / [[@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]] - [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]] - [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]] - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] - [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] - [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]](§II 異常タクソノミー・§III AgentOps 定義・Figure 5 運用の進化軸・Figure 6 AIOps vs AgentOps 比較) - [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]](§1 ボトルネック分析・§2 統一パラダイム・§3 実験・Appendix C 限界) - [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]](§III Agent-Ready 4 要件・§IV UModel アーキテクチャ・§V Alibaba Cloud 本番展開・§VI 実験) - [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]](§2 privacy/context/action validity, §3 手法, §5 アブレーション, §6 デプロイ) - [[@2021__TIST__A Survey of AIOps Methods for Failure Management]](§3 taxonomy・データソース・指標、§4 5 カテゴリ・14 サブカテゴリの代表手法・定量結果、§5 マルチモーダル/ベンチマーク/recovery 不足の課題) - [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]](§1.2 PFM 4 段階・Figure 2、§2 fault/error/symptom/failure 5 段階モデル、§3 評価指標、§4 入力データ系統による 4 主要枝の taxonomy) - [[@2024__arXiv__AIOps Solutions for Incident Management]](§1.2 6 能力モデル、§2 用語法と時系列スキーマ・4 層 maintenance strata、§3 4 フェーズ × 9 タスク手続き・6 desiderata、§4 9 軸 taxonomy・8 データソース・contamination zone、§5 100+ 件の手法レビュー、§6 40+ データセット compendium、§7 descriptive 模型の再評価) - [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]](§2 実証研究 Table 1〜3、§3 ART フレームワーク CHA-TEM-CAL 構成、§4 アブレーション Table 7、§5 定量評価 Table 5〜6)