Li et al.: 動画生成 AI をゲームエンジンとして読み直す——「状態」という残された難所 — Fukai が読む

一段落要約

動画生成 AI(映像そのものを予測して作り出す AI)で「遊べる世界」を作る、という研究が急速に増えている。この論文は、その乱立した研究群を、ふつうのゲームエンジンが昔からやってきた「プレイヤーの入力 → 内部状態の更新 → 画面の描画」という一巡のループに引き寄せて整理し直したサーベイ(研究の地図を描く論文)である。著者らはこのループから、プレイヤー操作の表現・ゲーム状態のダイナミクス・状態と映像の一貫性の持続・リアルタイム生成という4つの軸を取り出し、既存手法を軸ごとに家系図のようにグループ分けしている。

著者らの結論は明快だ。いま難しいまま残っている問題——蓄積した条件から結果を決めること、画面外に出た結果を保持すること、効果をルールどおりのタイミングで出すこと——はすべて「ゲーム状態」に関わっており、しかし多くのモデルはその状態を明示的に持っていない、と整理する。加えて著者らは『黒神話:悟空』のボス戦から、フレーム単位で操作・エンジン内部の状態・映像を揃えた90時間超のデータセットを作り、状態を明示的に扱う研究の土台として公開する意図を述べている。2026年7月15日の arXiv preprint(査読前)である。

はじめに

今日読んだのは “From Pixels to States: Rethinking Interactive World Models as Game Engines”(arXiv:2607.14076v1、2026年7月15日投稿、cs.CV)。著者は Zhen Li、Zian Meng、Shuwei Shi、Mingliang Zhai、Jiaming Tan、Chuanhao Li、Kaipeng Zhang の7名で、所属は Alaya Lab と記されている。連絡先の責任著者は Chuanhao Li と Kaipeng Zhang の二名だ。arXiv にのみ存在する preprint(査読前の原稿)であり、投稿から日が浅いため、まだ広く議論されていない段階の文章として読む必要がある。

私がこの一本を選んだのは、内容が新奇だからではない。むしろ逆で、この論文がやっているのは「新しい手法の提案」ではなく「既存研究を、ゲームを作る人が持っている語彙で並べ直す」という作業だからだ。動画生成でゲームを作るという話題は、この2年ほどで論文が洪水のように出た。個々の論文は読めても、全体として何がどこまで進んで何が残っているのかは、外から見ると分かりにくい。その地図を、ゲームエンジンのループという誰もが知っている図式で描いてくれる文章は、専門外の読者にとって価値が高い。

もう一つの理由は、この論文が扱う「状態(state)」という概念が、パズルを作る人にとって最も身近なものだからだ。パズルは、盤面という明示的な状態を持ち、入力によってその状態が規則どおりに変わり、その状態が画面に描かれる、というだけのものである。つまりパズル制作者は、この論文が「AI にはまだ難しい」と言っている構造を、最初から手で書いている。だからこの論文は、AI 研究の話でありながら、パズル設計の語彙を再確認する読み物としても機能する。

背景

背景を押さえておく。従来のゲームエンジンは、プレイヤーの入力を受け取ると、まず内部の変数群——体力、スタミナ、クールダウン、装備といった「ゲーム状態」——を規則に従って更新し、その更新後の状態から画面を描く。論文の冒頭では『黒神話:悟空』を例に、攻撃キーを押しても即座にピクセルが出るのではなく、エンジンはまずスタミナやクールダウン、ボスの位置とアニメーション段階を参照し、戦闘ルールを適用して「外した/ダメージ/怯ませた/フェーズ移行」といった結果を確定させ、その後にフレームを描く、と説明されている。

一方、近年の動画生成モデルは、この手順を丸ごと飛ばす。ジオメトリや挙動ルールを人が書く代わりに、映像から世界の規則性をまとめて学び、ユーザーの入力を条件として次の観測(=映像)を直接予測する。この路線から、リアルタイムに動くニューラルゲームエンジンや、動画生成に基づく世界シミュレータが次々に現れ、「次世代のゲームエンジンになりうる」と位置づけられるようになった、というのが論文の状況認識だ。

問題は、この路線が別々の研究の流れに分かれて進んできたことだ。視点の動かし方を精密にするカメラ制御の系統、言語やエンティティ単位で操作の幅を広げる系統、長く回しても過去と矛盾しないようにする記憶機構の系統、そして生成を実時間に近づける蒸留・ストリーミングの系統。論文はこれらが「それぞれ重要な側面を扱っているが、互いの関係とゲーム世界モデリング全体への含意が見えにくい」と述べる。分かっていなかったのは個々の技術ではなく、それらを並べる共通の座標軸のほうだった、という整理である。

アプローチ

著者らのやり方は、実験ではなく整理である。ゲームエンジンの「行動—状態—観測」ループを座標軸に使い、既存手法を4つの次元に分けて配置する。(1)プレイヤー操作制御、つまりプレイヤーの意図が生成に届く前にどう表現されているか。(2)ゲーム状態のダイナミクス、つまり世界の内部条件をどう表し、どう更新するか。(3)状態と観測の持続性、つまり長く遊んでも結果が矛盾しないか。(4)リアルタイム対話生成、つまり遊べる速さで返せるか。各次元でまず「遊べるゲーム世界に必要な能力」を述べ、次に手法を家族に分け、家族ごとの長所と代償を論じる、という共通の型で書かれている。

たとえば操作の表現は3つの家族に分かれる。一つ目は幾何的な軌跡としての操作——カメラの回転と平行移動を条件として与える系統で、視点の制御は精密になるが、扱えるのは移動と視点だけで、そもそも「精密な軌跡」は人間の生の入力とはかけ離れている、と評価される。二つ目はモーター信号としての操作——キーボードとマウスの状態をそのまま条件にする系統で、プレイヤーの操作実感には忠実だが、同じキーでも状況によって意図が違うため、コンボのような複合操作は学習しにくい。三つ目は意味イベントとしての操作——自然言語で「何をするか」を書く系統で、固定の入力体系では表せない相互作用まで扱えるが、粒度を細かくするほど条件付けのコストが上がる。

状態の扱い方も同じ調子で3つに分かれる。観測に埋め込まれた状態(=別建ての状態を持たず、世界のダイナミクスをピクセルの中だけで完結させる)、学習された潜在状態(=行動によって再帰的に更新される、圧縮された内部表現)、明示的な記述としての状態(=記号やテキストで書き出し、状態遷移を推論として扱う)。著者らは三番目について、「読めて検証できる」利点を認めつつ、状態注釈付きの大規模データが乏しいこと、離散的な記録では連続的な映像の動きを部分的にしか捉えられないこと、そして生成ループへの組み込みがほとんど未開拓であることを、そのまま弱点として挙げている。

論文のもう一つの柱がデータエンジンだ。著者らは Unreal Engine 製のアクション RPG『黒神話:悟空』を対象に、ボス戦のプレイを不特定多数のプレイヤー(スキルもプレイスタイルもばらばら)から集める仕組みを作った。エンジンを計装して毎ティックの操作と状態を JSON で書き出し、映像側は ReShade の自作シェーダで画面を分割して RGB とデプスマップを同時に映し、OBS Studio に各フレームのシステム時刻を記録させる。両者を同じ時計で打刻することで、あとからフレーム単位の突き合わせができる、という設計である。UI は該当する描画パスを無効化して消している。

発見

この論文は数値的な実験結果を出すタイプではないので、「発見」は主に整理から見えてきた構造のほうにある。最も鋭いのは、リアルタイム性の議論だ。著者らは、対話ループを縛る遅延には性質の異なる二種類があると指摘する。一つは制御遅延——入力から、視点が動くといった目に見える反応までの時間。これは短いほどよく、ゲームの操作感を決める。もう一つは結果遅延——行動から、攻撃が当たるといったルール上の結果が現れるまでの時間。こちらは短ければよいのではなく、正確であるべきだ、と著者らは書く。攻撃には発生・持続・硬直があり、結果が即座に現れると「間違っている」と感じられるからだ。

そのうえで著者らは、既存研究は「あらゆる遅延を縮めるべき量として扱っている」と述べる。数ステップで生成する蒸留(大きなモデルの振る舞いを小さく速いモデルに写し取る訓練)、ノイズ除去を流れ作業のように重ねるストリーミング生成、ハードウェアとアルゴリズムの協調設計。これらはいずれも入力からフレームまでの経路を短くするが、「結果がいつ現れるべきか」を扱ったものは一つもない、というのが著者らの評価である。

持続性の議論からも具体的な失敗像が出てくる。記憶を「過去の観測をそのまま保存したもの」として持つ手法は、静的な場面では確実に働く。しかし遊べるゲーム世界では世界が絶えず変わるため、過去の忠実なコピーが現在の参照にならない場合がある。著者らが挙げる例は分かりやすい——技で近くの建物を壊したのに、視界に戻ってきたとき記憶が無傷の建物を復元してしまう。動的なエンティティを記憶から除外する手法もあるが、環境そのものが変わる場合には効かない、と指摘される。

データセットについて確認できる数値は次のとおりだ。90時間超のプレイ、解像度 1280×720、30 FPS。フレームごとに三種類の正解データが付く——生のマウス・キーボード入力としての行動、ゲーム世界の内部変化を記述する状態、そして RGB フレームとデプスマップからなる観測。状態にはカメラ・プレイヤーキャラクター・ボスそれぞれの姿勢に加え、現在のアニメーション、発動中のスキル、体力・スタミナ・攻撃/防御・装備といった属性が含まれる。さらに、一定長の時間窓ごとに構造化した「スロットキャプション」と、Qwen3-VL-235B-A22B-Instruct が生成した「セマンティックキャプション」の二種類の注釈が付けられている。

使いどころ

一つ目。制御遅延と結果遅延を分けるという語彙は、AI を一切使わないパズルにもそのまま持ち込める。もし自分がデイリーパズルを作っているなら、セルを選んだ瞬間のハイライトやカーソル移動は必ず即座に返し(制御遅延は最小に)、一方で「正解/不正解」の判定演出は意図的に一拍置いてよい(結果遅延は速さではなく正しさ)。この二つを同じ「レスポンスの速さ」として一括で最適化すると、操作は軽いのに判定が軽薄に見える、という妙な手触りになる。私はこの区別を、今後 UI のレビュー観点として使うつもりだ。

二つ目。「状態を明示的に持つか、見た目に埋め込むか」という三分類は、生成 AI をコンテンツ制作に使うときの責任分界点そのものだ。もし自分が倉庫番系のパズルに自動生成を入れるなら、箱と壁とゴールの配置という盤面状態と、解の存在を保証するソルバは、絶対に記号側で持つべきである。生成モデルに任せてよいのは見た目・テーマ・装飾のほうだ。この論文が「ルールがピクセルの相関としてしか捉えられず、空間的・論理的な一貫性を保証しづらい」と述べているのは、まさにその境界を越えたときに起きることの説明になっている。

三つ目。画面外で世界がどう変わるかを設計として決めておく、という視点。もし自分がスクロールする盤面や複数の部屋を持つパズルを作っているなら、視界の外に出たオブジェクトの扱いを暗黙にしてはいけない。この論文の「壊したはずの建物が無傷で戻ってくる」という失敗は、実装上のバグとしてだけでなく、プレイヤーの因果理解を壊す設計上の事故として読める。盤面の一部しか見えないパズルでは、見えていない領域も同じ規則で進むことを、演出でプレイヤーに保証してやる必要がある。

四つ目。データエンジンの設計は、ウェブのパズルゲームのテレメトリ設計のひな型として読める。この論文がやっているのは要するに、(操作、状態、観測)の三つ組を同じ時計で打刻して揃えることだ。もし自分がデイリーパズルの難易度を後から分析したいなら、「何時何分にどのセルを押したか」だけを記録しても足りない。そのときの盤面状態と、プレイヤーが実際に何を見ていたか(どこがハイライトされていたか)まで揃えて初めて、詰まった瞬間の再現ができる。時間窓ごとに構造化して要約する「スロットキャプション」の発想も、ログを人が読める形に畳むやり方として応用が利く。

限界

著者自身が認めている限界から。明示的な状態を扱う路線については、大規模な状態注釈付きデータが必要になるがそれが乏しいこと、離散的な記録では連続的な映像のダイナミクスを部分的にしか捉えられないこと、そして生成ループへの組み込みがほとんど未開拓であることを挙げている。記憶を「現在の推定」として更新する新しい系統についても、高頻度の相互作用が小さな変化を積み上げて大きなずれになるため、毎ステップで効率的かつ確実に更新を判断する必要があり、その原理的な裏付けは未解決の問いだ、と書いている。操作を意味イベントで与える路線には、粒度を上げるほど条件付けコストが増えるという制御精度と対話効率のトレードオフがある、とも述べる。

ここから先は Fukai が読んで気づいた点だ。まず、この論文は自ら手法を提案しておらず、実験による比較もしていない。4つの次元と家族分けは著者らの整理であって、その分け方が唯一のものだと検証されたわけではない。読むときは「この座標軸は便利だ」と受け取るのが正しく、「この座標軸が正しいと示された」と受け取ってはいけない。私が本文で確認できた範囲では、家族ごとの長所と代償の記述も、実験値ではなく既存文献の読み込みに基づく評価である。

次に Fukai がここで指摘するのは、データセットの評価がまだ示されていないことだ。90時間・1280×720・30 FPS という規模と仕様は本文に明記されているが、そのデータで何かを学習させた結果や、既存データセットと比べてどう良いのかを示す実験は、私が読んだ範囲には見当たらなかった。データの入手方法やライセンスについても、本文からは確認できていない。役に立つかどうかは、これから誰かが使ってみて初めて分かる段階にある。

最後にもう一点。対象が『黒神話:悟空』のボス戦一種類である以上、ここから引ける結論は3D アクション RPG の戦闘という文脈に強く縛られる。著者らはボス戦を選んだ理由として、攻撃や回避といった相互作用が頻繁で、状態遷移が連続的で、一回が数分続くので長時間の生成の訓練と評価に向く、と説明しており、選択そのものは筋が通っている。ただしパズルや2D、あるいは時間がゆっくり流れるジャンルに同じ知見がそのまま移るとは、この論文は言っていない。私も言わないでおく。

Fukai の読み

ここからは私の解釈である。私はこの論文を、「生成 AI がゲームを飲み込む」という物語が一周して、ゲームエンジンという古い設計思想の側に評価軸が戻ってきた地点に置きたい。この2年、動画生成の進歩は「見た目が動く」ことを次々に達成してきた。しかしこの論文が四つの軸を並べて浮かび上がらせたのは、残った難所——結果の決定、画面外の保持、タイミングの正しさ——がすべて、エンジン設計者が半世紀近く前から「状態を持て」という一言で解いてきた問題だった、という構図だ。設計批評の語彙で言えば、これは表現の自動化がある水準まで来たあとで、規則の記述という別種の仕事が改めて可視化された、と読める。パズルを作る人間から見ると、この結論はほとんど痛快でさえある。私たちが盤面という小さな状態を手で書き続けてきたことは、遠回りではなかった、と読めるからだ。

おわりに

この論文は地図なので、地図の上の目印から先へ進むのがよい読み方だ。もし「動画生成をそのままゲームエンジンにする」路線の実物を見たいなら、論文が繰り返し参照している GameNGen(Valevski ら)、Oasis(Decart)、Genie 系(Bruce ら、Parker-Holder ら)あたりが起点になる。逆に「状態を明示的に持つ」路線に興味があるなら、フレームごとに状態注釈を付けた WildWorld(Li ら)や、毎ステップでキャラクターの属性を予測する AnimeGamer(Cheng ら)が、この論文の言う未開拓地の入り口にあたる。

パズル側から橋を架けるなら、盤面という明示的な状態を持ちながら生成を行う研究——たとえば制約充足やソルバでプレイ可能性を保証しつつレベルを作る系統——と読み比べると地図が立体になる。生成の自由さと規則の保証は、どちらかを選ぶ問題ではなく、どこに境界線を引くかの問題だ。この論文は、その境界線が今どのあたりにあるかを教えてくれる。参考文献は下にまとめた。

参考文献

本記事で参照した論文と関連資料:

・From Pixels to States: Rethinking Interactive World Models as Game Engines (Zhen Li, Zian Meng, Shuwei Shi, Mingliang Zhai, Jiaming Tan, Chuanhao Li, Kaipeng Zhang, 2026, arXiv preprint 2607.14076)

・論文 HTML 版(全文)

・関連研究: Diffusion Models Are Real-Time Game Engines / GameNGen (Valevski et al., 2024)

・関連研究: Genie: Generative Interactive Environments (Bruce et al., 2024)

・関連研究: World Models (Ha & Schmidhuber, 2018)

・本文中で言及されている作品: 『黒神話:悟空』(Game Science, 2024)