re:Invent 2024: AWSが提案する通信事業者向けAI活用クラウドソリューション
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら!
📖 AWS re:Invent 2024 - Build transformative, AI-powered telco solutions with AWS (TLC204)
この動画では、AWSのTelcoビジネスを統括するChivas NambiarとCTOのIshwar Parulkarが、通信事業者向けクラウドサービスの最新動向を解説しています。Generative AIの活用が進み、SK TelecomやNTT DOCOMOなどの通信事業者が顧客体験の向上や5G Core、RANの展開を実現している具体例を紹介。特にComcastの5G CoreのAWS移行やTelefonicaの100万人規模のユーザー移行など、大規模な実装事例が示されています。また、AWS GravitonプロセッサやAmazon EKS-Aを活用したvRANの展開、スマートホーム向けIoTサービス、SMB向けクラウドソリューションなど、通信事業者が新たな収益源を確立するための戦略的な取り組みについても詳しく解説しています。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください!
本編
Telco分野におけるビジネス動向と「Telco Flywheel」の概要
皆様、この1時間をご一緒できることを感謝いたします。このセッションでは、Telco分野のビジネスにおいて私たちが把握している状況についてお伝えしたいと思います。まず自己紹介させていただきますが、私はChivas Nambiarで、AWSのTelcoビジネスを統括しております。本日は、ビジネスユニットのCTOであるIshwar Parulkarと共同で発表させていただきます。
本日は、この1年間を振り返り、私たちが見てきたことについてお話しします。 また、私たちが「Telco Flywheel」と呼んでいるものについて説明し、そしてご想像の通り、Generative AIとモダナイゼーションについても触れていきます。 昨年、私たちがこのステージに立った時に述べたことのうち、実際に2つが現実のものとなりました。Telco各社が顧客体験の再構築に多くの時間を費やしてきたことが分かります。その多くは、Generative AIというトピックへの関心と、実際のユースケースへの適用が現実のものとなったことに起因しています。
2024年のTelco業界:Generative AIとモダナイゼーションへの大胆な賭け
私たちが予想していたほど進展が見られなかった分野が1つあります。それは産業用ユースケースのデジタル化です。通信事業者は依然として、複数の地域で展開可能で拡張性のあるユースケースを見出すことに苦心しています。私たちは、特に5G SAの展開が普及するにつれて、この分野に対して楽観的な見方を持ち続けています。今後さらなる進展が期待されますが、昨年は私たちが予想していたほどの動きは見られませんでした。
しかし、2024年に入ってからは、大胆な賭けが不足しているわけではありません。多くのリーダーたちがGenerative AI、モダナイゼーション、そしてネットワーク変革に賭けを行っているのを目にします。例えば、SK Telecomは独自のTelcoモデルを構築し、自社データを使用して大規模言語モデルをファインチューニングし、顧客体験を向上させました。また、NTT DOCOMOはAWSと提携して、次世代の5G CoreとRAN展開を全国規模で構築しています。
本日、COMCASTが5G CoreをAWSに移行することを発表しました。これに関するプレスリリースが先ほど公開されたところです。また、年初からTelefónicaが自社の5G Coreの一部をAWSで運用を開始し、現在100万人のユーザーがライブで利用しています。同社のCTOは、今後18ヶ月以内に400万人の加入者がこのシステムを利用することになると公に語っています。これらは非常に興味深い2つのユースケースであり、その部分に話が及んだ際にさらに詳しく説明させていただきたいと思います。
また、SunriseやTELUSなどの企業が、ネットワーク変革とGenerative AIがもたらす機能を活用して収益を生み出す機会を構築し始めている初期の兆しも見えています。これらすべては、お客様がGenerative AIについて考える際に、ついにビジネスで望む速度を実現するために使える投資資金だと認識し始めたことが原動力となっています。この1年は実験的な取り組みが中心でしたが、実際に本番環境での運用を始めると、移行とモダナイゼーションの取り組みを本格的に完了させる必要があることに気付くのです。
「Telco Flywheel」とGenerative AIがもたらす変革
では、この次世代のインテリジェンスを通信事業者のあらゆる業務に組み込むために、実際に何が必要なのでしょうか? AWSでは、Flywheelという考え方で物事を捉えています。Flywheelとは、メンタルモデル、つまり概念的なものです。通信事業者のビジネスを見てみると、ほとんどの通信事業者において、収益の大部分は消費者や企業による利用から生まれており、その利用量に基づいています。この利用量は、ネットワークとその機能に紐づいており、それらが製品体験を提供するために使用されています。
これが最もシンプルな形でのFlywheelの考え方です。通信事業者がネットワークを構築し、そのネットワークの機能を拡充していくと、突然、無制限データなどの製品体験を提供できるようになります。そうすると、顧客はその無制限データを使用して、より多くの動画を視聴するようになり、それに対応するためにさらなるネットワークの最適化が必要になります。これがFlywheelであり、私たちはこのFlywheelを使って、エコシステムに変化が起きた時に、それがビジネスにどのような影響を与えるかを考えています。
このFlywheelの文脈でGenerative AIについて考えると、通信事業者が特定のユースケースに取り組んでいることがすぐに分かります。今日の通信事業者のビジネスを運営するために必要なエンジニアリング作業の多くは、ネットワーク運用と製品開発の面にあります。
ここで、Generative AIが本当にエンジニアリング作業を変革し、最適化し始めているのを目にしています。15-20%の効果がすぐに実現されているユースケースを見てきました。これをFlywheelとして考えると、15-20%多くのエンジニアリングリソースで何ができるかということになります。Generative AIを活用して自動化を進め、自律型ネットワークに近づいていくにつれて、それがネットワークコストの削減につながり、さらに良いネットワークを生み出し、より良い製品へとつながっていくのです。
これこそが、通信事業者にとってGenerative AIが非常に興味深い理由です。通信事業者は皆、この影響が自分たちに及ぶことを認識しており、顧客とのエンゲージメントの方法を根本的に変えていくと考えています。ITやネットワークシステムの構築・運用方法も完全に変わっていくでしょう。そして時間とともに、より良い収益源を生み出していくと思います。これは素晴らしいことです。なぜなら、通信事業者は過去5-10年間、あまり良い道のりを歩んでいませんでした。多額の資本を投じ、技術に投資してきましたが、実際には大きな付加価値や収益を生み出すことができていなかったのです。
2023年と2024年を比較すると、2023年はGenerative AIとは何か、モデルとは何か、なぜモデルを使うべきなのかといった会話が多くありました。そして2024年になると、これらの実証実験の一部が本番環境に移行し始めたことで、より本格的な議論になってきました。現在では、どのようなデータが必要か、データをどのように管理すべきか、適切な保護措置をどのように設定すべきかといった話題が中心です。モデルを使用する際に、あるモデルから別のモデルに切り替える必要がある場合、すべてをやり直さなくて済むようにするにはどうすればよいのかといった議論もされています。
Generative AI導入の課題とAWSのソリューション
私たちはいくつかの一貫したテーマを耳にしています。今年の夏にTM Forumと共同で約300人の意思決定者を対象に調査を実施し、これらのユースケースについて何を行っているのか、実際に本番環境に移行しているのかを尋ねました。10以上のユースケースを本番環境で運用していると回答した顧客はわずか14%でした。さらに懸念されるのは、使用可能で実用的なプラットフォームを持っていると考えている顧客が50%しかおらず、この journey を進めるための人材とリソースを実際に持っていると考えている顧客はわずか25%だったことです。
誰もが理解しなければならない基本的な概念を考えると、これは困難な課題でした。AIインフラストラクチャをどのように構築し、管理し、運用するかが重要になってきます。通常のコンピューティングやストレージインフラの運用管理が難しいと思っていた方には、これはさらに困難です。すべてのデータをどのように見て、消費可能な形で統合し、適切にセキュリティを確保してガバナンスを行うか。これは非常に困難な課題です。この1年間、誰もがニュースフィードでこの分野の発展を目にしてきました。6ヶ月前に下した決定が、もはや適切でなくなっているかもしれません。そのくらいエコシステムの変化は急激なのです。
これはAWSが顧客をサポートできている重要な部分です。セキュアかつ責任を持ってシステムを構築する準備が整ったとき、必要な機能を持っているかどうかが問題になります。そのフライホイールと、エンジニアリングリソースから価値を引き出すことを考えると、このスタックの上位で多くの価値が生み出されているのが分かります。Amazon Q Businessは、チームが持っているデータを活用して異なるワークフローを実現し、エンジニアリングチームのワークフローを改善し、コードベースに含まれるデータに基づいて新しい製品を構築する能力を向上させることを可能にします。開発者がユースケースを構築したい場合に役立ちます。
Amazon Bedrockのようなマネージドサービスは、ユーザーが目的に合ったモデルを選択できる機能を提供します。必要なガードレールを設定でき、一度構築すれば、新しいモデルがエコシステムに追加された際も、同じガードレールを一貫して適用できます。これは非常に興味深いプラットフォームの仕組みで、新しいインフラを構築したり、通常必要となるGPU集約型の高負荷なインフラを運用したりする重い負担を負うことなく、開発者が迅速にスケールアップできるようになっています。
モデルの構築、トレーニング、ファインチューニングを行う先進的な事業者にとって、マネージドインフラストラクチャが必要であり、それを提供するのがAmazon SageMakerとその関連製品群です。コストについては触れていませんが、この1年でトレーニングと推論のコストは下がり始めているものの、私たちは次世代の機能を構築する必要があると考えています。そこで重要になってくるのが、AWS TrainiumとAWS Inferentiaによるシリコンへの投資です。これらは、推論、ファインチューニング、トレーニングのコストを時間とともに低減させることで、より多くのユースケースにこれらの機能を適用できるようにすることを目指しています。スタックの3層すべてにわたる機能を持つことが重要で、多くのお客様でそれが実証されています。
ユースケースを展開し、本番環境に導入しようとすると、非常に複雑になります。AWSの専門知識に頼ることで、世界最高レベルのインフラストラクチャと多くの優秀な人材を活用することができます。このモデルを本番環境に導入するには、AWS、Anthropic、SK Telecomの協力的な取り組みが必要でした。Anthropicはモデリングに非常に優れており、そのインフラストラクチャをスケールできることが強みです。私たちがAWSを選んだ理由は主に2つあります。1つはスケーラビリティです。一度に100万件のクエリがなくても、スケールアップとスケールダウンができることが私たちにとって非常に重要でした。AWSは、この点で素晴らしい対応をし、具体的なユースケースに合わせて適切なサイジングを行うことができました。
信頼性も非常に重要です。これは本番サービスであり、ダウンタイムは大きな経済的影響を及ぼします。AWSにはSLA(Service Level Agreement)が設定されており、モデルの可用性を可能な限り高く保ち、万が一ダウンした場合でも、いつ復旧するか、どのように対応するかについての保証があります。これも私たちにとって大きな利点でした。ここで強調したいのは、AWSが単独で行ったわけではなく、SK TelecomとAnthropicから大きな支援があったということです。Anthropicは誰よりも自社のモデルについて熟知しており、モデルの最適化やレイテンシーの削減など、ユースケースを市場に投入してお客様にサービスを提供するために必要な要素について、非常に有益な支援を提供してくれました。
3つの重要な教訓と成果があります。第一に、応答が速くなったことで、カスタマーエクスペリエンスが向上しました。韓国は「今すぐ」を重視する社会なので、より速く正確な応答を得られることは非常に重要です。第二に、応答の統一性です。以前は、各オペレーターが独自のスタイルを持っていましたが、この技術により、応答の一貫性を確保することでユーザーエクスペリエンスを統一できるようになりました。ユーザーAとBが同じ問題について問い合わせをして異なる回答を得るのは、良くないユーザーエクスペリエンスです。第三に、カスタマーサービス担当者の満足度です。この技術の導入により、新入社員の研修期間が短縮され、業務をサポートする技術があるため負担が軽減され、時間的なプレッシャーを感じることなく仕事ができるようになりました。これら3つの面で大きな成果が得られ、この技術の導入を非常に喜ばしく思っています。
SK TelecomのTelco LLM構築事例と得られた成果
SK TelecomのEricが、Anthropicと私たちと共に、TelcoのLLMを構築し、ファインチューニングを行い、ローンチするまでの1年間の準備について話してくれました。そこには多くの技術的な詳細が含まれています。
このトピックに関する別のセッションがあり、後ほどその詳細をご紹介します。ここで重要なのは、この取り組みが非常に価値のあるものだということです。Ericが言及した3つのメリットを聞いていただければ分かると思いますが、より良い回答をより速く得られるようになり、異なる質問に対しても一貫した回答を提供でき、さらにカスタマーサポートエンジニアやスタッフのオンボーディングを迅速化することで、ストレスレベルを下げながらより効果的な対応が可能になったとのことです。私が話をしている多くのTelco企業にとって、これら3つのポイントは非常に価値があるものです。だからこそ、この努力は価値があるのです。
では、なぜこれほど難しいのでしょうか? それは、今日の典型的な優れたプラットフォームがこのような形になっているからです。企業では、複数の組織がユースケースを取り上げ、このプロセスを通じて実現しようとしています。まず、これらの機能を活用し始めるためのランディングゾーンが必要です。簡単にオンボーディングでき、様々なデータソースに統一的な方法で接続できるようにする必要があります。安全な応答を得るためのガードレールを設定し、使用したいモデルを選択できる機能も必要です。そして、これらの機能を繰り返し改善しながら、現在導入され始めているエージェントと接続していく中で、このような性質のプラットフォームこそが、チームが構築する必要があるものなのです。
もしプラットフォームチームがこのような考え方をせず、単にAPIにリクエストを送って応答を得るような単一のユースケースだけを考えているのであれば、長期的にはビジネスでスケールすることはできないでしょう。ChatGPTのインターフェースがシステムとのやり取りの方法だと考えがちですが、このような性質のGenerative AIプラットフォームの基盤には、エンタープライズユースケースを活用し、ワークフローと機能を組み込むためには、プラットフォーム全体を考える必要があります。
Amazon Qとしてこれを構築すると、 先進的な顧客の中には、すでにその価値を実感している企業があります。British Telecomは、1,200人のエンジニアにAmazon Q Developerを導入したところ、15%の改善が見られ始めたと話しています。これは、より良い結果が得られるという私たちの仮説を証明しています。彼らはQからの推奨事項の受け入れ率が35%に達し、さらに上昇していると報告しています。私が示したプラットフォームのように、彼らも同様のガードレールを構築し、複数のプロバイダーからモデルを選択し、Generative AIゲートウェイの一部として利用できるようなプラットフォームが必要だという認識に至ったのです。
彼らは、どのようにこれを実装したかについて公に語っており、それによって適切なユースケースに適切なモデルを素早く見つけることができました。 これは私たちの通信事業者のお客様だけでなく、パートナー企業でも同様の動きが見られています。Amdocsは、Amazon Bedrockのようなプラットフォームを自社のプラットフォームの一部として採用することについて公に語っており、これにより、通信事業者であるエンドユーザーに対して、ユースケースに応じて適切なモデルを選択する機能を提供することが可能になっています。このように、多くの興味深い進展が起きており、これはまだ始まったばかりだと考えています。
通信事業者のネットワーク変革:クラウドネイティブ化への道のり
先ほど説明したFlywheelを振り返ってみると、 現在、Flywheelの中心にあるデータからインテリジェンスが大規模に生み出され、インサイトを構築していることがわかります。しかし、インサイトだけでは実際のビジネスには役立ちません。そこで重要になるのが、どのようにしてインパクトのある行動を促すかということです。ここで私たちが前提条件として認識しているのは、 デジタルマーケットプレイス、業務フロー、課金システムと連携するITシステムなど、エコシステム全体を大規模に近代化する必要があるということです。
請求書の説明を適切に行い、問い合わせの数を減らすことができれば、またこれらのインサイトやインテリジェンスをコールセンターの担当者へのガイダンスとして提供できる最新のコールセンターを構築できれば、大きな効果が期待できます。ネットワーク運用の分野では、すべてのデータを統合して意思決定を開始できる初期のユースケースが見られます。まだ多くの判断や行動を自動化している例は見ていませんが、そこに向かっていくでしょう。自律型ネットワークに向けた最初のステップが見え始めています。最新のシステムがあれば行動に移すことができ、これは通信事業者がこのテクノロジーを大規模に活用したい場合の重要な要素であり前提条件となります。
確かに課題も存在します。現時点で私たちが直面している主な課題の一つは、 通信事業者における一般的なベンダー選定において、クラウドへの移行が不可欠になっているということです。
このプロセスは予想以上に困難でコストがかかっています。また、規制環境の進化に伴い、データ主権に関する議論も増えています。私たちは この1年間、支援可能な分野を特定することに注力してきました。世界中の通信事業者の多くが大規模なVMwareインフラを構築しているため、従来型のインスタンスへの移行から、Amazon EKSやモダンなコンテナ管理システムでのコンテナ化、さらには場合によってはLambdaでの機能実装まで、近代化への道筋を特定するために彼らと協力してきました。
パブリッククラウドではなくオンプレミスでのデプロイメントが必要なユースケースが存在することを私たちは認識しています。そのため、お客様のデータセンター内でAWS Outpostsインフラストラクチャを使用してこれらのモデルを実装する方法を提供しています。お客様からパートナーオプションについての関心が寄せられたことを受け、NUTANIXやRED HAT OpenShiftとの連携も実現しました。最近では、新しいElastic VMwareサービスを発表し、お客様のVMwareフットプリントをAWSに持ち込むことを可能にしました。これにより、大規模な移行を行うことなく、VPC内でCloud Foundationを実行し、AWSエコシステムと接続することができます。
Oracleワークロードについても同様の進展を遂げています。これまでもOracleデータベースを実行する方法を提供してきており、多くのISPシステムがAmazon RDS上でOracleデータベースに依存して運用されてきました。しかし、通信会社が一般的に使用するRack上で動作する大規模なエンジニアードシステムについては、これまで効果的なソリューションがありませんでした。最近、私たちはOracleとの協力を発表し、Oracle Database@AWSを導入しました。これにより、Oracleのインフラストラクチャが当社のデータセンターに配置され、Rackやエンジニアードシステムのインフラストラクチャ上でOracleワークロードを実行し、AWSフットプリントと緊密に統合することが可能になりました。これにより、大規模な移行や変更を行うことなく、データベースをデプロイできるようになりました。
デジタル主権に関して、規制が進化するにつれて、通信事業者はAWSの完全な機能と大規模なパブリッククラウド環境で望むものとの選択を迫られることを懸念しています。私たちは、お客様がこのような選択を迫られるべきではないと強く信じています。ヨーロッパでは、ドイツ国内でEU国民によって運営される、すべてのパブリッククラウド機能を提供するヨーロッパ主権クラウドを展開しています。規制要件が求める地域において、これらの機能の提供を継続していきます。
モダナイゼーションを実施したお客様が価値を実感していることからも、その効果は証明されています。Virgin Media O2の事例をご紹介しましょう。私はVirgin Media O2のCustomer Contact担当ディレクターのAlan Stです。当社は英国を拠点とする通信会社で、約600万の固定回線顧客と4,000万のモバイル接続を持ち、世界44拠点で10,500人以上のエージェントを擁しています。Virgin MediaとO2ブランドの合併後、私たちのビジョンはコンバージェンスに焦点を当てました。お客様の出発点やタッチポイントに関係なく、継続的な会話を可能にするためのサービス体験の統合を目指しました。AWSは統合の簡素化を提供し、複雑な技術スタックを簡素化し、データとインサイトを通じて継続的な会話を可能にしました。
完了した移行では、お客様満足度の向上、引き継ぎの削減、データ提供の強化によるエージェントの権限拡大が見られています。この簡素化された運用モデルと改善された顧客インサイトにより、より良い顧客成果を達成しています。AWSは私たちのチームの不可欠な一部となり、お客様の課題やビジネス上の問題を理解し、協力してそれらを解決してきました。Amazon Connectを統合する上での重要な学びは、組織としてパートナーシップを築く必要があるということでした。
AccentureはAmazonやAWS、そしてConnectプロダクトについて豊富な経験を持っており、このプロダクトを活用してより良い顧客体験を実現する方法を熟知していました。長期的に見ると、これは私たちの学習を加速させることになりました。今年後半に予定されている追加コンポーネントについても期待しています。例えば、AIや生成AIの分野では、品質管理コンポーネントにおけるサポートが提供される予定です。Amazonとのパートナーシップにより、彼らは私たちと共に歩み、異なる顧客ソリューションを実現し、大胆にテクノロジーを取り入れ、そして再び、私たちのビジネスに全く新しい成果をもたらすことができます。
私たちと共にこの journey を歩んできた全てのオペレーターは、顧客にもたらすことのできる価値に興奮しており、これこそがAWSの真骨頂だと感じています。私たちは顧客が望むものから逆算して構築・提供することができます。このユースケースでは、Connectの導入により、JAIが提供する機能を活用して、より迅速に進めることが可能になりました。長期的に見ると、このイノベーションのセットは業界全体をけん引し、さらなるイノベーションを促進します。私たちは、ビジネスに還元されるすべてのエンジニアリング能力を活用して、より良い製品を構築することができます。そして、顧客が本当に望む製品を構築し、業界の成長を促進できれば素晴らしい成果になると考えています。
5G Coreのクラウドへの移行:Telefónicaの事例から学ぶ
ネットワークがAWSでどのように変革しているかについてお話しさせていただきます。私はIshwar Parulkarと申します。AWSのテレコム部門のChief Technologistを務めています。通信事業者の中核資産であるネットワークについて見ていきましょう。私たちは過去数年間、ネットワークをよりクラウドネイティブにするための変革の journey において、通信事業者と協力してきました。クラウドネイティブとは、マルチテナンシーと柔軟性による総保有コストの削減を意味し、クラウドが過去17年間実践してきた24時間365日のアップデート、継続的インテグレーション、ソフトウェアの継続的デリバリー、自動アップグレードとパッチ適用といった運用モデルを活用することで、より俊敏になることを意味します。そして、それと共にクラウドがもたらすセキュリティと回復力も実現します。
私たちは通信事業者と共にこの journey を数年間進めてきており、クラウドへのワークロードの段階的な移行ロードマップが見えてきています。これらのネットワークワークロードやネットワーク機能がAWSで成熟していく順序を決定する要因には3つの次元があります。第一の次元は複雑さです。どれほど複雑か、パフォーマンス要件は何かということです。一部には非常に厳格なものがあり、非常に高帯域のパケット処理要件があります。一方で、そこまでの要件がないものもあり、これらのワークロードに必要な機能の種類は非常に独特です。クラウドは継続的に進化し、より多くの種類のワークロードを処理できるようになってきています。
私たちは過去数年間、これらのネットワーク機能を実行できるよう、クラウドやVPCロードバランサーなどのサービスを強化してきました。同時に、これらのソフトウェア機能を構築するISVと協力して、よりクラウドネイティブになるよう取り組んできました。第一の次元は複雑さです。第二の次元はレイテンシーへの感度です。より遅延に敏感なものもあれば、そうでないものもあり、それによってクラウドエッジの連続体のどこに配置するかが決まります。私たちにはリージョンがあり、Local Zonesがあり、Far Edgeへのデプロイメントがあり、それらがどこに適合するかが、通信事業者がこれらを採用する早さに影響を与えています。
3つ目の次元は、集中型か分散型かという点です。これは配置場所を決める上で重要な役割を果たします。各リージョンで運用できるのか、それともend-to-endネットワークとして機能・運用するためにはEdge Cloudに依存する必要があるのでしょうか。これらの次元において、下側つまり集中型に位置するワークロードが最初に成熟し、採用されていきます。そして他のワークロードについても、これらの次元に沿って進化を続けています。 これらのワークロードについて、もう少し詳しく見ていきましょう。OSS(Operations Support Systems)とBSS(Business Support Systems)は、現時点で最も成熟したワークロードカテゴリーと言えます。このカテゴリーについては、おそらく6年ほど前から取り組みを始めました。パフォーマンスや機能の面では複雑ではなく、ITワークロードと同様に集中型で運用可能で、OSSの1、2の機能を除けば、レイテンシーにも敏感ではありません。
これらのOSS/BSSワークロードは自然と成熟度が高まり、多くのパートナーがAWS上にOSS/BSSをデプロイしています。これらは数多くのAWSネイティブサービスで構成されています。ここで最も興味深い点は、単にAWS上で動作するだけでなく、SaaSモデルへと移行していることです。パートナーはこれらをサブスクリプションやPay-as-you-goモデルのSoftware as a Serviceとして提供しています。これは通信事業者がこのワークロードを活用する方法として大きな飛躍であり、最も成熟が進んでいるカテゴリーとして、より高度な商用モデルやデプロイメントモデルへと進化しています。
現在、IMSと5G Coreも多くの実運用中の全国ネットワークで成熟度を高めています。 この取り組みは約4年前にBoost Mobileとともに始まりました。 これはグリーンフィールドの通信事業者で、データセンターもバックホール用の光ファイバーも保有していませんでした。何もない状態から、完全にクラウドネイティブな方式で、本格的な全国規模のネットワークを構築するというプロジェクトでした。2021年に立ち上げ、2023年にはBoost Mobileは70%の全国カバー率を達成しました。完全に最新のクラウドネイティブな方式で構築されたことを考えると、これは大きな成果と言えますが、これはグリーンフィールドのケースでした。
ではブラウンフィールドの場合はどうでしょうか?今年初め、私たちはTelefonicaと協力し、AWS Frankfurtリージョンで5G SA Coreを立ち上げました。これが特徴的だったのは、ブラウンフィールドの通信事業者だったということです。彼らにはすでにデータセンター、地中光ファイバー、確立されたインターネットピアリングポイントがありました。私たちは、これらの制約の中で私たちのクラウドモデルをどのように適合させるかを考える必要がありましたが、それを成功裏に実現し、100万人の加入者を既存のネットワークからFrankfurtリージョンで稼働するこのクラウドネイティブなCoreへと移行することができました。
本日、私たちはComcastについて発表します。 米国のブラウンフィールド事業者であるComcastが、オンプレミスのCoreコンポーネントを2つのAWSリージョンに移行します。彼らは2つのリージョンを使用して複数の市場にサービスを提供します。このケースでは、ネットワークの立ち上げにエンジニアリングの関与や深いISVパートナーシップを必要としなかったという点で、さらに一歩進んだ例と言えます。デプロイにかかった時間はわずか数週間でした。 当初は、事業者と私たちの間で相当なエンジニアリング努力が必要で、必要な機能やネットワークの運用方法を理解するために第三者のエンジニアリング関与も必要だったグリーンフィールドネットワークから、現在では既存のインフラや制約のあるブラウンフィールドネットワークでも、数週間で展開可能な状態にまで進化しました。これは5G Coreのクラウドにおける成熟度の進化という点で、非常に大きな進展と言えます。
この17年間、私たちは常に新しいワークロードに直面し、それらに対応するためにクラウドを強化してきました。現在、パケットコアのようなものは、AWSで実行される成熟したワークロードと考えています。ここで、Telefonicaのマリク CTOから、AWSを使用して100万人の加入者を移行した方法とその利点について詳しく聞いてみましょう。私はMalik Crow、Telefonica Germanyのチーフテクノロジー&インフォメーションオフィサーです。私のビジョンとして、通信業界は適応は得意ですが、自己変革は苦手です。そこでクラウドという技術が非常に魅力的でした。技術、オペレーティングモデル、カルチャーという3つの本質的な要素において、私たち自身を変革できるからです。通信のコアをクラウドに移行するという旅を始めたとき、私たちはAWSと協力して通信の中核機能をパブリッククラウドに移行しました。そこに到達するまでに3年かかりましたが、サービスを市場に素早く投入し、革新を起こすことが私たちの主な目的でした。そしてAWSと、この場合はNokiaと協力して5Gスタンドアロン向けのパケットコアソフトウェアを開発し、このソリューションで目指したお客様への成果は、いかに素早くスケールできるかということでした。
これを実現するために、ソフトウェアとサービスのアップグレードをどのように展開し、コアネットワークとインターネットを接続する際にこれらのサービスをどのように革新するかに取り組む必要がありました。5Gスタンドアロンと5G Advancedの低遅延アプリケーションでは、市場への投入を迅速に行う必要があります。AWSと協働して本当に良かったと感じるのは、アジリティがその核心にあることです。パブリッククラウドを始めた当初は、通信アプリケーション向けの準備が整っていませんでしたが、AWSのアジリティには本当に感銘を受けました。そこで、私のシステムのコアをパブリッククラウドに移行できると確信しました。現在、Frankfurtリージョンで100万人のお客様がライブで利用しています。過去3.5年間で構築したこのプラットフォームに、何百万人ものお客様を移行できるという自信がますます高まっています。
RANのクラウド化:次のフロンティアへの挑戦
ご覧の通り、AWSでのコアワークロードの成熟度は大きく飛躍しました。しかし、これはネットワーク機能やネットワークの一部を通常の運用方法で実行するだけの話ではありません。クラウドが実現できたこと、特に5G Coreの分野では、従来のネットワークや従来のネットワーク構築方法では不可能だったユースケースやシナリオに対応できるようになりました。いくつか例を挙げてみましょう。
一つは、マルチテナントのAPI駆動型MVNOです。オペレーターの既存のブランドインフラストラクチャがあり、APIを使用して素早くサービスをスピンアップできるコアを展開できることで、MVNOがネットワークを構築、展開し、顧客にサービスを提供する方法が一変しました。昨年、ハワイのワイヤレスキャリアであるMobiは、現在CISCOの一部となっているWorking Group TwoのマルチテナントコアをAWS上で使用しました。数日から数週間で、T Mobileの無線ネットワークを使用したMVNOをスピンアップし、カスタマイズされたサービスを顧客に提供し始めることができました。つい数日前には、OXIOがAT&TをRANプロバイダーとして使用し、AWS上で実行されているコアコンポーネントを使用してMVNOをスピンアップできることを発表しました。
二つ目の例は、クラウドでのコピーを使用した高可用性と災害復旧です。冗長システムには明らかにコピーが必要で、その一つの方法は、ネットワークコンポーネントのオンプレミスインスタンスとクラウドでのコピーを持つことです。これらを高可用性モードまたは災害復旧モードで冗長的に実行できます。オンプレミスで実行し、クラウドには少量のトラフィックのシードを置いておき、オンプレミスのコアがダウンするような災害が発生した場合に、そのトラフィックをクラウドにバーストさせることができます。これらの手法は、従来のネットワークでは多くのハードウェアを用意する必要があるため実現不可能でした。クラウドの弾力性と、必要なときにスピンアップし、不要なときにスピンダウンできる機能により、これらのアーキテクチャシナリオを非常にコスト効率よく適用できるようになりました。
3つ目の例は、Virtual Roaming Gatewayに関するものです。これは2つの通信事業者間でのローミングを支援するゲートウェイです。仮想化されると、ソフトウェアアプライアンスとして展開できるようになり、クラウドネイティブ化すると、最適な場所にエッジロケーションを活用して配置し、必要に応じて動的に起動したり移動したりすることができます。これにより、通信事業者間のレイテンシーが最適化され、インフラストラクチャが本質的に耐障害性を備えているため、信頼性が向上します。さらに重要なのは、その動的な性質です。アーキテクチャ、加入者トラフィック、その他の要因に応じてこれらのローミングゲートウェイを移動させることができます。これは従来型のネットワークでは実現不可能なユースケースです。
従来のアプローチでは、ハードウェアをプロビジョニングし、特定の場所にローミングゲートウェイを固定する必要がありました。つまり、これは単に本番環境のネットワークを運用するだけでなく、クラウドによってユースケースが拡大したということなのです。 ここに示しているのは、このローミングゲートウェイを実装したTELUSからの声で、システムの耐障害性と動的な性質がいかに役立ったかについて語っています。また、先ほど触れたMVNOのOXIOも、AWSを活用して非常に柔軟なネットワークを迅速に展開することができました。
それでは次のフロンティアと言える RANに話を移しましょう。これは最も複雑なワークロードです。当然のことながら、それはスタックの下位レイヤーが理由です。L1、L2レイヤーは非常に高いパフォーマンスを要求します。ビームフォーミングや多くの行列計算があり、これらはまだアクセラレーターを必要とし、x86シリコンのような汎用コンピューティングシリコンで実行できます。これらが後発でクラウドとの連携を始めた理由の1つです。また、これらは非常に分散化されており、明らかに最もエッジに近い場所に配置する必要があります。これが、私が先ほど選択順序の複雑さという観点で話していた、もう1つの側面です。
ここで私たちが試みたのは、 クラウドがどこで差別化できるかという観点からこの領域を見ることです。そして、この分野でいくつかの差別化できる領域があると考えています。1つは明らかに機械学習です。RANの最適化やO-RANアーキテクチャにおけるML基盤のxAppやアプリケーションの構築など、RAN向けのAI/ML分野で多くの取り組みが行われています。しかし、私たちはRANワークロードをホストするインフラストラクチャを構築するための基盤としてARMに注目しています。
そこには3つの利点があります。1つ目は価格性能比です。先ほど述べたように、これらは非常に要求の厳しいワークロードです。スタックのL1、L2レイヤーは極めて高いパフォーマンスを要求し、アクセラレーターを使用しますが、私たちのARM系プロセッサファミリーであるAWS Gravitonは、他のアーキテクチャと比較して最高の価格性能比を誇ります。2つ目は電力効率です。ご存知の通り、ARMは最も電力効率の良いアーキテクチャの1つであり、 ネットワークの消費電力の70〜75%はRANで消費されています。そこで私たちは、RANの基盤となるアーキテクチャを変更することで、大幅な省エネルギーを実現したいと考えています。
最後に、お客様への柔軟性と選択肢の提供についてお話しします。当社の重要な信条の一つは、お客様に選択肢を提供することです。私たちは、ベンダーがこれらのRANスタックコンポーネントを提供する際のシリコンの選択肢を作りたいと考えています。これが私たちが取り組んでいることです。2025年はRANの年になると考えています。通信事業者は、Virtual RANとOpen RANをどのように展開できるか、そしてクラウドを活用してそのメリットをどのように引き出せるかについて、より深く理解を深めていくことでしょう。
Nokiaは、AWS Gravitonプロセッサを試験的に導入し、効率的なレイヤー2処理が可能であることに加え、ARMベースのレイヤー1アクセラレータとの互換性があることから、大幅なパフォーマンス向上を実現しています。NTT DOCOMOも、主に省電力性能を理由にAWS Gravitonを5G Core向けに選択し、vRANの展開にはAmazon EKS-Aを採用しています。なお、EKSは私たちのマネージドコンテナサービスで、Elastic Kubernetes Serviceの略です。EKS-Aは、EKS Anywhereのことで、サードパーティのハードウェア上で同じ構成でEKSコンポーネントを実行できるようにするものです。それでは、DOCOMOの取り組みについて、大川さんからお話を伺いましょう。
NTT DOCOMOのイノベーション部門を担当する上級副社長の大川貴人です。AWSは、NTT DOCOMOにとって最も重要な戦略的パートナーの一つです。私たちの協業は、最近のAWS上での5Gネットワークや、vRANプロジェクトに象徴されています。DOCOMOは2025年からvRANの全国展開を計画しており、vRANの重要なコンポーネントとして、AWSが提供するAmazon EKS Anywhereをプラットフォームとして選択しました。
このプラットフォームは、NBソフトウェア、Qualcommハードウェアアクセラレータ、HPハードウェアプラットフォームと組み合わせて使用します。この構成により、新機能を柔軟かつ短期間で展開できるようになり、また、通信業界以外の幅広い市場でも、より高性能で省エネ効率の高いハードウェアアクセラレータを活用することが可能になります。EKSの機能により、ネットワークの管理・運用を自動化し、運用コストを削減しながらネットワークの可用性を向上させることができます。また、EKS上で動作する多くのサービスアプリケーションや、EKSのツールや環境に精通したエンジニアなど、AWSエコシステムの可能性を活用できることも期待しています。
このエコシステムを活用することで、同じコンピューティングリソースを共有しながら、AIなどのアプリケーションをプラットフォーム上で実行し、ネットワークに付加価値を与えることができます。AWSとNTT DOCOMOの間で、今後もさらなる素晴らしい協業と成果が生まれることを楽しみにしています。通信事業者が自社の中核資産であるネットワークの運用にクラウドを採用していく、この journey を見られることは本当に素晴らしいことです。特にAIが大きな役割を果たせる Radio Access Network の分野で、来年どのような展開が見られるか、とても楽しみにしています。
また、私たちはネットワークの自律化に向けた取り組みも進めており、構築、デプロイ、運用の全般にわたってGenerative AIを活用しています。この件については別のセッションで詳しく取り上げられますので、ここでは詳細は省きますが、ぜひそちらのセッションにご参加いただければと思います。フライホイールに話を戻しますと、ネットワークの構築と運用をよりCloud Nativeにすることで、コスト効率が向上するだけでなく、より俊敏な方法で新しいサービスを開発できるため、製品体験も向上し、より多くの利用を促進してフライホイールを加速することができます。
それでは、新たな収益源と、通信事業者がいかにして成長エンジンをさらに強化できるかについて見ていきましょう。通信事業者が検討している戦略は数多くあり、私たちもそのサポートを行っていますが、基本的にはコネクティビティレイヤーを超えることを目指しています。単なるコネクティビティサービスを超えて、他のサービスやオファリングへと展開し、Edgeコンティニアムを含むクラウドインフラストラクチャーとその上のサービスを活用して、マネージドサービスソリューションや新製品の新しいレイヤーを構築しています。クラウドとの組み合わせによって、これらの新しい製品体験の可能性を本格的に開拓することができるのです。
通信事業者の新たな収益源:隣接市場への展開とネットワーク資産の活用
私たちの取り組み方としては、まずコンセプトを考え出し、実証実験を行い、そしてAWSのサービスを使って本番環境へと移行していきます。この数年間で、これらの分野のいくつかで大きな進展を見せています。ここでは2つの戦略についてお話しします。1つは隣接市場や隣接事業領域への参入、もう1つはコネクティビティ以外のネットワーク資産の活用です。まず、通信事業者の中核事業に隣接する分野への展開について見ていきましょう。その一つが、私たちが取り組んできたスマートホームです。現在のスマートホーム体験を見てみると、ユーザーは家庭内に複数のデバイスを持っており、それぞれに複数のアプリがあります。例えば、私たちのAlexaや、Google Nest、様々なベンダーのセキュリティカメラなどです。異なるアプリ、異なるデバイス、異なるプラットフォームがあり、それらが相互に連携していないため、非常に断片的な体験となっています。
さらに、個々のルーティンを設定する必要があります。これらの複数のデバイスの管理やルーティンの作成を支援するAIの活用が不十分で、その潜在的な可能性が十分に引き出されていません。現在でも、各デバイスは手動で設定する必要があります。この複雑さは、私たちの顧客であるTELUSがユーザー調査を行った際に明らかになった問題です。
調査では、37%のユーザーが複雑さに関する問題を報告していることが分かりました。消費者向けの製品としては、これはかなり高い数字です。これは、TELUSのような通信事業者と協力して、クラウドサービスを使用して解決に取り組んでいる分野の一つです。
私たちが最初に取り組んだことの1つは、さまざまなサードパーティプロバイダーのデバイスのオンボーディングプロセスを簡素化するIoTサービスの構築でした。複数のエコシステムからのデバイスに対して、プラグアンドプレイの体験を提供する統一的なオンボーディング環境を作り上げました。また、このフロントエンドのオンボーディングを、課金システムなどのバックエンドの通信システムやミドルウェアと統合するためのIoTサービスも開発しました。これらは、通信事業者がスマートホーム機能を提供できるように支援するクラウドサービスで、このプラットフォーム上でアプリを構築したり、開発者に提供したりすることができます。
通信事業者と取り組んでいるもう一つの分野は、AIの活用、特にGenerative AIの活用です。これらのデバイスから得られるすべてのデータを分析し、ユーザーがこれらのデバイスをどのように使用しているかについて継続的に学習します。そして、Generative AIを使用して、ルーティンを推奨し、これらのデバイスをより自動的に設定できるようにします。IoTサービスと他のAI技術を組み合わせることで、お客様にスムーズでストレスのない体験を提供し、スマートホームにおけるデバイスの複雑さを管理するための推奨事項を提供します。先ほど触れたTELUSは、今年9月にスマートホームアプリをローンチし、消費者が家庭のエネルギー使用を最適化し、電力会社からの節約を実現できるようにしました。このプラットフォーム上では、さまざまなスマートホームアプリケーションを開発する可能性が広がっています。
これは、TELUSがスマートホーム分野で売上を伸ばすために活用した隣接市場の優れた例です。次に紹介したい2つ目の例は、SMBクラウドソリューションの領域です。中小企業は、レガシーアプリケーションを抱えており、これらのアプリケーションの変革、パフォーマンス向上の方法の理解、そしてクラウドへの近代化と移行に必要な知識や専門性の不足など、大きな課題に直面しています。大規模なSMBはセキュリティ、ガバナンス、アプリケーションパフォーマンスの向上に重点を置いている一方で、小規模なSMBはHR、給与計算、POSシステムなどのポイントソリューションを求めています。アプリケーション移行のための大きなIT予算は持っていません。
小規模と大規模のSMBクラウドプロバイダーの市場が非常に細分化されており、SMBの近代化とクラウド移行の課題を解決するための単一のチャネルやアプローチを持つことが難しい状況です。しかし、彼らには1つの共通点があります:モバイルと接続サービスのための通信事業者です。これは通信事業者にとって、接続性だけでなく、クラウドソリューションも組み合わせて提供することでSMBを支援できる機会となっています。通信事業者は私たちと提携し、AWS Marketplaceやその他のチャネルを通じてISVエコシステムを活用しています。彼らはAWSのサービスとパートナーエコシステムを組み合わせて、SMBの問題に対応するパッケージ製品を構築し、接続サービスを統一的に統合しています。さらに、Generative AIやその他のAI/ML技術を取り入れ、これらのサービスの使用状況や消費状況から学習して、新しいサービスや機能を改善、洗練、開発しています。これは通信事業者にとってもう一つの有望な方向性です。スイスの通信事業者であるSunriseは、このモデルを広範に活用している例です。
通信事業者はこの方向性で売上を増やすことを検討できます。SMEは接続性について通信事業者に依存しており、通信事業者はその既存の関係を活用して、AWSと協力しながらクラウドと接続性のソリューションを組み合わせて提供することができます。このモデルを活用し始める通信事業者が増えています。これは隣接市場に参入することで売上を伸ばす方法についてでしたが、もちろん、他にもさらなる機会が存在します。
通信事業者が採用しているもう一つの戦略は、接続性を超えたネットワーク資産の活用です。ネットワークには、デバイスの位置情報、デバイスのステータス、ユーザーが実行しているアプリケーション、SIMカードの交換有無、ユーザーのモバイル番号の認証など、多くの情報やデータが存在します。これらは、これまでほとんど活用されていなかったネットワークの機能です。通信事業者は、開発者が自由に利用してアプリケーションに組み込めるAPIを通じて、これらの資産を収益化することを検討しています。
この動きはここ数年で本当に加速しており、これらのAPIを構築するためのアプローチもさまざまです。CPaaS(Communication Platform as a Service)のエコシステムは、過去数年間これを成功させてきました。これらは高レベルのAPIですが、最近では、複数の団体がネットワーク層のAPIの開発に取り組んでおり、そうしたAPIが増えてきています。
クラウドプロバイダーである私たちにとって、これはごく自然な流れです。クラウドには17年以上にわたって構築された革新的な技術があり、現在では200以上のサービスを提供しています。そして、私たちが開発するものはすべて、何千ものAPIを通じて提供され、消費されています。そのため、ネットワークがAPIを通じて開発者に提供されることは、私たちにとってはごく自然なことなのです。 これにより、ネットワークの提供方法とユーザーによる消費方法が変わる可能性があります。従来は通話時間や通信量による課金でしたが、ここにはネットワークをさまざまな消費モデルで提供できる柔軟性と機会があります。
これは、私たちのコンピューティングプラットフォームと似ています。最初はサーバーのレンタルだけでしたが、現在ではコンピューティングに関する多様な消費モデルがあります。これにより、柔軟なネットワーク消費モデルとネットワーク強化アプリケーション、つまりネットワークからの情報で強化されたアプリケーションやネットワークのプログラム可能性を実現できます。例えば、スマートフォンでSIMが交換されたかどうかの情報を使用した不正検出や、ユーザーのモバイル番号の認証などです。この情報を活用してアプリケーションを強化する機会があり、それによって通信事業者が収益化できる多くの資産を活用することができます。私たちがここで行っているのは、250以上のAWSサービスと、これらのAPIを組み合わせて、シームレスな開発者エクスペリエンスを提供することです。
ぜひ、このre:Inventで開催されるセッションにご参加いただきたいと思います。特に注目していただきたいのは、ネットワークデジタルツイン向けの生成AIを活用したグラフに関するセッションです。これは、先ほど言及したネットワーク自動化の部分で、生成AIがネットワーク変革において大きな役割を果たしている例です。また、SK TelecomのTelClaudeセッションでは、Telco特有のユースケース向けにAWS上でFoundation Modelを構築・調整する興味深い事例が紹介されます。そして最後に、しかし決して軽視できないのが、Telecomのデモです。プレゼンテーションは素晴らしく、多くを学べますが、実際に構築したものを見ることに勝るものはありません。私たちはBuilderの集団を自認していますので、ぜひデモもご覧ください。この1時間、ご参加いただきありがとうございました。ご質問がございましたら、会場でお答えいたしますので、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion