# エージェント型ネットワーク障害診断 ## 定義 エージェント型ネットワーク障害診断は、LLM エージェントがツール呼び出しを通じて稼働中のネットワークを対話的に探査し、不完全かつ層をまたいで連鎖する症状から根本原因を特定する診断タスクである([[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]])。従来の LLM ネットワーク研究(Intent-based networking・zero-touch service management・LLNet・Confucius・NetLLM・NetConfEval 等)が「望ましい結果が既知の意図を設定へ変換する」順問題を扱うのに対し、本概念は根本原因が未知の逆問題であり、証拠収集・ツール起動・仮説改訂を観測の蓄積に応じて繰り返す点で本質的に異なる。 ## 横断的知見 - **証拠取得と仮説確定の分離が中心的な設計軸になる**: [[SADE]] は、既存エージェント(ReAct・汎用コーディングエージェント)が自由形式の熟考の中で証拠取得と仮説確定を混同する点を主要な失敗要因と位置づけ、フェーズゲート型のワークフローでこれを明示的に分離する。この分離の思想は cross-project 的には [[仮説駆動RCA]] における「核となる分析ループ」の考え方と同型であり、クラウド/マイクロサービス RCA の文脈で語られてきた仮説駆動アプローチが、ネットワーク層の診断にも独立に現れたことを示す。(Source: [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]) - **ボトムアップな層順スキャンが健全性の誤認を防ぐ**: SADE の深層ネットワークスキャンは L2/インフラ → 制御プレーン → ホストローカル → サービスの順に証拠を積み上げる。この順序は「下位層の故障が上位層の症状として現れる」という観測的な非対称性に基づいており、上位層(サービス・ホスト)が健全に見えても下位層(ACL・ルーティング)の故障を見落とさないようにする。クロススタック故障(`bgp_acl_block`・`dns_port_blocked`)では、到達性チェックが成功するにもかかわらず特定プロトコル/ポートだけがフィルタされているため、単一層の観測だけでは根本原因に到達できない。(Source: [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]) - **同一バックボーンでのアブレーションが方法論の寄与を定量化する数少ない実証例**: SADE は Claude Code ベースライン(同一 Claude Sonnet 4.6 バックボーン、SADE のワークフロー/スキルライブラリなし)との比較で、RCA F1 差 22 ポイント(0.77 - 0.55)を診断ポリシー自体に帰属させた。AIOps 領域では「LLM の進歩」と「エージェント設計の進歩」が交絡しやすいが、この論文は同一モデルでの有無比較によってそれを分離する具体例を提供する。(Source: [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]) - **停止規則の明示化が「探索の暴走」を防ぐ**: SADE の Phase 3 stop-and-submit ルールは、故障ファミリ指紋が一致した時点を明示的な終了点として符号化する。ベースラインの主要な失敗モードは「予算が尽きるまで探索を広げ続ける」(Claude Code)か「反証せずに最初の仮説へ固執する」(ReAct)のいずれかであり、いずれも明示的な終了/反証規則の欠如に起因する。未提出率(no-submission rate)という指標は、診断の正確性とは独立に「エージェントが診断を完結できたか」を測る点で、他のエージェント型 RCA 研究でも参照価値がある。(Source: [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]) - **スキルライブラリはファジーマッチングにより汎化する**: SADE の故障ファミリスキル(SKILL.md)は、プローブ出力から指紋への対応付けを固定ディスパッチテーブルではなくエージェントの実行時テキスト照合で行う。これにより同一スキルが任意のトポロジ・任意のデバイスに適用できる。この設計は Anthropic の Agent Skills 規約([[Flexible Skill Arrangement]] とも共通する「手続き的知識の外在化」パターン)をネットワーク診断ドメインに適用した具体例である。(Source: [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]) - **ベンチマークの故障注入自体が信頼性の交絡要因になりうる**: NIKA の標準インジェクタが意図した故障を常に注入するとは限らないという観測(開発セット 39 件中 17 件がスコア1で、検証済み注入では全件がスコア5)は、エージェント型診断ベンチマーク一般に対する警鐘であり、低スコアが「診断失敗」か「ベンチマーク側の不具合」かを切り分ける検証パイプラインの必要性を示す。(Source: [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]) ## 未解決の問い - ネットワーク層の障害診断(L2/L3/制御プレーン)と、クラウド/マイクロサービス層の障害診断(既存 wiki の大半を占める領域)とで、症状-故障マッピングの設計原理はどこまで共有可能か。両者を統一するスキルライブラリ設計は成立するか。 - SADE のスキルライブラリは人手著述に依存する。インシデントコーパスやオペレータプレイブックから自動的にスキルを構築・更新するアプローチ(著者らが今後の課題として言及)は、Fault-Index の対応付け精度をどこまで維持できるか。 - Kathará によるエミュレーション環境から実運用ネットワーク(ハードウェアフォワーディング挙動・NIC オフロード・ASIC レベルのキューイング・テレメトリ遅延を含む)への転移で、フェーズゲート型ワークフローの前提(下位層証拠が上位層症状に先行して確認できる)はどこまで崩れるか。 - 未提出率・ツール呼び出し効率という指標は、根本原因の正確性(F1)とは独立の軸として、他のエージェント型 RCA/障害診断ベンチマークでも標準的に報告されるべきか。 ## 関連 - ソース: [[@2026__arXiv__SADE - Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting]]・[[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]](NIKA 一次論文) - システム: [[SADE]] - ベンチマーク: [[NIKA]] - 関連概念: [[仮説駆動RCA]]・[[Flexible Skill Arrangement]]・[[Fault Localization]]・[[根本原因分析]]・[[ネットワークトラブルシューティングエージェントベンチマーク]](NIKA のベンチマーク設計・評価軸を扱う姉妹 concept。本ページは診断エージェント自体のワークフロー設計を扱う)