# 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]]、[[根本原因分析]]、[[障害緩和]] に分ける。 ## 子概念 - [[Causal Software Engineering]] - [[SRE Benchmark]] - [[agentic SRE]] - [[データベース O&M]] ## 横断的知見 - **AIOps という用語自体が「まだ達成されていない約束」として実務者から批判されてきた歴史がある**: 『Observability Engineering』第2版第8章は、AIOps(Gartner が2017年に作った用語で、機械学習によるアラートノイズ低減と異常検知の改善を指す)を初版執筆時点で「誤解を招く約束」と批判していたと振り返り、当時は明確なパターンの存在と常に変化するベースラインをモデル化できる場合にのみ AI が有効になりうる、という条件付きの懐疑を示していたとする。この実務者の懐疑は、本ページが集める研究サーベイの構造的偏り(検知・予測に研究が集中し緩和は薄い。[[A Survey of AIOps Methods for Failure Management]]・[[@2024__arXiv__AIOps Solutions for Incident Management]])や、SRE 実務評価で RCA 精度が14%程度にとどまる([[@2025__SRE NEXT 2025__Rethinking Incident Response - Context-Aware AI in Practice]])という数値的裏付けと符合する。生成AIの登場で著者らはこの評価を留保付きで更新しつつあり、「計算機が大量データ走査(得意分野)と人間的文脈付け(従来は人間の役割)の両方を担いうる可能性」を新たな検討課題として提示する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 8 Getting Started with Observability Analysis]], [[A Survey of AIOps Methods for Failure Management]], [[@2025__SRE NEXT 2025__Rethinking Incident Response - Context-Aware AI in Practice]]) - **「AIOps」という用語が確立する直前(2018年)、SRE実務者は同じ問題意識を「機械学習でトイル・異常検出・予見を解決する」という枠組みで語っていた**: Gartner が「AIOps」を作ったのは2017年だが([[@2026__OReilly__Observability Engineering 2E - Chapter 8 Getting Started with Observability Analysis]]横断的知見参照)、Ricardo Amaro([[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]]、2017年DrupalCon Viennaでの発表に基づく)は同時期に、Acquiaでの実務経験(数千インスタンス・数十ペタバイトのログ/メトリクス)から出発し、「トイルを生む反復タスクの自動化」「システムで将来起ころうとしていることの予見」「ソフトウェアエンジニアリングの運用機能への適用強化」という3つの疑問を機械学習の解決対象として提示した(§18.1)。同章が挙げる運用課題(ノイズ低減・異常検出・状況単位のワークフロー自動化・チケット分類・短期/長期予測、§18.2.1)は、AIOpsLabの4-level taxonomy(検知→箇所特定→RCA→緩和)や本ページが集積する研究サーベイの分類軸とほぼ同型でありながら、「AIOps」という用語もGartnerの定義も参照していない。これは、AIOpsという概念が特定のベンダー用語として上から定義される前から、SRE実務の現場で独立に類似の問題整理が行われていたことを示す一次資料であり、AIOpsという語の誕生(2017年Gartner)とほぼ同時に、無関係な文脈(DrupalCon)で同種の実務的整理が生まれていたことを裏づける。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]] §18.1, §18.2.1, [[@2026__OReilly__Observability Engineering 2E - Chapter 8 Getting Started with Observability Analysis]]) - **障害管理は 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 の下位に畳むなど粒度が違う。([[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([[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: [[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 軸の起源として読める**: [[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: [[A Survey of Online Failure Prediction Methods]] §1.2 §2 §3 §4, [[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: [[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 手薄)を別データで再確認した**: [[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, [[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) - **2020 年時点の国際会議観測でも「研究の理論的洗練 vs 実務のルールベース運用継続」というギャップが既に指摘されていた**: IEEE World Congress on SERVICES 2020(IEEE CLOUD 併催)の参加報告は、マイクロサービス・サーバーレス・エッジ-クラウド連携を対象とした異常検知・根本原因分析研究(教師なしワークロード異常検知・キューイングモデルベースの性能異常検知・ログ相関による根本原因メトリクス特定)が多数発表される一方、実運用現場ではルールベースの運用が継続している点を指摘した。この観察は、[[Interactive AIOps]] が同じ著者により 2022 年に提唱される 2 年前の実務観察であり、AIOps の「研究成果と実装可能性のギャップ」という本ページの未解決の問いが、LLM-era 以前から一貫して存在していたことを示す。(Source: [[@2020__yuuk.io__IEEE CLOUD 2020 参加録]]) - **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]]) - **産業実装での LLM エージェント評価は、単一の精度指標ではなく精度×レイテンシ×トークン消費量の 3 軸で解釈しないとモデル選定を誤る**: [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] は Red Hat OpenShift 上の [[ReAct]] エージェントで 10 種類の商用 LLM を同一環境・同一ツール実装で比較し、単発ツール呼び出し(Simple Reasoning)では Claude 3.5 Sonnet(100%)・Mistral Large(99.38%)が高精度だが、複数ステップのツール連鎖(Advanced Reasoning)では GPT-4o(100%)・GPT-4 Turbo(90%)が最良になるという逆転が生じた。さらに Mixtral 8x22B・GPT-3.5 Turbo は AR タスクで最速(P50 6.88s/6.99s)だが AR 精度は 0% であり、低レイテンシ・低トークン消費が「早期終了・不完全なツール連鎖」の反映にすぎない例が実証された。本 wiki の AIOps ベンチマーク系(AIOpsLab/SREGym)が報告してきた「ツール呼び出し過多」という失敗モードに加え、産業実装は「多段ツール連鎖の信頼性が単発ツール能力と独立している」ことをモデルファミリー横断で定量化した点で、能力軸の粒度をさらに細分化する示唆を与える。(Source: [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] §4.1–4.3) - **予測的容量計画モデルと LLM エージェントの統合は reactive な手動トリガーどまりで、AIOps エージェントへの自動組み込みは未解決のまま**: [[MLASP]] は [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] で ReAct エージェントのツールとして統合され、Simple Reasoning タスク(スループット KPI を満たす設定探索)で機能したが、Advanced Reasoning のような多段ツール連鎖への自動呼び出しは実証されていない。これは AIOps の「識別的モデル・ルール・LLM・実行エージェントの分業」という本ページの未解決の問いに、具体的な産業事例として容量計画ドメインの回答候補を追加する。 - **Transformer 特化サーベイは、能力軸を「タスクの種類」でなく「モデルアーキテクチャが何を保証するか」で再定義する第4の軸を提示する**: 本ページの能力軸(AIOpsLabの4-level)・自律度軸(SRE AI Autonomy Levels)・工程軸(データ→評価)はいずれも「AIOpsが何を達成するか」を問うタスク志向の軸だった。[[@2026__TOSEM__Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations - Chapter 4 Taxonomy]] の二層6能力フレームワーク(SEQ/PARALLEL/PTKL/ICL/TF/LANG)は、これと直交する「なぜそのタスクが解けるのか」というモデル内在的な能力軸を提示する。同サーベイの Fig. 8(パターンモデラー→文脈対応タスクソルバー→自律エージェント)は AIOpsLab の4-level taxonomy(検知→箇所特定→RCA→緩和)と類似の3段進化を示すが、判断基準が「タスクの種類」でなく「モデルの自律度」である点で SRE AI Autonomy Levels の自律度軸に近い。両者を並べると、本 wiki が蓄積してきた「能力軸」は暗黙にタスク志向(what)とモデル志向(why)を混在させてきた可能性があり、Data-Target-Principle-Approach タクソノミー(何をどう解くか)と能力フレームワーク(なぜ解けるか)を明示的に分離する枠組みは、今後の AIOps 地図の整理に転用できる。(Source: [[@2026__TOSEM__Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations - Chapter 4 Taxonomy]] §4.2, [[@2026__TOSEM__Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations - Chapter 8 Open Challenges and Future Directions]] §8; [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **トレース分析の Transformer 化が構造的に手薄という指摘は、本 wiki のマルチモーダル化(UModel/TVDiag)の議論と補完関係にある**: [[@2026__TOSEM__Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations - Chapter 8 Open Challenges and Future Directions]] §8.4 は、ログ・メトリクス・イベントが自然に系列データとしてTransformerに適合するのに対し、トレースは本質的にグラフ構造(有向非巡回グラフ)であるため Transformer ベースのトレース分析研究がほとんど存在しないと指摘する。本ページが引く Notaro+ 2021 のマルチモーダル化未解決課題や UModel/TVDiag の取り組みは「複数モダリティをどう統合するか」を問うが、この survey はさらに踏み込んで「モダリティごとのデータ構造とアーキテクチャの適合性」という設計制約を明示化しており、グラフ構造データに対しては Transformer 以外の構造(GNN 等)が引き続き必要になる可能性を示唆する。(Source: [[@2026__TOSEM__Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations - Chapter 8 Open Challenges and Future Directions]] §8.4) - **CSE は AIOps を名指しで「相関ベースであり因果推論を欠く」と批判し、AIOpsLab の 4-level taxonomy(検知→局所化→RCA→緩和)を「事後的なランキング」の枠組みとして相対化する**: [[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]] は、異常検知・予測分析・AIOps・LLM ベースエージェントを一括して「もっともらしい説明や連想的なシグナルを提供するが、意思決定に足る答えではない」と位置づけ、本ページが集積してきた AIOpsLab の検知 86%・局所化 71%・RCA 14%・緩和 43%(§横断的知見)という段階別精度低下を、単なる「タスク難度の違い」ではなく「観測(L1)から介入知識(L2)への飛躍を要求されているのに相関ベース手法しか使っていない」という構造的な限界として再解釈する視座を提供する。本ページが未解決の問いとして挙げてきた「識別的モデル・ルール・LLM・実行エージェントの分業」問題に対し、CSE は causal design spec / intervention log という具体的な設計対象を追加する。(Source: [[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]]) - **Eagle の Ops タクソノミー(6 コア能力 × 3 Ops フェーズ × 6 モダリティ)は、本ページの能力軸・工程軸を「評価ベンチマークの設計」という第三の切り口で再構成する**: Eagle([[@2026__FSE Companion__Eagle - Leveraging Operations Documents for Comprehensive Benchmark Question Generation]])の Understanding/Memory/Generation/Agent/Logic/Extraction という 6 コア能力は、AIOpsLab の 4-level taxonomy(検知→局所化→RCA→緩和、能力軸)や Remil+ 2024 の 6 能力モデル(Perception/Prevention/Detection/Location/Action/Interaction、§横断的知見)と同様に「AIOps に何ができるべきか」を分解する試みだが、対象が「システムの振る舞い」ではなく「LLM 自体が持つべき能力」である点が異なる。さらに Eagle は Pre-Event/In-Event/Post-Event という 3 フェーズを AIOpsLab の 4 段(検知・局所化・RCA・緩和)と直交する時間軸として重ね、10 モデル横断の評価では Memory・Logic が飽和する一方 Generation が最弱・Pre-Event が最も分散が大きいことを実証した(Table 6)。これは本ページが集積してきた「検知・局所化は現実的だが RCA・緩和は研究段階」(SRE NEXT 2025 引用の AIOpsLab 数値)という段階別精度低下の知見と符合し、AIOps の能力段階の困難さが「システムタスクの難度」だけでなく「LLM の生成能力・事前対応推論という基礎能力の弱さ」にも起因することを示唆する。(Source: [[@2026__FSE Companion__Eagle - Leveraging Operations Documents for Comprehensive Benchmark Question Generation]] §3.1, §5.2.3) - **AIOps ベンチマークの構築自体が産業デプロイの対象になり得ることを Eagle が実証した**: 本ページが集積する産業事例(IcM BRAIN・Bian Que・PerfScout 等)はいずれも「診断・対処エージェント」の本番デプロイだったが、Eagle は「OpsLLM を評価するベンチマーク生成パイプライン」自体を Huawei 社内に6ヶ月間デプロイし、4,845件の QA ペアからモデル選定・ロールアウト判断を行う社内横断ベンチマークレポートを作成した。これは AIOps の実務化が「診断・対処の自動化」に加え「評価インフラの自動化」という第二の産業応用面を持つことを示す新しい事例である。(Source: [[@2026__FSE Companion__Eagle - Leveraging Operations Documents for Comprehensive Benchmark Question Generation]]) - **博士論文の結論章は、評価基盤の拡張軸として「現実的ワークロード・広範な障害種別」に加え「セキュリティと信頼性(敵対的操作への耐性、DDoS 等のセキュリティインシデントの緩和)」を新たに提示する**: 本ページの評価地図(能力軸・自律度軸・工程軸)はいずれも運用上の有効性(タスク成功率)を測る設計だったが、[[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]] §6.2 は AIOpsLab の拡張として、これをエージェントが敵対的操作に耐えられるかというセキュリティ評価軸へ広げるべきと明示する。これは本ページが集積してきた AIOpsLab の検知・局所化・RCA・緩和という4段taxonomy(能力軸)のいずれにも属さない、評価対象システムそのものの頑健性という軸を示唆する。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]] §6.2, [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **AIOpsLab 原典(博士論文第5章)は、能力軸(4-level taxonomy)の各段階が要求する障害の性質を「症状型/機能型」という障害注入側の設計と対応付けて明示する**: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] §5.6 は、AIOpsLab の障害ライブラリを symptomatic(性能劣化・クラッシュ等、観測可能な症状のみで根本原因を持たない)と functional(設定ミス・コードバグ等、細粒度の根本原因を持つ)の2系統に分け、前者は検知・箇所特定(Level 1・2)までしか問題を構成できず、後者のみが検知から緩和までの全4レベルを構成できると明記する。これは本ページの能力軸(検知→箇所特定→RCA→緩和)が「タスクの難度」だけでなく「注入する障害がそもそもその難度の問いに答えられる構造を持つか」という障害注入側の制約に規定されていることを示し、能力軸の評価がベンチマーク設計(何を注入するか)と不可分であるという設計原理を明確化する。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] §5.6) - **Notaro et al. 2021 の「5 カテゴリ・14 サブカテゴリ」の具体名は次の通りで、AIOpsLab の 4-level taxonomy より 1 段深い「対象問題(target problem)」軸を持つ**: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 2 Related Work and Methodology]] §3.1 の Table 4 によれば、故障予防(Failure Prevention)= Software Defect Prediction(SDP)/ Fault Injection / Software Aging and Rejuvenation / Checkpointing、オンライン障害予測(Online Failure Prediction)= Hardware Failure Prediction / System Failure Prediction、故障検知(Failure Detection)= Anomaly Detection / Internet Traffic Classification / Log Enhancement、根本原因分析(Root-cause Analysis)= Fault Localization / Root-cause Diagnosis(+ 残差カテゴリ RCA - Others)、修復(Remediation)= Incident Triage / Solution Recommendation / Recovery、の計 14 の named サブカテゴリ(+ RCA - Others を含めると 15 タスク行)である。AIOpsLab の 4-level taxonomy(検知→箇所特定→RCA→緩和)と対応付けると、Fault Localization は AIOpsLab の Localization に、Root-cause Diagnosis は AIOpsLab の RCA にほぼ相当するが、AIOpsLab には Online Failure Prediction・Software Aging and Rejuvenation・Checkpointing のような先回り型サブカテゴリに対応する評価段階が存在しない。これは、LLM-era ベンチマークが pre-LLM 期タクソノミーの reactive 側のみを評価対象にしているという既存知見(本ページ上記)を、サブカテゴリ粒度でも裏づける。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 2 Related Work and Methodology]] §3.1, [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **Notaro+ 2021 は AIOps 全体を「障害管理(failure management)」と「資源配分(resource provisioning)」という 2 つの macro-area に分けており、LLM-era のエージェントベンチマークは前者にほぼ限定される**: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 1 Introduction]] は、最頻出 AIOps 問題(異常検知・RCA・資源配分・障害修復・障害予測/予防)を観察したうえで AIOps を障害管理と資源配分の 2 macro-area に分割し、本サーベイの対象を障害管理のみに絞ると明言する(資源配分は電力・計算時間・ネットワーク帯域・仮想メモリなど IT サービス提供資源の配分最適化として区別される)。本ページが能力軸の基準としてきた AIOpsLab の 4-level taxonomy(検知→箇所特定→RCA→緩和)は障害管理側の段階分解にすぎず、資源配分という macro-area をそもそも評価対象に含まない。これは、LLM-era の AIOps エージェント評価基盤(AIOpsLab・SREGym)が対象とする範囲が、pre-LLM 期サーベイが定義した AIOps 全体像のうち障害管理側の半分に体系的に限定されていることを示す。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 1 Introduction]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **CSUR サーベイ自身の Table 1(既存サーベイ比較)は、Notaro et al. 2021 を「reactive 側の 3 ラベルに圧縮して引用」しており、本ページが既出の「pre-LLM 期サーベイの reactive 側のみが LLM-era に継承される」という仮説を一次資料から裏づける**: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 1 Introduction]] の Table 1 は、Notaro et al. 2021(引用番号 [97]。本ページが集積してきた [[A Survey of AIOps Methods for Failure Management]] と同一文献。ただし CSUR 本文・Table 1 では著者名が「Paolop et al.」と誤記されている)の対象範囲を「Failure Perception; Root Cause Analysis; Remediation」という 3 タスクスコープの非 LLM サーベイと位置づけ、自らを「Data Preprocessing; Failure Perception; Root Cause Analysis; Auto Remediation」という LLM 対応の 4 タスクスコープとして対比する。Notaro+2021 の 5 カテゴリ・14 サブカテゴリ(本ページ既出: 故障予防・オンライン故障予測・故障検知・根本原因分析・修復)のうち、故障予防(Failure Prevention)とオンライン障害予測(Online Failure Prediction)という先回り型の 2 カテゴリは、この Table 1 の比較軸自体から欠落している。これは、LLM-era サーベイが pre-LLM サーベイを引用する際に reactive 側(検知・RCA・緩和)のみを継承し proactive 側(prevention・prediction)を暗黙に捨象するという本ページ既出の観察を、サーベイ自身の自己位置づけの記述から裏づける追加証拠である。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 1 Introduction]] Table 1, [[A Survey of AIOps Methods for Failure Management]] §4) - **本サーベイ(CSUR)は RQ1〜RQ4 の 4 軸を「提示構成」だけでなく「文献採録基準」としても運用しており、Notaro+2021 の事後分類的なタクソノミーとは方法論的性格が異なる**: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 2 Systematic Review Process]] §2.2 の採録基準(IC1〜IC4)は RQ1(新データ源)・RQ2/RQ3(新規手法・タスク変化、ただし本文中の対応表記は第1章の RQ2/RQ3 定義と逆転している)・RQ4(新評価指標・データセット)のいずれかへの新規性を採録の必要条件とする。Notaro+2021 が既存手法を事後的に 5 カテゴリへ分類する記述的タクソノミーだったのに対し、CSUR は「データ→タスク→手法→評価」の 4 軸をあらかじめ文献検索・選定のフィルタとして機能させており、taxonomy を成果物としてではなくプロセスの入力として使う点が異なる。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 2 Systematic Review Process]] §2.2) - **CSUR サーベイの出版動向データ(Fig. 1)は、LLM-based AIOps 論文数が ChatGPT 登場期(2022 年末〜2023 年)を境に加速したことを定量化し、本ページが既出の「生成 AI 登場が AIOps の研究地形を変えた」という観察に四半期粒度の裏づけを与える**: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 1 Introduction]] Fig. 1(a) は LLM ベース AIOps 論文数が 2020-Q4 の約 1 本から 2024-Q3 の約 50 本へ増加したことを示す(トレンド線は指数的)。Fig. 1(b) は LLM 全体の出版物数と LLM ベース障害管理(Failure Management)論文数がほぼ同期して急増していることを示し、T5・GPT-3・InstructGPT・ChatGPT・Gemini・GPT-4o 系のリリース時期と重ねて可視化する。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 1 Introduction]] Fig. 1) - **Notaro+2021 がマルチモーダル化不足として指摘した課題は、5 年後の CSUR サーベイの結論章でも「トレースデータの完全な未活用」という具体名で再確認されている**: [[A Survey of AIOps Methods for Failure Management]] Table 8 は 100 件の手法のほぼ全てが単一データソースに依存すると指摘したが(本ページ既出)、[[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]] §7.2 は LLM 時代に絞ってもメトリクス・ログの活用には進展がある一方、3 大システム生成データの一つであるトレースデータを効果的に取り込んだ LLM ベース研究は皆無だと明言する(理由: 入れ子状の詳細なイベント系列という複雑さと量の多さが LLM への表現を妨げる)。マルチモーダル化という pre-LLM 期からの未解決課題(本ページ既出、UModel/TVDiag が回答候補)は、LLM 時代になっても「どのモダリティが最も遅れているか」という粒度では変わっておらず、トレースが構造的に最後まで手つかずのまま残っていることを示す。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]] §7.2, [[A Survey of AIOps Methods for Failure Management]] §5.1) - **同じ ACM Computing Surveys 誌に載った2つの独立サーベイの「Future Directions」章を並べると、AIOps 研究の将来方向の語彙は efficiency/generalization/data-source 軸に偏り、trustworthiness 軸(公平性・プライバシー・人間の介入)を組織原理として使うのは別系統の文献に限られる**: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]] は将来課題を時間効率・費用対効果(§7.1)、多様な障害データソースの活用(§7.2)、ソフトウェア進化への汎化性・適応性(§7.3)、既存ツールチェーンとの統合(§7.4)という4軸で整理する。一方 [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 4 Future Research Directions and Opportunities]] は将来方向を「データプライバシー・公平性・頑健性・説明可能性・効率性・人間の介入」という6つの信頼性要件と「データ収集・データ前処理・異常検知・根本原因特定」という4構成要素の交点として組み立て、精度偏重から頑健性・効率性へのバランス転換(異常検知)、説明可能性偏重から公平性・頑健性へのバランス転換(根本原因特定)、6要件の外側にある倫理的要件(環境面のウェルビーイング、アカウンタビリティ)まで将来課題に含める。両サーベイは「実用的なリアルタイム性」を共に将来課題に挙げる点(CSUR §7.1 の時間効率 対 Xin+2025 の「正確なリアルタイムオンライン検知」)で収束するが、公平性・プライバシー・人間の介入を組織原理とする軸は Xin+2025 側にしか現れない。これは、本ページが蓄積してきた AIOps 研究の能力軸・自律度軸・工程軸・モデル内在的能力軸(SEQ/PARALLEL/…)のいずれにも、信頼性要件を横断的に組み込む軸が欠けていたことを示唆する。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]], [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 4 Future Research Directions and Opportunities]]) - [実行志向のオペレーション] KnowLutionは、実運用スーパーコンピュータのO&Mを会話的質問応答ではなくワークフロー実行として扱い、ワークフロールーティング・状態認識型検索・実行認識型ツールオーケストレーションを統合することで、200件の実運用由来タスクでTSR 85%・TESR 92%を達成し、ReAct・EasyTool・MetaGPT等の代表的ベースラインを大幅に上回った(Source: [[@2026__ISSRE__KnowLution - A Multi-Agent Framework for Execution-Oriented Autonomous Operations in Production Supercomputers]]) - [実行安全性] アブレーションでは、実行前の能力・安全性検証を担うツールオーケストレーションの除去がTSRへの影響が最大(85%→54%)であり、既存のRAG拡張推論や汎用エージェントフレームワークが欠く「実行前検証」がタスク完了に最も強く効くという定量的な裏付けを与える(Source: [[@2026__ISSRE__KnowLution - A Multi-Agent Framework for Execution-Oriented Autonomous Operations in Production Supercomputers]]) - [実運用フィードバック] Tianhe-NGスーパーコンピュータでの実運用デプロイでは書き込み操作に人間確認を要求し、81.5%の運用者が推奨をより信頼できると回答した。書き込み操作へのhuman-in-the-loopゲートは自律運用システムの実運用受容の鍵となりうる(Source: [[@2026__ISSRE__KnowLution - A Multi-Agent Framework for Execution-Oriented Autonomous Operations in Production Supercomputers]]) - [障害注入によるラベル生成] SLoFI は本番 HPC(Tianhe)で低権限の障害注入を行い、注入イベント・ノードテレメトリ・ワークロードイテレーションを絶対時刻で整列させることで、弱ラベルまたは無ラベルになりがちな本番テレメトリに対し、異常検知・根本原因の箇所特定モジュールを評価するための正解ラベル(ground truth)を生成する。クローズドループでは異常検知が平均検知遅延 32.43 秒で症状を報告し、根本原因の箇所特定が注入ノードを 86.67% のケースで Top-2 候補内にランクした(Source: [[@2026__ISSRE__SLoFI : Low-Privilege Fault Injection for Reliability Testing in Production Supercomputers]])。 - [[XiHe]]は3,000件超・12ヶ月の本番運用データに基づき、根本原因分析における解釈可能性(interpretability)を精度と独立した評価軸として定量化した事例である。オペレータへの一貫評価(Consensual Assessment Technique)から自動計算可能な3指標(SC=因果集中度、TC=トポロジ的網羅性、KC=知識準拠率)を導出し、いずれもオペレータ選好と相関することを確認している。(Source: [[@2026__SIGCOMM__Networked Agent Memory and Causality Representation - Experiences towards Interpretable Cloud-Scale Root-Causing]]) ## 未解決の問い - **CSUR サーベイの分析対象論文数は abstract(183 本)と §2.3 本文(163 本の新規研究)で一致しない**: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 2 Systematic Review Process]] は 5 データベースから 761 本を識別し、重複除去・スクリーニング・全文レビューを経て最終的に 163 本の新規研究が採録基準を満たしたと明記するが、同サーベイの abstract は分析対象を 183 本と記す。両者を橋渡しする記述は原本に見当たらず、本 wiki は数値の不整合として保留する。LLM-era AIOps の研究母集団規模を Notaro+2021(1,086 件中 100 件)・Remil+2024 と比較する際は、この不整合を踏まえて CSUR の 163/183 のどちらを採用するか明示する必要がある。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 2 Systematic Review Process]] §2.3) - **AIOps の 4-level taxonomy(検知→局所化→RCA→緩和)の各段階に、CSE の 3 アーティファクト(causal design spec・intervention log・living causal model)をどう対応付けるべきか**: CSE は自身のロードマップ(Route 1〜4)を SE ライフサイクル全体(要件〜運用)に対応付けているが、AIOps の運用時タスク段階(検知・局所化・RCA・緩和)との対応関係は明示していない。例えば intervention log は「緩和」段階の是正措置記録と重なるように見えるが、CSE 論文はこの対応を具体化していない。(Source: [[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]]) - Transformer の二層能力フレームワーク(SEQ/PARALLEL/PTKL/ICL/TF/LANG)を本ページの能力軸・自律度軸・工程軸とどう統合すべきか。4軸を独立に保つべきか、能力フレームワークをタスク志向の能力軸の下位分解として組み込むべきか。(Source: [[@2026__TOSEM__Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations - Chapter 4 Taxonomy]] §4.2) - 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: [[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時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]]) - Advanced Reasoning タスクでの多段ツール連鎖の信頼性は、単発ツール精度・モデル規模・ファインチューニングのいずれで最も効率的に改善できるか。産業実装([[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]])はプロンプティングのみで評価しており、[[ReAct]] のファインチューニングによる逆転(小規模モデルでも軌跡学習で最善手になる)が AIOps 実運用でも成立するかは未検証。 - LLM エージェントの明示的メモリコンポーネントは、時間的再計算を要するタスクで正答率を悪化させることが実証された([[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] §5.1)。AIOps エージェントにおいて、継続性が必要な対話とステートレス性が必要な計算タスクをどう選択的に切り分けるメモリ設計が可能か。([[エージェントメモリ]] 参照) - Eagle の Ops タクソノミー(6 コア能力 × 3 フェーズ × 6 モダリティ)は、本ページの能力軸(AIOpsLab 4-level)・Remil+ 2024 の 6 能力モデルとどう統合すべきか。3 つの独立したタクソノミーが同じ「AIOps に何ができるべきか」を異なる粒度で分解しているが、統一マッピングは確立されていない。([[@2026__FSE Companion__Eagle - Leveraging Operations Documents for Comprehensive Benchmark Question Generation]] §3.1) - Eagle は単一企業(Huawei)環境での実証にとどまり、著者自身が組織横断的な妥当性検証を今後の課題としている。Ops ドキュメント駆動のベンチマーク生成パイプラインは、ドキュメント構造・粒度が大きく異なる他組織(OSS プロジェクトの Wiki、他ベンダーの製品マニュアル等)でも同等の品質を維持できるか。([[@2026__FSE Companion__Eagle - Leveraging Operations Documents for Comprehensive Benchmark Question Generation]] §6) - クラウドを超えた自律運用(IoT・金融プラットフォーム・ロボティクス)は、AIOps の能力軸(検知→局所化→RCA→緩和)をそのまま転用できるか、それとも物理的・経済的帰結、ノイズの多いセンシング、即時性と安全性の両立要求のために taxonomy 自体を再設計する必要があるか。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]] §6.2) - Notaro et al. 2021 は結論部で「経験的な比較・評価のための問題の形式的標準化とベンチマークデータセット整備」を分野の課題として明示している。AIOpsLab・SREGym・OpenRCA のような LLM-era ベンチマークはこの不在をどこまで埋めたか、それとも標準化されたベンチマーク問題設定という土台自体は依然として個々のベンチマークが独自に定義したままか。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 5 Conclusion]] §5.1) - Notaro et al. 2021 は recovery(復旧)タスクを「故障対応の基本的かつ具体的なステップだが貢献が非常に少ない」と個別に指摘し、故障予防では既存4サブカテゴリに閉じないモデルベース予防(カナリアリリースやサーバーシャットダウンのリスクを事前推定する等)を未探索の方向として挙げる。LLM-era のエージェントはこのモデルベース予防・recovery 単体の自動化にどこまで踏み込んでいるか。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 5 Conclusion]] §5.1) - CSUR サーベイは、継続稼働・高いリアルタイム性が要求される[[異常検知]](例: 10 秒窓に対し 1 秒以内の推論)に十分対応した LLM ベース研究は現時点で存在しないと明言する。小規模モデル・LLM・OCE を有機的に組み合わせる統合アプローチは具体的にどう設計すべきか。検知には小規模モデルを残しつつ RCA・緩和にのみ LLM を割り当てる分業は、本ページの能力軸(検知→局所化→RCA→緩和)にそのまま重ねられるか。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]] §7.1) - トレースデータは複雑さと量の多さゆえに LLM ベース AIOps 手法に一切取り込まれていない。入れ子状のイベント系列を LLM が理解・活用できる形で表現する方法(グラフ構造のまま扱うか、系列に変換するか)は未確立のまま残っている。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]] §7.2) - ログベースの LLM 障害検知研究は、(a) T5・GPT-2 のような小規模事前学習モデルに依存して訓練コストが高いか、(b) GPT-3.5 のような大規模モデルを使っても従来の機械学習で十分解ける単純なデータセットに基づくかのどちらかに偏っており、LLM の優位性を示す実証がまだ乏しい。メトリクス系で有効なプロンプト埋め込みはログにどこまで転用できるか。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]] §7.2) - LLM ベース根本原因分析の多くはインシデントレポートを主データソースとしており、障害検知からトリガーされるべき AIOps の自動化フローを分断している。システム生成データ(メトリクス・ログ・トレース)から障害検知 → インシデントレポート生成 → 根本原因分析という一気通貫のパイプラインを構築した LLM ベース研究はまだ存在しないのか。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]] §7.2) - LLM ベース AIOps は事前学習の多様性ゆえに高い汎化性・適応性を持つと期待されているが、特にプロンプトベース手法についてはソフトウェア進化シナリオでの体系的な実証評価がまだ乏しい。従来 ML/DL 手法の汎化性劣化(本ページ既出の pre-LLM 期の課題)と比べ、LLM ベース手法は実際にどの程度改善するのかを定量化した研究が求められる。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]] §7.3) - Xin+2025 が示す「システムレベル」の信頼性要件(データプライバシー・人間の介入、図10)は、本ページの能力軸(検知→局所化→RCA→緩和)のどの段階にも一意に属さない。LLM エージェント化した AIOps では、この2要件をエージェントの評価軸(能力軸・自律度軸)にどう組み込むべきか。特にデータプライバシー(FL・差分プライバシー・ブロックチェーン型ストレージ)は、社内配置モデルでプライバシー制約に対応した [[RCAgent]] の設計判断と接続できるか、それとも別の評価軸として独立させるべきか。(Source: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 4 Future Research Directions and Opportunities]]) - Xin+2025 が将来課題として挙げる「倫理的信頼性要件」(環境面のウェルビーイングのためのエネルギー研究、アカウンタビリティのための法学研究)は、LLM ベース AIOps エージェントの推論コスト(トークン消費量・レイテンシ、[[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] が実証した3軸評価)とどう接続すべきか。エネルギー効率を AIOps エージェントの評価軸に加える先行研究は本ページにまだ蓄積されていない。(Source: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 4 Future Research Directions and Opportunities]]) - HPCスーパーコンピュータ運用向けのマルチエージェントAIOpsフレームワーク(KnowLution)は、クラウド/マイクロサービス向けのAIOps手法(OpsAgent・ChainCraft等)とどこまで技術基盤を共有し、どこがHPC固有(ジョブスケジューラ・MPI・ノード資源管理)の設計を要するか ## 関連 - 子 concept: [[異常検知]] / [[Fault Localization]] / [[根本原因分析]] / [[障害緩和]] / [[障害予測]] / [[エージェントシステム運用]] / [[Flexible Skill Arrangement]] / [[オブザーバビリティデータモデル]] - 隣接 concept: [[agentic SRE]] / [[SRE Benchmark]] / [[SRE AI Autonomy Levels]] / [[エージェント運用安全性]] / [[データベース O&M]] / [[NetOps]] / [[Causal Software Engineering]] / [[LLM評価]] - 実装システム: [[Bian Que]] / [[Kuaishou Technology]] / [[UModel]] / [[Alibaba Cloud]] / [[Eagle (OpsLLMベンチマーク)]] - ソース: [[Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations]] / [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] / [[A Survey of AIOps in the Era of Large Language Models]] / [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 1 Introduction]] / [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 2 Systematic Review Process]] / [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]] / [[@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__OReilly__Observability Engineering 2E - Chapter 8 Getting Started with Observability Analysis]] / [[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]] / [[@2026__FSE Companion__Eagle - Leveraging Operations Documents for Comprehensive Benchmark Question Generation]] / [[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]] / [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] / [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 4 Future Research Directions and Opportunities]] / [[@2026__ISSRE__KnowLution - A Multi-Agent Framework for Execution-Oriented Autonomous Operations in Production Supercomputers]] / [[@2026__ISSRE__SLoFI : Low-Privilege Fault Injection for Reliability Testing in Production Supercomputers]] / [[@2026__SIGCOMM__Networked Agent Memory and Causality Representation - Experiences towards Interpretable Cloud-Scale Root-Causing]] - エンティティ: [[Gartner]] / [[Yuqi Li]] / [[National SuperComputer Center in Tianjin]] / [[Tianhe-NG]] ## 出典 - [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] - [[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 デプロイ) - [[A Survey of AIOps Methods for Failure Management]](§3 taxonomy・データソース・指標、§4 5 カテゴリ・14 サブカテゴリの代表手法・定量結果、§5 マルチモーダル/ベンチマーク/recovery 不足の課題) - [[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) - [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]](§3 ReAct エージェント設計・§4 精度/レイテンシ/トークン消費量の比較・§5 メモリと失敗モード分析) - [[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]](§1-2 AIOps を含む相関ベース手法群への批判、Route 1「因果的可観測性」) - [[@2026__OReilly__Observability Engineering 2E - Chapter 8 Getting Started with Observability Analysis]](Automating Analysis with Generative AI: AIOps の初版時点での批判と生成AI時代の再評価) - [[@2026__FSE Companion__Eagle - Leveraging Operations Documents for Comprehensive Benchmark Question Generation]](§3 Ops タクソノミー・§5.2.3 10モデル横断のper-metric評価・§5.4 ケース分析) - [[@2021__OReillyJapan__SREの探求 - Chapter 18 SREのための機械学習入門]] §18.1, §18.2.1(2017年DrupalCon Vienna発表に基づく、Gartner「AIOps」命名と同時期のSRE実務者による独立整理) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]](§6.2 Future Work: AIOpsLab拡張・セキュリティ/信頼性評価軸・クラウドを超えた自律運用) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]](§5.6 症状型/機能型障害と能力軸タスクレベルの対応関係) - [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 1 Introduction]](Table 1 既存サーベイ比較・Fig. 1 出版動向・Fig. 2 RQ タクソノミー) - [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 2 Systematic Review Process]](§2.1 検索戦略・§2.2 採録/除外基準・§2.3 選定漏斗) - [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 7 Challenges and Future Directions]](§7.1 時間効率・費用対効果、§7.2 多様な障害データソースの活用、§7.3 ソフトウェア進化への汎化性・適応性、§7.4 既存ツールチェーンとの統合) - [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 4 Future Research Directions and Opportunities]](表3・図10の信頼性要件×構成要素タクソノミー、§4 の5つの将来方向)