# ネットワークトラブルシューティングエージェントベンチマーク ## 定義 LLM エージェントがネットワークインシデント(リンク障害・誤設定・リソース競合・攻撃等)を検知・箇所特定・根本原因分析(RCA)できるかを、稼働中のネットワークエミュレーション環境上で評価する枠組み。静的な設定合成ベンチマーク(NetConfEval・NetLLMBench)とは異なり、動的なネットワーク状態との closed-loop な相互作用を要求する点が特徴。NIKA([[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]])は、Kathará ベースのコンテナエミュレーションと Model Context Protocol (MCP) 経由の Agent Access Layer を組み合わせ、640 通りのインシデントで公開ベンチマークを構成する現時点最大規模の実装である。(Source: [[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]]) ## 横断的知見 - **ゴールの階層分解パターンがクラウド SRE ベンチマークと同型**: NIKA は「検知 → 箇所特定 → RCA」という 3 階層のトラブルシューティングゴールでエージェントを評価するが、これは [[SRE Benchmark]] で確立された [[AIOpsLab]] の「検知/箇所特定/RCA/緩和の 4 部分問題への分解」と同じ設計思想である。ドメインがクラウドネイティブなマイクロサービスからネットワークインフラへ変わっても、LLM エージェント診断ベンチマークの評価軸が「段階的に難易度が増すゴール階層への分解」に収束している可能性を示唆する。ただし NIKA は緩和(mitigation)の評価を明示的にスコープ外としており、AIOpsLab・SREGym が含む緩和段階を欠く。(Source: [[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]], [[SRE Benchmark]]) - **障害注入手段がドメインごとに異なる技術スタックへ分岐する**: クラウド SRE ベンチマーク([[AIOpsLab]]・[[SREGym]])は ChaosMesh 等のアプリケーション/仮想化層のカオスエンジニアリングツールを主に用いるのに対し、NIKA はネットワーク層の障害を Linux Traffic Control (TC)、ソフトウェア資源競合を stress-ng、デバイスレベル障害をカスタムスクリプトで注入する。対象レイヤー(アプリ/コンテナ vs. ネットワークリンク/デバイス)の違いが、障害注入機構の選択を規定している。(Source: [[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]], [[障害注入]]) - **構造化ツールインターフェースがハルシネーションを抑制するという主張の再確認**: NIKA は MCP 経由で 30 種類超の構造化ツールを提供し、ツール呼び出し誤り率が GPT-5 で 0.7%・GPT-5-mini で 1.6% と低いことを、先行研究([18, 57]、クラウド SRE ドメイン)が報告する重大なツールハルシネーション問題との対比で説明する。ドメインを問わず「生の CLI/API でなく MCP のような構造化インターフェースを介する」設計が、LLM エージェントの誤ったツール呼び出しを抑える可能性を示す一次データ点が、ネットワークドメインでも得られたことになる。(Source: [[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]]) ## 未解決の問い - NIKA は診断(検知・箇所特定・RCA)のみを評価し、緩和(mitigation)の評価を将来課題としている(Batfish 統合を計画)。クラウド SRE ベンチマーク([[AIOpsLab]]・[[SREGym]])が緩和評価に用いる「状態ベースの成功判定」は、ネットワークの改善策検証(構文的正しさ + 安全性)にそのまま転用できるか、それともネットワーク固有の検証(コンフィグの到達性解析等)が必要か。 - NIKA の評価は公開 640 インシデントのうち代表 150 件のサブセットで行われている。サブセット選択の代表性(各問題を「典型的なシナリオの 1 つで」インスタンス化)が、全数評価の結果とどの程度乖離しうるか。 - クラウド SRE ドメイン([[SRE Benchmark]])で観測された「複数ベンチマーク横断評価の標準化」「LLM-as-a-judge への収束」といった潮流は、ネットワークトラブルシューティングドメインでも今後同様に起きるか。NIKA 一次論文は混同行列ベースの精度評価のみを記述するが、[[SADE]] 論文は「NIKA の LLM-as-judge プロトコル」への言及があり、両者の記述に食い違いがある([[NIKA]] の contradiction callout 参照)。NIKA の GitHub 実装が judge ベースの採点を後から追加したのか、SADE 独自の judge を NIKA 由来と誤記したのかは未確認。 ## 関連 - [[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]] — NIKA 一次論文。 - [[NIKA]] — ベンチマーク本体の entity ページ。 - [[障害注入]] — 障害注入機構の横断比較。 - [[SRE Benchmark]] — クラウド/マイクロサービスドメインの類縁ベンチマーク群。 - [[根本原因分析]] — RCA タスクの一般的な定義。 - [[エージェント型ネットワーク障害診断]] — NIKA 上で評価された SADE が体現する、ネットワーク診断エージェントの設計パターンを扱う姉妹 concept。本ページが「ベンチマークの設計・評価軸」を扱うのに対し、あちらは「診断エージェント自体のワークフロー設計」を扱う。 ## 出典 - [[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]]