3種のエージェントが役割分担

AIエージェントの構成にも工夫がある。役割の異なる3種類のエージェントと、それらを統括する司令塔役が連携して監視・保守業務を遂行する。「各エージェントのコンテキスト容量（一度に扱える情報の量と範囲）に限界があるため、業務ごとに分割する必要がある」というのがその理由だ。特定の業務に特化させることで、精度を高めている。

正常監視エージェントはトラフィックデータやアラームを常時監視し、異常を検知する。要因推定（RCA）エージェントは、ネットワークの接続関係をグラフ構造として把握し、故障の根本原因を特定する。グラフ構造とは、データ間の関係性を「ノード（頂点）」とそれらをつなぐ「エッジ（辺）」で表現するデータ構造のことだ。SNSのつながりや交通網など複雑なネットワークを視覚的にモデル化する手法として広く使われている。

そして、レコメンドエージェントがマニュアル等を参照し、人間のオペレーターに対して最適な復旧手順を推奨、判断を仰ぐ。オーケストレーターエージェントは、これら3種の活動を管理・統括する。

取材時は商用稼働を開始してまだ3カ月余りであり、深刻な複雑故障を経験していない状況であったが、竹下氏は「複雑故障の対応時間を50%削減できる見込みだ」と述べた。従来はエスカレーション後に情報収集から始めていたが、AIエージェントが常時監視しているため、「エスカレーション時点ですでに必要な情報が集まっている状態を実現できている」ことがその理由だ。

一方で、現場からは課題も指摘されているという。「分析結果の精度は高く評価されているものの、処理時間がやや長い」というものだ。AIエージェントが調査・分析の際に複数回、生成AIを呼び出すため時間がかかっているのである。ChatGPT等の一般的なAIチャットボットと比べると応答は遅くなるが、「それでも、人間の対応より大幅に速い」（竹下氏）。この声は、現場の期待の大きさを表しているとも取れるもので、分析精度と応答性の向上を両立すべくさらにチャレンジしていきたいという。

異ベンダーの壁を乗り越える

ドコモは本システムをどのように開発したのか。ネットワークデータの集約やAIエージェントの開発には、AWSサービス群を利用している。図表1のように、ドコモ網からAWSのデータ基盤へトラフィックやアラーム情報等を収集。保守メンテナンスに関するナレッジデータベースも同基盤に構築した。AIエージェントの開発には、AWSのマネージドサービス「Amazon Bedrock AgentCore」を使っている。

図表1　ネットワーク保守向けAIエージェントシステムの全体像

ドコモでは、可視化や自動化を推進するために4年以上前からデータを整備するプロジェクトを始めた。様々なベンダーの機器・装置の組み合わせでできている通信事業者ネットワークから統一的にデータを収集し、装置間の接続関係を正確に把握してシステムが活用できるように取り組んできた。これらのアセットを活用することで、AIエージェント自体の開発については約半年で完了することができた。

ドコモとAWSは両社でアーキテクチャ設計を議論。AWSがAIエージェントの構築・運用プラットフォームを主に担当し、ドコモが業務整理、データ収集・整理、オペレーター向け画面の作成を担当した。

ここで竹下氏が強調したのが「内製化」の重要性だ。AIエージェントの開発・精度向上には「熟練者の暗黙知を学習させるプロセスが重要」であり、同氏らの開発チームが保守担当技術者とコミュニケーションしながら開発を進めた。「プロンプトの調整やデータの精度向上には現場知識が不可欠。アジリティ高く運用するためには、外部委託では困難であり、内製化が必要と考えている」。

全国5GネットワークにAgenticOpsを導入するこの取り組みはまだスタートを切ったばかりだが、竹下氏は今後の展望も口にした。

現在は、AIが対処法の選択肢を提示し、それを人間が判断する「人間とAIの並走」の段階だが、最終的には完全な自律化を目指しているという。「デジタルツインのような機構を用いて、AIが自ら出した答えを評価・確認したうえで実環境へ適用できる仕組みを取り入れることで、人間が介在せずに故障復旧まで完結させる世界観が将来的には実現できるのではないか」と話す。AIに任せる範囲が徐々に拡大すれば、保守者の役割は最終的に「AIの監視とチューニング」に変化していくことも考えられる。