フィジカル AI とは？リアルワールドを動かす AI の設計と実装

カテゴリー MaxのTips
カテゴリーイベント

こんにちは、ソラコムの松下（ニックネーム: Max）です。

2025年12月に米国/ラスベガスで開催された AWS re:Invent 2025 にて、AI がサイバー空間を飛び出して、現実世界（リアルワールド）を動かしていく「エッジ・フィジカル AI とAWS との関係性」について、ロボットアーム（SO-101）と AWS IoT Greengrass を用いたデモを交えて解説しました。

プレゼンテーションの様子は YouTube で公開されていますが、ここでは全体概要やセッションでお伝えしきれなかった情報をご紹介します。

「フィジカル AI」とは何か？

フィジカル AI とは、現実世界をセンサー等で観察し、AIが状況を判断して行動を決定し、ロボット等の機器操作として実行するという AI の使い方であり、考え方（コンセプト）です。

フィジカル AI は、人間の行動モデルの１つである OODA ループ（観察・判断・決定・実行）の一部または全部をデバイスと AI で担います。「ロボット＋AI」はその一例に過ぎません。本質はセンサーやアクチュエーターと連携し、AI が物理的な環境を判断・決定して動かしていくものです。

また、フィジカル AI は「どこで実行・推論するか」というアーキテクチャーの分類であるローカル・エッジ AI やクラウド AI とは異なります。エッジ AI はフィジカル AI の技術要素の一つですが、すべてではありません。要件によってはクラウド AI でもフィジカル AI は実現可能です。

フィジカル AI と IoT の関係性

フィジカル AI と IoT は密接な関係にあります。

OODA ループ “観察・判断・決定・実行” のうち、判断と決定は AI が担います。残る観察と実行を担うのが IoT です。現実世界をセンサーやカメラでデータ化したり、AI の実行計画（プラン）に基づいてロボットや機器を操作します。AI という “脳” に対する入出力、すなわち五感や手足が IoT であり、フィジカル AI において IoT は不可欠です。

フィジカル AI 、３つの設計要素

現在私たちが使っている AI の多くは、チャットボットやエージェントといった「画面の中の AI」でした。しかし、フィジカル AI はセンサーやカメラで現実世界を見て、モーターで物体を動かすことで、私たちと同じ物理空間で活動します。この「身体性」を持つ AI を実現するためには、以下の3つの要素が設計の柱となります。

Responsiveness（応答性）: 目の前の変化に、瞬きする間に反応すること。
Autonomy（自律性）: クラウドの返答を待たず、その場で判断して行動すること。
Collaboration（協調性）: 人間の意図を汲み取り、安全に共生すること。

決め打ち制御から、状況で動くロボットへ：VLA というアプローチ

「ロボット＋AI」を例に、フィジカル AI の効果を見てみましょう。

現在のロボット制御はどうしているのかといえば、人間がすべての動作をコードで記述したり、決まった動きを教えるティーチングによる「決め打ち制御（ルールベース）」が主流です。この手法は物体の位置が少しズレただけで動作が破綻します。そのため、ロボットが動きやすいように人間が位置調整をしているというのが現状です。

そこで登場するのが VLA（Vision-Language-Action）モデルです。 VLA はカメラ映像（Vision）と指示（Language）から直接「次にどう動くべきか（Action）」を生成します。観察・判断・決定・実行をすべてカバーしています。

セッションでは「黒い物体を見つけたら、片付け場所に移動する」という学習をした AI によるデモを紹介しました。

VLA に不可欠なカメラは、画面外の左側から机の上を撮っています。一般的な Web カメラです。そのほかの環境は以下の通りです。

Raspberry Pi 5 / 8GB + Raspberry Pi OS
SO-101 (ロボットアーム)
LeRobot (オープンソースのロボット操作・学習フレームワーク)
ACT (模倣学習アルゴリズム)

本デモはプロンプトを渡す VLA ではなく、模倣学習（人が教えた行動を真似る手法）を利用しましたが、ルールベースとは異なった AI によるデバイス操作の効果を感じていただけたかと思います。さらに、OpenVLA 等では「右の赤い立方体を左の箱に片付けて」といったプロンプトと現場の状況を基に AI が判断し、アーム操作を実行する「意図による自律動作」が可能です。

リアルワールドを動かすためのアーキテクチャー：100ms の壁

物理世界を扱うシステム設計において、重要な要件の1つが「遅延（レイテンシ）」です。たとえば自動販売機のボタンを押した際、人間が「反応がない」と感じ始めるまでの時間は、およそ100ms（0.1秒）という目安があります。

「フィジカル AI ＝エッジ AI」と思われがちな理由の１つに、この応答速度があります。クラウドにデータを送って結果を待つ数秒の遅延は、操作時の違和感に直結します。そのため、できる限りデータが生まれた場所（エッジ）で処理して応答時間を短縮するという考え方が、この背景です。

使い勝手の面で応答速度が重要なのは間違いありませんが、では、クラウドは本当に遅いのでしょうか？それを確かめるデモも行いました。

ローカルとクラウドの遅延比較デモ

二つのロボットアームは同期して動きます。その間を直接接続（左）、クラウド経由（右）で行った場合の遅延を比較したものです。

クラウドの方は、ラスベガス(US/西海岸)から US/東海岸のサーバーを折り返して通信しています。ping での RTT(往復時間) は 120ms ～ 130ms です。日本と US/西海岸間でも同様の RTT となります。これはネットワークだけで、アプリケーションレベルまで観察すると 500ms ～ 600ms の遅れが見受けられましたが、これは、わざと遠いサーバーを指定した＝ワースト寄りのケースとして紹介しました。

実は、同一リージョン内であれば ping の RTT が 30ms ～ 40ms 程度、アプリケーションレベルでも 150ms 程度の遅延に収まることもあります。このことから、遅延の期待値をコントロールできれば、クラウド AI でもフィジカル AI の実現は可能です。

ここでのポイントは、以下にまとめられます。

遅延の許容範囲を明確にする（過度な追求をしない）
計測をすること

つまり「フィジカル AI ＝エッジ AI」と安直に考えるのではなく、本当にエッジ AI が最適な解なのか？を検討することが重要です。

フィジカル AI の本質：モデルの優劣よりも「更新可能であること」

なぜ、エッジでの推論をテーマにしながら、セッションの中でわざわざクラウド AI との比較を提示したのかというと、そこには、アーキテクチャーを設計する上で最も重要な視点があります。

フィジカル AI を本格的に運用するフェーズにおいて、真に問われるのは AI モデル単体の賢さ（優劣）ではありません。「フィジカル AI を実現する “知能” = モデルを、いかに更新できるか “Updatable”」こそが本質です。

なぜ更新可能であるべきか？

ここはセッションで割愛した部分になりますが、ご紹介します。

物理世界は不確実性が高く、現場の環境変化や新しいタスクの追加など、絶えず変化します。従来のような「決め打ち」すなわち更新をしない戦略によって、変化に対応できず競争力を失うのは、ITの歴史が物語っています。

重要なのは、現時点での最高の AI モデルを選ぶことではなく、AI を更新できる仕組みを持つことです。これにより、常に最新の最適解を適用し続けられます。この「更新できる仕組み」こそクラウド AI の強みであり、フィジカル AI においてクラウド AI の利用を検討すべき理由です。

エッジでフィジカル AI を実装するならば、クラウド AI 並みに更新できる仕組みが不可欠です。

AWS IoT Greengrass がもたらす「クラウドの更新性をエッジへ」

エッジにおいて「クラウド AI 並みの更新性」を具現化する１つの方法が AWS IoT Greengrass (以下、Greengrass) です。

Greengrass の実体は AWS IoT Core 上で動く Greengrass 管理システムと、AWS IoT Greengrass Core という Linux や Windows 上で動くソフトウェアとのサーバー＆クライアントです。Greengrass は、AI モデルや推論ロジックを “コンポーネント” という単位でまとめて管理、配信できます。コンポーネントには Docker コンテナも指定でき、「デバイスへのコンテナ配信システム」という使い方もできます。

デモでは Hugging Face 上の VLA モデルをコンテナ化し(1/docker build)、Amazon Elastic Container Registry (Amazon ECR) にアップロード(2/docker push)。Greengrass からのデプロイ指示(3a)で
AWS IoT Greengrass Core が動いている Raspberry Pi がコンテナをダウンロード(3b/docker pull)して、VLA モデルを更新しました。

更新性を実現する要素「通信環境」

「AIをクラウド並みに更新し続ける」という戦略を実現するための重要な要素が、現場とクラウドをつなぐ通信環境です。

どれほど優れた VLA モデルを準備し、デプロイの仕組みを整えても、現場がオフラインであれば更新は途絶えてしまいます。フィジカル AI において通信は単なるインフラではなく、AI の鮮度を保つためのライフラインです。

デモで使った Raspberry Pi の通信環境には LTE 通信を使い、確実なネットワークを確保して臨みました。具体的には、 LTE USB ドングル SORACOM Onyx と SORACOM IoT SIM の plan01s を使っています。ちなみにこの様子やコマンドなどは別ブログ「LTE USB ドングル(アダプタ) SORACOM Onyx を Raspberry Pi OS(trixie) / NetworkManager で動かす」をご覧ください（登壇裏話もあります！）

物理世界（リアルワールド）の通信環境は常に不安定です。その不確実性を考慮し、いかなる状況でも「AI を入れ替えるための経路」を確保し続けること。この通信の設計までを含めて考えることが、フィジカル AI のアーキテクチャーを完結させる重要なポイントです。