Physical AIワークショップ：データ分割から方策評価、Sim2Real判断までを一周する

このワークショップの成果

目的は、ロボットを動かして派手な動画を作ることではない。公開または合成の episode を、再実行可能な split、base policy の比較、軽量適応の仮説、失敗分類、Sim2Real の判断票へ変えることである。ここではハードウェアを接続せず、モデル訓練も実行していない。コマンドや重みのバージョンは変化し得るため、実行時には LeRobot と利用する方策の現行公式資料を確認する。

1. 1タスク契約
2. 2episode inventory
3. 3group split と漏洩検査

1. 1base policy の固定評価
2. 2適応仮説（LoRA等）
3. 3同一条件で再評価

1. 1失敗動画と telemetry
2. 2原因カテゴリ
3. 3Sim2Real準備判定

1. 1判定が否
2. 2データ・評価・安全境界を修正
3. 3再評価

0. タスク契約を先に固定する

対象を「赤い立方体を容器に入れる」と仮定する。開始状態は立方体・容器・腕の初期姿勢、観測は前方カメラと手首カメラ、状態は関節角とグリッパ、action は手先増分とグリッパ命令、と一枚に書く。成功は「立方体が容器内で静止し、グリッパが離れ、上限時間内」、失敗は「対象落下、領域外、衝突、タイムアウト、停止」とする。action.delta_xyz が m/step なのか m/s なのか、座標が base/tool のどちらかも契約に含める。

この文書が無いと、モデルが改善したかを測れない。成功率は、開始位置を狭めるだけで上がる。安全性は、失敗をログから除くだけで良く見える。タスク契約は実験の説明書であると同時に、比較の改ざんを防ぐ境界である。

1. dataset inventory と切り分け

episode ごとに episode_id, session_id, operator_id, object_set, camera_setup, task_text, start_pose_id, raw_video_hash, started_at, length, outcome を収集表にする。frame をランダムに分けず、原則として session_id または episode_id を group として train/validation/test に割る。同じセッションでは照明、背景、物体、操作癖が似るため、別 split に入ると見かけの一般化が起きる。

機械的な検査は少なくとも四つ置く。第一に episode ID の集合積が空か。第二に raw video hash の集合積が空か。第三に test 用に隔離した object_set または start_pose が train に偶然戻っていないか。第四に正規化の平均・分散、画像 augmentation の乱数、tokenizer の vocabulary を train だけから作っているか。最後の項目は見落としやすい。test 全体の統計で標準化すれば、重みを見なくても評価分布を事前に見たことになる。

2. base policy を固定する

base policy は「適応前の比較対象」であり、失敗したら消すものではない。公開済み方策や単純な behavior cloning を一つ選び、checkpoint ID、コード commit、データ snapshot、入力変換、control frequency、seed を記録する。SmolVLAのような公開研究を使う場合も、論文の報告値を自分の結果として使わない。自分の task contract で一試行ずつ測る。

各試行で trial_id, policy_version, dataset_version, split, object_id, start_pose_id, seed, completed, time_s, stop_reason, intervention, video_id を残す。評価者は方策名を見ずに成功と失敗を付けられると望ましい。ベースラインが低い原因は、モデル容量ではなく camera crop、action 単位、時刻ずれ、開始状態の差かもしれない。この段階では改善を急がず、上位三つの失敗カテゴリを数える。

3. 軽量適応を仮説として扱う

LoRA のような parameter-efficient fine-tuning は、巨大な重み全体を更新せず、一部の低ランク更新を学習する方法である。VLA に LoRA が常に適用可能、または小データで安全に改善するとは限らない。利用する checkpoint と実装が公式に対応していること、ライセンスが用途を許すこと、適応対象の層と action head の扱いを確認してから初めて候補になる。

実験では「照明変化への適応」など一つの仮説だけを立てる。base と LoRA 適応版の差を、同じ train group、同じ validation、同じ augmentation、同じ試行予算で比べる。rank、学習率、step 数を validation で選び、locked test は最後に一回だけ使う。改善が出ても、train に近い背景だけで上がったなら一般化ではない。悪化、停止増加、action の振動も成功率と同じ重さで報告する。

4. 失敗を構造化する

失敗を perception（対象を誤認）、localization（位置・座標誤差）、grasp（把持失敗）、planning（順序誤り）、control（振動・遅延）、recovery（失敗後に復帰不能）、safety_stop（安全監視が止めた）、unknown に分ける。一試行に複数原因があり得るため、主原因と副原因を分け、根拠の video timestamp と telemetry を添える。unknown を無理に既知カテゴリへ入れないことが、次の観測を増やす理由になる。

混同行列も作る。人の注釈者二人が同じ動画を別々に分類し、食い違いを調停する。注釈者が結果のモデル名を知ると、期待に沿った原因を選びやすい。カテゴリ定義、注釈手順、調停理由を保存すれば、後から「モデルが悪い」という印象をデータに戻して検証できる。

5. Sim2Real はゲートで判断する

シミュレーションで成功しても、実機で成功する根拠にはならない。摩擦、把持、柔軟物、照明、カメラ遅延、エンコーダ誤差、通信断は簡単な simulator が再現しにくい。だから実機へ進む判定を二値の「十分賢いか」ではなく、複数のゲートにする。task contract、action 単位、座標変換、停止状態、データのライセンス、漏洩検査、失敗分類、再現できる評価ログが揃っているかを確認する。どれかが欠ければ not ready とし、実機試験を始めない。

実機を扱う組織ではさらに、非常停止、速度・力制限、立入制限、監督者、通信断時の停止、試行後の機体点検を別の安全計画で承認する必要がある。本章はその承認を与えない。ここでできるのは、公開・合成データで差分の仮説と観測設計を明確にし、実機で初めて知ることを小さくすることまでである。

提出チェックリスト

最後に、split manifest、漏洩検査の結果、base と適応版の同一フォーマットの評価表、失敗カテゴリの集計、未確認事項、Sim2Real 判定票を一つのフォルダに置く。結果が良くても not ready になる理由を最低一つ書く。例えば「camera calibration の独立検証が無い」「test が一収集日だけ」「停止時のログが無い」でよい。この正直な空欄が、次のデータ収集と安全な実機計画を具体化する。

readiness判断にはcounterfactual logが要る

拒否したrolloutごとに、失敗前のobservation window、提案action、safety filterの判断、継続に必要だったresetを残す。これで「policyが悪い選択をした」のか「cameraがstaleだった」のか「limitが危険actionを止めた」のかをreviewerが分けられる。task successと並べてintervention rateとtime-to-safe-stateを報告する。そうしないと高いsuccess scoreがnear missの反復を隠す。

stop path、watchdog、action envelope、recovery ownerを独立に試験するまで、この演習はofflineのままである。Sim2Real readinessはbenchmarkが出す閾値ではなく、判断記録である。

packetにsafety-case列を足す

2026年9月21日のNVIDIA safety overviewは有用な分離を支える。policy scoreはdeployment safety caseではない。test conditionごとにmonitor coverage、stop latency、safe-state evidence、未解決hazardの列を足す。monitor coverageが欠けるpass scoreは、task videoが安定して見えても「not ready」のままである。