障害対応もAI時代へ！AIOpsで実現する自律化運用 - ENGINEERING BLOG ドコモ開発者ブログ

はじめに

NTTドコモコアネットワークデザイン部NWAPI担当の福嶋、舟山です。

突然ですが、docomo MECはご存じでしょうか？

docomo MECは、MECサーバー（IaaS基盤）とIoT端末をつなぐ最適なモバイル回線サービスを提供しています。

www.mec.docomo.ne.jp

docomo MECには、接続端末とMEC基盤を直結して通信経路を最適化することで、低遅延・高セキュリティ通信を実現可能なMECダイレクトオプションがあり、私たちはMECダイレクトシステムの運用・開発業務に携わっています。

私たちの担当では、従来よりSaaS導入によるMECダイレクトシステムの運用業務の自動化に取り組んできましたが、今年度は運用業務へのAIの導入を内製で取り組みましたので、その取り組みを紹介いたします。

現状、PoCが可能なところまで実装ができており、商用導入により大幅な業務効率化が期待できると考えています。運用業務へのAI導入にご興味のある方はぜひ読んでみてください。

AIOps概要

ちなみに、AIOpsとは、「人工知能」(AI) と運用 (Ops) という用語を組み合わせたものです。

私たちは運用（Ops）業務として、当番制でシステムのアラート監視を行い、アラートの発生時はアラートの分析や関連部へのエスカレーション、故障個所への修復対応を実施する「監視措置業務」と、システムの増設や減設、アップデート対応等を行う「維持管理業務」を日々行っております。

監視措置業務や維持管理業務において、様々なSaaSを利用し、あらかじめオペレーターがルールを登録しておくことでオペレーターが介在することなくコンピューターが処理を行う、運用業務の自動化（Automation）はこれまで重点的に行ってきました。

一方で、AI自らが手順や判断基準を見つけ出し、AIが自動的に処理を行う、運用業務の自律化（Autonomy）はまだまだ対応が不十分で、直近の重要な課題だと考えています。

そこで、今年度は運用業務の自律化の一歩目として、「AIエージェントを利用した監視措置業務の自律化」に取り組みました。

システム運用にAIを使おうとしたきっかけ

現状の監視措置業務では、オペレーターが判断を行う部分が多く存在し、例として、アラート発生時はオペレーターが以下のようなアクションを実施しています。

運用影響やお客様影響の無いものについてはクローズ
運用影響やお客様影響があるものについては関連部へのエスカレーションや故障個所への修復の実施
運用影響やお客様影響が判断できないものについてはベンダーへの問い合わせを実施

特に、お客様影響が発生したものについては、関連部へのエスカレーションや修復対応を速やかに実施する必要があり、これらが遅れるとお客様に多大な迷惑をかけてしまうのですが、実際にアラートが発生したタイミングからエスカレーションや修復対応完了までどのくらい時間を要するでしょうか？

対応者の熟練度によりますが、概ね以下の図の対応を踏まえると、アラート発生からエスカレーションや修復対応完了まで結構な時間を要してしまいます。

加えて、メンバーの異動により、熟練者がいなくなってしまえば、対応完了までにさらに時間を要すると考えられます。

もし、AIが自律的にドキュメントや過去の対応状況を確認して、アラートの分析や関連部へのエスカレーション、故障個所への修復対応を行ってくれれば、大幅な時間短縮が可能となることから、監視措置業務の自律化は私たちの重要な課題でした。

加えて、私たちの担当では従来から多くのSaaSを導入していたため、例えば、アラートのドキュメントやシステムのマニュアルはMarkdown形式でGitで管理、過去のアラート対応状況はSaaSのAPIを利用してJSON形式でダウンロード可能、と自動化・自律化に取り組みやすい環境だったこともあり、今年度から内製でのRAG（検索拡張生成）を利用したAIエージェントの開発に取り掛かりました。

www.ntt.com

参考までに、25年度で目指している姿が以下の図です。AIエージェントが自律的に情報収集やインシデントの更新を行う想定で、アラート発生から措置までの時間を大幅に短縮することを目標にしています。

AIエージェントの開発の進め方

外部協力者を含む複数名のチームで、スクラム方式（アジャイル開発の手法の一つ）によりAIエージェントの開発を進めています。

本プロジェクトでは2週間単位でスプリントを走らせており、この期間に実装担当が成果物を作り上げます。スプリント期間中は各種打ち合わせを設定しており、概ね以下のイベントが2週間ごとに進んでいくイメージです。

週	曜日	ミーティング	時間	何をするか
第1週	月	スプリントプランニング	1時間	このスプリントでどんな成果物を作り上げるかを優先度も考えながら決める
第1週	火	デイリーミーティング	15分	簡易的な進捗と困りごとの確認
第1週	水	定例ミーティング	1時間	デイリーで足りなかった進捗と困りごとの確認
第1週	木	デイリーミーティング	15分	簡易的な進捗と困りごとの確認
第1週	金	デイリーミーティング	15分	簡易的な進捗と困りごとの確認
第2週	月	定例ミーティング	1時間	デイリーで足りなかった進捗と困りごとの確認
第2週	火	デイリーミーティング	15分	簡易的な進捗と困りごとの確認
第2週	水	定例ミーティング	1時間	デイリーで足りなかった進捗と困りごとの確認
第2週	木	デイリーミーティング	15分	簡易的な進捗と困りごとの確認
第2週	金	スプリントレビュー	1時間	スプリントゴールの達成状況の確認、振り返り、次のスプリントでの具体的な改善アクションを決定

各スプリントの成果物はPBI（プロダクトバックログアイテム）と呼ばれるもので管理しています。PBIの一例が以下で、担当者と完了の定義、タスク案が記載されているので、実装担当はそれに従って作業を進めます。

成果物はGitHubで管理しており、実装担当がPBI単位でブランチを切って成果物をプッシュします。成果物が完成するとプルリクエストを作成し、プロダクトオーナーのレビューに加え、GitHub Copilotも活用しています。なお、GitHub Copilotの指摘にはばらつきが生じる場合がありますが、見落としの防止に寄与するケースがあります。

以下は、Copilotのレビュー結果の一つで、不要なコードを指摘してくれています。この後、指摘部分のコードを削除して再プッシュを行いました。常に的確な指摘が得られるわけではありませんが、抜け漏れの防止に役立つ場合があるため、用途に応じて活用を検討することをおすすめします。

私たちが開発しているAIエージェントの仕様

私たちが継続的に開発を進めているAIエージェントはAWS上のサーバーレスサービスを利用して動いています。

プロジェクトの初期段階では、AzureやGoogle Cloudも選択肢に挙がっていましたが、チームメンバーがAWSの操作に慣れていたこと、プロジェクトの要件に照らした比較では大きな差は見られなかったことから、クラウドはAWSを選定しました。

そして、費用やセキュリティの観点から極力サーバーレスのサービスを利用しています。以下にシステム構成を示します。

AIエージェントのコア部分については、Agents for Amazon Bedrockの機能であるAction groupを利用しています。Action Groupは、AIエージェントの動作に必要な機能を定義し、これらの機能をAWS Lambdaで複数デプロイを行っています。

デプロイされたこれらのAction groupをAgents for Amazon Bedrockがオーケストレーションすることで、エージェントが外部システムやAWSサービスと連携し、分析に必要な情報をナレッジベースから収集したり、今後の分析改善のために外部システムの情報更新を行ったりします。そして、その結果を人間にとって理解しやすい形にAmazon Bedrockがまとめて出力してくれる、といった動作になります。

また、AIエージェントが誤った分析結果を出力した場合に備えて、オペレーターが分析結果の誤りを指摘できる仕様にしました。指摘をすることでAIエージェントが事象の再分析を行い、再分析結果が新たに出力されます。一方で、分析が正しい場合は承認できる仕様にしています。

上記の図には載っていないですが、チャットツールからのプロンプトインジェクションを防止するための入力検証やポリシー設定、インターネット上からの不正なリクエストやDDoSを防止するためのAWS WAF等を有効化しており、セキュリティについても意識して実装を行いました。

私たちが実装したAIエージェントは状況に応じて以下のように動作します。Agents for Amazon Bedrockが、以下の各ブロックの動作をオーケストレーションします。

また、ナレッジベースの定期的な更新も必要です。更新を行わないといつまでも古い情報が参照されてしまうので、AIエージェント機能とは別に定期的にナレッジベースの更新を行っています。

開発・デプロイ環境について

AWSを触ったことがある方ならご存じだと思いますが、AWSはWeb上でリソースの作成や削除を行うことができます。もちろん上記の構成も全てWeb上でリソース作成してデプロイすることは可能ですが、私たちはIaC（Infrastructure as Code）用ツールである「AWS CDK（AWS Cloud Development Kit）」を使ってAIエージェントのデプロイを行っています。

IaCは名前の通り、インフラ部分をコードとして記載することが可能で、AWSのリソース1つ1つをどのように作成するかをコードで記載します。また、リソースの構築順番についても特に明記しない限り、ツールが自動的に適切な順番でリソースの作成を行ってくれます。

例として、私たちのAIエージェントをIaCでデプロイした後、CloudFormationでスタックを確認すると、約90ものリソースが作成されていることが分かります。（これでも一部ですが）

新機能実装時には、テストのためにリソースの構成の変更や削除が伴うことがありますが、約90ものリソースがあると、リソースの変更を忘れて動かなくなったり、リソースを戻すことを忘れて正常に動作しなくなったり、といったことが考えられます。

一方で、IaCを利用すれば約90ものリソースがコマンド2、3個でデプロイや削除が可能になります。適切に設定を行えば削除時の消し忘れも無くなり、リソースがきれいさっぱり消えます。

また、手動でデプロイを行う場合はデプロイ用の操作マニュアルを用意する必要がありますが、IaCだとコードをgitで管理でき、デプロイ用のコマンドをREADMEに書いておけば良いのも利点だったりします。

このように、AIエージェント開発ではIaCやLambda用のコードを書くことが多いので、GitHub Copilotをチーム内に導入し、実装にも積極的にAIを活用しています。

現状の実装状況

25年度初めにAIエージェント開発を開始し、現在は担当内でPoCができる程度までは実装が進みました。

現状の実装状況を簡単に共有します。

PoCの結果、よく出るアラートについては精度高く分析できていることが確認できました。分析時間についてもアラート発生から10秒程度で分析結果が投稿されるので、商用導入ができれば従来と比較して監視措置業務の大幅な時間短縮になると予想しています。

アラートによっては、かなり精度高く分析されているものもあるので、例えば、監視措置業務の新人であってもAIエージェントを使うことで熟練者並みの速さで関連部へのエスカレーションや修復対応ができるようになると予想しています。

インタラクション機能についても既に利用できる状態になっており、実際にPoCでAIエージェントに再分析を依頼したところ、指摘内容が反映された分析結果が投稿されたことを確認できました。

一方で、年に数回程度しか出ないアラート、すなわちナレッジベースにほとんど存在しないアラートについては、妥当性に欠ける分析結果が表示されるケースが一定数ありました。こちらについては、上記のインタラクション機能を利用して指摘を行うこと、ナレッジベースを継続的にアップデートすることでエージェントの精度を向上したいと考えています。

苦労点や工夫点

私たちのシステムはトラブル時に措置をミスすればお客様に多大な迷惑を掛けてしまうため、AIエージェントの導入にも様々な工夫を行いました。

その中でもAIが誤情報を生成してしまう事象（ハルシネーション）については、発生確率を少しでも下げるために、AIが参照するデータの整備やプロンプトの修正にかなりの時間を費やしました。

しかし、データの整備を行った上で、プロンプトで「情報が見つからない場合は生成しないでください。」と指示しても、ハルシネーションを起こして存在しない情報を生成してしまうことがあり、現在でも継続的にデータの整備やプロンプトの修正を行っています。

（一見、正解に見える誤情報が生成されることもあり、注意が必要です。）

AIエージェント開発の気づきとして、データの整備やプロンプトの修正といった作業が業務へのAI適用において最も手間や時間が掛かる部分だと感じました。

また、AIエージェントが出力した措置手順に従って措置を行い、トラブルが発生してもAIは責任を取ってくれません。現在はPoC段階のAIエージェントも、いずれは本格的に運用業務で利用することになる想定ですが、AIに完全に頼り切るのではなく、AIが生成した誤情報を見破れるようなオペレーターの育成も重要だと考えています。

そのため、私たちの担当では、オペレーターの育成もしっかりと行った上で、運用業務へのAI導入を進めています。