ネットワーク障害対応AIに「生きた地図」を与えるHuawei GTS

導入

ネットワーク障害対応エージェントは、単一のログやCLIの出力を解釈するだけなら高い能力を示せる。しかし、実際の運用環境では、複数の機器、分岐する経路、ファイアウォール、ECMPが同時に関係する。エージェントは各コマンドの結果を理解するだけでなく、その情報がネットワーク上のどこに位置するのかを覚え続けなければならない。

Huawei GTSのチームは、この問題を「トポロジー健忘」と表現している。テキストだけのエージェントは、障害に関係するファイアウォールを見つけても、それが経路上の何番目にあるのか、どの分岐に属するのかを見失うことがある。調査が深くなるほど局所的な情報は増える一方、全体像が崩れてしまう。NetCanvasは、この空間情報を外部ワーキングメモリとして保持する仕組みだ。

NetCanvasの仕組み

NetCanvasは、最初から完成した静的なネットワーク図を提示する方式ではない。障害対応の進行に合わせてグラフを更新する。

• 段階的な成長：CLI調査で見つかった機器、リンク、経路の証拠を、その都度現在のグラフに追加する。
• 必要な範囲だけ表示：全体図と局所図を切り替え、調査対象のノードや経路を強調できる。
• 仮説を図に残す：線の色や種類を使い、接続状態や推論上の仮説を記録する。
• 技術者の認知に合わせる：ネットワークエンジニアが理解しやすい配置にすることも、モデルが図を利用するうえで重要だとされる。

この設計では、モデルが次に調べる対象を判断し、キャンバスが変化するネットワークの構造を記録する。大量のログをすべてテキストコンテキストに押し込む必要を減らせる点が特徴だ。

公開された評価結果

素材によれば、通信運用ベンチマークCTBenchで、全体のタスク達成率は30.3%から54.5%へ向上した。物理的な接続情報を事前に与えた条件では63.6%に達したという。二重ファイアウォールやECMPを含む、経路関係が重要なサブタスクでは、達成率が約10%から約90%へ上がったと報告されている。

タスク単位の比較では、性能が低下した問題はなく、16問が新たに解け、50問は同じ結果だったとチームは説明している。平均探索ステップも159から113へ減少した。正解1件あたりで計算したトークン試行コストは、26%から45%低下したとされる。

ただし、これらはプロジェクトが公開したベンチマーク結果である。異なるベンダーの機器、大規模な本番環境、未知の障害条件で同じ効果が得られるかは、追加検証が必要だ。

意義と今後

重要なのは、単にエージェントへ図を見せることではない。熟練したネットワーク技術者は、通信の流れ、分岐、機器の位置を頭の中で更新しながら調査する。その空間モデルを、エージェントが継続的に読み書きできる状態として実装することに意味がある。

この考え方は、専門エージェントの設計にも示唆を与える。性能を決めるのは基盤モデルだけではなく、ツール、状態管理、表示方法を含む周辺システムでもある。データベースや産業手順のように構造的な関係を扱う分野でも、外部ワーキングメモリは有効かもしれない。NetCanvasの実運用上の価値は、トポロジーデータの品質、権限設計、現実の障害パターンへの対応範囲に左右される。

プロジェクト： caimanjing/netcanvas

ベンチマーク： CTBench

出典： 量子位