# マルチモーダル障害診断 ## 定義 マルチモーダル障害診断(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) ## 横断的知見 - **「等価融合」と「タスク指向融合」の分岐**: 先行マルチモーダル手法(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) - **周波数領域分析(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]]) ## 未解決の問い - モダリティ-タスクのマッピング(「トレース→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]]) ## 関連 - ソース: [[@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]] - 概念: [[根本原因分析]] / [[Fault Localization]] / [[異常検知]] / [[ログ解析]] / [[分散トレーシング]] / [[テレメトリ]] / [[障害注入]] / [[AIOps]] / [[特徴量削減]] - エンティティ: [[TVDiag]] / [[Shuaiyu Xie]] / [[Bing Li]] / [[TAMO]] / [[Xiao Zhang]] / [[Dongxiao Yu]] / [[Shandong University]] / [[SCELM]] / [[Yongqian Sun]] / [[Shenglin Zhang]] / [[CUJBench]] / [[Haoming Meng]] - 関連 MOC: [[LLM4SRE - MOC]] ## 出典 - [[@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) - [[@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 障害モード)