Physical AI デプロイと運用

文書基準: 2026年9月 | この文書は変化の速い領域であり、四半期ごとのレビュー対象です。

概要

この文書はPhysical AIパイプラインの後段 — 学習済みモデルを物理世界へデプロイし、安全に運用するまで — を扱います。全体パイプラインの概観はPhysical AI 概要を、データ・学習層はデータと学習を参照してください。

レイヤー3 — ロボティクス基盤モデル

基本用語 — policyとembodiment

ロボットが「いまの状況で何をするか」を決める関数をpolicy(方策) と呼びます。観測(observation) — カメラ映像、距離センサー、関節角度など — を入力として受け取り、行動(action) — 関節指令、移動指令など — を出力するのが、ロボット知能の最小単位です。以降に出てくるモデルはすべて、このpolicyをどう作るかという問題です。

ロボットの身体はそれぞれ異なります。ロボットアーム(manipulator)、四足歩行、ヒューマノイド、自律移動ロボット(AMR)は関節数(自由度)も制御方式も異なり、これら異なる身体をembodimentと呼びます。ある身体で学んだポリシーを別の身体へ移すcross-embodiment転移は、この分野の代表的な未解決課題です。

LLMが言語を一般化したように、ロボットの認識・計画・動作を一般化しようとするロボット基盤モデルが台頭しています。自然言語の指示を受けて視覚(Vision)・言語(Language)・行動(Action)を接続するVLA(Vision-Language-Action)方式が代表例です。

項目	現況
代表スタック	NVIDIA Isaac GR00T — ロボット向けオープン基盤モデル(VLA)、Omniverse・Cosmosベースのシミュレーション・合成データ、Jetson Thorのオンデバイス推論
主要クラウド	自社の汎用ロボット基盤モデルはまだ限定的 — 概ねNVIDIAスタックをGPUインフラ上で実行するか、パートナーシップで提供
国家政策	日本はGENIACでロボティクス基盤モデル開発を国家プロジェクトとして採択(日本のAI動向参照)

物理世界とエージェントの接続

ロボット基盤モデルが認識・計画・動作を担うとすれば、その上で目標を受け取り自ら手順を計画し、ツール・センサー・アクチュエータを呼び出して実行する自律実行層がエージェントです。Physical AIにおけるエージェントはデジタルエージェントと異なり行動が物理世界へ即座に反映されるため、接続方式と権限境界が安全に直結します。

エッジエージェント ↔ クラウドオーケストレーション — リアルタイムの判断・制御ループは現場(エッジ)で自律的に回り、長期計画・複数ロボットの調整・モデル更新はクラウドが担う分業が一般的です。ネットワークが切れてもエッジエージェントが安全に動作を継続、あるいは停止できる必要があります。
ツール・アクチュエータ接続(MCPなど) — エージェントがセンサー値を読み上位タスクを指示するには標準化された接続層が必要です。ただしMCPのようなプロトコルは高レベルのタスク指示・ツール呼び出し層であり、リアルタイムのアクチュエータ制御(モーター・関節など)は遅延・安全が保証される別の決定論的な低レベル制御層(フィールドバス・ロボットミドルウェアなど)が担います。この2つを混同してはいけません。自律実行・ツール呼び出しの一般概念はAIエージェント、エージェント-ツール連携プロトコルはAIエージェント連携 (MCP)を参照してください。

なぜ層を分けるのか — 制御周期の不一致

この分離は設計の好みではなく、動作周期が物理的に異なるためです。モーター・関節を保持する低レベル制御ループはミリ秒未満の周期で決定論的に回る必要がある一方、大規模マルチモーダルモデルの推論はそれよりはるかに遅く、遅延のばらつきも大きくなります。そのため一般的な構成は2層に分かれます。

遅い層(理解・計画) — 場面を理解し次の目標を決めます。モデルが重く周期が遅くても構いません。クラウドに置くこともできます。
速い層(実行・制御) — 与えられた目標を実際の関節軌道へ変換し、一定周期で実行します。必ず現場にあり、遅延が揺れてはなりません。

エージェント-ハードウェア接続の標準

MCPがエージェントとデータ・ソフトウェアツールをつなぐ標準として定着したのに続き、エージェントと物理機器をつなぐ標準も現れ始めています。Anthropicは2026年8月に**Model Hardware Standard(MHS)** のリサーチプレビューを公開しました。機器ごとにカスタムアダプタを作る代わりに共通ドライバで機器を公開し、1つのエージェントが複数機器を並列に扱えるようにすることが狙いです。安全上の限界はエージェントより下のドライバレベルで強制され、モデルがプロンプトで限界を越えられないよう設計されています。

安全レイヤー — 自動運転とロボティクス

物理世界で動くAIは人命・設備に直結するため機能安全(functional safety) が中核となります。自動運転はISO 26262、産業機械・ロボットはISO 13849・IEC 61508などドメイン別の安全規格と認証体系が別途適用され、AIモデルの判断とは無関係に動作する独立した安全層(安全停止、ハードウェアインターロック、安全PLCなど)を設けるのが原則です。

各ベンダー・サプライヤーはこれを実装した商用スタックを提供しています。例えばNVIDIAは安全システムHalosを提供しています。

自動運転(AV): DRIVEプラットフォーム(AGX・Hyperion)とHalos安全システム(クラウド-車両の全区間、ISO 26262志向)、シミュレーションはOmniverse・Cosmos。
ロボティクス: NVIDIAは2026年6月、自動運転の安全基盤を産業用ロボット・ヒューマノイド・AMRへ拡張した**Halos for Robotics**(IGX Thor・Holoscan Sensor Bridge・Halos OS・AI Systems Inspection Lab)を発表しました。

マルチクラウド・エッジアーキテクチャの考慮事項

何をエッジに、何をクラウドに置くか

Physical AI設計の出発点は、各タスクをエッジとクラウドのどちらに置くかを決めることです。判断基準は遅延感度、データ量(帯域)、安全要件、ネットワーク断絶時の動作です。

タスク	主な配置	理由
リアルタイムの認識・制御ループ	エッジ	遅延に敏感で、ネットワーク断絶時も止まってはならない
安全停止・緊急遮断	エッジ	クラウド往復の遅延を許容できない
センサーデータの一次フィルタリング・集約	エッジ	生データをすべて上げると帯域・コストが過大
データ保存・ラベリング	クラウド	多数の機器のデータを集約し学習資産として管理
モデル学習・再学習	クラウド	大規模GPU・データセットが必要(GPUインフラ参照)
合成データ生成・シミュレーション	クラウド	デジタルツイン・シミュレータに大規模演算が必要
複数ロボット・フリートの調整、長期計画	クラウド	個々のエッジの視野を超えた全体調整
モデルのバージョン管理・配信(OTA)	クラウド → エッジ	中央で管理し現場へ配信

閉ループ(closed-loop)の運用サイクル

Physical AIは一度デプロイして終わりではなく、現場データが再びモデルへ戻る循環構造で運用されます。概要文書のパイプラインフロー図の各段階は、次の運用サイクルに対応します。

エッジ推論 (フロー図の エッジ推論) — 現場でリアルタイムに認識・判断・制御し、有意なイベント・異常データのみを選別します。
テレメトリ収集・整備 (テレメトリ → データレイク・ラベリング) — 選別したデータ・走行/作業ログをクラウドへ上げて保存し、学習に使えるよう整備・ラベリングします。
クラウド再学習・シミュレーション (クラウド学習・モデル管理 ↔ シミュレーション・デジタルツイン) — 収集データでモデルを改善し、デジタルツイン・シミュレーションで新しいシナリオを検証します。
OTAデプロイ (デプロイ → エッジ推論) — 検証済みのモデル・ポリシーを再びエッジへ配信します。デプロイ失敗・回帰に備えた署名・ロールバックなどの一般パターンはハイブリッド・エッジコンピューティングを参照してください。

何をもって合格と判定するか

閉ループを回すには「このモデルを出してよいか」を判定する基準が必要です。ところがPhysical AIでは、学習損失(loss)が下がっても実際の成功率が上がるとは限りません。 実演データをよく模倣するよう学習したモデルでも、実演になかった状態に陥ると回復できないためです。

したがって判定基準は損失値ではなく、最後まで実行した結果(rollout)の成功率でなければなりません。実務では次の3層を分けて記録します。

判定層	何を測るか	限界
オフライン指標	検証データに対する損失・予測精度	成功率との相関が弱い。回帰検知用途に限る
シミュレーションrollout	シミュレータで作業を最後まで遂行した成功率	Sim-to-Real Gapの分だけ実際と乖離する
実機rollout	実機での成功率・介入回数・復旧時間	最も信頼できるが最もコストが高い

フリートデプロイ — 中断とロールバックは別の層

ロボット1台にモデルを載せることと、数千–数万台のフリートへ配信することは別の問題です。フリート規模では、誤ったモデルがどれだけ速く広がるかと広がった後に戻せるかが設計の核心になります。

段階的ロールアウト — 全体へ一度に配信せず、小規模グループから拡大し、失敗率が基準を超えたら拡散を止めます。
中断(abort) — 拡散を止める仕組みです。ただし多くのフリートOTAサービスで中断はまだ開始していない対象のみをキャンセルし、すでに進行中のデプロイはそのまま完了するため、利用するサービスの中断動作の範囲をベンダーのドキュメントで確認する必要があります。
ロールバック(rollback) — すでに新バージョンを受け取った機器を以前の状態へ戻す仕組みです。中断とは別の層であり、機器側に旧バージョンの保持やA/Bパーティションといった復旧経路があってはじめて実際に機能します。

その他の考慮事項

データ重力と遅延 — センサーデータは大量かつ遅延に敏感なため、現場のエッジ推論とクラウド学習を分担する設計が基本です。何をエッジで処理し何を上げるかを先に決めてください。
シミュレータの可搬性 — デジタルツイン・シミュレーションが特定クラウドの専用サービスに縛られると移行が困難になります。NVIDIA Omniverse・IsaacのようにGPUさえあればどこでも実行できるスタックを優先検討すればロックインが減ります。
オンデバイスとクラウド学習の分担 — 学習・合成データ生成はクラウドGPU、リアルタイム推論はオンデバイス(例: Jetson系)に分けるのが一般的です。
安全・規制 — 自動運転・産業用ロボットには機能安全の認証と規制が別途適用されます。アーキテクチャの初期段階で認証要件を反映してください。
製品ライフサイクルの確認 — この領域は提供終了(EOL)の製品が多くあります(例: Azure Percept、AWS RoboMaker、マネージドのラベリングサービス)。設計前に各サービスの現行サポート状況を必ず確認してください。

よくある間違い

安全を後付けにする — 自動運転・ロボットは安全をアーキテクチャの初期から設計する必要があります(「bolt-on」ではなく「built-in」)。
物理エージェントに無制限の権限を与える — 自律実行エージェントが制約なくアクチュエータを呼び出せると、誤動作が物理的被害に直結します。行動範囲の制限と安全層の検証が必須です。
中断基準だけ設けてロールバック経路を設計しない — 拡散は止まっても、すでにデプロイされた機器は戻りません。
大規模モデルをリアルタイム制御ループへ直接配置 — 制御周期を満たせず安全上の問題につながります。遅い計画層と速い制御層を分離してください。
シミュレーション成功率をデプロイ根拠に使う — 実機rolloutの検証ゲートなしにデプロイすると、Sim-to-Real Gapが現場で顕在化します。

チェックリスト

エッジとクラウドの配置

エッジで処理する推論とクラウドへ上げるデータを区分したか?
ネットワーク断絶時にエッジが自律的に(オフラインで)安全に動作するか?
各判断が何ミリ秒以内に終わる必要があるかを定義し、遅い計画層と速い制御層を分離したか?
オンデバイス推論とクラウド学習の役割分担が明確か?

安全・規制

エージェントが物理アクチュエータを呼び出すなら、行動範囲(action space)を制限し安全層の検証を設けたか?
自動運転・産業用ロボットであれば、機能安全の認証要件を設計に反映したか?

デプロイ・運用

モデルの合格基準を損失値ではなくrollout成功率で定義し、実機検証ゲートを設けたか?
フリートデプロイに段階的ロールアウトとロールバック経路をそれぞれ設計したか(中断だけで十分と仮定していないか)?
目標フリート規模が各ベンダーの調整不可なサービスクォータに収まるか?