# Fault Localization ## 定義 Fault Localization(障害箇所特定)は、障害や異常が検知された後に、原因候補となるコンポーネント、サービス、ホスト、メトリクス、ログ系列、ネットワーク経路、GPU/ランクなどの「場所」を絞り込む取り組みである。[[AIOps]] の 4-level taxonomy では検知の後、[[根本原因分析]] の前に置かれるが、LLM 系サーベイでは RCA の下位タスクとして扱われることもある。(Source: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]], [[A Survey of AIOps in the Era of Large Language Models]]) このページは親概念であり、詳細は隣接ページへ分ける。RCA の評価指標は [[RCA評価設計]]、入力削減は [[RCA入力選別]] と [[特徴量削減]]、ログ由来の component localization は [[ログ解析]]、トレース由来の手法は [[分散トレーシング]]、訓練クラスタと RDMA 網の箇所特定は [[LLM学習モニタリング]]・[[RDMAネットワーク監視]]・[[GPUクラスタ運用]] に置く。 ## 子概念 - [[RCA入力選別]] - [[RCA評価設計]] - [[エージェント型ネットワーク障害診断]] - [[カーネル障害診断]] - [[不均衡障害分類]] - [[特徴量削減]] ## 横断的知見 - **障害箇所特定は「どこ」を答え、RCA は「なぜ」を答えるが、境界は手法ごとに揺れる**: MetricSifter や Minder は root fault metrics / faulty machine を絞る段階で止まり、根本原因の説明は後段に残す。一方 LogPilot はログから faulty component と root cause summary を同時に出すため、箇所特定と RCA が一体化する。(Source: [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **信号源は、ドメインの構造に従って変わる**: マイクロサービスでは依存グラフと伝播、分散トレースではリクエスト経路と処理時間、ログではイベント系列と言語情報、LLM 訓練クラスタでは均質な並列ワークロードからの逸脱、RDMA/ネットワークでは経路・層・来歴が信号源になる。単一の localizer を全ドメインに転用するより、信号源ごとに手法を分ける方が自然である。(Source: [[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **粒度は component → metric → machine/rank → network layer へ細分化している**: Pinpoint はリクエストトレースと統計検定でコンポーネントを絞った。MetricSifter はメトリクスレベルへ下り、Minder/Pulse は訓練クラスタでマシン・ランク単位へ下り、R-Pingmesh/Astral/Hawkeye は物理リンク、スイッチ、end-host、PFC backpressure の起点へ降りる。粒度が細かくなるほど、監視解像度とデータ量の制約が強くなる。(Source: [[@2002__DSN__Pinpoint - Problem Determination in Large, Dynamic Internet Services]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - **入力削減は古典統計手法と LLM エージェントの共通課題である**: MetricSifter は無関係メトリクスが因果探索へノイズを持ち込むため事前に削る。AIOpsLab や Bits AI SRE では、エージェントがテレメトリを取りすぎるとコンテキストウィンドウを圧迫し性能が落ちる。箇所特定の精度は、推論器の賢さだけでなく、どの信号を見せないかにも依存する。(Source: [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **Baidu のメトリクススクリーニングは、FluxRank 論文化前の実務向け箇所特定パターンを示す**: [[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis|Chen SREcon18 Americas]] は、コールグラフを見ながら上流から下流へモジュールを調べる診断作業を、メトリクス異常度測定・インスタンス単位のクラスタリング・ダイジェストランキングで置き換える。後続の [[@2019__ISSRE__FluxRank - A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]] が「根本原因マシン箇所特定」として詳細化する前に、SRE 実務者向けには「ゴールデンメトリクス設定を不要にし、読むべきメトリクス集合を推薦する」問題として提示されていた。これは障害箇所特定が、説明生成より先に「どこを見るか」を縮小する運用支援として導入されたことを示す。(Source: [[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis]], [[@2019__ISSRE__FluxRank - A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation]]) - **評価指標は SE FL と AIOps FL で似ているが、同一ではない**: Kochhar+ 2016 は実務者が Top-5 成功、成功率 75%、100kLOC、1 分以内、判断根拠を強く求めることを示した。AIOps 系では AC@K、Avg@K、Exact Match、Top-3 などが使われる。どれも「上位 K に原因候補が入るか」を測るが、ランキング品質、説明品質、緩和への有用性は別に評価する必要がある。(Source: [[@2016__ISSTA__Practitioners' Expectations on Automated Fault Localization]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **前処理段の精度指標は箇所特定の精度指標の不完全な代理指標にとどまる——「削減の良さ」と「特定の良さ」は同じ問題を測っていない**: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]](博士論文第 5 章)は、[[特徴量削減]] の balanced accuracy(BA)と箇所特定の AVG@5 との決定係数 $R^2$ を localization 手法別に測定し(Tab. 5.4)、ε-Diagnosis を除いて 13.9–51.0% しか説明しないことを定量的に示した。さらに PC・LiNGAM のような統計的因果探索系ほど $R^2$ が高く(RS より高い)、RCD・HT 系では削減の specificity より recall の方が寄与するなど、代理指標としての有効性は下流の localizer アーキテクチャに依存する。これは本ページの「評価指標は SE FL と AIOps FL で似ているが同一ではない」という知見をさらに一段掘り下げ、同じ AIOps パイプライン内でも**前処理の評価指標と本体タスクの評価指標の間に系統的なギャップがある**ことを示す——DéjàVu の Top-K 成功と説明品質の乖離(§本ページ既存知見)と同型の問題が、削減と特定という隣接タスク間でも起きている。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]], Tab. 5.4, [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]]) - **運用目的によって、精密な箇所特定と粗い隔離は分岐する**: 研究ベンチマークは正しい root cause entity を細かく当てる方向へ進むが、LLM 訓練基盤では継続を優先して並列グループ単位で過剰排除する設計もある。復旧時間を最小化する場面では、正確な箇所特定より迅速な隔離が合理的になる。(Source: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - **「どこ」と「どの種類」を同時に推薦するアクション可能な箇所特定が実務家の本来のニーズである**: DéjàVu([[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]])は「障害ユニット(failure unit = コンポーネント × メトリクスグループ)」という概念を導入し、「個別メトリクス(細かすぎて緩和策が見えない)」と「コンポーネント単体(粗すぎて種別が分からない)」の中間を狙う。産業調査では平均診断時間 28.98 分のうち障害ユニット特定に 9.2 分かかっており、ここを自動化すれば緩和策への接続が直接速くなる。(Source: [[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]] §2.3) - **[[再帰障害]](74〜94%)は監督学習の強力な根拠であり、GNN ベース手法が有効**: DéjàVu は[[障害依存グラフ]](FDG)上で GAT を 8 層スタックし、障害伝播を多ホップでモデル化する。同クラス内の過去障害から学習した特徴抽出器は、初めて現れる箇所(未知ユニット)の同種障害にも汎化する。これは「コンポーネントの場所でなくメトリクスパターンで種別を認識する」設計による。(Source: [[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]] §3.1, §5.5) - **障害特徴の不均衡分布は GAT+アテンション系手法でも残る構造的課題であり、損失関数設計で補完できる**: [[FL-AIer]]([[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]])は DéjàVu と同一データセット・同一「障害ユニット」概念を使いながら、多層 GAT（残差付き）＋ 1D-CNN で長距離依存と時空間特徴を強化し、マルチヘッドアテンションで障害特徴間の複雑な依存関係を解消し、Fault Knowledge Balancing（重み付き KL ダイバージェンス損失＋過剰サンプリング）で低頻度障害クラスへの過小学習を是正した。結果 DéjàVu に対し A@1 で +5.82〜+15.56%（平均 +9.24%）を達成。アーキテクチャ改善ではなく、同粒度設計のままトレーニング設計と依存関係処理が性能向上の源泉である。(Source: [[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]], [[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]]) - **解釈可能性は「内部機構の理解」より「診断経路の提示」が産業実務に合っている**: FL-AIer は LIME・LR のような特徴重要度スコアを使わず、特徴符号化の出力を入力として意思決定木(DT)を代理モデルとして訓練し、「伝送キュー 1 → 2 → ss_total で障害」というステップ別の診断経路をエンジニアに提示する。LLM ベースの障害説明と異なり、DT の分岐ルールは決定論的で再現可能である。これは Kochhar+ 2016 の実務者ニーズ調査（判断根拠の提示を強く求める）と一致する。(Source: [[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]], [[@2016__ISSTA__Practitioners' Expectations on Automated Fault Localization]]) - **変更後サービスの不均衡障害データは GAT 系・深層学習系手法の共通の盲点であり、損失関数設計だけでは対処できない**: FL-AIer の FKB（Fault Knowledge Balancing）は同一データセット内の障害クラス不均衡を重み付き損失で補正するが、これは「既存サービスの障害種別のサンプル数が多すぎる」第一の不均衡への対応にすぎない。新規デプロイサービスで「その障害種別のサンプルが 1〜2 件しかない」第二の不均衡には対処できない。SLIM はこの第二の不均衡に対し、DNF ルールセットと劣モジュラ最適化により F1 スコアを直接最大化するアルゴリズム設計レベルの解答を与えた最初の手法である。DejaVu は再サンプリングでこれを解決しようとしたが、実験上では効果が限定的であることが示された。(Source: [[@2024__ASE__SLIM - A scalable and interpretable light-weight fault localization algorithm for imbalanced data in microservice]], [[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]], [[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]]) - **ラベル不要の RCL は「システム偏差との類似度ランキング」で実現できる**: ART([[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]])は、インスタンスレベル偏差(ILD)とシステムレベル偏差(SLD)のコサイン類似度をランキング指標として使う教師なし RCL を提案した。実証研究では根本原因インスタンスの ILD-SLD 類似度が 0.71〜0.77 に対し非根本原因は 0.49 と定量的に分離可能であることを示し、監視ありの Dejavu・DiagFusion を上回った。このアプローチは「どのモジュールが根本原因か」を「どのインスタンスの偏差パターンがシステム全体の偏差パターンに最も近いか」という距離問題として再定式化する——ラベル付き障害事例が蓄積されていない初期段階でも即座に適用できる。(Source: [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]], §2.1, §4, Table 6) - **LagRCA(FSE Companion '26)は箇所特定の「時刻の整合性」を明示的な設計対象とした——原因と症状の時間的位置ずれ自体を箇所特定の失敗要因として定量化**: 従来の箇所特定研究は「どのサービス/メトリクスが原因か」という空間的な問いに集中してきたが、LagRCA は D1(46 インスタンス・本番銀行データ)の実インシデント分析で最大伝播ラグ Δt_max が 2 分以上の非同期伝播を示すインシデントが 81.5%を占めることを定量化し、「原因と症状の時間的整列」自体を箇所特定精度を左右する独立した設計変数として扱った。既存の同期集約前提の時空間 GNN(アブレーション c1: 静的呼び出しグラフのみ、c3: 標準 GCN)はいずれもフルモデルに劣り(D1 AC@1: 0.583/0.583 vs 0.667)、時刻整合性の欠如が箇所特定精度を直接下げることを実証した。(Source: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]]) - **カーネル領域では信号源そのものが分散システムと質的に異なり、単一の localizer 設計を転用できない**: KernelDiag([[@2026__arXiv__KernelDiag - Agent-Based Root Cause Diagnosis for Kernel Crashes]])は、マイクロサービスの「トレース・メトリクス・構造化ログ」に相当する信号がカーネルには存在せず、代わりに syscall・非構造化ログ・crash report という疎で低レベルなアーティファクトしか得られないことを指摘する。これは本ページの「信号源は、ドメインの構造に従って変わる」という知見をさらに一歩進め、ドメインが変わると信号源の抽象度そのものが数段階下がる場合があることを示す。詳細は [[カーネル障害診断]]。(Source: [[@2026__arXiv__KernelDiag - Agent-Based Root Cause Diagnosis for Kernel Crashes]]) - **[[バッチ障害診断]](Aloha, FSE Companion '26)は、単一障害の箇所特定とは異なる「集団としての異常パターン」を対象とし、実務適用の障壁が「アルゴリズムの欠如」ではなく「usability gap」にあることを指摘した**: 対照分析(contrast analysis)ベースの既存アルゴリズム [[CONAN]] は高精度な根本原因パターン抽出を提供する一方、シナリオ適用可能性の判定・データ品質の検証・目的関数/パラメータ選択という前後工程が手動である限りエンジニアの採用意欲が上がらない。Aloha はこれらを Fault Tree Analysis 由来の基準ベース判定・実行可能な検証ツールキット・RAG ベースの過去ケース検索という human-in-the-loop エージェントで補い、127 件のパイロットで CONAN に対し全 ACC@k で上回った(ACC@5: 0.9370 vs 0.6963)うえ、診断時間を約 10 時間から約 0.5 時間に短縮した。「精度の高いアルゴリズムを持つだけでは実務に採用されない」という知見は、他の箇所特定手法にも一般化しうる論点である。(Source: [[@2026__FSE Companion__Aloha - Localizing Batch Failures in Large-scale Cloud Systems via Contrast Analysis and Human-in-the-Loop Agent]]) - **共有 Mixture-of-Experts による「メトリクス非依存」設計は、Minder の「メトリクスごと個別モデル/決定木優先順位付け」問題を単一モデルで解く一つの答えを示す**: TSLoc([[@2026__KDD__TSLoc - Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters]]、KDD 2026)は、[[Minder]] の決定木ベースメトリクス優先順位付けを「closed-world 仮定に基づき未知障害・新規メトリクスへの day-one 対応ができない」と批判し、障害ラベルを一切使わない教師なし逸脱検知として障害箇所特定を再定式化した。健全ノードが同一コード・同一データ分割ロジックを実行するために生じる群コンセンサスからの逸脱を、共有 MoE 時系列エンコーダ(LSTM ゲーティング + KAN-AD エキスパート)で捉え、空間逸脱(ノード間距離)と時間的 volatility(埋め込みの時刻間変化)を Reciprocal Rank Aggregation で統合する。実験では Minder の VAE 成分を抽出した VAE/CVAE ベースラインが Acc@5=0.8776/0.8376 に対し TSLoc は 0.9082 を達成し、本ページの「粒度は component → metric → machine/rank へ細分化している」知見に「メトリクス横断で単一モデルが正常・逸脱を学習する」という設計軸を加えた。(Source: [[@2026__KDD__TSLoc - Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters]]) - **多様な役割(異種サブタスク)を持つノード群では、グローバルなコンセンサス比較そのものが偽陽性を生む**: TSLoc は強化学習(RL)タスクで軽量推論ノードと重い訓練更新ノードが混在する場合、リソース消費パターンの違いから正当な低負荷推論ノードを「異常」と誤判定する共通パターンを確認した(オンライン実験の失敗 4 件全てがこのパターン)。これは、コンセンサスベースの箇所特定手法が「全ノードが対称なワークロードを実行する」という暗黙の前提に依存しており、役割の異質性(role heterogeneity)を明示的にモデル化しない限り、非対称タスクへの適用限界があることを示す。(Source: [[@2026__KDD__TSLoc - Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters]] §5.6) - **「グラフ集約による平滑化が根本原因を覆い隠す」問題は、マイクロサービス・訓練クラスタに留まらず、都市交通網という全く異質なドメインでも同型で再現する**: TRACER([[@2026__KDD__TRACER - Physics-Guided Causal Evidence Construction for Zero-Shot Traffic Anomaly Diagnosis]])は、交通予測・異常検知に使われる ST-GNN/GWNet 等のグラフ畳み込みが低域通過フィルタとして働き、局所異常特徴を潜在空間で拡散させて根本原因と下流影響ノードのコントラストを減衰させる(fault smearing)ことを指摘する。これは本ページの「信号源はドメインの構造に従って変わる」知見を裏返し、逆に「メッセージパッシング型グラフモデルがもたらす平滑化アーティファクト」という失敗モードはドメインを問わず共通することを示す——マイクロサービス依存グラフでも道路網でも、近傍集約に頼るモデルは同じ理由で箇所特定精度を落とす。 - **統計的・トポロジカルな信号源だけでなく、ドメインの物理法則そのものを箇所特定の制約として使うアプローチが交通ドメインで有効性を示した**: TRACER は運動学的衝撃波理論(kinematic wave theory)による車両保存則を用いて因果探索の枝刈りを行い、統計的検証(Granger因果性検定)と組み合わせることで、物理的に不可能な逆方向伝播(下流の渋滞が上流の原因であるかのような推論)を排除する。マイクロサービス RCA ではこれに相当する「サービス呼び出し方向の保存則」や「プロトコル準拠制約」は暗黙的にしか使われておらず、明示的な物理/構造制約を枝刈りに組み込む発想は他ドメインの箇所特定手法にも転用しうる観点である。(Source: [[@2026__KDD__TRACER - Physics-Guided Causal Evidence Construction for Zero-Shot Traffic Anomaly Diagnosis]] §4.3、§5.5 Pruner アブレーション) - **L2/L3 ネットワーク層の箇所特定は、本ページが集約してきたマイクロサービス・GPU クラスタ・道路網とは異なる第四のドメインとして、症状の層別エスカレーションという固有の解法を持つ**: [[SADE]]([[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]、[[エージェント型ネットワーク障害診断]])は、故障ファミリスキルの指紋照合で「故障ラベル」と「故障デバイス」の両方を同時に特定する(Step 4: Fault Detection and Localization)。これは本ページの統計的・トポロジカルな信号源による箇所特定(TraceRank のスペクトル解析、DéjàVu の障害ユニット、TRACER の物理法則制約)とは異なり、**証拠を積み上げて故障ファミリを絞り込んでから、そのファミリ専用のプローブで対象デバイスを特定する**という二段階の設計を取る。クロススタック故障(`bgp_acl_block`: 到達性は健全だが特定プロトコルポートだけがフィルタされている)は、単一モダリティの信号(到達性のみ)では箇所特定できず、複数層(到達性・ルーティング状態・フィルタリングルール)を接続して初めて根本原因ノードに到達できるという点で、本ページの「複数モダリティ統合 localizer はどの障害クラスで単一モダリティを上回るか」という未解決の問いに対する具体的な肯定例を提供する。(Source: [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]) - **「集約先を中央から局所へ移す」という分散化の発想は、箇所特定の探索空間そのものを縮小する第五の粒度軸として機能する**: 本ページの既存知見は粒度を component → metric → machine/rank → network layer へ細分化する軸を扱ってきたが、[[@2026__TSC__A Decentralized Root Cause Localization Approach for Edge Computing Environments]] はこれとは直交する軸として「どこで計算するか(中央集中 vs 分散)」を扱う。エッジ環境では通信・コロケーションを考慮したクラスタリングでマイクロサービスをグループ化し、[[PageRank]] のパーソナライズド版(PPR)を各クラスタ内でローカルに実行することで、探索空間(グラフの辺数)そのものを縮小して局所化時間を最大 34% 削減しつつ精度を維持する。これは、削減対象を「見る信号の数」(MetricSifter の特徴量削減、AIOpsLab のコンテキスト圧迫)ではなく「1 回の PPR 実行が処理するグラフの大きさ」に置いた点で、本ページの「入力削減は古典統計手法と LLM エージェントの共通課題である」という知見に第三の削減対象を加える。(Source: [[@2026__TSC__A Decentralized Root Cause Localization Approach for Edge Computing Environments]]) - **中央集中型の遅さは「アルゴリズムの複雑さ」でなく「データ転送そのもの」に起因しうる——エッジという配置特性が箇所特定アーキテクチャの設計変数になる**: 従来の粒度細分化の議論(component→metric→machine→network layer)はいずれもクラウド内で完結する前提だったが、本論文はエッジ-クラウド協調環境において、テレメトリを中央(クラウド)へ集約する行為そのものが遅延の主要因になりうることを指摘する。唯一の先行エッジ研究 MicroCERCL も含め、既存 RCL 手法はすべて中央集中型であり、本論文はエッジデバイスレベルで RCL agent を直接実行することでこの制約を回避する初めての試みだと主張する。これは、箇所特定手法の設計において「どの信号を見るか」だけでなく「どこで処理を実行するか」がボトルネックの発生源になりうることを示す。(Source: [[@2026__TSC__A Decentralized Root Cause Localization Approach for Edge Computing Environments]]) - **クラスタ粒度の細分化は、局所化時間を削減する一方で Top-1 精度を下げるトレードオフを生む——本ページの「精度と効率は同一手法内でも綱引きになりうる」という論点に定量的な裏付けを加える**: MicroCERCL のコロケーション制約を緩めて最大 14 クラスタまで細分化する感度分析では、クラスタ数が増えるほど Top-1 精度が単調に低下する(3–5 クラスタで Acc@1≈0.56 → 12–14 クラスタで Acc@1≈0.49)一方、Acc@10 は全バケットで高水準を保つ。著者らはこれを「精度-粒度トレードオフ」として明示的に妥当性の脅威に位置づけており、MicroHECL のプルーニングや PDiagnose の投票ベース単純化(いずれも「効率化は精度を犠牲にしうる」と本ページが既に指摘)と同型のトレードオフが、分散アーキテクチャのクラスタ粒度という別の次元でも再現することを示す。(Source: [[@2026__TSC__A Decentralized Root Cause Localization Approach for Edge Computing Environments]]) - **GPU 訓練クラスタの箇所特定は「精密な機械学習ベース分類」ではなく「2 つの経験則による軽量な依存 DAG 構築」でも実運用に足りることを示す事例が加わった**: 本ページの「粒度は component → metric → machine/rank → network layer へ細分化している」知見は、Minder(machine-level 類似度)・Pulse(rank-level 監視)のような統計・機械学習ベース手法を中心に蓄積してきた。[[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]] の Fault Analyzer は、この粒度階層のさらに下(コレクティブ操作単位)で、(1) ジョブストール時は正常なコレクティブが全て完了しているはず、(2) 未開始コレクティブは同一ノード上の未完了コレクティブに依存する、という 2 つの経験則のみから inter-collective 依存 DAG を構築し outgoing 依存のないノードを culprit と判定する。統計モデルや学習を一切使わないにもかかわらず、4K GPU のモデルコードバグ・8K GPU の NIC 故障という 2 つの本番ケーススタディで根本原因コレクティブ・故障ホストの特定に成功しており、「箇所特定の精度は必ずしも手法の複雑さに比例しない」という、本ページが Baidu のメトリクススクリーニング(実務向け軽量パターン)で既に示した論点を GPU 訓練クラスタというドメインでも裏づける。(Source: [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - **Notaro ら(2021)が整理した2010年代の汎用箇所特定手法群は、データソース×対象コンポーネントのトレードオフをTable 7で明示的に可視化した最初期の体系的サーベイである**: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]] §4.4.1は、FChain[110](低レベルメトリクス→ハードウェア/データセンター、既存ブラックボックス手法比で適合率+90%・再現率+20%・オーバーヘッド1%)、Hotspot[132]/Squeeze[80](KPI→データセンター、手動数時間作業を平均20秒へ短縮・F1=0.86–0.90)、Sherlock[9](KPI+ネットワークトラフィック→ハードウェア/ネットワーク、350候補から16候補まで障害の87%超を絞り込み先行研究Shrink比+32%多く検知)という手法群を、Table 7で「汎用・教師なし/複雑な分析と空間枝刈りが必要」「教師なし・高精度・頑健/トポロジ情報とトラフィック情報が必要」という利点/欠点の対比として整理する。この整理は、本ページの「粒度は component → metric → machine/rank → network layer へ細分化している」知見が扱う2020年代のドメイン特化型手法(Minder/Pulse/R-Pingmesh等)より一世代前の、汎用アルゴリズム(離散マルコフモデル・モンテカルロ木探索・確率的推論グラフ)中心の設計を代表する。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]]) - **ソフトウェア障害箇所特定(SFL)は、本ページが蓄積してきた「サービス/ノード/リンクのどれが原因か」という粒度軸とは異なる、「どのコード行が原因か」という第六の粒度を加える**: Notaro ら §4.4.1が紹介するSFL手法群(Renieris et al.[121]のプログラムスペクトル類似度、Delta Debugging[156]とcause-transition[30]、SOBER[85]の述語統計解析、BARINEL[1]のベイジアン推論、DStar[145]の容疑度係数)はいずれもソースコードを直接の信号源とし、疑わしい文やコード領域を返す。SOBERはコード1%調査でバグの8.46%を捕捉(20%調査で73.85%)、BARINELはコードの10%未満の調査で障害の60%を発見するなど、報告値の単位が「調査すべきコード量の割合」という点で、本ページの他の全手法(A@K・HR@K・F1のような順位指標)と評価軸そのものが異なる。SFLは障害予測(SDP)と調査対象・分析ツールが類似するが、SFLは本番実行やテストケースから**観測された**障害パターンに依拠する点で、コードメトリクスに基づく**将来**障害の予測であるSDPとは異なる——この「予測 vs 観測に基づく事後分析」という区別は、本ページの他の箇所特定手法(いずれも障害発生後の事後箇所特定)がSDPとどう違うかを明確化する参照点にもなる。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]]) - **トポロジグラフ上でのランダムウォークは、[[因果推論ベースRCA]]が扱う統計的因果グラフを経ずに、サービス粒度で根本原因を絞り込む本ページ固有の経路として位置づけられる**: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.3 Monitoring-based Root Cause Analysis Techniques]] §4.3.2 が整理する MicroRCA・Wu et al. は、Kubernetes デプロイ状態から観測されたトポロジグラフ(サービス間相互作用・ホスティング関係をそのまま表す)上で MonitorRank 由来のランダムウォークを実行し、根本原因サービスを訪問回数で絞り込む。これは PC アルゴリズム等で統計的に推定した因果グラフを経由する CloudRanger・MicroCause 等(§因果推論ベースRCA が集約)と対をなす設計であり、「観測されたトポロジをそのまま使う」か「KPI 間の因果依存を推定してから使う」かという、本ページの「信号源はドメインの構造に従って変わる」知見をグラフ構築方法という軸で補完する。Sieve・Brandón et al. はさらにネットワークシステムコール監視からトポロジを自動再構築し、Granger 因果性検定によるペアワイズ比較(Sieve)や既知の異常グラフパターンとの類似度照合(Brandón et al.)でサービス粒度の候補を絞る点で、統計的因果グラフの全体構築を経ずに部分的な因果情報だけをトポロジグラフに足す中間的設計を示す。DLA は運用者提供トポロジを Hierarchical Hidden Markov Model へ変換し Baum-Welch/Viterbi で最尤経路を求める点で、ランダムウォーク系ともスコア伝播系(グラフベースRCA)とも異なる確率モデルベースの絞り込みを提供する。(Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.3 Monitoring-based Root Cause Analysis Techniques]]) - **データモダリティは信号源だけでなく、粒度の細かさそのものの上限を決める——メトリクスは間接的な値の変化しか反映できないため、ログ・トレースより粗い粒度に留まりやすい**: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]] §5.2 は、コンポーネントレベルにおいてメトリクスが変数値を通じて状態を**間接的**に反映するのに対し、ログはプログラムに埋め込まれたログ文が実行時状態・エラーを**明示的**に記録し、トレースはサービス間相互作用に加えてAPI・リクエスト固有の操作・メソッドまで記録するため、より細粒度な診断のデータ根拠になると整理する。これは本ページの「粒度は component → metric → machine/rank → network layer へ細分化している」知見に、**どのモダリティを使うかが到達可能な粒度の上限を規定する**という別の軸を加える——machine/rank・network layer への細分化(Minder・Pulse・R-Pingmesh)がいずれもメトリクス/カウンタ系の信号に依拠するのに対し、DéjàVu・FL-AIer・Nezha のような component 粒度より細かい「障害ユニット」「イベント」設計がログ・トレース系の信号に依拠するのは偶然ではなく、モダリティの表現力そのものに起因すると読める。同時に本章 §5.2 は、TrinityRCL・NetMedic のように因果関係グラフを構築してから根本原因ノードを探索する手法群では、モダリティに関わらずグラフ構築時に設定するノード種別(サービス・インスタンス・メトリクス・コード等)を変えるだけで粒度を柔軟に切り替えられるとも指摘しており、「モダリティが粒度の上限を決める」経路と「グラフ設計が任意の粒度を選べる」経路の 2 つが並立する。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]] §5.2) - **ログ・トレース・メトリクスという3系統のデータ源分類は、探索空間削減という共通課題に異なる枝刈り戦略で対応する**: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization]](Xin+, ACM Comput. Surv. 2025)は、根本原因箇所特定の研究をログベース(Adtributor・iDice・Squeeze・PSqueeze・SwissLogのように多次元属性の組み合わせ空間を削減)、トレースベース(MEPFL・TraceAnomaly・TraceRCA・TraceRankのようにサービス呼び出しグラフから疑わしいサービスを絞る)、メトリクスベース(統計的相関分析・トポロジグラフ分析・PC/LiNGAMによる因果推論+BFS/ランダムウォークによる推論)の3系統に整理する。効率性の信頼性要件についても、この3系統いずれもが「推論すべきトレース数の削減」(TraceRCA)・「階層抽出による探索空間削減」(Zhang et al.)・「異常サービス呼び出しエッジの枝刈り」(Liu et al.)という、探索空間そのものを縮小する設計に収束すると総括する(§3.4.2)。これは本ページの「信号源は、ドメインの構造に従って変わる」(既存知見)と「入力削減は古典統計手法とLLMエージェントの共通課題である」(既存知見、MetricSifter・AIOpsLab)の両方に、統計的因果推論ベースRCLという第三の事例群を追加する——PC・LiNGAMが因果構造学習の標準手法として収束している点は、本ページのMinder/TSLoc(訓練クラスタ)・R-Pingmesh/Hawkeye(RDMA)のドメイン特化型手法とは異なる、汎用グラフベースRCLの標準設計として並置できる。ただし本サーベイは、メトリクスベース手法の大半が粗粒度(サービスレベル)の局所化にとどまり、サービス+メトリクスの細粒度局所化は発展途上であるとも明記しており、本ページの「粒度は component → metric → machine/rank → network layer へ細分化している」知見のうち、metricレベルへの細分化はまだ発展途上の領域として位置づく。(Source: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization]] §3.4.1, §3.4.2) - **因果推論ベースの箇所特定は「モデル出力に説明を後付けする」のではなく「構造自体が解釈可能」という設計を取り、これは本ページのFL-AIer(決定木代理モデルで診断経路を提示)とは異なる説明可能性の達成経路である——ただし同じ因果推論ベース箇所特定の中でロバスト性研究は明示的な空白として指摘される**: 前掲サーベイ§3.4.2は「根本原因箇所特定は検知手法の説明とみなせ、特に因果推論に基づく箇所特定は本質的に解釈可能で理解しやすい」と述べる。FL-AIerがブラックボックスなGATの出力に対し決定木を後付けで訓練して診断経路を提示する(本ページ既出)のに対し、CIRCA・RCD・CloudRangerのような因果グラフベース手法は、推論結果そのものが因果グラフのエッジ・パスとして表現されるため、後付けの代理モデルを必要としない。ただし同サーベイはロバスト性についても、ログデータにおけるripple effect(Squeeze・PSqueeze)の活用を挙げる一方、「メトリクスにおける因果推論・グラフベース箇所特定のロバスト性研究は限定的である」と明示的に空白を指摘しており(§3.4.2)、構造的解釈可能性の恩恵とロバスト性研究の不足が同じ因果推論ベース箇所特定の中で並存する非対称性がある。(Source: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization]] §3.4.2) - **MagmaScope は変更チケットを「第ゼロのテレメトリ」として箇所特定パイプラインに組み込み、IM チャットを「第 4 のテレメトリ」として粗粒度フィルタリング後の細粒度分析に使う——変更記録の意味的正規化が箇所特定精度の律速になることを実証した**: [[MagmaScope]]([[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]])は、ログ/メトリクス/トレースではなく変更チケットと IM グループチャットを主信号とする箇所特定設計を採用した。粗粒度ランキングでは時間近接性スコア・変更依存グラフスコア・アラーム相関スコア・語彙的類似スコアの 4 種の軽量スコアを組み合わせて候補集合を圧縮し、細粒度ランキングで LLM エージェント(ReAct)が絞り込まれた候補とチャット情報を突き合わせて意味的に関連付ける。この「安価な候補圧縮 → 高コスト文脈推論」パターンは本ページが整理してきた MetricSifter の特徴量削減や AIOpsLab のコンテキスト圧迫回避と同型だが、前処理対象が「メトリクスの次元」でも「トレース数」でもなく「変更チケットの記述の意味」にある点が新しい。Change Object Rewrite([[Change Object Rewrite]])は変更チケットの断片的な記述を LLM で標準化することで、語彙的・意味的に不整合な変更記録を有効な相関可能形式に変換する。(Source: [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]] §3.2-§3.4, Tables 1-2) - 2004年のSteinder & Sethiによるサーベイは、障害箇所特定を専門家システム・モデル走査・グラフ理論・codebookの4パラダイムに分類し、multi-layer診断・時間相関・分散診断・サービス指向環境・モバイル網・モデル獲得を未解決課題として提起していた(→[[障害箇所特定パラダイム分類]]、[[確率的障害伝播モデル]])。(Source: [[A survey of fault localization techniques in computer networks]]) ## 未解決の問い - **サンプリング粒度が粗いメトリクス(60秒間隔等)では、障害が他ノードへ伝播しきった後の時系列からは根本原因ノードを判別できない場合がある**: TSLoc は Memory Usage(60秒間隔)の OOM 障害で、障害伝播後に全ノードのメモリ使用量が同時に低下し、ノード間差異がほぼ消失する事例を報告した。適応的サンプリングや複数粒度の融合で、この種の「伝播後の対称化」を検出前に捉える方法は未解決である。(Source: [[@2026__KDD__TSLoc - Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters]] §7) - **並列化・グルーピング情報(TP/DP/PP セット、役割別サブグループ)を箇所特定モデルに明示的に組み込む設計は、コンセンサスベース手法にどこまで一般化できるか**: TSLoc は今後の課題として、細粒度の並列化・ノードグルーピング情報を取り入れたサブグループ内比較を挙げているが、具体的なアーキテクチャは示していない。DéjàVu の[[障害依存グラフ]]や LagRCA の時空間 GNN のような構造化アプローチとの統合可能性は未検証。(Source: [[@2026__KDD__TSLoc - Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters]] §7) - **LagRCA の上流調整(β パラメータ)と DéjàVu/FL-AIer の不均衡対処は「下流被害者の過大評価」という共通課題への異なる解答であり、統合の可能性は未検証**: FL-AIer は障害クラス不均衡を損失関数(FKB)で補正するのに対し、LagRCA は推論時に上流由来の異常スコアを因果的に差し引く(s=ReLU(r−β·p))。両者は「見かけ上目立つが根本原因でない箇所を抑制する」という同じ目標を異なる段階(訓練時 vs 推論時)で達成しており、組み合わせた場合の効果は未検証。(Source: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]], [[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]]) - Top-K 型の箇所特定成功と、説明の妥当性、調査過程の健全性、緩和への有用性をどのように接続して評価すべきか。 - メトリクス、ログ、トレース、ネットワーク経路、GPU/集合通信カウンタを統合する localizer は、どの障害クラスで単一モダリティを上回るか。 - 監視粒度を下げたとき、どの粒度の障害まで検出・箇所特定可能か。サンプリング率、トレース欠落、メトリクス集約が精度に与える影響を体系化できるか。 - 正確な箇所特定と迅速な隔離のトレードオフは、MTTR、偽陽性隔離コスト、再発防止のどの条件で切り替えるべきか。 - LLM エージェントに統計的な特徴量削減結果を前処理として与えると、探索効率と説明品質は上がるか。 - 前処理(特徴量削減)の評価指標と本体タスク(箇所特定)の評価指標の乖離(BA→AVG@5 の $R^2$ が 13.9–51.0%)は、他の前処理段(ログのノイズ除去、トレースのサンプリング等)でも同程度に起きているか。前処理の評価指標だけでパイプライン全体の改善を主張することの妥当性はどう検証すべきか。([[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]] Tab. 5.4) - SREcon18 の top 1 = 60/70 と FluxRank 論文の top 1 = 55/70 は、評価対象・ラベル定義・ダイジェスト定義のどれが異なるのか。スライドと論文の評価差を追うことで、研究発表へ進む過程で何が厳密化されたかを確認できる。 - DéjàVu の「障害ユニット」概念は、GAT を活用する他の AIOps システムにも適用できるか。サービスメッシュの KPI ではなくデプロイ関係と組み合わせた FDG 自動構築のコスト対効果はどれくらいか。 - FL-AIer の未知障害種別への対応(同種の別場所への転移でなく、全く新しい種別)は開放課題である。未知障害と履歴障害の類似度計算をどのように設計すれば対処できるか。 - FL-AIer は訓練データの 80% でほぼ最良性能を達成するが、訓練データが 10〜30% 台では急激に性能が劣化する。初期の少数ショット期間に産業導入する際の実際的な最低障害収集数はどこか。 - SLIM は新規デプロイサービスで 2 件の訓練事例から正確な箇所特定が可能だが、1 件での対応はゼロショット学習の問題として再定式化できるか。LLM に障害の意味を事前学習させて 1 件でも汎化できるか。 - DNF ルールの「IF (cpu_usage>80 AND file_disk_read>180) OR ...」形式は解釈可能だが、障害種別ごとに個別モデルを訓練するため種別数が多い場合にスケールするか（Dataset D では種別 5、最大種別数はどのくらいまで対応可能か）。 - **マイクロサービス依存グラフの伝播方向制約(サービス呼び出し方向、リクエストの因果的順序)を、TRACER のような明示的な流れ保存則の枝刈りとして定式化し、既存の統計的因果発見(PCアルゴリズム等)に組み込むとスプリアス相関の抑制と探索コスト削減の双方に効果があるか**: TRACER は道路網という物理的な流れ保存則が明示的に存在するドメインで有効性を示したが、マイクロサービスでも「呼び出し元→呼び出し先」という一方向の依存構造は存在する。これを局所的なペアワイズ枝刈り制約として使う設計は、[[因果推論ベースRCA]] の既存手法(CausalRCA・MicroCausal 等の PC アルゴリズム系)ではまだ明示的に定式化されていない。(Source: [[@2026__KDD__TRACER - Physics-Guided Causal Evidence Construction for Zero-Shot Traffic Anomaly Diagnosis]] §5.6 Global PC 実験) - SADE のような「故障ファミリスキルによる二段階(ファミリ絞り込み→デバイス特定)箇所特定」は、マイクロサービス RCA の統計的・因果推論ベース手法(DéjàVu・LagRCA 等)とアーキテクチャレベルでどこまで統合可能か。ネットワーク層のスキルライブラリ設計をマイクロサービス層の障害クラス分類に転用する、あるいはその逆は成立するか。 - **分散箇所特定のクラスタ粒度は、どの指標(通信頻度・コロケーション以外)を考慮すれば精度-効率トレードオフを緩和できるか**: [[@2026__TSC__A Decentralized Root Cause Localization Approach for Edge Computing Environments]] のクラスタリングは通信頻度とコロケーションのみを考慮するが、異常伝播パターンの履歴やメトリクス相関構造を加味した動的クラスタリングは精度低下を抑えられるか未検証。 - **Fault Analyzer の 2 つの経験則(仮定 1: ストール時は正常コレクティブが全完了、仮定 2: 未開始コレクティブは同一ノードの未完了コレクティブに依存)はどの程度一般化可能か**: 著者ら自身が仮定 2 を「経験的(empirical)」と認めているが、どのワークロード・並列化構成でこの仮定が破れるか(例えば計算と通信を融合した融合カーネルでは per-collective 境界が曖昧になり仮定が成立しにくくなる可能性がある)は定量化されていない。Minder のような統計的類似度ベース手法との精度比較(誤検知率・再現率)も本稿では行われていない。 - **DéjàVu/FL-AIer の「障害ユニット」的な学習ベース箇所特定と、分散 PPR のような教師なしグラフ中心性ベース箇所特定は、エッジ環境というリソース制約下でどちらが実運用上優位か**: 本論文は GNN 系(MicroCERCL の元手法)より軽量な PPR を選んだ理由として訓練不要・低リソースオーバーヘッドを挙げているが、DéjàVu/FL-AIer が示した再帰障害への高精度な適応(学習ベース)との定量比較は行われていない。エッジデバイスの計算資源制約下で両者の精度・レイテンシ・保守コストを横断比較する余地がある。 - **Table 7 が整理した2010年代の汎用箇所特定手法(FChain/Hotspot/Squeeze/Sherlock)は、DéjàVu以降のGNNベース手法と精度・汎用性をどう比較すべきか**: 前者の報告値は「既存手法比+90%の適合率」「候補集合を350から16へ絞り込み」のような相対改善や候補数削減で示されるのに対し、後者はA@K・HR@Kのような絶対順位指標で示される。評価指標の単位が異なるため、Notaro ら(2021)が整理した古典的汎用手法と2020年代のドメイン特化型学習手法を同一の物差しで比較した研究は本ページにまだ見当たらない。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]]) - **トポロジグラフ系(MicroRCA・Sieve・Brandón et al.・DLA)のサービス粒度絞り込みは、2020年代の GNN ベース手法(DéjàVu・FL-AIer)や本ページが集約する localizer 群と同一データセットで比較されたことがない**: Soldani & Brogi(2021)§4.3.2 が挙げるトポロジグラフ系手法は、いずれも各論文独自のマイクロサービスベンチマークで評価されており、本ページの他の知見が使う Train Ticket・Sock Shop・Online Boutique のような共通ベンチマーク上での性能は確認されていない。ランダムウォーク系(MicroRCA)・Granger 因果性ペアワイズ比較系(Sieve)・グラフパターン照合系(Brandón et al.)・HHMM 系(DLA)という 4 つの異なる絞り込み設計が、共通の評価軸(AC@K・Avg@K)でどう序列づくかは未検証。(Source: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.3 Monitoring-based Root Cause Analysis Techniques]]) - **モダリティが規定する粒度の上限(ログ/トレース>メトリクス)と、グラフ設計が選べる粒度の自由度(TrinityRCL・NetMedic)を同一システムで両立させた研究はあるか**: 本ページの新しい知見は「モダリティが到達可能な粒度の上限を決める」経路と「因果グラフのノード種別選択が任意の粒度を選べる」経路が並立すると整理したが、両者を組み合わせて「メトリクスしか無い環境でもグラフ設計の工夫で疑似的に細粒度を得る」ことが可能かは、本サーベイ本文でも本ページの他の知見でも検証されていない。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]] §5.2) - **メトリクスにおける因果推論・グラフベース箇所特定のロバスト性を、ログベース手法のripple effect(Squeeze・PSqueeze)に相当する水準まで高める設計はあるか**: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization]]は、この空白を明示的に指摘するのみで具体的な解決策は示さない。本ページが蓄積するCauseInfer・Microscope・CloudRanger・MS-Rank・AutoMAP・MicroCause・MicroDiagのようなPC/LiNGAMベースの因果グラフ手法が、ノイズや欠測に対してどの程度頑健かを定量評価した研究は本ページにまだ見当たらない。(Source: [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization]] §3.4.2) ## 関連 - 上位/隣接概念: [[AIOps]] / [[根本原因分析]] / [[異常検知]] / [[RCA評価設計]] / [[RCA入力選別]] / [[特徴量削減]] / [[不均衡障害分類]] / [[バッチ障害診断]] / [[カーネル障害診断]] / [[因果推論ベースRCA]] / [[エージェント型ネットワーク障害診断]] - サーベイ章: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]] — §4.4.1の古典的汎用箇所特定手法群とソフトウェア障害箇所特定(SFL) - サーベイ章: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]] — §5.2 データモダリティが規定する診断粒度の上限と、因果グラフ構築が与える粒度の自由度 - 入力別概念: [[分散トレーシング]] / [[ログ解析]] / [[マルチモーダル障害診断]] / [[テレメトリ]] - ドメイン別概念: [[LLM学習モニタリング]] / [[GPUクラスタ運用]] / [[RDMAネットワーク監視]] / [[耐障害LLM訓練]] - 関連 MOC: [[LLM for SREの障害原因診断論文の分類]] / [[異常検知 - MOC]] / [[Project AI4SRE - MOC]] - サーベイ章: [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.3 Monitoring-based Root Cause Analysis Techniques]] — §4.3.2 のトポロジグラフ系サービス粒度絞り込み(MicroRCA・Sieve・Brandón et al.・DLA) - 概念: [[障害箇所特定パラダイム分類]] / [[確率的障害伝播モデル]] ## 出典 - [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.4 Root-cause Analysis (RCA)]](§4.4.1 Fault Localization: FChain・Hotspot・Squeeze・Sherlock・ソフトウェア障害箇所特定(SFL)群のデータソース・対象・報告値、Table 7) - [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]](Fault Analyzer: CollTrace 計装と 2 つの経験則によるコレクティブ間依存 DAG 構築、4K GPU モデルコードバグ・8K GPU NIC 故障の 2 ケーススタディ) - [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]](§2.1 実証研究 Table 3 ILD-SLD 類似度差、§4 RCL 手法 cosine similarity ランキング、§5 Table 6 監視あり手法との比較) - [[@2002__DSN__Pinpoint - Problem Determination in Large, Dynamic Internet Services]](リクエストトレースと統計的コンポーネント特定) - [[@2016__ISSTA__Practitioners' Expectations on Automated Fault Localization]](実務者採用閾値、Top-5、判断根拠) - [[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]](非集計トレース、スペクトル解析、PageRank 補完) - [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing]](スパンツリー因果推論による障害箇所特定) - [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]](特徴量削減、root fault metrics、因果探索前処理) - [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]](Tab. 5.4 削減指標と箇所特定指標の $R^2$、§5.5.4 妥当性検証) - [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]](4-level taxonomy、localization 評価) - [[A Survey of AIOps in the Era of Large Language Models]](LLM 時代の failure localization 分類) - [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]](ログベース component localization と root cause summarization) - [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]](分散訓練クラスタの machine-level similarity) - [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]](sub-OP-level 監視と rank-level 箇所特定) - [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]](RoCE パス単位監視とリンク/スイッチ特定) - [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]](層間相関による起因層切り分け) - [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]](GPU 単位の細粒度修復対象切り分け) - [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]](PFC 来歴追跡と原因フロー/ホスト特定) - [[@2026__arXiv__Which Types of Heterogeneity Matter for Root Cause Localization in Microservice Systems]](異質性と root cause localization) - [[Anomaly detection and root-cause identification in microservices]](グラフベース RCI と手法比較) - [[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis]](サービス診断向け自動メトリクススクリーニング、70 件中 60 件 top 1、実行時間 6 分以下) - [[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]](DéjàVu: 障害ユニット × GAT で再帰障害を行動可能かつ解釈可能に箇所特定、MAR 1.66〜5.03) - [[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]](FL-AIer: 多層 GAT + マルチヘッドアテンション + FKB で DéjàVu を A@1 平均 +9.24%、DT 代理モデルで診断経路提示) - [[@2024__ASE__SLIM - A scalable and interpretable light-weight fault localization algorithm for imbalanced data in microservice]](SLIM: 劣モジュラ最適化によるルールセット学習で変更後サービスの不均衡障害データに対応、2 件の訓練事例で正確な箇所特定) - [[@2026__FSE Companion__Aloha - Localizing Batch Failures in Large-scale Cloud Systems via Contrast Analysis and Human-in-the-Loop Agent]](Aloha: 対照分析ベースのバッチ障害診断における usability gap の指摘と human-in-the-loop エージェントによる解消、CONAN 比較で ACC@5: 0.9370 vs 0.6963) - [[@2026__arXiv__KernelDiag - Agent-Based Root Cause Diagnosis for Kernel Crashes]](KernelDiag: Linux カーネルクラッシュ向けエージェントベース根本原因診断、KGYM で LinuxFL+/Agentless を Top@1 で 24〜35% 改善) - [[@2026__KDD__TRACER - Physics-Guided Causal Evidence Construction for Zero-Shot Traffic Anomaly Diagnosis]](TRACER: 都市交通網向け物理接地型ゼロショットRCAエージェント、GNN低域通過フィルタによる fault smearing の指摘、運動学的衝撃波理論による因果枝刈り、SUMO/PeMS-BAY で Hit@1 32.6%改善・推論時間85.7%削減) - [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]](SADE: L2/L3 ネットワーク層向け Cisco 方法論ベースの LLM エージェント、故障ファミリスキルの二段階箇所特定で NIKA ベンチマーク RCA F1 0.77) - [[@2026__TSC__A Decentralized Root Cause Localization Approach for Edge Computing Environments]](エッジ環境向け分散 RCL、通信・コロケーション考慮クラスタリング + Personalized PageRank で局所化時間を最大 34% 削減、クラスタ間 P2P 近似処理、MicroCERCL/iAnomaly での評価) - [[@2021__CSUR__Anomaly Detection and Failure Root Cause Analysis in (Micro)Service-Based Cloud Applications - A Survey - Chapter 4.3 Monitoring-based Root Cause Analysis Techniques]](§4.3.2 Topology Graph-based Analysis: MicroRCA・Wu et al. のランダムウォーク系、Sieve・Brandón et al. の Granger 因果性/グラフパターン照合系、DLA の HHMM 系) - [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 5 Discussion]](§5.2 粒度と説明可能性: モダリティ別の情報の明示性/間接性、TrinityRCL・NetMedic の柔軟な粒度設計) - [[@2025__ACMCSUR__Trustworthy AI-based Performance Diagnosis Systems for Cloud Applications - A Review - Chapter 3.4 Root Cause Localization]](§3.4.1 データ源別(ログ/トレース/メトリクス)手法分類、§3.4.2 信頼性要件: 頑健性=ripple effect、説明可能性=因果推論の本質的解釈可能性、効率性=探索空間の枝刈り。メトリクスにおける因果推論・グラフベース手法のロバスト性研究が限定的であることの明示的指摘) - [[@2026__ICSE-SEIP__MagmaScope Identifying Root-Cause Changes for Emergency Incident in Large-Scale Cloud Infrastructure]](§3.2-§3.4: 変更チケット検索・粗粒度 4 スコアフィルタ・細粒度 ReAct エージェント、Tables 1-2: 実験結果)