# 根本原因分析 ## 定義 根本原因分析(Root Cause Analysis, RCA)は、障害の症状から、影響するシステム層・障害種別・因果連鎖を絞り込み、人間またはエージェントが次の緩和判断に使える説明を得る取り組みである。[[AIOps]] の 4-level taxonomy では検知・箇所特定の後、[[障害緩和]] の前に位置する。([[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) 本ページは RCA の地図ページとし、詳細論点は子 concept に分ける。入力の絞り込みは [[RCA入力選別]]、評価とベンチマークは [[RCA評価設計]]、調査ループは [[仮説駆動RCA]]、対象ドメインごとの差異は [[ドメイン別RCA]] に置く。 ## 横断的知見 - **単一根本原因の探索が構造的に成立しない歴史的事例として、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., [[HP 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 手法が免れない原理的限界であり、偽陰性の主因である**: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]]（Soldani & Brogi 2021）は、26 手法すべてが相関（KPI 相関・PC アルゴリズム・ランダムウォーク・グラフ中心性）を根拠として根本原因を特定するが、**相関は因果を保証しない**ことを明示的に述べる（§4.4.3）。例: あるサービスの KPI がフロントエンドの KPI と高相関でも、第三のサービスが共通原因の場合は偽陽性になる。トポロジグラフ手法でさえ「同一ノードに同居する別サービスがリソースを食い尽くす」ケースを構造的に見逃す。本 wiki の [[MetricSifter]] が「無関係メトリクスを削ることで因果探索を助ける」設計、[[RCAgent]] が「環境への入口を狭く設計する」設計は、この相関バイアスを削減の第一手として実装した事例として読める。LLM-era の RCA が「相関でなく因果推論を」に向かう動機はここに遡る。(Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]]) - **98 論文サーベイで pre-LLM 期 RCL の全手法地図が完成した**: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis]](Zhang+ 2024)は 2003〜2024 年の 98 論文を 4 モダリティ × ログ/メトリクス/トレース/マルチモーダルで分類し、マイクロサービス RCA の最初の包括的地図を提供した。メトリクスベース RCL が 63 論文と最多で、うち 38 件がインスタンスレベル、44 件がコンポーネントレベル。マルチモーダルは近年急増しているが総論文数はまだ少ない。本 wiki の [[根本原因分析]] が個別手法から積み上げてきた知見(MonitorRank パターン・PC アルゴリズム + ランダムウォーク・相関 ≠ 因果)がこのサーベイで体系化されている。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis]], §4, Figure 1, Figure 3) - **移植性の鍵は「論理グラフモジュール」であることが 5 本以上の先行研究で収束した**: Zhang+ 2024 の §5.3 は、特定の呼び出し依存ではなく論理的合意に基づいてグラフを構築する MicroCBR・CloudRCA・TrinityRCL・NetMedic・T-Rank が、異なる環境への展開コストを下げる共通設計を持つと整理する。これは本 wiki が扱う [[RCACopilot]] の「アラートハンドラ = 有向グラフワークフロー」設計と対比できる——RCACopilot が「ドメイン固有の手作業 DAG」で精度を得るのに対し、論理グラフ系は「ドメイン非依存の合意グラフ」で移植性を得る。精度と移植性のトレードオフとして読める。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis]], §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 の [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]] が整理する LLM-era の RCA がこのパターンをどう置き換えるかは未整理。(Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]]) - **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: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]], [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]]) - **マイクロサービス RCA の古典的手法地図は「機械学習・グラフ・統計」に収束するが、評価の共通土台はまだ弱い**: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]] は、根本原因特定を機械学習、グラフベース、統計手法に整理し、機械学習系を 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: [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]], [[@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; [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]]) - **時系列統計による因果発見の精度劣化は 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]]) ## 未解決の問い - **LogSage の推論遅延許容(約 3.1 秒)は「事後分析(post-mortem)としての RCA」という前提に依存するが、この前提はリアルタイム RCA が必要な障害クラスにどこまで一般化するか**: LogSage の著者らは「カーネルパニック RCA は本質的に事後分析であり、リアルタイム異常検知とは異なり遅延に寛容だ」と主張するが、本 concept が扱う RCA の多くは「調査ループ」の一部として即応性を要求される([[仮説駆動RCA]])。post-mortem 前提が成立する障害クラス(カーネルパニック等の致命的だが再現頻度が低い障害)と、リアルタイム性が必須な障害クラス(継続的なパフォーマンス劣化等)を切り分ける基準は明示的に整理されていない。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §4.2) - **LagRCA の時間ラグモデリングと KRCA の空間圧縮の統合可能性**: 両者は異なる本番環境(Alibaba/銀行 vs 快手)・異なる規模(46 インスタンス vs 20万超サービス)で評価されており、時間ラグモデリングがハイパースケール環境でどこまでスケールするか(低ランクパラメータ化 O(Nr) が数十万サービスで実行可能か)は未検証。(Source: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]]) - RCA の成功は、根本原因コンポーネントの exact match、説明の妥当性、調査過程の健全性、緩和への有用性のどれで測るべきか。 - HolisticRCA の 3 次元定式化(場所・詳細・知識)は「3 軸を同時に解く」ことを要件とするが、現実のインシデント対応では 3 軸の優先度は局面により異なる。「第 3 次元(障害種別)から着手し第 1・第 2 次元を必要に応じて行う」リアルタイム RCA 最適化は、優先度の局面依存性をどう設計に織り込むべきか。(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% のうち、どの程度がデータのセマンティクス付与（Semantically Rich）によるものか、トポロジーグラフ（Graph-Based）によるものか、ツール層（Tool-Enabled）によるものか。3 要素を分離したアブレーションは未実施。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §VI-B) - エージェントシステムの失敗帰属(AgentOps §VI)における 2 段階フレームワーク(非 LLM で疑惑領域を絞り込み → LLM-as-a-Judge)は、第 1 段階の絞り込み精度が第 2 段階の品質を律速する。第 1 段階のカバレッジ(見逃し率)とコストのトレードオフはどう設計するか。VAE 再構成を第 1 段階に使う試作は有望だが、分布外のエージェント障害パターンで汎化するか未検証。([[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]] §VI-C) - RCAgent は調査軌跡の最終化直前から TSC をサンプリングすることで性能を上げたが、複数仮説を明示的に保持する設計ではない。仮説駆動 RCA において、TSC のような出力多様化と、Bits AI SRE 型の仮説リスト管理は統合できるか。([[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]]) - サーベイが提案する Trusted Distributed AI の評価軸(信頼性・説明可能性・一貫性・頑健性・因果妥当性)は、RCA の exact match や top-k 指標にどう接続すべきか。特に「根本原因ランキングの分散」や「因果解釈可能性スコア」は、既存の AIOps ベンチで再現可能に測れるか。([[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]] Table 10) - Soldani & Brogi 2021 が挙げた「継続的デリバリ環境での継続的変化への対応」は 2026 年時点でどこまで解決されたか。LLM-era の RCA エージェントは zero-shot 推論で「訓練なしに新サービスの根本原因を特定できるか」という問いに答えつつあるが、動的なサービス依存グラフへの追従能力を評価した研究は少ない。([[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]] §6) - **非集計トレースが有効な障害クラスと集計トレースで十分な障害クラスの境界はどこか**: TraceRank([[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]])は部分的・断続的障害で非集計トレースの優位を示したが、全リクエストが障害の影響を受ける完全障害(例: 全トレースが障害コンポーネントを通過する)では集計ベースとの差がなくなるはず。パーソナライズドPageRankのランダムウォーク設計が BookInfo のような「全サービスが高相関」なシンプルトポロジで識別力を失う(同スコア問題の別形態)という既知の課題と合わせ、「非集計トレース + スペクトル解析」が確実に優位になるシステム条件(部分的障害の比率・トポロジの不均質性・レプリカ数)を定量化した研究が不足している。([[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]], §4.4) - **RCACopilot のアラート種別ハンドラを LLM が自律生成できるか、それとも OCE 手作業に依存し続けるか**: RCACopilot は Microsoft 30 超チームでのハンドラ構築工数を 4 年以上かけてカバーしたが、ハンドラを持たないアラート種別には適用不可という構造的限界がある。LLM 自身がアラートテンプレートとログ・メトリクスから初期ハンドラ(有向グラフワークフロー)を提案できれば、ハンドラ構築工数のボトルネックを解消できる。これは [[エージェント型コーディング]]・[[Flexible Skill Arrangement]] の「LLM が手続きを動的に組み立てる」設計と同じ問題系列であり、CIRCA/RCD の「アルゴリズム自体は固定」というアプローチとは異なる解空間に位置する。(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]]) - **ソースコードが「監視データの代替」として機能することが初めて定量的に示された**: [[COCA]]([[@2025__arXiv__COCA - Generative Root Cause Analysis for Distributed Systems with Code Knowledge]])は JIRA イシューレポートのみの設定で、静的解析でログメッセージをコード行に対応付け、ICFG ベースの実行パス再構築と RPC ブリッジングで障害前の実行コンテキストを LLM に提供した。[[RCACopilot]]([[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]])比で Exact Match +28.3%・BLEU-4 +22.0%。「入力選別は RCA の中核」という本 wiki の知見が「コードを入力に追加する」という別アプローチで再確認された。RCACopilot が「手作業 DAG ハンドラ + 埋め込み類似検索」というドメイン知識主導の設計で本番実績を得たのに対し、COCA は「静的解析 + コード実行ロジック理解」という別経路を開拓した。(Source: [[@2025__arXiv__COCA - Generative Root Cause Analysis for Distributed Systems with Code Knowledge]] §V, Tables II-IV) - **テスト環境の疎トレースでは統計メトリクスベースの因果発見が破綻し、単一トレース単位の排他レイテンシ分析が有効になる**: [[SparseRCA]]([[@2024__ISSRE__SparseRCA - Unsupervised Root Cause Analysis in Sparse Microservice Testing Traces]], ISSRE 2024)は、テスト環境のトレースが本番比 400 分の 1（6,000 件 / 37 日 vs 250 万件 / 50 日）と疎であり、MicroHECL・AutoMap 等の統計ベース手法が A@1=19.3〜40.7% に低下する問題を実証した。SparseRCA は排他レイテンシ(ExL)をスパンパターン(コンテキスト × 子集合)単位でガウス分布モデリングし、単一トレースから教師なしで A@1=66.1%・A@5=88.1% を達成した。パーソナライズド PageRank(RCM)の除去で A@1 が 49.2% に低下し、MonitorRank 以来のランダムウォーク系トポロジ活用パターンがテスト環境でも有効であることを裏付ける。さらに、訓練データの 40% で最良ベースライン(MicroRank 100%)の A@1 を上回るデータ効率は、「限定観測可能性」下での RCA 設計の具体事例として位置づけられる。TraceRank が「何を計測するか(処理時間)」の工夫で改善したのと同様、SparseRCA は「何を分解するか(包含→排他レイテンシ)」の工夫で疎データに対応した。(Source: [[@2024__ISSRE__SparseRCA - Unsupervised Root Cause Analysis in Sparse Microservice Testing Traces]]) - **RADICE は「根本原因集合」の出力から「根本原因因果サブグラフ」の出力への最初のシステム的な移行を示し、RCA が「何が原因か」から「どのように異常が伝播したか」へ拡張される可能性を具体化した**: 既存の因果推論ベース RCA（CIRCA/RCD/BARO/MicroCause 等）は根本原因の集合を出力するのに対し、RADICE（Tonon+ arXiv 2025）は PCMCI+ + 部分ドメイン知識 + エントロピー方向付け + 調整済み相関スコアを組み合わせ、根本原因から性能メトリクスまでの因果伝播経路を含むサブグラフを出力する。実広告システムの事例で専門家のマニュアル分析と一致した。この「因果サブグラフ」出力はインシデント対応の文脈では「どのコンポーネントがどの順で影響を受けたか」という説明を自動生成することを意味し、Cook（1998）の「複数寄与因子のネットワーク同定」への接近とみなせる。ただしサブグラフ構造そのものの評価指標は未確立であり、従来の recall/precision（集合ベース）では部分的にしか測定できない。(Source: [[@2025__arXiv__RADICE - Causal Graph Based Root Cause Analysis for System Performance Diagnostic]]) - **トレースの「異常スコア化」がメトリクスとの異種相関を可能にし、サービスレベルとメトリクスレベルを同時に教師なしで特定する**: HeMiRCA([[@2024__TOSEM__HeMiRCA - Fine-Grained Root Cause Analysis for Microservices with Heterogeneous Data Sources]], TOSEM 2024)は、VAE でトレースを**単一の異常スコア時系列**に圧縮し、メトリクス時系列との Spearman 単調相関でランク付けする非対称統合設計を採用した。非根本原因メトリクスは障害伝播の影響を受けても「異常スコアと同方向に単調変化」しないという観察が成立要因であり、TrainTicket でサービスレベル HR@1=82.7%・メトリクスレベル HR@1=74.0% を教師なしで達成した。「異種モダリティを融合するのではなく、1 つのモダリティをスコアに変換してから相関を測る」設計は、TVDiag の等価融合批判・TAMO の拡散アライメントとは異なる第 4 の統合路線を提示する。アブレーションで Spearman > Kendall > Pearson の優位が全条件で確認され、分布フリーのノンパラメトリック相関がマイクロサービス RCA の標準選択に向かうという収束（ε-Diagnosis の「エネルギー距離」優位と同方向）を裏付ける。(Source: [[@2024__TOSEM__HeMiRCA - Fine-Grained Root Cause Analysis for Microservices with Heterogeneous Data Sources]], §3-4, Tables 3-4) - **SRE 実践の文脈では「根本原因は誤った概念」という見解が 2018 年に明示的に表明された**: [[Will Gallego]]（[[Etsy]]、[[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]]）は、ポストモーテムの進行において「根本原因」「主要原因」などの用語を使わないことを強く推奨した。根拠は「イベントは常に複数の相互連関した要因・ツール・新規入力・変更ゴールによって起き、単一の原因を宣言することは『浅い答えで満足する』宣言に等しい」というものである。さらに「成功にも根本原因はない。失敗も同じ多因子構造を持つ」と論じる。これは Cook（1998）が命題 7 で述べた「根本原因帰属は社会的・文化的必要性を反映する」（[[@1998__CtL__How Complex Systems Fail]]）を、SRE 実務者の言葉で再表明した事例であり、AIOps 分野で「根本原因分析」を主要技術として研究し続けることとの緊張関係を持つ。技術的文脈（AIOps）では「根本原因ランキング」が評価指標として定着しているが、文化的文脈（ポストモーテム）では同じ用語がむしろ深掘りを妨げると見なされるという二重性が 2026 年時点でも解消されていない。(Source: [[@2018__SREcon18 Americas__Architecting a Technical Post Mortem]] p.22; [[@1998__CtL__How Complex Systems Fail]] 命題 7) - **「Root Cause の指定」は複雑システムの因果を 3 点で損なう**: [[Courtney Nash]]（[[@2023__SREcon23Americas__Far from the Shallows]]）は Root Cause の指定が①複雑システムの因果を単純化する、②上流/その他のシステム要因を見逃す、③人間の判断と行動に過剰索引付けするという 3 点の問題を持つと整理し、「因果性は構築される(causality is constructed)」という [[Sidney Dekker]] の命題を引用してインシデント分析における Root Cause 指定の認識論的問題を指摘した。Dekker・Cook・Gallego・Nash と複数の研究者・実践者が独立に収束している構造であり、RCA という語の使用自体が誤解を招くという観点は組織学習コミュニティと AIOps コミュニティで取り扱い方が大きく分岐している。(Source: [[@2023__SREcon23Americas__Far from the Shallows]] p.024) - **「根本原因 = システムの脆弱性、トリガー = 環境条件」という用語再定義が安全工学から導出された**: [[Laura de Vesine]]（[[Datadog]]、[[@2022__SREcon22 EMEA__Principled Identification of Root Causes Using Techniques from Safety Engineering]]）は「根本原因」をジャーゴンとして再定義する実用的アプローチを提案した。「根本原因 = システムに潜在していた脆弱性の集合で、障害を引き起こす潜在可能性があったもの」「トリガー = その脆弱性を顕在化させた(またはその可能性があった)環境条件の集合」という定義により、Will Gallego の「根本原因という用語を捨てよ」と Cook の「原因は構築される」の間で実用的な中間点を提示した。用語を廃棄するのではなく「何を意味するか」を合意する戦略は、AIOps の「根本原因ランキング」文脈と SRE ポストモーテムの「根本原因概念の拒絶」の橋渡しとして読める。(Source: [[@2022__SREcon22 EMEA__Principled Identification of Root Causes Using Techniques from Safety Engineering]] p.15) - **CAST(Causal Analysis based on Systems Theory)は RCA の対置ではなく「より深いフレーム」として Google で産業規模適用されている**: [[Ruben Barroso]](Google)による SREcon26 Americas 発表([[@2026__SREcon26Americas__The Case of the Misnamed Cities - CAST Analysis of a Google Maps Incident]])は、Google Maps の都市名誤表示インシデントを事例に、RCA が「評価ツールの不備」「サンプリング戦略の欠如」の2根本原因を特定するのに対し、CAST が「Dataset Import Team のメンタルモデルの誤り(US Census データの特殊性を認識していない)」「Engineering と Dataset Import Team 間の責任拡散」「Dynamic Environment による既存ポリシー陳腐化」という組織・環境的因果要因を追加で析出することを示した。CAST vs RCA の 4 軸比較(事故モデル・改善計画・分析フレーム・組織要因)では、CAST が「遠位イベント」と「社会技術的要因」まで踏み込む点が RCA との最大の差異となる。5年間・数十システムの Google 内適用実績があり、本 wiki 内の他の学術研究と異なる「本番産業実績ある代替フレームワーク」として位置づけられる。詳細は [[CAST]] 参照。(Source: [[@2026__SREcon26Americas__The Case of the Misnamed Cities - CAST Analysis of a Google Maps Incident]]) - **5 Whys の失敗モードは「判断基準の欠如」であり「トリガーのどこまでも遡行」か「スコープ外の大きすぎる原因」に終着する**: de Vesine は 5 Whys を機械的に適用すると「バーが燃えた原因 → 資本主義」という結論にも「原因は気候変動」にもなりうることを示した。いずれも「なぜその Why の答えが正しいか」を判断する基準なしに Why を重ねた結果であり、この「トリガーホワイトアモール(Trigger Whack-a-mole)」反射は根本原因分析の典型的失敗パターンとして本 wiki に整理されていなかった。判断基準が欠如した場合の 5 Whys の失敗モードが実例で示されたことで、[[仮説駆動RCA]] で言う「仮説を立て・検証する構造」がなぜ必要かの理由が補強された。(Source: [[@2022__SREcon22 EMEA__Principled Identification of Root Causes Using Techniques from Safety Engineering]] p.12・p.5) - X-lifecycle Learning([[@2024__FSE__X-lifecycle Learning for Cloud Incident Management using LLMs]])は「依存サービス障害（IC3 の約 50%）」に X-lifecycle データが有効と示したが、残りの障害種別（コードバグ・ハードウェア障害・設定ミス等）に有効な SDLC 段階の情報源は何か。ソースコード・コミット履歴・設定変更ログ等を組み合わせると、トークン制限と関連性選別の 2 重問題が生じる——「どのライフサイクル段階の情報をどの障害クラスに対して渡すか」の自動選別はどう設計するか。 ## 関連 - 子 concept: [[RCA入力選別]] / [[RCA評価設計]] / [[仮説駆動RCA]] / [[ドメイン別RCA]] / [[Sparkジョブ異常診断]] / [[宣言的RCA]] / [[コード知識強化RCA]] / [[グラフベースRCA]] / [[LLMによる根本原因分析]] / [[ログ解析]] - 親/隣接 concept: [[AIOps]] / [[agentic SRE]] / [[Fault Localization]] / [[障害緩和]] / [[インシデント管理]] / [[限定観測可能性]] - ソース: [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]] / [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] / [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]] / [[@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]] ## 出典 - [[@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 へのデプロイ) - [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]](§4.5 根本原因特定手法、§4.7 手法比較、§6.2 Trusted Distributed AI、Table 10) - [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey]](§4: RCA 26 手法の 2 軸分類(Table 2)・§4.4.3: 相関 ≠ 因果・§4.2.3: MonitorRank パターン・§4.4.4: 説明可能性と対策推奨・§6: 未解決課題) - [[@2024__ISSRE__SparseRCA - Unsupervised Root Cause Analysis in Sparse Microservice Testing Traces]](テスト環境の疎トレース RCA、ExL パターンベース分解、パーソナライズド PageRank) - [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis]](§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 本番デプロイ)