# RCA評価設計 ## 定義 RCA評価設計は、根本原因分析手法が本当に因果的な診断能力を持つかを測るため、障害データ、オラクル、指標、過程評価を設計する取り組みである。単純な Top@K や exact match だけでは、実務で役立つ説明・調査コスト・観測不能性を十分に測れない。 ## 横断的知見 - SimpleRCA が既存ベンチで SOTA に匹敵したことは、ベンチが原因サービスだけに症状を局在させすぎていた可能性を示す。([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - 既存ベンチの多くは観測データ欠落を含み、SOTA の失敗モードとして観測ブラインドスポットがある。RCA 評価は [[限定観測可能性]] を明示的に含める必要がある。 - [[Cloud-OpsBench]] は A@K の結果評価だけでなく、IAC/RAR/ZTDR などの白箱過程評価を導入し、結果が当たっても調査過程が脆いケースを分ける。([[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - [[LogPilot]] は exact localization と人手 usefulness を併用し、産業 RCA の受容率を開示した。実務では「当たったか」だけでなく「運用者が採用できる説明か」が評価対象になる。([[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - [[SRE Benchmark]] 系の checklist-based judge は、診断説明や緩和提案を評価できる一方、オラクル設計に人間の判断が混ざる。 - **「障害カテゴリの網羅性」と「ベンチマーク規模」のトレードオフを定量化したのが [[RCAEval]] 2025 WWW Companion 版**: [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]] は 735 ケース・11 種障害(リソース 4・ネットワーク 2・コードレベル 5)・3 システムを統合し、メトリクス系・トレース系・マルチソース系の 15 ベースラインを統一フレームワークで動かせる「使い回し可能ベンチマーク」を目指す。これに対し [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] は障害伝播パターン(Type I/II/III)で評価軸を切る方向、[[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]] は MAS 閉ループによる注入再現性を担保する方向で進化しており、RCA ベンチマーク設計は「カバレッジで広げる」(RCAEval)・「伝播パターンで切る」(FPA)・「決定論的再現性で固定する」(Cloud-OpsBench)の 3 路線が並走している。(Source: [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]], [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - **fine-grained 評価(根本原因インジケータ)を組み込んだ最初の公開 RCA ベンチマークは RCAEval(2025)**: 既存ベンチマークの多くが「根本原因サービス」だけを答え合わせの単位にしてきたのに対し、[[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]] は AC@k/Avg@k を root cause indicator(具体メトリクス・ログ・トレース)粒度でも測れるようにした。コードレベル障害ではスタックトレースで faulty line まで遡及できる点(本論文 §3.2)が fine-grained 評価の新規性を支える。LogPilot の usefulness 評価が「説明品質」軸での評価拡張だったのに対し、RCAEval は「答え合わせの粒度」軸での拡張。両者は orthogonal な fine-grained 化として並ぶ。(Source: [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **本番インシデント記録を題材にした RCA ベンチマークと、合成注入ベンチマークの根本的な評価差**: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] は Microsoft Azure の本番 1 年分(778 件、テスト 208 件)の GPU 訓練インシデントを題材にし、Micro/Macro F1 と検証時間で評価する。これは [[RCAEval]] 等の合成障害注入ベンチが「AC@k で answer を当てる」設計と異なり、(1)カテゴリ分類精度・(2)反復検証コスト・(3)未知ラベル耐性(out-of-distribution)という運用上の評価軸を導入する。Cloud-OpsBench が IAC/RAR/ZTDR の白箱過程評価を導入したのに対し、TSGuard は「正解クラスへの帰属」と「探索コスト」という別軸を強調する。本番由来のオラクルは postmortem ground truth が一意でないノイズを含み(TSGuard は 96% OCE 合意で品質担保)、合成注入の「単一正解 oracle」と本番由来の「人手 ground truth」では評価哲学が異なる。(Source: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]], [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - **実世界データセットのオラクル設計において、CIRCA(KDD 2022)が確立した「単一システム × 単一障害種別 × 正解ラベル付き 99 件」という手作業オラクルの先例が、後続の RCA ベンチマーク設計に影響を与えた**: CIRCA の D_O(Oracle データベースの高 AAS 障害 99 件、197 メトリクス)は、各障害に DBA が特定した根本原因メトリクスを正解ラベルとして手動付与した最初期の実世界 RCA データセットの一つ。この「実運用ログ + 専門家ラベル」の設計方針は、後続の[[RCAEval]](735 件)・[[TSGuard]](778 件、OCE 96% 合意)が踏襲する。一方で CIRCA の D_O は単一の Oracle DB 障害種別に限定されており、[[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] が批判するような「障害伝播パターンの多様性欠如」という弱点は CIRCA の D_O に最も顕著に当てはまる。「オラクル規模と多様性のトレードオフ」が RCA 評価設計の構造的緊張として CIRCA の段階で可視化されていた。(Source: [[@2022__KDD__Causal Inference-Based Root Cause Analysis for Online Service Systems with Intervention Recognition]], [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **「ベースライン側に Dummy を入れて統一比較する」設計は 2024 ASE 版で導入され、2025 WWW Companion 版でトレース系・マルチソース系へ拡張された**: [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]] が初めて Dummy ベースラインを導入して「先行手法を過大評価してきた可能性」を可視化したのに続き、[[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]] は同じ評価枠を維持しつつトレース系(TraceRCA・MicroRank)・マルチソース系(PDiagnose・multi-source BARO/RCD/CIRCA)まで 15 手法に広げた。これは「一つのベンチで異なるモダリティ・アーキテクチャの RCA 手法を横並びにする」評価設計の前例として機能する。(Source: [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]], [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]) - **推論プロセス評価パラダイムの具体的実装としてキーエビデンスと因果チェーンの2形式が提案された**: [[@2026__arXiv__A Multi-Dataset Benchmark for Evaluating LLM Agents in Microservice Failure Diagnosis]]（Cai et al. 2026）は RCA 評価の粒度を単純な「最終回答一致」から「推論プロセス品質」へ引き上げる2つのデータセットを公開した。AIOps2025（400件）は per-modality key-evidence リストを正解ラベルとして用いる Explainability 指標（Em/Et 比）を定義し、RCA100（103件）は因果伝播チェーン（3〜4ステップ）と 661 個の数値制約付き証拠チェックポイントを用いてプロセスを採点する。評価プロトコルの 70% が LLM ジャッジを用いない決定論的採点（UModel エンティティ ID マッチング）であることで再現性を担保し、同時に JustDiag の二層評価が手動 SRE ナラティブに依存するのと比べると大規模適用性を優先した設計となっている。AIOps2025 は Efficiency 指標で「LA 正解ケースでの推論長」をペナルティとして用いるが、エンドツーエンドのレイテンシ・トークン消費を捕捉しないという限界がある。(Source: [[@2026__arXiv__A Multi-Dataset Benchmark for Evaluating LLM Agents in Microservice Failure Diagnosis]] §3, §4.4, §5.4) - **「結果品質(Outcome Score)」と「プロセス品質(Process Score)」を分離した二層評価が説明責任ある RCA に必要**: JustDiag([[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]])は、最終診断アーティファクトのみを評価する Outcome Judge(正確性・証拠根拠付け・因果整合性・実行可能性の加重平均)と、診断プロセスアーティファクトを評価する Process Judge(証拠根拠付け・代替処理・矛盾管理・トレーサビリティ・不確実性管理の単純平均)を独立して使う二層プロトコルを提案する。この設計により「最終回答は正しくても調査プロセスが監査不能」なケースを定量的に分離できる。RCAgent と Flow-of-Action は Outcome Score(44.3/42.8)に対して Process Score(9.5/9.3)が著しく低く、既存アーキテクチャの説明責任欠落が数値化された。(Source: [[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]] §4, Appendix D) - **シルバー参照ナラティブは「完全客観的な ground truth」ではない**: JustDiag の評価は SRE が執筆したシルバー参照ナラティブを使い、ジャッジに「これを絶対的な ground truth として扱わないよう」明示的に指示する。これは TSGuard の 96% OCE 合意や RCAEval の人手ラベルと同様に、「本番インシデントに唯一の正解はない」という現実への対処。ジャッジはシルバーと乖離しても、関連する代替・矛盾・不確実性を証拠に基づいて保持していれば部分点を与える設計。評価設計の哲学として「最終回答一致率」より「診断プロセスの構造的品質」を中心に据える方向性がより適切との示唆。(Source: [[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]] §4.1, Appendix D.1) - **結果のみのラベルから段階的な因果プロセスのラベルへ——障害注入の「既知の介入」を利用した grounding 検証という新路線**: OpenRCA 2.0([[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]])は、根本原因サービスのみをラベル付けする従来設計([[OpenRCA]] 1.0・[[RCAEval]]・[[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds|AIOpsLab]] 等)に共通する限界を、障害注入時に既知である介入 do(v_root) を明示的に使う PAVE パイプラインで解決する。これは Cloud-OpsBench の IAC/RAR/ZTDR 白箱過程評価や JustDiag の Process Judge がエージェントの推論トレースを外側から評価するのとは異なり、**ground truth 自体を段階的な因果グラフとして構築**するアプローチであり、Path Reachability・Node F1・Edge F1 という直接的なグラフ形状指標を可能にする。11 モデルで AnySvc(76.0%)と PR(61.5%)の間に 14.5pp のギャップ(ungrounded diagnosis)が生じることは、Cloud-OpsBench や JustDiag が指摘する「最終回答は正しいが調査プロセスが監査不能」という現象を、人手ラベルや LLM judge なしに定量化できることを示す。(Source: [[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]], [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - **Edge F1 が Node F1 を系統的に下回るという知見は、[[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] の symptom drift 現象と補完的**: Fang らの旧研究(2510.04711)は「真の原因サービスと最も目立つ症状が異なるシナリオ」への SOTA の失敗を報告したが、OpenRCA 2.0 はこれをさらに掘り下げ、正しい根本原因サービスを言い当てた場合でも、そこから症状への経路(有向グラフの形)を正しく推論できるとは限らないことを示した(Edge F1 43.4% vs Node F1 62.2%、18.8pp のギャップが全モデルで一貫)。両研究は同一著者グループ(Aoyang Fang・Pinjia He ら CUHK-Shenzhen)による連続的な深掘りで、「ベンチマークの単純さが性能を過大評価する」(2510.04711)から「outcome-only 評価が推論過程の欠陥を隠す」(2606.27154)へと問題意識が精緻化されている。(Source: [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]], [[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]]) - **正解ラベルを既知として使う post-hoc な誤り帰属(reverse reasoning)は、outcome/process 二層評価に「なぜ失敗したか」を定量分解する第三の軸を加える**: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] の reverse reasoning agent は、誤った予測ごとに正解の根本原因から抽出済みアノマリーまでのエビデンスチェーンを再構築し、各次元(コンポーネント・reason・タイムスタンプ)を Reasoning Gap(証拠は存在したが未使用)・Data Ambiguity(証拠が真に不在)・None に独立分類する。OpenRCA 2.0 の PAVE パイプラインが**ground truth 自体**を段階的因果グラフとして構築し Path Reachability・Node F1・Edge F1 で評価するのに対し、reverse reasoning agent は**予測の誤りを事後的に遡って診断する**点で異なるアプローチを取る。両者とも「最終回答一致率だけでは推論品質を測れない」という同じ問題意識から出発しているが、OpenRCA 2.0 は評価前にグラフ構造のラベルを用意する設計、reverse reasoning は評価後に失敗ケースを LLM で遡及分析する設計という対比をなす。Market CB1(DK OFF)では reason 次元で Type 1(Reasoning Gap)が 65.7%、Type 2(Data Ambiguity)が 11.4% という結果は、「性能はデータアクセスではなく推論能力によって頭打ちになる」という定量的な結論を導出可能にした。(Source: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] §III-D, Table VII, [[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]]) - **held-out スプリットによるリークコントロールは、キュレーション型ドメイン知識と自動マイニング型ドメイン知識の両方に共通する評価要件として定着しつつある**: 手動ドメイン知識は正解ラベルを参照しながら構築されるため developed-on-test の楽観性が疑われる。[[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] はドメイン知識構築に使ったウィンドウを除外した held-out スプリットで DK ON を再評価し(変化は最大数ポイント)、さらに自動マイニングされたルールについても CB1 で学習し CB2(未使用)に適用するという held-out 検証を行った。前者はキュレーション済み知識の楽観性を測る従来型のリークコントロール、後者は「学習データと評価データの分離」という機械学習的な評価規律を LLM ベース RCA のドメイン知識注入に持ち込んだ点で新しい。両者を同一論文内で並行実施した点は、RCA 評価設計において「知識源の出処(手動 or 自動)によらずリーク検証を要求する」という規律の一般化を示す。(Source: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] §V-D, §V-E, Table VI) ## 未解決の問い - **reverse reasoning agent の Reasoning Gap/Data Ambiguity 分類自体の信頼性(ジャッジとしての LLM の正確性)は検証されていない**: reverse reasoning agent 自身も LLM であり、その分類判断(証拠が「存在した」かどうかの判定)にハルシネーションや見落としが混入する可能性がある。JustDiag が LLM judge の妥当性をシルバー参照ナラティブとの整合で間接的に検証するのに対し、本論文の reverse reasoning agent の分類精度を人手でサンプル検証した記述はない。(Source: [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]]) - RCA の評価単位は root service、root metric、root category、causal chain、human-readable report のどれに置くべきか。 - 1 障害 1 根本原因ではなく、多対多の症状・原因関係を持つ本番インシデントをどうベンチ化するか。 - 調査過程が破綻していても最終回答が当たるケースを、本番導入で信頼してよいか。 - LLM judge と人手評価を併用する場合、再現性と運用有用性のバランスをどう取るか。 - RCAEval の予備実験(Train Ticket / RE2 / 6 障害)で多くのマルチソース版が単独メトリクス版より劣る結果(CIRCA: 0.32 → 0.06、RCD: 0.09 → 0.10)を示した。マルチモーダル化の評価において、(a) 単純結合では性能が落ちる現象、(b) どの障害種別でモダリティ統合が効くかという問いは、ベンチマーク評価軸として独立に切り出すべきか。([[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]) - TSGuard 評価で未解決の 28 件は人間でも 122 時間 TTM の本質的に困難なケース。RCA ベンチマークは「現状の手法で解けないケース」を明示的にラベル化し、評価対象から除外する/別軸で集計する設計が必要か。([[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]]) - RCAEval の coarse-grained(root cause service)と fine-grained(root cause indicator)を両立した時、両指標の相関と独立性はどう変わるか。fine-grained で評価される個別メトリクス特定の難しさは、サービス特定の難しさを補助予測する指標になるか。([[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]) - JustDiag の Process Score(証拠根拠付け・代替処理・矛盾管理・トレーサビリティ・不確実性管理)の 5 次元は、人間 SRE が実際に評価する時の基準と整合するか未検証。各次元の重み(単純平均)は恣意的であり、タスク・組織・リスク許容度によって変わるべき可能性がある。([[@2026__arXiv__JustDiag! A Diagnostic Justification Engine for Accountable Root Cause Analysis]]) - OpenRCA 2.0 の PAVE パイプラインは注入介入 do(v_root) というアノテーション時にのみ得られる特権情報に依拠する。評価時にはこの情報は不要だが、同じ段階的因果 ground truth を「制限されたテレメトリ(サブサンプルされたトレース・欠落モダリティ・切り詰められた観測窓)」下でのエージェント評価に転用する場合、観測条件を情報可用性の制御可能な評価軸として体系化する設計はまだ手つかず。([[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]] §5) - OpenRCA 2.0 の PR(Path Reachability)は「1 つの正しいアンカーから 1 つの有効な経路」を要求するにとどまる最も緩い process 指標である。Node F1/Edge F1 のような厳密なグラフ全体一致と PR のような緩い経路存在確認の中間に位置する、部分的に正しい経路(一部のホップは合っているが分岐を見逃す等)を段階的に採点する指標は未定義。([[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]] §G.2.3) ## 関連 - 親: [[根本原因分析]] - 概念: [[SRE Benchmark]] / [[障害注入]] / [[限定観測可能性]] / [[Fault Localization]] / [[マルチモーダル障害診断]] / [[インシデント管理]] / [[因果発見]] - エンティティ: [[RCAEval]] / [[TSGuard]] / [[OpenRCA]] - ソース: [[@2026__arXiv__A Multi-Dataset Benchmark for Evaluating LLM Agents in Microservice Failure Diagnosis]] / [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] / [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]] / [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] / [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]] / [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] / [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]] / [[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]] / [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]] ## 出典 - [[@2026__arXiv__How Far Can Root Cause Analysis Go on Real-World Telemetry Data?]](§III-D reverse reasoning agent による Reasoning Gap/Data Ambiguity 分類設計、Table VII 誤り分類結果、§V-D/§V-E held-out リークコントロール) - [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] - [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]] - [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] - [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]](§3 データセット 3 種・735 ケース・11 種障害、§4 15 ベースライン統一評価、§5 Train Ticket / RE2 予備実験 Table 6) - [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]](§5.1 本番 778 件のキーワードフィルタ + OCE 96% 妥当性、§5.2 Macro/Micro F1 + カテゴリ別 + 未知ラベル耐性、§5.4 未解決 28 件の TTM 分析) - [[@2024__ASE__Root Cause Analysis for Microservices based on Causal Inference - How Far Are We]](Dummy ベースライン導入の起点) - [[@2026__arXiv__A Multi-Dataset Benchmark for Evaluating LLM Agents in Microservice Failure Diagnosis]](§3 設計原則、§4.4 AIOps2025 評価プロトコル、§5.4 RCA100 評価プロトコル、Table 1 既存ベンチマーク比較) - [[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]](§2 PAVE パイプライン、§3.2 outcome/process 二層評価 Table 2、§3.4 二重アノテータ監査 94%、§G 指標定義)