miHoYoが大学と共同でGameScalingをオープンソース化：ゲームAIは「コンテンツ生成」から「リアルタイム意思決定」へ#

皆さんこんにちは、無辺です。10月22日、国内ゲームAI業界で一つのニュースが話題を席巻しました。miHoYo崩壊AI研究開発チームが、清華大学、北京大学、中国科学院大学、香港大学、シンガポール国立大学と共同で、ゲームモデル「GameScaling」シリーズを正式に発表し、オープンソース化したのです。これは「AIがアセットを生成してくれる」ツールでも、「AIがシナリオを書いてくれる」パイプラインでもありません。ゲーム画面を見た後、直接キーボードとマウスを操作してくれるモデルなのです。

ゲームAIの応用を長年追いかけている者として、この種の「行動意思決定」モデルを見たとき、私はまず3つの点を確認します。パラメータ規模のラインナップ、デプロイのハードル、オープンソースライセンスの3つです。この3項目が、それが「論文デモ」なのか「他の人が本当に使えるもの」なのかを決めます。この3点を確認した結果、少なくとも一見したところでは3つすべてクリアしていたため、本格的な解説記事を書くことにしました。ラインナップは0.8Bから27B、小規模モデルはシングルGPUでデプロイ可能、コードと重みはどちらもApache 2.0ライセンスで公開されているからです。

まず事実の範囲を明確にしておきます。本稿の具体的な事実（パラメータ規模、レイテンシデータ、学習設定、ライセンス条項）はすべて、今回検証済みのファクトカードに基づいており、情報源は公式論文とリポジトリについての複数メディアの報道のクロスチェックです。うちパフォーマンスデータはすべて論文の数値であり、現時点で独立した第三者による再検証レポートは存在しません。本文では逐一その旨を記載します。また、付随する論文《Scaling in Games: Continued Pre-Training for Embodied Agents in Diverse Virtual Worlds》は10月20日にプレプリントプラットフォームarXivに掲載されており、番号は2610.28698です。原文を確認したい読者はご自身で検索してください。

一、出来事の概要：誰が、何を、どこでオープンソース化したのか#

まず出来事の骨格を整理します。今回のオープンソース化の主体は「1社のメーカーと5つの大学」です。miHoYo崩壊AI研究開発チームが主導し、清華大学、北京大学、中国科学院大学、香港大学、シンガポール国立大学が参加しました。成果物はGameScalingシリーズのゲームモデルで、付随する論文は10月20日にarXivに掲載され、オープンソース化のニュースは10月22日に国内テックメディアで広く報道されました。

注目すべき詳細がいくつかあります。第一に、GitHubリポジトリはTHUSI-Labという組織名の下に置かれており、Hugging Faceでも同じくTHUSI-Lab名義で公開され、プロジェクトページはgamescaling.github.ioです。3つの入口が揃っており、検索も容易です。第二に、ニュースは10月22日に集中して報道されました。これは論文公開の2日後で、この「先に論文、後に拡散」というペースは学術共同プロジェクトではよく見られるものです。第三に、「崩壊AI研究開発チーム」という署名は、これがmiHoYo社内で製品ラインを直接支えるAIチームによるものであり、対外的なブランド研究部門ではないことを示しています。ただし、チームの具体的な責任者や規模については、公式からは開示されていません。

二、モデルファミリー：8つのチェックポイントでスケーリング実験を一気に完了#

GameScalingは単一のモデルではなく、ファミリーです。0.8B、2B、9B、27Bの4つのパラメータ規模があり、各規模にS1とS3の2バージョンが存在し、合計8つのオープンソースチェックポイントがあります。すべてのバージョンは1600時間のゲームデータで学習されています。

この命名は分解して読む必要があります。S1とS3の違いは学習データの配合だけです。S1は《マインクラフト》データのみで学習され、S3は複数ゲームの混合データで学習されており、そのうち《マインクラフト》の割合は27%です。言い換えれば、どのパラメータ規模においても、S1とS3は天然の対照群です。前者は「単一の世界で極限まで鍛えるとどうなるか」に答え、後者は「多様なデータを混ぜるとどうなるか」に答えます。すべてのバージョンは統一して1600時間の学習データを使用しており、データ量という変数は固定され、残りの差はすべてデータ配合とパラメータ規模に由来します。

実験の皿をさらに深く覗くと、数字はもっと桁外れになります。混合比率には5種類の配合があり、これらの配合の背後には80タイトルのゲームからなるデータユニバースがあります。プロジェクト全体では120組の学習構成が実行され、データ予算は50時間から1600時間まで6段階に分けられ、総学習量は2.2×10^22 FLOPsに達しました。これはもはや「1つのモデルを学習する」規模ではなく、「スケーリングカーブを体系的に一通りスキャンする」規模です。論文タイトルにあるScaling（スケーリング）という言葉は、まさにこの仕事が「データ量、データ多様性、モデル規模」という3つの因子を実験変数として段階的にフィッティングしたことを指しています。この点は第6節のスケーリング則の結論で改めて展開します。

実験を再現したい読者にとって、この「段階 × 配合」のマトリクスは、すぐに使える実験デザインを提供しています。「多様なデータは役に立つか」という問いは、9B-S1と9B-S3の間で直接対照実験ができます。「規模は役に立つか」という問いは、0.8Bから27Bまでの同一配合バージョン間で対照実験ができます。変数がそれぞれ分離され、チェックポイントがすべて揃い、各バージョンは統一して1600時間のデータを使用しています。このオープンソースマトリクス自体が、論文のスケーリング実験に付随する実験材料なのです。これこそが、私が「また大規模モデルがオープンソース化された」以上に書く価値があると考えた理由です。オープンソース化されたのは、すでに敷かれた実験台一式なのです。

三、技術アプローチの解説：「画像を見て話す」から「画像を見て操作する」へ#

GameScalingの技術アプローチは一言で要約できます。画像を見られる土台の上に、「操作付きの録画」で行動の仕方を教え込む。分解すると3層になります。

土台：Qwen3.5視覚言語モデルをベースに継続事前学習を行っています。視覚言語モデルを土台に選んだのは偶然ではありません。この種のモデルはもともと画像を意味理解に変換する能力を持っており、GameScalingが行うのは、「画像の理解」に「操作の出力」という糸を接続することなのです。

データ形式：学習データはキーボード/マウス操作付きのゲームプレイ録画です。つまり、各データには「画面がどう見えるか」だけでなく、「この瞬間に人間の手が何を押していたか」も含まれています。これがこのアプローチ全体で最も重要なトレードオフです。ゲームエンジンの内部インターフェース（座標の直接読み取りや移動命令の直接発行など）を使わず、モデルに人間の手が実際に行うこと、どのキーを押すか、マウスをどちらに動かすか、ホイールをいつ回すかを学習させるのです。

入力と出力：モデルの各ステップの入力は、現在の画面、それ以前の一部の画面、およびそれまでの操作履歴です。出力は、キャラクターの行動を制御するための後続のキーボード・マウス操作命令そのものです。間に「まず計画し、それを命令に翻訳する」というモジュールは一切ありません。出力されるのは操作そのものです。

操作の粒度は、このモデルで特に単独で語る価値のある設計です。モデルは1回の呼び出しで約200ミリ秒の操作シーケンスを生成します。これには33ミリ秒持続する6つの操作ステップと、マウス移動およびホイール命令が含まれます。この粒度は何を意味するのでしょうか。33ミリ秒ごとのミクロな操作は、「リコイル制御でマウスを下に軽く引く」「回避フレームで回避ボタンを一度押す」といった連続的な微操作をすでにカバーしています。一方、多くの大規模モデルAgentの操作粒度は「ここをクリック」「あそこへ行け」といったレベルの意味的命令であり、両者の間には「手応え」という次元が丸ごと横たわっています。GameScalingは粒度をミリ秒レベルまで圧縮することで、本質的に人間プレイヤーの操作帯域幅に迫ろうとしているのです。

3.1 1回の推論ループの完全な流れ#

上記の数値を時間順につなげると、GameScalingが1台のマシン上で動作している様子が見えてきます。この閉ループは5ステップに分かれます。

1. 観察：ゲームが1フレームの画面をレンダリングし、それ以前の一部の画面とともに視覚入力としてモデルに送られます。同時に、それまでの操作履歴も入力されます。モデルは自分が前の拍で何を押したかを知らなければ、次の拍をどうつなぐかを決められません。
2. 意思決定：モデルはQwen3.5土台の視覚理解に基づいて、現在の状況を判断します。論文の数値では1ステップのレイテンシは0.13〜0.69秒で、このレイテンシがステップ2の所要時間のすべてです。
3. 出力：モデルは一度に約200ミリ秒の操作シーケンスを出力します。33ミリ秒持続する6つのキーボード/マウス操作ステップに、マウス移動とホイール命令を加えたものです。
4. 実行：操作解析コードがこの命令列を実際のキーボード・マウスイベントに変換し、ゲームに注入します。キャラクターはそれに応じて移動、攻撃、クラフト、回避を行います。
5. ループ：操作によって画面が変化し、新しいフレームと新しい操作履歴が次の推論ラウンドに入ります。これを繰り返すことで、モデルはゲームの中で「生きる」ことになります。

ステップ2とステップ3の時間収支を対照すると、より明確に見えます。1ステップのレイテンシは最速0.13秒であり、一方、各回の出力する操作シーケンスは約200ミリ秒のゲーム時間を賄えます。推論速度と操作消費がほぼ噛み合っており、このパイプラインが途切れることなく回り続けられるのです。これこそが第2節で「シングルGPUでのデプロイがこのアプローチの生存条件である」と強調した理由です。どれか1ステップでも遅くなると、チェーンにはゲームがモデルを待つアイドル状態が発生し、リアルタイム性が崩壊します。

四、デプロイのハードル：シングルGPUで動くことがリアルタイムの前提#

この節はハードウェア読者が最も関心を持つ部分です。公式が示すデプロイの数値は次の通りです。0.8B、2B、9Bの3バージョンの重みはいずれもシングルGPUにデプロイ可能で、うち9Bの重みは18.8GBです。27Bバージョンは2枚のGPUによるテンソル並列が必要で、重みは54.7GBです。同時に、モデルはvLLMによるモデルサービングのデプロイに対応しています。

この数字をどう読むか。第一に、0.8Bから9BまですべてシングルGPUで動くということは、実験に使いたい研究者や開発者がデータセンターの割り当てを申請する必要がないということです。18.8GBの重みが載るカード1枚に、vLLMによるサービングデプロイの経路を加えれば、推論を実行できる出発点になります。vLLMという推論フレームワークはコミュニティですでに非常に成熟しており、「モデルをどうサービス化するか」というエンジニアリングの問題を直接回避できます。

第二に、リポジトリには重みだけが置かれているわけではありません。公式の説明によれば、リポジトリには推論クライアント、システムプロンプトテンプレート、操作解析コード、サンプルプログラムが提供されています。この4つを組み合わせると、「重みをダウンロードする」から「モデルがあなたのマシンで実際にキーを打ち始める」までのすべての接着剤になります。特に「操作解析コード」は、モデルが出力する命令を実際のキーボード・マウスイベントに変換する役割を担っており、この種のコードは一見地味ですが、自分で書いてみて初めて落とし穴の多さがわかります。オープンソースプロジェクトにとって、この接着剤を一緒に出すことは、重みそのものよりもオープンソースの誠意を物語っています。

第三に、私がAI研究者として最も重視する点です。リアルタイム性はシングルGPUデプロイの下流の利益です。モデルは200ミリ秒ごとに操作を出す必要があり、その推論レイテンシはゲームのテンポと同程度に抑えられなければなりません。これは本質的に「4枚のカードからスタート」という重いデプロイを排除します。言い換えれば、0.8Bから9Bまでのラインナップ設計は単なるコスト削減のためではなく、この技術アプローチ自体の生存条件なのです。

五、最もドラマチックなデータ：ポーズ制とリアルタイム制のスコア逆転#

このモデルの存在意義を理解するために1組のデータだけを見るとすれば、私は論文中の「ポーズ制」と「リアルタイム制」の比較を選びます。まずレイテンシを見てください。GameScalingの1ステップのレイテンシは0.13〜0.69秒ですが、最先端モデルは1ステップに4〜24秒かかります。1桁以上の差があります。

次に2つの制の下でのスコアを見てください（論文の数値）：

このデータの読み方は、数字そのものより重要です。ポーズ制では、最先端モデルは54〜88.7点を取り、GameScaling-9B-S3の44.7点を明確に上回っています。不思議ではありません。最先端モデルは知的能力が高く、時間を与えられればより良い戦略を考え出せるからです。しかし、制がリアルタイムに切り替わると、画面はポーズせず、各ステップに与えられるのは0.数秒の窓口だけです。最先端モデルのスコアは5.3〜8.7点まで崩落し、一方GameScalingは36.7点を維持しました。順位が完全に逆転したのです。

これこそ私の言う「問題が解ける能力」と「リアルタイムでキーを打てる能力」は別物だということです。最先端モデルは答案用紙では高得点を取れるが、操作台に立つと手が追いつかない選手のようなものです。GameScalingは紙の上の知力では一歩譲りますが、アーキテクチャから粒度まで「画面を見て、操作を出す」というリアルタイムループのために設計されています。ゲームはまさにリアルタイム環境であり、ゲームはあなたの推論が終わるのを待ってポーズしてくれません。このスコア逆転こそ、この論文の中で業界に対して最も説得力のある論拠です。

正直に記載しておくべき点として、上記のスコアはすべて論文の数値であり、現時点で独立した第三者による再検証はありません。また、2Bクラスおよび各規模の他のベンチマークにおける完全な内訳スコア表も今回入手できなかったため、ここで補完や推算は行いません。

六、評価マトリクスとスケーリング則：4つの結論はすべて「多様性」を指す#

評価は4つのベンチマークをカバーしています。MCU（《マインクラフト》の30タスク）、ViZDoom（《DOOM》を題材にした戦闘と経路探索の評価）、OmniGameArena（学習時に未見の7つの3Dワールド）、GameWorld（2D/2.5Dゲームが中心）です。具体的なタスクは、《マインクラフト》の採掘、アイテムのクラフト、ゾンビとの戦闘から、密室シーンのパズル解きと脱出まで、サバイバル収集からアクションバトルまで幅広くカバーしています。

論文の核心的貢献の一つは、「データ量、データ多様性、モデル規模」という3つの因子を一本のスケーリング則にフィッティングし、検証損失のR²が0.98〜0.996に達したことです。かなりきれいにフィットしています。この曲線から読み取れるいくつかの結論は、実務者なら一つひとつ覚えておく価値があると私は考えます。

1. データが多いほど、同種の世界での性能が良くなる。 これは最も直感に合う結論であり、スケーリング実験が成立する基盤でもあります。
2. 多様性は「近い世界」を引き上げるが、差が大きい世界への向上は限定的。 つまり、混合データで買えるのは「近傍転移」であって「万能な汎化」ではない。《マインクラフト》で鍛えた採集ロジックは、別のサンドボックスゲームへの立ち上がりを速くする助けになるかもしれないが、格闘ゲームを戦う助けにはならない。
3. モデルが大きいほどデータを節約できる。しかし単一の世界しか学習していない場合、大きいほど転移はむしろ悪化する。 これは「大規模モデルを積み上げればよい」という素朴な楽観に対する一つの警告です。単一世界に過学習した大規模モデルは、見知らぬ世界に行くとむしろパフォーマンスが悪化する。
4. テスト時スケーリングも同様に有効。 推論時のステップ数上限を600から3000に引き上げると、9Bバージョンのスコアは50.9%から69.3%に、0.8Bバージョンは42.3%から59.3%に上昇しました。再学習せず、意思決定のステップ数を増やすだけで、成績が大幅に向上するのです。

そして、この比較群の中で最も目を引く数字は、継続事前学習を行っていないQwen3.5-9Bの土台が、同じ評価で2%から4%までしか伸びなかったことです。画像を見られる土台モデルは、ゲームをまったくプレイできません。成績を一桁から五六十以上に引き上げたのは、まさにあの1600時間の操作付き録画データなのです。この対照は、「継続事前学習」という工程の価値をしっかりと固定しています。

4つの結論を第2節の実験デザインに戻して読むと、さらにもう一つの含意が読み取れます。「単一の世界しか学習していないと転移が悪化する」のであれば、汎化が求められるシーンでは8つのチェックポイントの中でS3を優先的に選ぶべきです。「多様性の転移半径には限界がある」のであれば、S3の混合データにおける27%の《マインクラフト》の割合と、残り73%の複数ゲームの配合は、本質的に「近い世界」のために確保された転移の燃料です。チェックポイントの命名がS1とS3に分けて示されているのは、利用者に「この2つのバージョンは同じ問題に答えているのではない」と思い出させるためです。

もう一つ、対照的に見る価値のあるエンジニアリングの詳細があります。リポジトリが提供するシステムプロンプトテンプレートです。行動意思決定モデルの出力形式はチャットモデルとは異なります。出力すべきは一節の文章ではなく、構造化された操作命令の列です。システムプロンプトテンプレートはモデルがどのフォーマットで操作を出力するかを規定し、操作解析コードはそのフォーマットに従って受け取ります。この2つのファイルを合わせると、「モデル出力プロトコル」も一緒にオープンソース化されたことになります。第三者が統合を行う際に出力サンプルを相手にフォーマットを推測する必要がなく、これは推論側のエンジニアリングが完全であることのもう一つの証左です。

七、オープンソースの範囲：何が与えられ、何が与えられないか#

オープンソースライセンスの面では、コードとモデル重みはいずれもApache 2.0ライセンスを採用しています。これは現行の主流オープンソースライセンスの中で最も制約が緩い部類であり、研究者が二次研究に使うのも、開発者が統合検証のベースにするのも、ライセンス面での障害はありません。

しかし、オープンソースの範囲には明確な境界があります。学習コードと学習コーパスはモデルと共に公開されていません。つまり、あなたが手に入れられるのは「学習が完了した完成品」と「完成品を使用するためのツール一式」（推論クライアント、システムプロンプトテンプレート、操作解析コード、サンプルプログラム）であって、「このモデルをゼロから学習させたプロセス」ではありません。業界用語で一言でまとめると、結果は再現できるが、プロセスは再現できない。この土台の上でさらに前へ進みたい研究者にとって、これは2つのことを意味します。既存の重みに対するファインチューニング、評価、アプリケーション開発は可能です。しかし、学習パイプラインを再構築したい、あるいは5種類の配合と120組の構成の中の特定の曲線を検証したい場合、元データが手に入らない以上、そこで足止めになります。

もう一つ注目すべき声明がプロジェクトページから出ています。プロジェクトは「純粋な研究プロジェクトであり、いかなる商業活動も行わない」と明記し、対戦画面は研究結果の展示にのみ使用され、ゲーム画面の著作権は各パブリッシャーに帰属するとされています。この声明をApache 2.0の緩やかなライセンスと併せて読むと、境界は実に明確です。モデル自体は緩やかなライセンスで公開されているが、学習時に「見た」ゲームコンテンツはプロジェクト側のものではない。プロジェクト側自身も商業化を行わない。この制約群が後続の利用者にとって何を意味するかは、各ゲームパブリッシャーの権利境界に関わるため、本稿では断定しません。興味のある読者は、ライセンス原文とプロジェクトページの声明を併せてご自身で判断されることをお勧めします。

八、2つの路線の分岐：行動意思決定モデル vs ワールドモデル#

ここまで書いたところで、GameScalingをゲームAIの大きな地図の中に位置づける必要があります。ここ2年のゲームAIの賑わいは、基本的に互いに独立した2つの路線に集中しており、今回のGameScalingはまさにそのうちの1つの路線の重要なサンプルです。

第一の路線：コンテンツ生成路線。 この路線のモデルが引き受けるのは「ゲームコンテンツはどこから来るか」です。画像の生成、レベルの生成、さらにはゲーム世界全体をリアルタイムでレンダリングすることまで行います。以前このサイトで解説した崑崙万維のMatrix-Game 4.0は、まさにこの路線の代表です。モデル自体がプレイ可能なゲーム画面を生成し、プレイヤーはそのフレームごとに生成された画面の中で遊びます。興味のある読者はあのワールドモデルの解説を併せてご覧ください。

第二の路線：リアルタイム行動意思決定路線。 この路線のモデルはゲームエンジンに触れず、いかなる画面も生成しません。ゲームは元のゲームのままであり、モデルが演じるのは「プレイヤーの座」です。画面を見、対策を考え、操作を出す。GameScalingはまさに第二の路線の典型です。入力は画面と操作履歴、出力はキーボード・マウス命令であり、ゲーム世界自体は1フレームも変更されていません。

2つの路線は競争関係ではなく、分業関係です。一方は「ゲームコンテンツを誰が作るか」を解決し、もう一方は「ゲーム内の行動を誰が演じるか」を解決します。プレイヤーの体験に落とすと、前者は「ゲーム世界はどこから来るか」を決め、後者は「あなたと同じフィールドで戦い、あるいは共に戦うあのエージェントが人間らしく見えるか」を決めます。興味深いことに、2つの路線とも「コンシューマーハードウェアで動く」ことを2026年下半期の軍拡競争の焦点に据えています。今回GameScalingは小規模クラスをシングルGPUでデプロイ可能にし、まさに同じ方向を進んでいます。2つの路線が将来ある製品の中で