# LLMによる根本原因分析 ## 定義 LLMによる根本原因分析(LLM-based Root Cause Analysis)は、Large Language Model の emergent capabilities(in-context learning、instruction learning、chain-of-thought reasoning)を用いて、システム障害の原因を推定する研究領域。LLM はテキスト形式の異種テレメトリ(alert、log、incident description、SOP)を直接読み、専門家の思考プロセスを emulate して原因推定を行う。 [[根本原因分析]] の親領域に対し、LLM × RCA は (a) 訓練済みモデルの zero-shot/few-shot 推論能力により annotated training data を要求せず、(b) 自然言語で説明可能な分析結果を出力でき、(c) 既存の SOP / runbook / 外部知識を context として活用できる、という特徴を持つ。 ## 横断的知見 - **LLM の "RCA 内での役割" は同一研究領域でも 3 系統に分化する**: 同じ「LLM × 故障解析」でも LLM の責務が分かれる。(1) **外部知識リーダー**: SOP/runbook を読み因果ルールを抽出([[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach|COLA]])。(2) **グラフマッパー**: 多様なテキスト alert を構造化知識グラフ(Service Dependency Graph 等)のノードへ写像([[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs|Zha+ Electronics2024]])。(3) **多因子分析器・因果推論器**: 複数因子の比較と causality mining を chain-of-thought で実行([[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model|VOCE]])。SkyNet が LLM を **採用しない**位置を取るのは、severe network failure では context size 制約 + ハルシネーション耐性が運用上許容できないため(§2.3)。LLM が真に貢献するシナリオは外部知識やドメイン特化 reasoning が必須な層に限定され、scale 駆動の問題(10⁵ デバイス × 10M syslog/15min)には符号化済みヒューリスティクスや構造的アルゴリズムが優位。(Source: [[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach]], [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]], [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]], [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] §2.3) - **LLM が "Chain-of-Thought + 階層分解 + 反復多数決" で安定化する**: 単一プロンプトでは長い incident や複雑な因果推論に失敗するため、LLM ベース RCA は反復的な分解設計に収束しつつある。VOCE([[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model|Chen+ FASE2025]] §4.3)は「source 内 → 隣接 source 間」という階層分解と「k 回反復多数決」(k=5)で accuracy +4.71pt(GPT)/+3.75pt(LLaMA)を達成。CoT 単体や Prompt 単体に対して再現可能な改善を示す。Zha+ 2024 も Phase 2 で LLM を「クラスタ単位」に呼び出し、全アラートを一度に LLM に投げる naive 設計を否定する(§3.2.2 「直接 LLM 適用は impractical」)。長文 context への一発投入を避け、構造化された反復呼び出しに分解する設計が共通する。(Source: [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]] §3.2.2, [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]] §4.3) - **外部知識(SOP / SDG / Topology)が LLM の事実根拠を補強する**: 純粋な LLM プロンプトは hallucination の懸念が大きく、本番運用では deterministic な根拠が要求される。Zha+ 2024 は **Service Dependency Graph** で LLM のマッピング先を制約し(§3.2.2 「LLMs lack sufficient knowledge about the relationships between services」と明示)、VOCE は **System Topology** で causality mining の対象を制約し(§4.3)、COLA は **SOP** で domain knowledge を提供する。LLM 単独では「分かったふりの hallucination」を起こすため、ドメイン知識グラフでの bind が必須。SkyNet は「次世代 LLM の context window が拡張されれば SkyNet の structured output を LLM に流すという integration が成立する」と§8で明示し、LLM × deterministic preprocessing の posterior integration を将来方向として位置づける。(Source: [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]] §3.2.2, [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]] §4.3, [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] §8) - **GPT-4o は accuracy で LLaMA-2 13B を一貫して上回るが時間コストでは劣る**: VOCE(§5.2 RQ1)で GPT-4o は LLaMA-2 13B より accuracy +7.64pt(VOCE)/+6.68pt(CoT)/+9.72pt(Prompt)で一貫して優位。一方時間コストは GPT-4o の方が低い(56.79s vs 279.91s for VOCE)が、これは LLaMA の 8 GPU 並列 vs OpenAI クラウドリソースという比較条件差で、純粋な性能差ではない。商用 LLM 採用は accuracy 優先の場面で説得力を持ち、open-source LLM 採用はデータ機密性・コスト最適化の場面で意味を持つ二分。(Source: [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]] §5.2) - **マルチエージェント分担が LLM 単独より大きく RCA 精度を引き上げるが、"モデル規模" より "役割分担設計" が律速因子である**: mABC(Zhang+ EMNLP Findings 2024)は 7 専門エージェント(Alert Receiver・Process Scheduler・Data Detective・Dependency Explorer・Probability Oracle・Fault Mapper・Solution Engineer)を Agent Chain 上でコラボレーションさせることで、ReAct(単一エージェント・GPT-4-Turbo)を Train-Ticket で RA +11.4、AIOps で RA +8.0 上回った。特筆すべきはアブレーション結果で、マルチエージェント除去が最大の性能低下を引き起こし(w/o Multi-Agent: Train-Ticket RA 38.4、w/o Agent Workflow: 46.2、w/o Voting: 44.8 vs 完全形 54.4)、設計上の優先順位が「役割分担 > 標準手順 > 投票」であることが定量化された。さらに Llama-3-8B ベースの mABC が ReAct(GPT-4-Turbo)を上回った(RA 43.5 vs 38.5)という事実は、モデル規模のスケーリングを役割分担設計が補完・凌駕できることを示す。(Source: [[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]] §3.5, Table 4, Table 7) - **分散型多数決(blockchain-inspired voting)はハルシネーション抑制の実装経路の一つだが、精度への直接貢献は役割分担より小さい**: mABC の投票機構は「エージェントが答えた内容に他の全エージェントが賛否を表明し否決されたら再回答させる」という多数決型ハルシネーション制御を実現する。アブレーションで投票除去(w/o Voting)の精度低下は w/o Multi-Agent・w/o Agent Workflow より小さいが、人間評価(R-Useful)では mABC(GPT-4-Turbo)が 4.2/3.6(Train-Ticket/AIOps)と全手法中最高であり、解決策品質の観点では投票機構の寄与が定量的に確認された。LLM ハルシネーション対策として「外部知識グラフで制約する」([[LLMによる根本原因分析]]の既存知見)とは異なり、エージェント間の動的合意形成で制御する新しいアプローチである。(Source: [[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]] §2.4, Table 6, Table 7) - **監視データなし設定でコードベースが LLM の推論補助として機能する**: COCA([[@2025__arXiv__COCA - Generative Root Cause Analysis for Distributed Systems with Code Knowledge]])は JIRA/GitHub Issues のイシューレポートのみが利用可能な設定において、静的解析でログソースをコード行に対応付けて実行パスを再構築し、LLM に提供することで [[RCACopilot]] 比 Exact Match +28.3%・BLEU-4 +22.0% を達成した。「外部知識リーダー」「グラフマッパー」「多因子分析器」に続く **コード実行ロジック読解器** として LLM を機能させた初の事例であり、LLM の役割分化に新たなカテゴリが加わった。5 種の LLM(GPT-4o・GPT-3.5・LLaMa-3.1-405b・Claude-3.5-Sonnet・Gemini-1.5-Pro)すべてで Exact Match 平均 +43.3% という汎化性は、コード知識付与がモデル非依存の改善手法であることを示す。(Source: [[@2025__arXiv__COCA - Generative Root Cause Analysis for Distributed Systems with Code Knowledge]] Tables II, IV) - **「最終回答品質」と「プロセス品質」は独立して評価すべきであり、流暢な最終回答は説明責任の根拠として不十分**: JustDiag の二層評価プロトコルで、RCAgent と Flow-of-Action の Process Score はそれぞれ 9.5・9.3 と一桁台にとどまる。一方 Outcome Score は 44.3・42.8 と中程度であり、最終回答の品質とプロセスの監査可能性に大きな乖離がある。「診断ジャーナリング」を持たない LLM ベース RCA は、いかに流暢な説明を生成しても、本番インシデントに必要な「何を根拠に・どの代替を検討したか」を記録しない設計であることが定量化された。(Source: [[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]] §4.2) - **説明責任ある RCA は「診断的正当化アーティファクト」のエクスポートを要求する**: JustDiag([[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]])は、証拠・発見・競合仮説・矛盾・終端状態をエクスポート可能な JSON アーティファクト(`diagnosis_conclusion.json` / `diagnostic_graph_debug.json`)に書き出す設計を採用する。Chain-of-Thought による隠れた推論トレースとは異なり、このアーティファクトはジャッジ・人間オペレーターが独立に評価できる安定した形式を持つ。説明責任という概念を「監査可能な構造化出力の有無」として操作化した点が先行研究にない設計上の選択。(Source: [[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]] §3, Appendix A-D) - **オンコール QA（インシデント対応）は RCA より広い問題設定であり、LLM は「解決策生成」の文脈でも単独より多エージェント協調が有効**: OncallX(Fu+ ASE 2025)の実験では、同一 GPT-3.5 バックボーンで Direct(72.46%)→ ReAct(71.01%)→ OncallX(78.26%)という性能順序が確認された。特筆すべきはユーザー意図強化モジュール（RAG + 多ターン対話）の除去がパス率 −10.14pt かつトークン使用量を倍増させた点で、「あいまいな入力に対して LLM が無闇にトークンを消費しながら誤回答する」という既知の挙動が実証された。RCA ドメイン(mABC・JustDiag)で観察された「入力品質が LLM 推論品質の律速因子」という知見がオンコール対応にも一般化する。(Source: [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]] §V-B, Table I, Table III) - **LLM は「主推論エンジン」より「効率的ラベラー」として限定活用する設計がワンショット設定でのコスト制約を突破する**: LasRCA(Han+ ASE 2024)は各障害タイプに 1 件のみ障害ラベルが存在するワンショット設定で、LLM を全エンティティの推論担当にするのではなく「小型分類器が高混乱と判定したサンプルへのラベル付け担当」に限定した。この設計で全件 LLM 依存比のエンティティ関与数を約 10 分の 1 に削減しつつ、全ベースライン(DiagFusion・DejaVu・CIRCA・TraceRCA)を大幅に上回る精度を達成した。LLM の活用範囲を「コストが許容できる小さな判断集合」に絞り、小型分類器の反復学習と組み合わせることが、コスト制約下での LLM × RCA の実用的な設計原則として浮上する。(Source: [[@2024__ASE__The Potential of One-Shot Failure Root Cause Analysis - Collaboration of the Large Language Model and Small Classifier]] §4, §5.4) - **数値メトリクス系列の増減判定という基礎タスクで小規模 LLM と GPT-4 の間に実用上の性能断絶がある**: LasRCA の評価で Mistral-7B・Gemma-7B は「負の値の並びから上昇傾向を誤認する」幻覚を起こし、CPU Load 障害タイプを誤検知した。GPT-4 は同一入力で正確に「メトリクスは上昇していないため CPU Load 障害特徴に一致しない」と正しく判定した。RCA でメトリクス時系列を LLM に読ませる場合、小規模 LLM はこの基礎的タスクで信頼性が低く、大規模モデルの採用が事実上の要件となる。(Source: [[@2024__ASE__The Potential of One-Shot Failure Root Cause Analysis - Collaboration of the Large Language Model and Small Classifier]] §6.1, 図 11) - **2021〜2024 年 SLR で LLM は RCA/異常検知の主要手法(38.7%)として急台頭し、mABC はユーザースタディを実施した 5 件に入る**: [[Dahlia Ziqi Zhou]]・[[Marios Fokaefs]]([[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]])が 31 件を対象に実施した SLR では、LLM ベース手法が 38.7% を占め深層学習(32.2%)を上回る最多手法となった。2023 年以降の急増が特に顕著であり、RCAgent・LLMAD・GenKubeSec などが代表例として引用される。また SLR は 31 件中ユーザースタディを実施したのは OASIS・Groot・LLMAD・Zhang+[24](=[[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture|mABC]])・Zhang+[25] の 5 件のみと指摘する——本 wiki で詳述した mABC がユーザースタディ実施論文の一つとして独立に確認されたことは、研究の実用性への取り組みとして一定の評価軸となる。ただし SLR は本番デプロイ実績よりもベンチマーク評価を優先した 31 件を分析しており、本 wiki の SREcon26 知見(本番精度 11.34%)との乖離は研究–実用の断絶として引き続き未解決である。(Source: [[@2024__arXiv__AI Assistants for Incident Lifecycle in a Microservice Environment - A Systematic Literature Review]] RQ3・考察) - **本番インシデントでの実測精度は 11.34% にとどまり、AI は誤答を自信満々に提示する**: 研究環境での高精度と本番実環境での性能の乖離は以前から懸念されていたが、SREcon26 Americas の発表([[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]])が定量化した。3 つのエンタープライズシステム・335 件の実障害ケース・68GB 以上のテレメトリデータを用いた実験で、最高性能の Claude 3.5 Sonnet に専用 RCA エージェントを組み合わせた構成でも精度 11.34% しか達成できなかった。さらに「AI はただ幻覚するだけでなく、**自信満々に**幻覚する」——モデルは正確さに関係なく自信満々な説明を常に生成した。VOCE が研究環境で GPT-4o により 88.90% を達成するのとは大きく乖離しており、データセット・タスク定義・本番テレメトリの複雑さが研究–本番間のギャップを生んでいると考えられる。(Source: [[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]] p.12) - **ハイパースケール本番での構造的制約付き LLM RCA が最強ベースライン比 +31% を達成した初の事例が登場した**: KRCA([[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]])は快手(20万超サービス、1日4億人)で「LLM 直接適用はコンテキスト爆発する」という本 wiki の観察([[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]]、精度 11.34%)を「探索空間の事前圧縮 + 構造的事前知識 + 多エージェント分業」で突破し、AC@1=0.88(根本原因サービス)/0.79(障害種別)を達成した。ReAct・Reflexion・RCA-Agent という単一 LLM ベースのベースライン4手法に対して全設定で一貫して優位であり、特に「100以上の異常サービスを含む複雑なケース」でベースラインがコンテキスト爆発で回答不能に陥る一方 KRCA は安定稼働した。「LLM ベース RCA の本番精度 11.34%」(SREcon26)と「KRCA AC@1=0.88」(ASE'26)の乖離は、対象システムの規模・テレメトリの品質・探索空間の設計の差に起因すると考えられ、単純に矛盾するのではなく「構造化なし vs 構造化あり」の比較として読み直せる。(Source: [[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]] §4.2, Table 1) - **マルチエージェントのドメイン特化分業は「役割分担の精度への寄与」が「モデル規模スケーリング」より大きいことを KRCA とmABC の両方で確認した**: mABC([[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]])では「マルチエージェント除去」が最大の性能低下をもたらし Llama-3-8B ベースの mABC が ReAct(GPT-4-Turbo)を上回った。KRCA では「マルチエージェント除去」でサービス AC@1 が 0.88→0.75 に低下した(Table 2)。両者の独立した実証が「役割分担設計がモデル規模より精度を律速する」という同じ観察に収束する。ただし KRCA の分業設計は「9種のドメインに対応したサブエージェント(Traffic/CPU/GPU等)」であり、mABC の「調査プロセスの役割分担(データ収集・依存探索・確率推定)」とは分業の軸が異なる。両者の比較から「何を専門化すべきか(ドメイン vs プロセス)」という設計空間の問いが浮かぶ。(Source: [[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]] §4.3, Table 2; [[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]] Table 4, Table 7) - **「スケルトン構造制約 + LLM 推論」の組み合わせは「LLM の過信防止」の新しい実装パターンを提供する**: KRCA の LLM-Constrained 設定(スケルトン制約あり)は LLM-Unconstrained 設定と比べ、異常メトリクス数が20の時点で精度を60%超に維持した(無制約は30%に急落)。この観察は「外部知識グラフで LLM の出力先を制約する」(mABC・SkyNet・Zha+)という本 wiki の既存知見の亜型として位置づけられるが、KRCA のスケルトンは「どのメトリクスがどのメタ型に属するか」という帰属グラフであり、サービス依存グラフや SOP ルールベースとは異なる形式の構造制約である。「帰属型制約」という新しいカテゴリとして整理できる可能性がある。(Source: [[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]] §2.2, Fig.2(b)) - **LogSage は LLM を「グラフ推論の代替」ではなく「スパースな障害指示ログの要約器」に限定活用し、根本原因の分類自体は GNN(GraphSAGE)+ 能動学習に委ねる——本 concept が整理する「LLM の役割分化」に新しいカテゴリを加える**: LogSage([[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]], FCS 2025)の FILE モジュールは、DeepSeek-V3・LLaMA 3-8B・Mistral-7B の 3 LLM を CoT(障害の手がかり特定→根本原因の推論→最終要約生成の 3 ステップ)で使い、教師なしクラスタリングで絞り込んだ**最新クラスタのみ**に LLM 呼び出しを限定する。本 concept が整理してきた「外部知識リーダー」「グラフマッパー」「多因子分析器」「コード実行ロジック読解器」に続く**要約特化器**という役割分化であり、根本原因の最終分類は GARCA(GraphSAGE + 能動学習)という非 LLM コンポーネントが担う。これは KRCA の「スケルトン構造制約 + LLM 推論」(帰属型制約)とも異なり、LLM の出力自体を最終判断に使わず**中間表現(要約)の生成**にのみ限定する設計である。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §3.1.2) - **LLM バックボーンの比較で DeepSeek-V3 が LLaMA 3・Mistral 7B を全指標で上回り、精度と速度のトレードオフが再確認された**: LogSage の RQ2(§4.3)では DeepSeek-V3 が 3 データセット全てで最高性能(D1: F1=92.2)、LLaMA 3 がやや劣る(F1=87.7〜90.2)、Mistral 7B が最低精度ながら最速推論(2.45〜2.50s)という結果を示した。本 concept が VOCE で確認した「GPT-4o が LLaMA-2 13B を accuracy で一貫して上回るが時間コストでは劣る」というトレードオフと同型のパターンが、要約特化タスクという異なる LLM 応用でも再現された。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §4.3, Fig. 3) - **静的 RAG(VectorRAG/GraphRAG/LinearRAG)から状態条件付き動的検索(CMR)への移行が、外部知識制約という既存知見に新しい軸を加える**: 本 concept は「外部知識(SOP/SDG/Topology)が LLM の事実根拠を補強する」ことを Zha+ 2024・VOCE・COLA から確認してきたが、これらはいずれも診断開始時または固定粒度で 1 回検索する静的設計である。OpsMem([[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]])は GoS に VectorRAG・GraphRAG・LinearRAG を組み合わせた 3 ベースライン全てを上回り(最強ベースライン比 Match +6.66〜25.00pt)、その差分の要因を「検索された知識が進行する診断状態と明示的に整合しない」ことに帰属させる(§I)。アブレーションで CMR 除去による低下(Match 78.33→56.67)は、STM 除去(→45.00)より小さいが LTM 除去(→30.83)に迫る規模であり、「外部知識を持つこと」自体より「外部知識を診断状態に応じて動的に再活性化すること」が精度を左右するという、本 concept の外部知識制約パターンへの精緻化を提供する。(Source: [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] §I, §IV-B Table I, §IV-C Table II) - **失敗診断における「経験の自己蓄積」は、本 concept が扱う LLM の役割分化に「経験蒸留器」という新しいカテゴリを示唆する**: OpsMem の Long-Term Memory Consolidation は、解決済みインシデントの診断トレースを MetaAgent が要約・reflect し、Procedure/Pattern/Case の各メモリエージェントが CREATE/DELETE 操作を提案してマルチエージェント自身の出力から新しい運用経験を蒸留する。RQ3(Table III)では、この consolidation を持つ OpsMem が持たないバリアントより 4 つの連続インシデントウィンドウ全てで追加的に正しく診断できるインシデント数が多く、時間とともに性能が向上することを示した。本 concept が整理してきた「外部知識リーダー」「グラフマッパー」「多因子分析器」「コード実行ロジック読解器」「要約特化器」に続き、**自身の診断結果から次に使う知識を生成する「経験蒸留器」**という役割が加わる。ただし利得は各ウィンドウ最大 +5 ポイント(Match)にとどまり、劇的な自己進化ではなく漸進的改善である点には注意が必要。(Source: [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] §III-D, §IV-D Table III) - **障害の「親子関係(MFS と親シナリオ)」を差分プロファイルとして与える設計は、本 concept が整理してきた「外部知識制約」とは別軸の「証拠の構造化」でハルシネーションを抑える**: 本 concept はこれまで SOP/SDG/Topology のような**外部知識**で LLM の出力先を制約するパターン(Zha+ 2024・VOCE・COLA・KRCA のスケルトン制約)を蓄積してきたが、[[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]] の DPGD(Differential Profiling Guided Diagnosis)は外部知識でなく**同一システムの実行結果の対比**(MFS とその親シナリオの差分: 構造変化 $\Delta_{struct}$・RED メトリクス $\Delta_{RED}$・例外 $\Delta_{exc}$)を証拠として与える。障害探索(FaultWeave 前半)が自然に生成する MFS 構造を診断入力に転用する設計であり、Rule-Based Validator が「LLM が参照したメトリクスが実際に Δ Profile に存在するか」「値が一致するか」を決定論的にチェックして不合格ならプロンプトへフィードバック(最大3回リトライ)する点は、mABC の投票機構や JustDiag の正当化アーティファクトとは異なる**事後検証によるハルシネーション抑制**の実装である。286件のMFS診断のうち66.1%が完全正確、18.5%が部分正確、4.5%が手動修正を要したという内訳は、本 concept の SREcon26 実測(11.34%)や KRCA(AC@1=0.88)と並べると、対象システムの複雑度・証拠構造の質がLLM RCA精度に与える影響の別サンプルとなる。(Source: [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]] §3.4, §5.3.3) - **「複数障害の相互作用効果」に特化した診断ターゲットは、本 concept が扱ってきた単一障害・単一根本原因の RCA とは異なる問題設定を提示する**: FaultWeave の DPGD が解く問い(「なぜ {Fa, Fb} は失敗するが両方の親シナリオ({Fa} 単独・{Fb} 単独)は合格するのか」)は、mABC・VOCE・KRCA 等が前提とする「単一の根本原因を特定する」タスクと異なり、**複数の正常な要素が組み合わさることで生じる emergent failure** を LLM に説明させる。Figure 4 の Fallback-CircuitBreaker Conflict 例(フォールバック機構とサーキットブレーカーという個別には正しい2つの耐障害機構が、組み合わさると互いの意図を阻害する)は、根本原因が単一コンポーネントの欠陥でなく**複数機構の設計上の相互作用**にある障害の診断を LLM に担わせた事例であり、本 concept が蓄積してきた診断ターゲットの型に新しいカテゴリ(相互作用障害の説明)を加える。(Source: [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]] §3.4.4, Figure 4) - **「失敗の帰属を推論失敗とデータ不足に分解する」reverse reasoning agent は、本 concept が蓄積してきた誤り分析手法(JustDiag の Process Judge・OpenRCA 2.0 の PAVE)に「正解が既知の後付け(post-hoc)診断」という新しい形式を加える**: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]]([[QPIAI]] India)の reverse reasoning agent は、誤った Stage 1 予測ごとに正解の根本原因から抽出済みアノマリーまでのエビデンスチェーンを再構築し、各次元(コンポーネント・reason・タイムスタンプ)を Reasoning Gap(証拠は Stage 1 の取得データ内に存在したが使われなかった)か Data Ambiguity(証拠が全ソースから真に不在)に分類する。JustDiag の Process Judge がエージェント自身の推論トレースを外側から評価するのに対し、reverse reasoning agent は**正解ラベルを起点に逆方向にエビデンスチェーンを構築**する点で異なる。Market CB1(DK OFF)の分析では reason 次元で 65.7% が Type 1(Reasoning Gap)、Type 2(Data Ambiguity)はわずか 11.4% であり、「アノマリー抽出はほぼ完璧だが、モデルがそれを正しく使えない」という診断がベンチマーク全体を通じて一貫する。この設計は「最終回答一致率より診断プロセスの構造的品質を見る」という [[RCA評価設計]] の潮流(OpenRCA 2.0・JustDiag)に、正解ラベルを用いた**ポストホックな帰属**という具体的な実装を提供する。(Source: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] §III-D, Table VII) - **同一の「本番/高難度ベンチマークで精度が大きく低下する」パターンが、SREcon26 の実運用データ(11.34%)と OpenRCA 上の GALA・RCLAgent 再評価(2.56%・0.00%)の双方で確認された**: 本 concept は SREcon26([[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]])が本番 335 障害で Claude 3.5 Sonnet + 専用 RCA エージェントでも 11.34% しか達成できないことを記録してきた。[[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] は別の高難度ベンチマーク(OpenRCA、64GB マルチモーダルテレメトリ)上で [[GALA]](RCAEval では AC@1 最大 42.22%)を Accuracy@1=2.56 に、[[RCLAgent]] を Accuracy@1=0.00 に落とす結果を示した。両者は異なるベンチマーク・異なる手法だが、「研究環境の合成/中規模ベンチマークで高精度な LLM ベース RCA が、本番規模のマルチモーダル性・低観測性・短時間ウィンドウという条件が重なると精度崩壊する」という同一パターンの独立した実証例として並べられる。GALA の失敗要因(フェーズ1因果グラフのリコール依存)・RCLAgent の失敗要因(トレースツリー依存でノードレベル障害を検知不能)はいずれも、ベンチマークの前提条件からの逸脱として説明可能であり、KRCA が示した「構造化なし vs 構造化あり」の対比が OpenRCA という第三のベンチマークでも再現された。(Source: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] Table I, §V-B, Appendix B-B) - **「非 LLM 因果推論ベースライン(Granger/PC/FCI/LiNGAM/NTLR)が Accuracy@1・@10 とも全て 0」という結果は、[[因果推論ベースRCA]] の既存知見(辺方向推定のボトルネック・大規模グラフでの性能崩壊)をさらに極端なデータ制約下で再確認する**: [[因果推論ベースRCA]] は Pham+ ASE 2024 の 30 タイムスタンプでの性能崩壊を既に記録しているが、本論文も同じ制約(OpenRCA は 1 ウィンドウ 30 タイムスタンプ)下で全ての古典的因果発見手法が完全に無力化されることを独立に確認した。LLM ベース手法(GALA・RCLAgent・OpenRCA agent)と非 LLM 因果推論の両方が同じベンチマークで失敗するという構図は、「OpenRCA の難しさは特定のアーキテクチャの欠陥ではなく、データ制約(短時間ウィンドウ・低サンプル数・多モダリティ)自体に起因する」という、本 concept と [[因果推論ベースRCA]] を横断する統一的な観察を支持する。(Source: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] Table II, §V-A) - **手作業ドメイン知識キュレーションの「体系化・自動化」が LLM ベース RCA の実用化のボトルネックとして新たに前景化する**: 本 concept は既に「外部知識(SOP/SDG/Topology)が LLM の事実根拠を補強する」ことを蓄積してきたが、その外部知識自体の構築コストは従来 ad hoc な手作業とされてきた(OpsMem の LTM 構築が GPT-5.4 抽出で担うにせよ人的コストが未評価であるのと同様)。[[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] は reverse reasoning レポートを基盤とした 3 フェーズ(Mine → Cluster → Consolidate)の自動化ルールマイニングパイプラインを導入し、CB1 で学習した知識を CB2(held-out)に適用してもキュレーション済み DK ON を上回ることを示した(Full 35.90 vs 24.36)。これは「ドメイン知識の構築コストを下げる」という課題に対する具体的な解であり、本 concept が蓄積してきた LLM の役割分化(外部知識リーダー・グラフマッパー・多因子分析器・コード実行ロジック読解器・要約特化器・経験蒸留器)に**知識マイナー**という新カテゴリを加える可能性を示す。(Source: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] §III-E, Table III, §V-D) ## 未解決の問い - **reverse reasoning agent の「後付け診断」がリアルタイム運用に転用可能か未検証**: reverse reasoning agent は正解ラベルを既知として使う post-hoc 分析であり、本番運用時(正解が未知)には直接使えない。Reasoning Gap/Data Ambiguity の分類を正解なしで推定する(例えば複数の候補仮説を比較して証拠の充足度を自己評価する)機構は本論文で提示されていない。JustDiag の Process Judge のようにリアルタイムに動く不確実性管理と reverse reasoning の知見(証拠は大半存在する)を統合する設計は未着手。(Source: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]]) - **自動化ルールマイニングパイプラインは Market CB1 のみで検証され、Telecom・Bank への拡張と、複数ドメインをまたぐルールの transferability は未検証**: CB1→CB2(同一トポロジ)の held-out 転用は成功したが、トポロジ・障害語彙が異なる Telecom・Bank でマイニングされたルールがどこまで汎化するか、あるいはドメインごとに独立にマイニングする必要があるかは著者自身が将来課題としている。(Source: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] §VI) - **DPGD の Rule-Based Validator による事後検証と、本 concept の他の検証パターン(mABC の投票・JustDiag の正当化アーティファクト)を統一的に比較評価する研究はない**: 3種の検証機構(決定論的メトリクス照合・エージェント間多数決・構造化アーティファクトのエクスポート)は、いずれも「LLM の主張を裏付ける根拠の有無」を扱うが、対象とする失敗モード(存在しない証拠の参照 vs 単純な誤答 vs 監査不可能性)が異なる。同一データセット上でこれら3種を比較し、どの検証機構がどの失敗モードに最も有効かを実証する研究が求められる。([[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]], [[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]], [[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]]) - **MFS の親子関係(差分プロファイル)を診断入力に使う設計は、障害注入によって「既知の障害」を診断する評価であり、本番で実際に発生した未知の障害(親シナリオが人為的に制御されていない実インシデント)にどこまで一般化するか未検証**: FaultWeave の診断精度(66.1%完全正確)は、探索フェーズが完全に制御した MFS/親シナリオのペアに対する評価であり、SREcon26 が報告する本番インシデントでの実測精度(11.34%)とは前提が大きく異なる。制御された差分プロファイルの質(親シナリオの明確さ)が精度に寄与する割合はどれほどか、実インシデントで同等の差分プロファイルを構築できない場合に DPGD 型の診断はどこまで機能を維持するか。([[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]], [[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]]) - **LogSage の LLM 要約(FILE)の忠実性・幻覚リスクは体系的に評価されていない**: 本 concept が SREcon26 で確認した「AI は誤答を自信満々に提示する」という観察は、LogSage の要約生成ステップにも当てはまりうるか。LogSage は CoT で投機を避けるようプロンプト設計されるが、人手評価やハルシネーション率の定量測定は論文内に記載がなく、要約が下流の GARCA 分類にどう影響するかも未測定。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]]) - **LLM の hallucination 発生率と RCA 精度の関係**: VOCE は GPT-4o で accuracy 88.90% を達成するが、「誤った因果推論」を「自信満々に」出力する hallucination は本論文で測定されていない。誤分析の corner case を engineer が見抜けない場合、自動化が逆効果になる可能性。SREcon26 の 11.34% 実測値はこのリスクが本番で現実化していることを示唆する。 - **マルチエージェント RCA のコスト・スケーラビリティ限界**: mABC は 7 エージェント × ブロックチェーン投票という設計でエージェント数とアラートイベント数に比例して計算コストが増加する。現実の大規模 MSA(数百サービス、秒間数万アラート)での適用可能性は未実証。投票を省略したときの精度低下は小さいが、役割分担を簡略化した場合の性能限界はどこか。(Source: [[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]] §7) - **LLM 不採用設計(SkyNet)と LLM ハイブリッド設計(VOCE / Zha+ 2024)を同一データセット上で比較した実証**は未着手。データセット規模(数千〜数万 alerts)と severity(daily incident vs annual severe failure)で何が決定的因子か。 - **context window 拡張(Gemini 1.5 / Claude 3 / 100M token LLM)で SkyNet が "LLM 不採用" 立場を変えるか**: SkyNet §2.3 の根拠の (a) context size 制約と (c) reliability/hallucination 耐性は別問題で、(a) のみが解消されても (c) は残る。両者の独立性を分けた実証が必要。 - **multi-LLM cooperative RCA**: VOCE 1 つの LLM を反復呼び出すが、複数の LLM(GPT-4o + Claude + Gemini)の多数決や役割分担(分析 LLM + 検証 LLM)が精度をどう変えるかは未検証。 - **診断的正当化コストと Process Score のトレードオフの一般化**: JustDiag は DJ なし対照群より約 41% 多いトークン・45% 多い時間を要する。この追加コストが許容可能かどうかは障害の重大度・コスト制約・組織の説明責任要件によって異なる。コスト削減と Process Score 維持を両立するアーキテクチャ探索は未研究。 - **continuous improvement**: 本番運用で誤判定したケースを LLM の next call に反映する機構(retrieval-augmented memory、fine-tuning など)はどう設計すべきか。 - **コードベースへのアクセスが LLM RCA の前提条件となるか**: COCA は対象システムのソースコードにアクセスできることを前提とする。クローズドソースのクラウドサービス・サードパーティライブラリ・バイナリのみが利用可能な設定ではコード知識強化が機能しない。監視データが豊富な本番 AIOps 設定ではコード知識の付加価値がどれほどあるか未検証。(Source: [[@2025__arXiv__COCA - Generative Root Cause Analysis for Distributed Systems with Code Knowledge]] §VI-C) - **変更管理ドメインでの RAG vs fine-tuning の選択**: SCELM([[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]])はデータ不足・リアルタイム要件・機密制約が重なる変更管理では fine-tuning より RAG が実用的だと主張し、実験で RAG あり/なしの cosine 類似度差(D1: 0.840 vs 0.567、D2: 0.968 vs 0.778)を示した。一般的な LLM×RCA の文脈での「どの手法を選ぶか」という問いへの実証的根拠の一つとなる。 - **OpsMem の signal coupling・pattern activation の閾値(0.6・等重み)は感度分析されていない**: cross-memory resonance の中核パラメータであるにもかかわらず、これらの値がどう選ばれたか・他の値でどう性能が変わるかは論文に記載がない。VectorRAG/GraphRAG/LinearRAG との比較でも、検索対象の知識源は同一に揃えられているが、活性化閾値というハイパーパラメータの頑健性は未検証。(Source: [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] §IV-A5) - **LTM の事前構築コストと構築品質が下流精度にどう影響するかは未評価**: OpsMem の LTM はインタビュー・アンケート・運用文書から GPT-5.4 で抽出構築される(§IV-A4)。この構築コスト(人的コスト・LLM 抽出精度)が診断精度にどれだけ寄与するかは分離実験されておらず、LTM の初期構築なしに CMR だけを追加した場合の効果(≒コールドスタート性能)も不明。(Source: [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] §IV-A4) - **13 エージェントへの役割分割 + 名前が同じ"OpsMemory"を持つが別実装の共有ブラックボードという、mABC / OpsMem とは異なる第 3 のマルチエージェント設計が実運用で確認された**: [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]]([[Strands Agents]] + Amazon Bedrock AgentCore)は、RCA operator・Known-incident matcher・Root-cause finder・Anomaly correlator・Forecast-drift monitor など 13 の専門エージェントに機能を分割し、"OpsMemory" という共有ブラックボードで中間出力を交換する。mABC([[@2024__EMNLP Findings__mABC - Multi-Agent Blockchain-inspired Collaboration for Root Cause Analysis in Micro-Services Architecture]])のブロックチェーン投票型合議、OpsMem([[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]])の短期/長期デュアルメモリ + cross-memory resonance と比べ、AWS 版の"OpsMemory"は単純な中間出力共有ブラックボードとして説明されており、合議機構や resonance のような明示的な検証層を持たない。同名の "OpsMem(ory)" が独立に 2 系統存在することは、マルチエージェント RCA の実務(ブログ記事)と研究(論文)で用語が収束していないことを示す。エージェントの機能分割自体は Neptune Analytics のグラフアルゴリズム実行(Root-cause finder)・SageMaker 異常検知呼び出し(Anomaly correlator)など、決定論的な下流ツール呼び出しを LLM エージェントがオーケストレーションする設計であり、本 concept の他事例(VOCE・RCAgent)がツール呼び出しを LLM 自身の推論ループに統合するのに比べ、パイプライン各段の責務分離がより明示的である。(Source: [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]]) ## 関連 - 親概念: [[根本原因分析]]、[[AIOps]] - 兄弟概念: [[Chain-of-Thought Prompting]]、[[アラートインシデント分析]] - 関連手法: VOCE(Chen+ FASE2025)、Zha+ Electronics2024、COLA(Kuang+ ICSE-SEIP2024)、Ahmed+(ICSE 2023)、NetAssistant(NSDI 2024)、MonitorAssistant(FSE 2024)、RCAgent(CIKM 2024)、SCELM(Sun+ FSE Companion 2025) - LLM 不採用の対比: SkyNet(Yang+ SIGCOMM2025、severe failure × 10⁵ デバイススケールで LLM を意図的に避ける) - ソース: [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]] / [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]] / [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] / [[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]] / [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]] / [[@2025__arXiv__COCA - Generative Root Cause Analysis for Distributed Systems with Code Knowledge]] / [[@2024__ASE__The Potential of One-Shot Failure Root Cause Analysis - Collaboration of the Large Language Model and Small Classifier]] / [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] / [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] / [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]] / [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] - [[ワンショットRCA]] — LLM × 小型分類器のコスト制約下設計の詳細 - [[障害注入]] — FaultWeave の障害探索フェーズ(MFS 生成)との接続 - エンティティ: [[GALA]] / [[RCLAgent]] / [[OpenRCA]] / [[QPIAI]] ## 出典 - [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]](Strands Agents による 13 エージェント構成、OpsMemory 共有ブラックボード、NTT DOCOMO 実装) - [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]](Gopal & Krishnan, QPIAI India, arXiv 2026-07 — reverse reasoning agent による Reasoning Gap/Data Ambiguity 分類、GALA・RCLAgent の OpenRCA 再評価、自動化ルールマイニング) - [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]] §3.4(DPGD 設計・差分プロファイル・Rule-Based Validator)、§3.4.4(Fallback-CircuitBreaker Conflict 診断例)、§5.3.3(診断精度の内訳) - [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]] §3.2.2(LLM × Service Dependency Graph) - [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]] §4, §5(VOCE 設計と実験) - [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] §2.3, §8(LLM 不採用の根拠と posterior integration) - [[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]] §4(3 モジュール設計)、§5.4(RAG vs no-RAG 実験)、§5.6(LLM パラメータ規模比較) - [[@2025__arXiv__COCA - Generative Root Cause Analysis for Distributed Systems with Code Knowledge]] §III(4 フェーズ設計・RPCBridge)、§V(Tables II・III・IV：アブレーション・汎化性実験)、§VI(ケーススタディ・実用性) - [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §3.1.2(FILE の LLM 要約設計・CoT 3 ステップ)、§4.3(RQ2 LLM バックボーン比較) - [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] §I(動機・新規性)、§III(dual-memory 手法)、§IV-B/C/D(Table I/II/III：全体性能・アブレーション・自己進化)