【ITニュース解説】Cloud Robotics Development on AWS: Migrating from RoboMaker to Batch

AWS RoboMakerという、ロボットのシミュレーションをクラウド上で行うための便利なサービスが、2025年9月10日に利用できなくなることが発表された。このニュースは、現在RoboMakerを使っている開発者にとって、重要な変更を意味する。RoboMakerで動かしていたシミュレーションは、AWS Batchという別のサービスへ移行する必要があるのだ。システムエンジニアを目指す皆さんにとって、なぜこのような移行が必要なのか、そして具体的にどうすればよいのかを解説する。

まず、RoboMakerとはどのようなサービスだったか見てみよう。RoboMakerは、ロボットの動作を仮想空間でテストする「シミュレーション」を、AWSというクラウド環境で簡単に実行できるように作られた、ロボット開発に特化したサービスだった。通常、シミュレーションには高性能なコンピューターが必要だが、RoboMakerはROS（Robot Operating System）やGazeboといったロボット開発でよく使われるツールをクラウド上で動かし、必要なコンピューティングリソースを自動的に用意してくれた。例えば、複雑な環境を自動生成する機能（WorldForge）や、ログを記録するCloudWatchなどのAWSの他のサービスとの連携も簡単だった。開発者はシミュレーションのインフラストラクチャについて深く考える必要がなく、ロボットのプログラム開発に集中できた点が大きなメリットだったと言える。GUI（グラフィカルユーザーインターフェース）を使って、シミュレーションの様子をリアルタイムで確認できる機能も備わっていた。しかし、この便利なサービスが終了し、代替としてAWS Batchが推奨されている。

では、AWS Batchとは一体何だろうか。AWS Batchは、特定の用途に特化したRoboMakerとは異なり、コンテナという技術を使って様々な種類の「バッチ処理」を大規模に実行するための汎用的なサービスだ。バッチ処理とは、例えばたくさんの計算や処理をまとめて行うことを指す。Batchでは、Dockerという技術でアプリケーションを「コンテナ」と呼ばれる小さな箱に閉じ込めて実行する。ユーザーは、RoboMakerのようにロボット開発専用のインターフェースがあるわけではなく、自分でコンテナイメージ（アプリケーションを動かすための設計図）を作成し、どのようなコンピューティングリソースを使うか（例えば、CPUの種類やメモリの量など）を細かく設定する必要がある。これはRoboMakerに比べて手間がかかるように見えるかもしれないが、その分、非常に高い柔軟性と、RoboMakerをはるかに超える大規模な処理能力を手に入れることができる。

RoboMakerからAWS Batchへの移行は、単にサービスを置き換えるだけでなく、シミュレーションの実行方法に対する考え方を大きく変えることを意味する。RoboMakerはインフラを管理し、シミュレーションに特化したツールを提供したが、Batchは汎用的な計算リソースを提供する。これにより、いくつかのRoboMakerの便利機能（例えば、WorldForgeのGUIやオンデマンドの開発環境）は失われるが、代わりに得られるメリットは大きい。

最も大きなメリットの一つは、コストとスケーリングだ。RoboMakerはシミュレーション時間に応じて課金されるモデルだったが、AWS Batch自体にはサービス利用料がかからない。利用するのは、コンテナを実行するためのEC2（仮想サーバー）やFargateといったコンピューティングリソースの料金のみとなる。さらに、AWS Batchでは「スポットインスタンス」という、一時的に余っているAWSのリソースを格安で利用できるオプションを選択できる。シミュレーションのように途中で中断されても問題ないワークロードであれば、コストを最大90%削減できる可能性がある。また、RoboMakerがデフォルトで最大10個のシミュレーションを同時に実行できるという制限があったのに対し、AWS Batchはアカウントの制限や予算が許す限り、数百、数千といった膨大な数のシミュレーションを並行して実行できる。これは、例えば多数のロボットを同時にテストしたり、様々な条件下でのシミュレーションを繰り返したりする場合に非常に強力な利点となる。

具体的な移行ステップについて説明しよう。 まず、RoboMakerで作成したカスタムのワールドファイルやロボットのモデルなど、重要なアセット（資産）をエクスポートする必要がある。RoboMakerのWorldForge機能を使ってZIPファイルとしてS3に保存したり、手動でダウンロードしたりできる。

次に、ロボットのプログラムやシミュレーション環境をDockerコンテナとして「コンテナ化」する。これは、ROS2やGazebo、そして開発したロボットのコードなどを、Dockerという技術で一つの独立した実行環境としてパッケージングすることだ。例えば、ROS2 Humbleの公式イメージをベースに、GazeboやTurtleBot3（人気の教育用ロボット）のパッケージをインストールし、自分のロボットワークスペースをコピーするDockerfile（コンテナイメージを作るための指示書）を作成する。

作成したDockerイメージは、Amazon ECRというAWSのコンテナイメージを保存・管理するサービスにプッシュする。これにより、AWS Batchがそのイメージを使ってコンテナを実行できるようになる。

その後、AWS Batchの設定を行う。AWSコンソールで「コンピューティング環境」を作成する。ここでは、EC2インスタンスの種類（CPU中心のインスタンスか、GPU搭載のインスタンスかなど）や、オンデマンドかスポットインスタンスかを選択する。コスト削減のためにはスポットインスタンスが有力な選択肢だ。また、コンテナがECRからイメージをプルしたり、S3やCloudWatchにアクセスしたりするための権限を持つIAMロールを設定する。このコンピューティング環境に「ジョブキュー」を関連付け、最後に「ジョブ定義」を作成する。ジョブ定義では、どのDockerイメージを使い、どのくらいのCPUとメモリを割り当て、どのようなコマンドでシミュレーションを実行するかなどを具体的に指定する。

これらの設定が完了したら、AWS BatchのコンソールやCLI（コマンドラインインターフェース）からジョブを投入すれば、設定したコンテナが起動し、シミュレーションが実行される。

Batchでは、単一のコンテナだけでなく、複数のコンテナを一つのジョブ内で協調して動かしたり、複数のEC2インスタンスにまたがって一つの大きなシミュレーションを実行する「マルチノード並列ジョブ」もサポートしている。これにより、複数のロボットが連携するような複雑なシナリオも、より効率的にシミュレーションできるようになった。RoboMakerでは一つのコンテナ内で全てのコードを実行していたが、Batchのマルチコンテナ機能を使えば、Gazeboシミュレーター、LiDAR処理、制御、視覚処理といった役割をそれぞれ独立したコンテナで実行し、よりモジュール化されたシミュレーション環境を構築できる。

シミュレーションの監視やデータ管理も重要だ。実行中のコンテナから出力されるログは、AWS Batchによって自動的にCloudWatch Logsに送られるため、リアルタイムでデバッグや状況確認ができる。さらに、RoboMakerと同様に、ROSノードからロボットの位置やセンサーデータなどをCloudWatch Metricsに送信するように設定することも可能だ。シミュレーションの入力ファイル（ワールドファイルなど）や出力データ（rosbagファイルやCSVデータなど）は、Amazon S3というストレージサービスに保存するのが一般的だ。必要に応じて、Amazon EFSという共有ファイルシステムをBatchジョブにマウントして利用することもできる。

また、複雑なシミュレーションワークフローを自動化することも可能だ。例えば、異なるパラメータで複数のシミュレーションを連続して実行し、その結果に基づいて機械学習モデルをトレーニングするといった一連のプロセスは、AWS Step FunctionsやAWS CodePipelineといったサービスを使って自動化できる。Step Functionsは、一連の処理ステップを視覚的に定義し、順番に実行させるためのサービスで、Batchジョブの開始と完了を待つといった連携も容易だ。

まとめると、RoboMakerの終了は、ロボットシミュレーションのクラウド利用において、より汎用的で柔軟なAWS Batchへの移行を促すものだ。移行には、RoboMakerの特化した機能の一部を自前で構築する手間がかかるものの、コスト効率の向上、圧倒的なスケーリング能力、そしてインスタンスタイプや構成の自由度という大きなメリットが得られる。これらのメリットを最大限に活用することで、大規模なロボットシミュレーションや、より複雑なワークフローを構築する新たな可能性が開かれるだろう。システムエンジニアを目指す皆さんにとって、コンテナ技術やAWS Batchの活用は、今後のクラウドベースの開発において非常に重要なスキルとなるに違いない。