はじめに Turing では、日々たくさんの自動運転モデルを開発し、これを実車にデプロイして検証する開発サイクルを回しています。実世界でMLモデルによる自動運転システムを成立させるためには、モデル推論のレイテンシが非常にクリティカルな要素になってきます。モデルを高速に推論させるためには、低精度化や量子化、あるいはモデルの構造によってはKV Cacheなど、様々な手法が考えられます。 しかし、色々なアーキテクチャのモデルを大量に開発するTuring において、そのすべてにこうした技術を適用できるソフトウェアスタックを構築することは容易ではありません。今回の記事では、高速化技術を適用する

AWS にいる間、私はいつも学生と一緒に働く機会を探していました。私は地域の大学で 50 回以上の講演を行ってきましたが、会場で可能性を観察することは常に強いモチベーションになっています。それは、なぜ私がこの仕事をしているか、また今日会う学生が明日私たちの顧客や協力者になるかもしれないということを思い出させてくれます。それが、私が 2026 年 8 月 24 日週に AWS Builder Center で学生リワードを提供できることを嬉しく思う理由です。 Rick Suttles 氏が「 AWS Builder Center での学生リワードの紹介 」を公開しました。これは、認定を受けた高等教育学生向けの新しい特典です。SheerID を通じて登録を確認し、Builder Center プロファイルを完了すると、12 か月間のプレミアム AWS Skill Builder アクセス (900 以上のコース、ハンズオンラボ、認定試験の準備、ゲームベースの学習) がロック解除されます。そこから、Builder Center でのアクション (記事の公開、コメント、エンゲージメントの維持) を通じてバッジを獲得できます。バッジが 7 個になると、10 USD の AWS クレジットをロック解除できます。バッジが 14 個になると、さらに 20 USD のクレジットが得られます。バッジが 21 個になると、AWS 基礎認定試験バウチャー (100 USD 相当) を獲得できます。 これは、この新学期シーズンに 5 億 USD 以上のリソースのコミットメントを表しており、クラウドと AI でのキャリア構築を始めるために必要なトレーニング、ツール、認定資格を学生に提供します。学生リワードは、世界中の認定高等教育機関に在籍している 18 歳以上の学生を対象としています。ただし、検証と利用規約の対象となります。 学生のステータスを確認して 、学習を開始し、バッジを獲得し、リワードをロック解除しましょう! 2026 年 8 月 17 日週のローンチ その他、8 月 24 日週に発表された事項をご紹介します。 ネバダ州ラスベガスの新しい AWS ローカルゾーン — この新しいローカルゾーンは、Amazon EC2 C7i、M7i、R7i、C8gn インスタンス、Amazon EBS、Amazon ECS、Amazon EKS、Application Load Balancer、AWS Direct Connect をサポートします。AWS ローカルゾーンは、世界中の 30 を超える大都市圏で利用できるようになりました。さらに、AWS は 欧州 (ロンドン) リージョンに 4 つ目のアベイラビリティーゾーン を追加し、汎用コンピューティングに加えて Trn3 と P6 の高速インスタンスによる次世代 AI と ML のキャパシティを提供しました。 Amazon EC2 Auto Scaling がバッチインスタンスの終了をサポートするようになりました – 最大 100 個のインスタンス ID を TerminateInstanceInAutoScalingGroup API に渡してバッチとして終了できるようになりました。これにより、自動スケーリンググループのスケールダウンに必要な API コールの数が削減されました。バッチ終了は、AI/ML トレーニングジョブ、コンテナオーケストレーター、または一時的に大規模なフリートをスピンアップするイベント駆動型アーキテクチャなど、迅速なスケールダウンが必要なワークロード向けに設計されています。 AWS CloudShell に組み込みのビジュアルファイルエディタが含まれるようになりました – CloudShell には、単一の編集コマンドを使用してシェルセッションから直接起動できるビジュアルファイルエディタが含まれるようになりました。このエディタは、シンタックスハイライト、検索と置換、複数行選択、コピーアンドペースト、元に戻す/やり直すを単一のブラウザセッションでサポートしています。デプロイスクリプトの更新、エージェントステアリングファイルの変更、CloudFormation テンプレートの編集、Lambda 関数の修正のいずれを行っている場合でも、このエディタは CloudShell から離れることなくシームレスに編集して実行できるようにします。 Amazon Bedrock がクロスリージョン推論による SpaceXAI Grok 4.6 をサポートするようになりました – コーディング、エージェントタスク、ナレッジワーク向けに構築されたフロンティアモデルである Grok 4.6 が、Amazon Bedrock 上で利用できるようになりました。 このモデルは、レスポンス、チャット完了、コンバース API をサポートする bedrock-runtime エンドポイント上で実行され、モデル呼び出しログ記録、Amazon CloudWatch メトリクス、AWS Cost Explorer のコスト項目化など、既存のアカウントレベルのコントロールと連携します。 Amazon Bedrock が API サポートを拡張し、OpenAI モデルにクロスリージョン推論を導入しました – Amazon Bedrock が、レスポンス、コンバース、チャット完了 API で OpenAI GPT-5.6 モデル (Sol、Terra、Luna) をサポートするようになり、クロスリージョン推論が追加されました。地理的クロスリージョン推論は、事前定義された地域内でリクエストをルーティングします (今回のローンチでの米国地域サポートを含む)。一方、グローバルクロスリージョン推論は、低いトークンあたりのコストで、あらゆる商用 AWS リージョンからのリクエストを処理します。 AgentCore 支払いが Amazon Bedrock AgentCore で一般的に利用できるようになりました – 一般提供時点では、AgentCore コンソール内での Coinbase 認証情報の直接プロビジョニングのためのクイック作成、AgentCore Gateway を介した従量課金型の x402 エンドポイントの厳選された Coinbase Bazar MCP サーバー、Machine Payment Protocol (MPP) のサポート、および x402 プロトコルの「upto」スキームが含まれます。推論に応じた料金とダイナミックプライシングのユースケースに対応します。詳細については、 AI ブログの記事 をご覧ください。 AWS Glue 6.0 が 30% の料金引き下げと Iceberg v3 のサポートを提供 – AWS Glue 6.0 は、完全にモダナイズされたランタイム、Apache Spark 4.1、Python 3.13、および Scala 2.13 に基づいて構築されており、以前の AWS Glue バージョンよりも 30% 低い料金を提供しています。Iceberg v3 では、Glue 6.0 には、半構造化データの読み取りを高速化する自動シュレッダー処理、高性能な行レベルの更新のための削除ベクトル、空間処理用のジオメトリおよび地理データ型、および柔軟なスキーマ展開機能を備えた VARIANT データ型が追加されました。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース お客様に役立つ可能性のある記事をさらにいくつかご紹介します。 AWS サインインエクスペリエンスの更新 – AWS では、サインインおよびサインアップエクスペリエンスの更新を徐々に導入しています。再設計されたサインインページでは、新しい E メールベースのサインイン方法を使用するルートユーザーと顧客のための統一された E メールエントリポイントが導入され、IAM ユーザーは引き続きアカウント ID、ユーザー名、およびパスワードを使用してサインインできます。このページには、サポートされている ID プロバイダー (Google、GitHub、Apple、または Amazon.com) を使用して AWS アカウントを作成した顧客向けのサインインオプションも含まれています。再設計されたセッション選択ページにより、複数のアクティブなアカウントおよびロールセッションの表示と管理が簡素化されました。サインインページを操作するブラウザ自動化またはスクリプト化されたワークフローに組織が依存している場合は、投稿を確認して、これらの変更が構成にどのように影響する可能性があるかを理解してください。 開発中: ベルリン、ハイデラバード、サンパウロの AWS Builder Loft – 私の同僚の Channy が 3 つの都市に新しい Builder Loft をオープンする計画を発表しました。2025 年 7 月にサンフランシスコに最初の Builder Loft がオープンして以来、22,500 人以上の開発者を迎えてきました。新しい場所はそれぞれ、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ制作スペース、コワーキングエリアを提供する常設コミュニティスペースになります。ベルリンはデジタル主権とセキュリティ対策に、ハイデラバードは AI とクラウドネイティブアーキテクチャに、サンパウロはラテンアメリカの開発者エコシステムのサポートに焦点を当てます。 AWS と Amazon WorkSpaces が 2026 Gartner Magic Quadrant for Desktop as a Service のリーダーとして認められました – AWS は、ビジョンの完全性と実行能力が評価され、2026 Gartner Magic Quadrant for Desktop as a Service (DaaS) で、3 年連続でリーダーに選ばれました。Gartner は、オペレーション、地理的戦略、および全体的な存続可能性に強みがあると認めました。また、人間のユーザーと同じデスクトップ環境、セキュリティ境界、および監査証跡内で AI エージェントを実行する機能である Amazon WorkSpaces for AI エージェントが評価対象になったのは今年が初めてです。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 近日開催される AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – ビルダーやイノベーターがクラウドで最新情報を学び、交流し、探求するための無料の対面イベント。開催予定: チューリッヒ (9 月 2 日)、 サンパウロ (9 月 3 日)、 テルアビブ (9 月 10 日)、 ドバイ (9 月 30 日)。また、 AWS Summits Global Livestream + On-Demand Hub で基調講演やセッションを視聴することもできます。特定の Summit のライブコンテンツやオンデマンドコンテンツにアクセスするには、そのイベントに登録する必要があります。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。今後のイベントには、 ボリビアのサンタクルス (8 月 29 日)、 カナダのトロント (8 月 29 日)、 東京の JAWS SONIC (9 月 5 日)、 ポーランドのワルシャワ (9 月 8 日) などがあります。 AWS Builder Center にアクセスして、他のビルダーと交流したり、ソリューションを提供したり、構築を継続するのに役立つリソースを見つけたりしましょう。 夏も徐々に終わりに近づいています。私は、これから雨の多い秋を乗り切るために、今後数か月のうちに数日の休みを計画しています。お客様も同じように計画していることを願っています。8 月 31 日週もまた新しいニュースをお届けしますので、お楽しみに。 – Esra 原文は こちら です。

はじめに 株式会社セガは、家庭用ゲーム機、PC、スマートフォン向けゲームの企画・開発・販売・運営を軸に、各種コンテンツや商品を全世界へ届けています。同社では、比較的新しい技術も積極的に取り入れる文化のもと、複数タイトルで AWS を活用してきました。 本記事では、同社が開発・運用する『ソニックランブル パーティ』のバックエンドに Amazon DynamoDB と Amazon ElastiCache Serverless for Valkey を採用した経緯・技術的な工夫・得られた効果を、開発チームの声を交えて紹介します。 ※本画像は株式会社セガの許諾を得て掲載しています 『ソニックランブル パーティ』は、Dr.エッグマンが作り出したおもちゃの世界で、「ソニック」シリーズの人気キャラクターたちがスリリングな障害物コースや競技アリーナで競い合うマルチプレイパーティーゲームです。スマートフォンと PC のクロスプレイに対応し、2024 年初頭に一部地域でソフトローンチを行い、2025 年 11 月にグローバルローンチを迎えました。 解決したかった課題 グローバルに展開する Games as a Service（GaaS）のバックエンドを、少人数のチームで開発・運用できるようにすること。これが本タイトルの大前提であり、データベース選定でも最優先の要件でした。マネージドサービスを最大限活用し、インフラ運用の負荷を極力排除する方針のもと、データベースには次のような要件がありました。 グローバル規模でスムーズにスケールできること ：需要が読みにくいグローバル展開では、トラフィックの伸びに安定して追従できることが必要でした。Amazon Aurora では、API サーバーを増やすほど、各サーバーが保持するコネクションプールの分だけ DB への接続数が積み上がり、DB の接続数の上限が API サーバーのスケールの制約になりやすい構造がありました。 リソースのサイジング・管理からの解放 ：ストレージ容量・CPU 性能のサイジングや、ユーザー分割（シャーディング）に伴う複数クラスターの運用といった、リソースを自分たちで管理し続ける作業そのものをなくし、キャパシティを気にせず開発に集中したいという要望がありました。 データ量が増えても安定したレイテンシー ：数千万人規模のデータを持っても、応答性能（レイテンシー）が変わらないことが求められました。 稼働の波・スパイクへの対応 ：ローンチ時のトラフィックが読みにくく、また「最初は大きく構え、後から縮小できるようにしておきたい」というゲーム業界特有の事情に、無駄なく追従できることが重要でした。 なぜ DynamoDB / ElastiCache Serverless for Valkey を選んだのか DynamoDB 採用の決め手 複数のデータベース／クラウドサービスを比較検討したうえで、DynamoDB を採用しました。前述の課題を踏まえ、次の点が決め手となりました。 サーバーレスで、実質無制限のスケーラビリティを持つこと メンテナンスウィンドウやバージョン管理を意識せず、運用し続けられること 接続数・ストレージ・CPU といったリソース管理から解放されること ElastiCache Serverless for Valkey 採用の決め手 メインデータベースである DynamoDB への読み取り負荷を抑え、レイテンシーとコストを最適化するために、インメモリのキャッシュ／データストアとして ElastiCache を採用しました。ElastiCache は当初 Redis OSS エンジンのノードベース構成で構築を開始し、その後 Redis OSS 互換の Valkey エンジンによる Serverless 構成へ移行しました。Serverless を選んだ決め手は次の点です。 ノードベースのクラスターモードで必要だったシャードやクラスターの構成・管理から解放され、少人数チームでも運用できること 「立ち上げ時は大きく構え、ローンチ後は規模に合わせて縮小・最適化していく」というゲーム特有の需要変動にキャパシティが自動で追従し、過剰なリソースを抱えずに済むこと 冗長化構成を自分たちで設計・管理しなくても、高可用性が標準で備わること アーキテクチャ概要 主要なコンポーネントと役割は次の通りです。 Amazon DynamoDB（メインデータベース） ：主要なゲームデータを格納する永続データストア。ユーザーデータ（プロフィール・所持アイテム・進行状況等）とログデータ（行動ログ）を、基本的にシングルテーブル設計で管理しています。 Amazon ElastiCache Serverless for Valkey（キャッシュ／リーダーボード） ：ユーザーデータのキャッシュ、マッチメイキング処理の作業データ、リーダーボード（Sorted Set）などに利用。用途別に汎用の Common とリーダーボード専用の Ranking の 2 つに分けています。 Amazon ECS on EC2（API サーバー） ：API・マッチメイク・行動ログ集計加工の各アプリを配置しています。 Amazon EKS Auto Mode + Agones ：専用ゲームサーバーを管理しています。なおこちらの詳細は別記事 「株式会社セガ、グローバル展開タイトル『ソニックランブル パーティ』を少人数チームで支える Amazon EKS Auto Mode × Agones 活用事例」 にてご紹介しています。 技術的に工夫した点 1. シングルテーブル設計とキー設計 チームはこれまでリレーショナルデータベース（RDB）の Aurora が中心で、DynamoDB の知見はほぼゼロからのスタートでした。DynamoDB は RDB のように join や任意条件での柔軟なクエリができません。RDB でもインデックス設計は行いますが、DynamoDB では、想定するアクセスパターンに合わせてキーや GSI（グローバルセカンダリインデックス）、データを非正規化してどう持つかまで含めて先に設計する必要があり、アクセスパターンがデータモデルそのものを規定します。本タイトルはユーザーデータ・アカウント・フレンド・ギルド（クルー）・ランキングなどエンティティが多く、かつ各エンティティに複数の検索軸（ユーザー ID・アカウント ID・フレンドコードなど）が必要でした。 そこで、全エンティティを 1 つのテーブルに集約するシングルテーブル設計を採用しました。各アイテムのキーに「エンティティ名」の接頭辞を付けて名前空間を分離し、検索軸は汎用的な GSI をエンティティ横断で使い回す設計としています。 たとえばアカウントデータのキー設計は次のようになっています。 キー 型（命名ルール） 具体例 用途 PK {エンティティ名}#U{ユーザーID} AccountDataEntity#U0001 ユーザー ID で引く（基本アクセス） GSI1 {エンティティ名}#A{アカウントID} AccountDataEntity#A5555 アカウント ID で検索 GSI2 {エンティティ名}#F{フレンドコード} AccountDataEntity#F9999 フレンドコードで検索 GSI3 {エンティティ名}#T{引き継ぎID} AccountDataEntity#T1234 引き継ぎ ID で検索 ※「具体例」は実際の値のイメージです。 参照時は、同じ GSI に対してエンティティ名付きのキーを指定するだけです。たとえば GSI1 は、アカウント検索にもギルド（クルー）検索にも同じ 1 本を使い回します。 例 1：アカウント ID 5555 のアカウントを引く Query (index = Gsi1, P1 = "AccountDataEntity#A5555" ) 例 2：同じ GSI1 で、今度はギルド（クルー）”Dragons” を引く Query (index = Gsi1, P1 = "CrewEntity#Dragons" ) このように、少数の汎用 GSI をエンティティ横断で使い回すことで、インデックスの本数を抑えつつ、多様な検索軸に対応できます。RDB 中心だったチームにとっても、移行そのものは想定より円滑に進みました。一方で、GSI を使いこなせるようになるまでには数か月を要し、負荷試験時に GSI のキャパシティ不足に気づきにくいといった学習コストもありました。 2. トランザクションを使わず楽観ロック中心の設計 コストと性能を考慮し、トランザクションは採用せず、楽観ロック中心の設計としました。実装には、AWS SDK のオブジェクト永続化モデルが備えるバージョン属性による楽観ロックを利用し、必要な場面では SkipVersionCheck（バージョンチェックの無効化）を使い分けられるよう、データアクセス層を設計しています。 一方、ギルド（クルー）機能のように複数ユーザーが同一データを同時に更新する機能では整合性の担保が重要になるため、そうした箇所では Valkey によるロックを用いて競合を防いでいます。 3. リーダーボードのホットキー対策 ランキングは、ElastiCache（Sorted Set）でライブに集計・配信する一方、スコアはユーザーデータとして DynamoDB にも永続化しています。この DynamoDB 側のランキング用 GSI では、同一のランキング（単一のパーティションキー）に多数のプレイヤーの書き込みが集中し、特定のパーティションがホットになりやすいという課題がありました。 そこで、ランキング用 GSI のパーティションキーにユーザー ID の下 4 桁によるシャード分割（P1 = …#Shard{ユーザーID下4桁}）を導入し、書き込みを複数のパーティションに分散しています。ランキング全体の参照時は、集計タスクで各シャードを集約する構成です。 一方、キャッシュ側の ElastiCache Serverless にも同種の考慮が必要でした。ElastiCache Serverless は常にクラスターモードで動作するため、同一スロット制約を踏まえ、マルチキー操作は関連するキーを同一ハッシュスロットに寄せる（ハッシュタグを使う）キー設計が求められます。その分キーが偏る（ホットスロット化）リスクもあるため、トレードオフを意識する必要があります。本タイトルでも、設計当初にこの点を意識しておくとよいという気づきがありました。 4. グローバルローンチの急なトラフィックへの対策 2025 年 11 月のグローバルローンチは、トラフィックが読みにくい最大の山場でした。事前の暖機（ウォームアップ）として、次の対応を行いました。 DynamoDB ：Warm Throughput を利用し、マネジメントコンソールから必要なスループットを引き上げるだけで暖機が完了しました。手動でのプロビジョンドスループット調整（引き上げ後にオンデマンドへ戻す運用）と比べ、手間を大きく削減できました。 ElastiCache Serverless ：ローンチ前に最低 ECPU を設定するだけで事前に暖機できました。ローンチ後は通常運用に戻すのみで、キャパシティ調整の手間は最小限で済みました。 結果として、読みにくい急なスパイクにも問題なく追従できました。 AWS の技術支援 本タイトルの設計・実装にあたっては、AWS の技術支援プログラムである DynamoDB Immersion Day と、DynamoDB DCAD（Database Clinic in A Day）を通じて、数日間にわたる DynamoDB の勉強会・ハンズオンを実施しました。あわせて、Solutions Architect による設計相談・アーキテクチャレビュー・キー設計レビューも行っています。 特に効果が大きかったのは、次の点でした。 勉強会に社内の複数部署が参加したことで、「シングルテーブル設計」について複数の視点から比較・議論でき、設計の方向性を確かめられたこと 「TTL は設定時刻に必ず消えるわけではない」といった実運用上の注意点を事前に把握でき、誤った設計・運用のままサービスインすることを回避できたこと 実運用でのスケールの仕組みを聞けたことで、運用イメージを持てたこと 開発・運用面で得られた効果 開発・運用負荷を軽減し少人数運用を実現 現在、データベースを含むバックエンドを実質 1 名で開発・運用・保守できています。キャパシティ設計が不要なため、少人数でもアプリケーション開発に集中できています。 さらに、パーティショニングやシャーディングが透過的に扱えることで、開発環境と本番環境で構成を変えずに運用できる（dev/prod parity）点も大きなメリットでした。過去のプロジェクトで Aurora を利用していた際は、書き込み負荷を 1 クラスターで捌ききれず、ユーザー単位で複数クラスターにシャーディングしていました。どのクラスターにアクセスするかはアプリケーション側の振り分け（ディスパッチ）処理で制御していましたが、開発環境ではコスト都合で本番と同じクラスター構成を再現できないため、この振り分けを開発と本番で作り分ける必要がありました。一方、DynamoDB のパーティショニングや ElastiCache のシャーディングは透過的に行われ、キャパシティやシャード数の管理も不要です。そのため、アプリケーションはクラスターへの振り分けや分割を一切意識する必要がなく、同じコード・同じテーブル設計・キャッシュ構成が開発から本番までそのまま動作します。サーバーレスのため開発環境をコストのために縮小する必要もなく、本番との構成差が生じないことから、「開発で確認したものが本番でもそのまま通用する」状態になりました。 DynamoDB 移行後は、アラートが来たときを除いてほとんど監視画面を見る必要がなくなり、DB 周りの日常的な運用がほぼなくなりました。Aurora 利用時に気を配っていた、大規模テーブルのパーティション運用や肥大化に伴うパフォーマンス劣化への対処、API サーバーのスケール時のコネクション数（コネクションプール）といった懸念からも解放されています。 性能面の効果 DynamoDB のレイテンシーは、全 DynamoDB API の平均で 10 ミリ秒以下（CloudWatch の DynamoDB レイテンシー値）で安定しています。データ量が増えても応答性能が変わらないため、一貫して低いレイテンシーを維持できています。複雑なクエリを組まない（組む必要のない）設計になっていることも、クエリが重くなりにくい要因の 1 つです。 ElastiCache for Valkey については、従来利用してきた Redis と遜色ない性能を維持できています。頻繁に参照されるユーザーデータやランキングを ElastiCache でキャッシュすることで、低レイテンシーで応答しつつ、DynamoDB への読み取りアクセスも抑えられています。アクティブ・上位ユーザーほど参照頻度が高いため、限られたキャッシュ量でも高いヒット率が得られ、効率よく読み取り負荷を軽減できています。 コスト面の効果 最も実感しているのは、運用・管理まで含めたトータルでのコストメリットです。DynamoDB では、クラスター分割した Aurora での試算と比べて、開発・ステージング・QA 環境あわせて 95%、本番環境で 40〜50% のコストを削減できています。また、インフラの利用料金そのものに加え、これまで DB の運用・管理にかけていたコストまで含めて、負担が大きく下がりました。 ElastiCache Serverless については、開発環境ではノード構成と比べて大幅に低コストで運用できています。本番環境でも、スパイクに備えた過剰なプロビジョニングやリザーブドノードの事前購入が不要になり、負荷が読みにくいなかで容量を先に見込んで確保する必要がなくなりました。 可用性・耐障害性 最初のローンチ以降、無停止で安定稼働しており、サービスに影響するような障害は発生していません。 さいごに 『ソニックランブル パーティ』で得られたこうした成果を踏まえ、DynamoDB と Valkey は今後、部門の標準アーキテクチャとして後続タイトルでも採用していく予定です。なお、ElastiCache for Valkey を Serverless とノードベースのどちらで構成するかは、リザーブドノードの活用可否を踏まえて各プロジェクトで選択できるようにしています。 株式会社セガ 第4オンライン研究開発プログラム部 副部長の上園 政雄氏は、次のように話しています。 「DynamoDB と ElastiCache Serverless for Valkey は、少人数でグローバル展開を支えるうえで欠かせない基盤になりました。今後のタイトルでも標準的なアーキテクチャとして活用していきたいと考えています。」 株式会社セガ 第4オンライン研究開発プログラム部 副部長 上園 政雄 氏