仮説駆動RCA - yuuk1's Digital Garden

# 仮説駆動RCA ## 定義仮説駆動RCAは、障害症状から複数の原因仮説を立て、限定された証拠で検証・棄却・再定式化しながら根本原因へ近づく RCA の調査スタイルである。LLM エージェントに全テレメトリを要約させる設計ではなく、人間 SRE のトラブルシューティング手順をエージェントの制御ループとして実装する。 ## 横断的知見 - SRE Book の Effective Troubleshooting は、トラブルシューティングを仮説演繹法・分割統治・安定化優先として体系化した。これは agentic SRE の仮説駆動調査の前史である。([[@2016__OReilly__SRE Book - Chapter 12 Effective Troubleshooting]]) - [[Bits AI SRE]] は全テレメトリの一括要約から、因果的つながりを辿る hypothesis-driven investigation へ設計を移した。([[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]]) - [[SREGym]] は、多くのエージェントが最初のもっともらしい異常に固着し、競合仮説を作らないと報告する。仮説駆動を名乗るには、仮説生成だけでなく並行検証と停止条件が必要である。([[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - [[Cloud-OpsBench]] や agentic NetOps/AIOps サーベイは、調査軌跡を予算・停止規則・証拠 citation で制御する必要を示す。仮説駆動 RCA は推論技法だけでなく制御問題である。([[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]], [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]]) - [[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis|JustDiag]]([[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]])は、仮説競合を**主張レベル裁定(claim-level adjudication)**として形式化した。各仮説を検証可能な主張(Claim)へ分解し、ドメインエキスパートが `supports/contradicts/insufficient` の verdict を返す。仮説スコアは `Score(h) = Σ[Sup(c,h) − Con(c,h)]` で計算され、複数仮説の選好順序が常に明示的に保持される。これは「SREGym で指摘されたように最初のもっともらしい異常に固着する」問題に対して、設計レベルの回答を提示する。 - JustDiag の終端状態設計は「停止条件」問題への一つの答えを示す。`resolved/provisionally_resolved/need_more_evidence/stalled` の 4 状態により、証拠充足・カバレッジ比率・残留矛盾・次の確認の有無で停止を制御する。**校正された非閉包(calibrated non-closure)**として、stalled 状態は「誤った確実性」より「有用な不確実性の構造化記録」を返す設計方針を実現する。([[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]] §3.3) - **5 方向の UI インタラクションが「仮説駆動 RCA の探索プリミティブ」を人間-マシン協調として具体化した最初の VIS 研究**: RCInvestigator([[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]], TVCG 2026)は、上方向(一般化)/下方向(特化)/右方向(相関)/左方向(比較)/内方向(属性転換)の 5 方向を定義し、各インタラクションがタプル $c_{ip} = (e_i, a_{ip})$ の「エンティティ」または「属性」次元の一方のみを変更するという形式化を行った。これにより「どの方向を辿るか」の意図が探索軌跡に記録され、調査の再現・共有が可能になる。JustDiag の主張レベル裁定が「棄却された仮説を記録する」のと同様に、RCInvestigator の注釈機能は棄却仮説と確認仮説の両方を canvas 上に記録する。(Source: [[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]] §5.3) - **BCPD ベースの変化点整合度スコアはマシンが証拠の「関連度」を評価する軽量な実装**: RCInvestigator の拡張モデルは、エージェントが仮説を自動で決定するのではなく、分析者が指定した方向の探索空間に限定してランキングを提供する。これは [[Bits AI SRE]] の「telemetry tool call を絞り込む」設計と同じ方向——マシンが全データを要約せず、人間の仮説に沿ったデータのみを処理することで認知負荷を下げる——を、関連度スコアという形で実装した。(Source: [[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]] §5.3.1) - **Kingsman の仮説 3 条件・テスト 6 基準はインシデント現場の「仮説駆動 RCA 実践ハンドブック」として機能する**: [[Jack Kingsman]]（[[Atlassian]]）は SREcon26 Americas で、仮説の最低条件を **testable（テスト可能）・relevant（証拠と関連）・specific（具体的）** の 3 条件、テストの品質基準を **①仮説への作用・②相互排他性・③交絡要因排除・④効果の測定可能性と可逆性・⑤リスクの管理可能性・⑥最小介入** の 6 基準として明示化した。これらは本ページが集約する [[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis|JustDiag]] の主張レベル裁定（Sup/Con/insufficient）・[[SREGym]] の固着問題・[[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems|RCInvestigator]] の 5 方向探索という研究文脈と相補する実践的な具体化であり、「テストできないものは仮説ではなくフラストレーションだ」という Kingsman の言い方は、JustDiag が stalled 終了で「誤った確実性より有用な不確実性の構造化記録を返す」という設計哲学と同じ方向を指している。また「もっともらしい説明で探索を止める early stopping が最大の誤り」という主張は、SREGym が指摘した最初の異常への固着問題に対して、エージェント設計でなく人間実践の観点から独立した裏付けを与える。([[インシデント認識論]] に詳述。Source: [[@2026__SREcon26Americas__Epistemology of Incident Management]]) - **[[アノマリー応答]](Grayson 2019)は仮説駆動 RCA の理論的先祖**: SNAFUcatchers Consortium のチャットログ分析は、仮説群が「line of commitment(行動着手線)」を境に分岐・収束する時間発展を可視化した。これは本ページが集める「停止条件」問題(JustDiag の 4 終端状態、SREGym の固着問題)より 7 年早く、同じ課題——複数仮説をいつまで保持し、いつ行動に踏み切るか——を人間チームの chat ログから実証的に描いた。Grayson の「直近の変更が過度に優先され、時間的に離れた変更の追跡が遅れる」という観察は、agentic RCA の探索優先度づけにも未検証の懸念として引き継がれる。(Source: [[@2019__ACMQueue__Cognitive Work of Hypothesis Exploration During Anomaly Response]]) - **仮説の保持・棄却を「明示的なグラフ状態」として外部化する belief-state 設計が、GoS から OpsMem へ一段と拡張された**: OpsMem([[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]])の短期記憶(STM)は、症状・証拠・仮説をノードとし derive/refine/support/refute の 4 関係をエッジとするグラフであり、GoS(参考文献 [13])の belief-state 抽象化を踏襲する。本ページが集める JustDiag の主張レベル裁定(Sup/Con/insufficient)・RCInvestigator の 5 方向探索と同様、仮説の状態を非構造化な CoT テキストではなく明示的なグラフ構造として保持する設計に属する。OpsMem の新規性は、この belief-state(STM)を「過去に解決したインシデントの経験(LTM)」と cross-memory resonance で動的に結合する点にあり、STM を消すと Match が 78.33→45.00 に急落するアブレーション結果は、明示的な状態保持そのものが精度に直結することを長時間の反復診断(最大 3 ラウンド)で定量的に裏づけた。(Source: [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] §III-A, §IV-C Table II) - **「仮説を検証する証拠をどこから持ってくるか」という問いに、OpsMem は運用経験メモリという答えを提示する**: 本ページが集める仮説駆動 RCA の議論(SRE Book・Bits AI SRE・SREGym・RCInvestigator)は主にテレメトリからの証拠取得プロセスを扱うが、証拠の「解釈の拠り所」(過去に似た症状で何が原因だったか)をどう与えるかには踏み込まない。OpsMem の長期記憶(LTM、パターン・ケース・プロシージャのグラフ)は、この拠り所を明示的な記憶構造として外部化し、現在の症状に類似する過去パターンを cross-memory resonance で活性化する。これは仮説生成・検証のプロセスに「過去の類似インシデント」という第三の情報源を体系的に組み込む設計であり、Kingsman の「テスト可能性・関連性・具体性」の 3 条件のうち「関連性(証拠と関連)」を、人間の経験的直観ではなく構造化メモリの活性化スコアで担保しようとする試みと位置づけられる。(Source: [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] §III-A, §III-B) - **Honeycomb の BubbleUp は、LLM 登場以前から「異常領域と基準領域の全次元を diff してランク付けする」ブルートフォース自動化を実運用していた**: 『Observability Engineering』第2版第8章の**コアアナリシスループ**(起点確認→変化検証→共通次元探索→反復)は、本ページが SRE Book の仮説演繹法として整理した「前史」の直系にあたる非 LLM の実装であり、`global.availability_zone`が基準17%→異常領域98%という具体例のように、選択領域と領域外の全次元の値を計算・比較し差分の大きい順にソートして提示する。これは JustDiag の主張レベル裁定や RCInvestigator の5方向探索が LLM/人間の判断で仮説を絞り込むのに対し、**次元の総当たり比較そのものを自動化する**という異なるレイヤーの解であり、両者は排他的でなく組み合わせ可能(次元diffで候補を絞り、LLM が仮説の意味づけと検証を担う分業)と読める。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 8 Getting Started with Observability Analysis]], [[@2016__OReilly__SRE Book - Chapter 12 Effective Troubleshooting]]) - **「最も目立つ症状=根本原因」という固着は、マイクロサービスのトポロジ制約を仮説生成の段階で強制することで設計的に防げる**: TopoEvo([[@2026__arXiv__TopoEvo - A Topology-Aware Self-Evolving Multi-Agent Framework for Root Cause Analysis in Microservices]])は、この固着を symptom-amplification bias(症状増幅バイアス)と名付け、Hypothesis Planner に「最も異常な下流ノードは被害者であることが多い」ため victim-as-cause 代替仮説を必ず 1 つ以上含めるよう明示的に指示するプロンプト制約を課す。これは SREGym が報告した「多くのエージェントが最初のもっともらしい異常に固着し、競合仮説を作らない」という問題に対し、トポロジグラフの到達可能性・方向性という構造的制約を仮説生成テンプレートに埋め込むことで対処する具体例であり、JustDiag の主張レベル裁定・RCInvestigator の 5 方向探索とは異なる「反対仮説の強制生成」という第三のアプローチを提示する。(Source: [[@2026__arXiv__TopoEvo - A Topology-Aware Self-Evolving Multi-Agent Framework for Root Cause Analysis in Microservices]] Fig. 4, §III-D) - **TopoEvo の Judge Agent は temporal precedence・path consistency・template consistency の 3 基準チェックリストで仮説検証を行い、JustDiag の主張レベル裁定と同型の設計に収束する**: JustDiag が各仮説を検証可能な主張(Claim)へ分解し `supports/contradicts/insufficient` の verdict で採点するのに対し、TopoEvo の Judge Agent は「原因が結果より時間的に先行するか」「証拠が仮説経路上に位置し依存グラフと整合するか」「証拠が想定される障害テンプレートと一致するか」という 3 基準のチェックリストで判定し、最も競合する 4 つの代替仮説を証拠の矛盾または欠如という理由付きで明示的に棄却する。両者とも「非構造化な自由記述の説明」ではなく「明示的な検証基準に基づく採点」という同じ設計方針に、独立に到達している。(Source: [[@2026__arXiv__TopoEvo - A Topology-Aware Self-Evolving Multi-Agent Framework for Root Cause Analysis in Microservices]] §III-D) - **アブレーションで仮説検証ステップの除去が最大の性能低下をもたらすことが、TopoEvo でも定量的に確認された**: HET(Hypothesis-Evidence-Test)ワークフローを除去すると根本原因特定精度(AC@1)が全データセットで 15〜16 ポイント低下し、これは他の全コンポーネント(表現整列・ベクトル量子化・自己進化メカニズム)の除去による低下幅(8〜12 ポイント)を上回る最大の寄与要因だった。これは、本ページが集める「仮説駆動は推論技法だけでなく制御問題である」という知見(Cloud-OpsBench 等)を、検証ステップそのものの定量的重要性として裏づける追加証拠である。(Source: [[@2026__arXiv__TopoEvo - A Topology-Aware Self-Evolving Multi-Agent Framework for Root Cause Analysis in Microservices]] Table II) - **観測性データの表現そのものが「仮説形成のしやすさ」を左右するという上流の論点が加わる**: 本ページのこれまでの知見は、仮説の生成・検証・棄却を担う制御ループ(JustDiag の主張レベル裁定・RCInvestigator の探索方向・TopoEvo の Judge Agent)を主に扱ってきたが、[[@2026__ICPE Companion__Representation-Aware Root Cause Analysis with Large Language Models (Position Paper)]] はその一段手前——LLM に渡す観測性データの表現自体が仮説形成を助けるか妨げるか——を論じる。同論文は「サービス A→B→C の生トレースは数百のほぼ同一な span 系列を露出し、LLM はまず比較可能なトレースをどれか・逸脱が意味を持つかを自ら推論しなければならない」のに対し、「B→C の呼び出しが異常リクエストの大部分で高レイテンシを示す」という invocation-level 要約は「サービス C は B からの呼び出し下で遅い」という仮説を直接支持し、輻輳や上流影響という代替説明との比較も容易にすると主張する。これは、本ページが整理してきた仮説検証の制御構造(いつ止めるか・どの仮説を棄却するか)とは異なる、**仮説がそもそも立てやすい形にデータを整形する**という前段階の設計課題であり、観測性の粒度・明示性という軸が仮説駆動 RCA のパイプライン全体の入り口に位置することを示す。(Source: [[@2026__ICPE Companion__Representation-Aware Root Cause Analysis with Large Language Models (Position Paper)]] §1, §5) - **証拠取得と仮説確定の分離という同型の設計が、クラウド/マイクロサービス RCA とは独立にネットワーク層の診断でも現れた**: [[エージェント型ネットワーク障害診断]]で集約する [[SADE]]([[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]])は、既存エージェント(ReAct・汎用コーディングエージェント)の主要な失敗要因を「自由形式の熟考の中で証拠取得(evidence acquisition)と仮説確定(hypothesis commitment)を混同すること」と位置づけ、フェーズゲート型ワークフロー(初期スキャン→深層スキャン→症状-故障ファミリ対応付け→スキル駆動の検知)でこれを明示的に分離する。本ページが集める JustDiag の主張レベル裁定・RCInvestigator の探索方向制御・TopoEvo の Judge Agent はいずれも「仮説をどう検証・棄却するか」に焦点を当てるのに対し、SADE は「そもそも仮説を立てる前にどこまで証拠を集め切るべきか」という手前の段階をフェーズゲートで強制する点が異なる。同一 Claude Sonnet バックボーンでの有無比較(SADE vs Claude Code ベースライン)により RCA F1 差 22 ポイントを診断ポリシー自体に帰属させた点は、Cloud-OpsBench が指摘する「仮説駆動 RCA は推論技法だけでなく制御問題である」という知見の、モデル性能と切り離した定量的裏付けを提供する。(Source: [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]) ## 未解決の問い - BubbleUp 型の非 LLM 次元diff自動化(全次元を計算し差分の大きい順にランク付け)は、JustDiag/RCInvestigator/TopoEvo のような LLM ベース仮説管理と、ツールとして直接統合できるか。次元diffで候補次元を絞り込んだ後にLLMへ渡す分業設計は、SREGym が指摘する「最初のもっともらしい異常への固着」問題自体をどこまで軽減できるか未検証。 - TopoEvo の「victim-as-cause 代替仮説の強制生成」は症状増幅バイアスへの効果的な対策だが、マイクロサービスの依存グラフという明示的なトポロジ構造に依存する。トポロジが明示的でないドメイン(例: LLM エージェントの実行トラジェクトリ、分散ストレージの内部状態)でも同様の「構造制約による反対仮説強制」は設計できるか。 - 複数仮説をどの粒度で保持し、どの証拠で棄却済みとみなすべきか。 - 深掘りの停止条件は、証拠充足、予算、矛盾観測、緩和可能性のどれで決めるべきか。 - 仮説駆動 RCA が「もっともらしい物語」へ流れる story mode を、tool citation と contradiction check でどこまで防げるか。 - JustDiag の主張レベル裁定スコア(Score = Sup - Con の合計)は「仮説の正しさ」と「証拠の充足度」を混同している可能性がある。スコアが高くても stalled 終了する Case 7(Score: 67.27 で stalled)がその典型。スコアと確信度の乖離をどう説明するか。 - RCInvestigator の 5 方向探索は「知識グラフ上のノード遷移」を人間が制御するが、候補が多い状況では最適な方向の選択自体が認知負荷になる。知識グラフのミニマップ(専門家からの要望)や LLM による方向提案は、この探索オーバーヘッドを削減できるか。([[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]] §6.3) - OpsMem の LTM(パターン・ケース・プロシージャ)は評価前にインタビュー・アンケート・運用文書から一括構築される(§IV-A4)。本ページが集める「仮説を検証可能な主張へ分解する」(JustDiag)・「人間が探索方向を制御する」(RCInvestigator)といった実行時の人間関与の仕組みと、OpsMem の事前構築 LTM 経験プールはどう補完し得るか。診断中に人間が LTM へ直接介入する余地は OpsMem 論文に記載がない。(Source: [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] §IV-A4) - Wen+ 2026 の invocation-level 表現は「仮説形成を助ける」という定性的主張を Top-k 精度の改善で裏付けるが、JustDiag・RCInvestigator・TopoEvo のような明示的な仮説管理構造(claim・belief-state・judge agent)と組み合わせた場合に、表現改善と制御ループ改善の効果が加算的か、それとも一方が他方を代替するかは検証されていない。「仮説が立てやすい入力表現」と「仮説を管理する制御ループ」のどちらへの投資が費用対効果で優先されるべきかは未解決。(Source: [[@2026__ICPE Companion__Representation-Aware Root Cause Analysis with Large Language Models (Position Paper)]]) - SADE の「証拠取得と仮説確定の分離」をフェーズゲートとして強制する設計は、クラウド/マイクロサービス RCA の文脈(JustDiag・RCInvestigator・TopoEvo)における「仮説の検証・棄却の制御」とどこまで統合可能か。両者を同一の制御ループとして表現できるか、それとも診断対象ドメイン(ネットワーク層 vs アプリケーション層)ごとに異なるフェーズ構造が必要か。 ## 関連 - 親: [[根本原因分析]] - 概念: [[agentic SRE]] / [[SRE]] / [[障害緩和]] / [[エージェント運用安全性]] / [[インシデント認識論]] / [[エージェントメモリ]] / [[RCA入力選別]] / [[エージェント型ネットワーク障害診断]] - エンティティ: [[Jack Kingsman]] / [[Atlassian]] / [[Honeycomb.io]] / [[SADE]] - ソース: [[@2026__SREcon26Americas__Epistemology of Incident Management]] / [[@2016__OReilly__SRE Book - Chapter 12 Effective Troubleshooting]] / [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]] / [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]] / [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] / [[@2019__ACMQueue__Cognitive Work of Hypothesis Exploration During Anomaly Response]] / [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] / [[@2026__arXiv__TopoEvo - A Topology-Aware Self-Evolving Multi-Agent Framework for Root Cause Analysis in Microservices]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 8 Getting Started with Observability Analysis]] / [[@2026__ICPE Companion__Representation-Aware Root Cause Analysis with Large Language Models (Position Paper)]] / [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]] ## 出典 - [[@2026__SREcon26Americas__Epistemology of Incident Management]] - [[@2016__OReilly__SRE Book - Chapter 12 Effective Troubleshooting]] - [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]] - [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]] - [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]] - [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]] - [[@2026__TVCG__RCInvestigator - Towards Better Investigation of Anomaly Root Causes in Cloud Computing Systems]] - [[@2019__ACMQueue__Cognitive Work of Hypothesis Exploration During Anomaly Response]] - [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] - [[@2026__arXiv__TopoEvo - A Topology-Aware Self-Evolving Multi-Agent Framework for Root Cause Analysis in Microservices]] - [[@2026__OReilly__Observability Engineering 2E - Chapter 8 Getting Started with Observability Analysis]] - [[@2026__ICPE Companion__Representation-Aware Root Cause Analysis with Large Language Models (Position Paper)]](§1 導入例・§5 表現設計の3軸) - [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]