miHoYoの崩壊AI研究チームは、清華大学、中国科学院大学、香港大学などと共同で、キーボードとマウスの操作を直接出力するゲームエージェントモデル群GameScalingを発表した。論文は10月20日にarXivに掲載され、モデルの重みと推論クライアントはHugging FaceとGitHubで公開済み。ライセンスはApache-2.0となっている。
モデルはAlibabaの視覚言語モデルQwen3.5をベースに、キーボード・マウスの操作記録付きのゲーム動画で継続事前学習を行った。数フレームの画面を渡すと、次にどのキーを押し、マウスをどちらへ動かすかを返す。
操作のエンコード方式
モデルは1回の呼び出しで、この先200ミリ秒分の操作を出力する。これを33ミリ秒ごとの6ステップに分け、さらにその区間全体のマウス移動量とホイール量を加える。マウス移動量は千分率で表し、プラスマイナス1000以内に制限される。ホイールはプラスマイナス5までだ。1ステップで同時に押せるキーは最大4つで、学習に使ったキー語彙は全部で74個ある。
モデルは考えてから動くことも、直接操作を出すこともできる。切り替えは<think>タグをあらかじめ埋めておくかどうかで行う。プロジェクトはvLLMでのデプロイを推奨しており、1リクエストに最大8枚の画像を付けられる。デフォルトは過去フレーム5枚と現在フレーム1枚だ。
規模は0.8B、2B、9B、27Bの4段階。前の3つは1枚のGPUで動かせるが、27Bのbfloat16の重みは約54.7GBあり、テンソル並列で2枚のGPUが必要になる。各サイズにはS1とS3の2版がある。S1はMinecraftのデータのみ、S3はバランスよく混ぜたもので、Minecraftが27%、残りは他のゲームから取っている。合計で8つのチェックポイントになる。
120通りの構成から見えた法則
論文の中心はスケーリング実験だ。著者らはデータ量、多様性、モデル規模の3方向から120通りの学習構成を設計した。データ予算は50時間から1600時間まで6段階、データの混合方式は5種類である。
結論はいくつかの層に分かれる。データが多いほど、同じゲーム内での性能は上がる。多様性は近いゲームへの転移を助けるが、大きく異なる世界では効果は限られる。単一のゲームだけで学習する場合、モデルを大きくするとデータ効率は上がるものの、遠いゲームへの汎化はかえって難しくなる。
学習過程も2つの段階に分かれた。初期は「インターフェース段階」で、モデルはキーボードとマウスの操作方法を学び、この部分の効果はゲームをまたいで通用する。後期は「ワールド段階」に入り、効果は同じゲームと近いゲームに絞られていく。著者らはこれをもとに、検証損失と3つの変数との間の経験的なスケーリング則を当てはめた。また、3Dの世界ではMinecraft専用モデルや最先端モデルと渡り合え、リアルタイムの場面で最も良い結果が出たとしている。
論文の結びも率直だ。模倣学習には天井があり、遠い世界との差は残っている。汎用の身体性エージェントを目指すなら、継続事前学習だけでは足りないという。
中国の開発者はどこまで使えるか
この公開は、中国の開発チームにとって使いやすい点がいくつかある。ベースはQwen3.5で、国内のクラウドやローカル環境のツールチェーンになじみがある。Apache-2.0の下で、重みと推論コードは改変も組み込みも可能だ。
制約も明確に書かれている。リポジトリに学習コードはなく、学習コーパスは非公開で、ゲーム画面のデータは一切公開されない。ゲームの著作権は各パブリッシャーに帰属し、ライセンスはゲームコンテンツの利用権を与えない。プロジェクトは研究目的に限り、商業活動には使わないと明記している。arXivの論文本体はCC BY-NC-SA 4.0で、モデルのApache-2.0とは別のライセンスだ。商用利用を考えるチームは、両者を分けて確認する必要がある。
具体的な用途で言えば、ゲームの自動テスト、一緒に遊ぶボット、身体性エージェントの研究に取り組むチームは、0.8Bか2B版を1枚のGPUで動かし、自社のゲームでどこまで通用するかを試せる。これをベースに自前のデータで追加学習したい場合は、学習パイプラインを自分で整える必要がある。
READMEには対応ゲームの一覧が載っておらず、例として出てくるのはMinecraftとViZDoomのDoomステージだけだ。miHoYo自社のゲームでどの程度動くかについては、論文にもリポジトリにも記載がない。
参考資料：arXiv論文ページ、CocoLoop、GameScaling GitHubリポジトリ。チェックポイント数、重みのサイズ、操作のエンコード形式はリポジトリのREADMEで確認した。