> [!abstract] 概要(arXiv abstract の日本語訳) > 根本原因分析(RCA)は、長文脈理解・多段階推論・ツール使用といった LLM エージェント能力を包括的に試す課題である。しかし既存のデータセットには根本的な欠陥がある。根本原因のみをラベル付けし、それを観測された症状に結びつける伝播経路をラベル付けしていないため、タスクが素朴なパターンマッチングに大きく単純化されてしまう。厳密な評価を支えるため、我々は PAVE を導入する。これは障害注入による既知の介入を活用して因果伝播経路を再構成する、段階的なラベリングプロトコルである。そのメカニズムは前向き検証(forward verification)——症状から後ろ向きに推論するのではなく、原因から結果へと推論する——である。PAVE を適用すると OpenRCA 2.0(500 インスタンス)が得られる。これは LLM エージェント向けに段階的な因果アノテーションを持つ初の cross-system RCA ベンチマークである。11 の最先端 LLM 全体で、厳密な根本原因集合の回復に成功するのは平均 20.7% のケースにとどまる。この困難がどこにあるかを特定するため、基準を緩めると、我々が grounding されていない診断(ungrounded diagnosis)と呼ぶものが見つかる。エージェントは 76.0% のケースで少なくとも 1 つの正しい根本原因サービスを特定するが、それを観測症状への検証済み因果伝播経路として grounding できるのは 61.5% にとどまる。結果のみの評価はこの失敗モードを隠してしまう。段階的な因果 ground truth こそが、信頼できる LLM ベース RCA エージェントに欠けている最後のピースである。 ## 論文情報 - タイトル: OpenRCA 2.0: From Outcome Labels to Causal Process Supervision - 著者: Aoyang Fang, Yifan Yang, Jin'ao Shang, Qisheng Lu, [[Junjielong Xu]], Rui Wang, Songhan Zhang, Yuzhong Zhang, Boxi Yu, [[Pinjia He]](corresponding) - 所属: [[The Chinese University of Hong Kong, Shenzhen]] - 媒体: arXiv プレプリント(Preprint 表記、投稿先会議名は非公開) - arXiv ID: 2606.27154(v2, [cs.AI], 2026-06-30 改訂。初版投稿は 2026-06-25) - コード/データ: CC-BY-SA 4.0(データセット)・Apache 2.0(パイプラインコード)で公開予定(受理後) ## 概要 既存 RCA ベンチマークは根本原因サービスのみをラベルとし、原因から症状への因果伝播経路を記録しないため、モデルの学習・評価が「答え当て」に矮小化される問題を指摘する。論文は障害注入時に既知の介入 do(v_root) が使える情報非対称性を利用し、原因から結果への前向き検証によって伝播経路を再構成する PAVE パイプラインを提案する。これを 3 つの異なるマイクロサービスシステムに適用して 500 インスタンスの OpenRCA 2.0 を構築し、11 の最先端 LLM を outcome 層・process 層の両方で評価することで、正しいサービスを言い当てても検証可能な経路で裏づけられない「grounding されていない診断」という新しい失敗モードを可視化する。 ## 問題設定 - 入力: マイクロサービスシステムの二層依存グラフ G = (V, E)(サービス・Pod・ホスト)上で発生した障害から得られる、事後のマルチモーダルテレメトリ O_obs(トレース・メトリクス・ログ)。 - 出力: エージェントは根本原因の集合と、それを裏づける因果伝播グラフ(有向エッジ)を提示する。事前に依存グラフは与えられない(トポロジーの漏洩を避ける設計、§F.4.4)。 - 前提条件: 障害注入(Chaos Mesh)によって既知の介入 do(v_root)(対象コンポーネント・障害種別・注入窓 [t0, t0+Δt]・パラメタ)が記録されていること。これはアノテータだけが持つ情報であり、エージェントは持たない——この非対称性(式 (1): {O_obs} ⊂ {O_obs, do(v_root)})が、後ろ向きの推論問題を前向きの検証問題に変換する鍵となる。 - 必要なデータ: 事前注入ベースラインウィンドウのテレメトリ、注入後のテレメトリ、システム依存グラフ。 ## 提案手法 - **アーキテクチャ**: PAVE(Path Annotation via Verified Effects)は 2 フェーズのパイプライン。Phase 1(構造的枝刈り)がトポロジー上あり得る候補経路集合 Π_cand を作り、Phase 2(因果検証)がテレメトリ照合で真に検証された経路集合 Π* に絞り込む(Figure 3)。 - **アルゴリズム/手法の詳細**: - Phase 1 は生テレメトリ O(t) を離散状態アルファベット Σ(HighLatency, CPU_Throttled 等)に射影する型認識マッピング Ψ を使い、伝播ルール集合 R(§D.6、Table 7 に 4 カテゴリ 13 ルール——垂直: container→span・pod→span、first-hop: service→span、水平: span→span の RPC カスケードが全エッジの 8 割超、cross-channel: span→pod→span)が許すノード状態遷移だけを許容する。時間展開された異種グラフ上の制約付き DFS で循環依存を非巡回チェーンに展開し、Π_cand を得る。 - Phase 2 は各候補経路の各ノードについて、注入直前に記録した参照ベースライン D_base(P(・|do(v_root=∅)) の近似)と比較する分布検定を課す(Z-score・パーセンタイル・適応的レイテンシ検定を指標種別ごとに使い分け、§D.8)。経路 π が検証されるのは (i) 経路上の全ノードがベースライン逸脱を示す、(ii) 全ての連続エッジが R に適合する、(iii) 下流の異常が上流原因より早く発生しない、の 3 条件が同時に成立する場合のみ。 - 条件付き受理の確率的裏づけ(§D.8): 各条件の単独偽陽性率を p_s, p_r, p_t とすると、長さ k の非因果的経路が全条件を通過する確率は上界 (p_s・p_r・p_t)^k で指数的に減衰する(式 (3))。p_s=0.2, p_r=0.3, p_t=0.5 でも k=3 で ≈2.7×10^-5 となり、長い経路ほど誤って受理されにくいという設計原理を数値で裏づける。 - **実装上の工夫**: 各ノード単位の異常検知は意図的に寛容(偽陰性を避ける)にし、精度は経路全体の連言的検証(3 条件の同時成立)に委ねる階層設計。これにより単一検出器の感度と ground truth 全体の精度を分離できる。 **Figure 2: RCA の設定** ![[_attachments/arxiv-2606.27154/fig02-rca-setting.png]] (Figure 2. マイクロサービスシステムは 2 層の依存グラフを形成する。Seat に注入された障害は RPC チェーン(Seat→Travel→Order)に沿って水平に伝播しつつ、共有インフラ(同居 Pod 等)を通じて垂直にも伝播しうる。エージェントはテレメトリ(トレース・メトリクス・ログ)のみを観測し、隠された発端の障害へ後ろ向きに推論しなければならない。Source: Figure 2.) **Figure 3: Coarse-to-Fine 検証** ![[_attachments/arxiv-2606.27154/fig03-coarse-to-fine-verification.png]] (Figure 3. TrainTicket の実例: 真の根本原因は Seat で、Route は背景ノイズにより異常に見える無害なサービス。入力段階では観測された全ての異常と全ての潜在エッジが保持され根本原因を絞り込めない。Phase 1(構造的枝刈り)はトポロジーが許さないエッジ(例: Route→Seat)を除去するが Route 自体はまだフラグが立つ。Phase 2(因果検証)は各候補を事前注入ベースラインと照合し、Route の逸脱がベースラインノイズと一致するため除去され、チェーン Seat→Travel→Order のみが残る。Source: Figure 3.) ## 新規性 - 既存 RCA ベンチマーク([[OpenRCA]] 1.0・AIOpsLab・RCAEval・Stratus・Fang らの旧版 arXiv:2510.04711)はいずれも根本原因の同一性のみをラベル付けし、伝播経路のアノテーションを持たない(AIOpsLab は issue-type タグという部分的な形のみ)。Table 3 の比較で OpenRCA 2.0 だけが Outcome・Process・明示的な SLO サーフェス・LLM 評価の 4 軸すべてを満たす。 - 観測データのみから因果構造を推定する従来の因果発見手法(PC アルゴリズムなど)は交絡変数と高次元ノイズに弱く識別可能性の保証を欠くが、PAVE は障害注入という介入データ(do(x))を積極的に活用し、構造学習という難問を検証というより扱いやすい問題に変換する([[因果発見]] との対比、§4.2)。 - 評価軸として Path Reachability(PR)・Node F1・Edge F1 という因果グラフの「形」を採点するプロセスレベル指標群を導入し、outcome-only 評価が隠す ungrounded diagnosis を定量化した点が最大の新規性。 ## 実験設定 - **システムと障害**: TrainTicket(44 サービス、Java/REST、既存の Fang らの障害注入基盤を再利用)・OpenTelemetry Demo(15 サービス、ポリグロット、gRPC+Kafka)・Hotel Reservation from DeathStarBench(9 サービス、Go/gRPC)の 3 システムに、27 の chaos primary kinds(Table 5、PodChaos・StressChaos・HTTPChaos・DNSChaos・NetworkChaos・TimeChaos・JVMChaos の 7 カテゴリ)を注入。生の注入プールは 8,137 回で、silent injection(ユーザー影響なし)を除外し PAVE を適用、(system, chaos family, root service) で層化選択して 500 の評価可能インスタンスに絞る(§3.1, §A.2)。 - **クラスタ**: Kubernetes v1.29、1 control-plane(48 vCPU/64GB)+ 6 worker(worker1-3: 32vCPU/64GB、worker4-6: 128vCPU/128GB)の共有クラスタに 3 システムを別名前空間でホスト(§D.4)。 - **比較対象・エージェント設計**: 全モデル共通のツール拡張 ReAct 型エージェント(Deep Research agent [13] を踏襲)。llm_call → tool_node → compress_rca_findings の 3 ノードループで、ツールは list_tables_in_directory・get_schema・query_parquet_files(DuckDB SQL)・think_tool の 4 種。ツール呼び出し予算は目安 50 回、ハードキャップ 100 回。依存グラフは与えない(§F.2, §F.4)。 - **評価モデル**: Claude Opus 4.7・Gemini 3.1 Pro・Claude Sonnet 4.6・MiMo 2.5 Pro・GLM 5.1・Kimi K2.6・DeepSeek V4 Pro・Qwen3.6-Max・Hy 3.0 Preview・Seed 2.0 Pro・MiniMax M2.7 の 11 モデル(全モデル同一システムプロンプト・ツール定義・温度 0.7)。GPT-5.4・GPT-5.5 は API 予算制約で部分カバレッジのため付録で別掲(§F.5, §H.3)。 - **評価指標**: outcome 層(Exact Match・F1/Precision/Recall・AnySvc)と process 層(Path Reachability・Node F1・Edge F1・SQL Exec)の二層構成(§G)。Path Reachability は AnySvc を満たしかつ予測グラフ中にその根本原因サービスから ground-truth alarm ノードへの有向経路が存在する割合。HIT-anchored 版(サービスと障害種別の両方が一致するアンカーのみを認める、SDK 標準)も付録 Table 9 で別掲。 ## 実験結果 - **プールされたメイン結果(Table 2, n=500)**: 平均 F1 は 34.1%、EM は 20.7% と outcome 層はすでに低いが、AnySvc は 76.0% に達し「少なくとも 1 つの正しいサービスは言い当てられている」ことを示す。しかし最も緩やかなプロセス指標である PR でも 61.5% にとどまり、AnySvc から PR への 14.5pp のギャップが ungrounded diagnosis の直接的な規模。最高性能は Gemini 3.1 Pro(F1 43.8%、PR 70.4%)、最低は MiniMax M2.7(F1 20.6%、PR 46.4%)。 - **Edge F1 対 Node F1 のギャップ(Finding 2)**: 全 11 モデルで Edge F1(平均 43.4%)が Node F1(平均 62.2%)を 18.8pp 下回る。Gemini は Node F1 67.9% に対し Edge F1 36.8% と最大の分裂。サービスの特定は分類タスクに近く事前学習が得意とするが、それらを有向グラフへ組織化するには追加の推論ステップが要る。 - **単一モデルの支配なし(Finding 3)**: Table 2 の列ごとの最大値は 4 つの異なるモデルに分散(EM/F1: Gemini、AnySvc: 個別、PR: Qwen3.6-Max 71.8%、SQL Exec: Gemini 98.8%)。PR/AnySvc の条件付き比率は Qwen3.6-Max が 71.8/79.2 ≈ 91% に対し Claude Sonnet 4.6 は 52.6/79.4 ≈ 66% と、F1 が近くても grounding 能力に差がある。 - **システム別内訳(Table 8, §H.1)**: Hotel Reservation(142 件、9 サービス、平均最長経路 2.1 ホップ)では Opus が AnySvc 99.3%・EM 54.9% と飽和に近いが、TrainTicket(320 件、44 サービス、3.0 ホップ)では同モデルが AnySvc 75.3%・EM 15.6% まで低下。OTel Demo(38 件、15 サービス、2.5 ホップ)は中間(AnySvc 81.6%・EM 26.3%)。サービス数と経路の深さがともに難易度と同方向に効く。 - **失敗パターン分析(§3.3)**: (1) 探索不足下の早期コミット——複数障害が併存する hybrid injection で、モデルは目立つ半分に収束し subtle な半分を一律に見落とす。(2) 観測活動への presence bias——killed-pod 注入でスパンが完全に消える現象を「異常なし」と誤読し、上流の呼び出し元(エラーを表出させたサービス)に誤帰属する。(3) 最も目立つ信号への salience capture——高トラフィックのハブが注意を奪い、低トラフィックの真の根本原因サービスが見逃される。AnySvc が完全網羅から約 24pp 不足する主因。 - **アノテーション信頼性(§3.4)**: 500 件から一様無作為抽出した 100 件の二重アノテータ監査でケースレベル一致率 94%(94/100)。全 6 件の不一致は一方向(検証済み経路 G* に含まれるべきだが弱いエビデンスのため除外された経路がある、という under-coverage)で、G* に含まれる誤ったエッジ(偽陽性)は監査サンプル中ゼロ。 **Figure 1: ungrounded diagnosis の例** ![[_attachments/arxiv-2606.27154/fig01-ungrounded-diagnosis-example.png]] (Figure 1. Seat サービスでの NetworkDelay 障害を例にした ungrounded diagnosis。既知の介入(上)から PAVE は検証済み因果経路 Seat→Travel→Order→Gateway を再構成する(中)。エージェントは正しい根本原因を言い当てるが、Travel を飛ばす経路を作る(下): outcome-only 評価はこれを成功として採点するが、process レベル評価は欠落エッジを表面化させる。Source: Figure 1.) **Figure 4: 虚偽の因果推論ケース** ![[_attachments/arxiv-2606.27154/fig04-spurious-causal-reasoning.png]] (Figure 4. (a) ground truth は中間サービス(travel、travel2)を経由する障害伝播を示す。(b) Claude は根本原因(ts-basic-service)と症状を正しく特定するが、travel2/travel を飛ばして ts-route-plan-service への直接エッジを幻覚し、分岐構造を見逃す(Edge F1=44.4%)。この事例は §3.3 の Pattern (1) を経路描画の次元で例示するケーススタディとして本文に記載。Source: Figure 4, §3.3 Case Study.) ## 考察 - outcome 層の指標は 2 つの異なる失敗モードを 1 つの数値にプールしてしまう。緩やかな AnySvc(76.0%)は「サービスを言い当てる」能力を、厳密な F1(34.1%)/EM(20.7%)は「fault_kind まで正確にラベル付けする」能力を混ぜて測っており、両者のギャップの大半は識別したサービスの障害種別誤りに起因する。だが最も緩やかなプロセス指標 PR ですら 76.0% に届かない事実が、これがラベリングの artefact ではなく推論の失敗であることを示す決定的な証拠。 - Edge F1 が Node F1 を系統的に下回るという発見は、エージェントの出力(サービスのリスト)がその導出過程(有向グラフ)よりも ground truth に近いことを直接示す証拠であり、その乖離はモデル選定に影響するほど大きい。 - 内的脅威として、ルール集合 R が語彙外の伝播機構を暗黙に枝刈りしてしまう可能性と、ノード単位の異常検知器が低偽陰性に較正されているため個々のノードを偽陽性気味に許容してしまう可能性の 2 つの単一ゲート弱点が残るが、3 条件の連言的検証設計によりエンドツーエンドの誤りへは伝播しにくいと主張する(§5)。 - 外的妥当性については、本番規模のマイクロサービス展開を忠実に模擬することは目的でも到達可能でもないとし、報告数値はテストベッドの範囲内での結果であり本番への転用には別途較正が必要と明言する。 ## 強み / 弱点・課題 - **強み**: (1) 障害注入の介入情報という「答えを知っているアノテータ」の非対称性を明示的に利用し、後ろ向き推論というアノテーションの根本的難しさを回避する設計思想が明快。(2) 3 システム・27 障害種別にまたがる cross-system ベンチマークで、単一システムへの過適合を避ける。(3) 二層アノテータ監査(94% 一致、偽陽性エッジゼロ)により ground truth の健全性を実証的に裏づける。(4) Path Reachability・Node F1・Edge F1 という因果グラフの形を直接採点する指標群により、outcome-only 評価が隠す失敗モードを定量的に可視化した。 - **弱点・課題(論文が認める)**: (1) 入力前提——真の介入 do(v_root)・完全なサービス層依存グラフ・トレース/メトリクス/ログいずれかでの伝播シグネチャ・清浄な事前ベースラインという 4 条件が崩れる設定では、報告値は転用可能な推定値でなく上界として読むべき。(2) ルール集合 R の語彙外の伝播機構、および過度に寛容なノード単位検出器という 2 つの単一ゲート弱点が内的脅威として残る。(3) 本番スケールのマイクロサービス展開の忠実な模擬は目的でも到達可能でもないため、本番への転移は較正が必要。(4) アノテーションは PAVE の設計上、精度優先(弱いエビデンスの経路は除外)でカバレッジを犠牲にしており、実際に監査での 6 件の不一致は全て under-coverage 方向だった。(5) 全トレラン情報を要するのはアノテーション時のみで評価時は不要という非対称性を利用し、制限テレメトリ下でのエージェント評価という発展的方向を今後の課題として残す。