# マルチモーダル障害診断 ## 定義 マルチモーダル障害診断(Multimodal Failure Diagnosis)は、マイクロサービスベースのシステムにおいて、**ログ・メトリクス・トレースの 3 種類の監視データを統合**して障害の根本原因箇所特定(RCL: Root Cause Localization)と障害種別識別(FTI: Failure Type Identification)を行う取り組み。単一モダリティ手法では情報の偏りから特定の障害種別しか診断できないため、複数モダリティを組み合わせることで障害シナリオの網羅性を高める。([[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]]) ### 各モダリティの特性と診断タスクへの嗜好 | モダリティ | データ構造 | RCL への貢献 | FTI への貢献 | |---|---|---|---| | **トレース** | 木構造、呼び出し経路・レイテンシ・ステータスコード | 高(伝播経路が根本原因を指す) | 低(障害種別の詳細を含まない) | | **メトリクス** | 時系列数値 | 高(異常なリソース使用量が特定可能) | 中(ハードウェア系障害は確認できる) | | **ログ** | 半構造化テキスト | 低(因果関係を辿りにくい) | 高(ERROR ログが障害種別の手掛かりを含む) | ([[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]], §3.2・Figure 18) ## 横断的知見 - **TKG による「状態イベント化」という第四の統合設計路線**: TVDiag(タスク指向対照学習)・TAMO(拡散アライメント)・OpsAgent(テキスト化)に続く第四の設計として、[[@2024__TSC__No More Data Silos - Unified Microservice Failure Diagnosis With Temporal Knowledge Graph]] の [[UniDiag]] は時系列を「状態イベント(正常/過剰高/予期低)」に変換してから知識グラフのエッジとして格納する。数値をそのまま扱わず 3σ ルールで 3 値分類する「状態イベント化」は、OpsAgent のテキスト化(閾値ベースの言語記述)と方向性が近いが、グラフ構造に統合する点で異なる。TVDiag・TAMO が「モダリティ空間のアライメント」を中心に設計するのに対し、UniDiag は「モダリティをグラフの辺の種別に帰着させる正規化」を採用する——融合の統一表現として「ベクトル空間」(TVDiag/TAMO)か「グラフの辺種別」(UniDiag)かという設計選択の分岐が明確になった。(Source: [[@2024__TSC__No More Data Silos - Unified Microservice Failure Diagnosis With Temporal Knowledge Graph]], §V-B) - **障害検知と種別判定(Triage)を同時解く設計**: TVDiag・TAMO・SCELM がいずれも根本原因箇所特定(RCL)か障害種別分類(FTI)のどちらかに特化する傾向があるのに対し、UniDiag は「障害検知(Detection)+ 種別判定(Triage)」を単一フレームワークで統一する。GAIA ベンチマーク(D1)と E コマース模擬(D2)の 2 データセットで Weighted Average F1=0.869/0.723 を達成し、既存の単一モダリティ・マルチモーダル手法の全ベースラインを上回った。「検知と種別判定の統一」という問題定義の広さが、単一タスク特化手法との直接比較では評価軸の違いを生む点に注意が必要。(Source: [[@2024__TSC__No More Data Silos - Unified Microservice Failure Diagnosis With Temporal Knowledge Graph]], Table III, §III) - **「等価融合」と「タスク指向融合」の分岐**: 先行マルチモーダル手法(DiagFusion・Eadro)は各モダリティを等しく扱う融合(早期/中間融合)を採用してきた。[[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]] は「RCL ではトレース/メトリクス、FTI ではログが支配的」という先験的知識を教師あり対照学習(タスク指向損失)で定式化し、等価融合が各モダリティの強みを希釈することを定量的に示した(Dataset B での DiagFusion HR@1=0.205 対 トレース単独 HR@1=0.435)。タスク-モダリティ嗜好を明示的にモデル化するかどうかが、マルチモーダル診断の設計分岐点となる。 - **「ビュー不変情報」の存在と活用**: 同一障害を異なるモダリティから観測すると、共通の情報(異常インスタンス集合・障害度合い・システム状態)が各ビューに現れる。TVDiag はこれを「ビュー不変情報」と命名し、対照学習ベースのクロスモーダル関連付けで抽出する。ビュー不変情報の増幅がアブレーションで実証されており(CM 除去で HR@1・F1 の両指標が低下)、モダリティ横断の共有表現が診断に有意であることを示す。 - **RCL と FTI のインタータスク親和性**: TVDiag の実験で、RCL と FTI は互いの勾配更新が相手の損失を下げる補完関係(Table 8: $Z_{FTI \to RCL} = 8.77 \times 10^{-2}$ / $1.08 \times 10^{-1}$)を示した。単タスク学習でなくマルチタスク共学習が有効な理由の定量的根拠。[[根本原因分析]]と障害種別分類を同時解くことで共有知識(異常メトリクス・ログテンプレート・異常インスタンス集合)を相互活用できる。 - **「モダリティを選ぶ」という設計選択**: 単一モダリティ vs マルチモーダルの問いの前に「どのモダリティがどのタスクに効くか」を問う必要がある。[[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] はベンチマーク設計の観点でこれを示唆しているが、TVDiag は SHAP 値を使って各推論でモダリティ寄与を定量化し、オペレーターが後続分析のモダリティ優先度を判断できるようにする——「どの観測データを最初に見るべきか」という説明可能性のユースケース。 - **インスタンスレベル診断という設計選択**: TVDiag はサービスレベルでなくインスタンスレベルで根本原因を特定する。DiagFusion が「サービスレベルで特定してから最も異常なインスタンスを選ぶ」二段設計を取るのに対し、TVDiag はインスタンスを直接スコアリングする。Dataset B(各サービスに 3〜10 インスタンス)で DiagFusion が大きく負ける原因の一つがこの二段設計の崩れであり、インスタンスレベル直接スコアリングが複数レプリカ環境での RCL の標準設計として浮かび上がる。 - **グラフ拡張による観測不完全性への対処**: TVDiag の AUG は非根本原因インスタンスをランダムに無効化することで、(1) ラベル付きデータ不足を緩和、(2) ポッド停止/観測不能シナリオを模倣する。これは [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] が「既存ベンチの 99% は少なくとも 1 種の観測データを欠く」と指摘した観測完全性問題への学習フェーズでの応答。ただし AUG は「欠落があること」を学習させるが「どのモダリティが欠落するか」をモデルに伝えない——モダリティ全体の欠落はスコープ外。 - **拡散モデルによる「生成的アライメント」という第三の設計路線**: TVDiag(タスク指向融合)・HolisticRCA(マスク埋め込みアセンブリ)に続く第三の設計として、[[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]] の T1 は双分岐拡散モデルでログ・トレースを制御条件に、メトリクス時系列を多モーダル特徴付きの統合表現に生成的に変換する。特徴連結や投票と異なり、拡散による生成的アライメントは「意味ギャップをなくす」のではなく「ギャップを跨いだ整合表現を生成する」——TVDiag のタスク指向損失がモダリティ嗜好を学習方向から制御するのに対し、TAMO は生成過程そのものでアライメントを実現する。(Source: [[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]]) - **マルチモーダルアライメントがマルチモーダル RCA の律速**: TAMO のアブレーション(Table III)は T1(拡散アライメント)の削除が最大の性能低下を引き起こすことを示す(Acc@1 72.22%→43.75%、−28.47ポイント)。FFT 削除(−19ポイント)・時間分岐削除(−13ポイント)より大きい。「どのモダリティがどのタスクに効くか」(TVDiag のタスク指向融合が示す問い)より前に「モダリティを整合した共通表現に変換できるか」がボトルネックで、アライメント品質が後段の箇所特定・分類の上限を決める。(Source: [[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]]) - **TAMO と TVDiag の対比——「LLM を含む」か「LLM なしの純 DL」か**: TVDiag は GNN+タスク指向対照学習の純 DL フレームワーク(GPT 等 LLM を使わない)。TAMO は拡散+FFT+GAT の特化ツール群を LLM エキスパートエージェントが統合する設計。評価ベンチマークが一部重なる(両者とも HipsterShop・SocialNetwork の類似データを使用)が直接比較は行われていない。TVDiag は「どのモダリティがどのタスクに効くか」を SHAP で説明可能にし、TAMO は「LLM が自然言語の診断レポートと修復提案を生成する」説明可能性を持つ——説明の粒度と媒体(統計的寄与 vs 自然言語)が異なる。(Source: [[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]], [[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]]) - **変更ドメインのマルチモーダル診断は「変更票」という第 4 のモダリティを持つ**: TVDiag・TAMO がログ・メトリクス・トレースの 3 モダリティを扱うのに対し、[[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]] の SCELM は「変更票(change order)」を第 4 のモダリティとして統合する。変更票は変更 ID・対象サービス・設定情報・操作内容を含む構造化データで、異常の「いつ、どこで、何が変わったか」の起点となる。変更票を組み込むことで、障害がソフトウェア変更に起因するか否か(ECD)の判定が可能になり、RCCA で「どのコードや設定変更が根本原因か」まで特定できる。変更票なしのマルチモーダル診断は「何かが壊れた」と言えるが「何が変更で壊れたか」は言えない——変更管理ドメイン特有の要件。(Source: [[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]], §4.2.3) - **異常形状の自然言語化という設計——パターン分類を LLM 入力に変換**: SCELM は変化点検知後に異常形状を 11 種(Table I: sudden increase/decrease・level shift up/down・steady increase/decrease・single spike/dip・transient level shift・multiple spikes/dips・fluctuations)に分類し、自然言語記述に変換して LLM に渡す。これは TVDiag の「タスク-モダリティ嗜好」を学習するアプローチとは異なり、信号処理の出力(形状クラス)を意味記述にトランスコードして LLM のゼロショット推論能力を活用する設計。アブレーションで検知アルゴリズム除去(A2)より自然言語記述除去(A1)の方が大きく性能低下し、特に RCCA では A1 で Top5 が全空になる——LLM への入力は「値の変化」より「変化の意味」が重要。(Source: [[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]], §4.2.2, Table I, Table 4) - **ブラウザ可視層という第 4 の診断軸とクロスモーダル統合**: TVDiag・TAMO・SCELM はログ・メトリクス・トレース（＋変更票）の組み合わせを扱うが、いずれもバックエンドオブザーバビリティ内での統合にとどまる。[[CUJBench]] は「ブラウザ可視証拠（スクリーンショット・DOM・コンソール・ネットワーク要求）⇆ バックエンドテレメトリ」というより上位レイヤーのクロスモーダル推論を評価対象に加えた。6 モデル評価（A@1=19.7%、天井 52%）で、このクロスモーダル統合が現在の LLM エージェントにとって構造的に困難であることを示す。TVDiag のタスク-モダリティ嗜好研究と対比すると、「バックエンドモダリティ間の嗜好最適化」の先に「ブラウザ-バックエンド間の属性付け」という未解決の困難が存在することが見えてくる。(Source: [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]) - **アライメントではなく属性付けがボトルネック**: TVDiag・TAMO が示す「モダリティ間のアライメント（ビュー不変情報の抽出・拡散ベースの生成的アライメント）」が重要な先行課題である一方、[[CUJBench]] は別の困難を測定する。ER（証拠再現率 0.52〜0.65）が高い状態でも A@1（最高 44%）が低い——エージェントは証拠を見つけられるが「どのコンポーネントが根本原因か」に正しく帰属できない。この帰属ステップはモダリティのアライメントではなく、複数証拠を統合してコンポーネント-症状の因果連鎖を構築する高次の推論を要求する。モダリティアライメント研究（TVDiag・TAMO）とクロスモーダル帰属研究（CUJBench が計測）は異なる問題を解いている。(Source: [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]) - **変更後モニタリングでは「ビジネス KPI よりマシン KPI やログが先行シグナルを持つ」という時間軸の非対称性**: [[@2021__ESEC-FSE__Identifying Bad Software Changes via Multimodal Anomaly Detection]]([[SCWarn]])は、商業銀行の実データ分析で、ビジネス KPI のみを監視する既存手法が MTTD を数日〜数十日単位に長引かせる例を示した。Case II のメモリリーク案件では GC ログ/JVM メトリクスでの検知がビジネス KPI への影響の 5.6 時間前に発生。これはマルチモーダル診断の文脈で「どのモダリティが先行信号を持つか」というタイミング非対称性という新しい設計観点を提供する——TVDiag の「RCL vs FTI のタスク-モダリティ嗜好」とは直交する問いである。(Source: [[@2021__ESEC-FSE__Identifying Bad Software Changes via Multimodal Anomaly Detection]], §5.1 Case II) - **training-free なテキスト変換が MAS 協調のためのモダリティ統一を実現し、DL 融合の代替設計を示す**: TVDiag・TAMO・SCELM がいずれも DL モデルでモダリティをアライメントするのに対し、[[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] の OpsAgent は統計的/ヒューリスティック手法でモダリティを**テキスト記述に変換**し、全エージェントが共通利用できる言語的統一表現を生成する設計を採る(メトリクス: 3σ+CNN 形状分類、ログ: keyword+TF-IDF Drain3、トレース: 95 パーセンタイル+3 ホップコールパス)。アブレーションでプロセッサ除去時の Correct 16.54%→2.26% という劇的な差は、LLM が生の数値入力を苦手とすることを定量化する。DL アライメントが「モダリティ空間を揃える」のに対し、OpsAgent の training-free テキスト化は「LLM 入力空間に変換する」という方向性の差で、training-free 設計が cross-system 汎化(再学習不要)を実現する代償としてドメイン依存の閾値設定を要する。(Source: [[@2026__ASE__OpsAgent - An Evolving Multi-agent System for Incident Management in Microservices]] §3.2, Table 2) - **RAG を用いた変更管理マルチモーダル診断のコールドスタート特性**: SCELM([[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]])の実験は、RAG ベースのマルチモーダル診断が「タスクごとに異なるサンプル数で有効化される」コールドスタート特性を明らかにした。ECD(異常検知)は歴史経験ゼロでも合理的な性能を示し、FT(障害トリアージ)は 10〜20% で有意改善、RCCA(根本原因分析)は 70% 超でようやく頭打ちとなる。これはタスクの難易度が「データ分布の揺らぎ認識(ECD)→意味カテゴリ分類(FT)→原因特定(RCCA)」の順に高まり、必要な文脈蓄積量も同じ順序で増大することを示す。マルチモーダル診断の実用展開では「何件の歴史事例があればどのタスクが解けるか」を事前に設計に織り込む必要がある。(Source: [[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]] §5.3) - **周波数領域分析(FFT)がマルチモーダル時系列の異常検出に有効**: TAMO T2 の設計では、時間域の統合表現を FFT で周波数域に変換し高域フィルタで短期異常信号を増幅することが、マイクロサービスの動的依存グラフ上での根本原因特定に本質的な役割を果たす(FFT 削除で Acc@1 53.13% vs 保持 72.22%)。TVDiag がモダリティ-タスク嗜好の学習を重視するのと対照的に、TAMO は信号処理(周波数域分析)を前処理として組み込む——これは [[特徴量削減]] の [[MetricSifter]] が変化点検知で関連メトリクスを絞る方向と同じ「信号処理でノイズを減らしてから因果推論に渡す」骨格を持つ。(Source: [[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]]) - **AD・FT・RCL に共通する知識は「異常偏差(deviation)」であり、その2レベル表現(ILD・SLD)が教師なし統合の基盤になる**: [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]] の ART は、実証研究で(1)障害時の SLD L₁-ノルムが正常時より平均 22% 大きい(→AD への利用可)、(2)障害種別ごとに偏差が顕著なチャンネルが異なる(→FT への利用可)、(3)根本原因インスタンスの ILD と SLD のコサイン類似度が 0.714 (P83) で非根本原因の 0.487 (P46) より顕著に高い(→RCL への利用可)ことを定量化した。この「偏差の共有性」は TVDiag が示した「タスク-モダリティ嗜好(RCL→トレース・メトリクス、FTI→ログ)」と直交する視点で、モダリティごとの嗜好よりも「全モダリティ統合後の偏差パターン」を共通基盤とする設計が教師なしマルチタスク解を可能にする。(Source: [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]], §2.1, Table 1〜3) - **チャンネル依存→時間依存→呼び出し依存の順で依存関係をモデル化することが最良で、順序が逆転すると特に FT が大きく劣化する**: ART のアブレーション実験は 6 通りの依存関係順序を比較し、CHA(Transformer Encoder)→TEM(GRU)→CAL(GraphSAGE)の順が他の全順序を上回ることを示した。FT の D2 F1 は CHA-TEM-CAL 順で 0.802 だが TEM-CAL-CHA では 0.570 まで低下する(−29ポイント)。これはチャンネル粒度(CHA・TEM)と インスタンス粒度(CAL)を「細粒度→粗粒度」の順でモデル化することが深層表現の一般化に有利であるという理論的仮説と一致する。TVDiag が「融合タイミング」(早期/中間/後期)を問うのと対比すると、ART は「依存関係の抽出順序」という別軸の設計変数を開いた。(Source: [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]], §2.2, Table 7 B1〜B5) - **教師なし SSL で学習した「偏差ベース表現」が監視あり分類器を凌駕する**: ART は正常データのみで SSL 訓練し、ラベル不要の EVT 閾値(AD)・カットツリークラスタリング(FT)・コサイン類似度ランキング(RCL)で下流タスクを解く。結果として、監視ありの分類器に依存する Dejavu・DiagFusion・Eadro を FT・RCL の両指標で上回った。これは DiagFusion・UniDiag が「統一イベント表現空間への変換」を基軸にするのと異なり、「偏差の意味的解釈可能性(各次元が元のデータチャンネルに対応)」が監視なし後段タスクを可能にする設計的鍵であることを示す。ラベルが scarce な実運用環境でのマルチモーダル診断の重要な方向性として浮かぶ。(Source: [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]], §5.2, Table 5〜6) - **result fusion → model fusion → feature fusion の進化線が 98 論文サーベイで確認された**: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis]](Zhang+ 2024)は 98 論文を網羅し、マルチモーダル融合の歴史的進化を result fusion(早期・単純・保守コスト高)→ model fusion(因果グラフ/知識グラフにマルチモーダル特徴を格納)→ feature fusion(統一イベント表現・対照学習・自己教師あり学習)として整理する。PDiagnose が初の 3 モダリティ手法として位置づけられ、その後の DiagFusion・Nezha・DeepHunt・ART が feature fusion 手法に収束した系譜が可視化された。TVDiag のタスク指向融合・TAMO の拡散アライメントはこの feature fusion の特殊化として読める。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis]], §4.4, Table 6) - **RCL と FC の問題設定の分離が既存サーベイの共通欠落だった**: Zhang+ 2024 が 8 本の先行サーベイを比較した表1は、RCL と FC を明示的に分けて扱うサーベイが本論文以前に存在しなかったことを示す。この分離は TVDiag の「タスク-モダリティ嗜好」研究(RCL はトレース/メトリクス優先、FC はログ優先)の前提でもある。診断粒度(サービス 19 件・インスタンス 38 件・コンポーネント 44 件)の分布は、コンポーネントレベルが現実の最細粒度として主流になっていることを示す。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis]], Table 1, §3.3) - **「3 モダリティ全部入り」公開データセットとして RCAEval 2025 が標準化された一方、マルチソース化が因果推論ベースの一部手法で逆効果になる現象を定量化**: [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]] は RE2(270 ケース)・RE3(90 ケース)でメトリクス(77〜376 個)・ログ(1.7〜26.9M 行)・トレース(4.5〜76.7M スパン)を組にして公開し、PyRCA(メトリクスのみ・合成)、AIOps 2020(メトリクス + トレースのみ)の欠落を埋めた。Table 6 では multi-source 化された CIRCA・RCD が単独版より大きく劣化(CIRCA: AC@1 0.32→0.06、RCD: 0.09→0.10)し、TVDiag が示した「等価融合の希釈」現象を別ベンチで再現する。逆に BARO(仮説検定系)はメトリクス単独 0.67 → マルチソース 0.69 と維持、PDiagnose(元々マルチソース設計)は 0.48 と中庸——融合設計が「等価結合」か「明示的アライメント」かで結果が劇的に分かれる、という TVDiag/TAMO の知見を、公開ベンチで因果推論系手法に対しても確認した。(Source: [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]], [[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]]) - **「コードレベル障害」がマルチモーダル診断の新しい正解形式として導入された**: 既存のマルチモーダル診断(TVDiag・TAMO・SCELM)はサービス/インスタンスの根本原因特定までで止まり、コード行までは下りない。RCAEval 2025 の RE3 はコードレベル障害 F1〜F5(Incorrect parameter values 等)を 90 ケースで提供し、根本原因インジケータとして**ログのスタックトレース**や**トレースの response code**から fault line を遡及できる正解形式を初めて公開ベンチに組み込んだ(本論文 §3.2)。これは TVDiag の「インスタンスレベル直接スコアリング」のさらに先で、「コード行レベル粒度」をマルチモーダル統合で評価する潜在的軸を開く——ログ単独(メソッド名 + 例外型)とトレース単独(失敗 span + status code)では断片的だが、両者を統合すれば「どの呼出経路でどのメソッドが何の例外を投げたか」を再構成できる、という新しい評価軸。(Source: [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]) - **OS レベル障害診断はマイクロサービスと同じ 3 モダリティ(メトリクス・ログ・スタックトレース)を使うが、統合方式は「モデル融合」ではなく「検索クエリへの直列変換」を採る**: TVDiag・TAMO・UniDiag・ART が対照学習・拡散モデル・知識グラフ・SSL といった学習ベースの融合表現を構築するのに対し、[[OScope]]([[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]], ICSE-SEIP '26)はメトリクス(3σ ルール+トレンド)・ログ([[Drain]] テンプレート+クラスタリング+[[Isolation Forest]])・スタックトレース(リーフ関数頻度+キーワード)をそれぞれ独立に特徴抽出したうえで、Knowledge Aligner が単一の「特徴記述(feature description)」テキストへ要約し、これを検索クエリとして過去障害事例を引く。学習表現空間へのモダリティ融合ではなく、自然言語記述への直列変換によって統一表現を作る点は、[[OpsAgent]] の training-free テキスト化路線に近い設計選択である。マイクロサービスの「サービス間伝播」を伴わない OS 単体障害では、モダリティ間の融合よりも「症状記述の粒度・表現の統一」の方がボトルネックであることを示唆する。(Source: [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]]) ## 未解決の問い - OScope の「検索クエリへの直列変換」(OpsAgent のテキスト化路線に近い)と TVDiag/TAMO の学習ベース融合を、OS レベル障害・マイクロサービス障害の両方で直接比較する研究は未着手。学習表現の柔軟性とテキスト変換の解釈可能性・再学習不要性のどちらが実運用で優位か、ドメイン間で結論が変わるか。(Source: [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]]) - モダリティ-タスクのマッピング(「トレース→RCL、ログ→FTI」)は TVDiag が 4 データセットで確認したが、ドメインを超えて普遍的か。サービス間通信をトレースしない設計のシステム、またはログ品質が低いシステム(Dataset B でログ嗜好が崩れた)では TO の先験知識が誤りになる可能性がある。ログ品質に応じて TO のマッピングを自動調整する仕組みは設計できるか。 - TVDiag は障害種別を多クラス分類するが、既知の障害種別に限定される——未知障害種別(open-set)への対応は将来課題。TAMO も同様の限界を抱える。マルチモーダル障害診断を open-set 設定に拡張するにはどんな設計変更が必要か。 - [[ログ解析]] のサーベイ([[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]])が整理する LLM ベースのログ解析手法は、TVDiag のような GNN ベースのマルチモーダル診断フレームワークとどう統合できるか。LLM でログの意味的理解を深め(logKey 抽出を超えた文脈理解)、それを GNN の特徴として活用するアーキテクチャは成り立つか。 - 4 データセットはいずれも故意に注入した障害(Chaos Engineering)で評価している。本番環境の自然発生障害ではモダリティ間の相関構造が異なる可能性があり、ビュー不変情報の仮定が崩れるか未検証。 - TAMO の T1(拡散アライメント)は正常運転データで事前学習する必要がある。新規デプロイのシステムや希少障害シナリオでの cold-start 適用はどう対処するか。TVDiag のグラフ拡張(AUG)と比較して、データ不足へのロバスト性はどちらが優れるか。([[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]]) - SCELM は変更票+ログ+メトリクスのマルチモーダル統合で ECD・FT・RCCA を同時解決するが、TVDiag の「タスク-モダリティ嗜好」の観点で言えば RCCA に変更票が特に効き ECD/FT にメトリクスが効くはず——SCELM はこの嗜好を明示的に学習しておらず、自然言語化という統一変換に頼る。SCELM のタスク-モダリティ嗜好を TVDiag 型の対照学習で明示化すると性能は上がるか。(Source: [[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]]) - 生成的アライメント(TAMO の拡散モデル T1)とタスク指向融合(TVDiag の対照学習)を組み合わせることは有効か。拡散で時間整合表現を作ってから、TVDiag の SHAP ベースのタスク-モダリティ嗜好でさらに絞る 2 段設計は改善をもたらすか。([[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]], [[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]]) - [[CUJBench]] の ER>A@1 の「帰属ボトルネック」は、どのような設計（クロスモーダル事前学習・ツール選択の制限・CoT 強化・反事実推論）で改善できるか。TVDiag のタスク-モダリティ嗜好のアイデアをブラウザ-バックエンド軸に拡張すること（「ブラウザ証拠はコンポーネント帰属に強い」等の先験知識を組み込む）は有効か。(Source: [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]]) - RCAEval 2025 のマルチソース化失敗(CIRCA/RCD で AC@1 が逆に低下)は、TVDiag のタスク指向対照学習や TAMO の拡散アライメントを当てはめれば回復するか。公開ベンチで「因果推論ベース手法 × タスク指向融合」「因果推論ベース手法 × 拡散アライメント」の組み合わせを評価する研究は未着手。([[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]], [[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]]) - RCAEval RE3 のコードレベル障害 F1〜F5 を「行レベルマルチモーダル統合」で解く設計はどうなるか。ログのスタックトレース(faulty line を直接指す)とトレースのスパン(失敗 method を指す)を統合して fault line を当てるエージェントは、TAMO の拡散アライメントや TVDiag のタスク指向対照学習に近いか、それとも別の系譜が要るか。([[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]) - **ART の依存関係モデル化順序(CHA→TEM→CAL)は 2 データセットで検証されたに過ぎず、大規模・疎グラフ環境での汎用性は未確認**: サービス数 100 超や呼び出しグラフが疎なシステムでは CAL(GraphSAGE)の寄与が薄れ、別順序が最適になる可能性がある。依存関係順序の汎用性を問う研究は未着手。(Source: [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]]) - **ART の ILD/SLD 表現を FT のカットツリー以外の手法で転用できるか**: ART の FT はカットツリークラスタリングに依存し、cold-start(少数事例)では不安定な可能性がある。LLM のセマンティクスを活用したゼロショットクラスタリングに ILD/SLD を転用することで cold-start 問題を軽減できるか。(Source: [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]]) ## 関連 - ソース: [[@2024__TSC__No More Data Silos - Unified Microservice Failure Diagnosis With Temporal Knowledge Graph]] / [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis]] / [[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]] / [[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]] / [[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]] / [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]] / [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]] / [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]] - 概念: [[根本原因分析]] / [[Fault Localization]] / [[異常検知]] / [[ログ解析]] / [[分散トレーシング]] / [[テレメトリ]] / [[障害注入]] / [[AIOps]] / [[特徴量削減]] / [[時系列知識グラフ]] / [[TSG自動化]] - エンティティ: [[UniDiag]] / [[TVDiag]] / [[Shuaiyu Xie]] / [[Bing Li]] / [[TAMO]] / [[Xiao Zhang]] / [[Dongxiao Yu]] / [[Shandong University]] / [[SCELM]] / [[Yongqian Sun]] / [[Shenglin Zhang]] / [[CUJBench]] / [[Haoming Meng]] / [[ART]] / [[Binpeng Shi]] / [[Mingyu Mao]] / [[OScope]] - 関連 MOC: [[LLM4SRE - MOC]] ## 出典 - [[@2026__ICSE-SEIP__When LLMs Listen to Experts - Accurate Failure Diagnosis in Operating Systems]](§4.2.3 モダリティ別特徴抽出、§4.2.1 Knowledge Aligner による特徴記述への直列変換) - [[@2024__TSC__No More Data Silos - Unified Microservice Failure Diagnosis With Temporal Knowledge Graph]](§V TKG 構築・MOGE, §VI 実験, Table III 性能比較) - [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis]](§4.4 マルチモーダル融合分類, §5 考察, Table 6 手法一覧) - [[@2026__TOSEM__TVDiag - A Task-oriented and View-invariant Failure Diagnosis Framework for Microservice-based Systems with Multimodal Data]](§3 Motivation, §4 Approach, §5 Evaluation — 全体) - [[@2025__TSC__TAMO - Fine-Grained Root Cause Analysis via Tool-Assisted LLM Agent with Multi-Modality Observation Data in Cloud-Native Systems]](§III Methodology T1〜A, §IV Evaluation Table II〜IV, Figure 5〜7) - [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]](§2 実証研究 Table 1〜3, §3 提案手法 Figure 3, §4 アブレーション Table 7, §5 定量評価 Table 5〜6) - [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]](§I Gap, §II-A 問題定義, §III-D Table IV, §III-E 行動分析, §III-F 障害モード) - [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]](§3 RE2/RE3 の 3 モダリティ + コードレベル障害公開、§4-5 マルチソース版ベースライン評価、Table 6 マルチソース化で因果系の一部が逆効果)