📖

re:Invent 2025: GameLift StreamsでBandai Namco Gundam Metaverse構築

に公開

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら!

re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください

📖 re:Invent 2025: AWS re:Invent 2025 - Amazon GameLift Streams Powers Bandai Namco Entertainment's Metaverse (IND394)

この動画では、Bandai NamcoとAWSの共同プロジェクトであるGundam Metaverseの構築について解説しています。AWS Professional Servicesがインフラストラクチャ、ゲームサーバー、3D空間開発を担当し、ピーク時には80名のエンジニアが参画しました。Amazon GameLift Streamsを活用することで、20カ国以上に1080p/60fpsの低遅延ストリーミングを実現し、PCからモバイルまで単一ビルドで対応しました。マルチロケーションstream groupsによりリージョン管理を一元化し、Tokyo リージョン内で20ミリ秒以下のレイテンシーを達成しています。カスタムオートスケーリングとadaptive region auto scalerにより、コストとユーザー体験のバランスを最適化しました。さらにPuppeteerベースの自動化テストで数千人の同時プレイヤーをシミュレートし、Login with AmazonとAmazon APIを統合することで、メタバース内でシームレスなショッピング体験を実現しています。

https://www.youtube.com/watch?v=fOP_Or2gv8I
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。

本編

Thumbnail 0

Bandai NamcoとAWSによるGundamメタバース共同プロジェクトの概要

こんにちは、私は AWS のシニア プリンシパル ストラテジック エンゲージメント、田中正道と申します。このプロジェクトは Bandai Namco と AWS の共同プロジェクトで、本セッションを通じてメタバース空間をどのように構築したかについてお話しします。

Thumbnail 20

本セッションでは、このメタバース構築に使用した技術、具体的には3つの異なるソリューションについてお話しします。まず1つ目は AWS Professional Services です。皆さんの中で、プロジェクトで Professional Services を使用したことがある方はいらっしゃいますか?

Thumbnail 40

AWS Professional Services は、プロジェクトで複雑な課題が発生している場合に、ほとんどのお客様に提供しているサービスです。世界中のベストプラクティスを活用したストラテジック コンサルティングとテクニカル コンサルティングを提供し、プロジェクトを加速させます。また、Professional Services エンジニアによる実際の統合サービスも提供していますし、パートナーネットワークも活用できます。ですから、大規模なプロジェクトに対応して、最高の成果を提供することができます。2つ目は Amazon GameLift Streams という技術で、これを使用してユーザーがどのデバイスを使用していても、オンデマンドで低遅延のビデオストリーミングを提供することができます。このプロジェクトでは、例えばスマートフォンを使用しているユーザーに対して、Gundam メタバース空間をストリーミング配信することができました。また、Amazon API を使用して Amazon を空間に接続し、ワンクリックショッピングを実現しました。

Thumbnail 120

それでは、チーム構成についてお話しします。左側が Bandai Namco Entertainment チームで、本日はチームの2名の紳士にステージに登壇していただいています。右側が AWS Professional Services チームです。ピーク時には、このプロジェクトのエンジニア数は80名まで増加しました。Bandai Namco はこのプロジェクトの戦略立案、クリエイティブディレクション、品質管理を担当し、AWS Professional Services はインフラストラクチャ、ゲームサーバー、3D空間開発、およびプロジェクト管理を担当しました。

Thumbnail 170

Gundam という IP についてご存知かどうか分かりませんが、本セッションを開始する前に、Gundam Metaverse がどのようなものかをご理解いただくために、ビデオをご覧いただきたいと思います。

Thumbnail 180

Thumbnail 190

Thumbnail 200

Thumbnail 210

Thumbnail 220

Thumbnail 230

バンダイナムコエンターテインメントが目指すメタバース構築の背景とビジネス課題

  では、大森大介さんをステージにお迎えします。本日はご参加いただきありがとうございます。バンダイナムコエンターテインメントの大森大介です。バンダイナムコグループはキャラクターブランドを基盤としています。玩具、ゲーム、アニメーション、音楽、アミューズメント、これらを扱っています。

Thumbnail 260

グループ内では、私たちはコンソールゲームとモバイルゲームに注力するデジタルエンターテインメント企業です。毎年500以上のIPを扱っています。長く続いているタイトルから新作まで、世界中の人々にお届けしています。このスケールだからこそ、世代を超えて、地域を超えてファンをつなぐことが必要なのです。このプロジェクトでは、Mobile Suit Gundam という新しいチャレンジに取り組んでいます。Mobile Suit Gundam は1979年に始まりました。

Thumbnail 280

Thumbnail 310

Mobile Suit Gundam は1979年に始まりました。リアルな世界観と人間ドラマで知られています。それ以来、多くのテレビ作品や映画作品が続いてきました。何十年もの間、世界中の人々がこのIPを楽しんできました。では、ファンが世界中で集まる場所をどのように作り、コミュニティの成長をどのようにサポートするのか。それが、私たちがメタバースを構築している理由です。

Thumbnail 340

これが私たちが構築しているGundam メタバースのコンセプトです。まず、ファンが象徴的な世界観の中で一緒に体験し、ダンスができること。次に、アクセシビリティです。誰もが、いつでも、どこでも、どのデバイスからでも参加できること。そして3番目に、シームレスなジャーニーです。視聴して、ライブに参加して、ショッピングをする、すべてが一つの場所でできること。これら3つのコアアイデアを通じて、私たちは世界中のファンが集まり、本当の会話ができ、コミュニティの成長をサポートできる場所を作ることを目指しています。

Thumbnail 390

それでは背景についてお話しました。次に、私たちのビジネス上の課題についてです。まず、グローバルな接続性です。異なる地域とネットワークがある中で、誰もが1つの共有スペースに参加できるようなスケーラブルな方法が必要でした。次に、アクセシビリティ—いつでも、どこでも、どのデバイスでも滑らかな3D体験を実現することです。3番目に、1つの統合された体験です。動画を見たり、ライブに参加したり、ショッピングをしたりすることが、すべて1つの滑らかなジャーニーの中でできるようにしたいということです。AWS Professional Services と協力して、私たちはクラウド技術でこれを解決しました。

Thumbnail 450

AWS Professional Servicesによるクラウドインフラストラクチャとアーキテクチャ設計

次のページでは、AWS の Akinori がテクニカルな詳細についてプレゼンテーションします。皆さん、こんにちは。AWS Professional Services の Akinori です。このセクションでは、20カ国以上の Gundam ファンに提供されている Gundam Metaverse のシステムアーキテクチャについてご紹介します。

Thumbnail 460

まず、このプロジェクトにおける AWS Professional Services の役割についてハイライトしたいと思います。私たちはクラウドインフラストラクチャを超えた複数の領域にわたって包括的なサポートを提供しました。戦略的な計画支援から、メタバースアプリケーション開発の構築、学習、成長の各段階まで対応しました。戦略とアプリケーション両方に対する深い理解により、価値を最大化するグローバルにスケーラブルなクラウドインフラストラクチャを構築することができました。本日のセッションでは、特にクラウドインフラストラクチャの領域に焦点を当てます。

Thumbnail 500

こちらがGundam Metaverse のアーキテクチャ概要です。ユーザーフローに従って、各コンポーネントについて説明していきます。ステップ1では、プレイヤーが BANDAI NAMCO ID を使用して認証し、Web UI にアクセスします。次に、ステップ2が重要なポイントです。プレイヤーが Web UI にアクセスすると、クラウドゲーミング技術を使用して、AWS クラウド内の GPU インスタンス上でゲームアプリケーションが起動され、ゲームセッションが確立されます。

ステップ3では、プレイヤーがマウスとキーボード入力を送信することで、Web ブラウザを通じてゲームセッションにアクセスします。ステップ4に進むと、ゲームサーバーバックエンドは、他のプレイヤーの位置や動きなどの情報を共有することで、クライアントにオンラインマルチプレイヤー機能を提供します。ステップ5では、メタバース内で没入感のあるショッピング体験を提供するために、Amazon との統合を実装しました。ステップ6では、すべてのプレイヤーアクティビティログがアナリティクスプラットフォームに収集され、ほぼリアルタイムでダッシュボードインサイトを提供します。

Thumbnail 600

最後に、ステップ7では、クラウドゲーミング向けに最適化されたCI/CDパイプラインも実装しました。これにより、開発者はプレイヤーに対してスムーズにアップデートを配信することができます。

Thumbnail 650

このスライドでは、私たちのアーキテクチャで使用されている主要なテクノロジーを紹介しています。主要なテクノロジーには、ブラウザベースのメタバース体験向けのAmazon GameLift Streamsと、シームレスなショッピング体験向けのAmazon APIが含まれています。ゲームプラットフォームはUnreal Engine 5とNakama game serverで構築されています。開発プロセスでは、JetBrains TeamCityとPerforce HelixCoreを活用して、自動化されたビルドおよびデプロイメントシステムを実現しました。本日は、このプロジェクトの重要なコンポーネントであるAmazon GameLift StreamsとAmazon APIについて詳しく説明します。これら2つのサービスは、私たちのビジネス上の課題に対処する上で重要な役割を果たしました。Amazon GameLift Streamsはマルチリージョン、マルチプラットフォーム配信を実現し、グローバルなリーチとアクセス可能な体験を達成しました。Amazon APIはメタバース内でのAmazon製品のシームレスな購入を可能にし、没入感のあるショッピングを促進しています。

Thumbnail 690

以下のスライドでは、Amazon GameLift Streamsについてさらに詳しく見ていきます。Amazon GameLift Streamsが何かについて説明させてください。これは最近リリースされたAWSサービスで、ブラウザベースのゲーム配信を実現するものです。GameLift Streamsを使用すれば、ゲームはAWSクラウド内のGPUインスタンス上で実行でき、世界中のプレイヤーに対してオンデマンドで低遅延のストリーミングを提供できます。このストリーミング機能は、1080p解像度で毎秒60フレームまでをサポートしています。

Thumbnail 720

GameLift Streamsはグローバルなエンドポイントネットワークを通じて動作します。このマップに示されているように、ベータアクセス拠点を含む世界中の10つのリージョンにアクセスできます。この広範なカバレッジにより、プレイヤーを最も近いエンドポイントに接続することで、低遅延のストリーミングを提供することができます。Gundam メタバースの場合、このグローバルインフラストラクチャは異なるリージョン全体で一貫したパフォーマンスを提供する上で不可欠でした。

Thumbnail 760

GameLift Streamsのもう1つの強力な機能は、デバイスアクセシビリティです。ここに示されているように、テレビやタブレットからコンピュータ、さまざまなストリーミングデバイスまで、Webブラウザを備えたあらゆるデバイスでストリーミングが可能です。これにより、処理能力が限定されたデバイスにもゲーミング体験を提供することができます。その結果、私たちの潜在的なプレイヤーベースは大幅に拡大しました。

Thumbnail 800

このスライドは Gundam Metaverse の実際のゲームプレイ映像を示しています。 GameLift Streams を活用することで、ブラウザベースのメタバース体験を実現し、世界中 20 か国以上の Gundam ファンが互いにやり取りできるようになりました。さらに、当初は PC のみのサポートでしたが、GameLift Streams を使用することで、モバイルデバイスへのサポートを迅速に拡大することができました。

Thumbnail 830

以下のセクションでは GameLift Streams のアーキテクチャについて、2 つの重要な側面から詳しく説明します。まず 1 つ目は、マルチリージョンのスケーラビリティです。Gundam メタバースはグローバルなゲーム配信が必要でしたが、GameLift Streams により需要に応じてリージョンごとにスケールすることができました。また、リアルタイムおよびクロスリージョンのアクセスパターンを分析することで、キャパシティを最適化しています。2 つ目は、マルチプラットフォームのアクセシビリティです。GameLift Streams を通じたブラウザベースのアクセスにより、単一のビルドで複数のデバイスに配信することができました。また、標準的なブラウザベースのテストツールと統合した自動エンドツーエンドテストにより、品質を確保しています。

Amazon GameLift Streamsを活用したマルチリージョン・マルチプラットフォーム戦略の実装

これらの側面についてより詳しい情報をお伝えするために、Bandai Namco Entertainment の Natsuhiro Maruyama にバトンタッチしたいと思います。ありがとうございます。Bandai Namco Entertainment の Natsuhiro Maruyama です。Gundam メタバースの技術実装に関する思考プロセスについて、皆さんにご説明したいと思います。グローバルにアクセス可能にするための重要な要件は 2 つありました。

Thumbnail 910

Thumbnail 940

世界中どこからでも快適な体験を提供する必要があり、また任意のデバイスからのアクセスを可能にする必要がありました。 20 か国以上と 3 つのプラットフォームをサポートするマルチリージョン、マルチプラットフォーム戦略を採用しました。しかし、これには 4 つの技術的課題が伴いました。ネットワークレイテンシの最適化、動的キャパシティ管理、プラットフォーム体験の公平性、マルチプラットフォームテストフレームワークであり、それぞれが複雑なトレードオフを伴っています。

Thumbnail 960

ネットワークレイテンシの最適化には、対処すべき 3 つの追加課題がありました。各リージョンでレイテンシを最適化する必要があり、ユーザー需要に対応するために数千の GPU サーバーを確保する必要があり、グローバルに分散したインフラストラクチャの運用の複雑さを管理する必要がありました。これを解決するために、Amazon GameLift Streams の multi-location stream groups という機能を活用しました。この機能の利点は、プライマリロケーションでビルドを設定すると、GameLift Streams が自動的に同じバイナリを他のすべてのロケーションにデプロイするということです。

このようにインフラストラクチャ管理を一元化することで、複数のリージョンにわたって管理でき、エンジニアリングリソースと運用負荷を大幅に削減しながら、グローバルなデプロイメントを実現できました。パフォーマンスの面では、Tokyo リージョン内で 20 ミリ秒以下の低レイテンシーを実現し、Tokyo と Oregon リージョン間では 150 ミリ秒以下を達成しています。運用面では、単一の CI/CD パイプラインで複数のリージョンにデプロイでき、リリースサイクルを短縮し、開発速度を維持することができました。この機能を活用することで、クライアント側とサーバー側の責務を明確に分離でき、開発と運用の両方を大幅に簡素化することができました。

Thumbnail 1030

Thumbnail 1050

GameLift Streams を使用したリージョン選択の具体的な実装方法について説明します。まず、クライアント側で各リージョンへのレイテンシーを測定します。この例では、Tokyo リージョンへのレイテンシーが 20 ミリ秒、Oregon リージョンへのレイテンシーが 118 ミリ秒でした。 クライアント側で測定したレイテンシーに基づいて、レイテンシーの順序でソートされたリージョンを locations パラメータとして start stream session API に渡します。この例では、Tokyo が最初で Oregon が 2 番目です。GameLift Streams はこの順序でリージョンを評価し、最適なリージョンにセッションを自動的に割り当てます。割り当てられたリージョンは get stream session API で確認できます。

Thumbnail 1090

ご覧の通り、リージョン選択ロジックの実装は非常にシンプルでした。では次に、あるリージョンに利用可能な容量がない場合の動作を見てみましょう。 先ほどと同じように、Tokyo を最初に指定して start stream session API を呼び出します。GameLift Streams は Tokyo の容量をまず確認しますが、Tokyo に利用可能な容量がないとしましょう。その場合、次のリージョンである Oregon を自動的に確認し、そこに利用可能な容量があればセッションを割り当てます。重要なのは、クライアント側にリトライロジックを実装する必要がないということです。

Thumbnail 1140

Thumbnail 1160

これによってクライアントとサーバーの責務が明確になり、開発が本当に簡素化されました。複数のリージョンを順序立てて試すことで、セッション割り当ての成功率が向上し、全体的な運用がより安定しました。また、マルチロケーション stream group を使用することで、リージョンを簡単に追加できます。 ユーザー数が増えるにつれて、新しいリージョンを柔軟に追加できます。この例では、GameLift Streams コンソールを使用して 4 つのリージョン、Ohio、Frankfurt、Ireland、North Virginia を追加しました。これらの追加リージョンは、locations パラメータにリストとして渡すだけで すぐに機能します。この例では 6 つのリージョンを指定しています。Tokyo に利用可能なセッションがない場合、システムはリスト内の 2 番目のリージョンである Ireland にセッションを割り当てます。

Thumbnail 1190

ご覧の通り、マルチロケーション stream group によってグローバル環境でレイテンシーを最適化できました。しかし、ここで新しい課題に直面しました。それは、各リージョンの容量をどのように予測し、需要に応じて調整するかということです。 この動的な容量管理の課題を見てみましょう。考慮しなければならないトレードオフがあります。利用可能なセッションを増やすとユーザー体験が向上しますが、インフラストラクチャコストも増加します。

Thumbnail 1230

GameLift Streams には2つのオプションがあります。Always on は即座にアクセスできますが、コストが高くなります。一方、On-demand は起動に60秒以上かかりますが、動的にスケーリングします。それぞれにメリットとデメリットがあり、どちらか一方だけではこのトレードオフを本当に解決することができません。Gundam メタバースの場合、私たちはプレイヤー体験を優先するために always on オプションを選択しました。これをコスト最適化とバランスさせるために、私たちは2つのアプローチを実装しました。

1つ目はカスタムオートスケーリングです。これは需要に応じて always on の容量を動的に調整します。詳しくは次のスライドで説明します。そして2つ目のコンポーネントは adaptive region auto scaler です。通常の状況下では、アジアのユーザーを Tokyo リージョンに、その他の地域のユーザーを Oregon リージョンに統合しており、これはインフラストラクチャコストが最も低くなります。しかし、利用可能なセッションが少なくなったり、ネットワークレイテンシが増加したりすると、追加のリージョンが自動的に有効になり、最大6つのリージョンまで拡張されます。これにより、必要最小限のリージョンで運用しながら、需要の急増に柔軟に対応することができます。

Thumbnail 1290

これら2つのアプローチにより、コストとユーザー体験のバランスを最適化しています。では、カスタムオートスケーリングに戻って、もう少し詳しく説明させていただきます。まず、GameLift Streams の基本的な概念について説明します。3つの重要なメトリクスがあります:desired capacity、allocated capacity、そして idle capacity です。Desired capacity はリクエストする総容量であり、2つの部分で構成されています。Allocated capacity は実際に使用中の容量で、idle capacity は実行中だがまだセッションに割り当てられていない容量です。

例えば、desired capacity が100の場合、allocated capacity は70で、idle capacity は30になるかもしれません。良いユーザー体験を維持するには、一定数の idle capacity を確保しながら、スケールインとスケールアウトの操作を適切に実行して、無駄なコストを削減する必要があります。したがって、これら3つのメトリクスすべてを考慮したカスタムロジックを実装しました。次のスライドでこの実装について詳しく説明します。

Thumbnail 1360

GameLift Streams 専用のカスタムオートスケーリングロジックは、EventBridge によって1分ごとにトリガーされる Lambda 関数に実装されています。このダイアグラムは Lambda 関数の実装を示しています。まず、Lambda は GetStreamGroup API を使用して、現在の desired capacity、allocated capacity、および idle capacity メトリクスを取得します。その後、surplus rate を計算します。これは idle capacity を desired capacity で割ったものです。

この余剰率が30%以下の場合、アイドル容量が低いと判定され、新しいユーザーを受け入れることができないため、UpdateStreamGroup APIを呼び出して目的の容量を増やします。逆に、余剰率が50%以上で容量が過剰な場合は、スケールインします。このような動的容量管理を実現することで、コストとユーザー体験のバランスを取ることができました。

Thumbnail 1420

プラットフォーム体験の公平性確保と自動化されたマルチプレイヤーテストフレームワーク

次に、マルチプラットフォーム戦略に関連する技術的な課題について説明します。ここで私たちが直面する技術的課題は2つあります。1つ目はプラットフォーム体験の公平性です。すべてのデバイスにおいて公平な体験をどのように提供するか、ということです。そして2つ目はマルチプラットフォームテスティングフレームワークです。多様なプラットフォーム全体で品質をどのように確保するか、ということです。これら2つの課題にどのように対処しているかを説明します。

Thumbnail 1470

Gundam メタバースは、PC、iOS、Androidなど、あらゆるデバイスでプレイできるように設計されています。Webブラウザから送信されるユーザーエージェントヘッダーを使用してデバイスを識別し、それに応じてWeb UIレイアウトを切り替えます。PCおよびモバイルデバイスでゲームにプレイヤーコントロール入力を適切に送信するために、GameLift Streams の Web SDK をブラウザに実装しました。Web SDK には、キーボードとマウス入力のデフォルト機能、および自動コントローラー認識が付属しています。

Thumbnail 1500

さらに、仮想ゲームパッドを追加し、カスタムキーマッピングを指定することも可能です。Gundam メタバースでは、モバイルデバイス操作用に仮想ゲームパッドを実装しました。このスライドはモバイルユーザー向けの仮想ゲームパッドの実装例を示しています。左側には UI コンポーネント定義が表示されています。ジョイスティックとボタンをプレイヤー操作用のイベントリスナーとともに定義します。

右側には SDK 統合コードが表示されています。まず、仮想ゲームパッドオブジェクトを作成し、GameLift Streams SDK に登録します。その後、ブラウザイベントが発生すると、それを受け取って仮想ゲームパッドの軸とボタン入力に変換します。最後に、process game pads を呼び出すことで、これらの入力が GameLift Streams 上の Unreal Engine クライアントに送信されます。

それでは、このテクニカルセッションの最後に、クラウドゲーミングに特有な開発環境についてお話しします。従来のマルチプラットフォーム開発では、通常、様々なデバイス向けに別々のバイナリを作成し、各プラットフォームごとに QA でテストを実施する必要があります。しかし GameLift Streams では、ブラウザがすべての入力を処理し、サーバーはビデオをストリーミングするだけなので、1 つのバイナリで複数のプラットフォームに対応できます。これにより開発プロセスが大幅に簡素化され、より迅速なイテレーションが可能になります。さらに、ブラウザベースであるため、ウェブオートメーションツールがシームレスに機能し、大規模なマルチプレイヤータスクを簡単に実行できます。

Thumbnail 1550

Thumbnail 1590

Thumbnail 1610

マルチプレイヤーシナリオを大規模でテストするために、複数の GameLift Streams インスタンスをスピンアップして、ブラウザのインタラクションをシミュレートします。Amazon ECS の Step Functions を使用して、Puppeteer ベースのヘッドレスブラウザを起動し、自動化された操作を実行してセッションを Amazon S3 に記録します。 このビデオは、Puppeteer がスケーラブルなエンドツーエンドテストをどのように実現するかを示しています。複数のクライアントを自動的にスピンアップし、ブラウザを制御し、ログインを処理し、ゲーム内アクションを実行します。これらのセッションを数百個並列で実行することで、数千人の同時プレイヤーをシミュレートできます。すべてのタスクが記録されるため、営業時間後や修正後など、いつでも問題を検証できます。これにより、複数のユーザーが同じサーバーに同時に接続したときにのみ発生する問題を特定することができました。興味深いことに、これらの問題はサーバーモニタリングでは見えませんでした。これはクラウドゲーミングプロジェクトに予期しない利益をもたらし、ゲーム開発全体の品質を大幅に向上させました。

Thumbnail 1690

Amazon APIによるシームレスなショッピング体験の実現と今後の展開

それでは、クラウドゲーミングについてのテクニカルウォークスルーはここまでとなります。AWS の Mass をもう一度ステージにお招きして、Amazon との統合についてお話しいただきます。ありがとうございました、Natsu。それでは、Amazon を通じて実現した Gundam メタバースにおけるイマーシブなショッピング体験についてご紹介します。Gundam メタバースでは、メタバース空間内でシームレスなショッピング体験を実現するために、Login with Amazon と Amazon API という 2 つのテクニカル要素を活用しています。

Thumbnail 1700

Thumbnail 1710

Thumbnail 1740

Amazon と統合されたシームレスなショッピング体験では、プレイヤーはメタバース空間を離れることなく、商品を発見して購入できます。 より具体的には、ユーザーはメタバース空間内で Amazon の商品詳細、価格、顧客配送情報を取得でき、購入することを決めたときにボタンを押すだけで、その情報が Amazon に送信され、あなたのもとに配送されます。Gundam メタバースでは、2 つのテクニカル要素を使用して、このようなシームレスなショッピング体験を実現する Amazon 統合メタバースショップを開発しました。その 2 つのテクニカル要素について詳しくお話しします。1 つは Login with Amazon で、もう 1 つは Amazon API です。

Thumbnail 1760

このダイアグラムは Amazon統合メタバースショップのアーキテクチャを示しています。プレイヤーが初めてショップを訪れると、Login with Amazon を使用してログインするよう促されます。ボタンをクリックすると、情報を入力し、その情報がメタバース空間内のアカウントに接続されます。その後、プレイヤーは商品を閲覧して購入できます。必要なのはボタンをクリックするだけで、すべての情報が API 経由で Amazon に送信されます。注文が確定すると、注文情報は Amazon 内で処理され、Amazon を通じて購入品が配送されます。また、Amazon ウェブサイトを使用してカスタマーサポートにアクセスすることもできます。

Thumbnail 1810

では、Amazon との Login with Amazon の統合方法について詳しく説明していきます。 Login with Amazon は、ユーザーがメタバース空間などの任意のスペースに自分のアカウントをリンクする方法を提供しています。Gundam Metaverse では、ユーザーが Login with Amazon ボタンを押すと、メタバースショップがオーバーレイとして表示される Web 画面をポップアップします。なぜオーバーレイを使用するのかについて説明します。

Thumbnail 1850

Gundam Metaverse はクラウドゲーミング上で動作しており、クラウド上で動作していないため、Amazon アカウントを常にリンクする必要がありました。これにはいくつかの問題がありました。通常、Amazon アカウントをリンクするには、利用規約とプライバシーポリシーを表示する認証画面を表示し、ユーザーがユーザー名とパスワードを入力する必要があります。その後、権限確認画面を表示する必要があります。かなり多いですよね? そのプロセス中にユーザーがドロップオフしてしまうと、もう一度タスクをやり直す必要があります。

Thumbnail 1910

この問題を解決するために、オーバーレイを使用することにしました。Web 画面はユーザーの PC 上のキャッシュを利用できますが、クラウド上でこれを行う場合、それは不可能です。 これらの問題に対処するために、PC キャッシュを使用して認証画面を実装するために、プレイヤーの PC 上のメタバースゲーム外部にオーバーレイ Web 画面を実装しました。これにより、その後の Amazon API ユーザーの認証トークンを取得でき、また購入時のユーザーアクションを取得する方法も作成しました。

Thumbnail 1940

Thumbnail 1960

このページは実装例を示しています。ご覧のように、すべてをゼロから作成する必要なく、Amazon の標準認証画面を実際に表示できるようにする少量のコードを実装しました。 次に、メタバース内での Amazon API の使用例について説明します。API を使用することで、Amazon で利用可能なあらゆる情報を取得できます。例えば、ユーザーは商品の詳細情報と配送タイミングを確認でき、注文をプレビューできます。すべての情報を確認して購入することを決めたら、ボタンをクリックするだけで、すべての情報が API 経由で Amazon に送信されます。

Thumbnail 2010

API を通じて、ユーザーが購入ステップのどこで実際にドロップオフしたかを追跡し、ショップ設計に役立つデータを収集することができました。 最後に、購入後のプロセスは確実に説明しやすいです。Amazon.com ウェブサイトで購入するときと同じです。メタバース内で注文を購入した後、Amazon から商品を受け取り、ウェブサイトを使用して顧客サービスを含む Amazon との任意のタイプのやり取りを行うことができます。このメカニズムは基本的に Bandai Namco にバックエンドを持たないショッピング体験を作成する能力を提供しました。彼らがしなければならなかったのは、Amazon API を使用して Amazon への接続を作成し、自分たちの商品を Amazon に配置することだけです。それだけです。

Thumbnail 2060

Thumbnail 2070

それでは Gundam Metaverse についてのプレゼンテーションを終わります。このセッションからの主なポイントはこちらにまとめられています。 まず1つ目は、地域的にスケーラブルな metaverse の開発です。2つ目は、カスタム auto scaling を通じたコストと体験の最適化です。3つ目は、自動化された end-to-end testing によるサービス品質の向上です。そして最後になりますが、シームレスなショッピング体験を提供するために Amazon を統合しました。このインサイトが皆さんの今後の参考になれば幸いです。それでは次のお話について、Omorian にマイクをお渡しします。

Thumbnail 2120

Thumbnail 2180

最後に、これからの展開についてお話しします。 Metaverse テクノロジーは様々なビジネスに活用できます。私たちはまず character metaverse から始めて、同じベースから digital twins、simulation、training へと拡張していくことができます。このセットアップにより、小さな 3D spaces を素早く立ち上げて、安定した品質のまま世界中に展開することができます。私たちはシステムの standard backend、front-end、client を構築しており、パートナー企業もこれを活用できるようにしています。既に複数のパートナーが私たちと一緒に新しい spaces の構築を始めています。私たちはパートナーと実際のユースケースに取り組んでいます。ご興味がございましたら、re:Invent でこちらまでお気軽にお声がけください。本日はお時間をいただき、ありがとうございました。皆さんと私たちの取り組みを共有できて、光栄です。


※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。

Discussion