概要
ネットワーク障害対応では、「どの範囲が影響しているのか」「どの機器で異常が発生しているのか」を素早く把握することが鍵となります。
しかし実際には、数百単位のmetrics情報・疎通情報・ログ・実機情報を突き合わせながら原因を絞り込む必要があり、人手による対応には時間と属人性の課題が残っています。
本件では、ネットワークの知恵を組み込んだAI Agentが障害に関連しそうなノードを網羅的に探索し、抽出されたノード群を別のAgentが精査する協調的な仕組みにより障害箇所の情報整理を行うプロトタイプ実装を進めています。
これらの仕組みの有用性を検証するため、2025年1月より評価試験を実施予定です。
1. 背景と課題
DataCenterのClow NWにおいて一つの通信に関与する装置が多く、そのすべてでmetrics・疎通情報・ログを確認する作業が膨大となり、解析時間の長期化や解析ノウハウの属人化が課題となっています。
従来のコーディングをベースとした、解析では複雑になりがちだった障害対応の原因特定をAI Agentベースで進めてみました。
2. 設計概要
2.1 マルチエージェント構造
統括する親エージェントと各ノードを検査する子エージェントによるマルチエージェント構造とすることで、高速化とコンテキストの圧縮をはかりました。
親エージェントと子エージェントの二層構造にすることで子エージェントは”疑わしい”を全てエスカレーションし、親エージェントでまとめる事で、各ノードの詳細な情報収集とネットワーク全体の関連調査の両立を図っています。
2.2 LLM-as-Interpreterでの開発工数圧縮へのチャレンジ
各ノードを検査する子エージェントには「エンジニアの知恵」と言うべき確認ポイントを支持することで、LLMの知識不足をカバーした精密な調査を行なっています。これらの調査をあえてスクリプトベースではなくLLMベースで行う事で機種やOS、構成差分への対応工数の圧縮を試みました。
3. 実網評価試験計画(2026年1月開始予定)
2026年1月より、導入試験を実施いたします。
これにより障害特定情報の精度、対応一貫性の問題がないか、LLM-as-Interpreterでのコードの柔軟性を評価し、AI Agent導入の有効性を検証します。
4. 考察と今後の展望
本発表では、AI Agentの設計方針と評価結果を共有し、AIが運用現場の切り分け支援としてどこまで実用化できるのかを議論します。
議論ポイント
– AI Agentによる障害検知に実用化の未来はあると思いますか?
– LLM-as-Interpreter vs スクリプト、この結果を見てNOSの確認作業はどちらであるべきだと思いますか?
– AI Agentのあり方は”知恵注入方”と”自立思考型”どちらの方がより実用性があるか各社の事情都合などと絡めてご意見交わしたいと思います。
場所
本会議場2 グラングリーン大阪北館6F 6-1
日時
Day3 2026年2月13日(金) 15:00~15:40 (40分)
発表者
公開資料
各種情報
| ストリーミング配信 | 実施する |
| アーカイブ配信 | 実施する |
| SNSやSlackでの議論 | 制限しない |
| プログラム種別 | 登壇者から応募のあったプログラムです |
アーカイブ配信
本会議終了後、順次配信予定です
