@2026__ICWS__Reliable Orchestration of Specialized Multi-Agents for Cloud Incident Diagnosis

# Reliable Orchestration of Specialized Multi-Agents for Cloud Incident Diagnosis > [!abstract] 概要 > LLM(大規模言語モデル)ベースのマルチエージェントシステム(MAS)は、インシデント診断のような複雑なクラウド運用タスクに向けてますます採用が進んでいる。しかし、マルチモーダルなオブザーバビリティデータ上で複数の専門化されたエージェントを信頼性高く協調させることは依然として大きな課題である。本論文では、信頼性のあるクラウドインシデント診断のための4つのオーケストレーション設計パターンとマルチエージェントフレームワークを提案する。大手商用クラウド事業者における調査を通じて、我々は3つの主要な信頼性課題を特定した: 不確実性下でのクロスエージェント協調、LLM生成診断ツールの品質保証、オーケストレーションの柔軟性と運用効率のバランスである。これらの課題に対処するため、我々は4つのオーケストレーション設計パターンを提示する: (1) モダリティ特化を伴うコントローラ・エクスプローラオーケストレーション、(2) クロスエージェント協調のためのデュアルメモリアーキテクチャ、(3) 品質保証されたツールライフサイクル管理、(4) 適応的なプラン改訂を伴う段階的診断。335件の実インシデントからなる公開ベンチマークでの評価は、我々のマルチエージェントオーケストレーションがスコア率0.80を達成し、既存手法を2.04〜4.75倍上回ることを示す。品質管理されたツール管理はtop-1精度に22〜28%の追加的な改善をもたらす。 ## 論文情報 - タイトル: Reliable Orchestration of Specialized Multi-Agents for Cloud Incident Diagnosis - 著者: Haiyu Huang(The Chinese University of Hong Kong)、Jiewei Lyu(Sun Yat-sen University)、Shuting Lai(Sun Yat-sen University)、Zhihan Jiang(The Chinese University of Hong Kong)、Pengfei Chen(Sun Yat-sen University)、Michael R. Lyu(The Chinese University of Hong Kong) - 媒体: 2026 IEEE International Conference on Web Services(ICWS 2026)、全11ページ。DOI: 10.1109/ICWS72778.2026.00187 - 原本: `.raw/papers/Reliable-Orchestration-of-Specialized-Multi-Agents-for-Cloud-Incident-Diagnosis.pdf`(IEEE Xplore ダウンロード版のローカル PDF) ## 概要クラウドインシデント診断は、メトリクス・ログ・トレースという3つの相補的なオブザーバビリティモダリティを横断分析する必要があるが、単一のLLMエージェントに生データを直接与えると精度がわずか4.67%にとどまる(OpenRCAベンチマーク実測)。本論文は、大手商用クラウド事業者(Company A)での構築・運用経験から抽出した3つの信頼性課題(クロスエージェント協調の脆弱性、ツールの信頼性不足、柔軟性と効率のトレードオフ)に対応する4つのオーケストレーション設計パターンを提案し、これらを統合したマルチエージェントフレームワークをOpenRCAベンチマークと実運用の両方で評価する。 ## 問題設定 - **背景**: クラウドインシデントの根本原因特定(root cause analysis, RCA)には、メトリクス(時系列の挙動)・ログ(細粒度のイベント記述)・トレース(分散リクエストの因果トポロジー)という3つの相補的なモダリティの統合分析が必要である(図1)。単一エージェントに全モダリティを扱わせると、モダリティごとの分析が表層的になる問題が生じる。 ![[fig01-observability-modalities.png]] - **Company Aでの3つの信頼性課題**(2地域・40件の実インシデントに基づく観察、2025年1〜4月): 1. **課題1: マルチモーダルなオブザーバビリティデータには専門化された分析が必要**。40件の実インシデントで、単一のハイブリッドエージェント(3エージェント分のプロンプトを連結)と3つのモダリティ特化エクスプローラを持つマルチエージェント構成を比較した結果(AutoGenフレームワーク上、Claude 3.7 Sonnetをバックボーンに使用)、マルチエージェント構成はC@1で67.5%高い精度(27.5% 対 16.4%)、平均品質で3.6/5 対 2.3/5 を達成した。単一エージェントはモダリティ横断で表層的な分析に留まりがちだった。 2. **課題2: LLM生成の診断ツールには品質保証が必要**。テラバイト〜ペタバイト規模の本番オブザーバビリティデータを直接LLMプロンプトへ入れることは不可能であるため、LLMに実行可能な診断コードを生成させる実用的なパラダイムが必要になる。しかし14件の代表的な診断サブタスクで検証したところ、初期生成ツールのタスク完了率は30%未満にとどまり、SREフィードバックに基づく反復精緻化により3ラウンドで60.2%、6ラウンドで80.9%まで改善した(2.7倍の改善、図2)。さらに、対象システムの変化(例: データベーススキーマ変更)により既存ツールが一夜にして陳腐化する事例も観測された。 3. **課題3: 柔軟性と効率のバランス**。業界標準の「1-5-10」基準(1分で検知・5分で局所化・10分で復旧)は、探索的な調査に十分な時間的余裕を残さない。コールドスタート状態でのツール生成は平均260秒/ツールを要し、複雑なインシデントでは3〜4個のツール生成が必要となり、診断全体が15分を超える場合があった。 ![[fig02-tool-refinement-rounds.png]] ## 提案手法上記3課題に対応する4つのオーケストレーション設計パターンを、Planning(計画)・Investigation(調査)・Reasoning(推論)の3段階からなる統合フレームワークとして提示する(図3)。 ![[fig03-architecture-overview.png]] - **パターン1: コントローラ・エクスプローラオーケストレーション**。コントローラエージェントが調査計画を保持しオーケストレーションハブとして機能する一方、モダリティ(トレース・ログ・メトリクス)ごとに1体ずつインスタンス化されたエクスプローラエージェントが個別のサブタスクを実行する。コントローラは蓄積された証拠集合 ε に基づき、continue(サブタスク続行)・conclude(2モダリティ以上の証拠が収束した時点で推論器へ引き渡す)・escalate(繰り返しの失敗に応じてリプランを要求)の3アクションから選択するループを回す。「何を調べるか(コントローラ)」と「どう調べるか(エクスプローラ)」を明確に分離することで、各エージェントの認知的スコープを縮小し、診断の軌跡を完全に追跡可能にする。 - **パターン2: デュアルメモリアーキテクチャ**(図4)。長期記憶(LTM)は各エクスプローラが専有する永続メモリで、完了した調査アクション(タスク記述・使用ツール・結果)をテキスト埋め込みしベクトルインデックスへ格納し、新規サブタスク到着時に最類似の過去アクションを最近傍検索で提示する。LTMは空の状態から開始し、事前の既存インシデントレポートを必要としない。短期記憶(STM)は単一の診断セッションに限定された一時的な共有ワークスペースで、あるエクスプローラがサブタスクを完了するたびに簡潔な要約結果をブロードキャストキューへ追加する。中間の精緻化過程は共有せず最終結論のみを公開することで共有コンテキストを軽量に保つ。全エクスプローラの出力はモダリティ・観測時刻・影響コンポーネントID・自由記述の所見からなる標準化4フィールド形式に統一され、コントローラと推論器が異種ソースの証拠を曖昧さなく集約できるようにする。 ![[fig04-dual-memory-architecture.png]] - **パターン3: 品質保証されたツールライフサイクル管理**(図5)。2段階ツール生成では、推論指向LLMがサブタスクをLTM/STMの文脈で分解し入出力契約を規定したうえで、コード指向LLMがそれを実行可能なコードへ変換する(戦略と実装の分離)。フィードバック駆動の精緻化では、サンドボックス化されたDocker環境(ネットワーク分離、CPU/メモリクォータ、実行タイムアウト付き)でツールを実行し、ランタイムフィードバック(実行エラー・例外・出力形式違反)とヒューリスティック品質フィードバック(推論LLMが定式化するタスク固有の健全性チェック)の2種類の信号で反復精緻化する(最大MGラウンド、既定MG=3)。それでも失敗する場合は分析レベルの再試行(最大MAラウンド、既定MA=2)へエスカレーションする。永続的なツールスコアリングでは、スペクトルベース障害箇所特定([21])から着想を得た信頼性スコア式 $\mathrm{Qual}(t) = \frac{(n_t^{+})^2}{n_t^{+} + \bar{n}_t^{+}}$ により、ツール t の成功・失敗履歴からツールの品質を定量化する。ツールグラフは、過去の成功診断から観測された「Aの次にB」という呼び出しペアを有向グラフとして保持し、構造的な事前知識として活用する。マルチファクタのツール選択は、(1) タスク記述と保存済みツール記述の関連度計算、(2) 最小関連度閾値未満の除外、(3) 品質スコアによるランキング(上位5件保持)、(4) ツールグラフの後続候補追加、の4段階からなり、適合するツールがない場合のみ新規生成をトリガーする。 ![[fig05-tool-lifecycle.png]] - **パターン4: 適応的リプランニングを伴う段階的診断**。Planning(インシデント記述と利用可能データソースから、モダリティ別サブゴールの順序付き調査計画を粗粒度で生成)→Investigation(少なくとも2モダリティからの証拠収束を終了条件とし、単一モダリティの最初の説得力ある説明で早期終了すると40インシデントの実験で誤診率35%に達した)→Reasoning(思考の連鎖(chain-of-thought)による構造化レポート生成)の3段階を回す。エクスプローラが繰り返し失敗した場合(既定の精緻化ラウンド後もツールがデータを処理できない等)、retry→ツール精緻化→分析精緻化→リプランという段階的エスカレーションでコントローラがプランナーへ計画改訂を要求する。本番運用ではリプランは約8%のケースで発生し、主に初期計画が十分にカバーしていない特異な障害タイプに対して起きる。 ## 新規性 - 先行研究(mABC[33]のブロックチェーン式合意、Flow-of-action[8]のSOP誘導実行、LasRCA[34]のLLM+軽量分類器)がそれぞれ個別の協調機構を提案するのに対し、本論文は設計空間を4つの再利用可能なオーケストレーションパターンへ蒸留し、公開ベンチマークと産業実運用の両方で信頼性特性を評価した点が新規性として主張されている。 - ツールの品質を過去の成功・失敗実行結果からスペクトルベース障害箇所特定の式を転用して定量化し、ツール間の呼び出し順序をグラフとして構造的に活用する「ツールライフサイクル管理」は、単なるツール再利用(TaskWeaver等)を超えて、ツール選択自体に品質保証のフィードバックループを組み込む設計である。 - 実運用データにより、ハイブリッドなモデル配置(ローカルモデルがデータ接触型エクスプローラタスクを担当し、外部モデルが推論を担当)で7Bのローカルモデル(Qwen2.5-7B-Instruct)がネットワーク障害データセット(259件)で外部大規模モデルと同等レイテンシで80%精度を達成できることを示し、機微なテレメトリのプライバシー懸念を緩和できることを実証した。 ## 実験設定 - **ベンチマーク**: OpenRCA([10], [23])。Telecom(10サービス)・Bank(32サービス)・Market(72サービス)の3マイクロサービスシステムにまたがる335件の実インシデント。各インシデントには30分間のマルチモーダルオブザーバビリティデータウィンドウが付随し、正解は時刻・コンポーネント・原因の最大3要素からなる。難易度はEasy/Mid/Hardの3段階でラベル付けされている。 - **メトリクス**: C@k(top-k正解率、全正解要素がtop-k予測に含まれる割合)、P@k(top-k部分正解率、少なくとも1要素が一致する割合)、Sr(スコア率、獲得スコアと最大可能スコアの比)。 - **ベースライン**: LLMベースのRCA-agent([10]、ツール拡張単一エージェント)、非LLMのMicroRCA[24]・MicroScope[25]・MicroRank[26]・TraceAnomaly[27]・Nezha[2]。自フレームワークのアブレーション(w/o MAS: マルチエージェントを単一ハイブリッドエージェントに置換、w/o Refine: ツール精緻化を無効化、w/o Persist: ツール永続化・再利用を無効化)。 - **実装**: 既定のLLMバックボーンとしてGemini 2.5 Pro(推論・コーディング両段階)を採用。MG=3、MA=2。全LLMベース手法(Full・アブレーション)は同一バックボーン・コンテキスト予算・デコード設定を共有し、非LLMベースラインはOpenRCAプロトコルに従う元実装を使用。全実験はコールドスタート条件(事前の失敗履歴なし。長期記憶とツールインベントリが空から評価中に蓄積)で実施。品質台帳(式1)は実行ベースの信号のみから更新され、正解ラベルからは更新されない(テスト情報の漏洩なし)。実験環境はIntel Xeon Gold 6326 CPU・NVIDIA A40 GPUのLinuxサーバ。 ## 実験結果 - **RQ1(マルチエージェントオーケストレーションの効果)**: フル構成はスコア率0.80を達成し、全ベースラインを大きく上回った。C@1は49.85%(ほぼ半数のクエリがtop-1予測で完全解決)、P@1は79.40%。LLMベースラインRCA-agent(Sr=0.17)に対し4.71倍。非LLM手法はSr 0.4未満に留まり、粗粒度のRCAに特化しOpenRCAの多要素要件(時刻+コンポーネント+原因)に苦戦する。システム規模別では、最も複雑なMarket(72サービス)でもC@1 37.84%・Sr=0.73を維持し、RCA-agentはC@1が5%未満に低下した。 - **RQ2(設計パターンの寄与)**: マルチエージェント化(パターン1)はSr 0.47→0.80(70%改善)、C@1 28.36%→49.85%(76%改善)。Hardタスクで最も改善が大きい(C@1が3.1倍)。ツール精緻化(パターン3a)はC@1を22.09ポイント改善(27.76%→49.85%)。ツール永続化(パターン3b)はC@1を27.76ポイント改善(22.09%→49.85%)。精緻化ラウンド数の感度分析では、Sr が1→3ラウンドで0.52→0.80へ向上し3ラウンド超でプラトーに達する(図6)。 ![[fig06-refinement-rounds-impact.png]] - **RQ3(LLMバックボーンへの互換性)**: 55件のサンプルで3種のバックボーン構成を比較。DeepSeek R1(推論)+ Claude 3.5 Sonnet(コーディング)はClaude 3.5単独より26%高いSr(0.69 対 0.61)を達成し、2段階ツール生成が推論とコーディングを分離する設計の有効性を裏付けた。Gemini 2.5 Proが推論・コーディング両方に優れ、最良の総合性能(Sr=0.80)を示した。全構成でRCA-agentを一貫して上回った。 - **RQ4(オーケストレーションのオーバーヘッドと効率)**: 定常状態(ツールが永続インベントリから再利用可能な状態)での平均エンドツーエンド診断レイテンシはシステム種別ごとに173〜220秒で、5分の本番要件内に収まる。レイテンシ内訳はメトリクスエクスプローラが最大(45.4%)、トレースエクスプローラ(30.1%)、ログエクスプローラ(24.5%)の順。新規ツール生成が必要な場合は追加で平均260秒を要する。1インシデントあたり平均14.5回のLLM呼び出し、約52.67Kトークンを消費し、RCA-agent(19.0回・164.2Kトークン)比でLLM呼び出し23.68%削減・トークン使用67.94%削減を達成した(主にツール再利用とデュアルメモリの最終結果のみ共有する設計による)。ツールセットは処理5〜6件後に安定化し再利用率は80%を超え、Company Aの4本番システム全てで一貫したパターンだった。 ## 考察 - **産業導入(2025年6月以降・Company Aの4本番システム)**: 内部評価で診断精度80%超、手動診断時間を1時間超から5分未満へ短縮したと報告。ハイブリッドモデル配置(ローカルモデルがデータ接触型タスク、外部モデルが推論)は259件のネットワーク障害データセットでQwen2.5-7B-Instruct(ローカル7Bモデル)が同等レイテンシで80%精度を達成し、機微なテレメトリのプライバシー懸念を緩和する。新規システムのオンボーディングは、オブザーバビリティソースの設定のみで、長期記憶・ツールインベントリはゼロから起動するため既存インシデントレポート不要という移植性を確認した。著者ら自身が、これらの導入実績は統制された実地実験ではなく運用上の集計観測であり、システム別分布・テールレイテンシ(p95等)を伴う厳密な縦断研究は将来課題であると明記している。 - **ケーススタディ**(図7): API応答時間アラート(P99レイテンシが3秒超)を起点に、Plannerがメトリクス→トレース→ログの調査計画を生成。Metric Explorerが異常な潜時スパン(10:22〜10:31)を検知(初回ツールはタイムゾーン変換の誤りで無出力、精緻化後に検知成功しSTMへ公開)。STM経由で異常ウィンドウを認識したTrace Explorerがorder-procでの5倍の遅延を特定。Log Explorerがorder-procのconnection pool exhaustedエラー(異常ウィンドウ内で63回発生)を検出。Reasonerが3モダリティの証拠(メトリクス異常ウィンドウ+メモリサージ、トレースレベルのボトルネック、ログレベルの障害モード)を統合し、直近デプロイされたコードパスの未処理例外に起因するデータベース接続リークを根本原因として正しく特定した。 ![[fig07-case-study-workflow.png]] - **教訓1: レイテンシSLAにはツール再利用が不可欠**。初期導入時、新規障害タイプに遭遇するとツール生成フェーズが5分の局所化予算を超過することがあった。オンボーディング時に代表的な過去事例を使ってツールを事前生成するウォームアップ戦略により、定常状態の診断レイテンシをコールドスタート時の平均480秒からウォーム時195秒へ削減した。 - **教訓2: オーケストレーションの透明性がSRE採用を促進する**。SREは、診断結論が「何か」だけでなく「なぜ」導かれたかを理解する必要があると一貫して強調した。マルチエージェントアーキテクチャは、どのモダリティが分析されたか・各段階で何が検知されたか・クロスモーダルな証拠がどう相関付けられたか・最終根本原因がどう導出されたかを示す構造化された推論軌跡を自然に生成し、これがCompany AのSREにとって採用の鍵要因だったと報告されている。各レポートは自動的な修復コマンドではなく補助的な結果として提供される。 - **失敗モード**: (1) STMを通じたエラー伝播 — 早期のエクスプローラが誤った所見(例: メトリクスエクスプローラが異常ウィンドウを誤ラベル)を公開すると、下流のエクスプローラがそれに固定され誤った領域へ分析を絞り込むことがある。2モダリティ以上からの証拠収束を要求する仕組みは多くを捕捉するが全てではない。(2) 有用でない次モダリティ選択 — コントローラが当該インシデントにほとんど信号を持たないモダリティへサブタスクを割り振り、証拠集合が方向転換するまでレイテンシ予算の一部を浪費することがある。 - **未解決の課題として著者らが列挙**: エージェントワークフローの形式検証(協調性・終了性・網羅性の保証)、インシデント複雑度に応じた適応的エージェントスケーリング(現状は3体固定のモダリティ特化エクスプローラ)、マルチエージェントサービス信頼性のための標準ベンチマーク(既存ベンチマークは協調効率・エージェント障害下でのグレースフルデグラデーション・エージェント間情報の忠実度を評価しない)。 ## 強み / 弱点・課題 - **強み**: (1) 産業運用(Company Aの4本番システム、2025年6月以降)に裏付けられた設計であり、机上のアーキテクチャ提案に留まらない。(2) 4つの設計パターンそれぞれにアブレーションを対応させており(w/o MAS→パターン1、w/o Refine/w/o Persist→パターン3)、寄与を個別に定量化できている。(3) スペクトルベース障害箇所特定の式をツール品質評価へ転用する着想は、既存のツール再利用機構(単純な類似度ベース検索)に品質保証という新しい軸を加える。(4) 失敗モードの節を自ら設け、STMのエラー伝播や非生産的なモダリティ選択という限界を隠さず報告している。 - **弱点・課題**: (1) 産業導入の効果(診断精度80%超・時間短縮)は統制された実地実験ではなく運用上の集計観測であり、著者ら自身がその限界を明記している。(2) モダリティ特化エクスプローラは3体固定であり、単一モダリティに閉じたインシデントでは過剰投資、複雑なカスケード障害では専門エージェント不足という両方向の限界を著者らが認めている。(3) OpenRCAでの評価はGemini 2.5 Proを主要バックボーンとしており、コスト・レイテンシの観点で全ての構成にわたる体系的な比較は限定的(RQ3は55件のサブサンプルのみ)。(4) STMのエラー伝播が2モダリティ収束の要件でも完全には防げない点は、コントローラの終了条件設計に残る課題である。 ## 出典 - [[.raw/papers/Reliable-Orchestration-of-Specialized-Multi-Agents-for-Cloud-Incident-Diagnosis.pdf]]