【生成AIによる業務変革LOG #6】

ネットワークAIOpsツール (仮)の開発と
実用化への道

Master'sONE^®というVPNサービスの提供が始まってから15年以上が経過し、ネットワークに対する顧客の利用方法やニーズは大きく変わってきている。
特にコロナ禍でのリモートワークの増加に伴い、大きな変化が見られるようになった。全体トラフィック量は膨大になり、Web会議が日常的に利用されている。また、Microsoft 365などの多セッションを必要とするクラウドサービスの利用が増え、様々なアプリケーションからのアップデート配信が繰り返される中で、毎週月曜日の午前中は高トラフィック状態になる。
Master'sONE^®の代表的なサービスであるSIV-HighSpeedやBBEハイグレードサービスは、ベストエフォート品質での提供ではあるのだが、ネットワークサービスの重要度が増す中で、常に一定の最低品質が求められるようになってきている。

故障申告窓口へ、「つながらない」だけでなく「通信が遅い」といった品質問題に関するお問い合わせが2021年頃から増えている。通信遅延の申告は、ハードウェア故障のように簡単に特定できる問題ではない。お客さま環境やクラウドサービス側の要因も含めて原因が多岐にわたるため事象の切り分けや対処が難しく、そのためマニュアルだけでは解決が難しい。この場合、結果として開発部門（Tier2,Tier3）へのエスカレーションが増加することになる。また原因究明が困難な中でも設備増設や収容変更などで暫定対処を行うものの、その対応稼働もひっ迫しているのが現状だ。

運用担当者（Tier1）はNTTPCのあらゆるサービスに対応する必要があり、サービス毎に異なるシステムや運用手順、仕様書などの煩雑さが大きな課題となっている。その結果、対応品質にばらつきがみられることもあり、対応に時間がかかるなどお客さまへご迷惑をおかけしてしまうケースも出てきてしまっている。
最近は切り分けポイントや判断基準が明確になってきたものの、その切り分け方法やナレッジを浸透させるにはさらなる努力が必要である。

• 対応手順の指南
  AIエージェントに申告内容を入力することで、お客さまへの確認ポイントを明示し、ナレッジやログ情報から問題点や解決策を示唆
• ナレッジの活用
  過去の多くの事例や膨大な運用手順書および技術ドキュメントより、同様の事例や原因となる問題点を類推
• CPEなど設備ログの活用
  バックエンドシステムと連携し、お客さま拠点のCPEや拠点が収容されているバックボーンネットワーク設備のログをリアルタイムで確認し、原因可能性を類推
• エスカレレポートの作製
  Tier3へのエスカレ時には、対応履歴・ログ分析結果を取りまとめたレポートを自動作成
• ナレッジの蓄積と活用
  自動的に対応履歴を作成し、新たなナレッジに保存・学習し、次回の対応精度を向上

PoCでは、AIエージェントとワークフローをAWS EC2上にDifyを使って構築した。またモデルプロバイダーとしてAmazon BedrockのAnthropicを用い、LLMはCalude3.5 Sonnetを利用している。

ツール概念図

生成AIのナレッジ参照には、「Long Context」と「RAG」がある。

• Long Context
  長い文章や文脈全体を一度に読み込み、前後の内容を踏まえて応答や推論を行う手法
• RAG
  文章をチャンク（小さな断片）に分割し、それぞれをベクトル化して応答や推論を行う手法

一般的に、Long Contextの方が前後の内容を踏まえたより自然な応答や推論が可能と言われている。しかし、回答精度のチューニング中に、ナレッジの参照方法としてどちらがより適しているかは、元のナレッジの種類やフォーマットに依存することが分かった。

今回使用した保守対応履歴のように、原因と結果（解決策）が対で記載されているような場合、RAG化することで目標とする回答精度が得られた。一方、サービス仕様書や運用マニュアルのような長文で構成されたナレッジは、Long Contextにした方が精度が高いことがわかった。

このあたりのチューニングはPoCを経たのち、ナレッジを追加更新していく中で、都度検討・確認をしていきたい。

LongContextとRAGの違い

今回PoC用に用意したナレッジには、質問やログ分析に必要な情報が一部不足していた。しかし、AIは非常に気が利くため、自分のパブリックなナレッジから一生懸命データを探して原因を究明し、回答してくれる。

例えば、ネットワーク機器であるCPEのCPU使用率が非常に高い場合、人間の運用者は「CPEの性能を大きく超えるトラフィックやセッションが多い状態」と判断する。しかし、ナレッジである「運用手順書」には、CPU利用率の確認コマンドと表示例は載せていたが、CPU使用率を高める要因についての記載はなかった。そのため、AIは何とか答えようと、ネットワーク機器ではなく「サーバーのCPU使用率が高い場合の原因」を提示した。

しかし、サーバー機器とネットワーク機器とでは原因の種類が違うため、精度チェックとしては「不正」になる。この「気の利かせ」部分を抑制するには少々コツが要る。

指示書で抑制

DifyのAIエージェント設定項目には、オーケストレーション（プロンプト）という「指示書」記載個所がある。
そこに、AIエージェントの役割や、細かい対応指示を記載する。余談だが、ここは英語で書いた方が良く理解してくれる。

Dify オーケストレーション

では、ここに「ナレッジにない回答は答えないでください」と指示したら良いのではないかとなるが、それで100 %抑制できるわけではない。やっぱり多少付け加えてしまう。

回答をテンプレート化指示

当初のフローでは、CPEの各種コマンドを取得・まとめて分析したのちに、AIエージェントに渡していた。これを修正し、CPEの各コマンドに分析結果をつける「回答テンプレート」に添わせる指示をし、それをAIエージェントに渡すようにした。

これでAIの"気の利かせ"はある程度抑制できるようになったが、やはり100 %抑制できるわけではない。
さらにがっちりと指示を書きたくなるところだが、複雑な分岐ロジックをエージェントのオーケストレーションに書くと、AIが判断を間違える懸念が増える。そのためツール（ワークフロー）側でIF/ELSE分岐を入れたり、またワークフロー側にテンプレート指示を入れる、という方法もある。

ここまでくると、ややAI的ではないことに気づくのだが、実装のバランスの塩梅が難しいところである。
しかし、この「余計な部分」こそが生成AIを使うメリットであり、醍醐味だと考えている。そして、いつか人間が気づかないポイントを示唆してくれかもしれない、という思いは過度な期待だろうか。
運用においてどこまで許容できるかは、今後のPoC利用で確認したい。
なお、いうまでもなくナレッジを充実させることが回答精度向上に一番有効である。

エスカレーション、ナレッジ登録時の削除変更

最終的にTier3へのエスカレ時には、対応履歴や取得したログ・分析結果をAIエージェントがまとめてくれる。この場合、前述の余計な文言や、間違い個所は削除や変更ができるようにしている。
下の例では、電源周りの確認依頼に対し「ケーブルに埃が溜まっていてケーブルの確認が困難です」という入力時の回答である。
AIエージェントが丁寧に埃の掃除の仕方を提案してくれていて楽しいかぎりだが、エスカレーション、ナレッジとしてはまあ不要である。

この個所は削除して、レポートを作成、といったことで実のある情報連携、ナレッジ蓄積を可能にしている。

また、内容の追加や、記載内容を変更するなども可能で、このあたりは生成AIならではの機能を活用している。