# 根本原因分析 ## 定義 根本原因分析(Root Cause Analysis, RCA)は、障害の症状から、影響するシステム層・障害種別・因果連鎖を絞り込み、人間またはエージェントが次の緩和判断に使える説明を得る取り組みである。[[AIOps]] の 4 段分類では検知・箇所特定の後、[[障害緩和]] の前に位置する。([[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) 入力選別は前処理ではなく分析の中核であり、単一根本原因への帰結は寄与因子のネットワークを圧縮する社会的操作でもある。評価設計は手法選択以上に進捗を左右し、箇所特定と「なぜか」の説明は別能力である。争点は、根本原因という語を捨てるか対概念で再定義するか、緩和の成否をラベルの正しさで測るか十分性で測るか、にある。研究の重心は形式的因果モデルから経験的ハンドラと LLM 圧縮へ、成果物は箇所特定から説明と伝播経路へ、対象はサービス依存から実行軌跡上の決定点へ移っている。詳細は [[RCA入力選別]]、[[RCA評価設計]]、[[仮説駆動RCA]]、[[ドメイン別RCA]] に置く。 ## 子概念 - [[CAST]] - [[Causal Software Engineering]] - [[Change Object Rewrite]] - [[RCA入力選別]] - [[RCA評価設計]] - [[agentic SRE]] - [[インシデント調査戦略]] - [[クラウド障害ライフサイクル]] - [[ドメイン別RCA]] - [[ヒンドサイトバイアス]] - [[プライバシーエンジニアリング]] - [[仮説駆動RCA]] - [[故障の木解析]] - [[複雑システム障害論]] - [[コードブックによるイベント相関]] ## 単一根本原因という概念 - **単一根本原因への帰結は、複数の系統的寄与因子をオペレーター過誤へ圧縮する社会的操作である。** - 根拠: [[@2023__SREcon23Americas__Epic Incidents of History - The 1979 NORAD Nuclear Near Miss]] — 1979 年 NORAD 誤警報で国防総省はオペレーター過誤に帰結させたが、遠因は数十年の技術・組織圧力の蓄積だった - 根拠: [[@1998__CtL__How Complex Systems Fail]] 命題 7 — 根本原因帰属は技術的理解ではなく、特定の原因に責任を帰属させる社会的・文化的必要性を反映する - 根拠: [[@2004__AAS__Tales from the Lunar Module Guidance Computer]] — Apollo 11 の 1201/1202 アラームと LM-1 のエンジン誤停止は「コンピュータエラー」に片付けられたが、実因は ICD の記載漏れだった - 根拠: [[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]] — 仮説競合の裁定は、複数寄与因子の同定へ移る具体化の一つである - 関連: [[複雑システム障害論]] — 命題 7 の社会的構築性 - 関連: [[インターフェース仕様の齟齬による障害]] — Apollo 事例の層 - **SRE 実務と安全工学は語の廃棄と対概念による再定義に分かれつつ、単一原因思考からの脱却では一致する。** - 根拠: [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]] — [[Will Gallego]]（[[Etsy]]）は「根本原因」「主要原因」を使わず、単一原因の宣言は浅い答えで満足する宣言だと述べた - 根拠: [[@2023__SREcon23Americas__Far from the Shallows]] p.024 — [[Courtney Nash]] は Root Cause 指定が因果の単純化・上流要因の見逃し・人間への過剰索引付けを招くとし、[[Sidney Dekker]] の「因果性は構築される」を引用した - 根拠: [[@2022__SREcon22 EMEA__Principled Identification of Root Causes Using Techniques from Safety Engineering]] p.15 — [[Laura de Vesine]]（[[Datadog]]）は根本原因を潜在脆弱性の集合、トリガーをそれを顕在化させた環境条件の集合と再定義した - 根拠: [[@2022__OReilly__Anatomy of an Incident - Chapter 5 Postmortems and Beyond]] — [[wiki/entities/Anatomy of an Incident|Anatomy of an Incident]] はハザードとトリガーの対を独立に定式化し、語は残して精緻化する - 根拠: [[@2024__OReillyJapan__SREをはじめよう - Chapter 10 失敗から学習する]] §10.1 — [[David N. Blank-Edelman]] は「根本原因」ではなく「一因」を語ることが視点の転換だと述べ、なぜなぜ分析が並行する問いを飛ばすと批判した - 根拠: [[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]] §8.6 — 2004 年の教科書は原因木の使用をすでに RCA と呼んでいた - **CAST は RCA の対置ではなく、遠位の社会技術要因まで踏み込むより深いフレームとして産業適用されている。** - 根拠: [[@2026__SREcon26Americas__The Case of the Misnamed Cities - CAST Analysis of a Google Maps Incident]] — [[Ruben Barroso]] は Google Maps の都市名誤表示で、RCA の 2 原因に加えメンタルモデルの誤り・責任拡散・環境変化によるポリシー陳腐化を析出した - 関連: [[CAST]] — 事故モデル・改善計画・分析フレーム・組織要因の 4 軸 - **判断基準なしになぜを重ねると、調査はスコープ外の原因かトリガーの無限遡行に着地する。** - 根拠: [[@2022__SREcon22 EMEA__Principled Identification of Root Causes Using Techniques from Safety Engineering]] p.12・p.5 — 5 Whys を機械的に適用すると「原因は資本主義」「原因は気候変動」にもなり、判断基準のない Why の重畳がトリガーホワイトアモールを生む - 根拠: [[@2024__OReillyJapan__SREをはじめよう - Chapter 10 失敗から学習する]] §10.1 — 「ログローテーションが設定から漏れた」で止め、ディスクを埋め尽くすログを送っていた側を問わないのは同型の失敗である - 関連: [[仮説駆動RCA]] — 仮説を立てて検証する構造が必要な理由 - **交絡因子の非記録と症状だけの修正は、どちらも誤帰属を固定する。** - 根拠: [[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]] — リトライポリシー変更への誤帰属は、並行するオートスケーリングとトラフィックシフトが介入ログに残らなかったために起きた - 根拠: [[@2021__OReillyJapan__SREの探求 - Chapter 15 信頼性とプライバシーが交わるところ]] §15.3.2.2 — データ漏洩や広すぎる ACL では、個別バグや個別 ACL ではなく文書・ツール・デフォルト設定を直す - 関連: [[Causal Software Engineering]] — 交絡の非記録という自動化可能な欠落 - 関連: [[プライバシーエンジニアリング]] — 同型再発の予防 ## 仮説と証拠の反復 - **RCA は全データの要約ではなく、仮説を立て限定したテレメトリで検証する反復である。** - 根拠: [[@2016__OReilly__SRE Book - Chapter 12 Effective Troubleshooting]] — 仮説演繹法とトリアージ - 根拠: [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]] — [[Bits AI SRE]] の仮説駆動調査 - 関連: [[仮説駆動RCA]] — [[SREGym]] / [[Stratus]] の探索ループも同型 - 関連: [[インシデント調査戦略]] — 調査戦略の分類 - **実地の調査は日和見的出発と体系的追跡の組み合わせであり、相関の発見だけでは失敗する。** - 根拠: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] §IV-C — 30 インシデントの定性分析で、日和見的戦略（典型原因の確認・時間相関）と体系的戦略（症状連鎖・スタック追跡）の組み合わせが多数派だった - 根拠: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] 観察 8 — incidents 1.11, 2.2 は相関を見つけても因果を理解できず失敗した - **産業の調査エンジンは仮説空間の宣言と人間フィードバックを明示する。** - 根拠: [[@2019__SIGMOD__ExplainIt! - A Declarative Root-cause Analysis Engine for Time Series Data]] §5・§6 — SQL で仮説空間を宣言し 2014 年以来 44 件中 31 件を数十分以内に解決、13 件は監視データ不足で診断不能と報告した - 根拠: [[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]] §5・§6 — 知識グラフによる収集自動化、BCPD 変化点整合度と 5 方向仮説操作、調査ボードの共有で Precision/Recall = 0.94/0.93 - 関連: [[宣言的RCA]] — ExplainIt! の宣言的仮説列挙 - 関連: [[限定観測可能性]] — 44 件中 13 件がデータ不足で止まった - **ありふれた原因から先に除外する優先順位は、後年のエージェントが暗黙に採用する設計と同型である。** - 根拠: [[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]] §8.5.4 — Principle 45「まず明白な原因を除外せよ」。遠くの馬蹄の音では馬を疑う ## 入力選別と探索空間 - **情報を取りすぎることは統計手法の時代から続く病理であり、入力選別は前処理ではなく RCA の中核である。** - 根拠: [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]] — [[MetricSifter]] は無関係メトリクスを削ることで因果探索を助ける - 根拠: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] — テレメトリのツール呼び出しを増やすと性能が落ちる - 関連: [[RCA入力選別]] — 入力選別の詳細 - **入口の広さとデータモデルの質は、推論能力より先に精度を律速する。** - 根拠: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §VI, Tables IV-V — [[UModel]] はデータ組織化だけで LA +8.12・Top-1 Acc +6.52。PaaS 意味的ツール層は IaaS 直接クエリに対し OS +9〜+13 ポイント - 根拠: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §VI-A — 従来データモデルでは PromQL 直接生成が 5% 未満（GPT-4-Turbo でも約 2.6%） - 根拠: [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]] — [[RCAgent]] の SQL/SLS 直接ツール置換は Invalid Rate 70.94% まで悪化した - **事前宣言と要約圧縮は、無差別な取得を設計で排除する。** - 根拠: [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]] §2.3・§3.4, Tables 3, 7 — [[Bian Que]] は Skill(LoadDataSchema) で取得対象を事前宣言し、オンライン精度 80%・pass@5 = 99.0%。NOKNOW で pass@5 が −7.7 pp - 根拠: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 3 Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]] §3.4.3, Table 11 — RCACopilot は要約なし Micro-F1=0.689 から要約あり 0.766 へ改善した - 関連: [[Flexible Skill Arrangement]] — 事前コンテキスト制御 - **ハイパースケールでは探索空間の事前圧縮が、後段の因果発見や LLM 推論より先に必要になる。** - 根拠: [[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]] §2・§3.2 — 快手の 20 万超サービスでは障害時に最大 1 万サービスが連鎖し、API レベルで 3 サービスへ絞らなければ後段は実行できない - 根拠: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] §3-4, Tables 1-2, Figure 5 — [[MagmaScope]] は変更チケット検索→軽量ランキング→LLM 推論で Top@5 74.7%・Top@10 89.8%。チャット保存率 30% 付近で精度が跳ねる - 根拠: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §4.5.2 — LogSage の能動学習はラベル 6% で頭打ちになり、希少な教師ラベルへの緩和になる - 関連: [[Change Object Rewrite]] — 変更チケット記述の意味的正規化 - 関連: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] — 既存手法の想定規模 > [!contradiction] MagmaScope における関連付けの表現 > MagmaScope の §3.2.3 は関連付けを「causal inference mechanism」と呼ぶ一方、§8.1 は「causality」ではなく意味的理解を重視すると記述する。Top-k 推薦を因果関係の証明と解釈せず、意味的関連付けとして扱う。 - **追加情報は意味的適合と推論誘導が揃わなければ精度を下げ、サンプリングへの感度はアルゴリズム族で異なる。** - 根拠: [[@2024__FSE__X-lifecycle Learning for Cloud Incident Management using LLMs]] — Microsoft IC3 の 353 インシデントで InC DEP は BLEU +5〜38%・NUBIA +54.67% だが、例なしの DEP 単体は効果がなくわずかに低下する - 根拠: [[@2026__ISSTA__Gleaner : A Semantically-Rich and Efficient Online Sampler for Microservice Diagnostics]] §4.5 — MicroRCA は 99% 削減でも鈍感、ShapleyIQ は AC@3 が 0.64→0.21 に崩れ、Nezha は異常優先か多様性を欠くと Random 未満になる - 関連: [[トレースサンプリング]] — 入力の選び方が量とは別の軸になる ## 相関と因果 - **相関は因果を保証せず、この限界は 2004 年から自覚されていた。** - 根拠: [[@2004__OSDI__Correlating Instrumentation Data to System States - A Building Block for Automated Diagnosis]] — Cohen らは発見が相関であって因果ではないと明記し、無関係メトリクスを除外することが診断の主価値だと述べた - 根拠: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] §4.4.3 — Soldani & Brogi 2021 は 26 手法すべてが相関に依るとし、第三の共通原因や同一ノード上の別サービスを構造的に見逃すと述べた - 根拠: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.4 Discussion (Root Cause Analysis)]] — 章単位の同一整理 - 関連: [[RCA入力選別]] — 無関係信号の除外は 2004 年から中核だった - **因果探索と RCA 手法の多くは Dummy ベースラインを超えない。** - 根拠: [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]] — Pham らは 9 種の因果探索と 21 種の RCA を Dummy と比較し、PC/FCI/Granger/LiNGAM などの多くが同等以下、BARO・CausalRCA・RCD・CIRCA・NSigma（精確な障害時刻下）は上回った - 関連: [[因果推論ベースRCA]] — 包括評価の詳細 - **因果グラフ手法の律速は辺方向の推定と異常検知時刻への感度である。** - 根拠: [[@2020__IPCCC__FluxInfer - Automatic Diagnosis of Performance Anomaly for Online Database System]] — 重み付き無向グラフ + PageRank が PC 系 8 手法を AC@3 で 2〜15 倍上回った - 根拠: [[@2024__FSE__BARO - Robust Root Cause Analysis for Microservices via Multivariate Bayesian Online Change Point Detection]] §4.6〜4.8, Tables 3-4 — 平均・標準偏差ベースは $\hat{t}_A$ 遅延で Avg@5 が最大 33〜62% 変動し、RobustScorer は 25%。Train Ticket 64 サービスで因果グラフ手法は 0.07〜0.28、BARO は 0.81 - 根拠: [[@2019__WWW__ε-Diagnosis - Unsupervised and Real-time Diagnosis of Small-window Long-tail Latency in Large-scale Microservice Platforms]] — エネルギー距離は α=0.05 で再現率 100%、候補を総メトリクスの約 10% に絞り、Pearson は平坦→急上昇を検出できなかった - **時系列統計による因果発見はメトリクス数が増えると崩れ、意味情報で方向を先に確定する設計へ寄る。** - 根拠: [[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]] §2.2・§3.3, Fig.2(b) — PC と Granger は異常メトリクス 5 で精度 50%、20 で 20% 以下。スケルトングラフは E/I/D/K の方向をサービス設計の意味から先に確定する - 根拠: [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]] — 同一の Dummy 未達観察が独立に収束する - **原因と症状の時間的整列は、空間圧縮とは独立した設計変数である。** - 根拠: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]] — 本番銀行データ D1 の 81.5% で最大伝播ラグが 2 分以上だった - 根拠: [[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]] — 空間軸の事前圧縮とは補完関係にある ## グラフ訪問と古典的パイプライン - **因果グラフの構築とパーソナライズドランダムウォークの二段が、LLM 以前の主流パイプラインである。** - 根拠: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] §4.2.3・§4.4.1 — MonitorRank の相関比例ランダムウォークを CloudRanger・MS-Rank・AutoMAP・MicroCause・MicroRCA が再利用した - 根拠: [[@2013__SIGMETRICS__Root Cause Detection in a Service-Oriented Architecture]] — MonitorRank は LinkedIn 400 超サービスで HR@1=0.53 - 根拠: [[@2018__CCGrid__CloudRanger - Root Cause Identification for Cloud Native Systems]] — PC + 二次ランダムウォークで PR@3=0.946 - 根拠: [[@2020__WWW__AutoMAP - Diagnose Your Microservice-based Web Applications Automatically]] — 異常行動グラフと前方・自己・後方の 3 種ランダムウォーク - 根拠: [[@2019__ISSRE__FluxRank - A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation]] — マシンレベル RCA を Baidu に本番展開した - 根拠: [[@2023__arXiv__PyRCA - A Library for Metric-based Root Cause Analysis]] — PC/GES/FGES/LiNGAM + PageRank/ε-Diagnosis/BARO を一つの API に統合した - 関連: [[A Survey of AIOps in the Era of Large Language Models]] — LLM 期がこの二段をどう置き換えるかは未整理 - 関連: [[グラフベースRCA]] — グラフ訪問の詳細 - **移植性の鍵は呼び出し依存ではなく、論理的合意に基づくグラフである。** - 根拠: [[Failure Diagnosis in Microservice Systems]] §4, Figure 1, Figure 3 — 2003〜2024 年の 98 論文を 4 モダリティで分類し、メトリクスベース RCL が 63 本で最多 - 根拠: [[Failure Diagnosis in Microservice Systems]] §5.3 — MicroCBR・CloudRCA・TrinityRCL・NetMedic・Sleuth が論理グラフで展開コストを下げる。`[130]` は Sleuth（Yu Gan et al. 2023） - 関連: [[RCACopilot]] — ドメイン固有の手作業 DAG は精度と移植性の反対側にある - **入力グラフの曖昧さは、アルゴリズム以前に精度を損なう。** - 根拠: [[@2023__WWW__CMDiagnostor - An Ambiguity-Aware Root Cause Localization Approach Based on Call Metric Data]] Table 8 — AmSit を解消するだけで Microscope の HR@5 は 0.68→0.69、AutoMap は 0.78→0.82、MicroHECL は 0.80→0.89 - **非集計トレースと排他レイテンシは、集計や疎データが見逃す障害を拾う。** - 根拠: [[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]] — 個別リクエストをテストケースと見立てた Ochiai スペクトルと処理時間相関の PageRank で Precision 90%・Recall 86%、計算 500ms 以下 - 根拠: [[@2024__ISSRE__SparseRCA - Unsupervised Root Cause Analysis in Sparse Microservice Testing Traces]] — テスト環境は本番比 400 分の 1 の疎トレースで統計手法が A@1=19.3〜40.7% に落ち、排他レイテンシで A@1=66.1%・A@5=88.1%。PageRank 除去で A@1 が 49.2% - 関連: [[SparseRCA]] — 包含から排他への分解 - **グラフを捨てずに計算量と偽陽性を抑えるには、分割統治と論理・物理の二層統合がある。** - 根拠: [[@2025__AIDB__AutoDebugger - Efficient Root Cause Analysis for Anomaly Jobs]] — HybridRCA は顕著ノードで分解し、40 変数超の Spark ジョブで 147 秒を 12 秒にし、平均誤差 0.4%・最大絶対誤差 5% - 根拠: [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]] §2・§3 — [[eBay]] の [[NuData]]（1 スクレイプ 2000 万メトリクス）で論理階層と物理階層を統合し、IDF 型スコア伝播で数時間を数分にした - 関連: [[Sparkジョブ異常診断]] — HybridRCA の対象ドメイン ## 箇所特定と説明 - **RCA の成果物は箇所特定から、なぜ起きたかの説明と再発防止の対策推奨へ広がる。** - 根拠: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] §4.4.4・§6 — 説明可能性と対策推奨を 2021 年から未解決課題として挙げた - 根拠: [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]] — 運用者が真偽を絞り込める説明が目標になる - 根拠: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 6.3 Downstream Log Analysis Tasks - Failure Prediction and Root Cause Analysis]] — 出力は自由形式説明・構造化ラベル・対処に分かれ、ログは運用者向け証拠チェーンを提供する - 関連: [[AIOpsLab]] / [[UModel]] — 説明可能なデータと調査過程 - **箇所特定と原因診断は同じ順序を共有しつつ、分類の境界はサーベイ間で揺れる。** - 根拠: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]] — Notaro らは fault localization と root-cause diagnosis を RCA 内部の 2 段階に置いた - 根拠: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] — AIOpsLab は localization と RCA を独立した先行・後続ステージとして並置する - 根拠: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]] §VI — エージェントシステムの失敗帰属は実行軌跡上の決定ポイント特定へ移り、FAMAS・GraphTracer/AgenTracer・Who&When の 3 パラダイムがある - 関連: [[Fault Localization]] — 箇所特定を独立ページとして扱う分類 - **データ源による分解と機能による分解は直交し、古典手法の大半は第一段階だけを自動化している。** - 根拠: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.4 Discussion (Root Cause Analysis)]] — ログ/分散トレーシング/監視の class 分類は計装コストと詳細度のトレードオフを述べ、説明可能性は §4.4.4 に別立てされる - 根拠: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]] — 機能分解の第 2 段階（なぜかの診断）はデータ源の違いによらず未達成のまま残る - **問題定義の断片化は手法の汎化を阻み、場所・詳細・知識を同時に解く定式化が提案された。** - 根拠: [[@2024__TSC__Holistic Root Cause Analysis for Failures in Cloud-Native Systems Through Observability Data]] §II-A・§III — HolisticRCA はリソースエンティティ・オブザーバビリティ特徴・障害種別の 3 次元を同時に解き、Nezha・Eadro・DiagFusion を上回った - 根拠: [[@2024__TSC__Holistic Root Cause Analysis for Failures in Cloud-Native Systems Through Observability Data]] §IV-A〜C — 特徴を $\lambda$ 次元ブロックに部品化し、DiagFusion の 3 シグマ変換が潰す細粒度を保持する - 関連: [[マルチモーダル障害診断]] — 等価融合による情報希釈とは別の、正解定義の不整合 - **出力は根本原因の集合から伝播経路へ拡張され、層によってはパス推論が必須になる。** - 根拠: [[@2025__arXiv__RADICE - Causal Graph Based Root Cause Analysis for System Performance Diagnostic]] — RADICE は PCMCI+ と部分ドメイン知識で根本原因から性能メトリクスまでの因果サブグラフを出し、広告システムの専門家分析と一致した - 根拠: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §II-C・§IV-C3・§V-B 表IV — 現場は電源障害の修復だけでなく伝播路上の老朽 PSW も直す必要があり、PPI で PCR 46.3% - 関連: [[クラウドインフラ障害診断]] — 物理デバイス層のパス推論 ## 評価の不安定性 - **既存ベンチは最も目立つ症状を根本原因として許すことがあり、進歩は評価設計に依存する。** - 根拠: [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] — SimpleRCA が既存ベンチで SOTA に近い結果を出す - 根拠: [[Anomaly detection and root-cause identification in microservices]] §4.7 — 機械学習系 precision 94.9% / recall 98.0% / F1 99.0% などと集計するが、データセット・テストベッド・指標の不均一が直接比較を難しくする - 関連: [[RCA評価設計]] — 評価基盤の詳細 - **合成障害での性能は実システムへの転移を保証しない。** - 根拠: [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]] — 条件確率変化の合成注入と CPU スパイク等の実障害が乖離する - 根拠: [[@2022__ESEC FSE__Constructing Large-Scale Real-World Benchmark Datasets for AIOps]] — [[Suning]] 由来の dataset B は 400 件の合成障害（GRE + ガウスノイズ）で、著者自身が実障害の大量収集が困難だと明記した。[[Squeeze]] の B0〜B4 は同一原データ - **実障害の根本原因分布は学術の障害注入モデルとずれ、設定ミスと複数原因が支配的である。** - 根拠: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]] — AWS・Azure・Google Cloud の 354 件で設定ミス 31.6%、ハードウェア 17.0%、不明 12.1%、複数根本原因 23.2% - 根拠: [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]] p.15-17 — [[Sue Lueder]]（[[Google]]）の 9 カテゴリは Network Failure と Third Party Systems が高頻度で、Config と Workflow を独立カテゴリに分ける（全データ捏造と明記） - 根拠: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] — オペレータエラー支配という別分布 - **RCA タスクは層と種別の複合評価であり、指標は運用上の定義ごとに分裂している。** - 根拠: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] §5.3・§5.8 — AIOpsLab の RCA はシステム層と障害種別の 2 サブタスク（11 問で 22 インスタンス）だが、表 22(a) は単一 Accuracy（GPT-4o 40.90%）へ集約する - 根拠: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 6.3 Downstream Log Analysis Tasks - Failure Prediction and Root Cause Analysis]] Table 8 — 説明は意味的類似度、局所化は Acc@k、分類は F1、対処は ROUGE/BLEU を好む - 根拠: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.5 Root-cause identification]] Table 6・7 — グラフベース 45 件（58%）、機械学習 27 件（35%）、統計 23 件（29%）。研究数最多と報告性能の首位は一致しない - 根拠: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]] — RCACopilot を 4 段分類の RCA 段の実装例として自己位置づけするが、RCA 固有の頑健性評価は Future Work に明示されない - **公平性は RCA ではほぼ手つかずの信頼性要件であり、入力汚染と実行環境の改竄は別の脅威面である。** - 根拠: [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]] §4 — 異常検知にはコスト考慮学習があるが、根本原因箇所特定の公平性研究はほとんど見当たらない - 根拠: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 6 Challenges, open issues, and directions to future investigations]] §6.1 — TEE は分析器自体の実行完全性を問題にし、診断データ汚染とは脅威面が違う - 関連: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization]] — 説明可能性を因果構造の解釈可能性として置く ## ドメインと観測モダリティ - **RCA の主信号はドメインごとに変わり、粗粒度の物理基盤ではマイクロサービスの前提が成立しない。** - 根拠: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §I・§II-B・§V-B — 6 障害種別を単一ソースで全捕捉できず、AirAlert・COT を物理基盤へ適用すると形式が合わず、BSODiag は COT に PR@3 で +10.2% - 根拠: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §4.4 — [[ByteDance]] のカーネルパニックを FILE（選別）と GARCA（グラフ推論）に分け、F1=92.2%/95.3%/96.3%。選別段 +32.1 pt、推論段 +25.5 pt - 関連: [[ドメイン別RCA]] — マイクロサービス・DB・LLM 訓練で主信号が変わる - **マルチモーダルは独立分類へ格上げされ、融合は均質化・検知一体化・非対称スコア化に分かれる。** - 根拠: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]] — Zhang+ 2024 はマルチモーダルを第 4 分類とし、result / model / feature fusion に細分化する - 根拠: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.4 Failure Diagnosis Through Multimodal Data]] — 少なくとも 2 種類の組み合わせという定義 - 根拠: [[@2023__ESEC-FSE__Nezha - Interpretable Fine-Grained Root Causes Analysis for Microservices on Multi-modal Observability Data]] — 3 モダリティを共通イベントへ変換し、コード領域とリソースタイプまで絞り Top-1 89.77% - 根拠: [[@2023__arXiv__Eadro - An End-to-End Troubleshooting Framework for Microservices on Multi-source Data]] — 検知と箇所特定を一体化し、検知誤差の伝播を防ぐ - 根拠: [[@2024__TOSEM__HeMiRCA - Fine-Grained Root Cause Analysis for Microservices with Heterogeneous Data Sources]] §3-4, Tables 3-4 — トレースを VAE で単一異常スコアにし Spearman 相関で、サービス HR@1=82.7%・メトリクス HR@1=74.0%。Spearman > Kendall > Pearson - 関連: [[HeMiRCA]] — 1 モダリティをスコア化してから相関する第 4 の統合 - **モダリティの選択は粒度・解釈可能性・量・移植性を同時に規定する。** - 根拠: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]] §5.2〜§5.3 — ログ・トレースは細粒度だが量大、メトリクスは定量的だが文脈が薄い - 根拠: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.4 Discussion (Root Cause Analysis)]] — 計装コストと識別できる詳細度のトレードオフ - **ソースコードと変更チケット・会話は、ログ・メトリクス・トレース以外の証拠になる。** - 根拠: [[@2025__arXiv__COCA - Generative Root Cause Analysis for Distributed Systems with Code Knowledge]] §V, Tables II-IV — [[COCA]] は JIRA のみから静的解析と ICFG で実行コンテキストを渡し、RCACopilot 比で Exact Match +28.3%・BLEU-4 +22.0% - 根拠: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] — 第 4 のテレメトリとして IM チャットの診断価値を定量化した - 関連: [[コード知識強化RCA]] — 監視データの代替としてのコード - **決定的グラフの前後をエージェントが担う構成は、テレコムで実測されている。** - 根拠: [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]] — NTT DOCOMO（加入者 8900 万超）でグラフ分解→クラスタリング→中心性の前後を 13 エージェントが挟み、MTTD 15 秒 - 根拠: [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]] — 仮説駆動のマルチエージェントとは中核の置き方が違う - 根拠: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]] — 本番実測 11.34% 精度とは評価軸（速度）が違う - 関連: [[LLMによる根本原因分析]] — LLM に因果推論を委ねる設計との中間 ## エージェント適応と緩和接続 - **本番の実用性は形式的因果モデルより、経験的ハンドラと LLM 圧縮が先行している。** - 根拠: [[@2022__KDD__Causal Inference-Based Root Cause Analysis for Online Service Systems with Intervention Recognition]] — CIRCA はコールグラフとゴールデンシグナルを強く必要とし、Oracle DB 99 件で AC@1=0.404 - 根拠: [[@2022__NeurIPS__Root Cause Analysis of Failures in Microservices through Causal Discovery]] — RCD はドメイン知識を捨て 500 ノード 22 秒だが、本番評価は AWS 3 ケース - 根拠: [[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]] — RCACopilot は OCE のアラート種別ハンドラと LLM を組み合わせ、Microsoft 30 超チーム・4 年以上で Micro-F1=0.766 - 根拠: [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]] — Dummy 未達の不安は本番実績で部分的に解消され、ハンドラ構築工数が新たな律速になる - 根拠: [[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]] RQ2・RQ4 — 31 件中 11 件（35.5%）が RCA を主目標とし、[[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture|mABC]] と [[RCAgent]] を代表例に挙げる - 根拠: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]] — 多元的テレメトリへの LLM 推論適応を 4 段分類の RCA 段として要約する - **LLM の RCA 適応はモデル更新より、検索された事例と異種証拠の統合が主因である。** - 根拠: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 3 Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]] §3.4, Table 10 — GPT-4 Prompt は Micro-F1=0.026、ファインチューニング済み GPT は 0.103、検索付き RCACopilot は 0.766 - 根拠: [[@2023__ICSE__Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models]] — タイトル・要約のみのファインチューニングは非構造化信号を落とし、更新コストと幻覚が増える - 根拠: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 6.3 Downstream Log Analysis Tasks - Failure Prediction and Root Cause Analysis]] — ログ主体では LLM は推論者というより異種証拠の統合器であり、検索・ツール・SOP・グラフで生成を制約する設計が信頼できる - **緩和は RCA ラベルの正しさに構造的に依存せず、満たすべき条件はタイミングと十分性である。** - 根拠: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.1・§4.4 — STRATUS の緩和成否は TNR の `µ` の単調非増加だけで、GPT-4o の RCA 成功率 34.6% に対し緩和は 69.2% - 根拠: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 3 Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]] — 診断精度自体を最適化する設計との対比 - 根拠: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]] Finding 10 — 設定ミス→ロールバック 51 / リプレースメント 48、ハードウェア→フィックス 54 は強いが、リソース競合と例外は均一に複数緩和が使われる - **圧縮してから知識照合する再発識別は、LLM 以前から産業で実証されている。** - 根拠: [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]] — LogCluster は生ログ 1000 万件を 40 件に圧縮し、2013 年以来 Microsoft 4 製品チームで稼働した。高重大度ログの 10% 未満しか障害に関係せず、30% 超が INFO に起因する - 関連: [[L4]] — 3 指標が障害ログを弁別できないという後年の観察 - 関連: [[AlertGuardian]] — RAG 知識ベースと同型 - **人間がアルゴリズムの因果グラフを事後修正する機構は、説明可能性の主張に対して実例が薄い。** - 根拠: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.5 System-Level Trustworthiness Requirements]] §3.5.2 — 異常検知の人間介入は 4 件挙げるが、箇所特定は「因果グラフを人間が修正しうる」と一文にとどめる - 根拠: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization]] §3.4.2 — 因果推論を本質的に解釈可能とするが、監査・修正への接続は未検証 - 関連: [[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]] — 最も近いが対象は変化点スコアであり、グラフ構造の修正ではない ## 未解決の問い - 研究数で優勢な手法カテゴリ（グラフベース 58%）と、報告される性能指標で優勢な手法カテゴリ（機械学習）の乖離は、出版バイアスと性能報告基準の不統一のどちらに起因するか。同一カテゴリ内の評価指標の不統一が、この非対称をどこまで説明するかは未検証である。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.5 Root-cause identification]]) - AIOpsLab の RCA サブタスク（システム層の特定 / 障害種別の特定）は、それぞれ単独でどの程度正解しているか。複合 Accuracy に集約された報告からは、2 軸のどちらがより困難かが読めない。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] §5.8) - 根本原因箇所特定の公平性（特定の障害クラス・特定のサービスへの誤帰属バイアス）を定量評価した研究はあるか。不均衡な障害クラス分布への偏りは、異常検知のコスト考慮学習に相当する技術が未提案なのか、公平性という枠が top-k や完全一致になじまないのか。(Source: [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]]) - CSE の causal design spec / intervention log は、CAST や de Vesine の脆弱性/トリガー再定義とどう統合すべきか。形式的な因果推論の成果物と社会技術的な分析フレームを、同一のポストモーテム過程へどう組み込むかは未検討である。(Source: [[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]]) - アルゴリズムが構築した因果グラフを人間の知識で修正する RCA 向け人間介入は、どう実装されうるか。修正インタフェース・修正対象（辺の追加/削除/方向転換）・再学習コストは、サーベイが一文で示唆するだけで実証がない。(Source: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.5 System-Level Trustworthiness Requirements]]) - 合成障害データセット（dataset B 等）で最適化された多次元 RCA 手法は、実障害の根本原因分布にどこまで汎化するか。GRE ベースの合成が模擬できる異常と、実障害に特有で合成では再現されないパターンの違いは未検証である。(Source: [[@2022__ESEC FSE__Constructing Large-Scale Real-World Benchmark Datasets for AIOps]]) - LogSage の推論遅延許容（約 3.1 秒）は事後分析としての RCA という前提に依存する。この前提は、調査ループの一部として即応が必要な障害クラスにどこまで一般化するか。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §4.2) - LagRCA の時間ラグモデルと KRCA の空間圧縮は統合できるか。評価環境の規模差（46 インスタンス対 20 万超サービス）のもとで、低ランクパラメータ化 $O(Nr)$ が数十万サービスで実行できるかは未検証である。(Source: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]]) - RCA の成功は、根本原因コンポーネントの完全一致、説明の妥当性、調査過程の健全性、緩和への有用性のどれで測るべきか。 - HolisticRCA の 3 次元（場所・詳細・知識）は同時求解を要件とするが、実対応では優先度が局面で変わる。障害種別から着手し場所と詳細を必要に応じて行う最適化は、局面依存をどう設計へ織り込むべきか。(Source: [[@2024__TSC__Holistic Root Cause Analysis for Failures in Cloud-Native Systems Through Observability Data]] §V-E) - 多変量 BOCPD の計算は次元が増えると二乗程度に伸びる。サービス数 100 超・メトリクス数 1000 超で、BARO のような変化点検知は計算的に成立するか。([[@2024__FSE__BARO - Robust Root Cause Analysis for Microservices via Multivariate Bayesian Online Change Point Detection]]) - 複数仮説を並行検証するエージェント設計は、最初のもっともらしい異常への固着をどこまで防げるか。 - RCA 専門エージェントと緩和エージェントを分けると、診断誤差は後段で増幅されるか、それとも安全になるか。 - 限定観測可能性や未監視層があるとき、RCA は「不明」と判定する能力をどう獲得すべきか。 - [[UModel]] による RCA 改善の 8% のうち、意味付与・トポロジグラフ・ツール層の寄与はどれほどか。3 要素を分離したアブレーションは未実施である。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §VI-B) - エージェントシステムの失敗帰属における 2 段階（非 LLM で疑惑領域を絞る → LLM-as-a-Judge）は、第 1 段階の見逃し率とコストをどう設計するか。VAE 再構成を第 1 段階に使う試作は、分布外の障害パターンで汎化するか未検証である。([[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]] §VI-C) - RCAgent の TSC による出力多様化と、Bits AI SRE 型の仮説リスト管理は統合できるか。([[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]]) - Trusted Distributed AI の評価軸（信頼性・説明可能性・一貫性・頑健性・因果妥当性）は、完全一致や top-k にどう接続すべきか。根本原因ランキングの分散や因果解釈可能性スコアは、既存の AIOps ベンチで再現可能に測れるか。([[Anomaly detection and root-cause identification in microservices]] Table 10) - Soldani & Brogi 2021 が挙げた継続的デリバリ下の継続的変化への対応は、2026 年時点でどこまで解決されたか。LLM 期のゼロショット推論は新サービスの特定に答えつつあるが、動的な依存グラフへの追従を評価した研究は少ない。([[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]] §6) - 非集計トレースが有効な障害クラスと、集計トレースで十分な障害クラスの境界はどこか。部分的・断続的障害の比率、トポロジの不均質性、レプリカ数を定量化した研究が不足している。([[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]] §4.4) - RCACopilot のアラート種別ハンドラを LLM が自律生成できるか、それとも OCE 手作業に依存し続けるか。これは [[エージェント型コーディング]] と [[Flexible Skill Arrangement]] が扱う、手続きの動的組み立てと同じ系列である。(Source: [[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]]) - HybridRCA の分割統治と因果グラフの自動構築（NOTEARS/FCI）は統合できるか。ドメイン知識による手動構築なしに顕著ノードを検出できるか。(Source: [[@2025__AIDB__AutoDebugger - Efficient Root Cause Analysis for Anomaly Jobs]]) - X-lifecycle Learning が有効と示した依存サービス障害（IC3 の約 50%）以外で、有効な SDLC 段階の情報源は何か。ソースコード・コミット履歴・設定変更ログを組み合わせると、トークン制限と関連性選別が同時に起きる。(Source: [[@2024__FSE__X-lifecycle Learning for Cloud Incident Management using LLMs]]) - 評価基盤が敵対的操作への耐性を含むとき、細工された診断データやログ汚染に対して RCA の正確性はどこまで頑健か。AIOpsLab / OpenRCA / SREGym はこの軸を測っていない。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]] §6.2) - 緩和計画への十分性を測る指標（緩和成功までの再試行回数、緩和計画への追加ステップ数など）はどう定義できるか。ラベル一致や Micro-F1 とは別に、緩和との接続を軸にした動的指標は未確立である。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.1, §4.4) - 診断粒度・移植性・精度コストの 3 軸トレードオフを、単一のモダリティ選択として定量最適化した研究はあるか。[[RCA入力選別]]・[[特徴量削減]] と組み合わせたパレートフロンティアは見当たらない。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]] §5.2〜§5.4) - MagmaScope の外部妥当性は、ByteDance 固有の IM ワークフロー・専門用語・プライベート知識・変更起因の選択・エキスパートラベル・doubao データ汚染の 6 要因に制約される。55 件が変更起因以外やクロスシステム比較の保証を与えるかは未回答である。(Source: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] §4.4) - マイクロサービス以外の分野の原因特定手法を RCA へ転用する道筋は、Barata+ 2026 §6 では提案にとどまり実証されていない。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 6 Challenges, open issues, and directions to future investigations]] §6.3) - 入力データの汚染への頑健性と、分析器自体の実行完全性（TEE）を分けて評価する枠組みはあるか。既存の RCA システム評価は、データレベルの脅威と基盤レベルの脅威を区別していない。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 6 Challenges, open issues, and directions to future investigations]] §6.1) - 根本原因分析における『複数原因を優先順位付けして提示する』アプローチと、単一根本原因への収束を志向する評価指標(§単一根本原因という概念)はどう両立するか。 ## 未編纂の観察 > [!note]- 編纂前の観察 2026-09 > - **単一根本原因の探索が構造的に成立しない歴史的事例として、1979年 NORAD 誤警報がある**: [[@2023__SREcon23Americas__Epic Incidents of History - The 1979 NORAD Nuclear Near Miss]] は、テストデータが本番の早期警戒システムに誤って流れ込みソ連の核攻撃と誤認された事件を、数十年の軍事技術・組織圧力の蓄積(遠因)が現場オペレーターの判断にどう浸透したかとして描く。国防総省は「オペレーター過誤」という単一原因に帰結させたが、Walker・Woods・Rayo の「複数の系統的寄与要因 vs 根本原因」という枠組みは、[[複雑システム障害論]] の命題 7（RCA の社会的構築性）と同一の批判を、ソフトウェアシステムに限らない一般則として補強する。 > - **RCA は「全データ要約」ではなく、仮説と証拠の反復である**: SRE Book の仮説演繹法、[[Bits AI SRE]] の hypothesis-driven investigation、[[SREGym]]/[[Stratus]] の探索ループは、いずれも「仮説を立て、限定されたテレメトリで検証し、棄却または深掘りする」構造を共有する。([[@2016__OReilly__SRE Book - Chapter 12 Effective Troubleshooting]], [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]]) > - **情報を取りすぎる病理は統計手法時代から続く**: [[MetricSifter]] は無関係メトリクスを削ることで因果探索を助け、AIOpsLab/Bits AI SRE は LLM エージェントが telemetry tool call を増やしすぎると性能を落とすと報告する。入力選別は前処理ではなく RCA の中核である。([[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) > - **評価は RCA 研究の最大の不安定要因である**: SimpleRCA が既存ベンチで SOTA に近い結果を出す事実は、ベンチが「最も目立つ症状 = 根本原因」を許していた可能性を示す。RCA の進歩はモデルだけでなく評価設計に依存する。([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) > - **RCA はドメインごとに信号源が変わる**: マイクロサービスでは依存グラフとトレース、DB では内部メトリクス・実行計画・知識グラフ、LLM 訓練では GPU/ネットワーク/集合通信の均質性やストラグラーが主信号になる。一般 AIOps の語彙だけでは不十分で、[[ドメイン別RCA]] が必要になる。 > - **出力は箇所特定から説明へ広がる**: LLM 時代の RCA は root cause report generation や incident summary を含み、人間が読む「なぜ起きたか」の説明が成果物になる。これは exact-match 型の箇所特定評価だけでは測りきれない。 > - **エージェントシステムの RCA(= 失敗帰属)は「インフラ箇所特定」から「トラジェクトリ上の決定ポイント特定」へ移る**: 本 wiki の RCA はマイクロサービスの依存グラフ上でのサービス・ノード特定を主に扱ってきた(Cloud-OpsBench / Fault Propagation-Aware Benchmark 等)。AgentOps サーベイ([[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]])は、エージェントシステムの RCA を「どの実行トラジェクトリのどのステップで誰が最初に異常を起こしたか」という失敗帰属問題として定義し直す。FAMAS(スペクトル分析)・GraphTracer/AgenTracer(因果グラフ)・Who&When(LLM 裁定の 3 パラダイム)という 3 カテゴリを整理し、LLM ベースはコンテキスト長増大で精度が低下するが非 LLM ベースは安定という相補性を Figure 11 で示す。この「トラジェクトリ失敗帰属」は本 wiki の仮説駆動 RCA([[仮説駆動RCA]])の「推論ループを繰り返して原因を絞り込む」構造と類似しつつ、サービス依存グラフではなく実行軌跡グラフを対象とする点で根本的に異なる入力構造を持つ。(Source: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]] §VI) > - **データモデルの品質が RCA 精度を律速することが大規模本番環境で実証された**: [[UModel]] は 2025 AIOps Challenge データセットで従来データモデル比 LA +8.12・Top-1 Acc +6.52（8% 精度向上）を達成した。これはエージェントの推論能力や学習モデルの改善ではなく、データ組織化（オブジェクト中心モデリング）の改善のみによる成果である。「エージェントに何を見せるか」の制御が「エージェントがどう推論するか」より早い段階で性能を律速するという観察([[AIOps]] の「ツール呼び出し過多が主要失敗モード」と一貫)を、データモデル層から実証した。PaaS 意味的ツール層は IaaS 直接クエリに対して OS +9〜+13 ポイントの RCA 優位を一貫して示す。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §VI, Tables IV-V) > - **PromQL 直接生成精度の構造的限界（<5%）が観測可能性データモデルの重要性を後押しする**: 従来データモデルでは LLM が PromQL を直接生成する精度が 5% 未満にとどまり（GPT-4-Turbo でも約 2.6%）、エージェントが正しい推論ロジックを持っていても正しいデータを取得できない。この限界はデータ取得インターフェースの設計問題であり、LLM の能力向上だけでは解消できない構造的課題である。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §VI-A; [22]) > - **Sillito & Kutomi 2020 が分類した調査戦略の二分法（日和見的/体系的）は、LLM 時代の RCA エージェントの設計原則と対応する**: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] は 30 インシデントの定性分析で、インシデント調査を **日和見的戦略**（典型的原因の確認 / 時間的相関のある異常を探す）と **体系的戦略**（症状の連鎖をたどる / スタックをたどる）に分類した（§IV-C）。実際の調査は多くの場合両者の組み合わせで、日和見的戦略が「インシデントタイムラインの相関付け」で出発点を絞り、そこから体系的調査を継続するというパターンが多い。これは本 wiki が整理してきた LLM エージェントの RCA 設計と対応する: [[Bits AI SRE]] / [[Stratus]] の hypothesis-driven loop は日和見的戦略（仮説→検証の反復）、SRE Book の「スタックをたどる」手法は体系的戦略に対応し、[[AIOpsLab]] が評価する「Tool call を最小限に絞る」という指標は日和見的戦略の効率化として解釈できる。一方、相関を発見しても因果関係を理解できなければ調査が失敗する（観察 8: incidents 1.11, 2.2）という知見は、「相関 ≠ 原因」問題を AIOps エージェントも継承することを示す。(Source: [[@2020__arXiv__Failures and Fixes - A Study of Software System Incident Response]] §IV-C) > - **[[Flexible Skill Arrangement]] による事前コンテキスト制御が「情報を取りすぎる病理」の構造的解法として実証された**: [[Bian Que]] は Skill(LoadDataSchema)により RCA 実行前に取得すべきメトリクス・ログ・変更イベント・知識エントリを明示的に宣言し、エージェントが無差別にテレメトリを取得する問題を設計で排除した。RCA 精度 80%(オンライン本番)・pass@5 = 99.0%(オフライン)を 30B 超 LLM で達成し、「入力選別は RCA の中核」という本 wiki の観察([[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]])を「事前宣言型コンテキスト制御」という新しい機構で実装した事例となる。特に NOKNOW アブレーション(知識取得無効化)で pass@5 が −7.7 pp 落ちた事実は、信号選択に並んで「どの知識を参照するか」の制御も RCA 精度に不可欠であることを示す。(Source: [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]] §2.3, §3.4, Tables 3, 7) > - **RCA エージェントの入力制御は「前処理」「データモデル」「ツール面」の 3 層で収束している**: [[MetricSifter]] はメトリクス前処理で無関係信号を削り、[[UModel]] はオブジェクト中心データモデルで取得対象を構造化し、[[RCAgent]] は SQL/SLS 直接実行を避けて意味的に最小なツールと OBSK で観測量を制御する。RCAgent の SQL/SLS 直接ツール置換は Invalid Rate 70.94% まで悪化し、RCA の失敗が「推論が弱い」だけでなく「環境への入口が広すぎる」ことからも生じると示す。これは [[Bits AI SRE]] / [[AIOpsLab]] のツール呼び出し過多観察と同じ病理を、ツールインターフェース設計のアブレーションとして実証した事例である。(Source: [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]], [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]], [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]]) > - **因果推論ベース RCA の包括評価で「Dummy ベースラインを超えない手法が多い」ことが判明した**: Pham et al.（ASE 2024）が 9 種の因果探索手法と 21 種の RCA 手法を Dummy（ランダム選択）と比較した結果、PC/FCI/Granger/LiNGAM/fGES/NTLR-PageRank・CausalAI・RUN・MicroCause の多くが Dummy と同等以下の精度を示す。一方 BARO・CausalRCA・RCD・CIRCA・NSigma（精確な障害時刻条件下）は安定して Dummy を上回る。Dummy ベースラインを初めて導入したことで、先行研究が「因果グラフ構築 → スコアリング」の組み合わせを過大評価していた可能性が明らかになった。詳細は [[因果推論ベースRCA]]。([[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]]) > - **ノンパラメトリック統計 RCA が因果グラフ手法を上回るには「異常検知時刻への非感度設計」が鍵である**: [[@2024__FSE__BARO - Robust Root Cause Analysis for Microservices via Multivariate Bayesian Online Change Point Detection]](Pham+ FSE 2024)は、RCA 精度が異常検知モジュールの精度に強く依存するという既存手法の構造的脆弱性を指摘する。平均・標準偏差ベースの手法(N-Sigma・CIRCA)は異常検知時刻 $\hat{t}_A$ が遅延するだけで性能が大幅に低下するが(Online Boutique で Avg@5 最大 33〜62% の変動)、中央値・IQR ベースの RobustScorer は変動が 25% に留まる。因果グラフ手法(RCD/CIRCA/CausalRCA)が大規模システム(Train Ticket 64 サービス)で Avg@5 0.07〜0.28 に落ちる一方、BARO は 0.81 を維持した。Pham+ ASE 2024 の「Dummy ベースラインを超えない手法が多い」という観察と合わせると、RCA 精度の律速要因は「アルゴリズムの因果推論能力」ではなく「異常検知時刻への非感度性とスケーラビリティ」にある。(Source: [[@2024__FSE__BARO - Robust Root Cause Analysis for Microservices via Multivariate Bayesian Online Change Point Detection]], §4.6〜4.8, Tables 3-4) > - **二標本検定ベースの教師なし RCA は重尾・高分散の時系列に対してエネルギー距離が Pearson・K-NN・MST を上回る**: [[Huasong Shan]] ほか([[JD.com]], WWW 2019)の ε-Diagnosis は、小ウィンドウ(1 分/1 秒)で集計した P99 レイテンシの重尾・高分散という特性に対し、エネルギー距離相関(ε統計)が α=0.05 で 100% 再現率を達成し、候補メトリクス空間を総メトリクスの約 10% に絞り込むことを実証した。Pearson 相関は「平坦→急上昇」パターンの根本原因メトリクスを検出できず α=0.5 まで拡大しても 100% 再現率に達しなかった。エネルギー距離は分布フリー・スケール不変・回転不変という特性により、訓練データ不要の教師なし設定で重尾データに有効に機能する。(Source: [[@2019__WWW__ε-Diagnosis - Unsupervised and Real-time Diagnosis of Small-window Long-tail Latency in Large-scale Microservice Platforms]]) > - **合成データでの RCA 性能評価は実システムへの転移を保証しない**: Pham et al. で確認済みであり、Fault-Propagation-Aware Benchmark（Fang et al. 2025）による評価見直しとも一致する。合成データ生成器（条件確率変化で障害注入）と実障害（CPU スパイク等の連続変化）の乖離が根因。([[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) > - **「相関 ≠ 因果」は 2004 年から意識された限界で、Soldani & Brogi 2021 より 17 年早く同じ制約を明言した**: [[@2004__OSDI__Correlating Instrumentation Data to System States - A Building Block for Automated Diagnosis]]（Cohen et al., [[Hewlett Packard Labs]], OSDI 2004）は「本手法が発見するのは相関であって因果関係ではない」と論文内で明示的に述べ、「どのメトリクスが SLO 違反と相関するかを示すことは root cause analysis の基盤である」という立場をとる。Soldani & Brogi 2021 が「すべての RCA 手法が相関に基づくが相関は因果を保証しない」と結論する前に、同じ限界が TAN 論文で自覚されていた。また Cohen et al. は「メトリクスを有罪判決するのではなく、無関係メトリクスを無罪放免することが診断の主な価値」とも述べており、関与しないメトリクスの除外（否定的証拠の扱い）が 2004 年から RCA の中核と認識されていた。これは現代の [[MetricSifter]]（無関係メトリクスを削ることで因果探索を助ける）・[[RCA入力選別]]（必要な信号を絞る）と同じ設計思想の先駆けである。(Source: [[@2004__OSDI__Correlating Instrumentation Data to System States - A Building Block for Automated Diagnosis]]) > - **「相関 ≠ 因果」はすべての古典的 RCA 手法が免れない原理的限界であり、偽陰性の主因である**: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]]（Soldani & Brogi 2021）は、26 手法すべてが相関（KPI 相関・PC アルゴリズム・ランダムウォーク・グラフ中心性）を根拠として根本原因を特定するが、**相関は因果を保証しない**ことを明示的に述べる（§4.4.3）。例: あるサービスの KPI がフロントエンドの KPI と高相関でも、第三のサービスが共通原因の場合は偽陽性になる。トポロジグラフ手法でさえ「同一ノードに同居する別サービスがリソースを食い尽くす」ケースを構造的に見逃す。本 wiki の [[MetricSifter]] が「無関係メトリクスを削ることで因果探索を助ける」設計、[[RCAgent]] が「環境への入口を狭く設計する」設計は、この相関バイアスを削減の第一手として実装した事例として読める。LLM-era の RCA が「相関でなく因果推論を」に向かう動機はここに遡る。(Source: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]]) > - **98 論文サーベイで pre-LLM 期 RCL の全手法地図が完成した**: [[Failure Diagnosis in Microservice Systems]](Zhang+ 2024)は 2003〜2024 年の 98 論文を 4 モダリティ × ログ/メトリクス/トレース/マルチモーダルで分類し、マイクロサービス RCA の最初の包括的地図を提供した。メトリクスベース RCL が 63 論文と最多で、うち 38 件がインスタンスレベル、44 件がコンポーネントレベル。マルチモーダルは近年急増しているが総論文数はまだ少ない。本 wiki の [[根本原因分析]] が個別手法から積み上げてきた知見(MonitorRank パターン・PC アルゴリズム + ランダムウォーク・相関 ≠ 因果)がこのサーベイで体系化されている。(Source: [[Failure Diagnosis in Microservice Systems]], §4, Figure 1, Figure 3) > - **移植性の鍵は「論理グラフモジュール」であることが 5 本以上の先行研究で収束した**: Zhang+ 2024 の §5.3 は、特定の呼び出し依存ではなく論理的合意に基づいてグラフを構築する MicroCBR・CloudRCA・TrinityRCL・NetMedic・Sleuth が、異なる環境への展開コストを下げる共通設計を持つと整理する(本 wiki の以前の記述は [130] を T-Rank としていたが、原本の参考文献リストで `[130] Yu Gan et al. 2023. Sleuth: A Trace-Based Root Cause Analysis System` と確認し訂正した)。これは本 wiki が扱う [[RCACopilot]] の「アラートハンドラ = 有向グラフワークフロー」設計と対比できる——RCACopilot が「ドメイン固有の手作業 DAG」で精度を得るのに対し、論理グラフ系は「ドメイン非依存の合意グラフ」で移植性を得る。精度と移植性のトレードオフとして読める。(Source: [[Failure Diagnosis in Microservice Systems]], §5.3) > - **MonitorRank のランダムウォークパターンが後続 RCA 手法の標準設計となった**: Soldani & Brogi 2021（§4.2.3・§4.4.1）は、MonitorRank（Kim et al. 2013）が最初に提案したパーソナライズドランダムウォーク（correlation-proportional な隣接サービス訪問 → 訪問回数でランク付け）を、CloudRanger・MS-Rank・AutoMAP・MicroCause・MicroRCA が再利用・拡張したと整理する。このパターンは「グラフ訪問を軽量に保ちながら、確率的に重み付けされた根本原因ランキングを生成する」点でトレードオフが優れ、PC アルゴリズム（因果グラフ構築）との組み合わせで 6 つ以上の研究が収束した。因果グラフを PC アルゴリズムで構築し → ランダムウォークでランク付けする 2 段構成が pre-LLM era の**古典的 RCA パイプライン**の主流である。本 wiki の [[A Survey of AIOps in the Era of Large Language Models]] が整理する LLM-era の RCA がこのパターンをどう置き換えるかは未整理。(Source: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]]) > - **MonitorRank → CloudRanger → AutoMAP → PyRCA の 10 年間の系譜が一次ソースで確認された**: MonitorRank（Kim+ SIGMETRICS 2013）はサービス依存グラフ上で「異常コンポーネントとの相関に比例した遷移確率」のパーソナライズドランダムウォークを提案し、LinkedIn 400 超サービスで HR@1=0.53 を達成した。CloudRanger（Wang+ CCGrid 2018）は PC アルゴリズムによる因果グラフ構築 + 二次ランダムウォーク（異常相関 + 相関変化量の 2 軸）で MonitorRank を拡張し PR@3=0.946。AutoMAP（Ma+ WWW 2020）は異常行動グラフ + 前方・自己・後方の 3 種ランダムウォークで依存方向を動的に使い分ける。FluxRank（Liu+ ISSRE 2019）はマシンレベル RCA に特化し「異常検知→特徴選択→相関ランキング」の 3 段を Baidu に本番展開した。PyRCA（Liu+ arXiv 2023）がこの系譜を統合ライブラリ化し、PC/GES/FGES/LiNGAM + PageRank/ε-Diagnosis/BARO を一つの API で提供する。10 年間で「ランダムウォークの遷移確率をどう設計するか」が手法の核であり続けた。(Source: [[@2013__SIGMETRICS__Root Cause Detection in a Service-Oriented Architecture]], [[@2018__CCGrid__CloudRanger - Root Cause Identification for Cloud Native Systems]], [[@2020__WWW__AutoMAP - Diagnose Your Microservice-based Web Applications Automatically]], [[@2019__ISSRE__FluxRank - A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation]], [[@2023__arXiv__PyRCA - A Library for Metric-based Root Cause Analysis]]) > - **有向性推定を捨てた FluxInfer が PC 系 8 手法を上回ったことは「辺方向推定がボトルネック」の直接的解答の一つである**: FluxInfer（Liu+ IPCCC 2020）は DB メトリクス間の依存を重み付き無向グラフ（WUDG）として構築し PageRank でスコアリングする。有向 DAG を推定する PC 系 8 手法（PC/Granger/NOTEARS 等）を AC@3 で 2〜15 倍上回った。Pham+ ASE 2024 が「辺方向推定が全手法の共通ボトルネック」と指摘した問題に対し、FluxInfer は「方向を推定しない」という設計転換で精度を得た事例。ただし無向グラフは因果的介入の解釈を放棄するため、CIRCA/RCD のような因果推論的説明可能性とはトレードオフ関係にある。(Source: [[@2020__IPCCC__FluxInfer - Automatic Diagnosis of Performance Anomaly for Online Database System]], [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]]) > - **説明可能性と対策推奨は 2021 年から未解決の共通課題であり、LLM-era RCA が目指す先**: Soldani & Brogi 2021（§4.4.4・§6）は、根本原因に「なぜその原因か」の説明を付与すること（explainability）と、「同じ障害が再び起きないための対策を推奨すること」（countermeasures）を明示的なオープン課題として挙げる。これは 5 年後の本 wiki の流れ——[[AIOpsLab]] の「telemetry tool call 過多が主要失敗モード」観察・[[Bits AI SRE]] の仮説主導型調査・[[UModel]] の説明可能データモデル——がいずれも「運用者が根本原因の真偽を絞り込める説明」を目標にしている構図と直接接続する。説明可能 RCA は pre-LLM でも課題だったが、LLM の自然言語生成がその具体的な実装経路になった点が新しい。(Source: [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]], [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]]) > - **マイクロサービス RCA の古典的手法地図は「機械学習・グラフ・統計」に収束するが、評価の共通土台はまだ弱い**: [[Anomaly detection and root-cause identification in microservices]] は、根本原因特定を機械学習、グラフベース、統計手法に整理し、機械学習系を precision 94.9% / recall 98.0% / F1 99.0%、グラフベースを precision 92.7% / recall 89.7%、統計手法を precision 85.0% / recall 88.0% / F1 85.8% と集計する(§4.7)。しかし同論文は、データセット・テストベッド・指標の不均一性が直接比較を難しくするとも述べる。これは [[RCA評価設計]] が扱う「SimpleRCA が既存ベンチで SOTA に近づく」問題と接続し、RCA の進歩はモデル選択だけでなく、故障伝播を正しく含む評価基盤に依存することを再確認する。(Source: [[Anomaly detection and root-cause identification in microservices]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) > - **トポロジグラフ系 RCL では入力表現の不正確さ(AmSit)がモデルではなくデータ品質から精度を損なう**: [[@2023__WWW__CMDiagnostor - An Ambiguity-Aware Root Cause Localization Approach Based on Call Metric Data|CMDiagnostor]]([[@2023__WWW__CMDiagnostor - An Ambiguity-Aware Root Cause Localization Approach Based on Call Metric Data]], WWW 2023)は、分単位集計の CMD からコールグラフを構築する際に生じる「曖昧性(AmSit: ノードが複数上流と少なくとも 1 下流を持つ場合、下流の実際の親が特定できない)」が既存 4 手法で完全に無視されていたと指摘する。因果グラフ系(Microscope/AutoMap)の低精度はアルゴリズムの非効率だけでなく「誤ったグラフ入力」にも起因する可能性がある。AmSit を解消する AmSitor(回帰ベース)を追加するだけで因果グラフ手法の HR@5 が改善し(Microscope: 0.68→0.69、AutoMap: 0.78→0.82)、トポロジ手法はさらに大きく改善する(MicroHECL: 0.80→0.89)。「RCA の精度限界がアルゴリズムにあるかデータ表現にあるか」を区別する実験設計の重要性を示す事例。(Source: [[@2023__WWW__CMDiagnostor - An Ambiguity-Aware Root Cause Localization Approach Based on Call Metric Data]], Table 8) > > - **実本番ポストモーテム分析が「設定ミス単独支配」という根本原因分布の構造を三大クラウドで確認した**: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]](Li+ 2022)は AWS・Azure・Google Cloud の 354 件から、内部原因・外部原因の 2 層構造をとる根本原因分類(Table IV)を導出した。設定ミス(31.6%)が内部原因の筆頭、ハードウェア障害(17.0%)が外部原因の筆頭であり、不明が 12.1% 残る。この「不明が 1 割以上」という事実は、RCA ツールが現実の障害で正解を得られない比率の下限を示す一方、「そもそも根本原因が特定できなかった事例は記録から落ちやすい」という観測バイアスも示唆する。23.2% の障害が複数根本原因を持つことも、単一根本原因を前提にしたベンチマーク設計[[RCA評価設計]]の限界と接続する。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) > > - **2022 年の因果推論ベース RCA(CIRCA・RCD)と 2024 年の LLM ベース RCA(RCACopilot)は、ドメイン知識依存・スケーラビリティ・本番実績の 3 軸で対比される**: CIRCA([[@2022__KDD__Causal Inference-Based Root Cause Analysis for Online Service Systems with Intervention Recognition]])はアーキテクチャ知識(コールグラフ + ゴールデンシグナル分類)を**強く必要とし**、Oracle DB 99 件で AC@1=0.404 を達成する。RCD([[@2022__NeurIPS__Root Cause Analysis of Failures in Microservices through Causal Discovery]])は**ドメイン知識を捨てて** Ψ-PC + 階層分割統治で 500 ノード 22 秒のスケーラビリティを得るが、本番 AWS 3 ケースの少数評価にとどまる。RCACopilot([[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]])は LLM の言語理解と OCE が構築するアラート種別ハンドラ(ドメイン知識を**人手の DAG ワークフロー**として表現)を組み合わせ、Microsoft 30 超チーム・4 年以上の本番実績で Micro-F1=0.766 を達成し、3 系統の中で唯一の大規模本番稼働システムとなる。3 者の対比から、RCA 研究は「形式化された因果モデル(CIRCA/RCD) → 経験的なハンドラ + LLM(RCACopilot)」へ重心が移りつつあり、本番運用での実用性は形式論より経験的ハンドラ + LLM 圧縮が先行している構図が見える。[[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]] が CIRCA/RCD の包括評価で「Dummy を超える手法は少ない」と指摘した不安は、RCACopilot 系の本番実績によって部分的に解消される一方、ハンドラ構築工数(OCE 依存)が新たな運用律速として浮上する。(Source: [[@2022__KDD__Causal Inference-Based Root Cause Analysis for Online Service Systems with Intervention Recognition]], [[@2022__NeurIPS__Root Cause Analysis of Failures in Microservices through Causal Discovery]], [[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]], [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]]) > > - **非集計(dis-aggregated)トレースはランキングベース RCA において集計トレース系手法が見逃す部分的・断続的障害を検知できる**: [[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems|TraceRank]]([[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]], JSEP 2021)は、集計済みトレース(サービスごとの平均レイテンシ等)を使う MicroRCA・Automap・MS-Rank が部分的・断続的障害で正常と異常の平均化により根本原因を見逃す問題を指摘し、個別リクエストを「テストケース」と見立てた SBFL の Ochiai 式スペクトル解析と、処理時間相関に基づくパーソナライズドPageRankランダムウォークの 2 段補完で対処する。TrainTicket・BookInfo・実世界データセット(AIOps Challenge 2020、China Mobile)で Precision 90%・Recall 86%、12 のベースライン比で最大 +10% 改善。重要な知見は「スペクトル解析が同スコアになる密結合サービスのケース(T-Rank での失敗モード)をPageRankが補完できる」という役割分担の明示——これはMonitorRankが確立したパーソナライズドランダムウォークの遷移設計に「スペクトルスコアでキャリブレーションする」層を追加した系譜の拡張として読める。さらに「アクセスレイテンシでなく処理時間(process time)を相関の入力とする」ことで、下流サービスから伝播した遅延を除去し各サービスの健全状態をより正確に表現する設計は、CloudRanger・AutoMAP等が伝播グラフ上で「どこを辿るか」の設計を工夫してきたのとは異なる「何を計測するか」の工夫として対比される。計装オーバーヘッド CPU 2% 以下・RCA 計算 500ms 以下という実時間性も本番適用の根拠を与える。(Source: [[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]]) > > - **根本原因と緩和手段の強相関が「自動緩和推薦器」の実装可能性を示す**: Li+ 2022 は根本原因と緩和手段の関係をヒートマップで分析し、設定ミス→ロールバック(51 件)・設定ミス→リプレースメント(48 件)、ハードウェア障害→リプレースメント(29 件)・ハードウェア障害→フィックス(54 件)と強相関が確認できる一方、リソース競合・例外ハンドリングは均一に複数の緩和手段が適用され、「特定の根本原因に特定の緩和手段が対応する」という単純な規則が成立しないことも示した(Finding 10)。RCA の「なぜこれが根本原因か」の説明(Soldani & Brogi 2021 のオープン課題)が得られれば、強相関を利用した自動緩和推薦は実装可能な近傍問題として成立する。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) > > - **ログクラスタリング + 知識ベースという「圧縮してから照合する」RCA 補助パターンが 2016 年時点で産業規模で実証された**: [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems|LogCluster]]([[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]], ICSE Companion 2016)は、IDF と対比重み付けを組み合わせたベクトル化 → 凝集型階層クラスタリング → 代表系列抽出 → 知識ベース照合(再発なら緩和策を即返却、新規なら人手確認)という 4 段フローで、Microsoft 実サービスの生ログ 10 百万件を調査対象 40 件に圧縮した。ログ重大度レベルが問題診断の手がかりとして不十分(高重大度ログの 10% 未満しか実際の障害に関係せず、30% 超の障害が INFO レベルに起因)という観察は、本 wiki の [[L4]] が 2025 年に確認した「3 指標(ログレベル・頻度・エラー意味)が障害ログを弁別できない」という知見の 10 年前の先行事例である。「知識ベースに蓄積して再発を識別する」パターンは [[L4]] の fault library・[[AlertGuardian]] の RAG 知識ベースと同型で、「圧縮してから知識照合で既知/新規を振り分ける」構造が 2013 年以来 Microsoft 4 製品チームで本番稼働したことは、現代 LLM ベース RCA の知識再利用パターンに先行する産業実証として位置づけられる。(Source: [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]]) > > - **マルチモーダルオブザーバビリティデータを均質なイベント表現に変換し、コード領域・リソースタイプレベルの根本原因を特定する**: [[@2023__ESEC-FSE__Nezha - Interpretable Fine-Grained Root Causes Analysis for Microservices on Multi-modal Observability Data|Nezha]]([[@2023__ESEC-FSE__Nezha - Interpretable Fine-Grained Root Causes Analysis for Microservices on Multi-modal Observability Data]], ESEC/FSE 2023)は、メトリクス・トレース・ログを共通のイベント表現へ変換し、イベントグラフの構築とマイニングでパターンを抽出する。障害のない期間と障害の起きた期間のパターン比較で、サービスレベルにとどまらず**コード領域とリソースタイプ**まで根本原因を絞り込む。Top-1 精度 89.77% は単一モダリティ手法を大幅に上回る。TraceRank が「何を計測するか(処理時間)」の工夫で集計トレース系を超えたのに対し、Nezha は「どのデータを組み合わせるか(3 モダリティ)」の統合で粒度を引き上げた。(Source: [[@2023__ESEC-FSE__Nezha - Interpretable Fine-Grained Root Causes Analysis for Microservices on Multi-modal Observability Data]]) > - **異常検知と根本原因箇所特定を一体化したエンドツーエンドフレームワークは、検知誤差の箇所特定への伝播を防ぐ**: [[@2023__arXiv__Eadro - An End-to-End Troubleshooting Framework for Microservices on Multi-source Data|Eadro]]([[@2023__arXiv__Eadro - An End-to-End Troubleshooting Framework for Microservices on Multi-source Data]], arXiv 2023)は、既存手法が異常検知と箇所特定を独立に扱い検知の不正確さが箇所特定を深刻に劣化させる問題を指摘する。トレース・ログ・KPI のマルチソースデータからサービス内行動とサービス間依存をモデル化し、検知と箇所特定を統合する。BARO が「異常検知時刻のずれへの非感度設計」で頑強性を得たのとは別のアプローチ——検知自体を改善して下流への誤差伝播を防ぐ——であり、Nezha の「マルチモーダル統合」と Eadro の「検知-箇所特定統合」は直交する設計軸として両立しうる。(Source: [[@2023__arXiv__Eadro - An End-to-End Troubleshooting Framework for Microservices on Multi-source Data]]) > > - **RCA の問題定義の断片化が手法の汎化を阻む構造的問題として確認され、3 次元統一定式化が提案された**: [[@2024__TSC__Holistic Root Cause Analysis for Failures in Cloud-Native Systems Through Observability Data|HolisticRCA]]([[@2024__TSC__Holistic Root Cause Analysis for Failures in Cloud-Native Systems Through Observability Data]], TSC 2024)は、先行手法が「メトリクス箇所特定」「ログ障害種別」「エンティティ箇所特定」「障害種別分類」のいずれか一つを根本原因として定義していたため、異なる定義の手法を組み合わせると矛盾する結果が生じる問題を指摘する。解決策として「リソースエンティティ箇所特定(場所)・オブザーバビリティ特徴識別(詳細)・障害種別分類(知識)」の 3 次元を同時に解く統一フレームワークを構築し、TSC 2024 の 3 公開データセットでこれまでの手法(Nezha・Eadro・DiagFusion)を上回った。問題定義の断片化は本 wiki の [[マルチモーダル障害診断]] で TVDiag が観察した「等価融合による情報希釈」とは異なる設計失敗パターン——融合方法ではなく「何を正解とするか」という評価定義そのものが複数の不整合な視点に割れていたことが原因。(Source: [[@2024__TSC__Holistic Root Cause Analysis for Failures in Cloud-Native Systems Through Observability Data]], §II-A, §III) > > - **「ビルディングブロック組み立て」戦略は異種エンティティ間の特徴次元差異を共通ベクトル空間で解消し、均質システム前提を廃する**: HolisticRCA は各オブザーバビリティ特徴を独立した $\lambda$ 次元埋め込みに変換(ブロック部品化)し、同一種別エンティティの埋め込みを結合して $\nu$ 次元エンティティ表現を生成(ブロック組み立て)する。これにより $(n_{re}, n_f, n_d)$ の均質行列を前提とした既存手法が抱える「エンティティ種別ごとに独立モデルを作ると種別間の絡み合い関係を失う」問題を回避した。DiagFusion の 3 シグマ変換が「CPU 障害」と「CPU 緩やかな上昇」を同一イベントに潰してしまう細粒度情報の喪失問題は、この「ブロック部品化」が変換なしに特徴を保持することで回避する。(Source: [[@2024__TSC__Holistic Root Cause Analysis for Failures in Cloud-Native Systems Through Observability Data]], §IV-A〜C) > > - **2021〜2024 年のマイクロサービス AI アシスタント SLR で RCA は異常検知に次ぐ第 2 位の目標(35.5%)**: [[Dahlia Ziqi Zhou]]・[[Marios Fokaefs]]([[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]])の SLR は、31 件の一次研究のうち 11 件(35.5%)が RCA を主目標とすると分類した。Contain フェーズ(35.4%)に集中しており、グラフベース手法(Groot・Mulan)・過去インシデント活用(Zhang+・Wang+)・LLM エージェント([[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture|mABC]]・[[RCAgent]])が代表的ツールとして引用される。ログ(48.4%)・トレース(29%)・メトリクス(25.8%)に加え、過去インシデントレポート・依存グラフ・コードリポジトリなど非伝統的データソースの活用が RCA 精度向上の将来機会として特定された。なお mABC([[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]])は SLR 内でユーザースタディを実施した 5 件の一つ([24])として引用されており、本 wiki の LLM ベース RCA の蓄積と一致する。(Source: [[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]] RQ2・RQ4) > > - **「根本原因」という概念の社会的構成性と AIOps の緊張**: [[複雑システム障害論]] 命題 7 は「根本原因帰属は技術的理解ではなく、特定の原因に責任を帰属させる社会的・文化的必要性を反映する」と 1998 年に指摘した（[[@1998__CtL__How Complex Systems Fail]]）。AIOps・SRE 分野では 2020 年代もこの用語が標準として使われ続けているが、Cook の批判は「RCA を廃止せよ」ではなく「単一原因思考から脱却し、複数寄与因子のネットワークを同定せよ」というメッセージとして読み直せる。HolisticRCA の 3 次元定式化（場所・詳細・知識）、JustDiag の仮説競合裁定、mABC の多エージェント投票はすべてこの「複数寄与因子の同定」への移行の具体化として位置づけられる。(Source: [[@1998__CtL__How Complex Systems Fail]] 命題 7, [[@2024__TSC__Holistic Root Cause Analysis for Failures in Cloud-Native Systems Through Observability Data]], [[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]]) > > - **分割統治型の因果グラフ分解(HybridRCA)は $O(2^N)$ の計算量を $O(\sum_i 2^{n_i})$ に削減し、本番準リアルタイム RCA を実現した**: AutoDebugger の HybridRCA は、因果グラフ上で「顕著ノード(親ノードへの寄与を兄弟から独立して分離できるノード)」を軸にグラフをサブグラフへ分解し、各サブグラフに独立した RCA を実行して帰属スコアをスケーリング規則で合成する。40 変数超の Microsoft Fabric Spark ジョブにおいて従来の do-calculus 手法(147 秒/ジョブ)に対して 12 秒/ジョブを達成(約 12 倍)し、根本原因ランキングの平均誤差 0.4%・最大絶対誤差 5% で精度を保持した。FluxInfer([[根本原因分析]] の有向性推定を捨てて PC 系を上回った事例)とは対照的に、HybridRCA はグラフ構造を保持しつつ分解する点が異なる。ただし因果グラフ自体はドメイン知識による手動構築であり、将来の自動構築(NOTEARS/FCI)との統合は課題として残る。(Source: [[@2025__AIDB__AutoDebugger - Efficient Root Cause Analysis for Anomaly Jobs]]) > - **「宣言的仮説列挙 → スコアリング → 人間フィードバック」の反復ループが 4 年間 44 インシデントで実証された最古の産業 RCA エンジンの一つ**: ExplainIt!([[@2019__SIGMOD__ExplainIt! - A Declarative Root-cause Analysis Engine for Time Series Data]], SIGMOD 2019)は、SQL で仮説空間を宣言し PGM の部分的構造探索としてスコアリングする設計で、2014 年以来 [[Cisco Tetration Analytics]] の本番製品デバッグに使用された。44 件中 31 件を数十分以内に解決し、13 件は「監視データ不足」で診断不能と正直に報告した。これは「限定観測可能性が RCA の律速」という本 wiki の観察([[根本原因分析]] 未解決の問い)の早期実証事例である。単一スコアリング手法が全シナリオで最良とはならないという評価結果(CorrMax vs L2-P50 の相補性)は、先行する [[@2020__IPCCC__FluxInfer - Automatic Diagnosis of Performance Anomaly for Online Database System|FluxInfer]] の「有向性推定を捨てて無向グラフに移行」や [[@2024__FSE__BARO - Robust Root Cause Analysis for Microservices via Multivariate Bayesian Online Change Point Detection|BARO]] の「異常検知時刻への非感度設計」が個別に示した「手法に普遍的優位はない」という繰り返す観察とも一致する。(Source: [[@2019__SIGMOD__ExplainIt! - A Declarative Root-cause Analysis Engine for Time Series Data]] §5, §6) > - **分散データプラットフォームの RCA では「論理・物理の 2 層トポロジ統合」と IDF 型アラームスコアリングの組み合わせが偽陽性を低減する**: Grano([[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]], VLDB 2019 Demo)は [[eBay]] の [[NuData]](地理分散 NoSQL、1 スクレイプインターバル 2000 万メトリクス)に対し、Keyspace/Shard/Replica の論理階層と Zone/Rack/Host/Pod の物理階層を統合した異常グラフを構築し、IDF 型アラームエッジスコアリング + 信頼度スコア伝播で根本原因関連度(RCR)を算出する。MonitorRank → CloudRanger → AutoMAP の「ランダムウォーク型伝播」に対する「決定論的スコア伝播型」の別実装として位置づく。最大の特色は物理層(Pod が共存する Host まで)を含む点で、「同一インフラ上の別コンポーネントが根本原因」という障害クラスへの対応を可能にした。本番展開で根本原因特定を数時間から数分に短縮したことを示した。(Source: [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]] §2, §3; 詳細は [[グラフベースRCA]]) > > - **クラウドインフラ(物理デバイス層)の RCA では「上位 k 根本原因ランキング」だけでなく「障害伝播パス」が現場運用に必須**: BSODiag(Duan+ arXiv 2025)の実証分析は、現場エンジニア(OSE)が根本原因(電源障害)の修復だけでなく伝播経路上の老朽 PSW も発見・修復しなければならないことを示した。上位 k 件を返すだけの従来手法はこの要件を満たさず、「解釈可能な診断結果 = 根本原因 + 伝播パス」が物理インフラ障害診断の本質的な出力仕様である。BSODiag は最高累積伝播確率パスを PPI(Propagation Probability-based Path Inference)で推論し、PCR 46.3% を達成した。マイクロサービス RCA が「サービス依存グラフ上の根本原因ノード特定」を主眼とするのに対し、物理インフラ RCA は「物理デバイスの修復順序を規定するパス推論」が不可欠という問題設定の違いが浮き彫りになった。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §II-C RQ3, §IV-C3, §V-B 表IV; 詳細は [[クラウドインフラ障害診断]]) > - **クラウドインフラの粗粒度監視データ RCA は「マイクロサービスと異なる入力制約」として独立した問題設定を必要とする**: BSODiag は、マイクロサービス RCA が前提とする細粒度メトリクス・ログ・トレースがクラウドインフラでは収集できないという実証的観察(表I: 6 障害種別のうち単一ソースで全種捕捉不可能)から出発する。この「粗粒度制約」はアルゴリズム設計だけでなく問題定義そのものを変える。既存のマイクロサービス向け RCA 手法(AirAlert・COT を含む)を物理インフラに適用するとデータ形式の根本的不適合が生じ、BSODiag が COT に PR@3 で +10.2% 差をつけた主要因はデータ制約の正しい認識にある。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §I, §II-B, §V-B) > - **「ビジュアルアナリティクス(VA)+ 知識グラフ + BCPD」の組み合わせが手動 RCA の 3 大ペインポイントを系統的に解消した最初の産業研究**: RCInvestigator([[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]], TVCG 2026)は、知識グラフブループリントによるデータ収集の自動化(P1)、BCPD 変化点整合度ベースの手がかりスコアリングと 5 方向仮説インタラクションによる推論支援(P2)、調査ボードの canvas エクスポートによる共有可能サマリー生成(P3)という 3 層解消を実現した。1000 系列のテストで Precision/Recall = 0.94/0.93(純相関ベースライン 0.80/0.79 に対して +0.14/+0.14)。本 wiki の「RCA は全データ要約ではなく仮説と証拠の反復」「入力選別は RCA の中核」という観察([[仮説駆動RCA]]・[[RCA入力選別]])を、VIS 論文として具体化した事例である。(Source: [[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]] §5, §6) > > - **Google の実践的根本原因カテゴリ分類は学術手法が前提とする「障害注入モデル」と異なる分布を持ち、Third Party Systems・Config・Mother Nature が主要カテゴリに含まれる**: [[Sue Lueder]]（[[Google]] SRE Program Manager）が SREcon 2015 で公開した 9 カテゴリ分類体系（Capacity/Deployment Planning/Software/Workflow/Network Failure/Third Party Systems/Config/Mother Nature/Hardware）は、Network Failure と Third Party Systems が最高頻度であることを示した（全データ捏造と明記）。Li+ 2022 の三大クラウドポストモーテム分析（設定ミス 31.6% が最多）や [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] のオペレータエラー支配と比べると、Google の分類では「Config」と「Workflow（人的プロセス：コミュニケーション/要件誤解/コードレビュー見落とし/フェイルセーフ欠如）」が独立カテゴリとして分離されており、学術ベンチマークが障害注入で覆う Infrastructure Issue とコードバグ中心の評価と実運用の分布乖離をあらためて示す。また、根本原因の深さ問題（「なぜ 5 回」を何回まで掘るか）、カテゴリ整合性問題（チーム間の分類一貫性）、「ヒューマンエラー」の扱い（Ishikawa Fishbone で Root の Root を特定することの難しさ）が 2015 年時点でもオープン課題だったと明言している。(Source: [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]], p.15, p.16, p.17) > > - **X-lifecycle データ補完は LLM RCA において「インシデントメタデータ単独」という siloed view を超えるが、タスクへの意味的適合が前提**: [[@2024__FSE__X-lifecycle Learning for Cloud Incident Management using LLMs]](Goel+ FSE 2024)は Microsoft IC3(Teams バックエンド、250M+ ユーザー)の 353 インシデント・260 モニタで、SDLC の複数段階にわたるデータ（サービス依存関係・機能説明）を LLM プロンプトに補完する X-lifecycle アプローチを実証した。依存サービス障害インシデントでは InC DEP（インコンテキスト例 5 件 + 上流サービス説明）が BLEU +5〜38%・NUBIA +54.67% を達成した。しかし「DEP 単体（例なし）はインコンテキスト例なしでは効果なし（むしろわずかに低下）」という観察は、単に情報を増やすだけでは不十分で、追加情報とタスクの意味的適合と推論誘導手段（インコンテキスト例）の組み合わせが必要という条件を示す。これは本 wiki が整理してきた「入力選別は RCA の中核」([[RCA入力選別]])・「環境への入口を狭く設計する」([[RCAgent]])・「事前宣言型コンテキスト制御」([[Bian Que]])といった「何を渡すか」問題の別実証として位置づけられる。SDLC の情報源とタスクの適合性を選択する設計が次の研究課題として浮上する。(Source: [[@2024__FSE__X-lifecycle Learning for Cloud Incident Management using LLMs]]) > > - **ハイパースケール(20万超サービス)では「探索空間の事前圧縮」がすべての手法の前提条件になる**: KRCA([[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]])が快手の本番環境(20万超サービス、1日4億人ユーザー)で示したのは、障害発生時に最大1万サービスが連鎖的に影響を受ける状況では、既存の RCA 手法(深層学習・LLM 単独)が設計前提として採用している「手に届く規模の候補集合」が成立しないという点である。API レベルドリルダウンによって候補を3サービスに絞り込む段階がなければ、その後の因果発見や LLM 推論の精度がどれほど高くても「実行できない」という実行可能性の問題が先行する。既存の研究(Nezha・BARO・HolisticRCA・mABC)は~64 サービス規模を対象としており、「探索空間の圧縮」は研究の前提として扱われていなかった。ハイパースケールにスケールするには「圧縮メカニズム」の設計が RCA アーキテクチャの最前段に必要である。(Source: [[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]] §2, §3.2; [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]]) > > - **時系列統計による因果発見の精度劣化は 20 メトリクス以上で実証されており、「メトリクス意味情報を構造的事前知識として先に確定する」設計に収束しつつある**: KRCA の実証研究では PC 法と Granger 因果アルゴリズムを快手本番の実インシデントに適用し、異常メトリクス数が5の時点で精度50%、20になると20%以下に急落することを確認した。同じ観察は [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]](Pham+ ASE 2024)でも「PC/Granger を含む多くの因果推論手法が Dummy を超えない」として報告されており、両者の出典が独立に収束する。KRCA のスケルトングラフ(4種のメタメトリクス型 E/I/D/K とその方向性)は、時系列から方向を統計推定する代わりに「サービス設計の意味情報から方向を先に確定する」設計であり、FluxInfer が「有向性推定を捨てて無向グラフに移行」した選択とは異なるが同じ問題(辺方向推定がボトルネック)への別回答として位置づけられる。(Source: [[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]] §2.2, §3.3, Fig.2(b); [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]]) > > - **LagRCA(FSE Companion '26)は「原因と症状の時間的整列」を RCA アーキテクチャの明示的な設計対象とした——KRCA の「探索空間の事前圧縮」とは異なる軸のスケーラビリティ課題を提起する**: KRCA がハイパースケール(20万超サービス)で「候補集合の空間的圧縮」を前段に必要としたのに対し([[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]])、LagRCA は D1(46 インスタンス・本番銀行データ)の実インシデント分析で最大伝播ラグ Δt_max が 2 分以上の非同期伝播を示すインシデントが 81.5%を占めることを定量化し、「時間軸の整合」を診断精度を左右する独立した設計変数として扱った。両者はスケール(空間)とラグ(時間)という異なる軸で「既存手法が暗黙に仮定する前提が本番では成立しない」ことを実証しており、本番 RCA には空間的圧縮と時間的整列の両方が必要という補完的な知見を提供する。(Source: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]], [[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]]) > > - **カーネルパニックという単一障害ドメインを「スパース性 + 長距離依存」の 2 課題として定式化し、選別段とグラフ推論段のアブレーションを分離した LogSage は、本 concept の「情報選別」「グラフベース推論」という 2 つの横断テーマがドメイン特化 RCA でどう組み合わさるかを示す事例である**: LogSage([[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]], FCS 2025)は、[[ByteDance]] の大規模クラウド基盤における OS カーネルパニックの RCA を、少数の障害指示ログの抽出(教師なしクラスタリング + LLM 要約、FILE)とログ間の長距離依存(GraphSAGE + 能動学習、GARCA)の 2 課題として定式化し、ByteDance 本番 20,000 件を含む 3 データセットで F1=92.2%/95.3%/96.3% を達成、最強ベースライン LogKG を 15.5〜20.3 ポイント上回った。本 concept が繰り返し観察してきた「情報を絞ってから推論する」骨格([[RCA入力選別]])と「グラフ上で伝播・推論する」骨格([[グラフベースRCA]])が、単一システムの 2 段パイプラインとして明示的に分離・アブレーションされた点が特徴で、選別段(FILE、w/o→No LLM→Full で F1 +32.1pt)とグラフ推論段(GARCA、w/o→BERT→Full で F1 +25.5pt)のどちらもほぼ同等の寄与を持つことが定量化された。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §4.4) > - **能動学習によるラベル効率化(6% ラベルで頭打ち)は、本 concept が繰り返し指摘してきた「限定観測可能性・ラベリングコスト」問題への実務的回答の一つである**: LogSage の GARCA は初期 1% のランダムラベルから開始し、5 ラウンドの能動学習(各ラウンドでエントロピーベースの不確実性サンプリングにより最も不確実な 1% を追加)で最終ラベル比率わずか 6% に到達、4〜5 ラウンドで性能がほぼ頭打ちになることを確認した。ExplainIt! が「限定観測可能性が RCA の律速」であることを 4 年間の産業実証で示した([[@2019__SIGMOD__ExplainIt! - A Declarative Root-cause Analysis Engine for Time Series Data]])のと対をなし、LogSage は「教師ラベルの希少性」という別の制約に対して能動学習という具体的な緩和策を提示する事例である。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §3.2.2, §4.5.2) > > - **「コンピュータエラー」という表層的帰属は、現代の AIOps 以前から根本原因調査を止める典型パターンとして観察されてきた**: Apollo 11(1969)の 1201/1202 プログラムアラームと LM-1 のエンジン誤停止は、当時のメディアにより「コンピュータエラー」「チェックリストエラー」と片付けられたが、実際の根本原因はいずれもインターフェース仕様文書(ICD)の記載漏れ・未更新という異なる層にあった(→ [[インターフェース仕様の齟齬による障害]])。本 concept が扱う現代の RCA システムが自動化しようとしている「表層的な原因への性急な収束を避け、深い層の原因まで遡る」という要求は、半世紀以上前から人間の調査者が経験的に直面してきた課題であることを示す。(Source: [[@2004__AAS__Tales from the Lunar Module Guidance Computer]]) > > - **多次元根本原因箇所特定研究の代表的ベンチマークデータセット B は、合成障害・匿名化属性という制約を明示した上で公開された一次データ源であり、本 concept が扱う複数の RCA 論文がこれを再利用してきた**: [[@2022__ESEC FSE__Constructing Large-Scale Real-World Benchmark Datasets for AIOps]](Li+, ESEC/FSE 2022 Industry Track)は、[[Suning]] の実世界オンラインショッピングプラットフォームに基づき、5 属性を匿名化(i, e, c, p, l)した上で 400 件の合成障害(GRE によるランダム改変 + ガウスノイズ)を生成した dataset B を公開し、2019 年の AIOps Challenge(141 チーム、最良 F1=0.9593)で用いた。著者ら自身が「ground-truth 付き実障害の大量収集が困難」という理由で合成障害を選んだと明示しており、[[Squeeze]] [24] が用いる B0〜B4 は同一原データ・ほぼ同一の合成プロセスに基づく。本 concept が繰り返し観察してきた「限定観測可能性・ラベリングコスト」問題(LogSage の能動学習等)の裏側には、そもそもベンチマークデータセット自体が実障害でなく合成障害で構成されているという制約があり、多次元 RCA 手法の評価値(F1・top-k 精度)を解釈する際はこの前提を踏まえる必要がある。(Source: [[@2022__ESEC FSE__Constructing Large-Scale Real-World Benchmark Datasets for AIOps]]) > > - **「根本原因」から「一因」への言い換えは、Cook(1998)を直接引用しつつ SRE 実務者向け入門書という別の層で 2024 年に再表明された**: [[David N. Blank-Edelman]] は『SREをはじめよう』10章で、「根本原因」でなく「一因(contributing factor)」を語ることは単なる言い換えでなく視点と枠組みの転換であり、単一原因を追い求める行動を促す「根本原因」のデフォルト使用が「なぜなぜ分析」のようなアンチパターンにつながると論じた。なぜなぜ分析の例として「ログファイルが大きくなりすぎた→なぜ？→ログローテーション機構が設定ファイルから漏れていた」という因果の連鎖を示し、「システム上の何がディスクを埋め尽くすほどのログデータを送信していたのか」という並行して問うべき問いを完全に飛ばしていると批判する。これは de Vesine の「5 Whys のトリガーホワックアモール」批判(判断基準なしに Why を重ねるとスコープ外の原因に着地する)と同型の失敗モードを、より初学者向けの平易な事例で示したものであり、Gallego・Nash・Cook と続く「根本原因概念への懐疑」の系譜に、書籍という媒体で新たな独立の合流点を加える。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 10 失敗から学習する]] §10.1, [[@1998__CtL__How Complex Systems Fail]]) > > - **CSE の動機付け事例(リトライポリシー誤帰属)は、本 concept が繰り返し記録してきた「根本原因概念への懐疑」の系譜(Cook・Gallego・Nash・de Vesine・CAST)に、"介入と交絡因子の記録の欠如"という具体的なエンジニアリング上の欠陥を追加する**: これまで本 concept に蓄積された懐疑論は、いずれも「単一の根本原因という概念そのものが社会的・認識論的に構築物である」という組織論・安全工学的な批判だった(Cook の命題7、Gallego・Nash の「根本原因という用語を捨てよ」、de Vesine の「脆弱性/トリガー」再定義、CAST の遠位要因析出)。[[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]] のリトライポリシー事例(レイテンシ改善をリトライポリシー変更に誤帰属したが、実際は並行するオートスケーリングとトラフィックシフトが交絡因子だった)は、この懐疑を「なぜ誤帰属が起きるか」という技術的な機構——交絡因子が介入ログに記録されず、相関ベースの AIOps ダッシュボードがそれを見逃す——にまで具体化する。CAST が組織的・社会技術的要因の欠落を指摘するのに対し、CSE は「交絡因子の非記録」という、より狭いが自動化可能な欠落に焦点を当てる点で対比的である。(Source: [[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]]) > > - **根本原因箇所特定における公平性(fairness)は、AIOps 研究全体でほぼ手つかずの信頼性要件として明示的に指摘されている**: [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]](Xin+, ACM Comput. Surv. 2025)は、異常検知ではコスト考慮学習による公平性研究が一定数存在するのに対し、根本原因箇所特定では公平性を扱う研究がほとんど見当たらないと明示的に指摘する(§4「Robust and fair fine-grained root cause localization」)。同サーベイはロバスト性を ripple effect(Squeeze・PSqueeze 等の波及効果モデリング)、説明可能性を因果推論そのもの(構造が本質的に解釈可能)、効率性をトレース推論数削減・階層抽出による探索空間縮小の枝刈り戦略で達成されると整理する一方、粗粒度(サービス単位)の局所化が主流でサービス+メトリクスの細粒度局所化は発展途上と述べる。本 concept が蓄積する多次元 RCA(Squeeze・PSqueeze・HolisticRCA 等)や因果推論ベース RCA(CIRCA・BARO・RADICE 等)のいずれも、不均衡な障害クラス(発生頻度の低い障害種別)への検知バイアスを明示的に評価した例は見当たらず、「根本原因概念への懐疑」(Cook・Gallego・de Vesine の系譜)が扱う認識論的公平性とは別の、統計的公平性(特定の障害クラス・特定のサービスへの誤帰属バイアス)という技術的な空白領域があることを示す。(Source: [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]]) > > - **プライバシー領域における根本原因分析は「症状修正」と「同型再発の予防」を明確に区別する実務規範として、AIOps 系 RCA とは異なる語彙で同じ原則に到達している**: 本 concept が蓄積してきた AIOps 系の議論は主に「アルゴリズムがどう根本原因を特定するか」を扱うが、『SREの探求』15章は「特定した根本原因にどう対処すべきか」という下流の実務規範を扱う。バグが原因でデータ漏洩が発生した場合、単にバグを修正するだけでなく、最終的にドキュメンテーション・セーフガード・テストを改訂する必要がある場合や、ライブラリ/フレームワーク自体を改訂する必要が生じる場合があるとし、ストレージディレクトリのACL対象範囲が広すぎることを発見した場合も、特定のACLを修正するだけでなく、ディレクトリのセットアップができるツールを見つけてデフォルトのACL対象範囲を絞り込むよう変更すべきだと述べる。この「症状(個別のバグ・個別のACL)を直すだけでなく、それを生み出した構造(ドキュメント・ツール・デフォルト設定)を直す」という規範は、本 concept が[[複雑システム障害論]]・Cook命題7等から蓄積してきた「単一原因の宣言に満足せず構造的要因まで遡る」という原則と同型だが、AIOps 研究とは異なり「実務者が根本原因を発見した後に何を修正対象とすべきか」という下流の行動規範として定式化されている点が独自である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 15 信頼性とプライバシーが交わるところ]] §15.3.2.2) > > - **RCA アルゴリズムの設計思想(集約統計ベース・パターンベース・因果推論ベース)によって、入力トレースのキュレーション(サンプリング)への感度が大きく異なる**: トレースサンプラー Gleaner([[@2026__ISSTA__Gleaner : A Semantically-Rich and Efficient Online Sampler for Microservice Diagnostics]])の評価は、本 concept がこれまで「RCA アルゴリズムがどう根本原因を特定するか」を扱ってきたのとは異なる角度——「RCA に渡す**入力データの選び方**が精度をどう左右するか」——から新たな知見を提供する。MicroRCA(集約サービスメトリクス間の Pearson 相関 + Personalized PageRank)はサンプリング戦略にほぼ鈍感で、統計特徴量とトポロジさえ保持されれば 99% 少ないデータでも同等精度を維持する。一方 ShapleyIQ(因果推論ベース)は各 API エンドポイントの「健全なベースライン」との比較(marginal contribution)に依存するため、トレースの API 単位での均等なグルーピングを外すと AC@3 が 0.64→0.21 に崩壊する。Nezha(パターン比較ベース)は異常誘導型の多様性そのものに依存し、異常優先または多様性確保のどちらかを欠くと Random 未満まで劣化する。この3分類は、本 concept が蓄積してきた「限定観測可能性」「ラベリングコスト」といった入力データの**量**に関する課題とは異なる、入力データの**選び方**(何を残し何を捨てるか)に対する頑健性という新しい軸を提示する。(Source: [[@2026__ISSTA__Gleaner : A Semantically-Rich and Efficient Online Sampler for Microservice Diagnostics]] §4.5) > > - **「RCA」という語自体が2004年のシステム管理教科書ですでに定性的な原因列挙(原因木)の同義語として定着していた**: 本 concept の最古参照(2004年の[[@2004__OSDI__Correlating Instrumentation Data to System States - A Building Block for Automated Diagnosis]])は「相関と因果は別物」という限界の早期自覚として引用されてきたが、同年出版の[[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]] §8.6は、上位事象から下位原因へ系統的に展開する原因木(cause tree)の説明の中で「その使用はしばしばRoot Cause Analysis(RCA)と呼ばれる」と明記する。これは「RCA」という用語が2020年代のAIOps文脈で確立するはるか以前、2004年時点ですでにシステム管理の教科書レベルで定着した名称だったことを示す一次資料である。また同章§8.5.4の診断原則(Principle 45: 「まず明白な原因を除外せよ」、遠くの馬蹄の音を聞いたら馬を疑いシマウマを疑うな)は、[[仮説駆動RCA]]が扱う「仮説を立てて検証する」反復構造の、確率的な事前分布を明示しない素朴な先駆けとして読める――ありふれた原因から検証するという優先順位づけは、後年のRCAエージェントが暗黙に採用する「よくある原因パターンから先に確認する」設計判断と同型である。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]] §8.5.4, §8.6) > > - **博士論文の結論は RCACOPILOT を「多元的テレメトリへの LLM 推論適応」という事後段の到達点として要約し、AIOpsLab の4段 taxonomy における RCA 段の実装例として自己を位置づける**: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]] 冒頭要約は、RCACOPILOT による診断を「本番に到達した障害を多元的テレメトリへの LLM 推論適応で診断する」段と定式化し、[[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] の検知→局所化→RCA→緩和という4段 taxonomy の RCA 段に自己を位置づける。本ページが子 concept [[RCA評価設計]] 等で蓄積してきた「検知・局所化は現実的だが RCA は研究段階にとどまる」という評価観に照らすと、著者自身は結論章の Future Work(§6.2)で RCA 固有の改善方向を明示せず、より包括的な評価基盤(セキュリティ・信頼性軸の追加)がAIOpsLab 全体の拡張として語られるにとどまる——RCA 段の頑健性評価が今後の評価拡張にどう及ぶかは本章では示されていない。(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]]) > > - **RCACopilot は「ファインチューニングによる根本原因生成」ではなく「検索拡張つき few-shot CoT」として LLM 推論を RCA に適合させた——両者の分岐点は入力データの守備範囲と更新コストにある**: 博士論文第 3 章([[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 3 Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]])は、Ahmed et al.([[@2023__ICSE__Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models]])のインシデントタイトル・要約のみをファインチューニングする手法を明示的な対比先とし、(1) タイトル・要約だけでは複雑な非構造化・準構造化データ(ログ・テレメトリ・トレース)の信号を見落とす、(2) ファインチューニングは高コストで大量の学習サンプルを要する、(3) 進化するインシデントに追随できず幻覚が増える、という 3 つの限界を指摘する。RCACopilot の解は「モデル自体を更新する」代わりに「検索するデモンストレーションを更新する」ことで適応コストを下げる設計であり、時間重み付き類似度関数($\alpha=0.3,\ K=5$)による最近傍検索がファインチューニングに代わる適応機構として機能する。この設計は Table 10 のアブレーションで裏付けられる: デモンストレーションなしで直接予測する GPT-4 Prompt ベースラインは Micro-F1=0.026 まで落ち、ファインチューニング済み GPT も Micro-F1=0.103 にとどまる一方、検索付き RCACopilot は 0.766 に達する——「LLM 自体が持つ知識」より「検索された具体事例による文脈付け」が RCA 適応の主要因であることを定量的に示す。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 3 Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]] §3.4, Table 10) > - **RCACopilot は「要約という圧縮層」を LLM 推論の直前に挟むことで、情報過多とプロンプト長制約を同時に解消する**: 診断情報は 2,000 トークンを超えることが多く、生の情報をそのまま LLM に渡すとノイズが増え精度が落ちる(本ページ既出の「情報を取りすぎる病理」)。RCACopilot はこれを「入力を削る」フィルタリング型([[RCA入力選別]] が扱う統計的手法)ではなく、「LLM 自身に要約させてから別の LLM 呼び出しで推論させる」という 2 段 LLM 構成で実装した点が特徴的である。Table 11 のアブレーションは、要約なし診断情報(Micro-F1=0.689)から要約あり(0.766)への改善(+0.077)を定量化しており、同じ情報源でも LLM 自身による要約という前処理だけで精度が上がることを示す——これは MetricSifter のような統計的フィルタリングとは異なる、LLM 自身を圧縮器として使う適応パターンである。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 3 Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]] §3.4.3, Table 11) > - **RCA は緩和のクリティカルパス上になく、緩和へループを閉じるために RCA 結果が満たすべき条件は「正しさ」でなく「タイミングと十分性」である——STRATUS の実測タスク別成功率がこれを裏付ける**: 本ページは第3章(RCACopilot)を通じて「LLM 推論を診断にどう適合させるか」という事後段の精度追求を積み増してきたが、[[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.1・§4.4 は、RCA を緩和へ接続する制御フローの側から同じ問題を照射する。STRATUS は検知→診断(箇所特定+RCA)→緩和という順でタスクを進めるが、緩和(Mitigation Agent)は診断エージェント(Diagnosis Agent)の**分析的な出力**を受け取るだけで、RCA が正しいカテゴリラベルを出すことを commit/abort の判定条件にはしていない——判定は TNR の重大度指標 `µ` の単調非増加のみで行われる。実測でも RCA 成功率(GPT-4o で 34.6%)は緩和成功率(69.2%)を大きく下回るにもかかわらず、緩和は高い成功率を達成する。これは「緩和が RCA の正しさに構造的に依存しない」ことを実測タスク別成功率という定量データで裏付ける一次資料であり、RCACopilot のような**診断精度そのものを最適化する**アプローチ(第3章)と、STRATUS のような**診断結果を緩和計画の入力材料としてのみ使い、成否判定を別の指標(TNR の `µ`)に委ねる**アプローチ(第4章)という、同じ RCA→緩和の接続点に対する2つの異なる設計思想が本 concept 上で対比できる。前者は「RCA 結果自体の正しさ」を評価軸に置き、後者は「RCA 結果を使って緩和した後の状態が悪化していないか」を評価軸に置く——診断から緩和へループを閉じる際に RCA 結果が満たすべき条件は、ラベルの正確性ではなく、緩和計画を立てるのに十分な仮説を妥当な時間内に与えることだと言える。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]] §4.1, §4.2, §4.4, [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 3 Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]]) > > - **AIOpsLab の RCA タスクは単一ラベルでなく2サブタスク(システム層+障害種別)の複合評価であり、単純な exact-match 精度に還元できない**: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] §5.3 は RCA(Level 3)を「障害が発生したシステム層の特定」と「障害種別そのものの特定」という2つの独立したサブタスクを持つと定式化し、11のRCA問題が計22のタスクインスタンスとして採点される(§5.8)。しかし表22(a)ではRCA全体を単一の Accuracy 列(GPT-4o 40.90%等)で報告しており、2軸のどちらで失点したか(システム層は当たったが障害種別を外した、等)の内訳は公表されない。本ページが既に集積する HolisticRCA の3次元定式化(場所・詳細・知識、§横断的知見)がAIOpsLabの2軸評価と方向性を共有する一方、HolisticRCAが3軸を独立に評価するのに対しAIOpsLabは軸を単一指標へ集約する——RCA評価の粒度をどこまで開示すべきかという設計判断が、ベンチマーク間で暗黙に異なることを示す一次資料である。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]] §5.3, §5.8) > > - **Notaro ら(2021)はfault localizationをRCAというカテゴリ内部の第一段階として位置づけるが、AIOpsLab(2025)はlocalizationをRCAから独立した先行ステージとして扱う——両者は同じ2段階の論理的順序を異なる分類階層で表現している**: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]] は「根本原因分析(RCA)」という単一カテゴリの内部に、責任あるコンポーネント集合を絞り込む fault localization(§4.4.1)と、絞り込んだ対象の振る舞いを引き起こした原因を調べる root-cause diagnosis(§4.4.2)という2つのサブタスクを置く(定義: 「障害検知は症状の収集、RCAはその症状集合を生んだ障害集合を推論する過程」§4.4冒頭)。一方、本ページ定義部で参照する [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] の4段taxonomyでは、localizationとRCAは検知の後に続く独立した2段階として並置される。両者は「まずどこ(集合)を絞り込み、次になぜ(原因)を特定する」という同一の順序構造を共有しながら、Notaroらはこれを単一カテゴリ内の下位分解として、AIOpsLabは互いに独立したベンチマークタスクとして扱う——分類階層のどこに境界線を引くかという設計判断自体が、RCA研究のカテゴリ設計に揺れをもたらしている。この2021年時点の整理は、本ページが蓄積してきた「RCAは箇所特定から説明へ広がる」「エージェントシステムのRCAはインフラ箇所特定からトラジェクトリ上の決定ポイント特定へ移る」という後年の展開の出発点に位置する古典的な2分法を与える。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) > > - **データ源(ログ/分散トレーシング/監視)による分解とNotaroのfault localization対root-cause diagnosisという機能による分解は直交する軸である**: Soldani & Brogi 2021の第4章はRCA手法をclass(L/DT/M、データ源の種類)で分類し(Table 2)、§4.4.2は「データ源が要求する計装コストと識別できる根本原因の詳細度」というトレードオフを論じる——ログベース(Aggarwal et al.)は追加計装が不要だが単一のroot causing serviceしか返さず、監視ベース手法はエージェント配備・k8sデプロイ・ワークロード生成器を要する代わりにサービスレベルまでランク付きKPIを返せる。一方Notaroら(2021)の分解は、データ源に関わらずRCAという単一カテゴリの内部を「責任あるコンポーネント集合を絞り込むfault localization」と「その振る舞いを引き起こした原因を調べるroot-cause diagnosis」という機能的な2段階に分ける。両者を重ねると、Soldani & Brogi 2021が論じる「データ源が制約する粒度」という軸は、Notaroの2段階のうちfault localization寄りの出力形式(ranked services/KPIs)に主に対応する一方、root-cause diagnosis(なぜその振る舞いが起きたかの説明)にあたる要求は、Soldani & Brogi 2021では25手法いずれもが満たさない未解決課題として§4.4.4(説明可能性・対処策)に別立てされている。つまり本サーベイが分類する25手法の大半は、Notaroの2段階のうち第1段階(localization)をデータ源ごとに異なるコストで自動化しているが、第2段階(diagnosis、説明可能性)はデータ源の違いによらず未達成のまま残っていると読める——「何が原因である可能性が高いか」を返す能力と「なぜそれが原因なのか」を説明する能力は、Table 2のどの列にも独立の軸として現れていない。(Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.4 Discussion (Root Cause Analysis)]], [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]]) > > - **マルチモーダルという第4のモダリティが、3年の間にデータ源分類の独立カテゴリへ格上げされた**: Soldani & Brogi 2021(§4.4.2、本ページ既出)はRCA手法をログ(L)・分散トレーシング(DT)・監視/メトリクス(M)というデータ源3分類(Table 2)で整理し、複数データ源を組み合わせる手法は各手法の個別記述の中で扱うにとどめていた。3年後の [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion|Zhang+ 2024]] は、ログ・メトリクス・トレースに加えて「マルチモーダル」を第4の独立分類として明示的に立て(オブザーバビリティ3本柱のうち少なくとも2種類の組み合わせと定義)、これを result fusion・model fusion・feature fusion の3系統にさらに細分化する(§4.4、[[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.4 Failure Diagnosis Through Multimodal Data]])。同じ主題を扱う時期の異なる2つのサーベイを突き合わせると、マイクロサービスRCA研究において複数データ源の組み合わせが「個々の手法の実装詳細」から「独立した分類軸」へ格上げされるほど一般化した、という変化が浮かび上がる。(Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.4 Discussion (Root Cause Analysis)]], [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]]) > - **データモダリティの選択は、診断粒度だけでなく解釈可能性・データ量・移植性という複数の実用制約を同時に規定する——本サーベイの議論章(§5)はこれを横断的に定式化した**: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]] §5.2〜§5.3 は、メトリクスが変数値による間接的な状態反映にとどまるのに対し、ログ・トレースはログ行やAPI/リクエスト単位の操作を明示的・直接的に記録するため、より細粒度な診断の根拠になりやすいと整理する。同時に、その細粒度性の代償として、ログ・トレースは形式・内容が多様で量もメトリクスよりはるかに大きく処理コストが高い一方、メトリクスは定量的でリアルタイム検知に向くが文脈情報を欠き障害伝播への解釈可能性が低い、という対称的なトレードオフを指摘する。この整理は、本ページが Soldani & Brogi 2021(§4.4.2)から蓄積してきた「データ源が要求する計装コストと識別できる根本原因の詳細度のトレードオフ」という知見の、より新しい(2024年)サーベイによる独立確認であり、かつ「粒度」だけでなく「移植性」(§5.3の論理グラフモジュール設計)・「精度とコスト」(§5.4)という2軸を追加した点で射程が広い。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]], [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.4 Discussion (Root Cause Analysis)]]) > > - **同一サーベイの根本原因特定(RCI)手法分類は、§4.7の性能指標比較(本ページ既出)に加えて、§4.5では手法カテゴリの件数分布という別軸を提供する**: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.5 Root-cause identification]]のTable 6(68件)・Table 7(10件、計78件、2017〜2024年)のRCI Method列を集計すると、グラフベース手法が45件言及(複合ラベル含め全体の58%)で最多、機械学習が27件(35%)、統計的手法が23件(29%)、未記載が4件(5%)となる(1件が複数手法を併記する場合は各カテゴリへ重複計上)。本ページが既出の「§4.7ではグラフベースがprecision 92.7%/recall 89.7%、MLがprecision 94.9%/recall 98.0%/F1 99.0%、統計手法がprecision 85.0%/recall 88.0%/F1 85.8%」という性能軸の集計と合わせると、グラフベース手法は研究数で最多である一方、報告される性能指標そのものではMLが上回るという非対称性が浮かび上がる——「多く研究されている手法」と「高い性能を報告する手法」が必ずしも一致しないことを示唆する。件数分布の値は原文に明示的な記述がなく、本ページ作成者がTable 6・Table 7から独自集計した値である。(Source: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.5 Root-cause identification]]) > > - **根本原因箇所特定における「人間の介入」は、異常検知と比べサーベイ自身が体系化の遅れを認める空白領域であり、説明可能性(構造的解釈可能性)が実際の人間による監査・修正へどう接続するかは未検証のまま残る**: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.5 System-Level Trustworthiness Requirements]](Xin+, ACM Comput. Surv. 2025)は、システムレベルの信頼性要件として人間の介入(Human Intervention, HITL)を扱う節で、異常検知についてはデータアノテーション・ハイパーパラメータ調整・人間フィードバック(GraphUCBによる専門家フィードバック統合・Q学習による更新等)の具体的手法を4件挙げる一方、根本原因箇所特定については「人間の介入に関する研究は少ないが、アルゴリズムが構築した因果グラフを人間の知識で修正することで性能が向上しうる」と一文で述べるにとどめ、具体的な実装や実証研究を一切挙げていない(§3.5.2)。同サーベイは[[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization|Chapter 3.4]] §3.4.2で根本原因箇所特定における説明可能性を「因果推論に基づく手法は構造そのものが本質的に解釈可能」と位置づけているが、この構造的解釈可能性が実際に人間による因果グラフの修正・監査へどう接続されるかは、サーベイの範囲では検証されていない。本 concept が蓄積してきた CIRCA/RCD(ドメイン知識依存度の対比、§本ページ既出)は、いずれも因果グラフを**事前に**人間の知識で構築する設計であり、サーベイが示唆する「アルゴリズムが構築した後に人間が修正する」という逆方向の human-in-the-loop はまだ実例が見当たらない。(Source: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization]], [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.5 System-Level Trustworthiness Requirements]]) > > - **ログを主証拠とするRCAでは、LLMは『推論者』というより『異種証拠の統合器』として機能し、最も信頼できる設計は検索・ツール・SOP・グラフで生成を制約する**: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 6.3 Downstream Log Analysis Tasks - Failure Prediction and Root Cause Analysis]] は、ランタイムログが運用証拠として直接的/間接的に使われる20論文のRCA研究を横断し、手法差を(1) LLMの使い方(プロンプティング/ICL vs エージェント的ツール利用 vs 学習済みタスクモデル)、(2) 統合する外部文脈(リポジトリ・DB・SOP・グラフ・知識ベース)、(3) 出力の最適化対象(自由形式説明 vs 構造化ラベル/位置 vs 対処)の3軸に整理する。プロンプティング/ICL系(Chen et al.・Zhang et al.・InsightAI)は低エンジニアリングコストだが文脈選択・プロンプト頑健性・証拠の忠実性に性能が律速される一方、エージェント型・ツール拡張系(RCAgent・OPENRCA・TAMO・Flow-of-Action・RCLAgent・MicroRCA-Agent)は網羅性・追跡可能性を改善するがレイテンシ/コスト増とガードレールを要する。本ページが既に蓄積してきた「入力選別はRCAの中核」([[RCA入力選別]])・「安価な絞り込み→高価なLLM推論」の階層設計(RCACopilot・MagmaScope・Bian Que)という観察は、ログ主体のRCAでも同型に現れる——MicroRCA-Agentの「Isolation Forestによる異常識別段→エージェントRCA」は、本ページのハイブリッド設計パターンをログドメインで具体化した一事例として位置づけられる。ログが提供する固有の価値は、時系列的な症状証拠・エラー/例外の意味論・コンポーネント固有の文脈・観測から候補原因をつなぐ運用者向け証拠チェーンであり、メトリクス・トレース単体の相関分析では代替しにくいと同レビューは述べる。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 6.3 Downstream Log Analysis Tasks - Failure Prediction and Root Cause Analysis]]) > - **ログ主体のRCAはメトリクス/トレース主体のRCAと同じ評価断片化(意味的類似度 vs Acc@k vs F1 vs ROUGE/BLEU)を独立に抱えており、本ページの「評価はRCA研究最大の不安定要因」という観察をログドメインでも裏づける**: LLM4Log Chapter 6.3 のTable 8は、インシデントRCAが意味的類似度指標(METEOR・NUBIA・BLEURT等)を、局所化がランク/Acc@kを、分類がaccuracy/F1を、対処生成がROUGE/BLEUを、それぞれ好んで使うと整理し、この指標の多様性はRCAの運用上の定義(説明 vs 局所化 vs 対処)の違いを反映すると述べる。これは本ページが[[RCA評価設計]]で蓄積してきたSimpleRCAの観察(既存ベンチが「最も目立つ症状=根本原因」を許していた可能性)や、Anomaly detection and root-cause identification in microservicesサーベイの「データセット・テストベッド・指標の不均一性が直接比較を難しくする」という観察と同型であり、評価断片化がRCA研究全体を貫く構造的問題であることを、ログ主体という別の証拠源でも確認する。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis - Chapter 6.3 Downstream Log Analysis Tasks - Failure Prediction and Root Cause Analysis]]) - [評価の不安定性] 最終回答の正解率(outcome-level accuracy)は診断過程の完全性を隠す。伝播経路の再構築(Edge F1)は根本原因サービスの特定(Node F1)より一貫して困難で、正しく箇所特定できたケースでも Edge F1 は 0.67 を超えない例が報告されている。バックボーンモデルの強化は最終正解率を押し上げても、この再構築の天井をほとんど動かさない(Source: [[@2026__arXiv__Beyond Fault Localization - A Trajectory-Level Study of LLM Agents for Microservice Root Cause Analysis]]) - [評価の不安定性] 因果連鎖(伝播経路)の深さが増すほど根本原因特定精度は低下する傾向があるが、この低下幅はバックボーンモデルによって大きく異なり、強いモデルではほぼ見られない例が報告されている(Source: [[@2026__arXiv__Beyond Fault Localization - A Trajectory-Level Study of LLM Agents for Microservice Root Cause Analysis]]) - [評価の不安定性への反例] 「合成障害での性能は実システムへの転移を保証しない」という既存の懸念に対し、SLoFI は実験室のシミュレータではなく本番稼働中の Tianhe スーパーコンピュータ(568 ノード)上で低権限の障害注入を行い、注入ノードを正解ラベルとして根本原因の箇所特定モジュールを評価している(Top-2 候補内 86.67%)。合成障害の生成場所を「本番環境そのもの」に置くことで、合成/実環境の転移ギャップを縮める設計例になる(Source: [[@2026__ISSRE__SLoFI : Low-Privilege Fault Injection for Reliability Testing in Production Supercomputers]])。 - [相関と因果] **根本原因の特定を、症状アラートの因果グラフ上での劣モジュラ最適化(どのノードを直せば波及的に最も多くの症状が解消するか)として定式化した研究がある**。この定式化は NP 完全だが、貪欲近似(近似比 1-1/e)・上下界枝刈り・木サンプリングヒューリスティクスにより 10万〜100万ノード規模のグラフまでスケールする (Source: [[@2014__KDD__Towards Scalable Critical Alert Mining]])。 - 2004年のSteinder & Sethiによる古典的サーベイは、専門家システム・モデル走査・グラフ理論・codebookの4パラダイムに障害箇所特定を分類したうえで、multi-layer診断・時間相関・分散診断・モデル獲得を未解決課題として挙げていた。相関(因果グラフ上のアラーム共起)と因果(実際の障害伝播)の区別、および事前に正確な依存モデルを得ることの困難さは、この時点で既に中心的な論点として自覚されていた(→[[障害箇所特定パラダイム分類]]、[[確率的障害伝播モデル]])。(Source: [[A survey of fault localization techniques in computer networks]]) ## 関連 - 子 concept: [[RCA入力選別]] / [[RCA評価設計]] / [[仮説駆動RCA]] / [[ドメイン別RCA]] / [[Sparkジョブ異常診断]] / [[宣言的RCA]] / [[コード知識強化RCA]] / [[グラフベースRCA]] / [[LLMによる根本原因分析]] / [[ログ解析]] - サーベイ章: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]] — fault localization / root-cause diagnosis の2段階分解 - サーベイ章: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]] — データモダリティ(ログ/メトリクス/トレース/マルチモーダル)が診断粒度・解釈可能性・移植性・精度コストを規定する横断的議論 - 親/隣接 concept: [[AIOps]] / [[agentic SRE]] / [[Fault Localization]] / [[障害緩和]] / [[インシデント管理]] / [[限定観測可能性]] / [[Causal Software Engineering]] / [[プライバシーエンジニアリング]] / [[トレースサンプリング]] - ソース: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] / [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.4 Discussion (Root Cause Analysis)]] / [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 3 Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]] / [[@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__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]] / [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] / [[Anomaly detection and root-cause identification in microservices]] / [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 6 Challenges, open issues, and directions to future investigations]] / [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] / [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]] / [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] / [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]] / [[@2022__ESEC FSE__Constructing Large-Scale Real-World Benchmark Datasets for AIOps]] / [[@2024__OReillyJapan__SREをはじめよう - Chapter 10 失敗から学習する]] / [[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]] / [[Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications]] / [[@2021__OReillyJapan__SREの探求 - Chapter 15 信頼性とプライバシーが交わるところ]] / [[@2026__ISSTA__Gleaner : A Semantically-Rich and Efficient Online Sampler for Microservice Diagnostics]] / [[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]] / [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]] / [[@2026__ISSRE__SLoFI : Low-Privilege Fault Injection for Reliability Testing in Production Supercomputers]] / [[@2014__KDD__Towards Scalable Critical Alert Mining]] - 概念: [[エージェント軌跡評価]] / [[重要アラートマイニング]] / [[障害箇所特定パラダイム分類]] / [[確率的障害伝播モデル]] ## 出典 - [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]](§4.4: RCAをfault localization(§4.4.1)とroot-cause diagnosis(§4.4.2)へ分解する定義、§4.4.3のRCA支援ツール) - [[@2021__OReillyJapan__SREの探求 - Chapter 15 信頼性とプライバシーが交わるところ]](§15.3.2.2: バグ修正/ACL修正にとどまらずドキュメント・ツール・デフォルト設定を修正するという実務規範) - [[@2024__OReillyJapan__SREをはじめよう - Chapter 10 失敗から学習する]](§10.1: 「根本原因」→「一因」の視点転換、なぜなぜ分析批判) - [[@2022__ESEC FSE__Constructing Large-Scale Real-World Benchmark Datasets for AIOps]](§4 dataset B の構築手順・6 ステップ合成プロセス・AIOps Challenge 2019 結果) - [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]](ネットワークデジタルツイン + 13 エージェント構成、NTT DOCOMO 実装で 15 秒 MTTD) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 5 Evaluating AI Agents for Autonomous Cloud Operations]](§5.3 RCA の2サブタスク定式化、§5.8 複合Accuracyへの集約報告) - [[@2016__OReilly__SRE Book - Chapter 12 Effective Troubleshooting]](仮説演繹法・トリアージ) - [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]](hypothesis-driven investigation) - [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]](4-level taxonomy, telemetry overuse) - [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]](greedy approach) - [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]](SimpleRCA, observability blind spots) - [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]](コード実行型 RCA agent) - [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]](§VI: 失敗帰属の 3 カテゴリ整理 / FAMAS / GraphTracer / AgenTracer / Who&When の 3 パラダイム / AgentFail / AgentDebug / 2 段階フレームワーク / Figure 11 コンテキスト長による精度低下) - [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]](§III Agent-Ready 4 要件・§VI 実験・Tables IV-V・Figure 5-6 ケーススタディ) - [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]](§3 OBSK/ツール/専門エージェント/安定化/TSC, §5 アブレーションと安定性, §6 Alibaba Cloud Flink へのデプロイ) - [[Anomaly detection and root-cause identification in microservices]](§4.5 根本原因特定手法、§4.7 手法比較、§6.2 Trusted Distributed AI、Table 10) - [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 4.5 Root-cause identification]](§4.5.1〜4.5.3 ML/グラフ/統計の3分類、Table 6・Table 7のRCI Method列から独自集計した件数分布(グラフ58%・ML35%・統計29%)) - [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey - Chapter 6 Challenges, open issues, and directions to future investigations]](§6 冒頭: 他分野への手法転用・ServiceRankの異分野適用可能性、§6.1 TEEによるRCAコンポーネントの改竄防止、§6.2 TDAIとTable 10信頼次元の定式化) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 4 A Multi-Agent System for Autonomous Site Reliability Engineering]](§4.1 RCA は緩和のクリティカルパス上にない、§4.2 Diagnosis Agent の分析的出力、§4.4 検知/箇所特定/RCA/緩和のタスク別成功率) - [[Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications]](§4: RCA 26 手法の 2 軸分類(Table 2)・§4.4.3: 相関 ≠ 因果・§4.2.3: MonitorRank パターン・§4.4.4: 説明可能性と対策推奨・§6: 未解決課題) - [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.4 Discussion (Root Cause Analysis)]](§4.4: RCA 25 手法の 7 軸分類(Table 2)・§4.4.1: 因果グラフ構築(PC アルゴリズム)と MonitorRank 由来のランダムウォーク・§4.4.2: 識別できる根本原因の詳細度対セットアップコスト・§4.4.3: 偽陽性/偽陰性と相関 ≠ 因果・§4.4.4: 説明可能性と対処策) - [[@2024__ISSRE__SparseRCA - Unsupervised Root Cause Analysis in Sparse Microservice Testing Traces]](テスト環境の疎トレース RCA、ExL パターンベース分解、パーソナライズド PageRank) - [[Failure Diagnosis in Microservice Systems]](§4 手法体系, §5 考察(粒度・説明可能性・移植性・精度・コスト・将来方向), §6 データセット/ツールキット/評価メトリクス, Table 1 先行サーベイ比較) - [[@2004__OSDI__Correlating Instrumentation Data to System States - A Building Block for Automated Diagnosis]](「相関 ≠ 因果」の先駆的な明示・「無関係メトリクスを無罪放免する価値」・TAN による自動性能診断の基盤論文・3–8 メトリクスで BA 87–94%) - [[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]](§3.3 Ochiai 式スペクトル解析・§3.4 処理時間相関ベースPageRankランダムウォーク・§3.5 結果キャリブレーション・§4 TrainTicket/BookInfo/実世界データでの評価・§5 スケーラビリティとオーバーヘッド) - [[@2024__TSC__Holistic Root Cause Analysis for Failures in Cloud-Native Systems Through Observability Data]](§II-A 問題定義の断片化の動機・§III 3 次元 RCA 定式化・§IV ビルディングブロック組み立て戦略・§V-E リアルタイム RCA 効率性) - [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]](§3 LogCluster 4 段フロー(ベクトル化→クラスタリング→代表系列→知識ベース照合)、§5 Service A/Product G/Product L/Service C への 2013 年以来の本番展開、§6 教訓: ログ重大度レベルの限界) - [[@2025__AIDB__AutoDebugger - Efficient Root Cause Analysis for Anomaly Jobs]](§3 HybridRCA アルゴリズム・グラフ分解・時間計算量改善・§4 本番 30+ ジョブグループ評価) - [[@2025__arXiv__COCA - Generative Root Cause Analysis for Distributed Systems with Code Knowledge]](§III 4 フェーズ設計・RPCBridge・コードプロファイリング、§V Tables II-IV アブレーション・汎化性、§VI ケーススタディ 19.4 秒応答) - [[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]](§4 4 ステージワークフロー・5 方向仮説インタラクション、§5 BCPD ベース関連度スコア・知識グラフモデル・DAGre 2 段階レイアウト、§6 ケーススタディ 2 件・専門家インタビュー) - [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]](§2 Challenge 1/2 定式化、§3 FILE/GARCA 2 段パイプライン、§4.4 アブレーション、§4.5.2 能動学習ラベル効率、§5.1 ByteDance 本番デプロイ) - [[@2026__ISSTA__Gleaner : A Semantically-Rich and Efficient Online Sampler for Microservice Diagnostics]](§4.5 RCA アルゴリズム別のサンプリング感度分析、MicroRCA/Nezha/ShapleyIQ の比較) - [[@2026__FSE__Causal Software Engineering - A Vision and Roadmap]](§1 リトライポリシー誤帰属の動機付け事例、§2 交絡因子・許容される因果リンクの明示化) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]](§8.5.4 診断の第一原理・§8.6 原因木=RCAという命名の一次資料) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 6 Conclusion and Future Work]](冒頭要約: RCACOPILOTの事後段診断としての位置づけ、§6.2: 評価基盤拡張の方向性) - [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]](§5.2: 粒度・説明可能性、§5.3: 特性・移植性(論理グラフモジュール)、§5.4: 精度・コスト・未知障害対応、§5.5: 最良実践・将来方向) - [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization]](§3.4.2: 根本原因箇所特定の信頼性要件。説明可能性=因果推論の本質的解釈可能性という位置づけ) - [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.5 System-Level Trustworthiness Requirements]](§3.5.2: 人間の介入。根本原因箇所特定における人間の介入研究の少なさと、因果グラフの人間による修正という一文の提案) - [[@2014__KDD__Towards Scalable Critical Alert Mining]](劣モジュラ最適化による重要アラート選定と根本原因分析の関係)