本記事は 2026 年 8 月 17 日 に公開された「 Migrating from Kubernetes and Agones to Amazon GameLift Servers 」を翻訳したものです。 Kubernetes 上で動作する Agones は、専用ゲームサーバーをホストするためのオープンソースソリューションとして広く使われています。単一クラスター、単一の AWS リージョンでの構成であれば、専用ゲームサーバーのホスティング基盤として十分に機能します。しかし、グローバルな本番環境の規模になると、Agones の管理は複雑になり、ロケーションごとに複数の補助システムを構築・運用する必要が生じます。具体的には、リージョン間のセキュアな通信、プライベートネットワーク接続、ゲームセッションのアロケーター、マッチメイキング、モニタリング、そして Agones 自体が含まれます。これらはすべて、最初のゲームサーバーをデプロイする前に必要になります。 こうした運用の複雑さとそれに伴うコストから、多くの開発者はフルマネージドなグローバルゲームサーバーホスティングに Amazon GameLift Servers を選んでいます。Amazon GameLift Servers は、グローバルなゲームサーバーオーケストレーションの管理に加えて、リアルタイムの分散型サービス拒否 (DDoS) 保護とマッチメイキングを追加コストなしで組み込みで提供します。さらに、第 6 世代以降のインスタンスでは料金にデータ転送 (アウト) の料金も含まれており、総所有コストを大幅に削減できます。 Amazon GameLift Servers はまた、グローバルなゲームサーバーオーケストレーション全体に対して 99.95% の可用性 SLA を提供します。Agones ベースのソリューションでは、基盤となる Amazon Elastic Kubernetes Service (Amazon EKS) の SLA を超える部分はすべてユーザーの責任になります。 本記事では、この 2 つのホスティングオプションの違いをいくつか取り上げ、Agones ベースの実装から Amazon GameLift Servers へ移行する方法を解説します。 運用面とコスト面の主な違い 本番環境における 2 つのオプションの主な違いは、コストと運用の複雑さにあります。表 1 では、運用面を比較します。 機能 Amazon EKS 上の Agones Amazon GameLift Servers コンテナのコントロールプレーン EKS のデプロイ、バージョンアップグレード、プラグインを自分で管理 サービスに組み込み済み セッションのライフサイクル管理 各リージョンの Agones コントローラーを自分で運用 サービスに組み込み済み セッションの割り当て Agones アロケーターを自分で運用 サービスに組み込み済み グローバルなゲームサーバーコンピューティング 各リージョンの Amazon EKS クラスターを自分で管理 サービスに組み込み済み マッチメイキング 自分で管理・運用 (Open Match やその他のソリューション) サービスに組み込み済み モニタリング Amazon CloudWatch の Container Insights と、Prometheus や Grafana などのソリューション サービスに組み込み済み ( 組み込みの統合サポート により Prometheus や Grafana を追加することも可能) フリートのオートスケーリング Eviction の管理と Karpenter サービスに組み込み済み リモートロケーションのクラスターと中央バックエンド間の通信 クラスター間の証明書ベースのセキュアな通信を自分で構築 サービスに組み込み済み リージョン間でのコンテナイメージのレプリケーション 自分で管理 サービスに組み込み済み Blue/Green デプロイ 独自の継続的インテグレーション / 継続的デリバリー (CI/CD) ソリューションを自分で構築 シンプル: ゲームのバージョンを透過的に切り替え可能 ゲームセッションの DDoS 保護 各リージョンで独自のグローバルリレーソリューションを自分で管理 (Quilkin など) サービスに組み込み済み Ping エンドポイント Agones インフラの一部としてデプロイし、自分で管理 サービスに組み込み済み ゲームサーバーのコンテナイメージ 自分で管理 自分で管理 表 1 – 運用機能の比較 本番環境に対応した Agones ベースのデプロイでは、最初のゲームサーバーをデプロイする前の段階で、ホームリージョンに 30〜40 個の Pod、追加ロケーションに 20〜25 個の Pod が必要になります。これらは、モニタリング、運用、パッチ適用、セキュリティ対策、そして支払いをすべて自分で担う必要のあるサービスやツールです。 Amazon GameLift Servers ベースのデプロイでは、ビルドを一度アップロードし、グローバルフリートとその設定を定義するだけです。補助的なツールはサービスによって管理されるため、自分で管理する必要はありません。 図 1 は、グローバルな本番環境に対応した Agones ベースのデプロイと Amazon GameLift Servers のデプロイについて、アーキテクチャの違いを大まかに示したものです。 図 1 – アーキテクチャの比較 ホスティングプロバイダーを選ぶ際には、コストも同様に重要です。表 2 では、コスト要素を比較します。 コスト要素 Amazon EKS 上の Agones Amazon GameLift Servers コンテナのコントロールプレーン Amazon EKS コントロールプレーンのコスト 追加費用なし ゲームサーバーコンピューティング Amazon Elastic Compute Cloud (Amazon EC2) のコスト GameLift Servers のコンピューティングコスト (EC2 に対して約 20% の追加料金) ゲームサーバーインスタンスのデータボリューム Amazon EBS のコスト 追加費用なし ゲームサーバーからプレイヤーへのデータ転送 (アウト) データ転送 (アウト) のコスト 追加費用なし 補助サービス (オーケストレーション、割り当て、リージョン間通信、Ping エンドポイント) すべての AWS リージョンにわたるすべてのシステムの Amazon EC2 コンピューティングコスト (リージョンあたり 20 個以上の Pod) 追加費用なし DDoS 保護 各リージョンの各アベイラビリティーゾーンにおける独自のリレーレイヤーのコンピューティングコスト 追加費用なし マッチメイキング コンピューティングコスト (Open Match など) 追加費用なし モニタリング Container Insights とカスタムメトリクスのコスト (Prometheus や Grafana) 追加費用なし (Prometheus や Grafana による追加のモニタリングは追加コストで利用可能) 表 2 – コストの比較 表のとおり、コストはさまざまな要素で構成されます。中でも重要な 2 つの要素は、コンピューティングとデータ転送 (アウト) です。Amazon GameLift Servers ではデータ転送 (アウト) が料金に含まれますが、独自の Agones ソリューションではトラフィックの GB 単位で課金されます。データ転送のコストは、ゲームサーバーホスティングの総コストの最大 40〜50% を占めることもあります。コンピューティングについては、Amazon GameLift Servers では約 20% の追加料金を支払いますが、補助ツールに関する追加コストは一切かかりません。Agones ベースのソリューションでは、こうしたコストがリージョンをまたいで積み上がっていきます。Amazon GameLift Servers には、マッチメイキングと DDoS 保護が組み込まれています。いずれも、そうでなければ大きなコストになりかねない機能です。 データ転送 (アウト) や補助ツール、マッチメイキング、データボリューム、高度な DDoS 機能が料金に含まれることで、Amazon GameLift Servers はほぼすべてのシナリオで最もコスト効率の高いソリューションになります。さらに、これらの機能がマネージドであることで運用の複雑さが軽減されるため、ゲームサーバーの実装と最適化に集中できます。 ここまで Amazon GameLift Servers の運用のしやすさ、コスト、機能面での利点を説明してきましたが、それでもよりカスタムなデプロイが必要になる状況はあります。たとえば、ゲームサーバーノード間の緊密な連携を必要とする、大規模に分割された MMO ゲームなどのユースケースは、Amazon GameLift Servers での実装が難しい場合があります。単一プロセスで最大数百のゲームセッションをホストする基本的なリレーサーバーも、このサービスにとって最適とは言えないもう 1 つのユースケースです。これは、Amazon GameLift Servers がゲームセッションとゲームサーバープロセスの 1 対 1 のマッピングを前提に設計されているためです。 Agones から Amazon GameLift Servers への移行 既存の Agones ベースのソリューションから Amazon GameLift Servers に移行する際の手順は、比較的シンプルです。 Agones SDK の呼び出しを GameLift Servers SDK に置き換えるか、SDK Wrapperを使用する ゲームサーバー全体で単一のプライベートポートを使用する コンテナイメージをビルドし、 Amazon Elastic Container Registry (Amazon ECR) にプッシュする コンテナグループ定義を作成する コンテナフリートを作成する アロケーターをゲームセッションキュー (または FlexMatch) に置き換える バックエンドを更新し、接続情報の取得に Agones アロケーター API ではなく GameLift API を呼び出すようにする Agones インフラを廃止する 各手順を詳しく見ていきましょう。 ステップ 1: Agones SDK を GameLift Servers SDK に置き換えるか、SDK Wrapperを使用する Agones SDK の統合 ( SDK.Ready() 、 SDK.Shutdown() 、 SDK.Health() ) を、Amazon GameLift Servers SDK の対応するものに置き換えます。ここで重要な概念上の変化は、Agones がプル型 (サーバーまたは外部のアロケーターが Allocate() を呼び出す) であるのに対し、Amazon GameLift Servers はプッシュ型 (セッションを配置する際に、サービスが選択したゲームサーバー上の OnStartGameSession コールバックを呼び出す) である点です。WebSocket 接続を確立する InitSDK() 、 OnStartGameSession と OnProcessTerminate のコールバックハンドラーを備えた ProcessReady() 、そしてセッションの完了を通知する ProcessEnding() を実装します。Amazon GameLift Servers SDK は C++、C#、Go で利用でき、Unreal Engine と Unity 向けのプラグインも用意されています。SDK の統合とゲームセッションのライフサイクル管理の仕組みについては、ブログ記事「 Amazon GameLift Servers でローンチを成功させるためのステップ：開発フェーズ 」で詳しく解説しています。 完全な SDK 統合を行いたくない場合は、 Containers Starter Kit がサイドカーソリューションを提供します。これは、サーバービルドを変更することなく、サービスに必要な接続を自動的に実装します。 ステップ 2: ゲームサーバー全体で単一のプライベートポートを使用する Agones は、パブリックからプライベートへのポートマッピングを行いません。各 Kubernetes ノード上で、設定された範囲 (たとえば 7000〜7029) からホストポートを直接割り当てます。ゲームサーバーはそのポートにバインドし、プレイヤーは同じポート番号でノードの IP に接続します。Amazon GameLift Servers では、コンテナが内部ポートを定義し、EC2 インスタンス上の外部ポートへのマッピングはサービスが管理します。つまり、ゲームサーバーのコードは、外部に公開されるポートを認識したり気にしたりする必要がありません。Agones SDK を使って割り当てられたホストポートを検出して登録する代わりに、内部ポートにバインドし、外部へのマッピングは Amazon GameLift Servers に任せます。そしてセッションが配置されると、サービスがクライアント向けに正しい接続情報を返します。たとえば Unreal Engine で開発されたゲームであれば、すべてのサーバーがデフォルトの 7777 ポートを登録するといった形になります。 ステップ 3: コンテナイメージをビルドして Amazon ECR にプッシュする Amazon GameLift Servers のコンテナフリートは、Amazon ECR からイメージをプルします。フリートを作成する AWS リージョンと同じリージョンにプライベートな ECR リポジトリを作成し、ゲームサーバーイメージにタグを付けてプッシュします。既存の Docker file は、通常そのまま使えるか、わずかな修正で済みます。コンテナのエントリーポイントは、どちらのシステムでもゲームサーバープロセスです。前述の Containers Starter Kit は、このプロセス全体を自動化します。 ステップ 4: コンテナグループ定義を作成する コンテナグループ定義を作成して、コンテナのアーキテクチャを定義します。これは Agones の Fleet スペックと Pod テンプレートに代わるものです。ECR イメージ URI と、コンテナグループの vCPU およびメモリの上限を指定します。ロギングやモニタリング用のサポートコンテナ (サイドカー) を追加することもできます。Amazon GameLift Servers は、指定したリソース上限とインスタンスタイプに基づいて、各 EC2 インスタンスに収まるコンテナグループのレプリカ数を自動的に計算します。これは、Agones がリソースリクエストに基づいて Pod をノードに配置する方法に似ています。この手順でも、 Containers Starter Kit に要件を満たすための自動化が含まれています。 ステップ 5: コンテナフリートを作成する コンテナグループ定義、EC2 インスタンスタイプ、地理的なロケーションを指定して、マネージドコンテナフリートを作成します。この単一のリソースが、EKS クラスター、ノードプール、Agones のインストール、Helm チャート、cert-manager、そしてマルチクラスターの割り当て設定に取って代わります。Amazon GameLift Servers は、インスタンスのプロビジョニング、基盤となる OS、コンテナのデプロイ、ヘルスチェック、オートスケーリングを処理します。単一のフリートに複数のロケーションを追加すれば、複数リージョンでの展開が可能です。VPC ピアリングやクラスター間の TLS 通信は必要ありません。ホームリージョンからリモートロケーションへの通信は、サービスによって完全に管理されます。 ステップ 6: アロケーターをゲームセッションキュー (または FlexMatch) に置き換える フリートを指すゲームセッションキューを作成します。これは、独自の Director、マルチクラスターの Agones アロケーター、そしてリージョン間の TLS/VPC ピアリング接続に代わるものです。キューは、レイテンシーベースまたはロケーション優先度ベースのルーティングにより、ロケーション間での配置を処理します。組み込みのマッチメイキングが必要な場合は、チームサイズ、スキルレンジ、レイテンシー許容範囲を定義したルールセットを使って FlexMatch を設定します。それ以外の場合は、バックエンドから直接 StartGameSessionPlacement() をプレイヤーのレイテンシーデータとともに呼び出し、最適なロケーションをキューに見つけさせます。 ステップ 7: バックエンドを更新し、接続情報の取得に Agones アロケーター API ではなく GameLift API を呼び出すようにする 現在、バックエンドサービスは、ゲームサーバーの接続情報 ( GameServer.Status の IP とポート) を Agones アロケーター API に問い合わせています。これを、キューイベントの処理に置き換えます。配置が完了すると、 Amazon Simple Notification Service (Amazon SNS) の通知を受け取ります。マッチメイキングに FlexMatch を使用している場合は、FlexMatch イベントを使用することもできます。これらのイベントには、クライアントがサーバーへの接続を認証するために使用する、ゲームセッションの IP アドレス、ポート、プレイヤーセッション ID が含まれます。Amazon GameLift Servers は、オプションのプレイヤーセッション管理も提供します。これを採用することも、既存のソリューションを引き続き使用することもできます。 Event-based session placement のガイダンスには、キューを効果的に使用するためのアーキテクチャとサンプルコードが含まれています。 ステップ 8: Agones インフラを廃止する トラフィックが完全に Amazon GameLift Servers に移行され、検証が完了したら、Agones スタックを廃止します。これには、EKS クラスター (全リージョン)、VPC ピアリング接続、Open Match のデプロイ、cert-manager、Amazon ECR のレプリケーションルール、および関連するノードグループが含まれます。これにより、プラットフォームを稼働させるためだけに動いていた、ホームリージョンの 30〜40 個、各リモートリージョンの 20〜25 個のシステム Pod がなくなります。 まとめ 本記事では、Agones ベースのソリューションと Amazon GameLift Servers の主な違いを、運用とコストの観点から説明しました。運用面では、Amazon GameLift Servers に比べて Agones の方がはるかに多くの責任を負うことがわかりました。コスト面では、無料のデータ転送 (アウト)、料金に含まれる補助ツール、そして追加機能により、Amazon GameLift Servers が多くの場合によりコスト効率の高いソリューションになります。 また、Agones から Amazon GameLift Servers への移行手順も紹介しました。ほとんどのゲームでは、ゲームサーバーとゲームバックエンドのロジックに必要な変更はわずかで、シンプルかつ手間のかからないプロセスになるはずです。 マルチプレイヤーゲームサーバーのホスティングに、今すぐ Amazon GameLift Servers を使い始めましょう。ビジネスの加速をどのように支援できるかについては、AWS 担当者にお問い合わせください。 参考資料 Amazon GameLift Servers Developer Guide Free Network Bandwidth for Amazon GameLift Servers is Here Amazon GameLift Servers でローンチを成功させるためのステップ：ローンチフェーズ 著者について Juho Jantunen AWS for Games チームのワールドワイドプリンシパルソリューションアーキテクトで、ゲームバックエンドとゲームサーバーホスティングのソリューションを専門としています。ゲーム業界とクラウドテクノロジーのバックグラウンドを持ち、数百万人のプレイヤーを抱える複数のタイトルについて、AWS 上でゲームバックエンドを構築・運用してきました。 この記事は Kiro が翻訳を担当し、Solutions Architect の西坂がレビューしました。

はじめに 2026年6月25日、26日に幕張メッセで開催された AWS Summit Japan 2026において、AIエージェントによる建設機械のフリート管理デモ「産業機械の自律診断とリアルタイム安全監視」を展示しました。本記事では、このデモの技術的な構成と考え方を解説します。 建設機械や産業機械の保全業務では、機械の異常をいかに早く検知し、いかに早く適切な対処につなげるかが稼働率を左右します。また、日本をはじめ多くの国で熟練技術者の高齢化と労働力不足が進行しており、保全業務の担い手の確保は年々困難になっています。フリート運用の現場では、機械の情報が現場や機体ごとに分散して全体状況が把握できないこと、故障対応が熟練者の経験に依存することが課題となり、結果として復旧に時間と人手がかかります。センサーデータに基づく予知保全はこの課題への代表的なアプローチですが、従来の機械学習による異常検知には「異常が起きていることは分かるが、なぜ起きているのか、何をすべきかまでは分からない」という限界がありました。異常スコアを受け取った保全担当者は、結局マニュアルを調べ、過去の類似事例を探し、対処方針を自分で組み立てる必要があります。 本デモはこの課題に対し、IoT による遠隔監視で分散した情報を集約して機械の状態を可視化し、生成 AI エージェントが異常の一次分析と情報収集を自動で行うことで、保全担当者が判断と対処に集中できる環境を作る構成としています。エージェントが原因候補と対処手順をあらかじめ提示することで、経験の浅い担当者でも初動対応に着手しやすくなり、熟練者は高度な判断が求められる場面に集中できます。人手による報告、古典的な機械学習、そしてエージェント型の予知保全という3 つのアプローチを同一のフリートに対して並べて体験できる構成とし、それぞれの特性の違いが分かるようにしています。さらに、検知した異常に対する診断、チケット起票、オペレーターへの音声通知、実機の遠隔操作までを含めたエンドツーエンドのデモとして構築しました。 デモ概要紹介の動画は こちら からご覧いただけます。 デモの全体像 デモのシナリオは、建設機械メーカーのアフターサービス部門が、顧客先で稼働する 20 台の掘削機を遠隔監視し、サポートを提供するという設定です。東京エリアの各現場に散らばる掘削機はエンジン温度、エンジン回転数、油温、油圧、冷却水温度、クーラント残量、燃料残量といったテレメトリを送信しており、ダッシュボードではフリート全体の状態を一覧できます。 フリートマップは Amazon Location Service で構築しており、各機体の位置と状態 (Operational / Warning / Critical / Offline)を地図上に表示します。展示では、20 台のうち 19 台が正常に稼働し、1 台が異常状態にあるというシナリオを用いました。異常機体の存在を把握しマシン一覧に進むと、該当機体のエンジン温度と油温が異常に高いことをテレメトリから確認できます。分散していた機体の情報が一画面に集約されているため、異常の発見から状況の把握までがダッシュボード上で完結します。 Analytics 画面ではエンジン温度、エンジン回転数、油圧、燃料残量などの時系列チャートをリアルタイムに描画します。 デモ全体のアーキテクチャは、実機・エッジ・クラウドの 3 層で構成されています。実機側には ESP32 を搭載した掘削機の模型と、NVIDIA Jetson Orin Nano とカメラを組み合わせたエッジ推論環境があり、クラウド側では AWS IoT Core 、 AWS IoT SiteWise 、 AWS Lambda 、 Amazon DynamoDB を中心としたデータ基盤の上に、 Amazon Bedrock AgentCore と Strands Agents によるエージェント層を構築しています。詳細は後述します。 設計の考え方 デモの各機能を紹介する前に、設計にあたって重視した 2 つの考え方を説明します。なお、本デモの考え方は AWS Summit Japan 2026 のセッション「情報を集め、判断し、行動する時代へ:データ基盤・AI エージェント・エッジ AI で変わる製造現場」(IND327) でも解説しています。セッション資料は こちら からダウンロード可能です。 データにコンテキストを付与する センサーから届く生データは、センサー ID、タイムスタンプ、値、単位といった情報しか持ちません。「75.3 ℃」という値だけでは、それがどの現場の、どの機体の、どの部品の温度なのかが分からず、AI はもちろん人にも意味のある判断ができません。どの機体か、どの部位か、どの機種かといったコンテキストをデータに付与 (エンリッチ) して初めて、その値を「この機種の冷却系としては高すぎる」と解釈できるようになります。データの質と流れが AI の判断力を決める、というのが本デモの土台にある考え方です。本デモでは AWS IoT SiteWise のアセットモデルで機体・部位と計測値の関係を構造化し、エージェントが参照するテレメトリに機体のコンテキストが伴う状態を作っています。 人間と AI の役割分担を設計する AI を組み込んだシステムには、ルールベースの自動化、AI による支援、ゴール駆動型エージェントとの協働、完全自律型のエージェントというように、自律性の異なる段階があります。どの段階を採用するかは、対象業務のリスクと複雑性に応じて設計するものであり、既存のプロセスを単に AI に置き換えれば良いわけではありません。本デモの 3 種類のアラート(人手・古典的 ML・エージェント)は、後半に向けて自立度が高くなります。またデモ全体を通して、異常の検知や分析に必要な情報収集はエージェントが担い、機械を止めるか、現場に作業員を派遣するかといった判断は人間が行う、という役割分担で設計しています。 予知保全の 3 つのアプローチ 本デモの中心は、同じフリートに対する 3 つの異常検知アプローチの比較です。 人手による報告(Alerts – Human Driven) 最も基本的な形態として、現場の作業者が観察した異常を手動で報告するフォームを用意しました。機械、深刻度、タイトル、詳細を入力して起票します。人の観察は「油圧ポンプから変な音がする」といった、センサーには現れにくい定性的な情報を含む点で価値がありますが、報告のタイミングと粒度が人に依存し、状態を定量的に捉えて比較・追跡することができません。フリートが大きくなるとスケールしないという限界もあります。 古典的な機械学習(Alerts – Classical PM) 次の段階として、Amazon SageMaker AI 上に構築した古典的な機械学習パイプラインによる異常検知を実装しました。このパイプラインは、正常運転時のテレメトリから学習したモデルで各機体を継続的にスコアリングし、平常時からの逸脱が大きいときにアラートを発報します。デモの画面では、フリート 20 台それぞれの異常スコアと、予測値と実測値の乖離をチャートで確認できます。異常が進行している機体では、エンジン温度の実測値がモデルの予測レンジから外れていく様子が見て取れます。このアプローチはスケールし、人の観察より早く統計的な逸脱を捉えられます。一方で、アラートに含まれるのは異常スコアという数値だけで、原因や対処までは示されません。異常が起きていることは検知できても、なぜ起きているのかは説明できない。この点が古典的な機械学習による予知保全の限界であり、次のエージェント型アプローチが価値を発揮するところです。 エージェント型予知保全(Alerts – Agentic PM) エージェント型の予知保全では、Amazon Bedrock AgentCore と Strands Agents で構築した AI エージェントがテレメトリを監視し、異常を検知した際に原因分析と推奨アクションを含むアラートを生成します。たとえばデモでは「エンジン温度 95.2 ℃ と油圧低下 48.5 PSI の組み合わせはエンジン故障が差し迫っているリスクを示している。ただちに掘削機を停止し、点検を実施すること」といった、複数のテレメトリを組み合わせた解釈と具体的な対処指示を含むアラートが発報されます。単一メトリクスの閾値超過ではなく、エンジン温度と油圧の同時異常からオイルシステムの問題を推定するといった、保全担当者が行う推論に近い分析が行われる点が古典的 ML との違いです。アラートを受け取った担当者は、原因の調査から始めるのではなく、提示された分析と対処の妥当性を確認するところから対応を始められます。 もうひとつの特徴は、アラートルールの管理を自然言語で行える点です。「エンジン温度が 90 ℃ を超えたら警告して」「燃料レベルのアラートを無効化して」といった指示を入力すると、エージェントが予知保全モニターの使用するルールを更新します。閾値の調整のたびに設定画面を操作したりコードを変更したりする必要がなく、運用者の意図を直接ルールに反映できます。アラートの感度調整は運用を続けながら繰り返し行う作業であるため、この調整を運用者自身で完結できることは運用負荷の軽減につながります。 検知から対処までをエージェントで支援 異常の検知は保全業務の入口にすぎません。本デモでは、検知の後工程である診断、起票、通知、対話までをエージェントで支援する構成としました。 チケットの起票と AI 分析 アラートが発報された後のチケット起票は、人間が行います。担当者はアラート画面からエージェントに原因と対応策の分析を指示します。アラートはアラート画面で管理しますが、メールや SMS で通知することも可能です。人間から指示を受けた後、エージェントはマニュアルやテレメトリデータを自動で収集し、原因の特定と現場作業員向けの作業指示を作成します。チケットサービスはデモ内に MCP 経由で接続されており、担当者は分析結果を確認したうえで、アラート画面からそのままチケットを起票できます。起票されたチケットには、エージェントの分析結果が日本語で付与されます。たとえば「掘削機 001 はエンジン冷却水温度が 94.7 度と高く、C62 および C65 のオーバーヒート関連の故障診断コードが検知されています」といったように、テレメトリの値と診断コードを突き合わせた診断が記載されます。 異常の検知と、分析に必要な情報の収集はエージェントが行い、現場に作業員を派遣するかどうかの判断とチケット起票は人間が行う — このように分担することで、複雑な現場保全を効率的に進められます。分析にあたってエージェントは、後述する Knowledge Base を検索し、機器マニュアルや診断コードの定義を参照します。テレメトリ (定量データ) と技術文書 (定性情報) を組み合わせて、状況を総合的に判断させています。チケットには深刻度とステータスが付与され、Ticketing 画面で一覧・検索できます。診断コードの意味をマニュアルで調べるという一次診断と、機体名やテレメトリ値の転記が不要になるため、担当者の作業は分析内容の確認と派遣の判断に絞られます。また分析結果が日本語で記載されるため、現場の担当者がそのまま読んで対応に移れます。 Knowledge Base による技術文書の検索 Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless で、機器マニュアル、診断コード一覧、保守手順書を検索できるナレッジベースを構築しました。「掘削機のオーバーヒートに関する診断コードは何か」「油圧ポンプの交換手順は」「緊急停止の手順は」といった質問に、文書に基づいた回答を返します。このナレッジベースは、チケット起票時の AI 分析と、次に述べる音声通知の両方から参照されます。 Amazon Connect による音声通知 検知と診断の結果を現場のオペレーターに届ける手段として、 Amazon Connect による架電機能を実装しています。エラーコードを指定すると、エージェントが Knowledge Base からトラブルシューティング手順を検索し、その要約を Text-to-Speech で読み上げる電話をオペレーターにかけます。同じ内容はメールでも送付されます。ダッシュボードを見ていない現場の担当者にも、異常の内容と初動手順が音声で届くという体験です。 双方向の音声対話 通知にとどまらず、AI エージェントとオペレーターがリアルタイムに双方向で会話する音声対話も実装しています。エージェントは対象機体のライブテレメトリと診断結果のコンテキストを保持した状態で通話するため、オペレーターからの質問に答え、トラブルシューティングを対話的にガイドし、必要に応じてエスカレーションできます。一方向の読み上げと異なり、手順の途中で生じた疑問にその場で答えられるため、担当者への折り返し確認を減らせます。音声対話の基盤には Amazon Nova Sonic を利用しています。 AI Assistant これらの機能とは別に、フリート全体を対象としたチャット形式の AI Assistant も用意しています。Strands Agents によるマルチエージェント構成で、「フリートの状態は?」「掘削機-001 を診断して」「掘削機-003 のテレメトリを読んで」といった問い合わせに対し、フリート状態の照会、機体診断、ドキュメント検索を担当するエージェントが連携して回答します。現場の作業員はタブレットやスマートフォンからこのアシスタントを利用でき、展示ではエンジン温度が異常に高い機体への対応方法を質問する流れを紹介しました。診断コードやマニュアルの知識を持つ熟練者でなくても、その場で対応方法を引き出せることがこの機能の狙いです。 エッジと実機 クラウド側の機能に加えて、実機とエッジ推論を組み合わせた構成も実装しています。なお、今回の展示ではこの部分のデモフローは割愛しました。以下では、実装した構成を紹介します。掘削機の模型には ESP32 を搭載し、モーター、センサー、LED を MQTT で AWS IoT Core に接続しています。掘削機制御画面からは走行、キャビン旋回、アームの上下、非常停止(E-STOP)を遠隔操作でき、掘削機の状態は Unreal Engine で構築した 3D デジタルツインに反映されます。エッジ推論としては、NVIDIA Jetson Orin Nano 上で YOLO による物体検出と VLM(Vision Language Model)を組み合わせ、映像から安全に関わる状況をエッジ側で判定する構成を実装しました。また、 Amazon Kinesis Video Streams 03:06 PM と WebRTC による低遅延のライブ映像配信の上で、Amazon Bedrock による映像分析を行う構成も実装しています。「機材の近くに人が近づいたら通知して」のように監視条件を自然言語で定義でき、条件に合致するイベントが検出されると指定の方法で通知されます。この構成では、人の接近検知のような安全に関わる即時判断を Jetson 上のエッジ推論が担い、フリート全体の分析や診断をクラウド側のエージェントが担う分担を想定しています。 アーキテクチャ詳細 最後に、デモ全体のアーキテクチャを整理します。 データ基盤の層では、掘削機のアセット情報を AWS IoT SiteWise で管理し、実機からのテレメトリは MQTT で AWS IoT Core に取り込み、機体状態を Amazon DynamoDB に保持します。アラート、チケット、チャット履歴もそれぞれ DynamoDB のテーブルで管理し、生成・更新の処理は AWS Lambda と AWS Step Functions で実装しています。 エージェント層は Strands Agents で実装しています。アシスタント、シナリオ、ナレッジベース検索、チャット履歴といったエージェントは AWS Lambda(コンテナ)上で稼働し、音声対話エージェントは Amazon Bedrock AgentCore 上で稼働させています。エージェントから AWS IoT SiteWise などの OT/IT システムへのアクセスは MCP(Model Context Protocol) サーバーを介して行い、エージェントは目標に応じて必要なツールを自律的に選択・実行します。AgentCore はランタイム管理、認証、メモリ、可観測性といった、エージェントを本番運用するための基盤機能を提供します。ナレッジベースは Amazon Bedrock Knowledge Bases と Amazon OpenSearch Service で構成し、音声対話には Amazon Nova Sonic を利用しています。音声通知は Amazon Connect、メール等の通知は Amazon SNS が担います。 フロントエンドは Amazon CloudFront と AWS WAF を通じて配信し、認証には Amazon Cognito を利用しています。リアルタイム性が求められるテレメトリ配信には Amazon API Gateway の WebSocket API を、その他の操作には REST API を使い分けています。映像系は Amazon Kinesis Video Streams、地図表示は Amazon Location Service です。 まとめ 「産業機械の自律診断とリアルタイム安全監視」デモでは、建機フリートの予知保全を題材に、人手による報告、古典的な機械学習、生成 AI エージェントという 3 つのアラート発火のアプローチを比較できる形で実装しました。古典的な機械学習が「異常の検知」を担い、エージェントが「原因の分析と対処の提示」、さらに「起票・通知・対話」までを担うという役割分担は、製造業や建設業における保全業務の実務に近い形で生成 AI を組み込む際のひとつの参考になると考えています。さらに、検知後に人が担っていた調査・起票・連絡といった作業をエージェントに任せることで、担当者は判断と実際の対処に集中できるようになります。 本記事で紹介した構成の多くは、標準的な AWS サービスの組み合わせで実現しています。自社の設備データへの適用をご検討の際は、ぜひ AWS の担当ソリューションアーキテクトにご相談ください。 著者 新澤 雅治(Niizawa Masaharu) — IoT Specialist Solutions Architect。製造業、IT 企業を経て AWS に入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。 深澤 真愛(Fukasawa Mana) — Solutions Architect。入社以来、製造業を中心に、様々な業界のお客様の AI 活用やデータ活用の技術的支援に携わる。

1. はじめに こんにちは、ソリューションアーキテクトの戸塚と中本と宇加治です。 AWS Summit Japan 2026 の AWS Builders’ Fair にて、パデルフォーム分析アプリを展示します。パデルを知らない方向けに簡単に説明すると、テニスとスカッシュを合わせたような、壁に囲まれた小さめコートで 2 対 2 のダブルスだけで行うラケットスポーツです。この展示は、テクノロジーでスポーツ体験を拡張し、競技者の感覚や経験だけでは捉えにくいフォームの違いを可視化する取り組みとして、多くの方に触っていただきたい内容となっています。 このブログでは、展示の概要、使用している技術スタック、AI 駆動の開発手法、そしてこのシステムが解決する課題と他インダストリーへの応用可能性についてご紹介します。エンジニアの方もたくさん参加されていると思うので、ぜひ技術的な観点からも楽しんでいただければ嬉しいです。 2. AWS Summit Japan 2026 について AWS Summit Japan 2026 は、2026年6月25日から26日まで幕張メッセで開催される、クラウドと AI イノベーションの最前線を体験できる 2 日間の無料イベントです。260 以上のセッションに加え、AWS Village、ワークショップ、Partner Solution Expo など多彩なコンテンツが用意されています。AWS Builders’ Fair エリアは、AWS エンジニアが自作した “遊べる” デモを体験しながら、AI・IoT・サーバーレスなどの活用事例を学べるハンズオン型の展示ゾーンとなっています。来場者は自由にブースを回り、生成AI・IoT・サーバーレスなどを組み合わせたインタラクティブなデモを、実際に触ったり遊んだりしながら体験できます。 3. パデフォーム分析アプリ展示概要 このアプリは、 Meta Quest （VR ヘッドセット）、 HaritoraX （モーションキャプチャデバイス）、カメラによる骨格推定技術（ MoveNet ）を組み合わせ、バーチャル空間でパデルの球出しを受けた際の動作を計測・分析する仕組みです。 単にスイングを記録するだけではなく、身体の各部位の動きやタイミングの差分をとらえ、トッププレーヤーのフォームと比較評価できるように設計しています。 3.1 体験の流れ VR 空間で球出しを受ける — Godot で構築された 3D 空間内でプレー リアルタイムモーションキャプチャ — HaritoraX + カメラで動作データを取得 フォーム分析 — DTW(Dynamic Time Wrapping) アルゴリズムでトッププレーヤーのフォームと比較　※ 結果表示 — 5 指標のスコアカード + 生成 AI によるアドバイス VR、Haritora、カメラの３つのソースを統合して、最終的に 5 つの指標として評価するように実装しています。 写真: VR 空間でプレーする体験者の様子 図: 5つの評価指標を算出するための各データソースの役割 ※骨格推定には OpenPose や MoveNet といったスポーツ動作分析の標準手法を使っています。時系列比較の DTW は、 Ba č i ćらが 2022 年の VISAPP でストローク分類に使用しています。プロとの比較は Stanford の Liu が 2025 年に DTW によるプロ対アマ比較 を行っています。フェーズ分割はバイオメカニクスの標準的なアプローチとなっています。 写真: リアルタイムモーションキャプチャのデータ確認画面 ゲームとして楽しめるだけでなく、トレーニングにもなる設計を目指しています。プレイヤーは VR 空間の中でさまざまなボール（レボテやコントラパレットを含む）に対応することになり、楽しみながらフォームの改善ポイントを発見できます。 3.3 トッププレーヤーの教師データ 事前計測には、パデルトッププレーヤーとして久留広平選手、内海信仁選手、瀧田瑞月選手、内海和心選手に AWS オフィスへお越しいただきました。計測で取得したデータは、すでにアプリ内の教師データとして実装されており、体験者は彼らのフォームとの差異を比較できるようになっています。 この仕組みの面白さは、単に「上手い・下手」を判定することではありません。トッププレーヤーの動作を基準にすることで、打点の入り方、身体の回旋、重心移動、準備動作の速さなど、普段は言語化しにくい技術要素を、比較可能な形で捉えられる点にあります。 また、コーチングや自己改善の文脈でも活用しやすいのが特徴です。感覚に頼りがちなフォーム指導に対して、再現性のある比較軸を持ち込めるため、競技経験者はもちろん、これから上達したいプレーヤーにとっても新しい学習体験になり得ます。 写真: 計測結果のスコアカード画面（数値化 + 生成 AI アドバイス） 3.4 トッププレーヤーからのコメント 教師データ計測に協力いただいた選手から、本システムを実際に使用した感想をいただきました。システムの可能性を評価する前向きなコメントに加え、今後の活用方法に関するアイデアも頂戴しました。 ■ 久留 広平選手(日本代表) コーチの視点では、フォームや身体の使い方を指導する際に選手がイメージしている動作と実際の動作に乖離が見られるケースがあり、そのような場面でデータに基づくフォーム分析を活用することで、効果的な指導につなげられると感じました。 ■ 内海 信仁選手(ベテラン日本代表) 日本は世界から30年のビハインドがあり、中東、東南アジアは英語が話せるアドバンテージでどんどん差を埋めていますが、日本はそれが出来ていません。それをテクノロジーで埋めていくというのは日本らしさがあってとても素晴らしいと感じました。 ■ 瀧田 瑞月選手(2018〜2023 日本代表 2025年 Jr 日本代表サブコーチ) 率直に、これからの可能性にとてもワクワクしました。パデルに限らず、エンターテインメントやコーチング、競技力向上など、さまざまなカテゴリーで活用できる可能性を感じました。今後どのように発展していくのか、とても楽しみです。 ■ 内海 和心選手(日本代表) 自分の足りないところやいいところを見つけてくれるところが面白いと感じました。プロと比べて何が劣っているかとか見つかるところが今後の成長に繋がりそうだと思いました。 4. システムアーキテクチャ 4.1 全体構成 この展示は、スポーツテック、XR、センシング、コンピュータビジョンを横断する実験でもあります。Meta Quest による没入的な体験、HaritoraX によるモーションキャプチャ、カメラベースの骨格推定による姿勢解析を組み合わせることで、単一センサーだけでは捉えきれないフォーム情報を多面的に扱えるようにしています。VR アプリ構築には、Unity や Unreal Engine なども候補にあがりましたが、今回は費用も極力抑えることを考え、完全無料でオープンソースの Godot を採用しました。Godot は、Python に似た独自の言語「GDScript」を使います。文法がシンプルで読みやすいため初心者でも学習しやすい設計になっています。もちろん C# や C++ も使うことができます。今回はこの GDScript 等を Kiro の力を活用することで、自然言語でのやりとりでこのような VR アプリのオブジェクトや VR 空間での挙動までもプログラミングしているので、GDScript の学習コストはかかりませんでした。 本システムは以下のコンポーネントで構成されています: 図: システム全体概要 レイヤー 技術 用途 VR / 3D 空間 Godot Engine VR空間内でのパデル球出しシミュレーション。自然言語（Kiro）で開発 VR デバイス Meta Quest VR ヘッドセットによる没入体験 モーションキャプチャ HaritoraX 身体トラッキング（全身の動きを取得） 骨格推定 MoveNet (TensorFlow Hub) カメラ映像からリアルタイム骨格推定（17 キーポイント） フロントエンド Tauri v2 + React + TypeScript + Vite デスクトップアプリ（結果表示・操作 UI） バックエンド バックエンド Python FastAPI + Uvicorn リアルタイム分析 API（WebSocket 対応） フォーム比較 DTW (Dynamic Time Warping) 時系列データの非線形マッチングによるフォーム比較 クラウド AWS CDK (ECS Fargate + ALB + S3 + DynamoDB) 評価処理のオフロード、スコア永続化、ランキング AI フィードバック Amazon Bedrock スコアに基づくパーソナライズされた改善アドバイス エッジ側で動くアプリケーションは AWS IoT Greengrass の OTA (Over the Air)アップデート を使ってアプリ配信をする仕組みをとっており、複数拠点にあるアプリを遠隔で更新できる様にしています。また計測後のフィードバックは骨格推定を含んだ動画も見れるようになっており、動画配信は Amazon CloudFront を活用してレイテンシーが抑えられる形にしています。 図: エッジ側を含めた AWS 構成 4.2 AI 駆動の 3D 開発: Kiro × Godot 今後、3D や VR の需要はさらに高まっていくと見られます。一方で、3D プログラミングは従来、空間座標やベクトル演算、物理エンジンの理解など専門性が高く、参入障壁が高い領域でした。 今回のプロジェクトでは、Godot Engine を使った 3D 空間のプログラミングを、Kiro（AI コーディングアシスタント）を用いた自然言語プログラミングで実施しています。たとえば「ボールを放物線で飛ばしてラケットの当たり判定を追加して」「壁に当たったらレボテ（跳ね返り）する物理を実装して」といった指示で、3D 空間の挙動や空間認識のロジックを実装できました。 これにより、3D/VR 開発の経験が浅いエンジニアでも、アイデアを素早くプロトタイピングし、スポーツシミュレーションのような複雑な 3D アプリケーションを構築できることを示しています。AI 駆動の開発が、従来は専門家の領域だった 3D プログラミングの民主化を進める一例と言えます。 4.3 モーションキャプチャデータ連携の技術的課題 本システムの開発で最も技術的に挑戦的だったのは、異なるモーションキャプチャソースからのデータ統合です。 具体的には以下の課題がありました: 座標系の統一: HaritoraX（慣性式）、Meta Quest（光学式）、MoveNet（画像ベース）はそれぞれ異なる座標系・スケールで動作データを出力します。これらを統一的な骨格表現に変換する必要がありました。 データ同期: デバイスごとにサンプリングレートが異なり（カメラ 30fps、HaritoraX 100Hz 等）、時刻同期とリサンプリングの仕組みが必要でした。 欠損補間: オクルージョン（身体の一部が隠れる）時のデータ欠損を、他デバイスのデータで補間する戦略を設計しました。 リアルタイム性: 分析結果を体験者にすぐフィードバックするため、WebSocket 経由でのストリーミング処理パイプラインを構築しました。 これらの課題に対して、Kinesis 経由でデータを送りつつ UNIX タイムの時間同期、骨格情報との相対位置によるキャリブレーションにより統合し、クラウドと連携して分析する — これはまさに AWS が得意とする領域です。 5. 今後の可能性 5.1 このアプリが解決する課題 スポーツの世界では、トップ選手の技術は見えているようで、細部まではなかなか共有されません。コーチングの現場でも、「もっと腰を回して」「タイミングが遅い」といったフィードバックは、指導者の主観に依存し、再現性に乏しいものでした。 本システムは以下の課題を解決します: フォーム指導の属人化: 感覚的な指導を定量データに置き換え、再現性のある比較軸を提供 上達実感の欠如: スコアの時系列推移を記録し、小さな改善も可視化 トップ選手の技術の暗黙知化: 動作データとして記録し、比較可能な形でアクセス可能に フィードバックの即時性: リアルタイム計測 → 即座にスコア表示、改善ポイントを AI が提示 エンゲージメントの低下: VR ゲームとして楽しみながらトレーニングできる体験設計 5.2 他インダストリーへの応用可能性 本システムのコアである「モーションキャプチャ × AI 比較分析 × リアルタイムフィードバック」は、パデルに限らず幅広い分野に応用可能だと考えています。以下にユースケースを示します。 インダストリー 応用例 期待効果 スポーツ全般 テニス、ゴルフ、野球のスイング分析、サッカーのキック分析 定量的なフォーム改善、怪我予防 リハビリ・ヘルスケア 理学療法での動作評価、リハビリ進捗の定量モニタリング 回復度の客観的評価、遠隔リハビリ 製造業 作業員の動作分析、熟練工の技能伝承 品質向上、教育期間短縮 エンターテインメント ダンスや演技のフォーム評価、モーションキャプチャ活用 パフォーマンス向上、ゲーミフィケーション フィットネス パーソナルトレーニングのフォームチェック、ヨガのポーズ評価 トレーナー不在時の自己改善 介護・高齢者支援 歩行分析、転倒リスク評価 早期異常検知、予防介護 技術的には、DTW による時系列比較は人間の動作全般に適用可能であり、教師データ（基準動作）を差し替えるだけで異なるドメインに展開できます。AWS のクラウドインフラ（AWS Lambda, Amazon S3, Amazon DynamoDB,Amazon Bedrock, AWS IoT Greengrass等）を活用することで、スケーラブルかつ低コストな運用が可能です。 5.3 今後の展望 今回の展示はデモでありながら、今後の展開余地が大きい取り組みでもあります。 プレーヤーごとの癖や成長過程の可視化 ショット別の比較分析（フォアハンド / バックハンド / ボレー / バンデッハ） レベル別の推奨フィードバック コーチとの振り返り支援（セッション動画 + スコアの共有） 「どのトッププレーヤーのフォームに近いか」のパーソナライズ分析 マルチスポーツ対応（テニス、バドミントン、ゴルフ等） 写真: 教師データとして協力いただいたパデルトッププレイヤーの皆様 6. ぜひ会場で体験してください AWS Summit Japan 2026 の AWS Builders’ Fair は、遊び心あふれるテクノロジー展示を実際に見て、触って、開発者と会話できる場です。パデルフォーム分析アプリも、スポーツとテクノロジーが交わる体験を、できるだけ直感的に楽しんでいただけるよう準備しています。 ブースでアプリを体験いただいた方には、Amazon Padel ステッカーを配布予定です。AWS Summit Japan 2026 に参加される方は、ぜひ Builders’ Fair に立ち寄って、トッププレーヤーとのフォーム比較を体験してみてください。 AWS Summit Japan 2026 公式サイト: https://aws.amazon.com/jp/summits/japan/ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 中本 翔太(Shota Nakamoto) ネットワークチームに所属するソリューションアーキテクトで、サービス業界のお客様を中心にご支援をしています。 宇加治 邦生(Housei Ukaji) サービス業界のお客様を中心にご支援をしています。好きな AWS サービスは Kiro CLI です。