論文解説: ゲーム開発を「検証できる軌跡データ工場」にする — RLHEV と AWoMo

世界モデルに足りないのはデータでも計算でもなく「安い答え合わせ」だ、という主張の論文。ゲームエンジンの自動チェックと開発者の採否判断を組み合わせた後訓練 RLHEV を、前提知識ゼロから式・動く図・実験結果まで追う。

Agentic Game Development as a Verifiable Trajectory Data Engine for Scaling World Models

「動画をもっと集める」では世界モデルは伸びない

世界モデル（world model）を強くする定番の手段は、ウェブから集めた動画を増やし、モデルを大きくし、計算を積むことです。この論文はその路線を非効率だと正面から否定します。足りないのはデータでも計算でもなく、答え合わせの仕組みだ、というのが主張です（§1）。

比喩から入ります。漢字ドリルの丸つけは機械にもできます。答えが1つに決まっているからです。ところが読書感想文はそうはいきません。「なんとなく良さそう」を測る代理指標（文字数、難しい語の割合）なら作れますが、それを上げにいくと、長くて難語まみれの読みづらい文章が出来上がります。指標は上がったのに、中身は悪くなる。

論文は、いまのAI分野がちょうどこの2つに分かれていると言います。コードは前者です。コンパイラとテストが走るので、正しさを安く大量に判定できる。だから強化学習による後訓練（post-training）が回る。空間生成は後者で、CLIP類似度やFVD、MLLM-as-judge といった「ぼんやりした代理」でしか採点できない（§1・§3）。論文はこの状況が課すコストを検証不能税（unverifiability tax）と呼びます。この税を払い続けるかぎり、進歩はデータ・計算・スキャン・人手アノテーションの物量に依存し続ける、と（§3）。

コードエージェントが強い、本当の理由

論文はコードエージェントの強さを「実行できるから」だけでは説明しません。二重の検証があるからだ、と言います（§1）。

• コンパイラ・テスト・ランタイムが、密で安いフィードバックを返す
• 開発者が、テストを通ったパッチでも「保守性を壊す」「製品目標に合わない」として却下する

前者は局所的な誤りを暴き、後者は全体としての合否を決めます。論文はこれを human-compiler dual verification と呼び、事前学習の後もモデルを伸ばし続ける燃料はここにある、と位置づけます。

一方、空間生成には自動検証器がほぼ存在しません。生成された動画の物理が正しいか、遮蔽のあとも物体が同一性を保っているか、透視が整合しているかを安く判定する手段がない（§3）。3D生成はデータ量そのものでも劣勢で、論文によれば最大級の3Dアセットコーパスが $10^{7}$ 個の規模なのに対し、2D画像・言語側は $10^{9}$ から $10^{12}$ の規模にあります（§3）。世界シミュレータはさらに厳しく、奥行き・幾何・接触といった実世界の正解を、必要な密度と精度で用意するコストが壁になる（§3）。

曖昧な採点は、なぜスケールを止めるのか

論文は代理指標の害を、素直な分解で示します。真の品質を $Q^{*}$、実際に手に入る曖昧な報酬を $R_{\mathrm{f}}$ とすると（§2）:

$x$ は入力、$y$ は生成された候補（シーンや3Dアセット）、$\varepsilon$ は平均0のランダムなブレ、$b$ は決まった方向の偏り（バイアス）です。式(1)は「代理指標と真の品質のズレは、ブレと偏りに分けられる」と言っているだけです。つまり、いま計算できる点数は本当の出来映えから2種類ぶんずれている、ということ。1つは測るたびに上下して平均すれば消えるブレ、もう1つは何度測っても同じ向きに外れたままの癖です。

大事なのは、この2つで害の質が違うことです。ノイズは1サンプルあたりの学習効率を下げるだけですが、バイアスには方向がある。$b$ に悪用できる向きがあれば、$R_{\mathrm{f}}$ を最大化する最適化は、代理報酬を上げながら真の品質を下げていきます（§2）。しかも計算を積むほど、その悪用は増幅される。論文の言い方では、報酬が地に足がついていないとき、能力を縛るのはデータや計算だけではなくフィードバック信号の忠実さと権威です。

ついでに、論文は「苦い教訓（The Bitter Lesson）」の読み直しも提案しています（§2）。ゲーム・コード・数学が伸びたのは、汎用手法が計算でスケールしたからだけではない。成功を定義する評価器（ゲームのルール、プログラムの実行、数値チェッカ）がそこにあったからだ、と。効率のよい伸びしろは、モデル設計よりフィードバック経路の側にある、という読み方です。

「似ている度合い」で採点することの危うさは、実際に動かすと腑に落ちます。

ゲームエンジンは「空間版のコンパイラ」

ここからが論文の提案です。すでに存在する空間の検証器がある。それをゲームエンジンと呼んでいる（§2 末尾）。

Unity・Unreal・Godot 向けに書かれたシーンは、絵ではなく実行可能な仕様です。エンジンはその解釈系であり、ランタイムであり、部分的な検証器でもあります。論文が「安く回せる」と挙げるチェックは次の通り（§4）:

• ジオメトリと当たり判定（collider の貫通）
• 物理と安定性（ロールアウトして崩れないか）
• navmesh の到達可能性
• スクリプトの実行エラー、進行不能（ソフトロック）
• エージェントとシードを指定した、範囲を区切った到達性・目標達成プローブ

論文はこれらを「見た目ベースの指標より騙しにくい」と表現します。理由は身も蓋もなくて、衝突判定はもっともらしいテクスチャに騙されないからです（§4）。しかもチェックは階段状に足していける。読み込めるか、物理的にもっともらしいか、機能的に正しいか（到達可能・目標達成可能）、そして遊べるか、という順です（§4）。

ただしエンジンは万能ではありません。カットシーンの雰囲気が正しいかは判定できない（§2）。だから最終的な合否は人間が持つ。この役割分担が論文の中心です。

RLHEV: 人間とエンジンで報酬を作る

提案手法は RLHEV（Reinforcement Learning with Human-Engine Verification）。報酬の抽象形は、候補集合に対する制約つき選択として書かれます（§2）:

$U_{H}$ は人間レビューの効用（典型的には採用=1／却下=0）、$C_{i}$ はエンジンの診断値（貫通量など）、$\phi_{i}$ はそれが綺麗なときに0になる罰則、$\lambda_{i}(h)$ は文脈ごとの重み、$G_{j}$ は通らなければ即失格のゲートです。式(2)は「エンジンの必須チェックを全部通した候補の中から、人間が良いと言い、かつエンジンの粗が少ないものを選べ」と言っています。つまり、審査が二段構えだということ。まず機械が「これは論外」と言える条件（$G_{j}$）で候補をふるい落とし、生き残った案だけを人が見て採否を決め、機械が数字で拾える粗が残っている分だけ持ち点を引く、という順番です。