操作できる生成映像をゲームや対話型映画に使うなら、滑らかさだけでは使い心地を判断できない。
映像が毎秒24枚届いていても、いま押したボタンへの反応が遅れることはある。
RunwayのGWM Worlds 2を入口に、生成速度、操作への応答、世界の記憶を分けて考える。

発表で確認できること

Runwayは2026年9月3日、GWM Worlds 2を研究プレビューとして発表した。公表値は720p・24fpsの映像と48,000Hzの音声である。以下は公式資料の整理であり、筆者によるモデルの実測ではない。［1］

入力形式のWorldPromptは、世界の初期設定・最初の画像と、時刻付きの操作列を組み合わせる。操作には対象と開始・終了時刻があり、複数を重ねられる。カメラの移動も入力になる。

基盤の音声・映像モデルをこの形式へ適応させ、さらに双方向モデルから自己回帰型へ事後学習する。生成時には全体の設定、その時点の入力、直近の生成フレームを参照する。過去フレーム用のKVキャッシュはスライディングウィンドウで、古いフレームは外れる。音声・映像のデコーダも因果的に処理する。［1］

公開情報の限界

公式資料は、急なカメラ回転による画質や形状の劣化と、不完全な長期記憶を認めている。また、事前に操作列を用意する方式の方が、現在のリアルタイムデモより品質がよいと説明する。確認した発表本文には、入力から表示までの遅延分布や必要な計算機構成は示されていない。［1］

この公開範囲を踏まえ、ここからは対話型作品を設計する側の論点を整理する。

fpsは出口の流量を表す

24fpsを時間に直すと、1フレームの間隔は次のようになる。

1,000 ms ÷ 24 = 約41.7 ms / frame

この41.7msは、一定の速度でフレームが並ぶ場合の間隔だ。ボタンを押してから、その操作を反映した最初の絵が届くまでの時間ではない。

例えば、ある映像処理系が常に240ms分を先行してバッファにため、その後は41.7msごとに出力するとする。出口の映像は24fpsで滑らかに見える。それでも、新しい操作がバッファより後ろの生成にしか反映されなければ、手応えには待ち時間が生じる。

240msは説明用の仮定であり、GWM Worlds 2の測定値ではない。ここで示したいのは、出力の間隔と、入力が出口へ届くまでの時間を独立に測る必要性だ。

アプリケーション側で整理すると、操作はおおむね次の経路を通る。これは計測箇所を考えるための概念図であり、Runwayの内部構成を再現したものではない。

途中にLLMで台詞を作る処理を加えるなら、その待ち時間も入る。生成モデルだけを高速化しても、残りの区間は消えない。実装では処理が重なる場合もあるので、各部品の平均時間を足すだけでなく、同じ操作が経路全体を通った時間を追う。

三つの時計をそろえる

対話型映像では、少なくとも次の時間軸がある。

時間軸	何を表すか	混同すると起きること
入力時刻	利用者が操作した時点	受信した時点を起点にすると上りの待ち時間が抜ける
作品内の時刻	どの場面で行動を開始・終了させるか	一時停止や生成待ちを挟むと実時間とずれる
表示時刻	対応する映像が見える時点	生成終了だけを測ると配信・再生の待ち時間が抜ける

操作にIDを付け、生成側で受理した時点と、その操作を含めて生成したフレームを対応付けられると、原因を絞り込みやすい。ただし、入力に含めたことと、絵が指示どおり変わったことも別々に確認する必要がある。

全体の応答時間は、同じクライアントの単調時計を起点と終点に使って測る。サーバーの時刻も使って区間を分解する場合は、時計の同期方法と誤差を明記する。別々の機械の時刻をそのまま引き算しない。

例えば「照明を赤にする」という操作なら、まず操作IDとフレームの対応を記録する。次に、本当に赤い照明が現れた最初のフレームを確認する。前者は処理経路の確認、後者は指示の反映の確認になる。この仕組みを利用できるかは、接続するサービスや実装が公開する情報に依存する。

ブラウザ側の観測には、requestVideoFrameCallback()のメタデータが役立つ。WICGの仕様案には、表示予定のexpectedDisplayTime、合成へ渡したフレーム数のpresentedFrames、デコード周辺の処理時間を示すprocessingDurationなどが定義されている。WebRTCではreceiveTimeなどが得られる場合もある。コールバック自体は遅れたり、全フレームでは呼ばれなかったりする。［2］

expectedDisplayTimeを終点に使った遅延は推定値であり、ディスプレイの実表示を直接測った値ではない。コールバックの呼び出し回数だけでfpsを決めたり、processingDurationを生成モデルの推論時間と呼んだりもしない。ブラウザで観測できる範囲と、サーバー側の範囲を分けて記録する。

世界を覚える責任を決める

映像の整合性を試すなら、部屋に赤い箱を置き、いったん別の方向を見てから振り返る、という小さな場面でよい。

ただし、確認したい性質は複数ある。

箱の色や形が保たれるか。
箱が同じ位置に残るか。
箱に入れたアイテムを、後で取り出せるか。

最後の項目は、作品内のルールと履歴にも関わる。箱らしい映像が再登場しても、その中身の扱いまで正しいとは判断できない。

従来のゲームエンジンでも、画面の更新とシミュレーションの更新は区別される。例えばGodotは、可変頻度の_process()と固定頻度の_physics_process()を提供し、後者の既定値は毎秒60回である。描画fpsが変わっても、物理処理を同じ時間刻みで進めるための仕組みだ。これ自体が決定論的な再現を保証するわけではない。［3］

生成映像を使う作品でも、「どの事実を作品側で確定するか」を先に決められる。例えば、箱の中身やイベント達成条件は明示的な状態として保持し、それを使って次の演出を決める設計が考えられる。

その場合も、状態を保存するだけでは画面との一致は保証されない。状態上は空の箱なのに、映像にはアイテムが見えるかもしれない。不一致を許容する表現にするのか、場面を切り替えるのか、生成をやり直すのかまで作品側の判断になる。これは本稿の設計上の考察であり、GWM Worlds 2にその制御機能が実装されているという説明ではない。

操作の配送にも用途ごとの優先順位がある

視点の更新と、会話での選択肢確定は、同じ配送方法が適するとは限らない。

LiveKitのデータパケットには、順序付きで再送するReliableと、一度だけ送って順序も保証しないLossyがある。ただしReliableもベストエフォートで、切断中の相手への配送などを完全には保証しない。［4］

この違いを使うなら、例えば次のように判断する。

操作の意味	設計の例
最新の視点を知らせる絶対値	新しい更新で古いものを置き換え、受信側で順序番号を確認する
視点を少し回す相対変位	欠落すると結果がずれるので、絶対値への変換や補正を考える
会話の選択肢を確定する	操作ID、受理応答、重複の扱い、再接続後の状態確認を用意する

これは独自のアプリケーションを作る場合の設計例だ。GWM Worlds 2の操作APIや、デモ内部の配送方式を示すものではない。

試作で確かめたいこと

対話型映画なら、利用者が選択肢を確定した後に短い待機演出を挟むことで、速度の制約を作品のテンポに取り込める。一方、すばやい操作に反応する作品では、同じ待ち時間が体験を損ねる可能性がある。必要な応答時間は、用途ごとに決めたい。

試作を評価する際は、次の条件をそろえると比較しやすい。

滑らかさ：同じ再生時間で、表示間隔のばらつきと停止を記録する。
操作への反応：同じ種類の操作を複数回行い、入力から対応する絵までの中央値と95パーセンタイルを測る。無反応も失敗件数として残す。
場面の記憶：振り返り、遮蔽、離れて戻る操作を行い、対象と位置の維持を確認する。
作品のルール：取得済みの物や終了した会話が、後で矛盾した形で再登場しないか確認する。

これらの試験を本稿でGWM Worlds 2に対して実行したわけではない。公式資料を読む段階から、利用できる環境で試作を評価する段階へ進むための手順である。

生成映像を対話型作品へ組み込むときは、「何fpsで出るか」に加えて、「操作がいつ見えるか」「どの出来事を覚えている必要があるか」を要件として書く。その三つがそろうと、映像モデルに任せる表現と、作品側で管理する振る舞いを具体的に設計できる。

参考リンク

［1］Runway — Introducing GWM Worlds 2（2026年9月3日）

［2］WICG — HTMLVideoElement.requestVideoFrameCallback()（Draft Community Group Report、2024年8月2日。2026年9月8日確認）

［3］Godot Engine — Idle and Physics Processing（stable版ドキュメント、2026年9月8日確認）

［4］LiveKit — Data packets（2026年9月8日確認）