re:Invent 2024: Telefónica Germany、AWSで5G Coreを構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - O2 Telefónica Germany: 5G Core on AWS (TLC206)
この動画では、AWS Telco Business UnitのマネージングディレクターFabia Sheronが、Telefónica Germanyとの5G Coreプロジェクトについて解説しています。AWSのFlywheelモデルやAAAの原則（Agility、Autonomy、Automation）に基づき、クラウドネイティブな通信インフラの構築を目指した取り組みが紹介されます。Telefónica Germanyは100万人の加入者向けに5G Standaloneをライブ運用しており、2000万人までのスケールアップを計画。AWS Cloud Continuumを活用し、Regions、Local Zones、Outpostsを組み合わせることで、需要に応じて柔軟にスケールできる「呼吸するようなネットワーク」の実現を目指しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSとTelefónica Germanyの5G Core Network革新への挑戦
皆様、こんにちは。本日はお越しいただき、ありがとうございます。この会場まで、DamirやほかのColleagueたちと一緒に歩いてきたのですが、Venetianからここまで30分ほどかかり、皆様には本当に足を運んでいただき、感謝申し上げます。私はFabia Sheronと申します。AWS Telco Business Unitのマネージングディレクターとして、ヨーロッパ、中東、アフリカ地域を担当しています。Ericssonで1年を過ごした後、AWSに入社して6年になります。皆様、こんにちは。Fabiaが申し上げた通り、本日は貴重なお時間をいただき、ありがとうございます。私はAWSのプロダクトマネジメントを統括しており、後ほど私の役割についても詳しくご説明させていただきます。
今日お話しするのは、Telefónica Germanyとの5G Core Networkプロジェクトについてです。これは、Telecom Business Unitが設立されて以来、最も象徴的なプロジェクトの一つだと考えています。Telecom業界で最も影響力のある変革者の一人であるMalikとともに、2年半にわたる長い journey を歩んできました。残念ながら本日Malikは参加できませんが、後ほど短いビデオメッセージをご覧いただきます。このような大規模な変革に着手する際、私たちは単なるフロントエンドアプリケーションではなく、通信事業者の中核となる5G Coreについて話をしています。Malikが言うように、重要なネットワークワークロードをクラウドに移行できた時こそ、本格的なクラウド変革を成し遂げたと言えるのです。
このような非常に複雑な変革には、いくつもの要素が関係してきます。これは単なる技術的な変革ではなく、文化の変革、組織の変革、人材の変革、そして運用の変革なのです。まず最初にすべきことは、世界中の通信事業者だけでなく、多くの企業が陥っている分析麻痺から抜け出すことです。Telefónicaとの journey で学んだ技術的な詳細や成果についてお話しする前に、私たちAmazonが持っている、そしてこの journey の中でTelefónicaと、特にMalikと共有してきたいくつかのメンタルモデルについて、少しお時間をいただきたいと思います。
Amazonのイノベーション哲学とTelco業界への適用
この会社に入社して以来、私が本当に気に入っている最初のメンタルモデルは、私たちが「Flywheel効果」と呼んでいるものです。Jeff Bezosはよく、イノベーションを起こす際には、不変の3つの要素に焦点を当てるべきだと言っていました。これらの3つの要素とは、お客様が何を革新しようとしているかに関係なく、常に求め続けるものです：より良いコスト、より良い選択肢、そしてより良い利便性です。Amazon.comの成功を考えてみると、それはSellerを引き付けることから始まりました。なぜなら、Sellerを引き付けることで、バイヤーに選択の可能性を与えることができ、お客様は選択の自由を求めているからです。
Sellerを引き付けると、トラフィックが増加し、トラフィックが増えれば増えるほど、ビジネスの取引量が増え、スケールを活用してコストを削減できるようになります。コストベースラインからコストを削減できれば、価格面での優位性を生み出すことができ、コストを削減してSellerを引き付ければ引き付けるほど、より多くのCustomerを獲得できます。Customerを獲得すると、Customerからフィードバックを得られ、そのフィードバックによって利便性と体験を向上させることができます。これは、AmazonとAWSで一貫して経験してきたことです。この単純なルールを、私たちがAWSで通信事業者と行ってきたことに当てはめてみると、私たちは非常に意図的にこの基本ルールを適用してきました。まず、選択肢に関して、私たちは初日から、お客様がCore Networkに最適なベンダーを選択できるようにしたいと考えていました。企業を買収することもできましたし、その話も出ました。しかし、一貫した答えは、フルスタックを購入することを強制する、もう一つのフルスタックベンダーにはなりたくないということでした。私たちは、Ericsson、Nokia、Samsung、そしてWorking Group Twoのようなスタートアップと協力して、クラウド上でネットワークを運用するための最高のソフトウェアを選択できるようにすることだけを目指してきました。
2012年に独自のカスタムシリコンの開発を決定した時、それは大きな一歩でした。IntelやAMDといった大手と提携しながら、独自のチップセットを開発することで次のレベルへと境界を押し広げていく戦略の一環でした。これは現在に至るまで一貫したロードマップとなっています - 最初にNitro、そしてGraviton、Trainium、Inferentiaと続きました。その結果として、まずIntelと、次にAMDと、そして現在はNVIDIAとの間で、適度な摩擦と緊張関係を生み出し、境界を押し広げることができています。
現在のGraviton 4を見てみると、同等のx86インスタンスと比較して、パフォーマンス対価格比で30-40%の向上、さらに電力消費においては60%もの改善を実現しています。これはコストを削減し、可能な限り最良の価格でご購入いただけるよう、パートナーと共に懸命に取り組んでいる成果です。 2006年の会社設立以来のAWS Flywheelの効果により、フライホイール効果によって134回もの一方的な値下げを実施してきました。開発者コミュニティが、AWSクラウドが市場を革新するための最もシンプルで費用対効果の高いツールであることを理解したことで、AWSクラウドはイノベーションの中心となりました。
私たちのパートナーは、世界がクラウドへと移行する中で、ビジネスを成長させる素晴らしい機会があることを理解しました。これが実績です：何百万ものお客様、10万以上のパートナー、そして市場を革新するために開発者が使用する200以上のサービス。これらのパートナーの中には、数多くのISVや通信事業者のアプリケーションがあります。先ほど言及したWorking Group Twoは、Telenorからスピンオフした企業でした。昨年まで、彼らはサービスとして最も革新的なコアネットワークを提供しており、Ciscoに買収されました。彼らは、これまでで最も成熟したCloud Nativeコアを開発しました。Deutsche Telekomが部分的に所有する別のスタートアップも、同様の成果を上げています。現在、NokiaやEricssonそしてTelefónicaの仲間たちと協力して、彼らのソフトウェアをCloud Native化するサポートを行っており、Samsungやその他の企業とも同様の取り組みを進めています。
文化的変革、業務変革、組織変革について考えることは興味深いものです。組織や文化の形態と、提供するソフトウェアやシステムとの間につながりを見出すのは、いつも驚きの連続です。モノリシックな組織は、モノリシックなソフトウェアを生み出します。重要なのは、アジリティを提供するためにいかに物事をシンプルにするかということです。これは、モノリシックな組織と、フェデレーテッドな開発者ベースの組織との違い、つまり許可を求める必要のある文化から、実験や破壊的イノベーションが自由にでき、分析による麻痺から解放された許可不要の文化への移行なのです。
クラウドへの移行において、現代の組織で本当に重要な3つの要素を挙げるとすれば、それはAAAです：Agility（アジリティ）、Autonomy（自律性）、そしてAutomation（自動化）です。アジリティのためには、物事をよりシンプルなコンポーネントに分解する必要があります。つまり、何かを構築するチームを作る際、そのチームの食事にピザ2枚以上が必要になるようであれば、彼らが構築しようとしているものは複雑すぎると考えています。
組織的には、私たちは常に「2-Pizza Teams」と呼ばれるモデルを採用してきました。小規模なチームに分かれることで、これらの小規模チームが自律性を持つようになり、この自律性こそがAmazonにおけるもう一つの基本的な要素なのです。現代の組織では、構築したものに対して責任を持つ必要があります。なぜなら、それが当事者意識を生み出すからです。
第三の原則は、可能な限り自動化を進めるということです。Amazon Fulfillment Centerを例に考えると、すべてを自動化することの素晴らしい例といえます。1分間に4000個の商品を販売し、1日に160万個のパッケージを配送する中で、お客様との間で合意したSLAを守り、魅力的な価格水準を維持するためのコストベースラインを保つには、それが唯一の方法なのです。Malikとこれらについて話し合った際、彼は俊敏性、自律性、自動化というこれら3つの基本的な重要性を完全に理解していました。
Telefónica GermanyのCTOが語る、クラウドベースの5G Core実現への道のり
私はTelefónica Germanyの最高技術・情報責任者のMalik Crowです。私のビジョンとして、通信業界は適応は得意ですが、自己変革は得意ではありません。そこでCloudというテクノロジーが私たちにとって非常に魅力的だったのです。テクノロジー、オペレーティングモデル、カルチャーの面で自己変革を促すものだからです。通信のコアにCloudを据えるという取り組みを始めた時、私たちはAWSと協力して通信の中核機能をPublic Cloudに移行しました。そこに到達するまでに3年かかりましたが、サービスをより迅速に市場に投入し、サービスのイノベーションを実現することができました。
AWSと、この場合はNOKIAと共に5G Standalone向けのPacket Coreソフトウェアに取り組む中で、このソリューションでお客様のために目指した成果は、迅速なスケーリング、サービスアップグレードにおけるソフトウェアのデプロイ、そしてコアネットワークとインターネットを接続する際のサービスイノベーションの実現方法でした。5G Standaloneでは、5G Advancedの低遅延アプリケーションを迅速に市場に投入したいと考えています。AWSと協働して本当に良かったと感じるのは、AWSが俊敏性を核としているからです。始めた当初、Public Cloudは通信アプリケーションを受け入れる準備ができていませんでしたが、AWSの俊敏性には本当に感銘を受け、そこで私は自信を持ってシステムのコアをPublic Cloudに移行できると確信しました。
私たち双方が本当に学びを得るまでに3年かかり、現在ではFrankfurtリージョンで100万人のお客様がライブで利用しています。このプラットフォームに数百万人のお客様を移行できるという自信がますます高まっています。7月8日にこのデプロイメントを開始し、現在ではドイツで100万人の加入者が5G Standaloneを利用しており、2000万人までスケールアップする計画です。そこで、私たち自身に問いかけ、答えを見出そうとしている重要な質問は、Cloud Native Networksの学習曲線において、私たちはどの位置にいると考えているかということです。私たちは変曲点にいると考えています。過去2年間で多くのことを学び、2年半でライブ運用にまで至りました。
私たちはNokiaやMalik、そしてTelefónica Germanyと共に多くを学んできました。本当に厳しい教訓を得ることができました。成功の重要な要因は、私たちもパートナーも傲慢にならなかったことだと思います。そしてTelefónicaのようなお客様が本当に強く後押ししてくれました。期限を設定して本番稼働を目指すとなると、様々なことが起こるものですから。こうした大手企業が本気で取り組んでくれたおかげで、確かにまだまだ改善の余地はありますが、ここまで来ることができました。これから、私たちが学んだことについてさらに詳しくご説明させていただきます。
技術的な観点から、通信事業者の視点とネットワークアーキテクチャの観点で現状を見てみましょう。現在のネットワークは、私たちのモバイル端末、家庭用ゲートウェイ、家庭のWi-Fiネットワーク、TVサービスを提供するために、どのように設計・展開されているのでしょうか。現状では、従来型のRadio Accessベースのネットワークが主流です。もちろん、米国は少し進んでおり、Radio Access NetworkとPacket Coreにおいてクラウドベースのアーキテクチャを発表または展開している通信事業者がいます。業界はNon-Standaloneへの対応に苦心しており、先ほどMalikが言及したように、Standaloneコアへの移行も課題となっています。5Gが数年前に約束した機能は、Standaloneコアネットワークの展開とともに実現し始めるでしょう。音声ネットワークやIP Multimedia Systemネットワークは従来型の展開方式で、仮想化されていればCloud Nativeと考える人もいますが、自動化が組み込まれていなければCloud Nativeの基準を満たしていないと考える人もいます。つまり、現状のネットワーク展開はかなり静的なものとなっています。
これが、私がAWSに在籍している理由です。今日のパブリッククラウドのように、世界中に展開された大規模なインフラを消費するような世界を想像してみてください。多くの方がAWSのお客様やパートナーだと思います。クラウドは世界規模で展開された巨大なインフラです。そこには光ファイバーが敷設され、オフィスがあり、機器やサーバーが設置されたラックがあります。物理的なハードウェアは確かにそこにありますが、皆さんにはそれが見えません。仮想マシンを使用したい、Lambda関数を呼び出したい、コンテナランタイム環境が必要だと判断すれば、それがあなたの意図となり、要求に応じて実現されます。つまり、クラウドは、あなたの意図に基づいてオンデマンドでニーズを満たすことができる巨大なインフラなのです。
そして今、通信インフラが呼吸するように変化することを想像してください。つまり、吸気と呼気のように、スケールインとスケールアウトを行い、クラウドが実現できるような弾力性を提供できるようになるのです。これがAWSの視点から見た未来像です。通信インフラが完全に自動化されるのです。先ほど申し上げたように、私たちは何よりもまずクラウドカンパニーです。私たちは、将来の通信ネットワークを実現するために、自動化されたインフラ、つまりクラウドインフラを基盤として、ネットワークアプリケーションソフトウェアに提供することができます。それは呼吸するようなネットワークであり、企業や個人のお客様が必要なものと必要なタイミングを定義でき、サービスプロバイダーはトラックロールを行うことなくニーズを満たすことができます。Telefónica Germanyのように、ニーズに応じてスケールアップとダウンができるような方法でネットワークを設計・展開しているのです。
これが目標です。そして、ニーズの観点から見ると、通信ネットワークには、ミッションクリティカル性が求められます。常に利用可能である必要があります。これらの多くは国家インフラ資産として分類されています。私たちは低遅延、拡張現実、仮想現実、自動運転車など、これまで耳にしてきたすべてのユースケースについて話しています。そして、AIの時代が今後5年または10年でどのように展開されるかは、誰にも予測できません。そのため、スケールインやスケールアウトが可能で、お客様の要求や意図に応じてサービスを提供できる通信ネットワークにとって、決定的な遅延時間が重要な要件となります。そしてそれに伴い、データ量は少なくとも年間20%の割合で増加しています。
未来の「呼吸するネットワーク」の実現に向けたAWSの取り組み
このミニマリスティックな考え方は何を意味するのでしょうか？現在100ギガや10ギガを使用している場合、3年後にはデータ需要が2倍になるでしょう。これは、プロバイダーがインフラの俊敏性、ソフトウェアの俊敏性、そしてコミュニティ環境を持つ必要があることを意味します。特にインフラの俊敏性が重要です。先ほど申し上げた通り、将来的には呼吸するように伸縮できるネットワークが必要になります。これは、ソフトウェアだけでなく、基盤となるインフラもそのような能力を持つ必要があるということです。
これこそが、クラウドの可能性であり、私たちがTelefónica Germanyと構築してきたものが、Telcoネットワークの未来にとって大きな意味を持つ理由です。ミッションクリティカルな性質から、セキュリティと規制コンプライアンスは極めて重要な考慮事項となります。ドイツ市場は、規制の制約という観点から恐らく最も厳しい市場の一つです。転送中および保管時の暗号化に関する基準をクリアし、AWSが提供するテクノロジーが、オペレーターのビジネスのバリューチェーン全体とネットワークのトポロジー全体において、リージョンからエッジまで、AWS Cloudの連続性を支えることを確実にする必要がありました。
では、呼吸するように伸縮できるネットワークを構築するには何が必要でしょうか？スケールインとスケールアウトが可能な継続的なクラウドインフラストラクチャーが必要です。そして、レジリエンスを提供し、ミッションクリティカルな性質に対応し、低レイテンシーを実現し、セキュリティ要件を満たす必要があります。これは、オペレーターだけでなくISVにとっても複雑な道のりです。先ほど述べたように、私たちはTelco業界の主要なプレーヤーすべてと少なくとも6年間にわたって協力してきました。これには一貫性が必要です。なぜなら、オンプレミスのインフラストラクチャーがリージョンで実行しているものとは異なるコミュニティディストリビューションを実行していては、モデルが成り立たないからです。
次に、アーキテクチャの統一性について話しましょう。これは、私たちがNokiaのような技術と協力している分野であり、Telefónica Germanyと過去3年間にわたって行ってきたことです。長い道のりでしたが、それを隠すつもりはありません。むしろ、多くのことを学ばせていただきました。私たちは、完全なマネージド環境を提供するというビジョンを追求しています。これは、お客様が管理するのでも、システムインテグレーターが管理するのでも、AWSがインフラを提供するだけでもありません。私たちは協力して、ドイツ市場のエンドカスタマーが利用できる完全なマネージドサービスを提供しています。
この連続性、一貫性、統一されたアーキテクチャ、そして管理性が、クラウドオートメーションを実現します。 クラウドオートメーションは空から降ってくるわけではありません。意識的に検討しなければならない特定の必須要件があります。ここで、なぜAWS上に5G Coreを構築するのかを考えてみましょう。コスト改善と価値創出という2つのベクトルがあります。ある一定のポイントを超えると、コストの削減効果は逓減していきます。コスト削減とオートメーションは、人の介入を減らし、トラックロールを削減し、インフラの管理性を向上させ、完全マネージドサービスの展開を可能にします。運用のレジリエンスは、ミッションクリティカルな性質、低レイテンシー要件、セキュリティ上の考慮事項に対応します。
通信事業者のネットワークは国の重要インフラとして、低レイテンシー要件、セキュリティニーズ、サバイバビリティ基準を満たす必要があるため、極めて重要な性質を持っています。SLAを維持し、計画外の停止を減らしながら、インフラレベルでの継続的インテグレーションを可能にする運用の回復力が必要です。通信ネットワークは常時可用性が求められるため、新しいコードをデプロイするための停止は許されません。2日前に通知があったとしても、私たちは5分間の停止すら受け入れられないでしょう。
ビジネスアジリティについては冒頭で触れました。最初に何を言ったか覚えていますか？私たちには、意図に応じてニーズに対応できる、いわば呼吸するようなネットワークが必要なのです。これはどういう意味でしょうか？アジャイルなネットワークを持つということです。こんな例を考えてみましょう：私が自動車メーカーで、ある時点で車両との通信用のスライスを作成したいとします。何か発見をした時、そのスライスをすぐに作成したいのです。このスライスはコアだけでなく、伝送ネットワークやRadio Access Networkを通じて、車両まで届く必要があります。これこそが、私たちがビジネスアジリティの未来について語る際に意味することです。
だからこそ私たちは5G CoreとAWS をCloud Continuumを使って構築しているのです。なぜRadio Access Networkを構築するのでしょうか？これは私たちが集中的に取り組んできたことで、現在のTelefónicaではまだ実装していませんが、ネットワークトポロジー全体でそこを目指しています。Radio Access Networkの最終的なトポロジーとは何でしょうか？5Gネットワークでは？それがRadio Access Networkです。スライスを作成する時、それは5G Coreだけを意味するのではなく、Radio Access Networkも含みます。そのため、Cloud Continuumを5Gネットワークのベースバンドまで拡張する必要があります。これが、アーキテクチャの統一性と呼吸するような柔軟性を実現するために私たちが取り組んでいることです。
このセッションから一つだけ覚えて帰っていただきたいのは、私たちの生涯で、おそらく今後5年程度で、呼吸するようなネットワークを目にすることになるということです。実際に意図とニーズに基づいてオンデマンドで対応できるようになります。それは必ず実現します。これらすべてはAWS Cloud Continuumによって実現されており、私たちのインフラタイプについて説明しましょう。 AWS Regionsは、皆さんがご存知のAvailability Zoneで構成される巨大なデータセンターです。今日Mattが話していたように、Silicon、Compute、そして最も急成長している管理サービスであるAmazon EKSなど、すべてのイノベーションについて聞かれたと思います。 そして、メトロポリタンエリアレベルでAWS Local Zonesを発表し、 さらに、AWS Outpostsを通じて顧客のプレミス内に完全管理型のロバストなインフラストラクチャも提供しています。これは通信事業者のネットワークで使用されています。なぜなら、ほとんどの通信事業者ネットワークではプレミスで大量のコンピュート可用性が必要だからです。
これがビジネスバリューチェーンとネットワークトポロジー全体にわたる完全なスペクトラム です。同じAWS API、同じAmazon EC2、同じサービス - 似ているのではなく、まったく同じものです。これは重要なポイントです。なぜなら、多くの人が「似ている」と言うのを聞くでしょうが、そうではありません。完全に同一なのです。Regionで構築したものは、OutpostsやLocal Zonesでのテストを心配する必要はありません。これは私たちが業界に既に証明してきたことです。
Telefónica Germanyとの取り組みの一環として、私たちはAWS Outpostsにおけるパフォーマンス、TCO、自動化、そして完全マネージド体験に関する非常に具体的な要件を満たしています。これは私たちがすでに取り組んでいる内容で、具体的なビジネス課題に対応するものです。ここで要約して締めくくり、課題が何だったのかについて議論したいと思います。Malikはイノベーションを求めていたと言及しました。彼はすでに5Gネットワークと非スタンドアロン、5Gスタンドアロンネットワークを持っていました。
重点は、需要とインテントに基づいてスケールインとスケールアウトができる未来のネットワークを作ることです。これは、モノリシックなネットワークやモノリシックなアプリケーションから脱却することを意味します。解決策として、Regionであれ、Outpostであれ、トポロジー全体でセキュリティ要件を満たすことができるクラウドコンティニュアムを開発しました。同じアーキテクチャ、スケーリング機能、自動化フレームワークを維持しながら、異なる場所でのキャパシティプランニングを心配する必要がありません。これが私たちの実際の解決方法です。ビジネス成果として、現在100万人の顧客（主に大企業セグメント）がAWS上で運用されています。これらの顧客は、動的なサービスプロビジョニングに対してより高度な要求を持ち、その体験に対してプレミアムを支払う意思があるからです。
次のスライドは、コントロールプレーンとユーザープレーンのアーキテクチャを示しています。詳細は後続の議論で取り上げることができます。では、ここで主要なポイントをまとめましょう。私はAWSに8年間在籍しており、自己紹介をさせていただきます。私は、未来のネットワークを構築したいと考えるお客様やパートナーの要件と要望を満たすために存在しています。これが、AWSのTelcoセクターに焦点を当てたProduct Managementのディレクターとしての私の役割です。世界中の様々なパートナーやお客様とともに、ユースケース、設計上の考慮事項、選択肢について検討を重ねているチームがいます。
設計の選択について、とても鋭い観察をされました。もしお望みなら5Gコアネットワーク全体をRegionで実行することもできますが、それは何を意味するのでしょうか？すべてのキャッシュをRegionに移動し、異なるピアリングスキーマを使用する必要があります。それは単純な話ではありません。多くの人は基本的なパケット毎秒のスループット要件を満たすことだけを考えがちですが、それは当たり前の話です。私たちは本当にネットワークアーキテクチャの観点から考える必要があります。なぜなら、Telcoでは、CTOのように考える必要があるからです。ネットワークをどのように設計するか？様々なコンポーネントをどこに配置するか？YouTube、Facebook、その他のトラフィックであれ、トラフィック処理にどのような影響があるか？
私たちはこれらの考慮事項について検討を重ねてきました。そして、これは過去6年間で学んだ経験だと、謙虚ではありますが自信を持って申し上げることができます。私たちは、Region、AWS Outposts、Local Zonesのいずれかを選択した場合に生じる設計上の妥協点について、理解を深めるお手伝いができます。レジリエンスの姿勢はどうあるべきか、お客様がSLAに対してどの程度のプレミアムを支払う意思があるか、そしてそれらをどのように一緒により良く設計できるかについて議論できます。重点と強調点は、協力して取り組むことです。私たちは、お客様と協力し、設計上の考慮事項を検討し、運用チームとビジネスチームの視点から最適なアーキテクチャを決定する準備ができています。
セキュリティ、コンプライアンス、規制の観点から、AWS Nitroは基準を満たしており、詳細についてはご相談させていただきます。Telefónica Germanyとは1年がかりで、すべてのネットワーク要件に対応し、満足していただくための取り組みを行ってきました。自動化に関しては、万能なソリューションは存在しません。Network Geniusのようなフレームワークや、MLモデルの機能を活用するためのアーキテクチャのベストプラクティスがあります。継続的に統合、最適化、改善を行う自動化CI/CDパイプラインの構築について、ご一緒に取り組ませていただきます。最後のポイントとして、組織の現状と目指す姿、そして現在お持ちのテクノロジーと目指すテクノロジーの間には、非常に密接な相関関係があります。ご清聴ありがとうございました。ご質問がございましたら、お答えさせていただきます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion