【DL輪読会】Building a Multiplayer Video World Model in Minecraft
>100 Views
March 19, 26
スライド概要
DL輪読会資料
関連スライド
各ページのテキスト
DEEP LEARNING JP “Solaris:” [DL Papers] Building a Multiplayer Video World Model in Minecraft Shusaku SONE http://deeplearning.jp/ 1
アジェンダ 1. 書誌情報 2. 背景 3. 目的 4. 提案手法 5. 実験方法 6. 実験結果 7. 考察 8. 議論と限界 9. 制限と貢献 10.感想 2
１ 書誌情報 タイトル： Solaris: Building a Multiplayer Video World Model in Minecraft 著者： Georgy Savva, Oscar Michel, Daohan Lu, Suppakit Waiwitlikhit, Timothy Meehan, Dhairya Mishra, Srivats Poddar, Jack Lu, Saining Xie New York University 出版日: 2026年2月25日 出版物: arXiv 選んだ理由：複数視点を同時かつ整合的に生成する世界モデルに 興味があったため （single-view video world modelからmulti-view consistent world modelへ） 3
2 背景 (World Model研究の流れ) World Model（世界モデル）とは? 「観測」と「行動」から 未来の状態を予測するモデル ・入力 現在の状態, 行動 ・出力 次の状態 Video World Model とは? 画像・動画生成モデル（Diffusion / Transformer）を用いて 動画そのものを未来として生成するモデル ・入力: 過去の観測（動画）＋行動列 ・出力: 未来の観測動画の確率分布を生成 → 生成された動画を「未来のシミュレーション」とみなして、計画・学習・評価に使う。 4
2 背景 (Video World Modelの問題) 背景：既存 Video World Model の問題 ・既存研究の多くは単一エージェント前提 多くの Video World Model は，1人の視点の動画とその行動を入力として， その視点の将来動画を生成する設計． ・入力：1人分の観測動画 + 行動 ・出力：1人分の将来動画 この設定では，複数プレイヤーが同じ世界を共有する状況を十分に扱えない． 問題：複数視点の整合が保てない 2人のプレイヤー A, B が同じ世界にいるなら，Aの行動は Bの視点にも同時に反映される必要がある． しかし，単一視点モデルをそのまま2本並べるだけでは，A視点とB視点が別々の世界を生成してしまう 例えば， ・A がブロックを置いたのに，B の画面には現れない ・互いの位置関係がずれる ・雨や Mob など同じ出来事が片方にしか起きない といった破綻が起こりうる． 5
2 背景 (本研究の焦点) 本研究では，この問題を 「複数視点が，同じ世界を共有しているように整合しているか」 という観点から正面から扱う． つまり，重要なのは単に「それっぽい動画」を生成することではなく， 「視点間で矛盾しない，同一世界の生成」 である． 6
2 背景 (なぜMinecraftを使うのか？) Minecraft は，複数視点の整合性の難しさが自然に現れるテストベッド 1. 遮蔽 相手が壁の裏や視野外に消えても，世界としては連続しているため，再び見えたと きに正しい位置や状況が保たれている必要がある． 2. 環境改変 採掘や建築によって地形そのものが変わるため，A が置いた・壊したブロックが，B の画面にも同じ世界の変化として反映されなければならない． 3. 確率的イベント 天候や Mob などの出来事も，複数視点で同時に整合して起きる必要がある． 7
3 本研究の目的 複数プレイヤーの視点を同時に生成できる Video World Model を構築する 同じ世界を共有する複数エージェントの観測を整合的に生成する マルチプレイヤー動画データを大規模に収集する基盤を構築する Minecraft 上で協調プレイを自動実行する SolarisEngine を開発 複数視点の整合性を評価するベンチマークを提案する Movement / Grounding / Memory / Building / Consistency の5タスク 長時間生成を安定させる学習方法を提案する Checkpointed Self Forcing を導入 マルチプレイヤー世界モデルの研究基盤を公開する モデル・データ・コードを公開 8
4 提案手法（全体像） 本研究では， マルチプレイヤー Video World Model「Solaris」 を提案する。 提案手法は次の 3つの要素から構成される。 ・データ収集基盤：SolarisEngine ・マルチ視点 Video World Model：Solaris ・段階的学習パイプライン これらにより 複数視点で整合した世界生成を実現する。
4 提案手法（SolarisEngine（データ収集基盤）） マルチプレイヤー world model を学習するためのマルチ視点動画データ収集システム ・マルチプレイ協調を Mineflayer ベースで自動化（通信レイヤ／高レベルプリミティブ） ・controller（行動）× camera（視覚）× server を同期し、Dockerで大規模並列収集 ・「2人の行動」と「2人の見ている映像」を、同じタイムライン上でズレなく大量に集めることができる。 ・片方の行動がもう片方の視点に反映されるような、マルチ視点整合の学習に必要なデータを安定して作れる。 （注）Mineflayer: Minecraft を外部プログラムから操作するための JavaScript 製ボットフレームワーク。 キーボード操作の代わりに API で「移動・採掘・設置・視点変更」などを実行でき、複数ボットの 協調プレイやログ収集の自動化に使える。
4 提案手法（SolarisEngine（収集したデータ規模と例）） 12.64M フレーム（2視点同期） エピソード類型と行動空間を整備（MineRL 互換） （注）MineRL: Minecraft を対象にした強化学習/模倣学習のためのベンチマーク・環境群（行動空間や観測の表 現が標準化されている）。 「MineRL 互換」とは、前進/ジャンプ/採掘/設置/ホットバー等の操作を、既存コミュニティで広く使われる形式 で記録・入力できる、という意味。
4 提案手法（SolarisEngine（収集したデータ規模と例））
4 提案手法（Solarisモデル概要①） ・Minecraft マルチプレイ環境の動画生成を目的として、 Solaris と呼ばれる マルチプレイヤー Video World Model を提案。 ・Solaris は既存の Matrix-Game 2.0 の Diffusion Transformer（DiT） をベースとし、 それを マルチプレイ環境に適応するために拡張したモデルである。 ・Matrix-Game 2.0 は単一プレイヤーの動画生成モデルであり、行動条件付き拡散モデルとして動画フレーム 列を生成できる。 しかし Minecraft のマルチプレイ環境では、 ・同一世界を共有する 複数プレイヤー視点 ・プレイヤー間の 相互作用 ・Minecraft 特有の 高次元行動空間 を扱う必要がある。 そのため Solaris では、Matrix-Game 2.0 を基盤として次の三つの拡張を行う。 (1) マルチプレイヤー joint 状態の導入 (2) Expanded Action Space (3) Multiplayer Self-Attention
4 提案手法（Solarisモデル概要②） Solaris： Matrix-Game 2.0 を基盤とした次の三つの拡張。 (1) マルチプレイヤー joint 状態の導入 従来の video world model は単一視点の観測を 𝑥𝑆𝑃 ∈ ℝ𝐻×𝑊×𝐶 として扱う。 これに対し Solaris では、同一時刻における複数プレイヤーの観測をまとめて 𝐱 𝑡 = 𝑥1𝑡 𝑥2𝑡 … 𝑥𝑃𝑡 と定義し、 プレイヤー次元 𝑃を持つ joint 状態 としてモデル化する。 𝐵 𝑃𝑇𝐻 𝑊 𝐶 全員は 同じマイクラ世界 にいるので、世界の物理的な状 態は1つだが、見え方は人ごとに違う。モデルは「次の瞬 間、世界が全員にどう見えるか」を まとめて予測したい ので、複数視点を1パッケージにした状態（joint 状態)と してモデル化する これにより ・プレイヤーAには見えていない情報が ・プレイヤーBには見えている といった 複数視点の整合した世界状態 を扱えるようになる。
4 提案手法（Solarisモデル概要③） Solaris： Matrix-Game 2.0 を基盤とした次の三つの拡張。 (2) Expanded Action Space（行動空間の拡張） 「行動 を表すベクトルが“足りない”ので、もっと多くの操作を入れられるように入口を広げる」 という改変 Matrix-Game 2.0 の行動空間は ・camera ・WASD などの比較的単純な操作のみを想定している。 しかし Minecraft 環境では ・mine（採掘） ・place_block（設置） ・attack（攻撃） ・hotbar selection（アイテム切替） など、より複雑な操作が存在する。 そのため Solaris では MineRL-style 行動空間 を入力として扱えるように ・action module の入力次元を拡張 ・行動埋め込み層を再初期化 することで 高次元行動ベクトル 𝑎𝑝𝑡 ∈ ℝ𝐷 を扱えるようにしている。
4 提案手法（Solarisモデル概要④） (2) Expanded Action Space（行動空間の拡張） 状況：プレイヤーが 前進しながら、視点を 少し右・少し下 に動かし、ツルハシ（ホットバー3番） を持って 採掘を開始する（攻撃・設置・use はしない）。 拡張前（狭い行動の例：WASD + camera のみ） 拡張前は、そもそも mine(採掘) や hotbar(持ち替え) のスロットが無いので、同じ状況でも 書けるのは移動と 視点だけになります。 a_old = [forward=1, back=0, left=0, right=0, yaw=+0.05, pitch=-0.02] 拡張後（ 広い行動の例： キーを 全部入れる ） Solaris のデータ 仕様に合わせると 、 1ティックの 行動は 25スカラー 相当（ 7移動 + 2camera +6once + 1mine + 9hotbar） で書ける 。 ブロック 移動7 camera2 once×6 mine hotbar×9 成分 forward, back, left, right, jump, sprint, sneak yaw, pitch attack, use, mount, dismount, place_block, place_entity mine hotbar.1 … hotbar.9 a_new =[1,0,0,0,0,0,0, 0.05,-0.02, 0,0,0,0,0,0, 1, 0,0,1,0,0,0,0,0,0] ↑__移動7__↑ ↑cam2↑ ↑once×6↑ ↑m↑ ↑___hotbar×9____↑ 値（例） 1,0,0,0,0,0,0 +0.05, -0.02 0,0,0,0,0,0 1 0,0,1,0,0,0,0,0,0
4 提案手法（Solarisモデル概要⑤） Solaris： Matrix-Game 2.0 を基盤とした次の三つの拡張。 (3) Multiplayer Self-Attention Solaris では、プレイヤー間の情報交換を行うためにMultiplayer Self-Attention を導入する。 具体的には ・各プレイヤーの video tokens を 1本の系列に interleave player1: [p1_1, p1_2, ..., p1_M] ・共有 Self-Attention を適用 することで、視点間の情報交換を可能にする。 player2: [p2_1, p2_2, ..., p2_M] しかし単純に混合すると ・「どのプレイヤーの視点か」 interleave（ インタリーブ ： 交互に並べる ） ・「空間位置」 [p1_1, p2_1, p1_2, p2_2, ..., p1_M, p2_M] が失われるため、次の二つの仕組みを導入する。 ・Player ID embedding 各トークンに Player ID 埋め込みを付与し、どのプレイヤーの視点かを保持する。 ・per-player 3D RoPE 各プレイヤーごとにper-player 3D RoPE を用いることで ・プレイヤー内部の空間構造 ・視点の幾何整合 が崩れないようにする。 これにより Solaris は 視点間相互作用を許しつつ視点整合を同時に実現する最小改変 となっている。
4 提案手法（ Solarisモデル 学習時） 学習時には， データセットから 複数フレームの動画クリップと対 応する行動列を取り出し， それを潜在空間へ変換したうえで，Conditional Flow Matching により DiT を学習する。 学習時の流れ 1. 動画クリップと行動列を入力 2. VAE encoder で画像を潜在表現へ圧縮 3. 潜在を トークン化 4. 行動列を action module で埋め込み 5. 先頭フレームから first-frame tokens を作成 6. ノイズを加えた潜在を DiT に入力 7. Multiplayer Self-Attention とCross-Attention を通して予測 8. Flow Matching Loss で学習
4 提案手法（ Solarisモデル 学習時） Solarisでは 動画潜在空間で拡散モデルを学習する。 学習入力 動画クリップ 𝐼𝑝1:𝑇 行動列 𝑎𝑝1:𝑇 テンソル形状 𝐵 𝑃 𝑇 𝐻𝑖𝑚𝑔 𝑊𝑖𝑚𝑔 3 潜在空間への変換 まず動画フレームを VAE encoder に入力する。 𝐼𝑝1:𝑇 → 𝑥𝑝1:𝑇 潜在テンソル 𝑥∈ 𝐵 𝑃𝑇𝐻𝑊 𝐶 この潜在を パッチ化して visual tokens を作る。 記号 意味 B batch P player T time
4 提案手法（ Solarisモデル 学習時） First-Frame Conditioning Solarisでは 最初のフレームを条件として固定する。 まず 𝑥𝑝1 を取り出す。 これをトークン化して first-frame tokens を作る。 xₚ¹ ↓ patch tokenize ↓ first-frame tokens このトークンは Cross-Attentionで使用される。
4 提案手法（ Solarisモデル 学習時） ノイズ混合（Diffusion の開始） 潜在動画 𝑥にノイズを加える。 𝑥𝜎 = 1 − 𝜎 𝑥 + 𝜎𝜖 ここで 記号 意味 x 元の潜在動画 ϵ Gaussian noise σ ノイズレベル この計算はDiTに入力する前に行われる。 つまり latent video ↓ noise mixing ↓ DiT となる。 混ぜ具合 σ（シグマ：0〜1）に対し、 𝑥𝜎 = 1 − 𝜎 𝑥 + 𝜎𝜖 を データ𝑥と ノイズ𝜖で 線形補間 する。 σ=0 で完全に𝑥（教師データ）、σ=1 で完全に𝜖（ノイズ）。 その途中の 𝑥𝜎 に対して、 が 「この地点で、σ を少し進めたときの変化の向き・大きさ」 を予測する。
4 提案手法（ Solarisモデル 学習時） DiT（Diffusion Transformer） DiTの入力 入力 意味 ノイズ付き潜在動画 ノイズレベル 行動 first-frame tokens Transformer内部では Multiplayer Self-Attention player tokens ↓ shared self-attention プレイヤー間の情報交換を行う。 Cross-Attention video tokens ↓ first-frame tokens 最初の世界状態を固定する。
4 提案手法（ Solarisモデル 学習時） Multiplayer Self-Attention の役割 プレイヤーごとの視点トークンを 共有 Self-Attention で結合する。 𝑧 = 𝐴𝑡𝑡𝑛 𝑄𝑝𝑙𝑎𝑦𝑒𝑟𝑠 𝐾𝑝𝑙𝑎𝑦𝑒𝑟𝑠 𝑉𝑝𝑙𝑎𝑦𝑒𝑟𝑠 player1 tokens player2 tokens player3 tokens │ │ Self Attention ▼ 共有された世界状態 なぜ必要なのか？ もしこれが無いと player1: ボールあり player2: ボールなし のように 世界が矛盾する。 Multiplayer Self-Attention により player1 player2 player3 ↓ 同一世界モデルが学習される。
4 提案手法（ Solarisモデル 学習時） Cross-Attention の役割 Cross-Attention は video tokens → first-frame tokens を参照する。 つまり となる。 𝑧𝑡 = 𝐴𝑡𝑡𝑛 𝑄𝑣𝑖𝑑𝑒𝑜 𝐾𝑓𝑖𝑟𝑠𝑡 𝑉𝑓𝑖𝑟𝑠𝑡 これにより 生成されたフレームが最初の世界状態と整合する。 Query（video tokens）は Key（first-frame tokens）の「空間位置の特徴」 を参照している。 「今生成しようとしているフレームのパッチ」が 「最初のフレームのどのパッチに似ているか」 生成フレーム (Query) tokenA tokenB tokenC │ 参照 ▼ first frame (Key / Value) token1 壁 token2 プレイヤー token3 ボール token4 床 これにより 生成フレームが初期状態と矛盾しない ようになる。 つまり 最初の世界 → それを維持した未来 を生成できる。
4 提案手法（ Solarisモデル 学習時） 速度場の予測 DiTは 速度場 𝑣𝜃 を出力する。 Conditional Flow Matching Loss モデルは 𝜖−𝑥 を予測するように学習される。 これは ノイズ状態 → 元動画 に戻る方向のベクトルである。 損失関数 今のノイズ状態から どの方向に動けば 元の動画に近づくかを学習する 意味 予測した速度 − 真の速度 の誤差を最小化する。 「ノイズ状態から正しい未来フレームへ戻る方向（速度ベクトル）」 を学習する
4 提案手法（ Solarisモデル 学習時） Solarisの計算フロー 動画 I ↓ VAE encoder ↓ 潜在 x ↓ first-frame conditioning ↓ ノイズ混合 ↓ DiT ├ Multiplayer Self Attention └ Cross Attention ↓ 速度場 vθ ↓ Flow Matching Loss
4 提案手法（ Solarisモデル 推論時） 推論時には， 開始フレームと行動列を条件として， 潜在空間で 1 時刻ずつ自己回帰的に将来フ レームを生成する。 生成された潜在列は最後に VAE decoder で画像へ戻される。 推論時の流れ 1. 開始フレームを入力 2. VAE encoder で潜在へ変換 3. 先頭フレームから first-frame tokens を作成 4. 行動列を action module で埋め込み 5. 生成済み潜在を履歴として保持 6. 各時刻で拡散サンプラにより 次の潜在フレームを生成 7. Multiplayer Self-Attention により視点間整合を保つ 8. 生成した潜在列を VAE decoder で画像列へ変換
4 提案手法（ Solarisモデル 学習パイプライン） Solaris の学習は次の 5つの Stageで構成される。 Stage 0: pre-trained video model（Matrix-Game 2.0） ・既存の Matrix-Game 2.0（action-conditioned Video DiT） を初期モデルとして用いる。 ・このモデルは、複数のゲーム（Minecraftを含む）で事前学習 されており、「行動 → 次の映像」を生成する Video World Modelの基礎能力を持つ。 学習パイプラインの全体像 （“できるだけ学びやすい条件”から始めて、 最後に“本番生成と同じ条件”へ寄せる） ※この時点では単一プレイヤー前提であり、行動空間も限定的 （WASD＋視点操作）。 ※また、このモデルは 双方向（bidirectional）な動画拡散 モデルとして学習されている。 ※Stage 0では学習は行わず、この事前学習済み重みを出発点 としてStage 1以降でMinecraft特化・マルチプレイヤー対応 へ適応していく。
4 提案手法（ Solarisモデル 学習パイプライン） Solaris の学習は次の 5つの Stageで構成される。 Stage 1: single-player（双方向） ・まず1人プレイで、Minecraftの見た目と行動の対応を安定に学ぶ。 ・※ここでの双方向（bidirectional）は「時間方向」の話で、 プレイヤー数（single/multi）とは別。学習中はクリップ全体 （過去・未来）を同時に見られるため、学習が壊れにくい。 Stage 2: multiplayer（双方向） ・2人分の視点を同時に扱い、相手の動きや環境変化が 「もう一方の画面」にも矛盾なく出るように学ぶ。 ・この段階の双方向モデルは文脈を広く見られるので、 後段の Self Forcing で Teacher（お手本） になる。 学習パイプラインの全体像 （“できるだけ学びやすい条件”から始めて、 最後に“本番生成と同じ条件”へ寄せる）
4 提案手法（ Solarisモデル 学習パイプライン） Solaris の学習は次の 5つの Stageで構成される。 Stage 3: Causal training (multiplayer（因果＝本番形）) ・本番の生成は「過去の数フレーム（窓）＋行動」だけで次を 順に出すしかない。 ・そこで学習もその制約（因果マスク＋窓）に合わせ、推論と 同じ形で動く Generator（本番用モデル） を作る。 学習パイプラインの全体像 （“できるだけ学びやすい条件”から始めて、 最後に“本番生成と同じ条件”へ寄せる） Stage 4: Self Forcing（Checkpointed Self Forcing） ・本番では自分の生成が次の入力になるため、少しのズレが 長時間で増幅しやすい。 ・Teacher が示す「こうあるべき分布」に寄せつつ、Generator には 自分の生成を入力にした練習をさせて、長尺で崩れにくく する(自己回帰ロールアウト（生成→次入力） ) ・Checkpointed Self Forcing は、この長尺の練習を メモリ爆発せずに回すための工夫 （ロールアウト保存→並列再計算で逆伝播）。 ・ 長尺生成では、過去の一部だけを見る スライディング ウィンドウ / KVキャッシュ の発想が重要になる （注）スライディングウィンドウ: 長い動画でも、モデルが毎回参照できるのは「直近Nフレーム （潜在ならNコマ）」だけに制限し、生成が進むたびにその窓を …(t-N..t-1) のように右へずらして使う方式。 （注）KVキャッシュ: Transformer の Self-Attention で計算する Key/Value（過去トークンの表現）を保存し て再利用し、次フレーム生成のたびに同じ計算をやり直さず高速化する仕組み（窓の範囲だけ保持することが多い）。
4 提案手法（ベースモデル Matrix-Game2.0） ・立ち位置: Solaris は、既存の action-conditioned 動画生成モデル Matrix-Game 2.0 を土台（初期化） として使い、そこから「マルチプレイヤー化」に必要な最小改変を加える。 ・何ができるモデル？（入出力） ・入力: 参照画像（/先頭フレーム）＋行動列 ・出力: 行動に沿った将来の動画（= “こう動いたらこう見える”を動画として生成） ・内部表現の要点 画像/動画を 3D VAE で潜在に圧縮し、潜在上で DiT（拡散Transformer）を回して生成する （計算を軽くしつつ画質を出す）。 https://matrix-game-v2.github.io/
5 実験方法 (評価ベンチ・指標) 評価ベンチ ・評価には、学習で見ていない held-out episode types を用いる。 ・評価対象は、Movement / Grounding / Memory / Building / Consistency の5能力である。 ・狙いは、単に動画がきれいかを見るだけでなく、複数プレイヤーが同じ世界を共有している整合性をタスクごと に分けて測ることである。 指標 ・FID：生成動画の全体的な視覚品質を測る指標。低いほど良い。 ・VLM as a judge：生成動画がタスクの意味内容を正しく満たしているかを、VLM に検証可能な質問をして 判定する指標。高いほど良い。 ・具体的には、各タスクごとに「左に移動しているか」「相手が正しい位置に現れているか」などの質問 を行い、期待される正解と一致した割合を評価値とする。 この評価設計のポイント ・従来の FID だけでは、「映像がそれっぽい」ことは測れても、「2人が同じ世界を共有している」 ことまでは十分に測れない。 ・そこで本研究では、画質指標（FID） と 意味・整合性指標（VLM judge） を併用し、 マルチプレイヤー world model に必要な能力を多面的に評価している。
5 実験方法 (評価ベンチ・指標) 5つの評価タスクの意味 1. Movement ・プレイヤーの移動や向きの変化が、各視点で自然に生成できるかを調べる。 ・要するに、基本的な行動追従ができているかを見るタスクである。 2. Grounding ・片方のプレイヤーの位置や行動が、もう一方の視点に正しく接地して現れるかを評価する。 ・たとえば、相手プレイヤーがどこにいるかが、2視点で矛盾なく表現されるかを見る。 3. Memory ・一度視界から外れた相手や物体について、再び見えたときに正しい位置関係を保てるかを調べる。 ・つまり、遮蔽や視野外の状況でも、世界の状態を記憶できているかを見る。 4. Building ・ブロック設置や採掘などの環境改変が、両視点に整合して反映されるかを評価する。 ・たとえば、Aがブロックを置いたら、Bの画面にもその変化が見える必要がある。 5. Consistency ・同じ世界を見ている2人の視点として、二画面の整合性が保たれているかを調べる。 ・同方向を向けば似た景色、別方向を向けば異なる景色になるべきであり、その一貫性を測る。
5 実験方法 (評価ベンチ・指標)
5 実験方法 (評価ベンチ・指標)
6-1 実験結果 (定性) 図1では、4つの生成例を通して Solaris のマルチ視点整合性を示す。 ① 採掘と設置：壊す／置く環境変化が両視点で共有される ② バトル：攻撃の相互作用が両視点で対応して現れる ③ 建築＋相手を見る：環境更新と相手位置の整合を維持 ④ 建築＋視点変化：建築・向き・相手の見え方を同時に整合 → 複数プレイヤーが同じ世界を共有している生成 を定性的に確認できる。
6-2 実験結果 (能力例・訂正) 図10では、4つの能力例を通して Solaris の世界理解 能力を示す。 ① 状態追跡：ブロック設置後、インベントリ数が 正しく更新される ② 環境同期：雨などの環境変化が両視点で同時に 発生する ③ 行動整合：採掘・設置・アイテム使用が正しく 反映される ④ 相互作用：複雑地形での戦闘（PvP）が両視点で 整合する → 状態・環境・行動・相互作用を含め、 複数プレイヤーが同一世界を共有している生成 を確認できる。
6-3 実験結果 (ベースライン比較・長尺) 図9では、既存手法（Multiverse 等）との比較を通 して長尺生成性能を評価する。 ・ベースライン：時間が進むにつれて - 視点の崩れ - 物体の破綻 - 世界の不整合 が発生する ・Solaris： - 長時間でも視覚品質を維持 - プレイヤー間の整合性を保持 - 建築・環境変化も破綻しない ・特に、単一プレイヤー事前学習なしでは - 人体の崩壊 - 不自然な環境（例：水中化） が発生 → 長尺・マルチ視点で安定した世界生成を実現して いる点が優位 Frame concat（ベースライン①） ・既存手法（Multiverse系） ・複数プレイヤーのフレームを単純に結合（concat）して入力 Solaris w/o pretrain（ベースライン②） ・Solarisと同じ構造だが ・single-player事前学習なしで最初から学習 問題： •視点間の関係を「構造として」理解していない •長時間で破綻しやすい（ズレ・不整合） 問題： •人体の崩壊（プレイヤーが分裂など） •不自然な世界（例：水中化） •基本的な物理・見た目が不安定 Solaris（提案手法） ・single-playerで事前学習 → multi-playerに拡張 ・Shared Self-Attentionで視点間を統合
6-4 実験結果 (定量評価) 提案 Solaris は Grounding / Building / Consistency で優位（VLM↑/FID↓）。 マルチ視点で難しい「相手位置・世界改変・二画面整合」に効いている。 ・Frame concat は “動き” は強いが “共有世界” が壊れる: Movement VLM は最高（77.1）だが、 Building は 0.0、Consistency も 49.5 に留まり、FIDも悪化（Consistency FID 129.4）。 ・単一プレイヤー事前学習の重要性: Solaris w/o pretrain は Grounding VLM 29.2 など多くで劣化し、 見た目（FID）も悪くなりがち → Stage1（単一プレイヤーでの土台作り）が効いている。 ・Memory は依然むずかしい: Solaris でも Memory VLM は 37.5 程度で頭打ち （遮蔽・視野外の保持が難所であることを示唆）。
6-5 実験結果 (Self Forcing アブレーション) ・ODE Reg（ODE Regularization） 時間的に滑らかに変化するように制約をかける ・diffusion（Flow Matching）を →「変な飛び方しないように」する補助 ・Pre-DMD（Pretrained Diffusion Model） ・Causal FT（Causal Fine-Tuning） single-playerで事前学習された動画モデル 未来を見ないようにして学習する（因果的） 「世界の基本ルール（見た目・物理）」を学習済み ・学習： 過去＋未来（bidirectional）OK ・推論： 未来は見えない そのギャップを埋めるための微調整 表3では、Self Forcing の学習設定の違いを比較する ① 初期化方法 → 複雑な方法は不要 → Causal FTのみで十分 ② 蒸留（Pre-DMD） → 事前蒸留は効果なし ③ KV-BP → 有効化すると画質が向上 → Self Forcingはシンプルな構成で成立し，特にKV-BPが性能向上に重要 KV-BP（Key-Value Backprop） attentionの過去情報（KV）を通して勾配を流す ・長い系列で学習するための工夫 ・ただしメモリが重い
7 考察 ・最小改変でも「同一世界の共有」に効く: 追加の中核は Multiplayer Self-Attention と 行動入力の拡張で、2視点を別々に生成するのではなく、 視点間で情報交換して整合を作る設計が効いている（定量でも Grounding/Building/Consistency が良い）。 ・“画質”より“整合”が難所: FID は見た目の自然さには効く一方、視点間の整合は直接測りにくい。そこで VLM judge を併用し、相手位置・建築反映・二画面一致のような条件をタスクで直接測るのが妥当。 ・長尺で崩れないには「推論形に寄せた学習」が必要: bidirectional→causal（窓・マスク）→Self Forcing の段階化で、学習時の条件を推論（窓つき自己回帰） へ近づけ、誤差蓄積を抑える。 ・Checkpointed Self Forcing は“Self Forcingを回すための省メモリ化”: Self Forcing の目的は同じまま、rollout をキャッシュ＋再計算（checkpointing）して長いロールアウト学 習を可能にする。アブレーションでも KV-BP（KV側への逆伝播）が主に FID 改善に効く、という示唆。 ・単一プレイヤー事前学習（Stage1）が土台: w/o pretrain は多くのカテゴリで劣化し、 見た目・挙動の破綻も増える。まず単一視点で「Minecraftの見た目・操作」を安定化させるのが重要。
8 議論・限界 合成（ボット）データ起因の分布ギャップ: 学習は主に自動収集データに依存するため、人間プレイ特有の挙動・カメラ操作・タスク分布とのズレが残りう る（人手データの統合・ドメイン適応の余地）。 永続メモリ（状態保持）の弱さ: 遮蔽や視野外の間に「共有世界の状態」を内部に保持し続けるのは難しく、長尺・複雑な相互作用ほど破綻し やすい（Memory 系が難所になりやすい背景）。 操作・観測の表現制約: GUI操作（クラフト等）や raw mouse 記録には非対応で、カメラは相対 yaw/pitch など限られた表現。結果 として「実際のMinecraftの自由度」を完全にはカバーできない。 評価の限界（VLM judge）: 意味整合を直接測れる一方、VLM 依存のバイアスや誤判定の可能性があるため、 プロンプト・正解ラベル・GT上精度の検証（付録）とセットで解釈する必要がある。
9 制限・貢献 （貢献） ・マルチプレイヤー動画世界モデル Solaris: Multiplayer Self-Attention で視点間整合を作り、 2視点同時生成を実現 ・大規模収集基盤 SolarisEngine + データ公開: 2視点同期の動画＋行動ログを大規模に収集できる 土台を提供 ・評価ベンチ（5タスク + VLM judge）: 画質だけでなく「同一世界の共有」を定量化する指標設計 ・段階学習 + Checkpointed SelfForcing: 推論形（窓つき自己回帰）に寄せて学習し、 長尺での崩れを抑える（省メモリでSelf Forcingを実行可能に） （制限） ・ボット/合成データの分布ギャップ、永続メモリの弱さ、GUI操作・raw mouse 非対応、 VLM judge 依存の評価バイアス
10 感想 ・「同一世界の共有」を評価まで含めて正面から扱っているのが良かった （画質だけでなく、相手位置・建築反映・二画面整合をタスク化して測っている） ・モデル、データセットと全て公開していただけたため、自分でも試すことができるのが良いとおもう Website https://solaris-wm.github.io/ Engine Code https://github.com/solaris-wm/solaris-engine Model Code https://github.com/solaris-wm/solaris Datasets https://huggingface.co/collections/nyu-visionx/solaris-data Models https://huggingface.co/collections/nyu-visionx/solaris-models 44