サービス復旧時間短縮を実現するアラート自律対応システム
－LLM×RAGによる被疑特定と対処立案の自動化－

01. まえがき

近年の通信ネットワークの大規模化・複雑化に伴い，ドコモのネットワーク監視環境で扱うアラートは増加している．従来は，保守者がアラートを目視確認し，過去の障害事例や運用マニュアルと照合することで原因分析と措置判断を行ってきた．しかし，24時間365日の監視体制では，人的負荷，判断の属人化，および運用コストの増大が課題となっている．
これに対し，LLM（Large Language Model）*1の推論能力とRAG（Retrieval-Augmented Generation）*2による過去の障害事例の検索を組み合わせたアラート自律対応システムを開発し，docomo MEC（Multi-access Edge Computing）*3のネットワーク監視環境への適用可能性を検証している．アラートのグルーピング，重大度判定，原因分析，措置手順の提示，保守者への通知，およびチケット*4の作業メモの更新までの一連の初動対応フローを，アラート自律対応システムが保守者に代わって自律的に実行することで，障害復旧の迅速化および運用品質の平準化を目標とする．なお，ユーザ影響の大きな措置については，保守者の確認・承認を前提とする．
本稿では，アラート自律対応システムの設計思想と構成について解説する．さらに，実際の運用プロセスを想定した検証環境での評価結果を示し，保守者による確認・承認を含む安全設計と，将来的な自律運用に向けた機能拡張の方向性について述べる．

02. ネットワーク運用における課題

ネットワーク運用では，保守者は障害発生時にアラート内容を短時間で把握し，ユーザ影響有無・影響範囲を判断した上で必要な措置を速やかに実行する必要がある．しかし，監視対象の大規模化によりアラートの種類や件数は増加しており，保守者がそれらのすべてを目視確認し，過去障害事例や運用マニュアルと照合する従来の運用には限界がある．また，夜間・休日を含む運用では，保守者の熟練度や体制により初動対応の速度がばらつきやすい．
このため，ドコモでは障害対応の迅速化や運用負荷の削減を目的として，インシデント管理用SaaS（Software as a Service）*5の導入を従来から進めてきた．これによりアラート対応業務は一定程度効率化されたが，インシデント管理用SaaSに蓄積された過去障害事例や対応履歴は，主に保守者が都度検索・参照して判断する運用が中心であり，アラート内容に応じて関連ナレッジを自動的に抽出・提示する仕組みが求められる．
近年では，RAGによって外部ナレッジを検索・参照し，その情報を活用して応答生成を行う手法が広く用いられており，この手法によって，従来は人手で実施していた障害分析についても，AIによる自動化が可能と考えられる．そこで，既存のナレッジにRAGを適用し，障害分析および措置手順の提示の自動化に焦点を当てたアラート自律対応システムの構成について検討と実装を行った．

03. システム構成

3.1 全体アーキテクチャ

本システムの全体構成を図1に示す．本システムは，監視装置から発報されるアラート（図1①）を起点として動作する．発報されたアラートはインシデント管理用SaaSによって「マスキングツール／アラートグループ化ツール」に転送される（図1②）．マスキングツールでは，アラート内に含まれる所定の機密情報をパブリッククラウド上のログなどに残さないように，適宜マスキング処理を行っている．また，アラートグループ化ツールでは，所定の条件に基づいて，関連性の高いアラート同士がLLMによって集約される．その後，集約されたアラートがメインエージェント*6に転送され（図1③），後の再分析のためにアラートに紐付くセッション*7情報がデータベースに保存される（図1④）．
メインエージェントは各種ツールの使い方や使用タイミングを記載したシステムプロンプト*8やスキーマ*9を参照して推論を開始する．ツールの一覧を表1に示す．メインエージェントは各種ツールを呼び出すことで（図1⑤），過去事例や運用マニュアルをナレッジベース*10やベンダ連携用SaaS*11から取得し（図1⑥⑦），それらの情報を基にアラートの分析を行い，分析結果提示ツールを通じて分析結果をチャットツールに投稿する（図1⑧）．
保守者はチャットツールに投稿された分析結果を確認し，内容が正しければ承認，誤っていれば修正依頼を指示することで（図1⑨），チャットツールは保守者からの承認／修正依頼をメインエージェントに転送する（図1⑩）．メインエージェントはどの分析に対する承認／修正依頼なのかを照合するため，データベース上のセッション情報の呼出しを行う（図1⑪）．その後は再度，各種ツールを利用し（図1⑫），状況に応じて，チャットツールに再分析結果を投稿，ベンダへの問合せを実施，作業メモを更新する（図1⑬～⑮）．処理のフロー図を図2に示す．
一方で，これらのアラート分析の一連の流れによって，インシデント管理用SaaSやベンダ連携用SaaS上の情報は継続的に更新されていくため，ナレッジベース上の情報も定期的に更新する必要がある．そこで，定期的に実行される「定期更新ツール」がインシデント管理用SaaSやベンダ連携用SaaSから情報を収集し，ナレッジベースの更新を行っている（図1❶～❸）．このフローはアラート発報により動作するフロー（図1①～⑮）とは別の時間軸で実行される．ナレッジベースの更新においてはRAGの精度向上のために，収集した情報に対して工夫を行っており，それを以下で説明する．

3.2 ナレッジベース構築時の工夫

過去事例取得ツールによって参照されるナレッジベースを継続的にアップデートするために，インシデント管理用SaaSやベンダ連携用SaaSに蓄積された運用関連情報を定期的に収集するための定期更新ツールを用意した．本ツールが収集した情報をベクトル検索*12が可能な形式に加工してナレッジベースを更新している．
ここで，RAGの精度は格納するナレッジベースの品質に依存するため，十分に整理されていない運用関連情報をナレッジベースに取り込むと，ベクトル検索の精度は低下してしまう．そのため，装置種別やアラート種別などのメタデータ*13付与，キーワード抽出，要約・構造化，ナレッジ価値判定，およびチャンク分割*14を行うことで，検索精度の向上とノイズ低減を図った．ナレッジベースの品質向上を目的とした前処理の概要を表2に示す．
続いて，ナレッジベース定期更新時の具体的な流れについて解説する．フローは図3に示す．定期更新ツールは定期的に実行されるトリガによって起動される．ツールが起動されると，「ナレッジ収集フェーズ」にて，インシデント管理用SaaSやベンダ連携用SaaSから運用関連情報が収集される．その次の「ノイズ除去フェーズ」にて，所定の条件に基づいて，機械的に不要な情報の削り落としを行う．そして，「要約・キーワード抽出・価値判定フェーズ」では，表2に示した「メタデータ付与」「キーワード抽出」「要約・構造化」「ナレッジ価値判定」がLLMによって行われ，キーワードや要約・構造化された文言が抽出される．抽出された文言は次の「整形フェーズ」にて利用され，ナレッジ登録に適した形式に整形される．ただし，場合によっては整形処理後の情報量が想定よりも多くなってしまうことがあり，ナレッジベースの品質低下の原因となるので，表2に示す「チャンク分割」によって，あらかじめ指定した情報量に収まるようにトリミング処理を行っている．ナレッジベースの品質向上を目的とした前処理はこれで完了となるが，インシデント管理用SaaSやベンダ連携用SaaS上には，過去の運用において誤って記載された機密情報が残存している可能性がある．そのため，これらの情報がナレッジベースへ取り込まれないようにする仕組みが必要である．また，将来的に機密情報が誤って記載された場合であっても，ナレッジベースへの流入を防止し，情報漏えいリスクを低減するための対策が求められる．そこで，整形が終わったものについて，「機密情報マスキングフェーズ」にてLLMを利用して機密情報が残っていないかを分析し，残っていた場合はマスキング処理を実施している．マスキング処理まで完了したドキュメントはクラウドのストレージ上に格納され，「ナレッジベース更新フェーズ」にてナレッジベースの更新が行われる．
なお，定期更新ツール内の「要約・キーワード抽出・価値判定フェーズ」や「機密情報マスキングフェーズ」で利用しているLLMは高度な推論性能を必ずしも必要としないため，比較的軽量なLLMを用いることで，運用コストの抑制にも配慮した．

04. 評価結果

docomo MECのネットワーク監視環境において過去に複数回発報され，今後も発生が想定される5種類のアラートを対象として，本システムの評価を行った．評価条件を表3に示す．ここで，インシデント管理用SaaSは，アラートが発生するたびに処理番号を割り振り，作業メモなどのアラート対応状況の管理を行っており，アラートの処理番号や発生日時が分かれば，本システムはインシデント管理用SaaSの検索機能を利用して，当時の対応状況を容易に特定できる．このため，評価では，各アラート本文から発生日時や処理番号をマスキングしたデータを用い，本システムと保守者について，アラート受信から原因分析結果や措置手順の提示完了までに要した時間（秒）を計測し，比較した．なお，保守者は，業務経験2～3年程度で，週2日程度アラート監視業務に従事している中堅レベルの者とした．
評価結果を図4および表4に示す．本システムの提示時間は5アラートで70～86秒（平均77.2秒，標準偏差*15約7秒，最大値／最小値比約1.23）と安定していたのに対し，保守者A・B・Cの提示時間は74～945秒に分布し，保守者全体の平均は約476秒，保守者ごとの平均は保守者A：678.8秒，保守者B：465.0秒，保守者C：285.0秒であった．保守者の標準偏差は約160～260秒，最大値／最小値比は約2.0～9.9と大きく，経験や対応方針の差により提示時間が大きくばらつくことが確認された．
本システムは保守者平均と比較して約84％の時間短縮を達成し，最も対応に時間を要したアラート③（保守者A：945秒）に対しても82秒で完了するなど，アラート種別および保守者の経験差によらず安定した分析・提示時間を実現した．
分析結果や措置手順について，業務経験3年以上のベテランクラスの保守者により評価を行い，本システムと各保守者によって提示された内容の分析結果や措置手順に誤りが無いことを確認した．また，各アラートを本システムに10回ずつ分析させたところ，出力文言に軽微な差異はあるものの，いずれもベテランクラスの保守者から見て，分析結果や措置手順について正しい結果が得られ，分析結果の十分な再現性を確認した．この結果により，本システムを導入することで，保守者が数分から十数分を要していた初動分析を約1分で実施可能とした．また，保守者の経験差による対応時間のばらつきを抑え，均質な障害対応を実現できる可能性を示した．

05. 安全設計と自律運用への展望

AIをネットワーク運用へ適用する際には，安全性と監査性の確保が不可欠である．現状では，AIの回答精度や信頼性を継続的に検証する段階であるため，障害の原因分析，措置手順の提示，およびベンダへの問合せが可能な構成での実証実験を実施した．一方で，将来的には，自動復旧を含む実行系の機能を具備し，本システムが分析結果に基づいて安全な範囲で運用アクションを自動実行できる構成をめざす．そのためには，実行前の影響範囲確認，実行可能な操作範囲の制限，精度が十分でない処理に対する保守者承認の要求，異常検知時のロールバック*16，実行後の正常性確認，監査ログ取得，およびプロンプト・ツール利用条件の制御を組み合わせたガードレール*17設計が不可欠である．保守者承認の要求については，初期段階では，保守者による確認・承認ステップを必須とし，分析精度の向上と十分な運用実績の蓄積により信頼性を十分に確認できた領域から，自動実行へと段階的に移行することを想定している．また，本システムの出力を保守者が適切に評価・修正指示できるように，保守者の育成やレビュー体制の整備も重要と考えている．
本取組みは，ネットワーク自律運用に向けた段階的な高度化の一部として位置付けられる[1]．従来の運用では，インシデント管理用SaaSによるアラートの可視化や通知，チケット管理など，Awareness（認知・状況把握）およびExecution（実行）に相当する機能の自動化を進めてきた．これに対し，新たに構築した本システムは，AIを利用した原因分析や措置手順提示の自動化というAnalysis（分析）に相当する機能を自動化するものであり，TM Forum*18で議論されているオペレーション標準化やAutonomous Networks*19の方向性とも合致する[2]．
今後は，本システムが提示した分析結果に基づき，保守者が選択すべき措置候補を整理するDecision（意思決定）に相当する機能や，影響範囲が限定された操作を安全に実行する機能への拡張が考えられる．さらに，AIを用いた自動化シナリオやIntent*20（意図）モデルおよびAPI（Application Programming Interface）に関する議論も進んでおり[3]，将来的には，サービス品質目標や運用ポリシーをIntentとして入力し，ネットワーク状態に応じて必要な運用アクションを自律的に選択する仕組みへの発展が期待される．

06. あとがき

本稿では，LLMとRAG技術を組み合わせたアラート自律対応システムの設計と，docomo MECのネットワーク監視環境における実証実験の結果を報告した．アラート自律対応システムの導入により，これまでに保守者が実施していたアラートの原因分析や措置手順の提示をAIに担わせることで，障害発生時の初動対応の迅速化に加え，保守者の経験差に依存しない安定した原因分析・措置手順提示の可能性を確認した．また，従来は保守者に依存していた原因分析の自動化についても可能性を示した．今後は，安全性と信頼性を確保しながら，機能を段階的に拡張することで，より高度な自律運用の実現をめざす．