昆侖万維が Matrix-Game 4.0 をオープンソース化：RTX 5090 1枚で 60fps を実現するワールドモデルゲームを徹底解説#

皆さんこんにちは、紫星です。2026年10月15日、昆侖万維（AI事業の中核はSkywork AI、上場コード300418）は Matrix-Game 4.0 を正式発表し、同時にオープンソース化しました。公式の説明はかなり長いのですが、要約すると「コンシューマー向けGPU 1枚で動作する初の動画大規模モデルゲーム」ということになります。分解してみると、この一文には3つのキーワードが含まれています。「動画大規模モデル」は映像の供給源が従来のレンダリングパイプラインではなく生成モデルであることを示し、「ゲーム」はインタラクティブに操作できることを、「コンシューマー向けGPU 1枚」はハードウェアユーザーにとって最も重みのある言葉です。

この1年、ワールドモデル関連のデモは数多く見てきましたが、そのほとんどは2つの形態にとどまっていました。データセンターのマルチGPUクラスタ上で動くものか、見ることはできても遊べない動画生成か。今回の発表が解説記事に値するのは、「リアルタイムで遊べる」ことと「コンシューマー向けGPU 1枚」を同時に実現した点です。公式スペックによれば、NVIDIA RTX 5090 1枚で 480p・60FPS でゲームが動作します。この数字の組み合わせが何を意味し、その裏にどのようなエンジニアリングがあるのか。それが本稿で答えるべき核心的な問いです。

先に事実の範囲を明示しておきます。本稿の具体的な事実（性能数値、アーキテクチャの分担、オープンソースの範囲、時期）はすべて、今回検証済みのファクトカードに基づいています。性能データはすべて企業公表値であり、独立した第三者による再検証はまだありません。本文では出典の属性を逐一明記します。公式が未公開の部分について推測で埋めることはしません。また、サイト内での位置づけも説明しておきます。以前解説した Google Playground × Unity Spark は「プロンプトでコンテンツアセットを生成する」プラットフォーム型の路線でしたが、Matrix-Game 4.0 は「ワールドモデルがゲーム画面全体をリアルタイムにレンダリングする」ものであり、技術的にはまったく別の存在です。本稿の課題は、後者のアーキテクチャとハードウェア面の勘定を明らかにすることです。

一、公式性能スペック：まず数字を並べる#

ハードウェア解説の慣例に従い、まずすべての数字を並べた上で意味を考えます。Matrix-Game 4.0 の公式性能スペックは以下の通りです。

1.1 項目別に読み解く：各数字の裏にあるもの#

480p / 60FPS：これはシステム全体の目標動作形態です。解像度が480pにとどまっているのは、映像生成の解像度こそがこの技術をリアルタイム化するためにまず支払わなければならない代償であることを示しています。60FPSは「遊べる」ためのフレームレートの最低ラインで、これを下回ると操作のフィードバックが明らかに重くなります。両者を合わせて読むと、フレームレートは先に基準を満たし、画質は今後のバージョンで追い上げるという姿勢が見えてきます。

エンドツーエンド遅延150ミリ秒未満：基準はプレイヤーのキー入力から画面の最初のフレームが応答するまでです。参考までに、主要な対戦型オンラインゲームのサーバー往復遅延も通常このオーダー内にあるため、「画面を完全にフレームごとに生成するシステム」としては許容できる出発点と言えます。ただし、従来のゲームエンジンの「入力したそのフレームで応答する」操作感にはまだ隔たりがあります。この体験の差については現時点で引用できるレビュー報告がなく、今後の実測に委ねるしかありません。

1ステップデノイズ83FPS / 2ステップデノイズ約57FPS：2つの数字は異なるデノイズステップ数の構成に対応する定常生成速度です。少ステップのデノイズこそが、フレームレートを60FPSに到達させる直接の前提条件です。デノイズステップ数が多いほど画面は精細になりますが、1フレームあたりの計算コストも増大します。これは本質的なトレードオフであり、公式が2組のデータを同時に提示したのは、このトレードオフを表に打ち出したと解釈できます。

VRAMピーク値18.5GiB：ハードウェアユーザーにとって最も重要な数字であり、第3節で詳しく扱います。

1.2 2種類のデータは分けて語るべき#

最初の5項目は発表資料とメディアの転載によるもので、すべて企業公表値です。中国経済網、中証網、南方都市報の報道はいずれも同一のデータを引用していますが、執筆時点で独立した第三者による再検証は行われていません。6項目目はGitHubリポジトリのドキュメントにある実測データです。A100 80GB 上、864×480解像度、1ステップデノイズ構成において、シューティングシーンのモデル処理速度は約38〜39FPS。レーシングシーンのオンラインサーバー側パイプラインは、固定プロンプトで約38.5FPS、動的入力で約28.9FPSでした。

注目すべきは、リポジトリデータにおける「オンラインサーバー側パイプライン」という表現です。これはA100上で動作しているのがサーバー側パイプラインの形態であり、ローカルのRTX 5090上で特別に最適化された推論パスとは同じデプロイ条件ではないことを意味します。したがって、2組の数字を直接換算して比較することはできません。「ベンチマーク」に慣れた読者への私の提案は、60FPS / 150ミリ秒未満 / 18.5GiB の一組の数字を「公式が宣言する目標動作形態」と捉え、A100の38〜39FPSを「リポジトリドキュメントが示すサーバー側の参照値」と捉えることです。両者の検証には、より多くの実測報告を待つ必要があります。補足として、AI IDE List の分析記事では一部のテストで遅延が約112ミリ秒と報じられていますが、これは非公式の数字であり、本稿では記録するのみで結論とはしません。

二、3層アーキテクチャ：コードがルールを担い、エンジンが状態を維持し、動画モデルが映像を生成する#

Matrix-Game 4.0 のアーキテクチャは3層で構成され、公式の要約は非常に整然としています。コードがルールを担い、エンジンが状態を維持し、動画モデルが視覚表現を生成する、というものです。

2.1 技術的クローズドループ：3層はどう噛み合うのか#

公式はこの一連の流れを「技術的クローズドループ」と定義しています。コードがゲームロジックを生成し、構造化画面が構造的制約を提供し、動画モデルがリアルタイムにレンダリングする。公式の説明によれば、このクローズドループが完全に動作したのは初めてであり、ゲームプロトタイプ開発、パーソナライズされたカスタマイズ、UGCに対して実装可能な技術的パスを提供するものです。

クローズドループを実行順序に展開するとより直感的に理解できます。

1. プログラミングエージェントがゲームのルールをコードとして記述する。コードこそがゲームプレイの担い手である；
2. エンジンがそのコードをロードし、実行時にワールドの状態を維持し、インタラクションのルールを実行しながら、動画モデルへ構造化画面と動的セマンティック条件を出力する；
3. 動画モデルが基礎的な幾何情報を受け取り、それを視覚化されたリアルタイム画面へ変換する；
4. プレイヤーの入力がエンジンとコード層に戻って判定され、判定結果が再び第2・第3ステップを通る。この繰り返しによってゲームは連続的に動作し続ける。

2.2 状態と画面の分離：このアーキテクチャで最も価値のある設計#

3層がそれぞれの役割を果たす鍵は、エンジンの層にあります。従来の動画モデルによる画面生成は確率的なもので、同じフレームを2回生成すると結果が異なることがあります。もしゲームの状態（HP、位置、アイテム）もピクセルの中に隠されていたら、画面生成のわずかな瑕疵が「状態変化」として解釈される恐れがあります。これが純粋なピクセル型ワールドモデルに共通する状態ドリフト問題として知られるものです。

Matrix-Game 4.0 の解法は、状態を画面の外に取り出すことです。HP、所持アイテム、クエスト進行度などのゲーム状態はエンジンのコードに明示的に記録され、偶発的な画面生成の瑕疵がゲーム状態を書き換えることはありません。QbitAIが報じたデモの詳細はこの点をよく示しています。盾を拾うと先にダメージを吸収し、HPがゼロになるとゲームオーバーになる。判定はエンジンのルール層で発生し、画面はその判定結果を描いているだけです。画面は時々間違えて描いても、ルールはそれに従って間違わない。

この発想は、AIとゲームエンジニアリングの交差点に関心を持つ読者には見覚えがあるはずです。私たちは以前、AIエージェントが3ヶ月で『モダン・ウォーフェア2』のソースコードを再構築した 事例を解説しましたが、あれは複数エージェントが従来型のコードを書く路線でした。Google Playground がカスタムオーケストレーション層で「遊べて、再現できる」ことを解決したのも、本質的には確率的な出力を決定論的な構造へ収束させる試みです。Matrix-Game 4.0 の特異性は、「エンジン」という言葉を従来のゲームエンジンに譲らず、エンジンを状態の調停と構造出力に専念させ、画面全体を動画モデルに外注した点にあります。ルールと画面の分離こそ、このアーキテクチャで最も記憶に値する設計上の決定です。

三、RTX 5090 1枚のエンジニアリング：VRAM、遅延、最適化リスト#

3.1 VRAMピーク値18.5GiBが意味するもの#

ハードウェア読者にとって、これは本稿全体で最も重要な数字です。18.5GiBというVRAMピーク値は、32GBのVRAMを持つRTX 5090と比較すると、実行時にまだ余裕があることを意味します。重み、履歴フレームのキャッシュ、推論の中間状態を合わせてもVRAMを使い切っていないのです。

一方、公式は来週、RTX 5080 と RTX 5070 をサポートするバージョンを公開すると予告しています。これらのカードはVRAMがさらに少なく、同じモデルを収めるには最適化の圧力が5090より明らかに大きくなります。これこそが、この技術が主流GPUへさらに降りていけるかを判断する最初の観察ポイントです。VRAMピーク値をさらに圧縮できるかどうか。圧縮できなければ、降下の路線は5090で止まります。圧縮できれば、「コンシューマー向けGPU 1枚」という限定句は次第に限定の意味を失っていくでしょう。

3.2 同日公開された推論最適化リスト#

公式は10月15日、同日にRTX 5090専用の推論最適化を公開しました。リストは以下の通りです。

この4項目はいずれも推論デプロイ側の成熟したエンジニアリング手法です。公式がこれらを5090専用最適化として同日に公開したことは、「コンシューマー向けGPU 1枚でのリアルタイム実行」がモデル自体の能力ではなく、モデルと推論エンジニアリングの共同成果であることを示しています。モデルが下限を決め、デプロイの最適化がリアルタイムのラインに届くかどうかを決めるのです。1ステップデノイズの定常速度83FPSとゲーム実行の60FPSが同時に基準を満たせたのは、まさにこの層のおかげです。

3.3 遅延の基準とコスト構造の対比#

遅延について、公式の基準はキー入力から画面の最初のフレームが応答するまで150ミリ秒未満です。第1節でオーダーの判断は済ませたので、ここでは位置づけを一言補います。完全に生成型の画面を持つシステムとしては、この数字は合格点の出発点です。操作感を追求するプレイヤーにとっては、継続的に最適化すべき長いマラソンの起点です。

もう一つ、コスト面の対比も書き留めておく価値があります。同様にAI駆動のオープンワールド体験を作る場合、TaipeiGTAの解説 が示すように、あの形態はオンラインサーバー側の継続的な推論に依存し、コストはオンライン規模に応じて積み上がります。Matrix-Game 4.0 は推論をローカルの1枚のGPUに移し、コスト構造を「人数に応じて支払うサーバー請求書」から「一度購入するGPU」へ変えました。リポジトリドキュメントでA100のレーシングシーンに「オンラインサーバー側パイプライン」と注記されていることは、サーバー側形態が依然存在することを示しています。2つのデプロイ形態が併存する場合、ローカル1枚のGPU方式がエンドユーザーにとって意味するのは、継続的な推論コストからの解放です。これはワールドモデルゲームの商用化パスにとって実質的な差異であり、「オープンソース＋ローカル実行」という組み合わせが単なる技術デモよりも重視されるべき理由でもあります。

四、学習パイプライン：Unreal Engine 5 のデータペアと Wan2.2 5B の改造#

画面モデルがどのように訓練されたのか、公式とリポジトリドキュメントが明かした経路はかなり明確で、3ステップに分けて記録します。

4.1 データペア：構造化画面と精細画面の結合#

第1ステップはデータです。Unreal Engine 5 で「構造化画面—精細画面」のデータペアを作成し、可視オブジェクトとその状態を記述する動的セマンティックアノテーションを併用します。この設計はアーキテクチャ層の分担に対応しています。構造化画面はエンジンが出力する幾何とセマンティクスの骨格であり、精細画面は最終的なレンダリング結果です。動画モデルが訓練で学ぶのは、まさに「構造的制約から精細画面へのマッピング」です。これが、推論時にエンジンが出力する構造化画面が動画モデルを制約できる理由も説明しています。両者は訓練の時点でデータペアとして結合されていたからです。

4.2 ベース：Wan2.2 5B Fun Control の改造#

第2ステップはベースの改造です。動画モデルは Wan2.2 5B Fun Control をベースに改造され、因果的な少ステップ生成を採用しています。少ステップのデノイズこそが、フレームレートを60FPSに到達させる直接の前提条件であり、公式が示した1ステップデノイズ83FPSと2ステップデノイズ約57FPSという2組のデータは、まさに異なるデノイズステップ数構成における定常速度に対応しています。因果生成の方向もインタラクティブなシーンと合致しています。ゲーム画面はすでに発生した過去のフレームにのみ依存でき、「未来のフレーム」が描き終わるのを待って埋め戻すことはできないからです。

4.3 時間的一貫性：空間メモリと履歴フレームのキャッシュ#

第3ステップは時間的一貫性です。空間メモリの参照画像とキャッシュされた履歴フレームを利用します。動画モデルがフレームごとに生成する際に最も失われやすいのは「前のフレームがどのような姿だったか」です。参照画像と履歴フレームのキャッシュは、モデルに継続的に見える記憶のアンカーを与えることに相当し、これもリアルタイムのストリーミングインタラクションに踏み切れる根拠の一つです。バージョン表に戻って3.0のキーワード「長期記憶」を見ると、この記憶の路線が一歩一歩今日まで歩んできたことが分かります。

3層アーキテクチャと学習パイプラインを合わせて見ると、システム全体の設計論理が高度に一貫していることが分かります。不確実で生成型の部分（画面）はすべて動画モデルの内部に限定され、確定性が必要な部分（ルール、状態、構造）はすべてコードとエンジンの中に残されています。学習パイプラインはモデルが構造的制約を尊重することを学ばせ、推論エンジニアリングはこのプロセスをリアルタイムに速くする役割を担うのです。

五、一行のプロンプトでゲームプレイを変える：能力と3種類のローンチシーン#

5.1 自然言語によるゲームプレイ改変はどう実装されているのか#

ゲームプレイの改変について、プログラミングエージェントを利用することで、ユーザーは自然言語でシーンを調整し、インタラクションを変更し、ゲームプレイを設計できます。公式は創作のハードルを「一行のプロンプト（Prompt）」という表現まで下げました。QbitAIが報じた2つのデモ事例：武器の射撃レートを上げるよう要求すると、実現できました。タイムトライアルをチェイスレースに変えることも、実現できました。

この2つの事例の性質に注目してください。一つは数値パラメータの変更であり、もう一つはゲームプレイモードの変更です。どちらも「コードがルールを担う」という層の管轄範囲内に収まっています。変更の実装経路はこうです。プログラミングエージェントがプロンプトをコードの変更に変え、エンジンが新しいルールを実行し、動画モデルが新しい画面を描く。画面層は最初から最後までルール判定に参加しておらず、これこそ第2節で述べた分離設計がゲームプレイ改変においてもたらす直接的な利益です。Meta Horizonツール のような「自然言語でゲームを生成する」経路はインタラクション形態がこれに似ていますが、Matrix-Game 4.0 の差異点は、静的な完成品を生成するのではなく、リアルタイムに動作しているワールドモデルゲームを改変している点にあります。

5.2 3種類のローンチシーンと能力のプロファイル#

ローンチコンテンツについて、リポジトリは3つのプレイ可能なシーンを提供しています。

シューティング2つとドライビング1つという構成は、現在の技術条件下でこのシステムが安定して支えられるゲームプレイタイプに対応しています。能力の限界も同様に明確です。解像度は480p、シーンはシングルプレイヤー体験、ゲームプレイのプロトタイプは3種類に限定される。これらが現行バージョンのプロファイルです。公式の位置づけもそのまま引用する価値があります。ゲームプロトタイプ開発、パーソナライズされたカスタマイズ、UGCへの技術的パスを提供するものであり、完成品ゲームの代替ではない、と。言い換えれば、現時点での正しい使い方は「インタラクティブなゲームプレイの下書き」と「一行のプロンプトでルールを変えられる実験場」であり、これを3Aタイトルの完成品と比較するのは現実的でも公平でもありません。

六、オープンソースの範囲と1年半で4世代の反復#

6.1 何がオープンソース化されたのか#

オープンソース化は、今回の発表の中でコミュニティにとって最も長期的な影響を持つ動きです。GitHubリポジトリの SkyworkAI/Matrix-Game には3つのものが公開されました。推論コード、ブラウザデモ、3つのプレイ可能なゲームのソースコードです。モデルの重みとゲームアセットはHugging Faceに置かれています。ライセンスについて、Matrix-Game 4.0 は Apache-2.0 を採用し、初期バージョンは MIT でした。一つ、表現の不一致をそのまま明記しておく必要があります。リポジトリのAbout欄に記載されたライセンスフィールドと、v4の説明ドキュメント内の Apache-2.0 との間に不一致があり、リポジトリ内のv4サブディレクトリのライセンスを正とし、サードパーティコンポーネントはそれぞれ独自のライセンスを持ちます。本稿の検索時点でのスナップショットデータとして、リポジトリのスター数は約2500で、参考までに。

6.2 バージョンの沿革：1年半で4回の反復#

バージョンの沿革を表にすると、この技術路線の推進リズムが見えてきます。

1年半で4回の反復、リズムは3ヶ月から7ヶ月に1世代です。1.0がオープンソースの基準線を確立し、2.0が「動かすこと」を解決し、3.0が「覚えていること」を解決し、4.0が「動かせること」を解決しました。各世代が先代が残した弱点を補っており、この反復の経路自体が、単一のデータポイントよりもチームのこの技術路線への継続的な投資を雄弁に物語っています。

6.3 オープンソースの組み合わせが持つベンチマーク的意義#

オープンソースの意義は、組み合わせの完全性にもあります。推論コード、ゲームのソースコード、重みの3つが揃い、商用に友好的な Apache-2.0 ライセンスが加わり、さらに「ゲームロジックがコードとして存在し、改変できる」という特性がある。コミュニティが手にするのは、見ることしかできないデモではなく、改造でき、スキンを交換でき、ベンチマークテストできる完全なツールチェーンです。ワールドモデルゲームという、まだ公認のベンチマークが存在しない新分野において、再現可能で比較可能な公共の参照系は、モデルそのものに匹敵する価値を持ちます。中証網が引用した業界分析も同様の判断を示しています。「制御可能な動画」から「実行可能なワールド」へ向かうことは、AIゲームのクリエイティブ生産のハードルを下げることに役立つ、と。

七、現実の隔たり：「本当に遊べる」まであとどれくらいか#

7.1 現行バージョンの硬い限界#

公式の主張をすべてそのまま提示した後、この節では冷静に隔たりを計算します。現行バージョンの硬い限界は4つあります。

1. 解像度が480pにとどまる；
2. シーンがシングルプレイヤー体験である；
3. ゲームプレイのプロトタイプが3種類（シューティング2つ、ドライビング1つ）に限定される；
4. 画面が動画モデルによるフレームごとの生成に完全に依存している。

最初の3つはプロダクト形態の限界であり、4つ目は技術原理の限界です。画面が生成型である限り、「画面に瑕疵があっても状態を書き換えない」という分離設計が保証できるのはゲームプレイ層の安定だけで、見た目の層の安定は保証できません。

7.2 公式のロードマップと限界の項目別対照#

公式が示した今後の路線は4つあり、上記の限界と項目別に対照できます。

4つの路線の中で、マルチプレイヤーの視点一貫性がこのアーキテクチャの出来栄えを最も試す項目です。生成品質を試すだけでなく、「状態の権威はエンジンにあり、画面は単なる投影である」という設計が、複数の観察者の間で自己整合性を保てるかどうかを試すものだからです。

7.3 未検証項目：現時点のすべての定量結論は利害関係者から出ている#

さらに、いくつかのことをそのまま明確にしておく必要があります。

• すべての性能数値（60FPS、150ミリ秒未満、83FPS、18.5GiB）は企業公表値であり、独立した第三者による再検証はありません；
• ブラウザデモの具体的な体験品質、画面の実際の見栄えについては、現時点で引用できるレビュー報告は一切ありません；
• 「コンシューマー向けGPU 1枚で動作する初の動画大規模モデルゲーム」という「初の」は企業の宣伝上の主張であり、第三者による認証は受けていません；
• AI IDE List が引用した一部のテストによる約112ミリ秒の遅延は非公式の数字です。

言い換えれば、現時点でこのシステムについて存在するすべての定量結論は利害関係者から出ているのです。だからこそ本稿では通篇でデータの出典を明記しています。独立した実測が現れるまで、これらの数字に対する正しい態度は「記録に残し、検証を待つ」ことです。

7.4 3層のプレイアビリティ・フレームワーク：今はどの段階に立っているのか#

では、「本当に遊べる」まであとどれくらいか。私のフレームワークは3層です。

1. インタラクティブ：操作でき、フィードバックがある。すでに実現している；
2. 安定して遊べる：フレームレートが基準を満たし、状態がドリフトせず、1セッションが完結する。公式の主張ではラインに達しているが、独立した検証待ち；
3. 長期にわたって遊べる：高解像度、マルチプレイヤー、豊富なゲームプレイ、継続的なコンテンツ。4つの路線はすべてここを指しているが、どれ一つとして容易な戦いではない。

このフレームワークで測ると、Matrix-Game 4.0 は第2層の敷居の上に立っており、第3層への道はまだ始まったばかりです。

八、紫星の判断#

この解説を