敵を撃ち倒し、振り返って歩く。たった今通り過ぎた部屋、その中に落ちていたアイテムや半開きのドアは、もう画面の外だ。数分後に戻ってきたとき、その状態はそのまま残っているだろうか?
映像生成モデルでゲーム画面を描くアプローチは、まさにこの一点で最もよく崩れる。画面の外へ出たものはモデルの「記憶」の中にしか残らず、その記憶は時間とともに薄れていくからだ。
Matrix-Game 4.0が選んだ原則はひとつ。世界が今どんな状態なのかをモデルの記憶に委ねず、コードが別に抱え込んでおく。そのおかげでRTX 5090グラフィックボード一枚で480p・60FPSでプレイされる世界を、キーを押してから画面に反映されるまで112msの遅延で回しきる。
生成モデルで操作可能な映像を作る流れそのものは新しくない。Genie系列の「インタラクティブ・ワールドモデル」——プレイヤーの入力に反応して次の画面をリアルタイムで作り出すモデル——がすでに可能性を見せてきた。問題は、目標が「ちょっと見て回る」から「ルールが生きている長いゲーム」へと変わった瞬間に表れる。映像生成だけに頼って世界を維持しようとすると、三つがずれる。
状態を忘れる。 世界の状態が、生成されたピクセルとモデルの文脈の中にだけ暗黙的に入っている。視界から外れた領域は別に保存されない。だから戻ってきた部屋が、最初に見た部屋と違っている。
誤差が積もる。 モデルは直前のフレームを見て次のフレームを作る(これを自己回帰と呼ぶ)。正してくれる外部の基準がないので、小さな誤差がフレームを経るごとに雪だるま式に膨らみ、場面がじわじわ崩れていく。外部の3Dツールでカメラ位置を推定して貼り合わせても、その推定の誤差が積もれば結局同じ壁にぶつかる。
ルールを執行しにくい。 相互作用が移動と単純な環境反応にとどまる。命中と外れを判定し、行動の結果を維持し、プレイヤーが追う目標を掲げること——ゲームをゲームらしくするルールを映像生成だけで強制するのは難しい。しかも過ぎ去ったフレームが空間情報として整理されず、そのまま積み上がるだけなので、プレイが長くなるほどメモリコストが膨らむ。
結局、爆発に見える画面を描くことと、その爆発が残したダメージを計算して世界に記録することは、別々の仕事だ。拡散モデル(ノイズから画像を復元しながら学ぶ生成モデル)は「何が何と一緒に現れるか」という統計的な相関を学ぶだけで、物理や因果を理解しているわけではない。だから論文は、今の映像生成器を、世界を理解するモデルというより、指示された通りに描き出すレンダラーに近いものと見ている。[^1]
既存アプローチとの違いからおさえよう。Genie系列は映像生成が世界の状態まで背負う——先ほど見た弱点が向かう先がこちらだ。Matrix-Game 4.0は逆を行く。コードで定義した世界を映像モデルがレンダリングする側に立ちつつ、そこにリアルタイムの自己回帰生成と、コードを直接書くAIエージェントを組み合わせる。「操作可能な映像」から「実行可能な世界」へ移ろうとしているのだ。
実際にどう噛み合うのか、プレイヤーが床のドラム缶を撃つ一場面でたどってみよう。仕事は三つに分かれる。エンジンが判定し、エージェントがコードと説明を用意し、モデルが画面を作る。
エンジン — 判定と記憶。 軽量なゲームエンジンが世界の状態とルールをコードで握る。弾がドラム缶に当たったか、当たったなら爆発が起きて周囲の体力がどれだけ削れるかを、エンジンが決める。このときエンジンは完成した画面を描かない。ドラム缶も壁もキャラクターも単純な図形のままにしておく。肝心なのは、爆発で消えたドラム缶と焦げた床の状態を、プレイヤーが振り向いて画面の外へ送り出しても、エンジンがそのまま抱え続けているという点だ。
エージェント — あらかじめ準備する側。 エンジンとモデルの間には、マルチモーダルなコーディングエージェントがいる(「マルチモーダル」とは、文章と画像をあわせて扱うという意味だ)。重要なのは、このエージェントが毎フレーム割り込むのではなく、プレイが始まる前やルールが変わる瞬間に働くという点だ。
やることは二つ。第一に、プレイヤーが言葉で新しいルールを求めたら、それを実行可能なゲームコードに変えてエンジンに加える。「モンスターが四方から押し寄せるようにして」という一言は、コードに移す瞬間にいくつもの決定を要求する——どこから現れ、どう動いて攻撃し、何で勝敗を分けるのか。プレイヤーが埋めずに残した部分は、エージェントが既存の場面の文脈に合わせて補う。まだ何も決まっていないドアを開ければ、エージェントが「隅に鍵のかかった鉄製の箱がある倉庫」を建ててエンジンに登録し、その瞬間から箱の状態と開閉の有無はエンジンが管理する。
第二に、場面に登場するオブジェクトごとに、どんな見た目かという説明をあらかじめ付けておく。地味な箱ひとつに、どんな材質・どんな色という意味を添えておく、という具合だ。この説明が後で画面を描くときの材料になる。
モデル — 画面。 映像生成モデルは、エンジンが渡した単純な図形の画面を受け取る。この図形の画面を論文は低ポリプロキシと呼ぶが、質感のない基本図形だけを残した骨組みの画面という意味だ。モデルはこの骨組みの構造と動きはそのまま守りつつ、材質・照明・雰囲気をまとわせる。今の入力と直前までのフレームを条件に、映像を継ぎ足して描く。
プレイ中のリアルタイムループはこう回る。プレイヤー入力 → エンジンが状態更新 → 図形の画面と制御信号 → 映像レンダリング → プレイヤーへの視覚フィードバック。注目すべきは、このループの中にエージェントがいないことだ。ドラム缶が爆発するたびにエージェントが呼び出されて場面を説明するのではない。爆発の判定はエンジンが下し、その結果を画面に伝える「説明」は、後で見るようにエンジンの状態値から自動的に埋められる。エージェントが書いたコードと、あらかじめ付けておいたオブジェクトの説明は、このループが回る前にすでに準備されている。
こう分けておくと、世界を一貫して維持する難しい仕事と、リアルタイム速度がかかった仕事とが分離される。エンジンは軽いシミュレーションだけ回せばよいので、速度の負担はレンダリング側に寄せ、そこで集中的に削れる。同じ世界の状態を複数のプレイヤーが共有しながら各自の視点で見る道も、この構造から自然に開ける。
レンダラーは「単純な図形の画面 → 高画質の映像」という対応を学ばなければならない。そのためには、まったく同じ場面を二つのバージョンで撮ったペアデータが必要だ。ひとつは完成した高画質の映像、もうひとつは同じカメラ・同じタイミングの図形の画面だ。二つがピクセル単位で噛み合ってこそ、モデルは「この骨組みにはこの質感」というルールを身につける。
このペアデータはUnreal Engine 5で合成した。おさえておきたい点がある。データを作ったこのUnreal Engine 5と、プレイ中に状態・ルールを握る「軽量なゲームエンジン」は、名前が似ているだけで互いに別の用途だ。ひとつは学習素材を撮る撮影現場であり、もうひとつはゲームが実際に動く舞台だ。
扱った場面は四種類——メガシティ運転、砂漠の開けた地形と中世の城での三人称シューティング、砂漠の峡谷での空中戦——で、すべて合わせてクリップ114,334本、1,712時間分だ。(場面ごとの詳しい規模と、評価用に取り分けたデータは付録にまとめた。)
図形の画面はこんな見た目だ。空は黒く床はグレーのチェッカーボード、建物や壁は単色の箱や角柱、木は円柱の上に球、キャラクターはブロック状。すべて黒い輪郭線だけをまとい、質感・反射・影はない。空間の幾何構造だけを残して、残りを取り払った格好だ。エンジンはこの画面とともに、オブジェクトID、可視性、相互作用イベントも記録する。
この記録が「動的キャプション」につながる。先ほどリアルタイムループで後回しにしたあの「説明」が、まさにこれだ。動的キャプションはモデルを呼ばず、エンジンの状態値だけで作る。インタラクティブなゲームでは、プレイヤーが動くたびに画面が変わる。カメラを回せば見えるオブジェクトが変わり、イベントがオブジェクトの状態を変える。固定された説明一行では、これを追えない。そこで、オブジェクトごとにあらかじめ付けておいた意味の説明(エージェントが用意しておいたあの説明だ)に、今見えているオブジェクトとリアルタイムの状態をルールベースのテンプレートで埋め込む。車が去れば説明から抜け、歩行者は「立っている」から「接近中」に変わり、新しく入ってきたオブジェクトは「変更」と表示される。図形の画面が位置・配置という構造を、キャプションがどのオブジェクトがどんな状態かという意味を供給して、互いを埋める。ビジョン・言語モデルを通さないので誤る余地が少なく、追加の遅延もない。
レンダリングモデルは、Wan2.2 5BのFun Control変種を映像対映像(V2V)モデルに改造したものだ。V2Vは入力映像を受け取って別の見た目の映像に変える方式を指す。ひとかたまり(チャンク)を生成するとき、四つが条件として入る。エンジンの図形の画面は「何をどこに描くか」を指示し、動的キャプションはディテールを供給し、空間メモリ参照フレームはプレイヤーが同じ場所へ戻ってきたときに先に見た姿とずれないよう押さえ、最初のフレームは新しく作った映像を今の画面に継ぎ合わせる。(ネットワーク仕様と学習設定は付録にある。)
リアルタイムは速度と反応のあいだの綱引きだ。一度に短く生成すれば反応は速くなるが、モデルをより頻繁に呼ばねばならず、呼び出すたびにやる仕事が少なければGPUが次の指示を待って遊ぶ。論文は二つでこの綱引きを解くが、効果から言えば、ひとつは「描く回数を減らすこと」、もうひとつは「すでにやった計算を使い回すこと」だ。
描く回数を減らす。ふつう拡散モデルは、ノイズを何度にも分けて少しずつ取り除きながら絵を完成させる。このモデルは蒸留を経て、その過程を一、二回に圧縮する。蒸留とは、大きなモデルの結果を小さな手順で真似させるように教えることだ。取り除く回数が減れば、一フレームにかかる計算もそのぶん減って速くなる。
すでにやった計算を使い回す。毎フレームすべてを最初から計算する代わりに、先に作ったフレームと、変わっていないキャプションの中間計算結果を取っておいて、また取り出して使う。特にキャプションは、変わったときだけ計算し直す。同じものを二度計算しないぶん、時間が抜ける。
累積の最適化の大きな分け前は二つの段階から出た。生成段階を一回に減らした蒸留がスループットを24.2から51.2FPSへ引き上げ、複数の演算をひとつにまとめるカーネル最適化が遅延を367msから121msへ落とした。最適化を一つずつ積み上げた結果と各段階の数値は、付録の表にまとめた。全体としてはおよそ19倍速くなり、遅延はおよそ9.9倍低くなった。
数値は条件とともに読んでこそ誤解がない。とくに二種類の速度を混ぜてはいけない。ひとつはモデルがフレームを打ち出すスループットで、もうひとつはプレイヤーがキーを押したときに画面が反応する速さだ。測る対象が違う。
論文が代表的な成果として掲げるのは反応の速さだ。RTX 5090一枚で480p・60FPSでプレイされ、キー入力が画面に反映されるまで112msかかる。プレイの体感に直結する数値だ。
スループット側の代表値は83FPSで、シングルステップ・デノイジングの定常状態での生成速度だ。このときGPUメモリは最大およそ18.2GiBを使う。60FPSのプレイと83FPSのスループットが別々に記される理由がここにある。前者はゲームが実際に動くフレームレート、後者はモデルがフレームを取り出す速度だ。
普及帯のGPUに下りても使いものになる。固定プロンプトでシングルステップ生成が、RTX 5080でおよそ67FPS、RTX 5070 Tiでおよそ58FPSに達する。どちらも16GiB級なので、ローカル配備の範囲が広がる。ただし「固定プロンプト」という但し書きを聞き流してはいけない。先に見たように、キャプションが変わればテキスト側の計算をやり直さねばならないので、プロンプトが固定された側が速度で有利だ。キャプションをキャッシュするように組んだ設計が、そのまま性能の条件として表れるわけだ。
機能の面では、エンジンがルールを強制する、手を入れられるシューターと運転ゲームを実演する。コードとモデルの重み、低ポリのアセットを公開している点は、研究と創作の両方に役立つ。
著者たちが明かした制約から見よう。学習はゲームごとにモデルをひとつずつ置く方式だ。四つの場面にそれぞれ専用のモデルがあり、ひとつの汎用レンダラーがすべてのゲームを処理するわけではない。データもすべてUnreal Engine 5で合成したペア映像なので、図形→高画質の対応が、この合成パイプラインが出せる範囲の中で定義される。普及帯GPUの高いFPSも固定プロンプトが前提だ。
より深い問いは、「世界が一貫している」という言葉を解きほぐすと出てくる。じつはこれは三つの異なる要求だ。
第一に、状態が維持されること。一度爆発したドラム缶は、消えたままでい続けなければならない。これはエンジンが状態をコードで握ることだけで、かなり解決される。
第二に、同じ場所が同じ姿で見えること。エンジンが「ここに倉庫がある」という事実を握っていても、その倉庫を描き直すのはモデルの役目だ。モデルが毎回少しずつ違って描けば、状態はそのままなのに外見が揺れる。空間メモリ参照フレームを別に置く理由は、まさにこの外見の揺れを押さえるためだ。
第三に、判定と画面が一致すること。エンジンは命中と判定したのに画面では弾が外れたように見えれば、プレイヤーは何を信じればよいのか分からない。エージェントが作り出したドアがエンジンには「開けられない装飾」として登録されているのに、画面は開きそうに描かれれば、近づいたプレイヤーは空振りをすることになる。
これを確認済みの欠陥と断じるのは早い。ただ、どう見極めるかは言える。同じ場所を離れては戻りながら外見がどれだけ変わるかを測り、エンジンの命中判定と画面に描かれた被弾表現がフレーム単位で噛み合うかを比べてみることだ。自然言語で場面とルールを作り出す流れが、実際にどれだけ一貫してコードに落ちるのかも、今は定性的な実演でしか確認されていない。この三つを分けて測る瞬間、設計の紹介は評価の視点へと深まる。
この論文から私たちが持ち帰る原則はひとつだ。持続する状態を、モデルの会話の記憶の外で管理する。ONTLEにすでに実装された設計を説明するのではなく、この論文を自分たちの仕事に照らして見た視点だ。
今、私たちが悩んでいる問題はこうだ。AI PMが一週間、複数プロジェクトの作業状態を追いながら、朝ごとにブリーフィングを作る。よくある失敗は、モデルに「先週の文脈を覚えておいて」状態を維持させようとすることだ。PMエージェントが会話の記憶だけで「このタスクは終わっていたか」を推論すれば、小さな取り違えが次のブリーフィングへ、またその次へと広がる。映像モデルが世界の状態をピクセルと文脈に抱えていて誤差が積もる構造と、同じ落とし穴だ。
だから適用する設計も同じだ。状態の真実は、モデルではなくタスクDBに置く。どのタスクがどんな状態かは決定論的なシステムが握り、そのタスクが今回の会話の文脈の外にあっても、状態はDBに残る。モデルはDBが差し出した状態を人が読むブリーフィングに移し、「今週遅れているものだけリスク中心で」といった要求を、照会条件と分類ルールに翻訳する。動的キャプションをルールベースで取り出したのと、同じ精神だ。
だが、この喩えがそのまま成り立たない点がある。ゲームエンジンは世界の状態を自ら作り出すので、エンジンが握った値はそれ自体で真だ。業務DBは違う。タスクの状態は、コミットログ、レビュー承認、人の報告といった外部の信号が入ってきて初めて埋まり、その信号は解釈と確認を経なければ信じられない。DBが状態を「保管」することと、その状態が「正しく入ってきて更新される」ことは、別の問題だ。だから手順をひとつ足す。完了の有無が曖昧だったり出所が衝突するタスク——たとえばコミットは上がったのにレビューは未承認の場合——は、ブリーフィングに自動反映せず「要確認」として切り分け、人や元の出所に一度問い直して状態を更新したうえでのみ「完了」へ移す。
研究段階の技術レポートで、コードとモデルの重み、低ポリのゲームアセットを公開しています。公式リポジトリが公開したモデル・ゲームは中世の城・古代エジプト・都市運転の三種で(学習に使った砂漠の峡谷の空中戦は公開リストにありません)、場面ごとに専用モデルを学習した構造なので、公開された場面の外へそのまま拡張されるわけではありません。
まだです。データがUE5で合成したペア映像で、場面ごとにモデルを別々に学習した構造だという前提があります。著者たちは、ゲーム開発ワークフローでコーディングエージェントとニューラルレンダリングがどう使えるかを示す「具体的な予告編」として、この仕事を位置づけています。
表1. 学習データ
| 場面 | クリップ数 | 分量 | FPS |
|---|---|---|---|
| 中世の城 | 17,848 | 290時間 | 24 |
| 古代エジプトの砂漠 | 40,296 | 643時間 | 24 |
| 砂漠の峡谷の空中戦 | 28,720 | 467時間 | 24 |
| CitySampleメガシティ | 27,470 | 312時間 | 17 |
| 合計 | 114,334 | 1,712時間 |
シューターと空中戦のクリップはおよそ1分の長さだ。過学習と評価の汚染を防ぐため、城・砂漠・都市は完全な撮影セッションを3つずつ、空中戦はマルチマシン撮影バッチ全体を取り分けて評価用にのみ使う。これらのセッションは学習に一クリップも入っていない。
表2. 最適化の累積効果 (RTX 5090、チャンク1潜在フレーム=4フレーム、KVウィンドウ21潜在フレーム)
| 最適化 (累積) | FPS | 遅延 |
|---|---|---|
| ベースのCausal Wan2.2 DiT (4ステップ、フルWan VAE) | 4.5 | 1110ms |
| + タイニーVAE(TAEHV) | 6.5 | |
| + RoPEカーネル・テキストKVキャッシュ | 15.4 | |
| + 8ビット重み・CUDA Graph | 24.2 | |
| + 1ステップ蒸留 | 51.2 | |
| + 非同期I/Oパイプライン | 57.7 | |
| + フューズドTritonカーネル | 65.8 | 367ms → 121ms |
| + リングKVキャッシュ | 73.7 | |
| + スプリットKV FlashAttention | 83.4 |
ネットワーク (DiT、50億パラメータ)
学習 (ゲームごとにモデル1個)
[^1]: 著者たちはこの「絵への移し替え」を、ヤコブソンの記号分類のうち記号間翻訳(intersemiotic translation)になぞらえる。意味を握る側が上流の言語モデルであり、拡散モデルはその指示を絵へ移すのだという。