Physical AIを導入するなら何から決める？sensor・推論・制御・Cloudを分ける

結論

Physical AIは「どのモデルを載せるか」から始めず、sense→infer→decide→act→monitorのloopを分解し、安全停止に必要なlatencyとcloud切断時の動作を先に決めます。

判断の順番は 必須条件→費用/性能の得失→運用条件 です。価格、plan、求人、hardware仕様など時間で変わる事実には 2026-09-13 の観測日を付け、未測定の速度・品質・時間・電力を公式仕様から推測して数値化しません。

判断表：sense→infer→decide→act→monitorのarchitecture map

Sensor ── timestamp/calibration ──> Preprocess ──> Inference
   │                                           │ confidence + deadline
   │                                           ▼
   └── health ─────────────────────────────> Decision/State machine
                                                │ safety gate
                                                ▼
                                             Actuator
                                                │ state/limits
                                                ▼
Local log/buffer ────────────────> Monitor/Fleet/Cloud

Layer	必須input	failure時の既定動作	Production gate
sense	rate・timestamp・calibration	stale/欠損を明示	欠損を正常値扱いしない
infer	model/runtime/version・deadline	timeout/degraded	target HWでdeadline検証
decide	threshold・state・business rule	deterministic fallback	AI confidence単独で危険動作しない
act	speed/force/range limit	independent safe stop	safety limitをmodel外に置く
monitor	health・thermal・drift・network	local buffering/alert	cloud断でも安全側に動く

Physical AIでは精度だけでなく、deadlineを外した正解は制御上の失敗として扱います。

判断の前提

Physical AIはsensor input、inference、判断、actuator、monitoringが閉loopを作ります。LLM/vision model単体のbenchmarkではsystem safetyを判断できません。

edge側はlatencyとcloud切断時の継続性を担い、cloud側はfleet管理・学習・集約を担うなど役割を明示します。安全停止はAI出力とは独立したpathを持たせます。

Jetson/ROS 2ではhardware/software対応表とQoS/real-time条件があるため、SILで通った後にtarget hardwareでHILを行う公開条件を置きます。

このテーマで実際に見るポイント

sense

sensor rate、timestamp、calibrationを固定。

infer

deadline内に出ない推論は精度が高くても失敗。

decide

AI confidenceだけでactuationを決めずstate machine/safety ruleを併用。

act

force/speed/areaなどphysical limitをAI外で制約。

monitor

drift、sensor health、thermal、networkをfleet側で観測。

Cloudへ送る前にlocal deadlineを決める

Physical AIで最初に決めるべきは「どのmodelを使うか」ではなく、sensor inputからactuator commandまでに許される最大時間です。安全停止や衝突回避のように遅延許容が小さいloopをcloud round-tripへ依存させると、network jitterや切断がそのまま制御riskになります。local edgeで完結すべきloopと、cloudへ送ってよいanalytics/training/fleet管理を分離します。

SensorからAIまでのdata contract

sensor rate、timestamp、座標系、calibration versionをmodel inputと一緒に管理します。画像だけ正しくてもtimestampが古ければ判断は誤ります。複数sensor fusionでは、欠損・遅延・clock driftをfailure caseに入れます。Jetson/ROS 2を採用する場合も、hardware性能よりこのdata contractが先です。

AI判断と安全制御を同じ層にしない

modelのconfidenceが低いときにどうするか、推論がtimeoutしたらどうするかをstate machineへ明示します。motorの最大speed/force、立入禁止領域、emergency stopはAI出力を無条件で通さず独立したsafety layerで制約します。これはmodel accuracyを上げる施策とは別です。

PoCから実機へ進む確認項目

simulationで動いた後、software-in-the-loop、hardware-in-the-loop、限定環境の実機と段階を分けます。各段階でlatency distribution、sensor欠損、thermal throttling、network断、再起動後のstateをraw logへ残します。平均latencyだけでなくdeadline missを数えます。

運用開始後

model version、runtime/JetPack、sensor firmwareをfleet単位で追跡し、rollbackできるようにします。cloud監視が落ちてもlocal safetyが維持されるかを定期検証します。Physical AIは「AI modelの精度」と「制御systemの安全・可用性」を別KPIとして持つのが重要です。

hardware選定は最後に戻す

必要sensor bandwidth、model memory、deadline、actuator I/O、networkが決まってからJetson等の候補へ落とします。AI TOPSが大きくてもcamera input数やreal-time interfaceが不足すればsystem要件を満たしません。反対に軽いperceptionだけなら最大構成はpower/thermalの無駄になることがあります。

Securityもphysical safetyと接続する

remote updateやfleet管理のcredentialが侵害されれば、software問題が物理動作へ波及します。secure boot、signed update、device identity、management networkをarchitecture mapへ追加し、update失敗時のrollbackとsafe stateを決めます。

選ばない・進めない条件

target hardware上のlatency、安全停止、network断の挙動をHILで確認できないまま実機運用へ進めない。

これは「慎重に」という抽象論ではなく、比較表の必須条件を満たさない候補をランキングから外すための公開条件です。

一次情報

• NVIDIA — Jetson Thor
• NVIDIA — JetPack
• NVIDIA — Isaac ROS
• ROS 2 — QoS settings
• ROS 2 — Topics/services/actions
• NVIDIA Isaac ROS — Getting started

まとめ

Physical AIは「どのモデルを載せるか」から始めず、sense→infer→decide→act→monitorのloopを分解し、安全停止に必要なlatencyとcloud切断時の動作を先に決めます。

変化が速い領域ほど固定ランキングより、同じinputで更新できるsense→infer→decide→act→monitorのarchitecture mapを正本にします。更新時は変化した項目だけを最新の情報源/実際の観測結果で差し替え、同じ判断基準で結論を再計算します。