歩いていって棚の上のカップをつかむ場面を思い浮かべてほしい。その数秒の間、目の前の映像は二つのことが同時に変わる。足を運べば視界全体が流れ、手を伸ばせば画面の片隅にある手の形が変わる。人間にとっては一つにまとまって起きる動作だが、機械にとっては性質がまるで違う二つの変化だ。
Ropedia W0 は、この二つの変化を一度に予測するモデルだ。最初の場面を一枚と「こう動け」という指示を与えると、その動きのあとに目の前がどう見えるかを一人称映像で描き出す。こうして行動の結果を映像で前もって描いてみせるモデルを世界モデル(world model)と呼ぶ。
これまで世界モデルは、たいていおとなしい側だけを扱ってきた。テーブルの前に固定された腕がグリッパーで物をつかむ状況だ。歩きながら視点が揺れ、複数の指で物を繊細に扱う、移動と操作が重なった長い状況は避けて通ってきた。Ropedia W0 が打ち出す差別化点はここにある。人間の手、2指グリッパー、多関節のヒューマノイドの手まで — 見た目の異なる複数の体を一つのモデルでまとめて扱いながら、歩行と操作を一緒に予測したのは、著者らの知る限り初めてだという。
Ropedia W0 は「次に何をするか」を自分で決めるモデルではない。入力は三つだ。いま見えている場面を一枚、やろうとしていることを書いた短い文、そして「こう動く」という動きの情報。出力は、その動きを実際に行ったときに見えるであろう未来の映像だ。
ロボットを直接操るモデルは別にある。ふつう方策(policy)と呼ばれ、いまの場面を見て「ならば腕をこちらへ」と次の行動を決める。世界モデルはその一つ手前の段階だ。方策が「どう動くか」を選ぶと、世界モデルは「ならば何が見えるか」を予測する。カップをつかもうとする方策が「手をもう少し前に伸ばす」という候補の動作を思い浮かべると、世界モデルはその動作のあとの目の前の絵を前もって描いてみせる、という具合だ。
難しいのは「こう動く」をモデルにどう書き込むかだ。
人間の手は関節が多く、2指グリッパーは開いて閉じるのがすべてで、多関節のロボットハンドはまた別の構造をしている。体が違えば、同じ「握る」でも数字での書き方がすべて違ってくる。だから体が一つ増えるたびに、その体の動きをモデルに入れてやるための通路を新しく敷かなければならなかった。
これまでの研究もこの壁を越えてきたが、共通して、新しい体が登場するたびにその体専用の仕組みや追加の適応が必要だった。Ropedia W0 は、この体ごとの通路そのものをなくそうとする。どんな体でも同じ一枚の絵に変換して書き込むのだ。
動きを二手に分けて絵で書き込む。
歩行が生み出す視点の変化は、カメラポーズ(カメラの位置と向きをまとめて呼ぶ言葉)で書く。カメラがどこへどれだけ移動してどちらを向くかが、次の瞬間に画面がどう流れるかを教えてくれる。このとき移動量をメートル単位で書くのがコツだ。人間が歩こうとロボットが動こうと「1メートルは1メートル」という距離の感覚が揺らがない。
手の操作は、画像の上に重ねて描いた骨格(スケルトン)で書く。手の関節がいまどこにあるかを絵で乗せてやるのだ。人間の手の関節だろうとロボットの指だろうとグリッパーの開きだろうと、それぞれの体に固有の連結構造をそのまま生かして描く。
結果として、見た目の異なるすべての体が「カメラポーズ一枚 + 骨格図一枚」という同じ書式に翻訳される。入力形式が同じなので、高価なロボット映像と安価な人間映像を一つのモデルに一緒に食わせることができる。
同じ書式が実際に何を再利用させてくれるのかは、学習の過程で明らかになる。モデルはまず、人間の一人称映像だけで「カメラと手がこう動けば場面がこう変わる」という共通の関係を身につける(事前学習)。次に人間データとロボットデータを同じ確率で混ぜ、ロボット固有の外見と関節構造をまとわせる(中間学習)。二つの段階が同じカメラ-骨格の書式を使うため、人間映像で身につけた「動き → 結果」の感覚をロボット予測にそのまま再利用できる。体ごとに異なる幾何構造は絵の中にそのまま残る。
三つの既存アプローチと Ropedia W0 を、「動きを表現する方式」と「新しい体に適用するときに必要な作業」で並べて置くとこうなる。
| アプローチ | 動きを表現する方式 | 新しい体に適用するときに必要な作業 |
|---|---|---|
| DreamDojo | 潜在行動 — 映像から推定した抽象的な動きの信号(latent action) | ロボットに使うとき、その信号をロボット専用の行動に差し替える |
| Cosmos3 | 共通の胴体は共有しつつ、動きはドメインごとに投影 | ドメインごとに専用の投影経路を新しく敷く |
| AnyWorld | 元の人間の骨格を条件として再利用 | 対象ロボットの運動学(関節の連結構造)は使わない |
| Ropedia W0 | カメラポーズ + 画像上の骨格図 | 同じ書式に新しい体の幾何だけを描き込む |
※ 検証範囲:AnyWorld は移動と操作が重なった状況では検証されていない。
著者らは五つのベンチマーク全般で最高性能(SOTA, state-of-the-art)だと述べ、ベンチマークごとの定量結果を表3〜5で公開している。たとえば DreamDojo の1%学習条件における In-lab PSNR(値が大きいほど予測映像が元に近い)は、W0 A14B モデルが 23.028dB で、DreamDojo 14B の 18.983dB を上回る。以下では、報告された成果の方向性を併せて伝える。
人間映像を増やしたときにロボット予測も一緒に改善したというのが核心的な結果だ。人間の事前学習映像を増やすと、人間映像の予測がよくなるだけでなく、ロボットへの転移性能まで上がった(人間データの規模に応じた転移性能は図6〜8に示されている)。安価でありふれた人間の一人称映像が、高価で貴重なロボットデータの予測を押し上げる — これが論文の核心的な主張だ。
活用の可能性も三つの筋で示された。(1) 方策を映像で前もって採点してみる方策評価(policy evaluation)、(2) 複数の行動の結果を描いてみて選ぶモデルベース計画(model-based planning)、(3) 世界-行動モデリング(world-action modeling)だ。特に最後では、行動専用の部品を新しく付け足す代わりに、映像予測で学習しておいたバックボーン(モデルの共通の胴体)をそのまま行動学習の出発点として使った。映像を描きながら積み上げた表現が、行動を学ぶ土台としても使えるという見方だ。
生成速度は実用の側に踏み込んだ。大きなモデルを小さく速いモデルに移す蒸留(distillation)を経て、生徒モデルが毎秒 21.3 フレームで分単位の相互作用を回す。オフラインで一度回してみる予測器ではなく、人間が途中で割り込む対話型シミュレータや VR のリアルタイム相互作用まで担える速度だ。
この研究の隠れた重心は、モデルではなくデータにある。材料は多い。人間側の公開・自前撮影分とロボット側の公開データを合わせ、人間1万時間、ロボット3千時間を集めた(データセット名 Xp-Data)。問題は、これらの材料の規格がてんでバラバラだという点だ。公開されている人間の一人称映像は多いが、メートル単位のカメラ軌跡がなく、手のポーズが汚く、形式がすべて違う。多いが、そのままでは使えない。
いちばん手を焼いたのは、手の骨格を画像に正確に乗せる作業だ。ロボットは関節の角度から指先の位置を計算する順運動学(forward kinematics)で骨格を取り出せる。ところが公開ロボット映像では、この計算結果が実際の手やグリッパーとしばしばずれ、カメラのキャリブレーション値がない場合も多い。そこで人間が直接、画像の上にキーポイント(関節のような主要な点)を打ち、ずれた投影を手で直した。順運動学はあくまで下描きの推定値にすぎず、学習に実際に使う骨格は手作業で合わせたものだ。
著者らが新たに作った評価用データ(Xp-Teleop)には、失敗したグリップとそれを立て直す過程をわざと残しておいた。世界モデルが成功場面だけを真似るのか、それとも外れた結果まで描き出せるのかを併せて見ようというのだ。成功場面だけを収めたデータでは、「うまくいかなかったときに画面がどうなるか」を十分に学習したり評価したりするのは難しい。
データパイプラインとモデルの装備・ツール・数値の仕様は長いので畳んでおく。
Xp-Data は人間側の公開データセット14個 + 自前収集6,000時間(魚眼カメラ4台のリグ) + ロボット側の公開データセット13個で構成される。生の映像は 収集 → 映像フィルタリング(ビジョン言語モデルがひどいブラー・露出問題・過度な揺れ、そしてカメラも手も動いていない区間を除去) → マルチモーダル注釈 → 品質検査 → 学習クリップ構成 の五段階を経て、通過したサブタスクは81フレーム・16fpsのクリップに標準化される。
注釈ツール:カメラ軌跡はキャリブレーション値があればそのまま、なければ自前の SLAM・DA3 でメートル単位推定し、Grounding DINO で手・人などの動的領域を見つけて軌跡の一貫性検査から除外する。手の整列は人間の場合 WiLoR で復元した MANO キーポイント投影、ロボットは URDF ベースの順運動学 + 手作業補正。行動説明はタスク・サブタスク・原子行動の3層キャプションだ。誤り検証はキャプションの場合 Gemini 生成 → Qwen 検証 → 人間解消、手は MediaPipe とファインチューニングした MMPose の2D検出を交差比較、ロボットキーポイントは自前のファインチューニング検出器二つで交差確認する。
Xp-Teleop:Unitree G1 ヒューマノイドに6自由度の多関節ハンドを二つ付け、既製ハードウェアと Unitree オープンソースフレームワークで組み立てた全身遠隔操作リグで収集した新ベンチマーク。27本の長いテイク(一人称30fps、約1時間)、操作者二人が歩行と手の操作を同時に遂行。RGB-D・カメラポーズ・投影骨格・ロボット状態・言語・触覚・頭部IMUが同期しており、人間が注釈した543個の原子区間(30個のスキルクラス、テイクあたり中央値18区間)に分割される。Table 1 基準でテイクあたり平均118.6秒、歩行範囲1.48m、平均3.6個のサブタスク。評価は五つの交差体ベンチマーク(DreamDojo, Ψ_0, ω-HOME, Xp-Teleop, AgiBot)と、別に取り分けた人間の一人称映像でゼロショット・少数サンプル・全体の後続学習として行われ、比較対象は DreamDojo・Cosmos3・OSCAR・RynnWorld-Teleop などで、付録には WorldArena での BWM との比較もある。
モデル・学習:本体は潜在映像拡散トランスフォーマー(latent video diffusion transformer)。カメラ条件はピクセルごとに6チャンネルのプリュッカー光線マップ(Plücker-ray map)でエンコードし、ピクセルに整列する条件(カメラ・骨格)は映像トークンに加えて融合、広い画角の骨格のようにピクセル対応がない情報はクロスアテンションで注入する。カメラ・骨格の投影入力は0で初期化し、学習初期に事前学習済みバックボーンを乱さないようにした。規模は密な5Bモデルと Wan2.2-I2V-A14B ベースの MoE(総計約27B、アクティブ14B)。学習は人間一人称映像の事前学習 → 人間とロボットを同じ確率で混ぜる中間学習(mid-training)の二段階で進み、両段階とも同じカメラ-骨格の書式を使う。その後 Causal Forcing でブロック単位4ステップの生成器を作り、LongLive で長時間ストリーミング向けに引き伸ばしてから蒸留する。
統一表現が人間からロボットへ実際に移してくれるのは「手と関節が空間のどこへ行くか」だ。一方、骨格入力には接触がどれだけ硬いか、握る力がどれだけ強いかが直接は示されない。形式が同じになったからといって、人間の腕とロボットの腕の運動能力の差まで消えるわけでもない。力と接触が抜け落ちた表現が「どんな作業まで」計画と制御を支えられるのかは、先に見た方策評価・モデルベース計画の具体的な数値でさらに吟味すべき問いとして残る。
統一表現の代償は人間の手で支払われた。公開ロボット映像の順運動学投影がしばしばずれ、相当な手作業のキーポイント注釈と補正が必要だったということは、裏を返せば、この書式は人間が支えてやらなければ揺らぐという意味だ。規格を揃えるコストが、モデル構造ではなく人間に回された。新しいロボットをもう一つ付け足すときにこのコストがどれだけかかるかは、いまの資料だけでは見積もりにくい。
物理的な正確さは別に見る必要がある。映像をそれらしく描くことと、その映像が物理的に正しいことは別の問題だ。関連研究でも、視覚品質・物理一貫性・実際の制御での有用性をそれぞれ測るベンチマークが別々にある。見た目それらしい予測が、ロボット制御でどれだけ信頼できるかは、方策評価・計画側の具体的な数値でさらに吟味すべきだ。
評価セットの規模も過信は禁物だ。Xp-Teleop の27本のテイク、約1時間は、学習用ではなく評価用に取り分けた集合だ。長い呼吸の移動-操作を測る良い物差しであることは確かだが、評価セット一つの多様性が将来の汎化すべてを代弁するわけではない。
ここから先は検証された結論ではなく仮説だ。
ONTLE は、プロジェクトごとに使うツールもスタックもチームも異なる現場に入り込み、散らばった作業情報を一つに集めて、いま盤面がどう回っているかを読み取ってくれる。この論文から借りる発想は一つだ。現場ごとの生データはてんでバラバラのままにしておき、推論に使う上位の表現だけを一つに統一する。核心は「連携が楽になる」ことではなく、異なるツールの情報を同じ基準で解釈できるようになるという点にある。
一つの場面に絞って見よう。顧客が納期を前倒ししてほしいと言う。この要請が日程にどんな波紋を起こすかを読むには、イシュートラッカーのチケット、リポジトリのコミット、カレンダーのマイルストーンを一目で見る必要がある。ところがこの三つは見た目がすべて違う。Ropedia が体は違っても「カメラポーズ + 骨格」に翻訳したように、この三つを「作業状態(待機・進行・完了)」と「作業同士の依存関係」という共通の書式に移しておく。
ただし、状態と依存関係だけでは「いつ遅れるか」までは出てこない。各作業に残った作業量、担当者の余力といった情報を同じ書式に一緒に揃えて入れてはじめて、「この作業を前倒しすると、後に続く作業がどこで遅れるか」を一つの盤の上で描いてみることができる。そしてこの「揃えて入れる」作業はタダではない。論文でも、統一表現は勝手に揃うわけではなく、人間が骨格を手で補正しなければならなかった。イシュー一つをどの作業状態と見なすか、コミットをどの作業に紐づけるか — その整列の品質が、そのまま予測品質の天井になる。
最後に、Ropedia がそのまま保証してくれるわけではない問いが一つ残る。人間映像がロボットへの転移を押し上げたように、積み上がった過去のプロジェクト履歴が、データの乏しい新規プロジェクトの遅延予測を実際に支えてくれるのか、だ。これは ONTLE のデータで別途確かめなければならない — 過去プロジェクトで学習した予測が、履歴のない新規プロジェクトで人間が手で見積もったものより優れているかを測ってみればいい。
見た目と関節構造が互いに異なる体 — 人間の手、2指グリッパー、多関節のヒューマノイドの手 — を行き来しながら一つのモデルで扱うという意味です。この研究が評価に使ったベンチマーク五つがすべて「交差体」ベンチマークなのも、体を変えながら同じモデルが予測できるかを測るためです。