ロボット無しで始めるPhysical AI：安全な学習手順と、実機へ進まない判断

この章の境界

ここで扱うのは、ロボットを接続せず、モータを動かさず、他人や物を危険にさらさない学習手順である。実機の安全性、電気配線、機体互換性、性能はこの章では検証していない。Physical AI を始める時、まず身体を買うより、データと評価の因果を読めるようになる方が、後の失敗を安くする。

1. 1公開資料を読む
2. 2データの一エピソードを可視化
3. 3成功条件を言語化

1. 1合成データで評価器を作る
2. 2シミュレーションで仮説を反証

1. 1安全レビュー
2. 2実機が必要か判断
3. 3必要なら別計画で段階試験

第一週：観測と行動を読む

LeRobotの公開資料を読み、データセットの画像、state、action、episode、timestamp が何を指すかを自分の言葉で説明する。一つの公開エピソードを時系列に描き、「画像で見える変化」「state でしか見えない変化」「action が表す意図」を三列にする。ここで最初に発見するのは、画像だけではグリッパ開度や関節限界が分からず、action だけでは何を避けたのか分からないということだ。

次に、成功ラベルを再定義する。物体が目的地に一瞬入っただけなのか、安定して置かれたのか、接触が許容範囲だったのか。論文の success rate はこの定義に依存する。OpenVLA 論文や GR00T N1を読む際にも、モデル名より評価プロトコルを先に抜き出す習慣を作る。

第二週：評価器を先に書く

合成の 2D ブロック世界を紙、表計算、簡単なプログラムのどれかで作る。状態は block=(x,y), goal=(x,y), obstacle、行動は上下左右と停止だけでよい。方策を学習させる前に、到達、障害物衝突、境界逸脱、歩数超過を判定する評価器を書く。意図的に悪い方策を三つ作り、評価器が各失敗を検出することを確認する。

この演習の要点は、モデルを良く見せるためではなく、評価が何を見落とすかを先に発見することだ。ゴールに近いだけを報酬にすると、障害物を貫く経路が高得点になるかもしれない。正確な位置だけを見ると、到達までの危険な振動を見逃す。実機で同じ穴を見つける前に、低リスクの系で仕様を直せる。

第三週：分布ずれを意図的に作る

学習用の背景を白、ブロックを赤と青に限定した後、評価では黄色、影、カメラのずれ、障害物、開始位置の変更を加える。精度が下がった時、「モデルが一般化しない」とだけ言わない。視覚表現、座標変換、行動制約、成功定義、データ量のどれが変わったかを一つずつ記録する。VLA の大規模事前学習は意味表現の助けになり得るが、手元の物理条件に対する十分なデータと評価を不要にはしない。

実機へ進む前の停止条件

以下が曖昧なら、実機計画を始めない。(1) 非常停止を誰がいつ押せるか、(2) 速度・力・可動域の上限、(3) 人と壊れやすい物からの隔離、(4) 遠隔操作と自律の切替、(5) 通信断時の停止、(6) ログと再現手順、(7) 失敗を許容する対象。高性能なモデルデモはこのリストを代替しない。人型のような多自由度システムでは、転倒と接触を含む追加のリスク評価が要る。

まとめの演習

公開論文一つを選び、「入力」「出力 action」「身体」「データ」「評価」「明示されない安全境界」の六欄で一ページに要約する。次に、実機を使わない再現課題を三つ書く。例はデータ schema の検証、動画と行動時刻のずれ検出、合成環境での安全評価器である。最後に「この結果だけでは主張できないこと」を同じ量だけ書く。Physical AI の学習で信頼できる進捗とは、できたデモの数ではなく、観測済みの事実と未検証の仮説を分離できることだ。

実機なしで検証できる四つの成果物

第一は dataset validator である。上の schema を読み、欠損、単位不明、timestamp 逆転、episode をまたぐ frame、範囲外 action を report にする。第二は replay viewer で、画像、state、action を同じ時刻軸に並べる。手元の視覚だけでなく「この時刻に何を命令したか」を一目で検査できる。第三は policy contract test で、入力 shape、不正値、停止フラグを与えた時に、方策が例外または安全な no-op を返すかを確かめる。第四は simulator-free な counterfactual 表で、対象物が消える、カメラが遮られる、通信が遅れる時に期待する遷移を定義する。

これらは実機性能を証明しないが、実機へ進む前の不明確さを減らす。検証結果には test_id, input_version, expected, observed, reviewer, timestamp を残す。観測が期待と異なったら、モデルを直す前に仕様・データ・評価器のどれが間違っているかを疑う。実機を持たないことは制約であると同時に、安全条件と測定可能性を先に学ぶ機会でもある。

数値で考える停止境界

仮に action が 10Hz で delta_xyz を送るなら、各周期 1cm の命令は、検査無しには一秒で 10cm になる。上限を ||delta|| <= 0.005m、作業領域を x∈[0.1,0.4], y∈[-0.2,0.2], z∈[0.05,0.3] と書けば、制御器に渡す前に決定論的に弾ける。これらの数値は実機の推奨値ではなく、境界を明文化する例である。実際の値は機種、負荷、周囲、人への影響を踏まえて安全責任者と定める。

非実機の提出物として、(a) schema validator の失敗レポート一例、(b) split 重複を検出したテスト結果、(c) 座標変換の往復計算、(d) 停止条件を含む状態遷移図、を揃える。各成果物に「入力」「期待」「観測」「未検証」を書けば、次の人がハードウェア無しでも設計をレビューできる。性能を主張する成果物ではなく、安全に未知を減らす成果物として扱う。

レビューでは、各成果物に反例を一つ要求する。validator には timestamp 逆転、split には重複 video、座標には回転符号逆、状態図には通信断を入力する。正常例だけの確認は、危険な境界が実装された根拠にならない。反例を通した記録は、将来実機計画を始めるかどうかの判断材料になる。

作業を終える条件も明文化する。各反例に対して、検査が pass ではなく理由付き fail を返し、失敗を修正した版では同じ検査が pass になることを保存する。手で表示を確認しただけの結果は再現できないため、入力ファイルのハッシュと検査版も添える。この段階で「方策が賢い」とは評価しない。安全な研究の前提が、機械的に壊れた時に見えることだけを確認する。

safety gate：simulatorのpassと通電許可を分ける

simulatorでpassしても、指定したobservation-action traceがsimulatorの仮定を破らなかったことしか示さない。hardwareの前に、ownerと観測可能なstop conditionを持つgateを書く。stale camera frame、joint state欠落、上限envelopeを超えるaction、予期しないcontact、watchdog喪失、人のwork envelope侵入である。安全側のactionはhold、zero velocity、power-disableのどれかを明示し、学習policyなしで独立に検査できなければならない。

これはoffline設計演習である。緑のchecklistはmotor接続の許可ではなく、acceptance rateが高くてもemergency-stop不在をsoftware問題へ縮めてはならない。

最近のsafety announcementはsafety caseではない

2026年9月21日のNVIDIA safety overviewはhardware、software、simulation、validationをまたぐlifecycle safetyを論じる。これはarchitecture claimであり、特定labの安全性の証拠ではない。artifactへ変換する。各stop conditionをsensor、独立monitor、commanded safe state、owner、test recordへ対応づける。一つでも欠ければoffline exerciseはofflineのままである。