re:Invent 2025: Cox CommunicationsのAgentic AIによる自己修復型ケーブルネットワーク構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Transforming Cable Network Reliability with Agentic AI & Graphs (IND3332)
この動画では、Cox CommunicationsがAWSと協力して、リアクティブなトラブルシューティングから自己修復型の自律ネットワークへと変革する取り組みが紹介されています。Service Healthプラットフォームを中心に、Amazon Neptune、OpenSearch、SageMaker、Bedrockなどを活用したデジタルツインの構築、時系列データとトポロジーの統合、Strandsエージェントによる根本原因分析の自動化が解説されます。1日2億トランザクション、5000万イベントを処理し、コール量22%削減、トラックロール10%削減、顧客障害時間48%削減を実現した具体的なアーキテクチャと、Agent Coreを活用した次世代の自律ネットワークへの展望が語られています。データ品質への徹底的な取り組みと、エンジニアリングチームとの密接な協力体制が成功の鍵として強調されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
プレゼンテーション開始：データから行動へ - Coxの自律ネットワーク変革の全体像
皆さん、おはようございます。AWSでは、ネットワーク運用の未来は単にデータを収集することでも、それを分析することでさえもないと考えています。それは、行動するデータについてなのです。本日は、Coxがデータ分析からエージェント型AIへの連続体に沿って、どのようにその旅路を切り開いているか、そして彼らのケーブルネットワークをリアクティブなトラブルシューティングから自己修復型の自律ネットワークへと変革している様子についてお話しします。私はPooja Chikkalaと申します。AWSのSolutions Architectで、Coxのエンドツーエンドの変革に注力しています。それでは、他のプレゼンターの皆さんに自己紹介をお願いします。
こんにちは、Joe Kellerです。Network Analytics and Reliability EnablementのVice Presidentを務めています。Brad Pfaffです。Cox CommunicationsのData ScienceのAVPです。皆さん、こんにちは。Imen Grida Ben Yahiaです。AWSのPrincipal AI Scientistで、ネットワークとAIに取り組んでいます。
それでは、始めさせていただきます。まず最初に、ネットワークとAIのユースケースのためのAWSソリューションフレームワークをご紹介し、その後、自律ネットワークへの旅路とAWS上のソリューション、すなわちService Healthに焦点を当てます。そして最後に、次のステップと、自律ネットワークへの旅路における新しいサービスをどのように評価しているかについてお話しします。
自律ネットワークへの旅路：TM Forumのフレームワークと4つの要件レイヤー
それでは始めましょう。世界中のCSPにとって、すべてが自律ネットワークへの旅路を開始したか、または開始しつつあります。ここで旅路という言葉を強調させてください。すべてのネットワーク運用、キャパシティプランニング、最適化を実現する単一の製品というものは存在しません。これはデータパイプラインであり、旅路なのです。つまり、今始めて、ネットワーク運用を最適化するために導入しようとしているさまざまなユースケースに満足するまで、充実させ続けるということです。
では、通信事業者の自律ネットワークへの旅路とは何でしょうか。これはTM Forumによって異なるフェーズとして構造化されています。それは、異なるネットワークセグメント全体に配置する閾値、ルール、ハードコードされたスクリプトを管理する必要がある手動運用から、最高レベルであるクローズドループベースの運用まで進んでいきます。では、それは何を意味するのでしょうか。それは、あなたのネットワークがデータを感知し、データを理解し、データの上で推論し、そしてPoojaが冒頭で紹介したように、データから行動を起こすことができるということを意味します。
そのために、自律ネットワークのこのハイレベルな説明から、そこに到達するために必要な要件へと私たちを導く要件を紹介したいと思います。基本的に、これはデータ部分から自律実行まで進んでいきます。最初のレイヤーはデータについてです。データはあなたの燃料です。ネットワークからのデータは、例えば、KPI、つまり主要業績評価指標です。それはsyslog、カウンター、さらには異なるネットワークから送られてくるアラームといった手段によるテレメトリであり、また設定ファイルでもあります。ですから、これらすべてを抽出して利用可能にする必要があり、その上でデータの処理、正規化、変換を準備できるようにします。
これらすべては第2のレイヤーで行われます。それがknowledge fabricです。あなたの機械学習、深層学習、分析、そしてエージェントは、聞くための知識を必要とします。彼らはネットワーク運用に必要なインサイトをあなたのために生成できるようにするための知識を必要とします。ですから、knowledge fabricは、生のカウンターから時系列への変換から始まります。時系列は表形式のフォーマットで、そこから予測、異常検知、またはネットワークを監視する際の偏差検知を行うことができます。
また、異なるネットワークノード間の依存関係と時間経過による変化の捕捉にも及びます。これは変更管理に役立ち、根本原因分析に役立ち、サービス影響評価やさまざまなユースケースに役立ちます。また、サービスレベル契約のドキュメント、さまざまなベンダーのドキュメント、アラームの説明、方程式の説明、そしてネットワークドメインに関連するあらゆるドキュメントを用いた埋め込みを持つことについてでもあります。
ですから、knowledge fabricをカバーしたら、楽しい部分が始まります。楽しい部分とは、インテリジェンスで強化していくところです。それはシンプルな分析レイヤーから機械学習と深層学習、そして基盤モデルまで及びます。そして、私がCoxのアプローチで気に入っているのは、彼らが本当にデータ基盤をよく構築しているという点です。つまり、適切なデータフォーマットに対して適切なインテリジェンスを持っており、今ではエージェントによって、ネットワークから活用している空間情報と時間情報の観点で、すべてのデータ基盤が利用可能であるため、適切なエージェントを持つことができるのです。
AWSのサービスとフレームワーク：Amazon Bedrock AgentCoreからグラフ技術まで
では、テレコの自律化の旅から要件まで、サービスの観点で何を提供しているのでしょうか？お客様が自律ネットワークへの旅に進むことを、私たちはどのように可能にしているのでしょうか？
まず第一に、実行について、エージェント的な部分についてです。エージェントについては、まずエージェントを作成する必要があり、エージェントを作成するにはフレームワークが必要です。ここにStrands Agentsがあります。これはオープンソースのフレームワークで、エージェントを作成したり、エージェント間のインタラクションを作成したり、エージェント間の異なるコミュニケーションを可能にするために使用できます。第二の部分はライフサイクルについてです。エージェントはソフトウェアの一部であり、更新、ガバナンス、観察が必要です。これらはすべてAmazon Bedrock AgentCoreを通じて行われます。これについてはプレゼンテーションの最後の部分で触れます。
ここで、私たちのVPが言及した自律的で自動化された推論についての一文を活用させていただきます。私たちは、特に私たちのドメインにおいて、ファウンデーションモデルがネットワークに対して創造的であることを望んでいません。正確で、精密であり、私たちのために正しい設定を生成したり、ネットワークで実行する正しいトラブルシューティングを生成してくれることを望んでいます。これはすべて、現在Amazon Bedrockの一部である自動推論フレームワークを通じて実現されます。最後の部分は、AgentCoreがあらゆるモデルとあらゆるフレームワークに対応しているということを述べるだけです。つまり、私たちはオープンです。オープンソースのフレームワークや、お持ちのカスタムモデルを使用することができ、そしてエージェントの観察性とメンテナンスのためにAgentCoreを活用できます。
次の部分は、目的別に構築されたデータベースについてです。先ほど申し上げたように、データは燃料であり、エージェントや機械学習、ディープラーニングは、すべて皆さんのためにインサイトを構築するためにデータを必要とします。まず、Amazon S3 vectorについてですが、これはネットワークドメインにおける最も一般的なユースケースの一つです。多くのドキュメントがあり、大規模なエージェント的RAGアーキテクチャを採用したい場合です。Amazon S3 vectorはコスト効率が高いことが証明されており、ネットワークからこのドキュメントから情報を抽出することを可能にします。
グラフの部分ですが、グラフと言うとき、単にグラフだけを意味するのではなく、グラフ技術を意味します。グラフ技術は今日のネットワークに非常に適しています。なぜなら、ネットワークは定義上グラフであり、その間の依存関係を捉えたいからです。レガシーなグラフデータベースから、現在私たちが持っている疎結合のグラフ技術への大きな変化があります。永続的なワークロードのためのグラフストレージデータベースとしてAmazon Neptuneがあります。グラフアナリティクスがあり、そこでは異なるグラフアルゴリズムを実行して、グラフの統計を取得したり、例えば最も重要なノードを見つけたり、あるノードから別のノードへの最短経路を見つけたりすることができ、これを異なるネットワーク運用タスクに活用できます。そして、グラフディープラーニングフレームワークがあります。これはオープンソースのフレームワークで、予測、異常検知、そしてネットワークデータに対する様々なディープラーニングに使用できます。
これにより、3つのタイプのインテリジェンスに辿り着きます。これはCoxのアプローチにもあり、JoeとBradが後ほど言及します。彼らはインテリジェンスの異なるレイヤーを持っています。アナリティクスの部分、つまりデータの統計は非常に重要です。データの集約は非常に重要です。アナリティクスの部分をスキップしてエージェント的な部分に進むことはできません。ここでは、インテリジェンスの部分のために、ディープラーニングと機械学習全般のためのAmazon SageMaker、そしてデータベースとアナリティクスエンジンにおけるグラフアナリティクス、さらにSageMakerですでに見つけることができる組み込みアルゴリズムなど、様々なツールを提供しています。
今週発表された最後の部分はカスタマイゼーションについてです。ご存知のように、ネットワークはネットワーク特有の異なる語彙を持つドメインであり、そのため、スケールさせてデータ上にある情報の大部分をキャプチャできるようにするために、現在見られているトレンドとして、モデルのカスタマイゼーションがネットワークドメインにおいて非常に重要になっています。そしてここで、今週発表したばかりなのですが、カスタマイゼーションのためのいくつかのテクニックがあり、これによってより簡単な方法でモデルを特化させることができるようになります。そうすれば、ネットワークで行っているすべてのタスクに対して大きなモデルを使う代わりに、スケールで異なる小さなモデルを持つことができます。
これはグラフの部分を強調するためのものです。なぜなら、これもCoxのアプローチにおいて、私たちが使用してきた最も重要なピースの一つだからです。そしてこれを中心に、もちろん、それと連携する他のすべてのインテリジェンスのテクニックがあります。私たちは自律ネットワークに向けたこのジャーニーを構築するために、さまざまなサービスを使用しています。そしてこれらのデータベース、最初のレイヤーはデータベースレイヤーです。繰り返しになりますが、これはデータに関するものであり、先ほど説明したように、embeddingからトポロジー、そしてネットワークから収集しているイベントまで含まれます。
次に、インテリジェンス部分のためのさまざまなツールがあります。フレームワークとしてのSageMaker、foundation modelsとlarge language modelsのためのフレームワークとしてのBedrock、そしてアナリティクス部分のためのNeptune Analyticsです。それから残りの部分は、先ほど説明したように、実行の自律レイヤーです。説明したように、これはすべてagentic AIに関するもので、これらの異なるレイヤーからインサイトを取得しに行きます。
ネットワーク運用の3つのユースケースカテゴリーとデジタルツインの役割
それで、私たちがやってきたことはケーブルネットワークからモバイルネットワークまで、さまざまな顧客にわたってです。これはradio access network、トランスポート、そしてバックボーンに及びます。さまざまな顧客から常に異なるユースケースが出てきていました。すべてを説明することはしませんが、3つの大きなカテゴリーがあることをお伝えしたいと思います。グリーンの部分はオーケストレーション、ガバナンス、そしてプランニングについてです。このカテゴリーでは、ネットワークで発生しているイベント、例えば深刻なアラームが発生したり、アラームの量からスパイクが来たりすることによってトリガーされるエージェントがあります。これによってオーケストレーターがトリガーされ、ネットワークで何が起こっているかを理解し、ネットワークで何が起こっているかを理解するために他のサブエージェントをトリガーします。
これがグリーンの部分です。そしてグリーンの部分にはガードレールと評価もあります。これは、正しいエージェントをトリガーしていること、このエージェントがこのデータにアクセスする権限を持っていること、そしてトラブルシューティングのためにこれを要求しているユーザーにこれを共有する権限を持っていることを確認するエージェントがあるということを意味します。つまり、これはすべてデータを保護し、情報源にアクセスするための適切な権限を持つ正しいエージェントを確保するためのものです。
ピンクの部分は、さまざまなユースケースに関する専門知識が存在する場所です。オンデマンドのオブザーバビリティは、ネットワークと対話して情報を抽出することがすべてです。トラブルシューティングの場合もあれば、推奨事項のため、またはネットワークの健全性を評価するためのこともあります。つまり、パフォーマンス管理データ、アラームデータ、トポロジーデータ、そしてエンベディングに接続し、それぞれ異なる目的のためにすべてを活用するwhat-ifシナリオなのです。
プロアクティブな方法は、ネットワークで発生するイベントによってトリガーされ、レポートを共有してくれるので、質問する必要がありません。ネットワークがあなたに話しかけ、イベント分析、イベントの優先順位付け、そして何をすべきかの推奨事項を提供してくれるのです。これは、今日モバイルネットワークやケーブルネットワークにおいて、世界中で最も要望が多く、使用されているユースケースの1つです。
2つ目は、根本原因分析またはサービスへの影響についてです。これは依存関係が非常に重要となるwhat-ifシナリオです。依存関係とは、変更管理とサービスへの影響を意味します。障害が発生した場合、ネットワーク上で何が影響を受けたのかを知りたい、あるいは運用中に問題があるが、異なるネットワークセグメント全体で影響が見られる。このような依存関係をどのように把握できるでしょうか?そしてこれも、Journey to Autonomous Networkのケースで見ていきますが、彼らがService Healthプラットフォーム内でデジタルツインの概念をどのように活用していたかということです。
他のユースケースについては詳しく触れませんが、これはネットワークのクローズドループ構成生成とアクティベーションに関するものです。これは、ネットワークの問題から回復する方法、つまり何をすべきかを推奨するだけでなく、例えばネットワークノードや基地局を再起動したり、ネットワークで発生していた輻輳を吸収するために、異なるネットワークノードの容量を再構成したりすることについてです。
黄色の部分は完全に新しいユースケースで、これらはよりアイデア段階にあります。しかし、簡単に説明するとどうなるでしょうか?現在、作業の80%はデータ、つまりネットワークデータの準備です。そのため、お客様からは、何百ものジョブを書く代わりに、生データからトポロジーを推論する方法はないか、と尋ねられています。データエンジニアリングの部分を短縮するにはどうすればよいか、私のデータを理解し、例えば重いXMLから、さまざまな目的に使用できる準備の整った表形式データに適切に準備してくれるエージェントを持つことで実現できないか?あるいは、従来のモデルのための特徴量エンジニアリングをどのように構築できるか?例えば、輻輳の実行において、何百もの特徴量の中から正確な特徴量は何かを知ることができます。
これらすべては、ネットワークにおいてますます多くのAIを活用するための道筋を加速させるためのものです。そしてもちろん、前のスライドでお見せしたように、下部の2つのレイヤー、ネットワークの知識と上部のインテリジェンスがあります。それでは、デジタルツインのコンセプトと、これがチームの皆さんがお見せするService Healthプラットフォームにどのように適合するかに焦点を当てていきます。
デジタルツインの構築：空間・時間データの統合とエージェントアーキテクチャ
まず基本的なところから、定義についてです。デジタルツインはバズワードですね。ここでは、このデジタルツインに何を求めているのか、そしてさまざまなネットワークのユースケースでどのように活用しているのかについて、正確で明確な定義を示しています。これは、ネットワークをリアルタイムでミラーリングするものだと考えてください。空間的および時間的な観点からのデータを統合し、その上にすべてのインサイトを構築できるようにする方法なのです。
つまり基本的には、ネットワークがどのように接続されているかを示すだけでなく、ネットワークノードが時間の経過とともにどのように進化し、互いにどのように影響を与え合っているかを示すものです。そして繰り返しになりますが、グラフとして表現すると言っても、データベースだけを意味するわけではありません。グラフ分析、グラフディープラーニング、そして時系列データや表形式データのための専用データベースとの統合も含まれます。これは非常に重要です。
次のパートでは、デジタルツインをどのように構築するかという可能性のあるフローをお見せします。そして、彼らがどのようにそれを構築しているか、そのアプローチには2つの主要なコンポーネントがあることがわかります。イベントベースの部分と、すべてのテレメトリーを含むグラフ関連の部分です。ここでは、さまざまなステップを順を追って説明します。まず、トポロジーとさまざまなオペレーターからネットワークノードを構築し、発見することから始めます。現在、正確なインベントリを持っていないオペレーターもいるため、これを自動化された方法で構築する方法を考え出す必要があります。それが最初のステップです。
2番目のステップでは、データ品質を向上させる技術を使用します。これにより、このグラフ表現から一部のリンクや情報が欠落しているかどうかを把握できます。そして3番目のステップでは、テレメトリー、アラームなどをすべて統合された表現にまとめ、ネットワークをリアルタイムでミラーリングします。そしてもちろん、これはすべて自動化され、時間の経過とともに維持され、ネットワークの正確な状態を反映します。
ステップ4と5が再び始まります。ステップ3が完了し、ネットワークの連合表現ができたら、そこから様々な機械学習や分析パーツを使って、すべてのインテリジェンスを構築したり、このデータを活用したりできるようになります。ここでは、オプション2について触れておきたいと思います。通常、予測を行うにはモデルをトレーニングする必要があります。私たちは1ヶ月前にChronos 2というモデルを発表しました。これは多変量時系列用のもので、そのまま使って次の値を予測できます。例えば、アラームのスパイクや次の値がどうなるかを予測できます。これもまた、より多くのインテリジェンスを活用し、もちろんそれをエージェントに提供して、様々なユースケースで意味を持たせるための、より簡単な方法です。
このフローの視点から見ると、これをアーキテクチャに落とし込むとこのようになります。このアーキテクチャは非常にハイレベルでデータドリブンなものです。ポインターがないのですが、BedrockとStrandsのエージェント部分を見ていただくと、それらをここのS3バケットにある生データに直接接続することはできません。これらのステップを経る必要があります。魔法はありません。これはデータパイプラインです。エージェントが適切な方法でデータを消費できるように、データを準備する必要があります。
エージェントは定義上、ユースケースが必要とするタスクを実行するための指示、ツール、タスクですが、生データに直接接続することはできません。処理を経て、インテリジェンスで強化したり、一般的にはデータの正規化や変換で強化したりする必要があります。ネットワークの知識ができたら、エージェントでこの情報を活用する準備が整います。これは一例を示すためのものです。
前のスライドをズームインすると、そこにあるStrandsエージェントのアイコンにズームインすると、たくさんあります。たくさんあるということは、ユースケース、タスク、そして一緒に相互作用する必要がある様々なエージェントの構成によって異なるということです。ここで見てきたのは、様々なユースケースから繰り返し出てくるパターンです。トラブルシューティング、レコメンデーション、根本原因分析など、常にオブザーバビリティレイヤーが必要です。オブザーバビリティレイヤーは、エージェントがデータに接続され、これらのサブエージェントを通じて、オンデマンドの集約やオンデマンドのデータ相関によって情報をもたらすものです。
そしてオブザーバビリティレイヤーを通じて、例えば根本原因分析や変更のためにデジタルツインをトリガーすることを決定しますが、常にまずデータの分析に基づいています。これは常にコスト効率のためです。なぜなら、ネットワーク内のデータは膨大で、何百万ものイベントが発生しているため、段階的に異なるインテリジェンスレイヤーをトリガーする前にフィルタリングする方法が必要だからです。そしてもちろん、最後の部分はアクチュエーションに進むところです。
アクチュエーションは、単にシステム上でチケットを作成し、フィールドエンジニアにレポートを生成するといった簡単なものから、先ほど申し上げたように、クラウド化されたネットワークのフルスライスの再構成、あるいはネットワークの変更を行うためのDevOpsパイプラインのトリガーといったものまで、様々です。これらが異なるステップであり、様々なお客様の間で繰り返し登場する最も一般的なエージェントです。
Cox Communicationsの紹介：信頼性重視への転換とデータ活用の歴史
それでは、プレゼンテーションの前半で見てきたことをまとめます。通信事業者の自律型ネットワークへの道のりとは何か？要件とは何か、先ほど申し上げた4つのレイヤー、つまりデータ、ナレッジファブリック、予測インテリジェンス、そして自律的な実行です。サービスとフレームワークとは何か？
そして今度は、Coxがこの自律型ネットワークへの道のりに向けて、これをどのように活用しているかに焦点を当てます。繰り返しになりますが、これは道のりであり、Joeyが参加してくれます。デジタルツインのコンセプトが、今日本番環境で稼働している実装にどのように反映されているかをご覧いただけます。
さて、Imenから、私たちがサービスヘルスエコシステムを実現するためにAWSから活用しているツールボックスについて、素晴らしい背景説明をしていただきました。しかし、その話に入る前に、私たちは誰なのか？Cox Communicationsとは何か？Cox Communicationsは、600万人以上の住宅および法人のお客様に、データ、ビデオ、音声サービスを提供する複合サービス事業者です。これらのサービスは、18万マイルのハイブリッドファイバー同軸ケーブルおよびファイバー・トゥ・ザ・ホームネットワークを通じて提供しており、2万人以上の従業員を擁しています。その2万人のうち、約100人が私のチーム、Network Analytics and Reliability Enablementを構成しています。
Coxでは、現代における最も重要な取り組みの一つは、ネットワークサービスに信頼性を浸透させることだと考えています。私たちにとって大きな焦点となっているのは、そしてこれからもそうであり続けるのは、信頼性です。歴史的に、私たちの業界では、お客様を主要な診断手段として頼りにしてきました。お客様は私たちに電話をかけ、経験している問題、その症状を説明しなければならず、私たちはそれらの問題をトラブルシューティングして解決しなければなりませんでした。
2018年から移行する中で、顧客信頼性に対するそのような時代遅れのアプローチから、私たちはデータの力を活用することに焦点を当て始めました。異なるシステム、プロセス、ポリシー全体で何が起こっているのかを理解し、改善の機会を特定するためです。私たちはトランザクション削減というレンズを通して本当に焦点を当てました。その考え方は、電話やトラックを減らすことができれば、顧客の問題に影響を与えるシステム的な根本原因に効果的に対処できるということです。私たちはBI品質タイプのデータセットを中心にデータ構造化の旅を始めることに本当に注力しました。
そこから2022年、2024年へと移行を始め、私たちが持つこの斬新なサービスヘルスのアプローチに入りました。ここで私たちは本当にアナリティクスの旅に乗り出し始めたのです。私たちの業界で利用可能な膨大なテレメトリーとデータの力を活用して、顧客の問題が発生するのをより良く検知して修正したり、予測して防止したりするためです。最終的に、それが私たちを今いる場所に導きました。データの力を活用して労働力を優先順位付けする信頼性オペレーションに焦点を当てた組織となり、顧客にとって最も影響力のあることに最初に集中できるようになりました。
私たちには約800人の技術者がいて、40,000以上のノードにサービスを提供しています。ノードは約200人の顧客がいる近隣地域のようなものだと考えてください。顧客の信頼性を維持するために、その労働力を効果的に優先順位付けできる必要があります。その労働力の優先順位付けは方程式の大きな部分であり、また、ネットワーク内の関心ポイントを分離できることも重要です。Imenが言及した地理空間コンポーネント、トポロジーと、時系列ベースのテレメトリーを組み合わせて活用します。これについては後ほどもう少し詳しくお話しします。
それが私たちを今いる本当に素晴らしい時代に導きました。エージェンティックAIという概念を持つこの斬新な時代です。そして、私が言うところの野菜を食べたからこそ、データセットを構築し、従来のアナリティクスアプリケーションを確立し始めたからこそ、今やエージェンティックAIの力を活用して、人間には決してできない方法で運用的にスケールできるのです。
Service Healthエコシステム：ネットワーク、ノード、構内の3ドメイン統合
これが私たちのサービスヘルスエコシステムです。2022年から現在まで、そのデータ構造化の旅を通じて築いてきた高レベルの機能です。ここで考えるべき3つのドメインがあります。ネットワークヘルスは、ヘッドエンドより北側のすべてです。ヘッドエンドはすべての信号が集まり、パブリックインターネットに到達し、ファイバーバックボーンにアクセスする場所のようなものだと考えてください。ノードヘルスがあり、これはケーブルモデム終端サーバーから近隣地域へと下流のすべてです。先ほど述べた40,000のノード、ノードあたり約200人の顧客がいる40,000の近隣地域です。それから構内があり、これはタップから家庭までのすべてです。
さて、サービスヘルスは現在、私たちのすべてのオペレーショナルプラットフォームに組み込まれています。これはオフラインの分析機能のようなものではありません。これらはデータサイエンティストと開発者によって構築された分析アプリケーションであり、お客様のご自宅へのトラック派遣を含むセルフサービストラブルシューティングのためのプラットフォームに統合され、トラブルシューティングのためのすべてのエージェントデスクトップを支え、さらに労働力の優先順位付けを可能にし、適切な技術者が適切な場所に適切なタイミングで向かうことを保証しています。
左側のネットワークヘルスから始めますと、私たちはSNMPトラップを通じて収集したすべてのプローブデータを活用して、バックボーン、つまりヘッドエンドより北側のすべてのものに対して持っているトポロジーに集約し、相関付けています。これはおそらく、ここで話しているドメインの中で最も初期段階の形態です。私たちはこの取り組みを始めたばかりです。その多くが2026年の間に実現するはずです。
真ん中のセクションは非常に成熟したノードヘルスです。ここでは、ノード、ラインエクステンダー、アンプ、そしてHFCネットワークで発生するすべてのカスケードに関連するすべての地理空間情報を活用し、時系列ベースのテレメトリーと組み合わせています。それはCPEつまりカスタマープレミス機器、セットトップボックス、ケーブルモデムからのすべてのポールベースデータ、そして私たちが持っているリアルタイムストリーミング、オンラインおよびオフライントラップのすべての情報です。これはデバイスがCMTSへの、つまりヘッドエンドへの接続を失ったときです。そのデバイスがオフラインであることを判断できるトラップを発信します。
これらすべてが集約されて、私たちが「イベント」と呼ぶものの3つの分類を提供します。まず、緊急イベントがあります。これは従来の障害と考えてください。歴史的にはお客様からの電話によって把握されていました。一定期間内に一定数のお客様が電話をかけると障害がトリガーされます。現在では、テレメトリーベースのオンラインオフライントラップと、Bradと彼のチームが構築した素晴らしいモデルがあり、前方誤り訂正やテレメトリー送信および受信電力レベルの問題などに基づいて、差し迫った障害や停止を予測できるようになっています。次に、クリティカルイベントがあります。これは実質的に緊急の繰り返しや障害の繰り返しで、私たちのビジネスプロセスが失敗したシナリオであり、これらの問題に対処するために特別な手段と対応を提供する必要があります。
最後に、障害イベントがあります。障害とは、サービスは動作しているが、途切れたり劣化したりしていると考えてください。速度が遅い、断続的な接続の問題です。障害ノードは私たちにとって本当に大きな焦点であり、お客様がサービスに対して持っているヘルシーミニッツの量に基づいて労働力の優先順位付けを行ってきました。たとえば、特定のノードに対して75%のヘルシーミニッツがある場合、ノードに対して90%のヘルシーミニッツを持つお客様よりもそちらを優先することになります。
最後に、premise healthによって、家庭を認証し、外部プラント保守技術者を必要とする問題と、家庭内技術者が家庭に行って家庭内に存在する障害を修正する必要がある問題とを区別することができます。外部プラント保守技術者は800人で、40,000の異なるノードまたは近隣地域にサービスを提供しています。さて、結果は明白です。コール量が22%削減され、トラックロールが10% 削減され、今年だけでお客様の障害発生時間を半分に削減しました。これにより、agenticの機会に向けて良い準備ができています。なぜなら、これらのデータセットと従来の分析手法に投資する時間を費やしてきたからです。これで、agenticをサポートするために拡張を開始する能力を持つようになりました。
デモンストレーション：40,000ノードを管理するReliabilityビューとデジタルツインUI
それでは、Bradに引き継ぎます。彼がService Healthの内部を少し見せて、私たちが行ってきたことを皆さんに紹介します。ありがとう、Joe。さて、それでは少しデモに入っていきます。 少し背景を説明させてください。Joeが言及したように、ネットワークには約40,000のノードがあり、 これらは大まかに言えば近隣地域で、毎日優先順位をつける必要があります。約800人のフィールド技術者がいます。彼らは私たちのプラント技術者です。彼らはバケットトラックで近隣地域を回り、電柱に登って問題を修正する人たちです。さらに、NOC、スーパーバイザー、フィールドチームのリーダーシップの間に、おそらく200人のサポートスタッフがいます。彼らは、技術者がどこに向かっているのか、そして特定の日に何に集中する必要があるのかを把握する必要があります。
Service Healthのこのビューは、node healthドメインのreliabilityビューと呼んでいるものです。これは40,000のすべてのノードを作業ゾーン別に分類して表示しており、これは技術者をルーティングする方法で、もう少しスーパーバイザー向けのビューです。すべてのチケット発行と優先順位付けはService Healthから自動化されているので、これらの技術者はすでに必要な方向に動いています。しかし、これによりスーパーバイザーとサポートスタッフは、ノード、技術者がいる場所、およびそれらのノードのアクティブな問題を素早く確認できます。したがって、少し上空からの視点やサポートが必要な場合は、ここで得ることができます。
デモを素早くクリックして、何をしているのか説明していきます。左側を見てください、これはノードのリストです。今、リストを素早くスクロールしているところです。緊急ノードでフィルタリングされているので、これらはすべて特定の停止が発生するノードです。ノードをクリックすると、 いくつかの情報が表示されました。そこに技術者の履歴が表示されているのがわかります。最近のチケットと技術者の活動が表示されており、誰がそこにいるかもしれないか、何が起こっているかもしれないかについて、少し文脈を提供しています。それでは、アプリケーションのnode health側の核心部分に入っていきます。これは、 基本的に私たちのノードのデジタルツインを提供するUIです。
ここで一時停止します。そこです、完璧です。デジタルツインとして説明したものについて考えると、デジタルツインには実際に2つの主要なコンポーネントがあります。トポロジーがあります。つまり、ネットワーク内のすべての資産とそれらがどのように接続されているかです。
そして、ネットワーク上を流れるすべてのデータがあります。つまり、これがすべてのネットワークテレメトリです。さらに、この概念にいくつかのものを追加しています。顧客トランザクションは本当に、本当に重要です。これらはもはや私たちの主要なテレメトリソースではありませんが、優先順位付けのための非常に優れた追加価値となります。なぜなら、顧客がそれを感じていて、私たちに知らせてくれている場合、私たちは本当に確実にそれらを優先したいからです。
このUIを見ると、明らかにマップが目立ちます。これが私たちが話していた近隣地域の1つで、これはArizona州Phoenixの近隣地域で、私たちの最大の市場の1つです。左側を見ると、これはすべて時系列データであることがわかります。現在約14日間にズームインしていて、最初の13日間ほどはあまり何も起こっていません。これは素晴らしいことです。これが私たちが見たいものです。つまり、ノードが本当に健全であることを意味します。このビューで何も興味深いものが見られないことが、基本的に目標なのです。
明らかに、最後の数日間で、あのピンクと青の大きなスパイクが見えます。これは、このノードからリアルタイムで送られてくるRFテレメトリです。これは、さまざまなポーリングシステムの集約であり、そのすぐ下にあるのがすべての顧客トランザクションです。つまり、これはCoxの約14の異なる接点の集約です。これらを、私たちのモバイルアプリケーション、ウェブサイト、コールセンター、さまざまな、私たちのWi-Fiアプリケーションと考えてください。顧客が楽しみのためにケーブル会社に電話したい人はいないので、基本的に、彼らがどのプラットフォームでも私たちに連絡してくるときは、私たちにとって興味深いことです。なぜなら、彼らは何かを探しているからです。時系列ビューで、これらすべてが一致していることがわかります。これは、私たちの技術者にとって本当に、本当に強力なことです。
では、少しスクロールさせます。ライブデモが大好きです。追いつくまで待ちます。 そして、それが追いついている間に、もう1つハイライトするのは、私たちのポイント・オブ・インタレスト機能です。マップが再び表示されたら、 もう一度停止しないようにします。そうならないように。しかし、マップ上の黄色のエリアをハイライトしたいと思います。すぐに表示されると、 見えるでしょう。そのノードの上部セクションに、オフラインのポイント・オブ・インタレストである家のグループがあります。
そして、そのデジタルツインの概念について考えると、基本的にそれは、それらの家のモデムからリアルタイムで送られてくるテレメトリが、トポロジーを通じて最小共通祖先に集約されているということです。そして、これらすべてをどのように構築したかのアーキテクチャについては、すぐに説明します。 RFテレメトリが見えます。前方誤り訂正が見えています。これは基本的にパケットがドロップされているということです。今、顧客インタラクションをパンしています。 これは私たちのIVRです。つまり、コールセンターアプリケーションです。
こちらの下の方には、実際のモデム、Joeが話していたオンライン・オフラインのトラップが表示されています。そしてその下には、実際にたくさんのプロセス情報があります。これは異常検知モデルやチケット情報などで、ネットワーク内でアクティブなチケットがある場合は常に、このシステムでリアルタイムに表示され、技術者はドリルインして必要な詳細情報を取得できます。では早送りしましょう。
時系列イベントシステムのアーキテクチャ：OpenSearchとAmazon Neptuneの活用
さて、ここから少し細かい話に入っていきます。これは、おそらくService Healthの中核となる部分の、ハイレベルなアーキテクチャビューと言えるでしょう。これは私たちが行うすべてのことに対する、まさに時系列イベントシステムです。そしてデジタルツインについて考えるとき、それは時系列データとトポロジーデータの両方であることを覚えておいてください。左端を見ていただくと、青いボックスが見えます。少し抽象化されていますが、基本的に私たちはハイブリッドチームなんです。
つまり、私たちはアナリティクス開発者であり、本番アプリケーションを管理しています。Service Healthの場合、ご覧いただいたすべてが本番環境でリアルタイムに稼働しており、毎日24時間高可用性で動いています。しかし同時に私たちはアナリティクスチームでもあるので、エンジニアリングチームと非常に密接に連携しながら、ネットワークの詳細なフォレンジックを行います。そのため、このシステムは本番のユースケースだけでなく、実験したいこと、テストしたいこと、サイドバイサイドで実行したいことにも対応できる必要があります。
そして入力の観点から言うと、あらゆるテレメトリーイベント、あらゆる異常検知モデル、私のチームが同じシステムで追跡したいという理由で作成したいものは何でも、ここで共通のフレームワークを通ってSQSフィードに入り、私たちがイベントと呼ぶものに変換されます。そしてこの場合のイベントとは、基本的に開始時刻と終了時刻を持つ関心のあるパターンと、トポロジーの集約であり、これが鍵となります。下の方を見ていただくと、デジタルツインがある場所が見えます。Amazon Neptuneについて触れておきたいと思いますが、もう少し詳しく説明します。基本的に私たちが作成するイベントは、例えばノードに対する異常検知モデルがあるとします。
異常検知モデルがノードの問題を特定すると、モデルを作成してシステムを通して送信します。システムはフォーマットを標準化し、トポロジーシステムと照合することで、そのノード上のすべての顧客に基づいてエンリッチメントを行います。そして、そのイベントのオープンとクローズをOpenSearchでリアルタイムに管理します。Service Healthにあるほぼすべてのデータは、この標準化を経てOpenSearchデータベースで管理されます。私たちはこのシステムを通じて1日あたり約2億のトランザクションを管理し、このシステムで1日あたり約5,000万のイベントを管理しています。これは本当に働き者のシステムですが、この標準化によって、その上にレイヤーを重ねる素晴らしい機能が得られるのです。
また、右側を見ていただくと、これらの外部アプリケーションがありますが、これらの統合が非常に簡単になります。例えば、私たちはCoxのほぼすべてのタッチポイントに統合されています。このシステムは、障害や問題に関する顧客コミュニケーションも管理しています。そして、新しいユースケースや追加したい新機能がある場合でも、新しい統合ポイントは必要ありません。データモデルは変更されないため、反復、適応、機能追加が非常に簡単なのです。
上部のフローを見ていただくと、このシステムが私たちのチームと会社全体のための分析アセットをすべて生成していることがわかります。いくつかの処理を経て、最終的にはS3バケットに格納され、そこからAthena経由でアクセスできます。そこで多くのデータ品質モニタリングが行われていますが、同時に分析も行っており、UIで見ていただいたすべてのものと管理は、このシステムから直接流れてきています。
では、デジタルツインについてもう少し深く掘り下げてみましょう。さて、ここで魔法が使えればいいのですが、そうはいきません。あらゆるネットワーク、特にケーブルネットワークにおいて、非常に一般的で困難な課題がアセット管理です。Coxも例外ではありません。私たちのドメイン全体で、おそらく30種類ほどの異なるアセットとトポロジーのソースがあります。
ネットワークについて考えてみると、数千万台のデバイス、数十のレイヤー、数百のベンダーがあり、すべてが少しずつ異なる方法で管理されています。これらの機器の中には、30年から40年もネットワークに存在しているものもあり、エンジニアリングチームがどれだけ記録を適切に維持してきたか、あるいは時には自動的に検索可能なものに依存することになります。しかし、その場合はファイアウォールに左右されるため、ここには本当に魔法はありません。このデータは難しいのです。非常に難しいのです。
私たちが差別化できている要因の一つは、私たちのチームがエンジニアリングチームや建設チームと非常に密接に連携している運用モデルであり、データ品質に焦点を当てていることです。つまり、ネットワークが機能しているだけでは十分ではないのです。それは文書化された、機能するネットワークである必要があり、私たちが継承して理解できる方法でシステムにアセットが存在している必要があります。なぜなら、自動化もエージェント型システムも、その他のどんなものも、この問題を解決することはできないからです。
私たちが本質的に行ってきたことは、複数の異なるソースから取得するシステムの標準を定義したということです。かなりの量の変換を行い、その標準を満たしていることを確認するために多くの品質チェックを実施しています。そして、ここでは見えていない部分ですが、Coxには多くのコンプライアンスレポートとデータ品質に関する多くの目標があります。これらはエンジニアリングチームが責任を負うものであり、私たちは堅牢なフィードバックシステムも持っています。トポロジーで何か正しくないものを見つけた場合、それを上流にフラグを立てています。ユーザーにはそれをフラグする機能があり、ソースシステムで修正されるプロセスが動いています。
しかし最終的には、標準形式に処理して、AWS Neptuneで管理しています。私たちは約7年間Neptuneユーザーです。Neptuneでやってはいけないことすべてにおいて専門家であると言えますし、おそらくあらゆる方法で壊してきました。しかし、その領域で成熟すると、本当に素晴らしいシステムになります。
現在、デジタルツインのグラフクラスターで数千万台のデバイスを管理しており、関心地点やクラスタリングのような本当に強力なことができるようになっています。ここで見ていただけるのは、Neptuneデータベースの上にStrandsエージェントを配置していることです。これは私たちにとって少し新しい取り組みです。実際、数ヶ月前にAWSと提携してこれに関するワークショップを行いました。
基本的にこれが行っているのは、既知のデータ品質の問題がある場所を探すことです。孤立したアセットがあります。正しく接続されていないアセットがあり、これらを見つけることができます。なぜなら、ネットワークのこれらのレイヤーが一般的にどのように見えるべきかを知っているからで、これらはそのように見えないものです。このエージェントが行っているのは、そのデータを取得して正しいパターンを探すことです。どのように見えるべきかのルールを与えており、そしてネットワーク内のデータを本質的に修復する方法について推奨を行い、グラフ内に推論されたエッジとしてそれらのエッジを作成しています。
これによりシステムが稼働し続けます。完璧ではないかもしれませんが、ここでは完璧である必要はありません。この場合、接続がないよりも何らかの接続がある方が良いのです。そして、このシステムはすべてLambdaサービスを通じて管理されており、これを理解する必要がある他のアプリケーションにとって、本当に入り口となっています。
では、このLambdaが非常に高いレベルでどのように機能するかというと、私が何かからのリクエストを持ってきた場合、それが分析ユーザーの一人であれ、イベント作成のための別のアプリケーションであれ、どこかのルーターノードであれ、関係なく、ネットワークのどこかの部分であれば、このシステムに跳ね返ります。このシステムは、そのシステムに接続されているすべての下流デバイスと顧客を理解しているので、そのイベントをそういった豊富で詳細な情報で充実させることができます。これにより、他のすべてのテレメトリーと非常に強力な結合や分析を行うことができるんです。もう一つの機能は、何かの影響を受けている顧客がいると想像してください。その顧客についてこのサービスにクエリを投げると、ネットワーク全体を通じて彼らのトポロジーのチェーンを辿っていき、そして他のすべてのイベントや彼らに触れている、または影響を与えている可能性のあるものを非常に迅速に結合できるんです。そして、すべてが標準フォーマットのようなものなので、非常に迅速に本当に強力な相関関係を得ることができます。
さて、これは素早く進めていきますが、Digital Twin Point of Interestです。Point of Interestは見ていただきましたね。これは基本的にクローズドループシステムです。ここにはいくつかの設定可能性がありますが、基本的にはどのイベントが興味深いかをシステムに伝えています。それらのイベントをOpenSearchから取得し、見つけたらすぐに、先ほど言及したトポロジーを通して、私たちが組み立てたカスタムの最小共通祖先技術を使って実行し、そして別のイベントを作成します。ここでの大きなポイントは、イベントのOpenSearch環境から取得し、いくつかの分析を行い、別のイベントを作成するということです、わかりますか？つまり、フローを変更することはありません。ソーシングを続けるのが非常に簡単で、すべてに対して複数のエンドポイントを持つ必要がないんです。
エージェントAntonの実装：Strandsを使った根本原因分析の自動化
では素早く、ボタンを間違えてクリックしてますね、いいですね。さて、素早くエージェント関連のことに入っていきましょう。これは数ヶ月前に始めたことの一つです。私たちはこのような豊富な情報をすべて持っていますが、それでもリサーチが必要な人々にチケットを送っているんですよね？そして、これがエージェント機能が本当に輝く場面なんです。では、皆さんにAntonを紹介したいと思います。これがAntonです。Antonは、私たちのより上級の開発者の一人にちなんで名付けられました。彼は20年間会社にいて、チームの中心的存在ですが、基本的にこれは本番環境のService Healthに直接存在するチャットアシスタントで、すべての技術者がアクセスできます。
そして、Antonが何ができるかを見ると、これは要約プロンプトを実行します。これは単なる事前に用意されたプロンプトです。何でも好きなことを聞くことができます。これは完全に機能するチャットボットですが、この場合は同じノードで、素早くスクロールさせますが、ここで本当に強調したいのは根本原因です。Antonが何をしたかを見ると、彼はOpenSearchのすべてにツールアクセスを持ち、Neptuneのすべてにツールアクセスを持ち、そしてそのすべての豊富なデータにツールアクセスを持っていて、人間なら数時間かかるようなことを本当に素早くまとめることができるんです、チケットやイベントを精査したり、システムにログインしたりすることですね、特にそこの根本原因です。つまり、この故障した顧客のドロップの根本原因は、まさにそこの要素でネットワークに重大な上流ノイズを導入していたということです。問題は最初、マルチブランチコネクタで解決され、ノードの残りの部分に一時的なサービス中断がありました。
これは非常に強力ですよね？基本的に何が起こったかというと、顧客が不良なドロップを持っていて、イングレスがネットワークに入り込み、技術者が現場に出ました。皆さんが見た大きなオフラインのスパイクは、実際には私たちの技術者が問題を修正していたもので、ノードをほんの1分間ダウンさせ、それから元に戻してすべてが修復されました。これは私たちのAI機能の始まりのようなものです。では、どうやってこれを実現したか素早くお見せしましょう。
さて、これに対するハイレベルデザインは比較的シンプルです。皆さんの中には、これを見て「あれ、AgentCoreが見当たらないぞ」と思われている方もいらっしゃるでしょう。その通りです。私たちはAgentCoreが発表される約1ヶ月半前にエージェントの取り組みを始めていました。そして私たちの哲学の一つは、とにかく物事を世に出す必要があるということです。ですから、アーキテクチャを固定して、このまま本番環境に移行し、独自のものを構築することにしました。現在AgentCoreを検討中で、おそらく次の四半期にはこちらに移行する予定ですが、私たちのやり方としては、すべてのエージェントを管理するルーティングLambdaを用意しています。そして基本的にはSQSのバックログがあり、そこにすべての入力トークンリクエストを、それがどのエージェント向けであれ、バックログに送信します。
エージェントはスケールアウトして必要に応じてそれらを処理し、別のSQSを通じて同じルーティングLambdaに送り返します。つまり、このルーティングLambdaは、リクエストを行う誰に対しても、本質的に非同期APIとして機能するわけです。それは別のエージェントかもしれませんし、Service Healthアプリケーションのフロントエンドかもしれませんし、SageMakerのユーザーかもしれません。また、キャッシング用のベクトルストアとしてOpenSearchも配置しています。そして、コアコンポーネントとしてはもちろんStrandsとBedrockを使用しています。それから、今お話しした全アーキテクチャから独立した共通ツールセットがあり、すべてのエージェントからアクセス可能になっています。
Agent Coreへの移行と重要な学び：データ基盤構築の重要性と継続的イノベーション
これはかなり盛りだくさんですね。Agent Coreについてもう少し詳しく聞いていただくことになりますので、Poojaさん、お願いします。洞察に富んだ内容でしたね。それでは、Agent CoreとそれがCoxの自律ネットワークビジョンにどのように適合するかについてお話ししましょう。そうですね、現在、Bradが指摘したように、Strandsを使用してデプロイされたエージェントがあり、Amazon EKS上で動作しています。しかし、セルフヒーリングネットワークの次のレベルに向かうにつれて、エージェントがアクションを推奨するレベル3から、エージェントが検出、診断、修復アクションを行うレベル4、そして最終的にはレベル5へと進むには、より本番環境に適した堅牢なシステムが必要になります。そこで登場するのがAgent Coreです。
Agent CoreはAmazon Bedrockの包括的なエージェントプラットフォームで、本番環境でエージェントを大規模にデプロイすることができます。ランタイム、メモリ、アイデンティティ、ゲートウェイなどのモジュラーコンポーネントを備えており、新たに発表されたAgent Core evaluationsもあります。しかし今日は、ゲートウェイ、メモリ、オブザーバビリティにのみ焦点を当てます。それでは、Agent Core Gatewayについてお話ししましょう。現在、エージェントはトポロジー用のNeptuneやイベント用のOpenSearchなど、さまざまなツールにアクセスしていますが、これらの統合はそれぞれカスタムで構築されています。Agent Core Gatewayはこれを変革します。Model Context ProtocolまたはMCPを使用した標準化された通信プラットフォームを提供し、新しい機能の追加が単なるプラグアンドプレイになります。
自動修復ツールを追加したいですか?Agent Core Gatewayに登録するだけです。セルフヒーリングスマートアンプリファイアワークフローを追加したいですか?同じです、登録すれば完了です。コード変更は不要です。エージェントがこれらのツールにアクセスするために使用する一貫したAPIがあります。次にAgent Core Memoryについてです。そして、現在の単独のインシデントに対して孤立して作業している現在のエージェントを、時間とともに学習し改善できるインテリジェントなシステムにどのように変革できるかについてです。
現在、これらのStrandsエージェントは、トラブルシューティングを行っているインシデントについてある程度のコンテキストを持っていますが、基本的にはその問題に対して独立して作業しています。Agent Core Memoryは2つのコンポーネント、短期記憶と長期記憶をもたらします。これはちょうど人間の記憶と同じですよね。短期記憶は現在のコンテキスト、つまり目の前のインシデント、確認しているテレメトリの読み取り値、すでに実行されたアクションを提供します。これによりエージェントは現在のインシデントに集中できます。
しかし、本当の変革がもたらされるのは長期記憶からです。なぜなら、今や組織的な知識を持つことができるからです。各エージェントは、このノードで過去に何が起こったか、どのようなアクションが取られたか、どの解決策が効果的だったか、特定のタイプの問題に最も適した専門技術者は誰かといった洞察を持つこのシステムにアクセスできます。これは、各エージェントが毎回20年のベテラン経験を手元に持っているようなものだと考えてください。このメモリアーキテクチャは継続的な改善をもたらします。すべての問題がエージェントをより賢くします。すべての解決策がナレッジベースに追加されます。
そして最後に、Agent Core Observabilityについてです。高度に自律的なネットワークに向かって進む中で、エージェントが何をしているかの可視性がより重要になってきます。
そしてAgent Core Observabilityは、さまざまなレベルでその可視性を提供します。エージェントレベルでは、これらのエージェントが何をしているか、どれだけのコストがかかっているか、何トークン使用しているかをトレースでき、それによってパフォーマンスを最適化し、コストを管理できます。ワークフローレベルでは、スーパーバイザーエージェントがこれらの専門エージェントをどのように呼び出しているか、その推論プロセスは何か、どのツールを起動しているかをトレースでき、そしてこれをカスタム影響メトリクス、トラックロード削減、サービス信頼性向上といったビジネス成果と関連付けることができます。これにより、ビジネスインパクトに直接結びつけることができます。
Observabilityにより、エージェントが正しい意思決定を行っていることを証明し、エージェントがより良いツールやトレーニングを必要としているタイミングを特定し、それをビジネスインパクトに結びつけてビジネスステークホルダーに価値を示すことができます。さて、これでAgent Coreが次のレベルの自己修復型自律ネットワークへの旅に私たちをどのように導くかについてお話ししました。私たちはこの旅を通じてCoxと非常に緊密に協力してきました。そしてAWSは、Coxがネットワーク運用の未来において可能なことの境界を押し広げ続ける中で、さらなる協力を約束します。それでは、重要なポイントについてJoeに引き継ぎます。
ありがとうございます。さて、ワクワクする内容ですよね？それでは、私たちの旅路で学んだいくつかのことをお話しします。Bradが言ったように、近道はありません。ですから、これらの結果の多くは、地道な作業の積み重ね、つまり基礎をしっかり固めること、データセットの構築、アナリティクスアプリケーションがどのように機能するかを理解するための投資、パートナーシップ、そして組織的な課題への取り組みの結果なのです。繰り返しになりますが、コールの22%削減、トラックロールの10%削減、そして障害が発生した顧客時間の48%削減、つまり半減です。私たちにとって本当に素晴らしい成果です。
ここからが、皆さんに自社や雇用主に持ち帰っていただきたい重要なポイントです。データがすべてです。ここからそこへ行くのに近道はありません。スタート地点を飛ばしてAIに直行することはできません。高速データに取り組み、高品質を理解するために時間をかける必要があります。Bradは、私たちが導入した多くの測定システム、運用プラットフォームに組み込まれたインラインアナリティクスアプリケーションについて触れました。そして、ネットワークのパフォーマンスを理解するために構築する可観測性を持ち、それらの構造を継続的に革新し改善していくことができるのです。
意図的なイノベーションは、私たちが大切にしているものです。私たちは組織内でスタートアップのメンタリティを持っていると考えています。繰り返しになりますが、障壁を打ち破り、エンジニアリングパートナー、外部プラント保守チーム、ホームテクニシャン、ネットワークオペレーションテクニシャン、そしてエンジニアリングチームとワンチームのメンタリティを持つことです。先ほど申し上げたように、意図的なイノベーションとは、データサイエンティストと開発者が、エンジニアリングの専門家や外部プラント保守の専門家と肩を並べて、文字通り隣り合わせで働くことを意味します。そして、私たちの統一された目標の力です。私が述べた、私たちの時代の最も重要な課題だと信じているもの、それは信頼性です。
私たちのすべてのチームは、毎日信頼性ダッシュボードを監視しています。週に一度、これらの組織全体で集まり、ネットワークのパフォーマンスを評価し、改善の機会を特定し始めます。OFDMAやOFDMのような新しい斬新なアプローチをエンジニアリングと試行し、より良く、より違ったやり方ができることを検討します。そして最後に、採用して実行することです。Bradが言及しました。Agent Coreは、私たちが始める必要があったときにまだ準備ができていませんでした。そこで私たちは決断を下し、前進して新しい領域、新しい地平を切り開き始めました。そして私たちが発見している多くのことを、今ではAWSとパートナーシップを組んで、彼らと継続的にイノベーションを起こす方法を理解し、私たちのニーズという観点で持っているものを理解し、将来のロードマップについて彼らと協力しています。
最後に申し上げたいのは、変化に対応できる構築です。今年の大きなテーマは、適応、適応性でした。ですから、私たちが行うすべてのことは変化を念頭に置いて構築されており、方向転換できる能力を持っています。Bradが述べたように、私たちは新しいデータセットを導入し、新しいイベントを作成し、それらのイベントを評価し、顧客体験と信頼性の向上に向けて継続的に反復できるフレームワークを作成しました。それでは、以上で終わります。もし皆さんが興味を持たれて質問がある場合は、廊下で私たちに会いに来てください。喜んで皆さんの質問にお答えし、オフラインで少しお話しさせていただきます。どうもありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion