Physical AI データと学習
文書基準: 2026年9月 | この文書は変化の速い領域であり、四半期ごとのレビュー対象です。
この文書はPhysical AIパイプラインの前段 — 物理世界からデータが入り、学習資産になるまで — を扱います。全体パイプラインの概観はPhysical AI 概要を、学習済みモデルをデプロイ・運用する後段はデプロイと運用を参照してください。
レイヤー1 — エッジ推論とIoT
Section titled “レイヤー1 — エッジ推論とIoT”物理世界のデータは大量かつリアルタイムであり、すべてをクラウドへ送って処理するのは困難です。現場(エッジ)でまず推論し、必要なデータのみをクラウドへ上げる構造が基本です。
| 項目 | AWS | Azure | Google Cloud | OCI |
|---|---|---|---|---|
| エッジランタイム | IoT Greengrass | Azure IoT Operations / IoT Edge | Google Distributed Cloud (Edge) | Roving Edge Infrastructure |
| エッジML推論 | Greengrass MLコンポーネント (SageMaker AIモデルのデプロイ) | IoT Edgeモジュール + Azure AIサービス | Edge TPU / Coral (現行サポート状況の確認が必要) | RED上のコンピュートで自前構成 |
| 産業データ収集 | IoT SiteWise (OPC UA) | IoT Operations (OPC UA) | — (パートナー・自前構成) | — (自前構成) |
エッジ推論ハードウェア
Section titled “エッジ推論ハードウェア”エッジランタイムがソフトウェア層だとすれば、その下で実際に推論を実行するアクセラレータハードウェアの選択が実現可能性とTCOを左右します。判断基準は4つです — 目標モデルを動かす演算性能、モデルが載るメモリ容量、ロボットの電力・発熱予算、そしてソフトウェアエコシステムの寿命です。
| 系統 | 性格 | 留意点 |
|---|---|---|
| ロボティクス向けエッジモジュール(例: NVIDIA Jetson系) | 低電力の小型モジュールから高性能モジュールまで幅が広く、ロボティクスVLAのオンデバイス推論でよく検討される選択肢 | 世代・モジュール間で性能とメモリの差が大きく、価格帯も大きく開きます。目標モデルが該当モジュールのメモリに載るかを先に確認してください |
| 汎用CPU内蔵NPU・小型アクセラレータ | 分類・検出のような軽量ビジョンには十分で、電力・単価が低い | 大規模マルチモーダル・VLA推論にはメモリと帯域が不足する場合が少なくありません |
| FPGA・産業用SoC | 決定論的な遅延と長期供給の保証が重要な設備に有利 | 開発難度が高く、モデル移植のコストが大きくなります |
| クラウド事業者のエッジアプライアンス | クラウドの運用ツール・管理体系を現場へ拡張 | 現場サーバー・ゲートウェイ用途であり、ロボット搭載のリアルタイム制御を代替しません |
センサーデータパイプライン — 収集・保存・ラベリング
Section titled “センサーデータパイプライン — 収集・保存・ラベリング”エッジから上がってきたデータをそのまま学習に使うことはできません。Physical AIのデータは1D時系列(関節角度・電流・温度)、2D映像、3D点群、設備メタデータが混在するマルチモーダルであり、収集 → 保存 → 整備・ラベリングの段階を経てはじめて学習パイプラインに入ります。
| 段階 | AWS | Azure | Google Cloud | OCI |
|---|---|---|---|---|
| ストリーム・映像収集 | IoT Core (エッジ入口) / Kinesis Video Streams・Data Streams (ダウンストリーム格納) | Event Hubs + IoT Operations | Pub/Sub | OCI Streaming |
| データレイク | S3 | Data Lake Storage | Cloud Storage | Object Storage |
| 学習用並列ファイルシステム | FSx for Lustre | Azure Managed Lustre | Managed Lustre / Parallelstore | File Storage with Lustre |
| ラベリング | SageMaker Ground Truth (新規顧客の受付終了) | Azure MLデータラベリング | — (マネージドは終了、パートナー・OSS) | OCI Data Labeling |
レイヤー2 — デジタルツインとシミュレーション
Section titled “レイヤー2 — デジタルツインとシミュレーション”ロボット・車両を実世界だけで学習させると、コスト・リスク・時間が大きくなります。そのため物理環境を仮想に複製したデジタルツインとシミュレーションで大量のシナリオを生成・学習し、現実へ移すsim-to-realのアプローチが定着しました。
| 項目 | AWS | Azure | Google Cloud | OCI | クロスベンダー |
|---|---|---|---|---|---|
| デジタルツイン | IoT TwinMaker | Azure Digital Twins | — (Spanner Graph・BigQueryなどで自前構成) | — | NVIDIA Omniverse |
| ロボット・物理シミュレーション | — (RoboMakerサポート終了、自前構成) | — (パートナー・自前構成) | — (パートナー・自前構成) | — | NVIDIA Isaac Sim / Isaac Lab |
学習データはなぜ不足するのか
Section titled “学習データはなぜ不足するのか”シミュレーションが選択肢ではなく前提になる理由はデータ希少性にあります。言語モデルはインターネット上のテキストという事実上無限の事前学習データから出発しましたが、「ロボットが実際に物を掴んで運んだ」データは桁違いに少ないのが実情です。Physical AIの学習は、安価で豊富なデータで不足を補う設計から始まります。
| データ層 | 性格 | 限界 |
|---|---|---|
| インターネット映像・画像・テキスト | 事実上無限で安価。一般常識・物体知識を提供 | ロボットの身体・関節指令と直接結びつかない |
| 人の作業映像(一人称) | 相対的に多い。動作順序・意図の手がかりを提供 | 人の身体基準のため、ロボットのembodimentへそのまま移せない |
| ロボットのteleopエピソード | 実際の関節指令を含み最も正確 | 人がロボットを直接操作して作るため、収集コストが最も高い |
teleoperation(遠隔操作) とは、人がコントローラやVR機器でロボットを直接動かして実演データを作る方式であり、そのデータをそのまま模倣するよう学習させるのが模倣学習(imitation learning) です。最も確実な方法ですが、人の時間がそのままコストになるため規模を拡大しにくいという制約があります。
公開データセットとベンチマークのエコシステム
Section titled “公開データセットとベンチマークのエコシステム”データ希少性は一つの組織だけで埋めるのが難しいため、複数の機関がデータを持ち寄り評価課題を共有する公開エコシステムが形成されています。スタックを選ぶ際、「このスタックでどの公開資産をそのまま使えるか」 はロックインを判断する実質的な基準になります。
| 区分 | 代表的な資産 | 何に使うか |
|---|---|---|
| クロスロボットデータセット | Open X-Embodiment (論文) | 複数機関のロボットデータを統合したコレクション。cross-embodiment事前学習の基準線 |
| 大規模操作データセット | DROID | 多様な環境で収集したteleopデータ |
| シミュレーションベンチマーク | LIBERO、CALVIN、RoboCasa、Meta-World | 標準課題セットでの作業成功率によりポリシーを比較 |
| 人の作業映像 | Ego4D | 一人称の作業映像。上記データ3層の中間層に相当 |
| オープンツールチェーン | LeRobot | データ形式・学習・評価をまとめたOSSスタック |
Sim-to-Real Gap
Section titled “Sim-to-Real Gap”シミュレーションの価値は明確ですが、シミュレータの物理・センサー・材質モデルは現実と微妙に異なります。 摩擦係数、照明、センサーノイズ、部品のガタつきといった差が積み重なり、シミュレーションで成功したポリシーが実機で失敗する現象をSim-to-Real Gapと呼びます。
一般的な緩和策は3つあります。
- ドメインランダム化 — 摩擦・質量・照明・テクスチャなどの物理パラメータを学習中にランダムに揺らし、現実がその分布に収まるようにします。
- 実機データによる少量のファインチューニング — シミュレーションで事前学習したポリシーを、実機データで仕上げ調整します。
- 実機検証ゲート — シミュレーション成功率とは別に、実機での成功率をデプロイ基準として設けます。
規模に見合う学習インフラ
Section titled “規模に見合う学習インフラ”Physical AIでありがちな誤解が「ロボットモデルの学習には必ず大規模GPUクラスタが要る」というものです。実際には事前学習済みのロボット基盤モデルを自社のロボット・作業に合わせるファインチューニングが大半であり、この区間はLLMの事前学習とは規模がまったく異なります。小規模なPEFT・アダプタ学習は、単一GPUの短時間ジョブで終わることが多くあります。
| 段階 | 作業の性格 | インフラパターン | コスト戦略 |
|---|---|---|---|
| 初期検証 | 実演データが少量、LoRA・PEFTアダプタの学習 | 単一GPUインスタンス1台 | スポット・プリエンプティブルインスタンスを既定に。中断されても再開コストが小さい |
| 作業特化 | 実演データが中規模、全体のファインチューニング | 単一ノード複数GPU + マネージド学習ジョブ | 自動チェックポイント・再開のあるマネージド学習サービス |
| プラットフォーム化 | 多数のロボット・多数の作業、反復的な再学習 | 複数ノード + 高速インターコネクト | 予約・コミット割引。ノードの自動復旧が必要(分散学習参照) |
よくある間違い
Section titled “よくある間違い”- すべてのデータをクラウドへ送る — 遅延・帯域・コストを無視した設計はリアルタイム制御で破綻します。エッジ推論の分担が先です。
- EOL製品を新規設計に使う — RoboMaker・Percept・マネージドのラベリングサービスのように、サポートが終了または縮小したサービスを古い資料だけで採用しないでください。
- 単一ベンダーのシミュレータに依存 — 特定クラウド専用のシミュレーションに学習パイプラインを縛ると、移行・比較が困難になります。
- GPUコストだけでTCOを見積もる — データ収集・保存・ラベリングとシミュレーションの占有コストが、学習演算とは別に発生します。
- シミュレーション成功率をデプロイ根拠に使う — 実機rolloutの検証ゲートなしにデプロイすると、Sim-to-Real Gapが現場で顕在化します。
チェックリスト
Section titled “チェックリスト”データ・コスト
Section titled “データ・コスト”- センサーデータの保存・整備・ラベリング層を設計し、ラベリングツールの代替可能性を確認したか?
- データ収集・保存・ラベリング・シミュレーションのコストをGPUコストとは別に算定したか?
- 利用する公開データセット・ベンチマークのライセンスと自社embodimentのカバー範囲を確認したか?
ハードウェア・学習
Section titled “ハードウェア・学習”- エッジアクセラレータをTOPSの数値ではなく目標モデルの実測で選定し、ドライバ・ランタイムのサポート寿命を確認したか?
- 学習規模に見合うインフラ段階を選んだか(初期検証で過度なコミットをしていないか)?
- デジタルツイン・シミュレーションスタックが他のクラウドへ移行可能か(ロックイン点検)?
- 利用予定のIoT・ロボティクスサービスは現行サポート状態か(EOL確認)?
- Physical AI 概要 — 全体パイプライン・階層構造・未解決問題
- デプロイと運用 — ロボティクス基盤モデル・安全・アーキテクチャ・フリートデプロイ
- ブロック・ファイルストレージ — 並列ファイルシステムの比較
- GPUインフラ — クラウド学習・シミュレーション用GPUクラスタ
- 分散学習 — 複数ノード学習・チェックポイント戦略
- AWS IoT Greengrass開発者ガイド
- AWS IoT TwinMaker
- AWS IoT SiteWise
- Amazon FSx for Lustre
- Amazon SageMaker Ground Truthドキュメント
- Azure IoT Operationsドキュメント
- Azure Digital Twinsドキュメント
- Azure Managed Lustre
- Azure Machine Learningデータラベリング