@yoshiyakato(加藤義也)

フィジカルAI　とは　応答速度が異なる反応系の組みあわせ？

Last updated at 2026-06-03Posted at 2026-06-03

フィジカルAI = LLM/VLM × エッジAI × エッジ制御 ── 「研ぎ澄まされた制御はAIか？」

最近「フィジカルAI」という言葉をよく見るようになりました。

ただ、言葉だけを見ると少し大きすぎます。

ロボットのこと?
生成AIのこと?
画像認識のこと?
自律制御のこと?
エッジAIのこと?

どれも関係していそうだけど、単体では説明しきれない。

最近、ドローンの構成を研究しているのですが、ドローンは独自の進化を遂げているフィジカルAIと言って良いのかどうか？　とするとドローンの自律姿勢制御を司るFCはもはやエッジAIではないのか？
と思索を巡らせていた。

そこで自分なりに整理すると、フィジカルAIはかなりシンプルに、こう捉えると分かりやすいのではないかと思い、その気づきを忘れまいとこの記事を書き始めました。

フィジカルAI = LLM/VLM × エッジAI × エッジ制御

はい。つまり、フィジカルAIとは「LLMをロボットに載せること」ではなく、

意味を理解するAI、現場を見るAI、身体を動かす制御系をつないだ物理実行チェイン

なのではないか、という話です。

ただし、この記事ではもう一歩踏み込みます。多くの「フィジカルAI」論は、情報側(LLM)から物理側へ降りてくる視点だけで語られがちです。本稿は、物理側からも知能は上がってきているという対称的な見方を加えたい。結論を先に言うと、フィジカルAIの本質は「LLMがロボットを動かす」ことではなく、物理側から上がってくる知能と、情報側から降りてくる知能が出会う境界面の設計にあります。

まず、LLMだけではフィジカルAIにならない

LLMは非常に強力です。

自然言語の指示を理解し、手順を分解し、曖昧な状況を説明し、例外時の判断もある程度できます。

たとえば、

赤いブロックを右の箱に入れて

という指示を受けたとき、LLMは次のような手順に分解できます。

赤いブロックを探す
右の箱を特定する
赤いブロックを掴む
右の箱まで移動する
ブロックを置く
成功したか確認する

ただし、LLMはそれだけでは物理世界を動かせません。

LLMに直接、

joint_1を3度動かして、joint_2を-5度動かして……

のような低レベル制御を任せるのは危険です。

理由は単純で、ロボット制御にはミリ秒単位の応答や、安全停止、トルク制限、衝突回避が必要だからです。
LLMは「何をしたいか」を扱うのは得意ですが、「今この瞬間にモーターをどう回すか」を扱うものではありません。

3層で見ると整理しやすい

フィジカルAIを実装寄りに分解すると、次の3層になります。

層	主な役割	フィジカルAIにおける意味
LLM / VLM	意図理解・意味理解・作業計画	「何をしたいのか」「どの順でやるのか」を決める
エッジAI	認識・状態推定・局所判断	物理世界を見て、対象・位置・状態・失敗を判断する
エッジ制御	リアルタイム制御・安全実行	実際に身体を動かし、安全に止める

この3つがつながって初めて、物理世界に作用するAIになります。

人間の意図
  ↓
LLM / VLM
  ↓ 作業指示・計画
エッジAI
  ↓ 現場認識・把持判断・状態推定
エッジ制御
  ↓ モーター・アクチュエータ
物理世界が変化
  ↓ センサーで再観測
エッジAI / LLMへフィードバック

ポイントは、一方向の命令系ではなく、センサーで結果を見ながら修正する閉ループであることです。

VLMとは何か

ここで出てくる VLM は Vision-Language Model の略です。日本語では「視覚言語モデル」と呼ばれます。

簡単に言うと、

画像や映像を見て、その内容を言葉で理解・説明・判断できるAI

です。

LLMがテキストを読むAIだとすると、VLMは画像も読めるLLMのようなものです。

ロボットアームであれば、VLMはたとえば次のような判断に使えます。

赤い部品はどれか
箱Aはどこか
机の上に障害物はあるか
人の手が近くにあるか
作業が成功したように見えるか
この部品は傷ついているか
どれを掴むべきか

ただし、VLMも万能ではありません。

「赤い部品が右側にある」といった意味理解は得意でも、ミリ単位の把持点推定や、リアルタイム衝突回避や、1〜10ms単位のモーター制御には向きません。そこはエッジAIやエッジ制御の仕事です。

応答時間で責任分界を考える

この3層は、役割だけでなく「期待される応答時間」がまったく違います。

分類	応答時間の目安	代表例	LLMに任せてよいか
低レベル制御	1〜10ms	モーター制御、PID制御、姿勢制御、関節角制御、トルク制限	不可
安全停止・フェイルセーフ	10〜100ms	衝突検知、非常停止、人検知、通信断時の停止	不可
認識・状態推定	50〜500ms	物体検出、姿勢推定、把持点推定、障害物検出	基本はエッジAI
動作プリミティブ	0.5秒〜数秒	pick、place、scan、move_to_pose、局所リトライ	LLMは命令だけ出す
タスク計画	1〜10秒	自然言語理解、作業手順化、曖昧指示の解釈	LLM向き
例外判断・対話	数秒〜数十秒	失敗理由説明、人間への確認、再計画、ログ生成	LLM向き

ここで重要なのは、

応答時間が短いほど、LLMから遠ざける

という原則です。

速い・危険・連続的
    ↓
エッジ制御に任せる

中速・認識・局所判断
    ↓
エッジAIに任せる

遅くてよい・意味理解・計画・説明
    ↓
LLMに任せる

LLMは思考や説明には向いていますが、モーター制御や緊急停止には向きません。

横道に入る前に ── 「制御系はAIではない」という素朴な前提を疑う

ここまでは「LLM/VLMがAIで、制御系はその下請けの非AI」という暗黙の前提で書いてきました。多くの記事もそうです。でも、この前提は実はかなり怪しい。本稿の中心はここからです。

「自律姿勢制御はAIか?」と問うと、多くの人は反射的に「いや、あれは制御工学であってAIではない」と答えます。私も最初はそう整理していました。でも、AIでないと言うための根拠を詰めていくと、残る線は2本しかなく、どちらも持ちません。

「学習していないから」 ── これは持ちません。学習はAIの十分条件であって必要条件ではない。古典的プランナー(A*、min-max探索)も古典的GOFAIの中核で、誰もAIから外しません。学習の有無でAI/非AIを分けるのは、深層学習時代に後付けされた狭い定義にすぎない。

「単純だから」 ── これも持ちません。EKF(拡張カルマンフィルタ)による状態推定、非線形系の安定化、外乱下での目標追従は「単純」ではないし、そもそも複雑性はAIの定義要件ではない。「ではサーモスタットもAIか」と問われれば、知覚-判断-行動ループを持つ最小の作用主体という意味で、Wienerのサイバネティクスの視座では実際それは最小のAIだと言ってよい。

残るのは結局**「慣れ」**だけです。姿勢制御が枯れて当たり前になったから、AIと呼ぶと大げさに感じる。これは有名な AI effect ── 「動いて実用化された途端、それはAIではなくなる」という認識のクセそのものです。チェスもOCRも音声認識も、使えるようになった瞬間「単なるアルゴリズム」に格下げされてきました。姿勢制御もその系譜の被害者かもしれない。

なので本稿の立場は、留保なしに 自律姿勢制御もAIと言ってよい、です。ただし「全部AI」と言い切ると識別力を失うので、二値ではなく自律性の階層で語ります。

自律性の3つの階層

「AIか/AIでないか」の二値で押すより、自律の次元で語る方が、物理と情報の連続性を正確に描けます。

階層	名称	何をしているか	入力空間	代表例
第1層	反応的自律 (reactive autonomy)	誤差を検出し打ち消す	センサ値(連続量)	姿勢制御、position hold、モーターアウト再構成
第2層	熟慮的自律 (deliberative autonomy)	事前定義の方針から選ぶ・経路を計画する	記号空間(緯度経度・状態)	waypoint navigation、フェイルセーフ段階遷移
第3層	概念的自律 (conceptual / grounded autonomy)	開いた概念を世界にグラウンドして即興する	自然言語・概念空間	「郵便局まで行って撮影して戻れ」

重要なのは、3つとも自律でありAIだが、自律の次元が違うという点です。フィジカルAIが目指しているのは第3層ですが、第1層・第2層がAIでないわけではない。むしろ ──

物理側からの上昇 ── 制御理論はすでに「例外対応」を持っている

ここがこの記事で一番伝えたいところです。

ドローンの挙動を3つ並べると、物理側がどこまで「知能的に見える堅牢性」を獲得しているかがよく分かります。

① 風下でも同一地点に留まる(position hold / loiter)

GPS+IMU+気圧/対地センサで位置誤差を検出し、外乱(風)を打ち消す推力ベクトルを連続生成しているだけ。フィードフォワードはなく、ひたすら誤差を潰す。

でも外から見ると「風に逆らって踏ん張る意志」に見える。突風に流され、また戻ってくる挙動は、決定論的なのに「立て直した」と擬人化される。最も物理側に張り付いたAIの、最も分かりやすい顕現です。これが第1層(反応的自律)。

② 電圧低下時のフェイルセーフ

ここで質が一段上がります。多くのフライトコントローラーは多段の閾値を持ち、電圧/残容量に応じて「警告 → RTL(自動帰還) → その場着陸」と段階的に方針を切り替える。

これはもう単なる誤差抑制ではなく、**状態に応じた方針選択(ポリシー切り替え)**です。「目標を諦めて安全を優先する」という価値判断の萌芽がここにある。第1層と第2層の境界です。ただし判断ロジックは事前定義の閾値テーブルなので、「設計者の意図の再生」に留まる ── 自分で帰還を発明したわけではない。

③ 冗長ローター機で1基故障(モーターアウト)

3つの中で最もAI的に見えるし、技術的にも一番深い。

ヘキサ/オクトコプターでは1基喪失時に**制御アロケーション(control allocation)**を再構成し、残存ローターの推力配分を解き直して姿勢を保つ。機種によっては効きの悪い軸を犠牲にしてでも墜落だけは回避する縮退飛行に移る。クアッドで1基失うと制御自由度が足りず、意図的にヨー回転を許容して推力軸方向だけ保つ「relaxed hovering(緩和ホバリング)」のような縮退状態すら研究されています(機体は推力軸まわりに回転し続けるが、位置と高度は維持される)。

ここで起きているのは、故障という想定外に対して、残りリソースで目標を再充足するという、まさに「例外対応」です。

そして決定的なのは ── これの大半にLLMは要りません。制御アロケーションの数理(擬似逆行列、QP最適化)と FDI(fault detection and isolation)で実現されている。

「例外対応はLLMの仕事」という素朴な整理は、物理層に降りると崩れる。
物理側には物理側の、古くて強力な例外対応の数理がある。

フィジカルAIの議論は情報側(LLM)からの下降ばかり語られがちですが、物理側からの上昇 ── ロバスト制御、適応制御、故障耐性 ── が既に相当の高さまで来ている。両者が出会う面こそが本当の境界面です。

では、LLMは何のために要るのか ── シンボルグラウンディング

物理側がこれだけ強いなら、LLMの担当範囲はどこか。境界はシンボルグラウンディングの有無で引けます。

入力が事前定義の記号空間(緯度経度、ID、waypoint)に閉じている → 第2層。高機能オートメーションで足り、LLMは不要
入力が開いた概念空間(「郵便局」「人が少ない場所」「安全な着陸地」)から自由に取られる → 第3層。ここで初めてLLM/VLMが要る

「(35.6895, 139.6917)へ行って戻れ」は、経路計画・軌道生成・状態推定・外乱抑制を含む決して単純でない仕事ですが、グラウンディング層を人間の脳(オペレータ)に外注している。waypoint navは「人間との分業を前提にした半端系」です。

「郵便局まで行って撮影して戻れ」が直感的にAIの閾値に感じられるのは偶然ではありません。ここで初めて「郵便局」という概念を世界モデルにグラウンドし、視覚的に同定し、安全な経路と撮影構図を即興する必要が生じる。フィジカルAIとは、この分業境界を機械側に飲み込もうとする営みだと言えます。

「指示・状況理解・意図・企図」というスペクトルで言えば、現状の実用ラインは「状況理解」と「意図解釈」あたりまで。**「企図」(言われていないことを自発的に計画する)**に踏み込むと、もはやフィジカルAIというより自律エージェントの問題系で、まだ研究領域です。

どれくらいのLLMサイズで「フィジカルAI」になるか

実装の現実論として、小型LLM + フライトコントローラーで「フィジカルAI」は十分成立します。タスクを分解して見積もると:

タスク	必要サイズの目安	補足
指示 → フライトプラン変換	2B級で十分	Gemma系2B、Qwen2.5 3B級 + 構造化出力(JSON Schema constrained decoding) + ツール呼び出し(geocoding/地図参照)で安定実用
安全の常時確認	そもそもLLM外	ジオフェンス、電圧、姿勢逸脱、通信ロスは決定論的supervisorで実装すべき。LLMを入れる方が安全性が下がる
想定外の例外再計画	7B〜14Bが実用閾値	open-endedな再計画はsmall modelだと「もっともらしい誤判断」の確率が無視できない。Qwen 7B / Llama 8B / Phi-4(14B)級から堅牢性が立ち上がる

現実的な実装戦略は階層構成です。

オンボード 2B   …常時稼働・低遅延・定型対応
    ↓ 通信可能時のみ
クラウド 70B+   …novel exceptionへエスカレーション
    ↓ 通信断時
オンボード 2B   …保守的判断(帰還/ホバリング)へフォールバック

Jetson Orin Nano/NX級なら2BのINT4推論は十分回るので、「2Bでどこまで?」はハードウェア制約ではなくシステム設計問題です。問い直すと:LLMに何を担わせない設計にできるか ── これと表裏一体です。

ドローンのフライトコントローラーは、かなり良い先行モデル

この話を考える上で、ドローンはとても分かりやすい例です。フライトコントローラーは、すでに多くのことをやっています。

モーター回転数の制御
姿勢制御
高度維持
GPSによる位置推定
バッテリー監視
風などの外乱への補正
通信断時のフェイルセーフ
Return to Home
Waypoint移動

ユーザーや上位システムは、必ずしもモーターの回転数を直接指定しません。むしろ「この緯度経度へ移動せよ」「ホームへ帰還せよ」という、より抽象度の高い命令を出します。

これはフィジカルAIでも同じ構造です。

ドローン	ロボットアーム	担当	自律階層
ESC / モーター制御	サーボ / 関節制御	エッジ制御	第1層
姿勢安定化	アーム姿勢・軌道追従	エッジ制御	第1層
障害物回避	衝突回避 / 人検知	エッジ制御 + エッジAI	第1〜2層
GPS waypoint移動	move_to_pose	エッジ実行層	第2層
Return to Home	home / safe_pose	エッジ実行層	第2層
ミッション計画	作業手順計画	LLM	第3層
撮影目的・報告生成	作業説明・例外判断	LLM	第3層

つまり、フライトコントローラーはフィジカルAIにおける「エッジ実行層(第1〜2層を担う自律体)」の先行モデルとして見られます。ロボットアームでも、LLMが直接サーボを動かすのではなく、アーム版フライトコントローラーのような層が必要になる。

ロボットアームなら、エッジAIに何を持たせるか

センサーフュージョン

ロボットと環境の状態を常時把握します。関節角度、モーター電流、トルク、グリッパー開閉量、カメラ画像、Depth情報、力覚センサー、接触センサー、作業台上の物体位置、人間の接近検知 ──

LLMが毎フレーム画像を見るのではなく、エッジ側が状態を構造化して、必要に応じてLLMへ渡すのが自然です。

プリミティブ動作の実行

LLMには、関節角ではなく意味レベルの命令を出させます。

{
  "command": "pick_and_place",
  "target": "red_block",
  "destination": "box_A"
}

エッジ側は、それを具体的な動作に分解します(対象確認 → 把持候補計算 → 衝突回避経路計画 → 接近 → グリッパー閉 → 把持判定 → 移動 → 離す → 成功確認)。

動作プリミティブの例:move_to_pose / open_gripper / close_gripper / pick / place / home / stop / scan_workspace / retry_grasp / inspect_object / return_to_safe_pose

リアルタイム安全制御(LLMに任せてはいけない)

可動範囲制限、関節速度制限、トルク上限、接触検知、人間接近、カメラ喪失、通信断、電源低下、異常振動、予期しない障害物、グリッパー過負荷 ──

LLMとの通信が切れた → safe_poseへ移動
人が近づいた       → stop
トルク異常         → motion abort
物体が落ちた       → 作業停止して報告
カメラが見えない   → scan or request help

これは、ドローンが風で流されたとき上位AIに相談せず姿勢を補正するのと同じ第1層の仕事です。

局所的な失敗検知とリトライ

掴めなかった、少し滑った、対象が数cmずれていた、把持位置をずらして再試行、別の角度を試す、一定回数失敗したらLLM/人間に報告 ── これも第1〜2層で閉じる例外対応です。

世界モデルのローカル更新

エッジAIは簡単な作業空間モデルを持ち、LLMにはその要約を渡します。

{
  "workspace": {
    "objects": [
      {"id": "red_block", "type": "block", "reachable": true},
      {"id": "blue_block", "type": "block", "reachable": false}
    ],
    "zones": [
      {"id": "box_A", "status": "empty"},
      {"id": "human_zone", "occupied": false}
    ]
  }
}

設計原則 ── エッジ側に「拒否権」を持たせる

LLMは操縦者ではなく作業監督です。低レベル指示ではなく意味レベルの指示を出させます。

{
  "action": "pick_and_place",
  "target": "red block",
  "destination": "right box"
}

LLMは「何をしたいのか/どの順でやるのか/失敗時に人間に何を確認するのか」を担当します。
一方で「本当にその動作をしてよいか/衝突しないか/人間が近くにいないか/可動範囲を超えていないか/トルクが危険値を超えていないか」は、エッジ側が判断する。

つまり、エッジ側には拒否権が必要です。LLMがありえない座標を指定したら ──

{ "command": "move_to", "pose": [999, 999, 999] }

エッジ側はこう返すべきです。

{ "status": "rejected", "reason": "pose_out_of_workspace" }

人間の手の近くの物体を掴もうとしたら、

{ "status": "blocked", "reason": "human_too_close" }

LLMの出力をそのまま実機に流すのではなく、エッジ側で安全性・実行可能性を検証する。この拒否権こそ、第1〜2層の自律体が第3層に対して持つべき主権です。

補論 ── ユーザー目線と提供側目線の非対称性

最後に、産業構造として面白い論点を一つ。

利用者から見れば「自然言語で頼んだら物理世界で結果が返ってくる」体験そのものがフィジカルAIで、内部の分業構造への関心はない。しかも 「フィジカルAIだ」と認識させるエンジニアリングコストは、それを実装するコストより遥かに低い。自然言語が入口にあるだけで人は背後を「知能」と認識し(ELIZA効果の物理版)、物理的に動く対象だと認識される知能量がさらに跳ね上がる(embodiment effect)。失敗すら「健気な努力」に見える。

一方、提供側(特にLLMプロバイダ)は明確に線を引きたい。理由は複数あります。

責任分界 ── 墜落時に「郵便局」の解釈ミスか、autopilotの回避失敗か
課金設計 ── トークン課金と機体運用課金は別軌道
安全認証レジームの分離 ── 飛行制御層は(有人機や高リスクUAS=Certifiedカテゴリでは)DO-178C等の認証下に置かれうる一方、LLM層は無認証。混ぜると規制が降りてくる(※消費者向け小型ドローンの大半はOpen/Specificカテゴリで、DO-178Cの本格適用外。ただし機体が大型化・社会実装が進むほどこの認証境界が効いてくる)

先例はTeslaのAutopilot/FSDで、ユーザーは「自動運転」と認識するが、法務は「運転支援・ドライバー責任」を死守し続けている。ユーザー体験のカテゴリと提供側のカテゴリの乖離は、技術問題ではなく法務的・経済的圧力の帰結です。

そして利用者がこの線引きに無関心でいられるのは失敗が起きるまで。誰が悪かったかを問う瞬間、利用者も急に線引き問題に巻き込まれる。フィジカルAIという呼称が普及するほど、この摩擦面は大きくなります。

まとめ

フィジカルAIを「LLMがロボットを動かす」と考えると、少し危ういです。むしろ、こう考える方が実装に近い。