re:Invent 2025: EricssonのAI活用によるモバイルネットワーク最適化と開発体験変革
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Ericsson Innovation: Optimizing Mobile Networks & Unified Development with AWS
この動画では、EricssonがAWSのAIスタックを活用してモバイルネットワークの最適化と社内開発体験の変革を実現している事例が紹介されています。EricssonのCognitive Network Solutionsチームは、従来のML推論とマルチエージェントソリューションを組み合わせ、Amazon SageMakerとAmazon Bedrock Agent Coreを活用してCSPのネットワークパフォーマンスを最適化しています。強化学習エージェントであるcell shapersがネットワークのデジタルツインを構築し、カバレッジ、キャパシティ、品質を継続的に最適化します。System Comprehension Labでは、数万人の開発者が持つ膨大な社内ドキュメントとデータ資産をAIで活用し、複雑なシステムエンジニアリングにおける理解力の限界を克服しています。MCPを通じた統合、カスタム大規模言語モデルのトレーニング、observabilityとidentity管理を含む包括的なアーキテクチャにより、エンタープライズスケールでのagentic AIの実装を実現しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
AWS と Ericsson による通信事業者向け AI 活用の全体像
おはようございます。皆さん、聞こえていますか？本日はお越しいただきありがとうございます。私の名前は Christian Finelli で、AWS の Telco Business unit のシニアソリューションズアーキテクトです。本日は、Ericsson が AWS 上の AI を活用して社内開発体験をどのように変革しているかについて学びます。Bastian と Doug が次のセッションでそれについてお話しします。Ibrahim と私は、Ericsson が AWS 上の AI を活用して顧客のモバイルネットワーク体験をどのように最適化しているかについてご説明します。
AWS は Communications Service Provider と協力して、収益を増加させ、コストを最適化し、顧客チャーンを削減するというビジネス目標を達成しています。 CSP は複雑な BSS および OSS システムを AWS に移行・最新化しています。これにより、市場投入までの時間を短縮し、製品の俊敏性を向上させています。同時に、複雑な IT ワークロードを AWS に移行して、AI オートメーションを通じて運用効率を向上させています。CSP はまた、AWS 上でネットワーク機能を移行・仮想化して、弾力性、スケーラビリティ、および AWS のディザスタリカバリーオプションを通じたビジネス継続性を向上させています。
CSP は顧客データから始まり、顧客行動をモデル化し、パーソナライズされた顧客体験を提供することで、顧客体験を変革しています。AWS と CSP は協力して、接続性を超えた新しいビジネスを構築し、既存のネットワーク投資を保護・収益化しています。彼らは Software as a Service などの新しいビジネスモデルを探索しており、これにより新しい価格設定構造を探索するオプションが得られ、製品ラインの俊敏性が向上します。AI はこれらすべての領域における重要な要素であり、主要な AWS パートナーである Ericsson がこれらのイニシアティブをグローバルにスケールするのに最適な立場にあることが見えています。
エージェンティック AI ソリューション成功のための重要要素
Ericsson は AI と ML を活用してビジネスと製品ラインを変革しています。彼らがそれをどのように実現しているかについて、いくつかの例をご紹介します。彼らは複雑なソフトウェアスタックをフィールドに統合するためにエージェントを活用して、製品配信時間を短縮しています。彼らは従来の ML とエージェンティック AI ソリューションの組み合わせを活用して、顧客である CSP のモバイルネットワークパフォーマンスを最適化しています。また、内部チームによって実装される新機能を市場に投入するまでの時間を短縮するために、MLOps プラットフォームを構築して ML テクノロジーの採用を加速させ、大規模なソフトウェア開発者ベースに力を与えて、彼らの効率を向上させ、より良い製品を構築できるようにしています。
私たちは Ericsson と密接に協力しており、成功するエージェンティック AI ソリューションを構築することが何を意味するかについて、第一線の経験を持っています。これは単に LLM を特定して選択したり、エージェンティック SDK を採用したりするだけではありません。エージェンティック AI ソリューションを支える AI スタック全体、その精度と経済的実行可能性を含めて、その成功のための重要な要素です。 私たちが特定した領域がいくつかあります。私たちは、ビジネスがエージェントとこれらのエージェントの出力を信頼できなければならないという事実から始めます。これは、最も基本的なレベルで認可されたデータと知識へのアクセスを意味します。同時に、従来の機械学習トレーニングでは、データ系統がデータの出所を追跡し、データソブリンティ要件を満たす上で重要な役割を果たしていることに注意することが重要です。
信頼というのは説明可能性から生まれます。エージェントがどのように振る舞うのか、どのような判断を下すのか、推論プロセスがどうなっているのか、そしてどのようなツールを呼び出しているのか、またそのパフォーマンスがどうなのかを把握し、分析できることが重要です。次のステップとしては、コンテキストが王様です。知識とデータが適切なタイミングで適切なエージェントに簡潔に届けられる方法が重要です。なぜなら、データサイズはコストに直結するからです。これが成功のための別の重要な要素です。
複数のエージェントが組み合わさって動作するマルチエージェンティックなソリューションでは、各エージェントがもたらす価値を明確にすることが重要です。価値というのは、マルチエージェンティックソリューション全体の成果を意味しています。その価値は異なるエージェント間で分散されており、各エージェントがもたらす価値とコストを把握することで、各エージェントのROIを原子的に決定することができます。これは運用上の卓越性の基盤となる説明可能性と可観測性に関わってきます。
これらのエージェントのパフォーマンスをエンドツーエンドで理解し、監視できることが不可欠です。また、それらを運用できることも重要です。エージェントと言う時、それは単なる運用だけではなく、LLM オペレーションや ML オペレーションを含む基盤となる AI スタック全体が含まれます。AI SDC 機能を通じてこれらの運用を効率的に実行できることが極めて重要です。Ibrahim、顧客にとって説明可能性がなぜ重要なのかについて、お話しいただけますか。
説明可能性と可観測性を実現する AWS AI スタック
ありがとうございます、Christian。Agentic AI に携わる人々と密接に仕事をしている中で、私たちが理解していることは、エージェントはテクノロジーのデプロイメントだけではないということです。CSP、つまりサービスプロバイダーが Ericsson からエージェントを調達する場合、そのエージェントから出てくる成果を信頼しています。彼らは国家インフラのネットワーク運用を Ericsson のような企業にアウトソースしているわけです。彼らにとって極めて重要なのは、エージェントがなぜそのような決定を下したのか、ワークフローがなぜそのように設計されているのか、どのようなツールが使われているのか、そしてなぜこれらのツールが通信などの国家インフラに変更を実装するためにそのような決定を下しているのかについて、スタック全体における説明可能性を持つことです。
説明可能性は極めて重要であり、AWS が提供するスタックは、CSP に対してこの説明可能性を実現するためのツールと機能を提供してくれます。説明可能性と可観測性は重要ですよね、Christian？
本当にありがとうございます、Ibrahim。observability というのは、Ibrahim が言ったように、agentic AI レイヤーだけでなく、AI スタック全体にわたっています。Ericsson は AWS AI スタックのさまざまなサービスを活用しています。これから 2 つのユースケースを見ていきますが、それぞれ異なるビジネスケースに対応した複数のペルソナをカバーしています。
スタックの一番下のレイヤーでは、データサイエンティストが AI compute を使ってトレーニングジョブを実行し、GPU から Amazon チップまで、推論用にモデルをホストしています。Amazon SageMaker はデータサイエンティストが ML モデルの MLOps 全体を実行するために使用されており、データの準備、モデルのトレーニング、モデルのライフサイクル全体を通じた継続的な評価、推論用のモデルホスティング、そしてモデルパフォーマンスの監視が含まれています。スタックを上に進むと、エンジニアと開発者が Amazon Bedrock を使用して、エージェントを本番環境でスケーラブルかつセキュアに実行しています。これにより、モデルと基盤モデルの選択肢が得られ、それをスケーラブルかつセキュアに実行する機能が提供されます。
Agentic SDLC アプリケーションは開発者によって活用され、コーディング、ソフトウェア開発、運用全体を通じた効率性を向上させています。
Ericsson の社会的影響力と 2 つのユースケース
本日は、Ericsson の 2 つのチームが舞台に上がって、これら 2 つのユースケースについて直接お話しします。1 つ目は Cognitive Network Solutions、つまり CNS です。彼らは従来の ML 推論とマルチエージェントソリューションの組み合わせを活用して、CSP のモバイルネットワークパフォーマンスを最適化しています。2 つ目は System Comprehension Lab で、Ericsson のエンジニアが AI を通じてより良い製品を構築できるようにしています。では Ibrahim、ステージをお譲りします。ありがとうございました、Christian。
Agentic AI を構築する上での私たちのパートナーシップの旅についてお話しします。その前に、Ericsson が何を大切にしているのか、私たちのミッションは何なのか、そして社会にどのような影響を与えているのかを理解していただきたいと思います。今日、5G ネットワークは約 340 あり、そのうち 189 が実際に Ericsson のイノベーションを使って運用されています。これは世界中の 5G ネットワークの 50% 以上であり、中国以外の世界中の 5G トラフィックの 50% 以上が私たちの機器で運用されています。
ここはベガスですが、AT&T、Verizon、T-Mobile のいずれかのモバイルサービスを使用している場合、100% の確率で Ericsson のイノベーションを使用しています。CSP は Ericsson のイノベーションを活用してサービスを提供しています。これが私たちが社会に与えている影響です。これが私たちが世界にもたらしている影響です。これらのサービスが最高レベルで提供されることを確保するために、私たちは 150 年にわたるイノベーションの歴史を持っています。最も明らかなのは、モバイルテクノロジーにおいて私たちがもたらす特許の数です。60,000 件以上の特許があります。
このようなテクノロジーとイノベーションが価値を提供していることを実際に証明しているのは、Ericsson の機器を使用している場合、世界中の CSP の 74% 以上が市場での競争相手と比較してベンチマークされたときに常に最初に来るということです。Ericsson にとって、社会への影響、パフォーマンスとイノベーションの面で CSP にもたらすものが最高レベルであることを確保することは非常に重要です。だからこそ、AWS のようなパートナーと協力して、そのような価値を提供することが重要なのです。そして AI は、私たちが顧客に提供する変革の中核です。
Autonomous Networks と認知ループによるネットワーク運用の変革
私たちはモバイルテクノロジーのスタックのさまざまな部分と、AI を使用したネットワーク運用全体にわたってポートフォリオを変革するために取り組みました。私たち自身の専門知識を活用し、自社の専門知識をシフトさせて、社内の人々が AI を使用して顧客に新しい価値を提供できるようにしました。また、人々のマインドセットをシフトさせ、各オファリングで AI を提供することが何を意味するのかを理解することに取り組みました。私たちは、今日見ている AI トラフィックと将来の成長に対応するためにネットワークを構築しました。また、ネットワーク運用全体とスタック全体で AI を使用しており、これについては少し後で説明します。
私たちはこれをモバイルイノベーションが CSP にどのように提供されるか、そしてこれらのネットワークをどのように運用するかというポートフォリオで提供しています。これは autonomous networks について私たちが話すフレームワークです。
Autonomous networks は、ネットワークを今日と将来どのように運用するかについて TMF によって定義されたフレームワークです。実際には、スライドに表示されている 5 つの異なるレベルにわたっています。ここで皆さんの注意を引きたいのは、下のグラフです。今日、レベル 3 またはレベル 3 を超えるレベルにかろうじて到達している CSP の割合は 10% 未満です。
レベル 3 プラスへの移行は、ネットワーク運用システムに AI を統合し始めるときに発生します。コミュニティまたはここ CSP でより高いレベルのネットワーク自律性に到達し、レベル 4 に到達することについて聞くかもしれません。ネットワークを運用する方法に AI を組み込まなければ、レベル 4 に到達することはできません。だからこそ、autonomous networks は CSP にもたらすべき非常に重要なフレームワークなのです。
私たちは Telco AI ポートフォリオを通じて、これを実現しています。それは認知ループと呼ばれるもので、ネットワーク運用のための5段階のワークフローです。まず測定から始まります。ここでは測定エージェントがネットワークデータを理解し、次のステップである保証段階に進むために必要な情報をキャプチャしていることを確認します。保証段階では、分類器やroot cause analyzerのようなエージェントを持っており、これらはネットワークで何が起きているのか、どのような異常が存在するのか、そしてそれらの異常の根本原因が何であるかを教えてくれます。
その後、提案段階に進みます。ここでは AI recommender システムと推奨ツールを備えた AI エージェントが次のベストアクションを提案します。しかし、ネットワークは複雑なので、最良の決定が実際にネットワークに実装される最終的なものであることを確認するための評価ステップがあります。これは各国の国家インフラストラクチャです。評価の後、実行とアクティベーションが発生し、サイクルが続きます。これが私たちが認知ループと呼んでいるものです。
マルチエージェント AI アーキテクチャと強化学習エージェント「cell shapers」
Agentic AI フレームワークと agentic AI ファブリックは、認知ループ全体に実装されており、異なる特化したエージェントを通じてエンドツーエンドで機能することを確保しています。これらのエージェントは特定のワークフローに特化しており、トラフィックが毎日、毎時間シフトして変化するときにネットワークからランタイムコンテキストを受け取ります。これを実現するために、私たちはオープン性と水平化を信じています。 AWS と一緒に構築したアーキテクチャは、これら2つの主要な目的を包含しています。オープン性と、データをどのように取得し、異なる AWS サービスを通じてそれを上位層のエージェントに公開するかです。
これらのサービスはエージェントに異なる機能を提供します。例えば、私たちはエージェント用のツールを活用しており、これはネットワークで何が起きているのかを理解し、これらのネットワークに変更を実行する機能をエージェントに提供する方法です。Observability は非常に重要であり、AWS からのスタック内の異なるサービスと共にあります。すべてはラジオアクセスネットワークから大量のデータを取り込むことから始まります。 下部には ETL レイヤーがあり、これは serverless サービス、コンテナ、および Athena や Glue のような AWS の完全マネージドサービスを含む AWS サービス上で実行されます。
これはラジオアクセスネットワークから来るデータを処理し、ML パイプラインによって消費されるように準備します。Amazon SageMaker は ML パイプラインが構築される場所であり、ここでデータが準備され、モデルが訓練され、モデルが評価され、その後推論のためにホストされます。ポイント推論はその後、私たちのアプリケーションによって呼び出されます。これらはML駆動型のアプリケーションであり、ネットワークパフォーマンスに関する予測を消費します。これらのアプリケーションは関連するエージェントのコンテキストに貢献します。
エージェント自体は、RAG技術を通じて他のデータソースとナレッジベースにも依存しており、これには製品ガイド、ネットワーク構成、自然なデータ構造、および異なるネットワークパラメータ間の相関関係が含まれています。その後、エージェントは私たちのアプリケーションを呼び出して、この予測を消費し、情報を取得することができます。
Amazon Bedrock Agent Coreは、その後、メモリと可観測性のような機能をEricsson に提供し、これらの機能をAWSマネージドサービスにオフロードします。本質的には、フルスタック全体が役割を果たしており、SageMakerは機械学習とエージェントを通じて正確な予測を生成し、Agent Coreはエージェントの完全なライフサイクルを管理します。
これらのエージェントに提供するツールに戻ると、基本的には、ネットワーク上で何が起こっているかについての予測と理解を提供できる私たちのラジオアプリケーションです。一つの例は、私たちが「cell shapers」と呼ぶもので、これはネットワークのデジタルツイン表現を持つ強化学習エージェントです。ネットワークがラジオの観点からどのように構築されているかに詳しい人にとっては、ネットワークは初期の時代から、特定のカバレッジエリアを持つアンテナで設計されてきました。エンジニアが解決しようとする最初の問題は、カバレッジと品質をどのように最適化するかということです。これは2G、3G、4G、5Gから始まり、6Gでも見られる、複数世代にわたる問題です。
このネットワークで最適なカバレッジ、キャパシティ、品質を確保するにはどうすればよいでしょうか。業界の典型的なアプローチは、デプロイ前と信号が空中に出る前にシミュレーションを行うことでした。強化学習エージェント、つまりAWSスタック上のエージェント用に提供するツールを使って、私たちが行うことは、ライブトラフィックに基づいてラジオ環境を再構築し、ネットワークで何が起こっているかから常に学習することです。この学習は、マルチオブジェクティブ強化学習アルゴリズムを通じて行われ、異なるレイヤーのカバレッジ、キャパシティ、品質の間で常に最適なトレードオフを提供していることを確認します。
エージェントはトラフィックが変わり、異なる側面がそれに影響を与えるにつれて、常にネットワークから学習しています。例えば、新しいスペクトラムの導入、サイトの高密度化、またはcloud RANや5G上の6Gのような新しいテクノロジーの追加などです。これらのcell shapersは、私たちが「proposed stage」と呼ぶコグニティブループの一部に属しており、AWSのようなスタックでこのような自律性を実現するのに役立ちます。これらは私たちが使用する唯一のエージェントではありません。私たちが開発し、現在AWSと協力して、ユーザーエクスペリエンスを向上させ、ネットワーク運用を改善し、ネットワーク運用の効率を向上させるために、スタックのさまざまな部分に導入するために取り組んでいるエージェントの種類についてさらに詳しく説明しました。
System Comprehension Lab：複雑なシステムエンジニアリングにおける理解力の限界への挑戦
ここに見えている数字は、実験室の結果ではありません。実は、これらのエージェントの実際の現場配置から得られたデータなんです。私たちは、Ericsson テクノロジーを通じてもたらす影響を測定し、社会に対する私たちの影響がいかに深刻であるかを理解することができます。ここで同僚の Dag に、私たちがどのようにそれを構築しているかについて説明してもらいたいと思います。 私たちがどのように運用しているかについて少しお話ししましたので、Dag が私たちがそれをどのように構築しているかについて説明することができます。
では、少し立ち戻ってみましょう。ネットワークにはたくさんの AI アプリケーションがあり、私が話したものです。しかし、実際のインテリジェンスはどこから来るのでしょうか？それは一部、ネットワークを観察し、制御関数理論を適用することから来ていますが、また同時に、私たちが 40 年間にわたってモバイルネットワークインフラストラクチャを構築してきたという事実からも来ています。インテリジェント・ネットワークについて話すのであれば、これの多くは実際に、私たちが制度的に持っている知識、私たちが持っている人材、そして私たちが会社内に持っているデータ資産を表現することについてなのです。これが、System Comprehension Lab と呼ばれるものを作成した理由です。これにはいくつかの異なる目的があります。
特に米国の大きな国全体にわたるモバイルネットワークは、驚くほど複雑で、非常に複雑な分散システムを表しています。それらは配置と管理の両方の観点で複雑ですが、Abraham が議論したように、設計の観点でも非常に複雑です。私たちは、さまざまな種類のラジオ製品を持っています。2G、3G、4G、5G、そして 6G が共存しています。これらのネットワークを運用および構成するために設定されている数百万の構成があります。
私たちの AI への取り組みは数年前に AWS との協力を始めたときに始まり、それは Ericsson にとって、そして私たちの顧客にとって AI で興味深い問題を本当に解決するためには、現実の世界にこの膨大なシステムの複雑性があることを認識する必要があるという概念から始まりました。これは実は特に Ericsson 固有の問題ではなく、テレコム固有の問題でもないと言えます。航空機や原子力発電所、またはそのような性質のものを設計している場合、あなたは膨大なシステムの複雑性に対処しており、AI はどういうわけかあなたを助ける必要があります。
そこで、私たちにとって根本的な質問に到達します。 私たちは理解力に制限されているのでしょうか？実は、この時点ではそれは質問ですらありません。私たちは理解力に制限されています。ここで「私たち」と言うとき、私は分散システムの領域で働いている数万人の人々で構成される Ericsson の R&D を意味しています。6G を構築したり、次世代の 5G を構築したりすることについて考えるとき、私たちはプロジェクト実行の従来の 3 つの柱、つまりコスト、スコープ、時間によって制限されているのでしょうか、それとも実際に、私たちはおそらく、関係する人間が実際にこれらのプロセスに適用できる理解の量によってより制限されていると言えるのでしょうか？
私は自分たちのことについて過度に自己批判的になるつもりはありません。Abraham が言ったように、世界の 5G トラフィックの半分が私たちの製品を通じて流れているので、私たちは良い仕事をしています。しかし、それでも、モバイルネットワークインフラストラクチャを開発する人間として、私たちはおそらく理解力に制限されていると言えます。ですから、私たちの AI ミッションはこうです：複雑なシステムエンジニアリングの限界の中で、AI を実際にどのように機能させることができるか、ということです。繰り返しになりますが、telecom、nuclear power、aircraft、cars、あるいは何を考えるにしても、それは関係ありません。
私たちにとって、System Comprehension Lab は、社内に何百万もの文書があるという点から始まります。私たちは AI なしで 30 年から 40 年間、同じことをやってきました。ですから、私たちの最初のミッションは、すべてのデータと社内のデータ資産を活用して、モバイルネットワークの設計をより良くすることです。もし私たちがそれをうまくやり、Amazon Web Services、Bedrock などを使ってそれを行えば、少し後でお話しします。私たちは、モバイルネットワークがどのように構築されるかについての制度的知識とインテリジェンスの基盤を築きます。
その上に、Abraham が話していたような種類のデータを層状に重ねることができます。それは、実際に外部のライブネットワークで何が起こっているかの膨大なデータストリームを見るときです。私たちはそれが何を意味するのかを説明でき、それに対して行動でき、そしてそのデータフローにインテリジェンスを統合することができます。そうすることで、私たちの製品が人間の意図をどのように理解させるかについて考えるための基礎が築かれます。それは、私たちが制度的知識を統合しているという事実から導き出されるもので、私たちの製品の設計をより良くします。その後、実際のネットワークテレメトリーを上に層状に重ねています。
また、ここで言及したいのは、世界中に本当に断絡があるということです。 私たちは皆、frontier AI capabilities が多くの注目を集めている情報フローの一部だと思います。例えば、competition-level programming、competition physics、competition mathematics などです。これらは、産業環境での AI の影響の現実、または製品開発環境での AI の影響の現実に向かって非常に大きなギャップを開いています。このギャップは、実際には私がここで視覚化しようとしているものよりもはるかに大きいです。製品開発において AI で自分たちで生成できる価値の量と、最先端技術の間のギャップは重要です。
私たちは AWS と多くの協力をしてきました。Ericsson のような規模の企業がこのギャップを埋めるには何が必要かということです。私たちはかなり大規模な R&D 組織であり、Ibrahim が話していた価値を実際に提供できるようにこのギャップを埋める必要があります。これは、すべての組織が多くのデータを持っているが、誰もクリーンなデータを持っていないという課題についてです。competition programming などについて見るすべてのデモの下には、膨大なデータ作業があります。それをやらなければならず、この非常に複雑な設計空間全体にわたってさまざまな種類のデータ資産を組み合わせなければなりません。
マルチステップの推論というのは、これを難しくしているんです。私たちは、新しいマルチステップ推論が可能な LLM があれば、それは素晴らしいことだと言うのに慣れていました。しかし、推論のステップが増えれば増えるほど、複雑な技術的問題に適用する場合、各ステップで軌道を外れる可能性があり、前に進むにつれてそれを制約できない限り、非常に素早く何もない状態に分岐してしまいます。これらの課題が、ここ数年 Bastian と AWS と一緒に AgentCore に取り組むきっかけになりました。
MCP を活用した情報融合と組織規模での AI 展開の実現
基本的に私たちが意味しているのは、情報融合です。繰り返しになりますが、これは DevOps の設定では異なりますが、私の立場からすると、私たちは組み込みシステム企業です。要件を収集し、体系化し、開発し、テストして統合し、リリースしてデプロイし、その後、私たちの製品は 10 年以上現場に出ています。これは、このフロー全体を通じた非常に複雑なデータ資産のセットを取得し、これまでできなかった方法で融合させることについてです。私たちにとって重要な質問は、数万人の開発者がいる私たちの R&D 組織の規模でこれを行うために、どのような仮定またはアーキテクチャが必要かをどのように判断するかということです。
最初に達成したいのは、一種の分離です。Amazon Q Developer や Quiro のようなツールがあり、これはユーザーに向けたフロントエンドツールのようなものですが、それ自体は Ericsson の内部 R&D 資産について何も知りません。MCP を通じて、フロントエンドツールと私たちが社内で設計するものの間の分離層として MCP を標準化しました。私たちはエンドツーエンドの AI 製品にならないことに多くの努力を払い、代わりに特化した AI エージェント、Ericsson にとって何らかの差別化となる特化した AI テクノロジー、特化したモデル、特化した開発者ツール、そして特化したエージェントを構築しています。特に特化したエージェントのカテゴリーでは、Bastian を招待して、このことの異なる側面と、これがどのように私たちのために実現したかについて少し話してもらいたいと思います。
本当にありがとうございます、Doug。理解に制約されているという概念について話してくれてありがとうございます。これは、特に R&D が多い企業を含む、すべてのエンタープライズにとって重要なことです。System Comprehension Lab でこれにどのように取り組むかは素晴らしいことであり、System Comprehension Lab 内で重要な要因は何か、そしてこれを成功させるために取り組む必要がある主要な柱は何かについて少し話します。
一方では、エージェントは人間とインターフェースするものだと言いますが、彼らは正しいデータが必要です。私たちはこれについてすでに多くの話をしてきました。融合する必要があるさまざまなデータサイロがあります。その一部は、マルチステップ推論には独自の問題がありますが、マルチステップ推論は本当に重要なことの 1 つです。なぜなら、私たちは従来の素朴な RAG を超えて進む必要があるからです。素朴な RAG は、あなたが持っているテキストスペース内で単に同様のテキストを見つけるだけです。何か理にかなったものを得ることは不可能です。または何かを得ますが、それは正しいですか？ユーザークエリを評価し、異なるデータソースをクエリし、このデータを組み合わせ、おそらく一歩下がって、もう一度考え、おそらくユーザーと再度やり取りして、エージェントが必要とする正しいデータに到達するシステムを持つことが重要です。
さらに言えば、これはエージェントに対して、適切なデータ、簡潔なデータを適切なタイミングで提供することです。エージェントがこれに基づいて行動するために必要なもう一つのことは、時には一歩さらに進める必要があるということです。コンテキストは、ある時点では従来の AIML モデルに依存していますが、カスタム大規模言語モデルが必要になる場合もあります。次のステップで、それがなぜ重要なのかについて、少し詳しく説明します。マルチモーダル処理も重要です。私たちが見るデータは、単に非常によく構造化されたテキスト文書を取り込むようなものではありません。データにはさまざまなモダリティがあり、次のスライドでもう少し詳しく説明します。
これでエージェントが適切なデータを取得できることが確認できました。これは簡略化されたビューですが、エージェントは適切なデータを持っています。他に何が重要でしょうか？重要なのは、ダウンストリームツールと統合できることです。これらのエージェントは、物理的または デジタル世界と相互作用する必要があります。これはエンジニアがより良い製品を構築するためのものです。エンジニアは 多くの異なるツールを使用しています。コーディングとエンジニアリングを行う際に、彼らは使用しているプロジェクト計画ツールへの接続、そこにある知識、そして使用しているソースコントロールツールへの接続が必要になる場合があります。さまざまな種類のツールがあり、それらへのアクセスが必要です。ユーザーのこれらすべての摩擦ポイントを取り除きたいので、それをエージェントに任せます。
MCP はここで、これらすべてを接続するレイヤーです。実際にこのダウンストリームシステムとどのように連携するのか？これらのツールを MCP を通じて利用可能にし、エージェントがそれらを使用できるようにします。彼らはそれを通じて互いに使用することもできます。これでダウンストリーム統合ができました。もう一つ必要なのは、この情報をユーザーに表示することです。Ericsson はここで、ユーザーが作業したい場所でそれを利用可能にするという素晴らしい原則に従っています。
時には、ブラウザ内で深い研究タスクに取り組むのが正しいことかもしれません。そのため、彼らはそのための専用フロントエンドを持っています。時には、コーディングを行う IDE 内で直接それを行いたいかもしれません。特定のプロジェクトのために、そして Amazon Q Developer を通じて直接それを利用したいかもしれません。エージェントは適切なツールと適切なデータを持っていますが、それ以上のものがあります。重要な非機能的な側面があります。
observability についてはすでにかなり多く話してきました。重要なのは、どのようなツールが呼ばれているのか、そして私たちが正しいツールを選択したのかを理解することです。それらはタスクに関連しているのか？正しい出力を得ているのか？正しいコンテキストを得ているのか？マルチステップの推論を通じて作成したコンテキストが、実際に質問されたことやエージェントが取り組むべきタスクに関連しているのか？
Observability はそれ以上のものです。これらのシステムは単なるエージェントとどこかのモデルではありません。多くの動く部分を持つ複雑なシステムです。通常のアプリケーション、モデル、データソース、そしてデータを処理するパイプラインがあります。追跡する必要があることがたくさんあります。ですから observability は最も重要です。
次に scalable architecture があります。技術的な部分についてはあまり詳しく説明するつもりはありませんが、重要です。Ericsson は Agent Core をメインのコアピースの 1 つとして使用して、これを簡単にしています。エージェントを実行する serverless な体験が得られます。しかし scalability にはもう 1 つの側面があり、それは organizational scalability です。
ここにあるのは two-sided marketplace で、チームは特定のドメインに専門知識を持っており、これらのエージェントを通じてそれを利用可能にしたいと考えています。しかし、彼らは必ずしも agentic AI の専門家になりたいとか、モデルをトレーニングする方法を知りたいとは思っていないかもしれません。これらのチームとその知識をシステムにすばやくオンボードできる必要があります。これが Ericsson が blueprints とエージェントを使ってチームをシステムにオンボードするのに本当に上手くやっていることです。
プロデューサー側とコンシューマー側があります。コンシューマー側もオンボーディングが必要で、enablement が関わってきます。ユーザーがコスト的に意味のある方法でシステムを使用していることを確認する必要があります。LLM にはコストがかかるので、これがちゃんと機能していることを確認する必要があります。また、ユーザーがアクセスすべきツールにはアクセスできるようにする必要がありますが、おそらくすべてにはアクセスできないようにします。ここには一定レベルの認証と認可が関わってきます。
最後になりますが、これは実は私が GenAI のユースケース評価を行うあらゆるミーティングで最初に話すことです。これが最初に来る必要があります。GenAI プロジェクトにおいて唯一の定数は変化であり、ここで見られるのは非常に高速な変化です。試したい最新のモデルや試したい最新のテクニックやパターン、あるいは単にデータを更新するのに対応する唯一の方法は、今導入した変化が少なくとも昨日と同じくらい良いかどうかを理解することです。これは初日から堅牢な evaluation フレームワークを構築した場合にのみ機能します。
データ処理からカスタムモデル開発まで：Agent Core を基盤とした統合アーキテクチャ
では、説明に時間をかけたいことに移ります。これを完全に話そうとすれば、数日間かかってしまうので、本当に重要だと思うことにフォーカスします。まず最初は data processing の部分です。Data processing は複雑です。というのも、実は全体の中で最も複雑な部分の一つだからです。これは大幅に簡略化されていますが、最も重要な部分を説明したいだけです。
基本的には raw data があり、これが最も難しい部分です。このデータを理解し、処理し、その後、エージェントの特定のタスクに役立つ data storage で利用可能にするパイプラインがあります。データ側の問題は、これが均質なデータではないということです。PDF、Word ドキュメント、どこかのナプキンの画像など、多くの異なるフォーマットのデータがあります。多くの異なるデータがあります。その上、relational database から来るような非常によく構造化されたデータもあります。一方で、data lake 全体に散らばっている非常に非構造化されたデータもあります。どうやってそれを理解しますか？
その後、データの第 3 の次元は maturity または authority です。それはどういう意味ですか？これは信頼できるものですか？これは確定的で権威のある答えをくれるものですか？これらのデータソースでは、3GPP specification のような仕様から、エンジニアが昼食中に描いたナプキンに戻ってくるまで、あらゆるものがあります。エージェントが異なる方法で評価する必要がある異なる種類のデータです。
では、これらの部分がデータ処理の部分に移っていきます。Ericsson は AWS Batch や AWS の他のサービスを使って、このデータを最大限に活用しています。時にはデータソースへの統合についてですが、より興味深い部分は、実際にメタデータをどのように抽出するかということです。ドキュメントから画像を抽出する場合、どこから来たのかを確認したいですよね。それがそのドキュメントに合致しているのか。このドキュメントはどこから来ているのか。後でこれを再度表示できるのか。
さらに興味深いタスクもあるかもしれません。これはエンジニアリングなので、数式やデータテーブルを抽出する必要があり、それをうまくやる必要があります。これらのシステムではおおよそで十分というわけにはいきません。ですから、これらの異なる処理パイプラインがあります。最終的には、例えば Amazon Bedrock Knowledge Bases を通じてエージェントにそれを利用可能にします。より従来的な RAG アプローチが必要な場合ですね。しかし、これは後でエージェント内の多段階推論と組み合わせることもできます。
セマンティック検索を通じた構造化検索が必要な場合、例えば Amazon Bedrock Knowledge Bases を OpenSearch Serverless で使用できます。エンティティとそれらがどのように相互に関連しているかについてのより多くの情報が必要な場合、グラフデータベースは良い選択肢です。そしてそれもこのシステムで使用されています。最後に、アドホック分析や他の構造化クエリを使用したい場合があり、そこで Amazon Redshift を使用できます。これらすべてが実は Amazon Bedrock Knowledge Base の背後にあることができ、それはあなたが比較的簡単に始めるのを助けることができます。しかし、時には少し多くのカスタマイズが必要です。この場合がそうです。
ですから、必要な場所に適切なデータがあります。しかし、他の部分もあります。 私はすでに、トレーニングする必要があるカスタム大規模言語モデルがあることをほのめかしました。なぜトレーニングする必要があるのか。Ericsson は独自のハードウェア、独自のシリコンを提供し、作成しています。そのシリコンの上には独自の専有フレームワークと言語があります。ですから、コーディング関連のタスクのためにオフザシェルフの大規模言語モデルでエンジニアを支援することは、うまくいくわけではありません。適切なコンテンツを生成できる必要があり、その場合、Ericsson は独自のモデルをそれでトレーニングすることが重要だと認識しました。これがこのスライドにあるものです。
ここで非常に詳細に入るつもりはありません。詳細に入りたい場合、これはまた別の 2 日間のセッションです。しかし、要するに、ソースコードが必要です。システムドキュメンテーションまたはそのコードドキュメンテーションが必要です。高いデータ品質、トレーニング用の高品質なデータアセットを取得するために、前処理パイプラインを通じて実行する必要があります。この場合、これは継続事前トレーニング、インストラクト微調整、そしてその上に人間のフィードバックを伴う強化学習で行われ、その後ホストできる最高のモデルを取得します。異なるモデルに応じて、常に最高のモデルが何かが変わるため、時には Bedrock Agent または Bedrock カスタムモデルインポートでうまく機能し、他の時には EC2 でホストされます。
そしてもちろん、評価が重要なので、これは常に評価して再トレーニングするものです。最後のアーキテクチャスライドに移りますが、ここで 全体を少しまとめたいと思います。ランタイムではどのように見えるのでしょうか。エンジニアからもう一度始めましょう。エンジニアは、それが意味をなす場所、つまり彼らが働く場所で使いたいわけです。専用のフロントエンドか、Amazon Q Developer または Qiro を通じて使うかのどちらかです。ポイントは、どのようにそれを活用するのか、実際にどのように MCP gateway を統合して使うのか、ということです。Ericsson が作成した MCP gateway は、左側にいるネットワークエンジニア向けのアシスタンスのツールを提供することができます。
MCP gateway は統合ポイントであり、ここで agent がツールと通信でき、agent が agent と通信でき、さらにはツールが agent と通信することもできます。既に存在するツールで、それを Agent Core gateway を通じて利用可能にしたいだけの場合もあります。オリジナルの MCP server またはツールの場合もあり、その場合は Agent Core runtime で実行することができます。Agent Core runtime は主に agent を実行するために使われ、ここに私たちが持っているさまざまな agent の選択肢があります。3GPP agent かもしれませんし、LTE experts のような特定の機能に特化した agent かもしれませんし、他にもたくさんの特化した agent があります。
その後、例えば code generation agent があり、これは大規模言語モデルと統合されています。Agent は大規模言語モデルと統合する必要があるコードの一部であり、オーケストレーション用です。Amazon Bedrock で利用可能な多くのモデルにフォールバックするか、カスタムモデルを使用するかのどちらかを選択できます。Agent Core の素晴らしい点は非常に柔軟であることなので、例えばオンプレミスのモデルがある場合、それを簡単に統合することができます。
Agent は知識が必要で、多くの異なるナレッジレイヤーと統合することができます。比較的簡単です。例えば、Strands のような agent フレームワークを使用する場合、Amazon Bedrock ナレッジベースに比較的簡単に直接統合することができます。これでアーキテクチャの主要な部分は完了ですが、その後、重要な observability があります。Agent Core observability はこれを可能にし、OpenTelemetry と互換性があります。アプリケーション全体のエンドツーエンドスタックを見るのは非常に簡単で、スタック全体で持っている他の APM トレースと統合すれば非常に意味があります。
スタック全体というのは、フロントとバックにアプリケーションがあり、あちこちに Lambda があり、あちこちにコンテナが実行されているということなので、全体像を持ちたいわけです。だから observability が重要なのです。特に agent のトレーサビリティについては、Agent Core observability をプリミティブとして持っています。Identity も重要なので、agent が本来やるべきことだけができるようにする必要があります。Agent Core identity により、インバウンドおよびアウトバウンドの identity を管理することが可能になり、agent とユーザーが必要なものだけにアクセスできるようにすることができます。また、データソース内のデータの行レベルセキュリティと行レベル認可まで進むことができます。
最後に、メモリがこれを締めくくります。エージェントに適切なコンテキストを提供することが重要で、時にはそれをセッション間で持ち越したいことがあります。メモリは、プリファレンスとトピックをセッション間で持ち越すために使用される要素の1つです。Agent Core はコアでしたね。 ここに引用文があるのですが、このパートはあなたに語ってもらった方がいいと思います。ありがとう、Bastian。ラボの成果がこのように凝縮されているのを見るのは素晴らしいです。つまり、私たちは本気です。モバイルネットワークのデプロイメントやエンジニアリングを見るときに直面する複雑性、そしてそのすべての複雑性をどのように実際に一つにまとめて、私が提示した課題に取り組むのか、これは非常に大きなチャレンジです。AI の最先端が、AI の既成概念的な産業用途よりもはるかに速く進んでいるという状況の中でです。
私たちは Bastian と AWS チームに要件を投げかけてきました。少しあなたたちをテストするためという側面もありますが、本当は協業を新しいレベルに押し上げるためです。それが Agent Core の開発ドライバーの1つになりました。私たちにとって、Agent Core は基盤であり、この知識融合レイヤーで支援を受けることができ、再び自分たちのシャンパンを飲んで、複雑性を取り除くことができる場所です。Kubernetes クラスタを運用するビジネスには関わりたくないんです。むしろそれをコアプラットフォームにオフロードしたいです。Agent Core は私たちがスケールするための重要な要素になってきました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion