ネットワークの自律オペレーションを実現する自動化とAI活用

01. まえがき

モバイルネットワークは重要な社会基盤インフラであり，個人の生活から企業活動，公共サービスに至るまで，あらゆる分野を支えている．スマートフォンによる音声通話やデータ通信はもちろん，キャッシュレス決済，リモートワーク，IoT，地震時の緊急速報など，さまざまなサービスがモバイルネットワーク上で提供されている．
さらに，近年普及してきている第5世代移動通信システム（5G）の高速・低遅延という特性により，自動運転，遠隔医療，スマートシティ*1といった次世代サービスもモバイルネットワーク上でさまざまな形で提供されていくと想定され，それらをサービス断無く提供し続けるために，キャリアはモバイルネットワークを安定稼働させなければならない．このためネットワークの保守は，重要な要素となっている．
そのようなモバイルネットワークの保守業務において，保守部門はハードウェア・ソフトウェアで発生した多種多様な故障に迅速対応し，サービス影響時間を最小化することが要求される．これら故障のうち対処法が明確なものに対しては，あらかじめ決められた手順を自動化することで対処することができる．一方で，対処法が明確でない故障が発生した際は，さまざまな情報を収集し，要因の分析を行い，措置を判断することになるが，これらすべてを保守者が人手で対応するとサービス影響時間が延びる要因となってしまう．
そこで，ドコモでは，これらの複雑な分析や判断をAIが行えるようにするため，AI開発を進めている．具体的には，異常検知AI，要因推定AI，措置レコメンドAIの開発，およびこれらのAIを活用しながら統合的な判断を行う生成AI*2ベースのオペレータAIエージェント*3の開発を行った．これらの技術を組み合わせることで，人手で対応する場合に比べてサービス影響時間を大幅に削減できる見込みであり，本稿ではそれぞれの技術ポイントを解説する．

02. AIによる自動化の概要

AIによる自動化の全体アーキテクチャを図1に示す．モバイルネットワークは一般に，無線アクセスネットワーク，転送ネットワーク，コアネットワークのドメイン*4に大別され，それぞれの領域において運用支援システム（OSS：Operation Support System）*5が存在する．OSSには，各ネットワークエレメント（NE：Network Element）*6から発報される警報の受信・集約機能や，トラフィック量などの統計情報の収集機能が実装されている．これらのデータを基に，通信サービスにおける提供状況の監視および正常状態の維持を行うことが保守業務の主目的である．
通信サービスは異なるベンダやドメインの装置をまたいで提供されるため，各OSSのデータを統合的に分析できなければ，正しく状態を把握することができない．しかしながら，各OSSで収集しているデータの形式や粒度，インタフェースの違いなどにより，システムを統合することは容易ではない．また，保守者が分析できる管理範囲などの要素もあり，多くのキャリアにおいてはベンダ・ドメインに閉じた体制とならざるを得ない．このため，その間を保守者同士が人手で連携して対処することとなり，故障の影響時間が長期化する恐れがある．
故障による影響時間を最小化するためには，保守者の手動介入無しにシステムが自律的なアクション（CLA（Closed Loop Automation）*7）を行う必要がある．このため，ドコモではドメイン横断で装置の状態をリアルタイムに収集し，統一的に扱うデータ基盤の整備を進めている．今回の開発において，AIがデータ基盤の情報を活用することで監視・分析・措置判断をできるようになり，サービス影響時間を大きく短縮できると期待される．
AIによるCLAを実現する要素を図2に示す．モバイルネットワークの保守業務は主に監視・分析・措置のフェーズに分かれる．それぞれのフェーズにおいて，既知の対処方法が明確な故障（定型故障）は自動化で対応する．一方で，定型化が困難な故障（非定型故障）についてはAIで対応する．
・異常検知AIは，装置から収集できるさまざまなメトリクス*8や警報，システムログから異常を検知する．
・要因推定AIは，異常時にどの装置が原因なのかを大規模なデータから分析する要因推定（RCA：Root Cause Analysis*9）を行う．
・措置レコメンドAIは，過去の措置履歴やマニュアルなどから，起こっている事象への対応方法を生成AIにより保守者に措置レコメンドとして提案する．

また，これらのAI機能同士を接続するためにAIエージェントがある．AIエージェントは生成AIを活用した技術であり，各AIのさまざまなアウトプットから動的に分析方法・措置方法を切り替えて最適な措置を実施できるようにしている．これらのAIは，ドコモのモバイルネットワークの保守業務において順次商用化を進めている．
なお，本技術領域は，オペレーション標準化団体であるTM Forum*10において，「Autonomous Network」という名称で自動化の段階の定義が行われている[1]．Autonomous NetworkはLevel 0～5まであり，現在多くのキャリアは保守者ではなくシステムが主に運用を担うLevel 4をめざして技術導入を進めている．本技術群はAutonomous Network Level 4を実現する上では必須となっている．以降で，各技術の詳細を説明する．

03. ネットワーク保守自動化のための各AI技術

3.1 異常検知技術

異常検知技術は，トラフィックなどのネットワークデータを用いて，正常な状態とは異なるデータの傾向を検知する技術である．多くの場合は装置から異常状態を知らせる警報が発せられ，保守者は装置の異常に気付く．一方，装置のソフトウェアの不具合や装置自体の故障により警報が出せないケースなど，警報が発生していないがサービス影響が発生する故障もあり，異常検知技術はそのような故障を検出することができる．本技術はトラフィックおよびシステムログを利用しており，それぞれの技術イメージを図3に示す．
以下では，それぞれの分析手法について解説する．
(1)トラフィック分析
トラフィック分析では，正常状態のトラフィックからAIモデルを作成し，正常状態からかい離するトラフィックの発生を捕捉することによってAIが異常検知を実施している．この技術は，正常状態を学習する学習フェーズと，学習モデルを用いて異常検知を行う分析フェーズから構成される．学習フェーズや分析フェーズに使用するアルゴリズムの選定においては，基地局などのネットワーク装置の稼働期間に占める異常発生期間はわずかであるため，正常時のデータからモデル学習ができるような教師なし機械学習*11をベースとしたAIモデルを採用した．
学習フェーズでは，装置単位などの学習・分析を実施する単位で学習データを作成し，選定したアルゴリズムにそれを入力することでAIモデルを作成する．分析フェーズでは，学習フェーズ同様に分析データを作成し，学習フェーズで作成したAIモデルに入力して分析する．分析した結果，出力される正常状態からのかい離を示す値によって異常とするかを判断し，異常と判断した場合は保守者に通知を行う．
(2)システムログ分析
ネットワーク装置からは，装置で起こっているさまざまなイベントが，ログとして出力される．これらにはサービスに影響するイベント，今後影響する可能性のあるイベントが含まれることがあるものの，ログ全体としては膨大な件数が発生するため，システムログの確認は難しかった．そこで，システムログ分析AIにより，システムログを分類し，その上で監視すべきシステムログの絞り込みを行い，監視業務を効率化している．
システムログはテキストデータであり，このテキストデータを分類し数値化を行うためにAIを使用している．分類・数値化工程では，まず半角スペースやタブなどの区切り文字からテキストデータを区切り，単語に分解する．分解された単語に記載されている英数字や記号などの構成と単語の発生順序からAIにより分類を行い数値化する．
異常と判断する数値は決定しているため，保守者はその数値を指定するのみで異常検知が可能となる．また，AIで初めて読み込むシステムログは新しく分類，数値化されることで，今まで発生したことがない未知のシステムログとしてAIは検知を行い，保守者が対処すべきシステムログかどうかの判断を可能とした（図3）．システムログの内容により，ハードウェア障害などの予兆検知にも活用ができる．
本システムログ分析技術と単純な文字列検索の比較における優位性として，AIにより分類することで，装置のアドレスの違いやバージョンアップによるシステムログの細かい変動を考慮する必要が無くなり，装置の種別ごとにまとめてモデルを作成できることが挙げられる．本技術により，日々数百万件発生するシステムログの効率的な監視を実現した．

3.2 要因推定技術

大規模障害時には，複数の装置から大量に警報が発生し，保守者は各警報の内容を確認しながら障害の原因となっている装置の特定を実施するため，時間がかかることがある．このようなケースには，例えば，故障した装置が警報を出せなくなる場合や，装置の振舞いとして周辺装置のほうが警報を多く出す場合などがあり，これらのケースのように警報を確認しても，どこが原因となるかは単純には特定できないことがある．
また，大規模障害のバリエーションは無数にあり，事前にルールを定義する形での障害復旧対応自動化は困難である．
そこで，警報の内容によらず，アルゴリズムにより柔軟に対応可能な要因推定技術の開発を行った．概要を以下に解説する．なお，本件はAWS（Amazon Web Services）*12との共同プロジェクトであり，詳細については文献[2]を参照されたい．
(1)グラフデータとNetwork Digital Twin*13の活用
装置間の繋がり情報であるトポロジ*14情報は，大半がドメインごとにリレーショナルデータベース（RDB：Relational DataBase）*15で管理されているが，ネットワークの全体を繋げた場合，RDBの弱点である「複数テーブル間のJOINやトランザクションをまたぐ操作は，物理的に分散されるとパフォーマンスが大きく劣化しやすい」といったスケーラビリティ*16の問題が生じる．そこで，それを解決するためにネットワーク状のデータ構造において威力を発揮するグラフデータベース*17を活用した．また，物理的なネットワーク環境を仮想空間に再現し，リアルタイムに監視・分析する技術であるNetwork Digital Twinを構築した．
今回の環境構築に活用したデータを以下に示す．
・各ドメインを関連付けるトポロジ情報と各装置の重要度（高い中心性をもつと高スコア）
・各装置の重要度の高い警報数

これらのデータを活用し，実際の商用問題状況をNetwork Digital Twinに再現し，検知から15秒で期待する被疑箇所推定の結果が得られることを確認した．
(2)汎用的なアルゴリズムを用いた被疑箇所推定機能とダッシュボード*18
故障が起こった際に，グラフデータベースに登録した各装置のFM（Fault Management）*19データとトポロジ情報を基に，中心性アルゴリズム*20などの汎用グラフアルゴリズムにより，被疑箇所と想定される装置を算出し，さらに，被疑箇所推定結果をダッシュボード上で可視化性を高く表示することを実現した（図4）．

3.3 措置レコメンド

ネットワーク装置に異常が発生した際，ネットワーク保守者により原因特定・復旧作業が行われるが，ドコモが有するネットワーク装置は膨大であるため，対応時に参照するマニュアルや過去の措置履歴なども数が多く，調査に時間がかかることが課題であった．そこで，生成AIを用いた措置レコメンドシステムを開発した．本システムが，発生した事象に対して最適なマニュアルや過去の措置履歴を保守者に提示することにより，調査に要する時間を短縮できる．
(1)機能概要
措置レコメンドにおいては生成AIを用いるが，生成AIはサービス内容や構成など，業務に固有のドメイン知識*21をもたない．そこで，生成AIからネットワーク装置に関する回答を得るため，保守者の質問に関連する情報（措置履歴，対応マニュアル）をデータベース検索し，その情報とともに生成AIへ質問を与えることで業務固有の知識をもった回答を生成させる検索拡張生成（RAG：Retrieval-Augmented Generation）*22技術を実装した．具体的なイメージについて図5に示す．
措置履歴については，もともとは保守者が参照することを想定しているため，必ずしも生成AIが読み取りやすい形にはなっておらず，無加工のものを読み込ませても良好な結果が得られない（過去に失敗した措置や古い手順を返す／サービス中断のリスクを考慮しない措置の提案など）．この問題を改善するために，マニュアルなどを生成AIが読みやすい形に変換するとともに，措置履歴に対しては，クラスタリング*23により類似した履歴を集約してマニュアルを作成し，これらを生成AIに読み込ませることで，確度の高い措置を生成AIが提示できるようにした．
(2)本技術の有効性
特定の業務領域における実際の障害対応での検証において，従来2時間以上かかり対応全体の5割以上を占めていた影響調査時間を約70％削減し，従来3～4時間かかっていた対応作業を約1時間で完了できることを確認した．
また，作業に習熟していない新規着任者であっても迅速な調査が可能となり，対応品質の均質化に貢献した．

3.4 オペレーション向けAIエージェント

ネットワーク装置の故障は，定型故障（対応方法が明確なもの）と非定型故障（対応方法が不明確なもの）が存在する．定型故障については自動化の仕組みが導入され，人手を介さずに対応を実施できる一方で，非定型故障は保守者が各種警報，データ，マニュアルなど多岐にわたる情報を参照し，対応方法を都度検討しているため，対応の遅れやコスト増加の要因となっていた．
AIエージェントでは，これまで保守者が確認していた警報などの大量のデータを，LLM（Large Language Model）*24でリアルタイムに分析して異常の発生を検知し，保守者による故障対応方針の決定を対話的に支援する．
(1)機能概要
AIエージェントは，常時分析および保守者からのチャットを通じた分析により発見された異常に対して，自律的に試行し回答を導くことができる．その際，社内に存在するさまざまなネットワーク関連データ（警報，システムログ，トラフィックや，トポロジ，工事・イベント情報，措置履歴など）を参照して状況を把握した上で，最終的な回答を出力する．
また，これまで保守者が警報やトラフィック情報を参照する際はOSSの画面確認や，データベース検索を行っていたが，細かい調査には一定のスキルやノウハウが必要であることや，時間がかかることも課題であった．本基盤では，AIエージェントに質問を行うことで，保守者の要望を満たすクエリ*25をAIエージェントが発行できるため，自然言語*26でのデータベース検索も可能となり，クエリなどの知識が無い習熟度の低い保守者でも高品質な対応を行うことができるようになった．
(2)アーキテクチャ
アーキテクチャは2層で構成されており，①エージェント層，②データ層に分かれる．イメージを図6に示す．
①エージェント層
本取組みで扱うデータの種類は多く複雑であるため，単体のエージェントとして実装するのではなく，各種データを専門的に扱うAIエージェントを複数作成し，それらを統括するオーケストレータエージェントが回答に必要な情報を検討し，各AIエージェントに情報整理を実行させるマルチエージェント構成を取り入れた．これにより，保守者へ早期に高精度な回答を提示することを可能とした．
②データ層
故障発生時，AIエージェントが正確な判断を下すためには，リアルタイムなデータを参照できる必要がある．そのため，ドコモネットワークのほぼすべてのデータを収集して適切な形式のデータベース（時系列データベース，グラフデータベースなど）に保管する．また，エージェントが参照できるようにするために，生成AIとのインタフェースとなるMCP（Model Context Protocol）*27が提供できるデータベースを使用している．これにより，①のエージェント層にある生成AI群が適切にデータを分析できるようにした．

04. あとがき

本稿では，AIによるドコモのモバイルネットワークの高度化について解説した．
ドコモは商用ネットワークにおけるAutonomous Networkレベルの向上に向けて，これからもさまざまな技術の活用を検討し，繋がり続けるネットワークの実現に取り組んでいく．

文献