はじめに # GFXBenchというGPUベンチマークソフトを取り上げたシリーズの4回目です。 前回で古いAndroidバージョン対応のビルドが行えました。 今回は実際に古いAndroidバージョンで実行してベンチマークスコアを確認してみます。 ベンチマーク実行結果 # 実行までの手順は今までと変わらないので、早速結果からです。 実行するAndroid端末はAndroidバージョンが古いものを手元のコレクションから見繕ってみます。 目標は SdkVersion:'21' (Android5.0) だったのですが、手元のAndroid端末の都合上、SdkVersion:'22' (Android5.1) までとなりました。 以下、実測した結果例です。ベンチマークスコアはオフスクリーン版のfps値です。 --> Caution あくまで 「筆者の環境および測定時点における一例」 であり、同様のGPU、手順で測定された場合でも、環境によって異なる結果となる可能性がある点をご了承ください。 GPU SoC Driver version Android version T-Rex score Manhattan score Adreno 418 Snapdragon 808 OpenGL ES 3.1 V@103.0 5.1.1 34 15 Kepler GK20A Tegra K1 OpenGL ES 3.2 NVIDIA 361.00 6.0.1 66 32 Kepler GK20A Tegra K1 (Denver) OpenGL ES 3.1 NVIDIA 343.00 7.1.1 63 30 Maxwell GM20B Tegra X1 OpenGL ES 3.2 NVIDIA 361.00 8.1.0 109 59 上記 Tegra X1 のスコアは Pixel C というタブレットのものです。携帯用のためか低い値となっているようで、確か据え置き用のAndroid端末の SHIELD だと T-Rex/Manhattan = 120/60 オーダーのスコアだったかと思います。 この Tegra K1 のスコア T-Rex/Manhattan = 60/30 と Tegra X1 のスコア 同 120/60 のオーダーが長らく私の中で比較する際の基準のスコアとなっていました。 --> Information Tegra K1の SHIELDタブレット で実際にサンプル（Unreal Engine、Unity等）を動かしたりゲームをしたりの感触より。覚えやすい値だったというのもあります。 時代的に仕方ないですが、このあたりのタブレットがメモリ2GBでなく4GB積んでいれば今でも普段使いしていたのに...と惜しく思います。 スマートフォン/タブレットを見る時はまずは Tegra K1 のスコア位あれば十分と見ていたものでした。Tegra X1を超えようものならもうえらい事です（※個人の感想です）。 今回はGPU違いですがオフスクリーン版の結果なのでそのまま比較できます。ただGPUの FLOPS (Floating-point Operations Per Second) も考慮に入れるとまた違った比較が行えます。次回以降に機会があれば触れてみたいと思います。 以下スコア以外の余談です。 ビルド時に CUDA Toolkit が必要だった件ですが、Tegra K1 で無事CUDA情報が表示されていました。Android版でまったく無駄というわけでもなかったようです。例はこれ位かもですが。 今回の古いバージョン5.1.1のAndroid端末でも、Car Chase（OpenGL ES 3.1 + AEP）および Aztec Ruins（OpenGL ES 3.1）までも実行可能でした。 Androidバージョン5.0から OpenGL ES 3.1 + AEP 対応が始まっていたので確かに可能ではあるのですが、実際に描画される画、fpsも低く健気に動く姿に目頭が熱くなる思いでした。 こんな昔からきちんと頑張ってくれていたのだなと...。 おわりに # 今回は前回ビルドした古いAndroidバージョン用のGFXBenchを実際に実行してベンチマークスコアを確認しました。 この記事をお読みの方の中にも、古いAndroid端末を眠らせたままにしている方は多いかもしれません。 久しぶりに取り出して、どこまで頑張れたのかチャレンジしてみてはいかがでしょうか。 より古いAndroidバージョン、より多くのベンチマーク種類の実行、より低いスコアを出せた方が優勝！です。 ライセンスおよび免責事項 # 本記事に掲載している検証結果は、BSD 3-Clause Licenseのもとで公開されている Kishonti-Opensource/gfxbench のソフトウェアおよびアセットを利用したものです。 Original Copyright: (c) 2005–2025 Kishonti Ltd. License: BSD 3-Clause License 【免責事項】 本記事に掲載している手順、ベンチマークスコア等の測定結果は、特定の検証環境における現状のまま（AS IS）のものであり、その正確性、安全性、再現性を保証するものではありません。 本情報の利用や検証の実行により生じた直接的・間接的な損害について、筆者および株式会社豆蔵は一切の責任を負いません。内容を十分にご確認の上、ご自身の責任においてご利用ください。

本記事は 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 活用やデータ活用の技術的支援に携わる。