# 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 として活用できる、という特徴を持つ。 ## 子概念 - [[Change Object Rewrite]] - [[ReAct]] - [[アラートインシデント分析]] - [[アラート集約]] - [[エージェント修復]] - [[グラフベースRCA]] - [[コード知識強化RCA]] - [[ドメイン別RCA]] - [[マルチエージェント協調]] - [[診断的正当化]] ## 横断的知見 - **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) - **本 concept が蓄積してきた「LLM の RCA 内での3系統の役割分化」(外部知識リーダー/グラフマッパー/多因子分析器)は、AIOps 全域を横断するサーベイが独立に見出した「特徴抽出器→コパイロット→自律エージェント」という3層構造と対応する**: [[@2026__TOSEM__Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations - Chapter 5 Transformers in AIOps Domain]] §5.3.4 は、イベント分析(障害理解・RCA)における Transformer の役割を、(1) 特徴抽出器(BERT等でセマンティック情報を抽出するのみ)、(2) コパイロット(文脈知識と代表例を統合してオンコールエンジニアに洞察を提供、RCACopilot・Ahmed et al. 等)、(3) 自律エージェント(RCAgent・OpenRCA・FlowXpert等、環境と動的に相互作用し実行まで担う)の3層に整理する。本 concept の「グラフマッパー/知識リーダー」は主に(1)〜(2)の層に、「多因子分析器・因果推論器」は(2)の高度な形態に対応し、mABC・RCAgent 等のマルチエージェント系は(3)の自律エージェント層に位置づけられる。両分類は独立に生成されたにもかかわらず「単純な情報抽出→人間支援→自律実行」という同一方向の進化軸を示しており、本 concept の知見が AIOps 全体のパターンの一事例であることを裏づける。(Source: [[@2026__TOSEM__Why Transformers - A Comprehensive Overview of Transformers in Artificial Intelligence for IT Operations - Chapter 5 Transformers in AIOps Domain]] §5.3.4) - **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% を達成するのとは大きく乖離しており、データセット・タスク定義・本番テレメトリの複雑さが研究–本番間のギャップを生んでいると考えられる。なお登壇者は口頭説明で「その後、別アプローチにより成功率は約80%まで改善されたと認識している」とも述べているが、一次情報源は口頭でも示されておらず未検証(スライド非記載・信頼度低)。(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) - **mABC・RCAgent という本 concept が既に詳述してきた2つの LLM ベース RCA エージェントが、独立した後付け修復レイヤーの実証対象として再登場した**: 本 concept は mABC(多エージェント・ブロックチェーン投票)と RCAgent(単一エージェントの軽量ワークフロー)を「マルチエージェント分担が精度を引き上げる」「ツールインターフェース設計が RCA 精度を律速する」という2つの異なる観点から扱ってきたが、[[@2026__arXiv__STAR - A Stage-attributed Triage and Repair framework for RCA Agents in Microservices]] はこの両者を「ベースエージェントの推論トレース生成器」として横並びに扱い、その上に共通の後付け修復レイヤー(STAR)を適用した。RCAgent(弱いベースライン)は mABC(強いベースライン)よりも STAR から一貫して大きな相対的利得を得る(例: Dataset A・GPT-5 で RCAgent は Acc@1 +24.9pt、mABC は +19.0pt)。これは、本 concept が既に記録した「役割分担設計がモデル規模より精度を律速する」(mABC のマルチエージェント除去アブレーション)という知見に、「ベースエージェントの初期推論品質が低いほど、後付けのステージレベル修復から得られる利得が大きい」という第3の軸(修復可能性)を追加する。(Source: [[@2026__arXiv__STAR - A Stage-attributed Triage and Repair framework for RCA Agents in Microservices]] §V-C) - **RCA トレースを EP/HS/AS/DR の4段階アーティファクトへ明示的に分解する設計は、本 concept が蓄積してきた「LLM の役割分化」の議論とは異なる軸——「エージェント自身の失敗の構造化」を提供する**: 本 concept はこれまで LLM が RCA プロセス内でどう使われるか(外部知識リーダー・グラフマッパー・多因子分析器・コード実行ロジック読解器・要約特化器・経験蒸留器・知識マイナー)を蓄積してきたが、STAR はこれと直交する問い——「LLM ベース RCA エージェントの出力自体がどこで壊れたか」を扱う。JustDiag の Process Judge(§本 concept 既存知見)がプロセス品質を事後的に採点するのに対し、STAR は診断結果に基づいてステージ単位でパッチ・再実行までを行う点で、単なる評価を超えた修復レイヤーである。[[エージェント修復]] が扱う AgentTether・PROBE(汎用エージェントタスクの TU 粒度帰属)と対をなす、RCA ドメイン特化の帰属・修復手法として本 concept と [[エージェント修復]] の橋渡しになる。(Source: [[@2026__arXiv__STAR - A Stage-attributed Triage and Repair framework for RCA Agents in Microservices]] §III, §IV) - **診断対象を「マイクロサービス/クラウドインシデント」から「LLM 推論基盤そのもの(GPU カーネル・CUDA API・分散通信)」へ下げた初の事例が登場し、本 concept が蓄積してきた「モダリティ融合」「文脈圧縮」の議論に新しい層を加える**: 本 concept のこれまでの知見はほぼ全て、サービス/インスタンス粒度で observability データ(alert・ログ・SOP・topology)を読む LLM RCA を扱ってきたが、[[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]](TELLER、ASE '26)は診断対象を LLM 推論エンジン自身(vLLM/SGLang)の内部——エンジン・CUDA ランタイム・GPU カーネル・NCCL 通信——に置く。診断粒度が「どのサービスが壊れたか」から「どの GPU カーネル呼び出しが根本原因か」まで一段下がる点が、本 concept の他ソースと質的に異なる。TELLER が導入する Trace Pair Encoding(TPE、構造保存型トークナイザ)は、ボキャブラリ 256 で 83.88% 圧縮しつつ最良の診断精度を保つ一方、512/1024 への積極圧縮でオペレータレベル局所化 Macro F1 が 0.806→0.173→0.138 まで崩壊する(表3・表6)。これは本 concept が VOCE で確認した「階層分解+反復多数決」・OpsMem の「動的検索」に続く、**文脈圧縮そのものの精度への影響を定量化した初めての事例**であり、「LLM への入力をどこまで圧縮できるか」という設計問いに直接答える。(Source: [[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]] §3.5, §5.2, 表3, 表6) - **同一著者陣が「訓練クラスタの異常検知」から「推論のリクエストレベル根本原因分析」へ研究を発展させた継承関係が確認できる**: TELLER の著者陣([[Ruilin Xu]]・[[Junyi Li]]・[[Pengfei Chen]]・[[Zongxuan Xie]]、いずれも [[Sun Yat-sen University]])は、[[eACGM]](IWQoS 2025、同著者陣の一部)の「eBPF + libnvml による非侵入フルスタック計装 + GMM 教師なし異常検知」という設計を土台に、(1) 計装手段を eBPF/libnvml から NVTX/CUPTI へ切り替え、(2) 診断対象を「訓練クラスタのメトリクス異常検知」から「推論のリクエスト単位・trace–log マルチモーダル根本原因分析(自然言語説明付き)」へ拡張した。TELLER 自身が参考文献[38]として eACGM を明示的に引用しており(§8)、同一研究グループの発展系列を独立ソース間の追跡で確認できる稀な事例。(Source: [[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]] §8, [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]]) - **反実仮想的なパッチ&リプレイによる決定的ステージ特定は、本 concept が記録してきた「診断だけでは不十分」という観察に、定量的な改善保証を加える**: STAR のアブレーション(Table V)は、反実仮想的候補評価(パッチを実際に適用し改善を確認してから帰属を確定する設計)を除去するとステージ局所化精度が最大8ポイント以上・下流の Acc@1/Acc@3 も低下することを示した。これは JustDiag が指摘した「流暢な最終回答は説明責任の根拠として不十分」という知見の裏返しとして、「診断も、実証された改善なしには不十分」という原則を修復の文脈で補強する。(Source: [[@2026__arXiv__STAR - A Stage-attributed Triage and Repair framework for RCA Agents in Microservices]] §IV-C, Table V) - **「トレースグラフに沿ったスパン単位の文脈分解」は、本 concept が蓄積してきた「LLM の文脈爆発対策」に、外部知識制約とは異なる第4の軸——構造整合的な証拠分解——を加える**: 本 concept は外部知識(SOP/SDG/Topology)による制約(Zha+ 2024・VOCE・COLA・KRCA のスケルトン制約)、階層分解+反復多数決(VOCE)、動的検索(OpsMem の CMR)という文脈管理パターンを蓄積してきた。[[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]](RCLAgent)はこれらとは異なる軸として、トレースグラフのトポロジそのものに沿って各スパンへ専任エージェントを再帰的に割り当て、Global Evidence Graph で細粒度証拠を保持したまま Root-Level Diagnosis Report へボトムアップに集約する。アブレーションでは Global Evidence Graph の除去が最大の精度低下(平均 MRR 69.73%→56.90%)をもたらし、「蓄積される文脈をどう分解・保存するか」自体が精度の律速因子であることを定量的に裏付けた。ReAct baseline でのラウンド数変化実験(Fig. 3)は「深い探索ほど精度が上がるが遅延も線形に増える」という、逐次推論構造に内在するトレードオフを独立に再確認しており、KRCA の「LLM-Constrained vs Unconstrained」の対比と並ぶ、構造制約 vs 無制約の別サンプルとなる。(Source: [[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]] §IV, Table IV, Fig. 3) - **「RCLAgent」という同一名称のフレームワークについて、引用元論文([[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]])の記述と原論文の実際のアーキテクチャが一致しないことが判明した**: 本 concept が既に記録した「GALA・RCLAgent の OpenRCA 再評価(Accuracy@1=2.56%・0.00%)」という知見は引用元論文の記述に基づくものだが、RCLAgent 原論文([[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]])を直接 ingest した結果、引用元が説明する「data agent + thought agent、initial-reasoning/critical-reflection/final-review の3フェーズ」という構成は原論文中に一切登場しないことが分かった。原論文の実際の構成要素(Dedicated Agent・Agents Pool・Global Evidence Graph・Diagnosis Synthesizer)とは食い違っており、詳細は [[RCLAgent]] の contradiction callout を参照。二次資料による手法記述の孫引きには誤差が混入しうるという、本 wiki の出典検査プロセス上の教訓でもある。(Source: [[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]] 全体、[[RCLAgent]]) - **RCAgent・mABC に先行する最初期の ReAct-for-RCA 実証研究が「KBA(トラブルシューティングガイド)」を外部知識制約の実例として確立した**: 本 concept は「外部知識(SOP/SDG/Topology)が LLM の事実根拠を補強する」パターンを Zha+ 2024・VOCE・COLA から蓄積してきたが、[[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]](Roy+, FSE Companion 2024)は RCAgent(CIKM'24, 2024-10)・mABC(EMNLP Findings 2024)より早く、Microsoft の実運用ケーススタディで KBA(Knowledge Base Article)へのアクセスが「単純なインシデントの自律解決」と「複雑インシデントでの行き詰まり」を分ける決定的因子であることを実証した。KBA Q/A ツールに加え、行動空間へ明示的に KBA Planning Tool を導入することで「ReAct の性急な thought-action インターリーブが高レベルプランニングを損なう」問題を緩和したという設計判断は、本 concept が蓄積してきた「外部知識制約」パターンの中でも、SOP/SDG のような構造化知識ではなく**自然言語のトラブルシューティングガイド**を対象にした最初期の事例である。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §7.2-7.3, §7.5) - **ゼロショット ReAct はクラウド RCA でも「精度は同等・ハルシネーションは最小」という ReAct 固有のトレードオフを示し、LLM ベース RCA の役割分化に「エージェント型プランナー」という早期の実例を提供する**: 本 concept は LLM の役割分化(外部知識リーダー・グラフマッパー・多因子分析器・コード実行ロジック読解器・要約特化器・経験蒸留器・知識マイナー)を蓄積してきたが、[[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] の ReAct エージェント(107,000 件本番インシデントで評価)は、few-shot 例なしのゼロショット設定でも Retrieval Baseline・CoT と意味的類似度で同等の性能を示しつつ、不正解ケースのハルシネーション率が最低(6% vs Retrieval Baseline 49%・CoT 18%)であった。この結果は 2023年の ReAct 原論文(HotpotQA)が示した「外部接地が幻覚を減らす」という知見が、ドメイン知識を要するクラウド RCA という全く異なるタスクでも成立することを裏付ける、本 concept 初の ReAct 単体エージェントの定量評価事例である。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §6.1, Table 3) - **人間介在ツール(Human Interaction Tool)を行動空間に明示的なアクションとして組み込む設計は、本 concept の「事後検証」「投票」「正当化アーティファクト」に続く第4のハルシネーション・行き詰まり対策パターンを提供する**: 本 concept は mABC の投票、JustDiag の正当化アーティファクト、FaultWeave の Rule-Based Validator という 3 種の検証機構を蓄積してきたが、[[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] のケーススタディでは、テーブルからの行フィルタリングのような ReAct が一貫して解決できないサブタスクを、エージェントの行動空間に組み込んだ Human Interaction Tool で OCE が直接介入して解決した。これは「LLM の出力を事後検証する」のではなく「LLM が行き詰まった箇所をリアルタイムに人間へエスカレーションする」設計であり、本番運用における実用的な緩和策として他の検証パターンと並置できる。(Source: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] §7.3, §7.4.2) - **「呼び出しレベル(invocation-level)集約」は、本 concept が蓄積してきた文脈管理パターン(外部知識制約・階層分解・動的検索・TPE 圧縮)とは異なる第5の軸——同一実行パスを持つリクエスト群を統計量へ集約する粒度変換——を提示し、非LLM ベースライン比の性能ギャップという既存知見に新しいサンプルを加える**: [[@2026__ICPE Companion__Representation-Aware Root Cause Analysis with Large Language Models (Position Paper)]](Wen+, ICPE Companion '26)は Train-Ticket 上で trace-level(リクエストごとの生 span 系列)と invocation-level(同一呼び出しパスの集約統計)を比較し、invocation-level が平均入力トークンを最大2桁削減しつつ Top-5 精度を同等以上に保つことを示した。さらに、暗黙的異常指標(support・confidence)を trace-level の「正常/異常ラベル」(TELLER の TPE や KRCA のスケルトン制約と同様、外部の構造的知識でなく履歴逸脱から導出される)に対応する invocation-level 版として新設計し、生メトリクスの追加が trace-level では精度を悪化させる一方 invocation-level では改善するという粒度依存の相互作用を報告した。一方で、この論文の最良 LLM 設定(Top1 54.5%)は非LLM手法 TraceRCA(Li+ 2021 IWQOS)の参考値(Top1 64.8%)に及ばず、本 concept が SREcon26(本番実測 11.34%)・OpenRCA 再評価(GALA 2.56%・RCLAgent 0.00%)で蓄積してきた「LLM ベース RCA が非 LLM ベースラインや実環境で精度が伸び悩む」という観察に、TrainTicket という研究環境データセットでの独立したサンプルを加える。(Source: [[@2026__ICPE Companion__Representation-Aware Root Cause Analysis with Large Language Models (Position Paper)]] §6.3-6.5, Table 1, Table 2) - **本 concept が蓄積してきた事例のほぼ全ては「推論時に LLM を補助する」設計(外部知識制約・階層分解・多エージェント分業・事後検証)だが、[[OpsLLM]] は LLM 自体を訓練時にドメイン RCA へ整合させる対照的な軸を提示する**: [[@2026__arXiv__OpsLLM - Construction of Large Language Model for Software Operations with Multi-stage Learning]] は SFT(LoRA)の後に、ドメインプロセス報酬モデル(DPRM)を用いた段階ゲート型 GRPO 強化学習で RCA の最終回答精度と推論過程の信頼性を同時に最適化する。RCACopilot・RCAgent・Flow-of-Action のような推論時手法との対比で著者ら自身が明示する通り、この設計は「LLM を外部フレームワークの一構成要素として扱う」のではなく「LLM 自身の運用ドメイン専門性を直接強化する」ものであり、本 concept が扱ってきた事後検証(mABC の投票・JustDiag の正当化アーティファクト・FaultWeave の Rule-Based Validator)とは異なる**訓練時の整合**という第5の軸を提供する。OpsLLM-32B は Online Boutique 障害注入 150 ケースで RCA 精度をベースモデル比 11.3%→77.4%(Easy)まで引き上げ、SREcon26 が報告する本番実測精度 11.34%(推論時補助のみの Claude 3.5 Sonnet + 専用エージェント)と同程度の値がベースモデルの水準として現れる点は、「訓練時整合」と「推論時補助」のどちらがどの精度域を担うかという設計選択の対比材料になる。(Source: [[@2026__arXiv__OpsLLM - Construction of Large Language Model for Software Operations with Multi-stage Learning]]) - **「結果は正しいが推論が不整合(Correct Outcome but Misaligned Reasoning)」の定量化は、本 concept が JustDiag で確認した「最終回答品質とプロセス品質は独立に評価すべき」という知見に、訓練データとしての具体的な再現数値を加える**: OpsLLM の予備実験(Fig. 1(b))では、Qwen-plus-2025-09-11 が到達した「正しい根本原因コンポーネント」のうち 100% が誤った障害レベルを伴う不整合推論であり、Qwen-flash・Kimi-K2-Instruct でも 51.4%〜69.6% が同様の不整合を示した。JustDiag が RCAgent・Flow-of-Action の Process Score の低さ(9.5・9.3)を事後的な評価指標として定量化したのに対し、OpsLLM はこの不整合を DPRM の訓練シグナル(5 ルーブリックで 0〜5 点採点)として直接に学習ループへ組み込む点が異なる。(Source: [[@2026__arXiv__OpsLLM - Construction of Large Language Model for Software Operations with Multi-stage Learning]] Fig. 1(b)) - **「診断対象を最終回答でなく中間の伝播チェーン構築に置く」設計は、本 concept が蓄積してきた事後検証パターン(mABC の投票・JustDiag の正当化アーティファクト・FaultWeave の Rule-Based Validator・STAR の反実仮想的パッチ)とは異なる時間軸——障害予測(pre-hoc)における閉ループ洗練——にこれらのパターンを移植した事例を提供する**: [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]](ChainCraft)は、[[障害予測]]ドメインで因果グラフ制約下の異常伝播チェーンを LLM(Chain Builder)に生成させた後、Structural/Temporal Checker(決定論的なグラフ整合性・時刻整合性検証)・Chain Critic(LLM による意味的妥当性評価、hard violation/soft issue への分類)・Chain Refiner(指摘位置のみの最小局所編集)という3層の検証・修正パイプラインを、決定論的 comparator(構造/時間/意味ペナルティの重み付き品質スコア)で反復させる。本 concept がこれまで扱ってきた RCA(post-hoc 診断)向けの事後検証は「最終回答の正しさ」を検証するのに対し、ChainCraft の閉ループは「伝播チェーンという中間生成物」を対象とする点が異なり、Chain Critic が担う役割は本 concept の役割分化(外部知識リーダー・グラフマッパー・多因子分析器 等)に**チェーン監査器**という新しいカテゴリを示唆する。アブレーションで洗練モジュール除去(C2)は F1 を低下させ、閉ループ洗練の寄与を定量的に裏づけた。(Source: [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]]) - **ハイブリッドなテキスト構造検索(`Sim_chain` が記述・ノード・エッジ・パス・トポロジの5類似度を統合)は、本 concept が蓄積してきた「外部知識制約」パターンとは異なる軸——過去事例の検索ランキングに構造的類似度を組み込む設計——を提供する**: KRCA のスケルトン構造制約([[@2026__ASE__KRCA - An Efficient Root Cause Analysis System in Hyper-Scale Microservice Systems via Agentic AI]])が LLM の**生成**を構造で制約するのに対し、ChainCraft の構造認識型 RAG は過去故障事例の**検索・ランキング**を構造的類似度(ノード種別・エッジ集合の Jaccard・層タイプ系列の最長共通部分列・グラフ構造特徴)で行う。アブレーション(C3、構造認識 RAG 除去)は F1 を低下させ、テキスト症状のみに依存する従来の RAG(VectorRAG・GraphRAG・LinearRAG 等、本 concept が OpsMem で扱った静的検索)に対し、伝播グラフのトポロジ情報を検索スコアに組み込むことの効果を定量的に示した。(Source: [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]]) - **AIOps 全域を横断するサーベイの「手法軸」5 分類(foundation model・fine-tuning・embedding-based・prompt-based・knowledge-based)に、本 concept が既に蓄積してきた RCA システムを当てはめ直すと、prompt-based と knowledge-based の 2 軸に集中していることが見える**: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 5 RQ3 - LLM-based Methods for AIOps]] §5 は LLM 適用手法を「モデルをどう用意するか(foundation model・fine-tuning)」「入力をどう変換するか(embedding-based)」「モデルにどう働きかけるか(prompt-based・knowledge-based)」の 5 分類に整理する。本 concept が詳述してきた RCACopilot・Xpert は §5.4 の In-Context Learning に、RCAgent・RCACopilot(TAG 側)は §5.5 の Tool Augmented Generation に、LM-PACE は §5.5 RAG(類似検索による過去インシデント・推奨根本原因の同時検索)と §5.4 CoT(GPT-4 診断能力強化)の両方に、AnomalyLLM は §5.2 Full Fine-Tuning(LLaMA2-7B + 動的認識コントラスティブファインチューニング)と §5.4 ICL の組み合わせに、RealTCD は §5.4 CoT(因果関係特定)に、LasRCA は §5.4 ICL(one-shot learning + 小型分類器)に対応する。本 concept が独自に蓄積してきた「LLM の役割分化」(外部知識リーダー・グラフマッパー・多因子分析器・コード実行ロジック読解器・要約特化器・経験蒸留器・知識マイナー・推論チェーン抽出器)は「RCA パイプライン内で LLM が何を担うか」という機能軸であるのに対し、サーベイの 5 分類は「LLM をどう用意・駆動するか」という実装軸であり、両者は直交する——同じ RCACopilot が「グラフマッパー/コパイロット」(機能軸)かつ「ICL + TAG」(実装軸)として二重に記述できる。本 concept のどの事例も §5.1(foundation model そのままの利用)・§5.3(embedding-based)には該当せず、RCA タスクでは「モデルを準備する」段階より「モデルに何を検索・実行させるか」の設計が支配的であることが、サーベイの分類軸を通して裏付けられる。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 5 RQ3 - LLM-based Methods for AIOps]] §5.1-§5.5) - **生ログの直接 LLM 注入に対するコンテキスト制約とドメイン幻覚の壁は、シャノンエントロピーによるシンボリック2層圧縮と対比的歪み分析によって、1,000〜7,000倍の圧縮率とMRR 0.790を両立しながら克服できる**: [[@2026__ASE__Log-Insight - Automating Microservice Incident Diagnosis via Neuro-Symbolic Log Analysis]] は、Huawei本番環境(30分で200万行超のログ)において、46k文字の固定API枠に生ログをそのまま入れると50〜80行で破綻する問題に対し、決定論的シンボリック処理と汎用LLMを組み合わせたニューロシンボリック手法を実証した。列レベルのエントロピー評価(高エントロピーな識別子・UUIDの抽象化と低エントロピーな列挙値の温存)およびテンプレート内パラメータ抽象化により、数百万行の生ログを7k〜20k文字の安定したコンテキストへ圧縮する。さらに成功ログとエラーログの偏在を統計的に検定する対比的歪み分析(Contrastive Skew Analysis)で抽出した Critical Hint をプロンプト先頭に配置することで、Lost in the Middle 現象を構造的に抑止し、LLM がドメイン固有の根本原因コードを事後知識で上書きしてしまう「物語優先の転倒(narrative override)」を抑制した。本知見は、本 concept が蓄積してきた「文脈管理パターン」(外部知識制約・階層分解・動的検索・TPE圧縮・invocation-level集約・KG構造分解)に、「情報理論的エントロピー圧縮 × 統計的対比歪みフィルタリング」という強力な第7の軸を追加する。(Source: [[@2026__ASE__Log-Insight - Automating Microservice Incident Diagnosis via Neuro-Symbolic Log Analysis]]) - [エージェント設計] RCA 専用に設計されていない汎用の深層リサーチ・コーディングエージェント(適応的で制約の少ない ReAct 型ループ)が、RCA 特化のマルチエージェント設計を上回る例が報告されている。上位エージェント間の性能差はバックボーンモデルの差より小さく、投資すべきは調査アーキテクチャの開放性かドメイン特化かという問いに対して前者を支持する観察(Source: [[@2026__arXiv__Beyond Fault Localization - A Trajectory-Level Study of LLM Agents for Microservice Root Cause Analysis]]) - [失敗分析からの介入] 誤診断を「証拠が全く収集されない/収集されても誤読される/根拠のない推論に上書きされる」という三分類の失敗タクソノミーに還元し、それぞれに対応する grounding(接地)・verification(検証)の二段防御を組み合わせることで、held-out のバックボーンモデル・データセット・サービストポロジーでも根本原因特定精度が改善する例が報告されている(Source: [[@2026__arXiv__Beyond Fault Localization - A Trajectory-Level Study of LLM Agents for Microservice Root Cause Analysis]]) ## 未解決の問い - **ChainCraft の閉ループ洗練(Structural/Temporal Checker・Chain Critic・Chain Refiner)が、本 concept が蓄積してきた他の検証機構(mABC の投票・JustDiag の正当化アーティファクト・FaultWeave の Rule-Based Validator・STAR の反実仮想的パッチ)と比べてどのハルシネーション対策パターンとして最も効果的かは未比較**: いずれも「LLM の主張を検証する」という共通目的を持つが、対象(最終診断 vs 中間伝播チェーン)・検証主体(投票 vs LLM 自己批判 vs ルールベース照合 vs 実行結果の反実仮想比較)が異なる。同一データセット上でこれらを統一的に比較する研究は本 concept 内に存在しない。(Source: [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]]) - **invocation-level 集約(呼び出しパスの統計量への集約)は、本 concept が蓄積してきた他のマルチエージェント・多段階 RCA システム(mABC・KRCA・OpsMem・RCLAgent 等)の入力表現にも組み込み可能か未検証**: Wen+ 2026 は固定プロンプト・単一 LLM(Gemini 1.5)という単純な設定でのみこの表現変換を検証しており、役割分担型・階層分解型のアーキテクチャに invocation-level 集約を前処理として組み込んだ場合に精度・トークンコストがどう変化するかは示されていない。また、この論文の最良設定(Top1 54.5%)が TraceRCA(Top1 64.8%)に及ばない理由が「表現設計の余地がまだ残っている」のか「LLM 推論そのものの限界」なのかも切り分けられていない。(Source: [[@2026__ICPE Companion__Representation-Aware Root Cause Analysis with Large Language Models (Position Paper)]]) - **OpsLLM の DPRM による訓練時整合と、本 concept が蓄積してきた推論時の検証機構(mABC の投票・JustDiag の正当化アーティファクト・FaultWeave の Rule-Based Validator・STAR の反実仮想的パッチ)を組み合わせた場合に精度がさらに向上するか未検証**: OpsLLM は訓練時に推論品質を DPRM で整合させるが、推論時に追加の検証層を重ねる余地は論文内で議論されていない。「訓練時整合」と「推論時補助」が独立に効く設計なのか、重複した対策なのかは今後の実証課題。(Source: [[@2026__arXiv__OpsLLM - Construction of Large Language Model for Software Operations with Multi-stage Learning]]) - **STAR の RCA 特化4ステージ分解が、本 concept が蓄積してきた他の LLM ベース RCA システム(VOCE・KRCA・OpsMem・FaultWeave 等)にも移植可能かは未検証**: STAR は mABC・RCAgent という LangGraph 上に再実装可能なワークフローを前提とするが、VOCE(階層分解+反復多数決)・KRCA(スケルトン構造制約)・OpsMem(dual-memory)のような異なるアーキテクチャに STAR の4段階監査・Fast/Slow Routing・反実仮想的ステージ局所化がそのまま適用できるかは自明ではない。 - **本 concept が記録した「本番実測精度は 11.34%」(SREcon26)という知見と、STAR が公開ベンチマーク・本番データセットの両方で高い修復率(1〜2回のリプレイで90%以上)を報告している事実の関係は未整理**: STAR の Dataset B は実運用の本番データセットだが、SREcon26 が報告する 335 件の実障害・3エンタープライズシステムほどの規模・多様性を持つかは論文からは判断できない。STAR の高い修復成功率が「ベースエージェントの初期推論を改善する」ことによるものか、「Dataset B の障害パターンの複雑さが SREcon26 の対象システムより低い」ことによるものかは切り分けられていない。 - **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]]) - **RCLAgent の実効性能がバックボーン LLM 能力に強く依存する点(Table III で最大14%超の差)は、本 concept が蓄積してきた「役割分担設計 vs モデル規模スケーリング」という対比に対し、「専任エージェント設計であっても結局バックボーン能力が律速する」ケースを提示する——mABC・KRCA の知見(役割分担がモデル規模を凌駕しうる)との境界条件は未整理**: RCLAgent は HumanEval で高スコアの GPT-4 が RCL 精度で著しく低迷する逆説的な結果(Table III)を報告しており、「汎用推論能力の高さが RCLAgent 上の有効性を保証しない」ことを示した。mABC の「Llama-3-8B ベースが GPT-4-Turbo ベースの ReAct を上回る」という知見と一見矛盾するが、両者の役割分担の粒度(RCLAgent はスパン単位、mABC はプロセス単位)の違いがこの差にどう寄与するかは未検証。(Source: [[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]] §V-D, Table III) - **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)が精度をどう変えるかは未検証。 - **discussion comments が RCA 性能を明確に改善しない理由の構造分析が未完**: [[@2024__FSE Companion__Exploring LLM-Based Agents for Root Cause Analysis]] は、履歴インシデントの discussion comments をリトリーバルコーパスに加えても語彙指標が指標ごとに改善・悪化し、意味指標には影響しないという結果を報告し、要因として「診断ステップの結果のみが記録され手順が記録されない」「対象インシデントに症状が明示的に出現しない」「discussion 自体が管理的内容でスパース」の 3 点を推測するが、いずれも定量的に切り分けられていない。KBA(手順知識)と discussion comments(結果記録)の情報価値の違いを定量比較する研究は本 concept 内に存在しない。 - **KBA Planning Tool の「高レベルプランニング専用ツールの明示的導入」が他の LLM ベース RCA アーキテクチャ(mABC・VOCE・KRCA 等)にも一般化するか未検証**: 本論文は「ReAct の性急な thought-action インターリーブが高レベルプランニングを損なう」という予備実験での観察に対し、KBA Q/A ツールと構造的に同一だが行動空間で独立したツールとして導入することで緩和したと報告するが、この設計介入の効果を定量的にアブレーションした結果は示されていない。マルチエージェント分業(mABC・KRCA)や階層分解(VOCE)といった別解法との比較優位性も未整理。 - **診断的正当化コストと 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) - **TPE の圧縮–精度トレードオフの「最適語彙サイズ」は、エンジン・ワークロード・バックボーンを跨いで普遍的か未検証**: TELLER は 256/512/1024 の 3 段階で「中程度の圧縮が最良」を示したが(表3)、著者ら自身が「厳密な最適点はエンジン・ワークロード・バックボーンによって変わりうる」と留保している(§7)。本 concept が VOCE・OpsMem で確認した「文脈管理パターン」(階層分解・動的検索)と TPE の「構造保存型圧縮」を横断比較し、どのパターンがどの入力長・タスク種別に最も有効かを問う統一的な実証研究は未着手。(Source: [[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]] §7) - **本番の希少性・ノイズ・エンタングルメントの下で TELLER がどこまで有効かは未検証**: 主評価は障害注入ベースのバランス済みデータセットで、SREcon26 が報告する本番精度 11.34% のような「研究–本番ギャップ」パターンが GPU カーネルレベルの診断でも再現するかは、TELLER 自身では検証されていない(低事前確率再サンプリングのみ実施、実インシデントでの評価は将来課題として明記)。(Source: [[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]] §7) - **AIDAの「推論チェーン抽出器」(訓練時)とKG構築・多段階推論(推論時)という二段構えの設計は、本 concept が蓄積してきた他システムの単一軸設計(訓練時整合のみのOpsLLM、推論時補助のみのVOCE・mABC等)と比べてどこまで一般化するか未検証**: AIDAはRLで中間表現抽出器を訓練しつつ、推論時にも多段階検証・信頼度ランキングという複数の対策を重ねる。この「訓練時+推論時」の併用が、OpsLLMのような訓練時単独設計やVOCEのような推論時単独設計と比べてどの程度追加的な精度向上をもたらすか、同一データセットでの直接比較は行われていない。(Source: [[@2026__SIGCOMM__AIDA - Accelerating Root Cause Analysis for Multi-Vendor Device Failures with LLM-Powered Reasoning]]) - **AIDAのabstain設計(確信度不足時に診断せず人間へ引き継ぐ)は、本 concept が蓄積してきた他の検証機構(mABCの投票・JustDiagの正当化アーティファクト・FaultWeaveのRule-Based Validator)と比べて、どのハルシネーション対策パターンとして最も効果的か未比較**: 事後検証(投票・正当化アーティファクト・ルールベース照合)が「誤った診断を出した後にそれを検出する」のに対し、AIDAのabstainは「診断を出す前に確信度で足切りする」という予防的パターンである。両者を組み合わせた場合の精度・カバレッジのトレードオフは、本concept内のどのソースでも定量比較されていない。 - **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]]) - **RLでファインチューニングしたLLMを「非構造化診断メールから構造化推論チェーンを抽出する装置」として使う設計は、本 concept が蓄積してきた LLM の役割分化(外部知識リーダー・グラフマッパー・多因子分析器・コード実行ロジック読解器・要約特化器・経験蒸留器・知識マイナー)に、8番目のカテゴリ——「推論チェーン抽出器」——を加える**: [[@2026__SIGCOMM__AIDA - Accelerating Root Cause Analysis for Multi-Vendor Device Failures with LLM-Powered Reasoning]] は、SFT(専門家50件・2.5人時)で初心者抽出器を作った後、GRPOで精錬する二段階ファインチューニングにより、過去の診断メールを問題記述・証拠・根本原因要約の3ノードからなる因果的に整合したチェーンへ変換する専用LLMを構築する。報酬関数は内容完全性(ROUGE-L + ログの厳密文字列一致)と論理的整合性(より大きなLLMを判定器としたステップ粒度・因果整合性の評価)を組み合わせる。これは OpsLLM の「訓練時にLLM自体をRCAへ整合させる」という軸(本concept既存知見)と同じ大分類に属するが、OpsLLMが最終回答精度そのものをDPRMで最適化するのに対し、AIDAは**中間表現(推論チェーン)の抽出品質**をRLで最適化し、その中間表現を後段のKG構築・多段階推論の入力として使う点で異なる。LogSageの「要約特化器」が非構造化ログを自然言語要約に圧縮するのに対し、AIDAの推論チェーン抽出器は非構造化テキストを**構造化された因果グラフのノード**に変換する点でも異なる出力形式を持つ。(Source: [[@2026__SIGCOMM__AIDA - Accelerating Root Cause Analysis for Multi-Vendor Device Failures with LLM-Powered Reasoning]] §3.3.1) - **6種のバックボーンLLM(8B〜1T)を横断した評価で「役割分担設計(構造化知識+多段階推論)がモデル規模スケーリングを上回る」という本 concept の中心的知見(mABC・KRCA)が、ネットワーク機器RCAという新ドメインでも再現された**: AIDAはQwen3 8B・Qwen2.5 72B・GLM-4.7 358B・DeepSeek-V3.2 685B・GPT-5.2・Qwen3-Max 1Tの全モデルで一貫してベースラインを上回り(平均Accuracy +8.0pt・Precision +9.8pt)、8BモデルのAIDA(Precision 93.3%)が72BモデルのLightRAG(84.5%)を上回った。一方ベースライン側はモデル規模を9倍(8B→72B)にしても精度向上はごくわずかであった。mABCの「Llama-3-8BベースがGPT-4-TurboベースのReActを上回る」・KRCAの「マルチエージェント除去がAC@1を0.88→0.75に低下させる」という既存知見と同型のパターンが、マイクロサービスRCAから独立したネットワーク機器RCAというドメインで確認されたことは、この知見がAIOps全域に一般化する可能性を補強する。(Source: [[@2026__SIGCOMM__AIDA - Accelerating Root Cause Analysis for Multi-Vendor Device Failures with LLM-Powered Reasoning]] §5.1, Table 1) - **多段階推論による証拠ノード単位の逐次検証は、本 concept が蓄積してきた「文脈管理パターン」(外部知識制約・階層分解・動的検索・TPE圧縮・invocation-level集約)に、「構造化KGのノード粒度に沿った文脈分解」という第6の軸を加える**: AIDAのMulti-Step Reasoningは、検索した推論チェーンを証拠ノード単位に分解し、各ノードについて意味考慮ログテンプレートで絞り込んだログだけをLLMに提示して検証させる(二段階フィルタリングで16,729行→367.7行、45.6倍削減)。VOCEの「source内→隣接source間」という階層分解、OpsMemの動的検索(CMR)とは異なり、AIDAの分解単位は**推論チェーンの因果構造そのもの**(問題記述→証拠→根本原因)であり、KG構築時に確定した構造をそのまま推論時の文脈分割の単位として再利用する。この設計により平均トークン消費量を64.8%削減しつつ、多段階推論なし条件と比べPrecisionを3.9pt改善しており(w/o Multi-step ReasoningのアブレーションFigure 23b)、本concept が蓄積してきた「文脈爆発対策」の議論に、KG構築とオンライン推論の分解単位を統一するという設計解を追加する。(Source: [[@2026__SIGCOMM__AIDA - Accelerating Root Cause Analysis for Multi-Vendor Device Failures with LLM-Powered Reasoning]] §3.4, §5.2, §5.3) - **保守的なabstain設計(確信度不足時は診断せずmanual fallbackへ)は、本 concept がSREcon26・JustDiagで確認してきた「誤った自信のある診断」問題への、事前予防的な対処パターンを提供する**: 本conceptはSREcon26([[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]])の「AIは正確さに関係なく自信満々な説明を常に生成する」という観察や、JustDiagの事後的なプロセス品質評価を蓄積してきたが、AIDAはこの問題に**推論時のconfidenceスコアで診断を出すか出さないかを判断する**という予防的設計で対処する。信頼度スコア $e(f_i) = \text{Rel}(R_i) \cdot \prod \text{Conf}(T_s^{(i)}|g_s^{(i)})$ はベイズ平滑化されたチェーン信頼度とLLMのトークン出力分布から推定したエビデンス確信度の積であり、確信度が閾値未満のケースは「診断不能」として人間へ引き継ぐ。この結果Accuracy(70.2%→85.4%)がPrecision(95.4%)より大幅に低いというトレードオフを意図的に許容しており、SREcon26が報告する「本番実測精度11.34%」という低いAccuracy値の背景に、AIDAのような意図的なabstain設計が寄与している可能性を示唆する——両者を比較する際は「診断を出したケースの正しさ」(Precision)と「全ケースに占める正しい診断の割合」(Accuracy)を区別する必要がある。(Source: [[@2026__SIGCOMM__AIDA - Accelerating Root Cause Analysis for Multi-Vendor Device Failures with LLM-Powered Reasoning]] §4.1) - **MagmaScope は LLM を「粗粒度ランキング後の細粒度分析器」として ReAct エージェント内で使用し、その関連付けが「因果推論ではなく意味的理解」に基づくと明示する——本 concept が蓄積してきた LLM の RCA 内役割分化に「意味的関連付け器」という実用的カテゴリを加える**: [[MagmaScope]]([[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]], ICSE-SEIP '26)の LLM エージェントは、粗粒度スコアで絞り込んだ変更チケット候補を受け取り、IM グループチャットから蓄積した障害情報と突き合わせてその意味的相関を判断する ReAct ループを実行する。重要な点として、同論文は「我々のアプローチは因果推論ではなく意味的理解に基づく関連付けを行う」と明示しており、本 concept が扱ってきた causal graph RCA とは設計思想が異なる。入力が変更チケット + IM チャットであるため、テレメトリ(ログ/メトリクス/トレース)を直接読む TELLER・COCA・RCLAgent とは異なり、「人間が書いた不完全・断片的な自然言語記述を LLM で意味的に補完・標準化する」Change Object Rewrite([[Change Object Rewrite]])が前段に必要という点も独自である。(Source: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] §3.3-§3.4) > [!contradiction] MagmaScope の関連付け表現 > §3.2.3 は同じ機構を「causal inference mechanism」と呼ぶ一方、§8.1 は統計的手法を超える意味的理解を重視し、因果性ではないと記述する。したがって本ページでは、この手法の Top-k 推薦を因果関係の証明とは扱わない。 - **本 concept が蓄積してきた「機能軸」(LLM の役割分化)と、サーベイ横断の「実装軸」(foundation model/fine-tuning/embedding-based/prompt-based/knowledge-based)を統一的にクロス集計した研究は存在しない**: 個々の RCA システムがどちらの軸でも記述可能であることは分かったが、「機能軸のどのカテゴリが実装軸のどの手法と相性が良いか」(例: 経験蒸留器は fine-tuning と相性が良いか、それとも knowledge-based の動的検索で代替可能か)を体系的に検証した研究は本 concept 内にない。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 5 RQ3 - LLM-based Methods for AIOps]]) - **統計的歪み分析で抽出された確信度の高いシグナルが、LLM内部の事前学習知識(より一般的・直感的な因果ストーリー)と競合して順位を下げられる「物語優先の転倒(narrative override)」を、プロンプト制約や批判エージェント以外で構造的・決定論的に防止できるか**: Log-Insight は JSON スキーママッピング強制や Critic-Agent による検証を試みているが、根本的な原因は LLM が提示された統計事実よりも自身の parametric memory を過信することにある。シンボリックな統計優位性とニューラルな言語生成の序列を、生成段階でいかに破綻なく同期させるかは、ニューロシンボリック RCA に共通する未解決課題である。(Source: [[@2026__ASE__Log-Insight - Automating Microservice Incident Diagnosis via Neuro-Symbolic Log Analysis]]) ## 関連 - [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 5 RQ3 - LLM-based Methods for AIOps]] — AIOps 全域を横断する LLM 適用手法の 5 分類(実装軸)。本 concept の役割分化(機能軸)と直交する。 - [[障害予測]] — post-hoc 診断(本 concept の主対象)に対し pre-hoc 予測という異なる時間軸で、閉ループ検証・構造認識型検索という同型パターンを適用する隣接分野。[[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]] - 親概念: [[根本原因分析]]、[[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 を意図的に避ける) - ソース: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] / [[@2026__arXiv__OpsLLM - Construction of Large Language Model for Software Operations with Multi-stage Learning]] / [[@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?]] / [[@2026__arXiv__STAR - A Stage-attributed Triage and Repair framework for RCA Agents in Microservices]] / [[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]] / [[@2026__ICPE Companion__Representation-Aware Root Cause Analysis with Large Language Models (Position Paper)]] - [[エージェント修復]] — STAR の RCA 特化ステージ帰属と AgentTether/PROBE の汎用 TU 帰属の対比 - [[ワンショットRCA]] — LLM × 小型分類器のコスト制約下設計の詳細 - [[障害注入]] — FaultWeave の障害探索フェーズ(MFS 生成)との接続 - エンティティ: [[GALA]] / [[RCLAgent]] / [[OpenRCA]] / [[QPIAI]] / [[Lingzhe Zhang]] / [[Tong Jia]] / [[Ying Li]] / [[eACGM]] / [[Ruilin Xu]] / [[Junyi Li]] / [[Pengfei Chen]] / [[Zongxuan Xie]] - [[GPU観測性]] / [[マルチモーダル障害診断]] / [[CUDA API トレース]] — TELLER が接続する GPU/トレース観測性レイヤーの概念 - 概念: [[エージェント軌跡評価]] ## 出典 - [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 5 RQ3 - LLM-based Methods for AIOps]] §5.1-§5.5(foundation model・fine-tuning・embedding-based・prompt-based・knowledge-based の 5 分類と各代表手法。RCACopilot・Xpert・RCAgent・LM-PACE・AnomalyLLM・RealTCD・LasRCA 等、本 concept 既存の RCA システムがこの実装軸のどこに位置するかの再整理) - [[@2026__ISSRE__ChainCraft - Bridging Causal Discovery and LLM Reasoning for Failure Prediction in Microservices]](Zhao, Sun ほか — PCMCI 因果グラフ制約下の LLM 伝播チェーン生成、Structural/Temporal Checker + Chain Critic + Chain Refiner の閉ループ洗練、ハイブリッドテキスト構造検索、Alibaba 3か月間産業デプロイ) - [[@2026__arXiv__OpsLLM - Construction of Large Language Model for Software Operations with Multi-stage Learning]](Fig. 1 予備実験の推論不整合率、DPRM の5ルーブリック、段階ゲート型 GRPO による訓練時整合) - [[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]](§3 NVTX/CUPTI トレーシング・causal-context slice・TPE・マルチモーダル RCA モデル、§5 RQ1〜4、§6 AI21 Labs 障害ケーススタディ、§7 限界) - [[@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：全体性能・アブレーション・自己進化) - [[@2026__arXiv__STAR - A Stage-attributed Triage and Repair framework for RCA Agents in Microservices]] §III(4ステージ問題設定)、§IV(手法)、§V-C(mABC・RCAgent への後付け効果)、§V-F(アブレーション) - [[@2026__ICPE Companion__Representation-Aware Root Cause Analysis with Large Language Models (Position Paper)]] §6.3-6.5(粒度・モダリティ・summarization の探索的実験)、Table 1・Table 2(Top-k 精度とトークン量)、Table 3(few-shot 補足実験) - [[@2026__TDSC__Towards In-Depth Root Cause Localization for Microservices with Multi-Agent Recursion-of-Thought]] §III(SRE 実務分析・失敗モード分類)、§IV(RCLAgent 設計)、§V(3ベンチマーク評価・アブレーション・バックボーン比較) - [[@2026__SIGCOMM__AIDA - Accelerating Root Cause Analysis for Multi-Vendor Device Failures with LLM-Powered Reasoning]] §3.3.1(RLによる推論チェーン抽出器の訓練)、§3.4(多段階推論・信頼度スコアリング)、§5.1(6バックボーンLLM横断評価)、§4.1(本番Accuracy/Precisionトレードオフ)