こんにちは。さとみんです。
re:Inventから帰ってきて約1週間がたちました。
まだまだまとめが追いついていなかったので私が受けたChalk talkの内容をまとめていきたいと思います。
今回選んだchalk talkは「Agentic AI for Autonomous Networks:AgentCore Design Patterns in Action」というものです。
私は金融系の担当のため通信業界には普段関わっていないのですが、他部署が関わっていたりAgentCore関連で今後何か活かせるかもと思い参加してみました。
Chalk talk とは
Chalk talkとは基本的にはスピーカーの話を聞く講義形式のセッションです。ただし少人数のため気になるところはセッション内で手を上げて常に参加者とスピーカーで双方向にやりとりが行われるのも特徴の一つです。
また途中からホワイトボードを利用しての説明も行われ、基本的にYoutubeなどで後日配信もされないので現地ならではのセッションといったイメージを持ちました。
概要
通信業界は2G,3G,4G,5Gとどんどん通信が発達するにあたって、設備とそれらのネットワークを管理するための人的資本に多額の投資を行ってきました。
そこでAIをネットワークに適用し自律的に(ここでいう自律とは人が監視をする必要がないということ)存続できるネットワークを構築していくためにどのような構成をとったのかをBTグループ(British telecomというイギリスのインターネットプロパイダー)の事例を元に紹介してくださるセッションでした。
セッション内容
通信業界や通信業界へのAI導入の課題として以下の点をあげていました。
- 大規模かつ複雑なためトポロジーを最新の状態に保つのが困難
- 同じ故障モードの結果をもたらす可能性のある順列や組み合わせが非常に多いためラベルデータを作成するのが困難
→MLモデルだと故障モードに適したラベルデータが見つからないと実際には対応できないという問題あり(運用部門のようなルールベースのアプローチに等しているという言い方をしていた) - 情報説明する上でのコンテキストの制限
この問題を解決するためにAgentCoreを利用した構成図が以下です。
（画像がガビガビで申し訳ないです。。）
▽作成するエージェント
- SuperVisorエージェント(全体統括的ポジション)
- 各ドメインコミュニティ用のエージェント
- コミュニティ間エージェント
▽利用するツール
- Aurora Posgre MCPサーバ(アラーム蓄積用)
- Neptune MCPサーバ(トポロジーデータベース用)
- KnowledgeBase（NOCやRCAのナレッジベース）
- BTグループのITSMツール
各ドメインコミュニティ用にエージェントを分けるのは、一つのエージェントに処理させる情報量を少なくすることでコンテキストの制限や情報処理の精度をあげるためとのこと。(人間もすべてを知っている人などいないから、それぞれの専門家を作るというイメージでドメイン毎にわける）
また通信業界は各ドメイン同士の相互関係も根本原因を分析するためには大切な要素となるため、そのコミュニティ間を調査するエージェントも別途用意する必要があります。
そしてこれらのエージェントを垂直的・水平的に相関させることで根本原因を見つけるためSuper Visorエージェントとして全体統括的ポジションのエージェントを配置するようです。(垂直相関、水平相関あたりは若干聞き取れなかったのでもし内容不備があったらすみません。。)
またAgentCoreはAgentCoreMemoryにより過去のやりとりなどを保管できるため、複雑で常に最新の情報を保持するのが難しい通信業界としては記憶としてエージェントが過去のやりとりを参照できるのは有効だと述べていました。
後半はこの構成を取ったときの実際にインシデントが起きたとき(アラートを検知したとき)のエージェントの対応フローをホワイトボードで説明されました。
またインシデント対応という観点では今回発表されたDevops agentとSecurity agentなどの活用も考慮に入れていきたいとのコメントもしていました。
感想
Chalk talkとはいえ事例紹介の要素が強いセッションだったのかなと思います。
英語でのセッションとても不安でしたが構成図があるとこういう話かというのが頭に入りやすく万国共通のシステム構成図最高！と感じた一日でした笑
また内容面でいうと今案件でAIエージェント関連にかかわっていますがまだ現状は一つの特定の作業に関してのエージェント化しか考慮していません。ただ今後どんどんAIエージェントで扱う範囲が広がっていった際は今回の事例のように専門家エージェント＋全体統括エージェント（＋専門家エージェント同士の間を埋める必要があればそこを考慮できるエージェントも）といった構成も検討したいと思いました。