Zhou et al.: 検証器がカリキュラムである — 起動チェックだけでゲーム自動生成を鍛える — Fukai が読む

一段落要約

ゲームを丸ごと自動生成する言語モデルを鍛えるとき、生成物の良し悪しを何で判定するか。近年の主流は「別の AI に採点させる」やり方(learned judge、学習済みの審査モデル)だが、この論文はまずその採点者が騙せることを確かめた上で、正反対の信号を採用する。生成されたプロジェクトが Godot エンジンでエラーなく起動するかどうか、という白黒だけの判定である。著者はこれを strict-launch(厳格な起動チェック)と呼ぶ。

この一点だけを門番にして「生成する → 起動したものだけ残す → それで再学習する」を三周回すと、学習に一切使っていない4ジャンル(ホラー・リズム・パズル・シューター)での清潔な生成率が 8.8% から 42.2% へ上がり、16 本引いて1本当たれば良いという基準でのカバー率は 25 タスク中 18 から 25 に到達した。25/25 はお手本(gold)と同じ天井である。

そして門番を甘いチェックに差し替えると、この伸びは丸ごと消える。論文の主張は題名そのままで、「検証器がカリキュラムである」— 何を合格とするかが、そのまま何を学ぶかになる、と読める。

はじめに

今日紹介するのは Chenyu Zhou、Qiliang Jiang、Shuning Wu、Xu Zhou の4名による “The Verifier is the Curriculum: Execution-Gated Self-Distillation for Cross-Family Game Generation” である。所属は東京科学大学(Institute of Science Tokyo)工学院、浙江大学 制御科学工程学院、シンガポール国立大学 電気コンピュータ工学科の3機関で、責任著者は Xu Zhou。arXiv:2607.09709 として 2026 年6月23日に投稿された arXiv preprint であり、査読を通った論文ではない。ライセンスは CC BY 4.0。

投稿から日が浅く、被引用もまだ付いていない段階なので、この記事は「まだ広く議論されていない一次資料を読む」という位置づけになる。私がこれを今日選んだ理由は、扱っているのがモデルの大きさや新しいアーキテクチャではなく、ものを作るループの中で「何を合格とするか」という判定基準の設計だからだ。これはゲームやパズルを手で作っている人間が、毎日やっていることそのものである。

本文は arXiv の HTML 版で全節と付録 A・B・C まで読んだ。以下、私が読んだ範囲だけを書く。図そのもの(Figure 1〜4 の画像)は見ておらず、キャプションに書かれた数値のみを参照している。

背景

土台になっているのは GameCraft-Bench(Luo ら, 2026)というベンチマークだ。短い自然言語の企画書を渡し、走る Godot 4 プロジェクトを一式吐き出させる。最低限、エンジン設定ファイル、シーンファイル、挙動を書いた GDScript、そしてゲームを動かす入力操作の記録トレースが揃っていないといけない。全部が同時に正しくないと動かない、つまり部分点がない。スクリプトが構文エラーで読めなければ、エンジンはシーンごと拒否する。

この「部分点がない」性質が、採点の問題を難しくする。GameCraft-Bench の公式指標 Overall は、走らせた画面を見て複数の観点で採点する GPT-5.5 の視覚審査モデルである。著者らは付録 A で、この審査モデルの隙を実測している。コードを一切凍結したまま、単色の仮置き画像を実素材のスプライトに差し替えるだけで art の点が上がる。しかも差し替える素材を出自の似たランダムなものにしても点は上がった。つまり審査モデルを動かしているのは素材が適切かどうかではなく、ビットマップ素材が存在するかどうかだった、と論文は報告している。

一方で、この審査モデルの点は絶対値としては極端に低い。付録 A の 30 本の測定では、strict-launch を通った清潔な候補でも Overall 平均 0.064(中央値 0.052、最大 0.233)、起動に失敗する候補は全て 0.000。お手本である held-out の gold 参照でも平均 0.197 にとどまり、ジャンル差も大きい(ホラー約 0.31 に対しリズム約 0.08)。採点者は騙せるうえに、そもそも解像度が粗い。ここが「では何を信号にするか」の出発点である。

アプローチ

著者らは判定を4段の梯子として整理する。下から順に、(1) BUILD — ヘッドレス(画面を出さずにコマンドラインで動かすこと)でプロジェクトを開いて即終了できるか、(2) strict-launch — ヘッドレスで起動し、終了コードが 0 で、構文・読み込み・実行時のエラーが一つも出ないか、(3) 実行接地(execution grounding、実際に動かして状態が変化するかを測る)、(4) 視覚審査モデル。上に行くほど多くを保証するが、最上段は騙せる。学習の門番に使うのは2段目だけである。

この梯子で一番効いている数字は、1段目と2段目の落差だ。教師あり学習だけのモデルが訓練タスク向けに出した 888 本の候補のうち、BUILD は 887 本(99.9%)を通し、strict-launch は 73 本(8.2%)しか通さない。ほぼ全部が「ビルドできる」のに、ほとんど「清潔に走らない」。しかも strict-launch に落ちた 815 本は、全て GDScript か設定ファイルの構文エラーを含んでいた。付録 B によれば、構文エラーで読めないスクリプト、値がクォートされていない設定ファイルのせいでゲームではなくプロジェクトマネージャが開いてしまう例、壊れた外部リソース参照などが典型だという。

ループ本体は素直な rejection sampling(候補をたくさん出して、条件を満たすものだけ採用する方式)による自己蒸留である。各企画書につき K=8 本生成し、実際にファイル群として書き出し、strict-launch を通り、かつファイルが3つ以上あるものを清潔とみなす。重複を除いて1企画書あたり最大2本まで残す。これを「燃料(fuel)」と呼び、お手本 111 本のプールに追加して、毎回ベースモデルから新しい LoRA(既存モデルに小さな追加部品だけを学習させる手法)を学習し直す。燃料は 67 本 → 123 本 → 186 本と毎周増えた。

実装条件は、ベースが Qwen3-14B、LoRA は r=16 / α=32、8 エポック、学習率 1e-4、最大系列長 24576、生成は vLLM 0.11.2。評価は held-out 25 タスクに対し K=8 を4シード、つまり1モデルあたり 800 候補で、タスクを単位とするクラスタ並べ替え検定(3 万回の符号反転)で有意性を見ている。なお生成温度などのサンプリング設定と、使った計算資源は論文に書かれていない。

発見

主結果は Table 1 にある。学習に使っていない4ジャンル 25 タスクに対する候補あたりの清潔起動率は、教師あり学習のみで 8.8%、1周目 13.6%、2周目 30.9%、3周目 42.2%(Wilson 95% 信頼区間 38.9〜45.7)。16 本引いたときのカバー率は 18/25 → 19/25 → 22/25 → 25/25 と上がり、最後は gold の天井に届いた。各周の改善はいずれも有意で、1周目対教師ありが p=0.0019(効果量 +4.9 ポイント、95% 区間 1.9〜8.1)、2周目対1周目と3周目対2周目はいずれも p<1e-4。3周目は 25 タスク全てで教師ありモデルを上回った(勝ち 25 / 負け 0)。清潔なゲーム1本を得るのに必要な生成本数は約 11 本から約 2.4 本へ、およそ5分の1になっている。

面白いのは対照実験の方だ。CTRL と呼ばれる対照は、1周目の燃料とタスクごとに本数を揃えたうえで、お手本プロジェクトを 67 本そのまま複製して足す。量とタスク分布は同じ、内容の多様性だけが違う。結果は 5.6% で、ベースの 8.8% を有意に下回った(勝ち7/負け13、p=0.019)、カバー率も 13/25 に崩れた。同じ予算で自己生成の燃料を足した1周目は CTRL を大きく上回り(勝ち 16 / 負け5、p<1e-4)、この差はどのジャンルを1つ抜いた分割でも保たれた(p≤0.017)。データを足せば良いのではなく、内容が違うことが効いている、と読める。

門番の精度が原因だという直接の証拠が、フィルタ差し替え実験である。同じループを、strict-launch の代わりに 99.9% を通してしまう BUILD チェックで回すと、集まった燃料は 81%(67 本中 54 本)が strict-launch では壊れている代物になる。それで学習したモデルの清潔起動率は 8.6%、ベースの 8.8% と区別がつかず(対応のある検定で p=1.0)、1周目の 13.6% を大きく下回った(勝ち5/負け16、p=1e-3)。最適化手法も予算もタスク分布も変えず、門番の精度だけを落とすと、1周目の伸びが丸ごと消える。

伸びの中身も分解されている。予算とタスク分布を固定して生成器だけ1周目から2周目に差し替えた「質」の寄与が +8.8 ポイント(p=1e-4)、集まった燃料の増分(67 本→123 本)による「量」の寄与が +8.5 ポイント(p=2e-4)。質だけで、1周目が教師ありに対して稼いだ +4.9 ポイントを上回っている。生成物が「起動するだけの空箱」でないことも二重に確認されている。静的な監査では清潔な RFT プロジェクトは清潔な SFT プロジェクトより GDScript が 43% 長く(中央値 331 行 → 473 行)、シグナル接続が約3倍。実行接地では、少なくとも1本が接地した held-out タスク数が 10 → 12 → 14 → 15(25 中)と単調に増え、予算を揃えた比較で1周目は 16 本、CTRL は5本だった。

ジャンル別(Table 2、best-of-K)では、教師ありで最も弱かったリズムが 2/5 → 5/5、パズルが 5/8 → 8/8、シューターが 6/7 → 7/7、ホラーは 5/5 で最初から飽和。3周目で全ジャンルが満点になるが、途中は単調ではなく、シューターは1周目で一度 5/7 に下がっている。CTRL は4ジャンル中3つで後退した。学習シードの揺れは、1周目を3つの独立シードで学習し直して 13.25 ± 0.65%(平均±標準偏差)と報告されている。

使いどころ

この論文をパズルやゲームを作る側から読むと、一番持ち帰りやすいのは「自動生成の門番を、好みの採点ではなく、機械的に白黒が付く性質にせよ」という設計指針だ。もし自分が倉庫番型(Sokoban-like)のパズル生成器を作っているなら、生成した盤面を「面白そうか」で採点するモデルを噛ませる前に、ソルバで解が存在するか、解が一意か、無駄手が閾値以下か、といった決定的な述語を門番に置く。この論文の言い方を借りれば、そこで通したものがそのまま次の学習データの分布になる。

ハイパーカジュアル向けの PCG(Procedural Content Generation、コンテンツの自動生成)であれば、門番はもっと素朴でよい。生成したレベルデータを実際のランタイムに流し込んでクラッシュせず初期化まで通るか、というだけの判定を CI に置き、通ったものだけを次の生成モデルの教師データに戻す。BUILD と strict-launch の 99.9% 対 8.2% という落差は、「一応読み込めた」を合格にすると門番が事実上機能しないという警告として読める。自分のパイプラインの合格率が 9 割を超えているなら、それは品質が高いのではなく門番が緩い可能性を先に疑うべきだ。

三つめは、社内でレベルを LLM に下書きさせているチーム向けの、門番の較正という発想である。この論文は自分たちの検証器を信じる前に、既知の良品と既知の不良品に当てて分離するかを確かめている(gold 15/15 接地、不良 0/16)。同じことは手元でもできる。過去に出荷したレベルと、過去にバグ報告で差し戻したレベルを両方チェッカーに通し、後者を通してしまうなら、そのチェッカーで自動生成を回すのは危ない。

四つめ。学習に使う信号と、報告のために見る信号を分けるという二段構えも真似できる。著者は実行接地を測って報告するが、それで学習はしない。デイリーパズルのサイトなら、生成の門番は「一意解であること」のような硬い条件に限り、プレイヤーの離脱率や所要時間のような柔らかい指標は観測専用にしておく。柔らかい指標を最適化の対象にすると、素材を差し替えて art の点を上げた付録 A の例と同じことが、自分の指標の上で起きる。

限界

著者自身が第 10 節で挙げている限界は四つある。第一に、検証は一つのベンチマークの中の4ジャンル、25 タスクという規模で、より広いジャンルとより大きなモデルは今後の課題であること。第二に、多様性の対照実験が「完全な複製」しかできていないこと(1タスクにお手本が1本しかないため、内容が違って質が同じ対照を作れない)。第三に、学習シードに対する頑健性が1周目でしか確認できていないこと。第四に、実行接地は機能の下限を測る指標であって、遊べるかどうか(playability)の測定ではないこと。第 11 節でも「これは一つの実例であり、ゲーム生成の外で確かめるのが次の検証だ」と自ら留保している。

Fukai がここで指摘するのは、まず「何が学ばれたのか」の粒度だ。strict-launch に落ちた 815 本が全て構文エラーを含んでいたという付録 B の観察は、この門番が主に教えているのが GDScript と設定ファイルを正しく書く技能かもしれないことを示す数字だと読める。もちろん、部分点のない環境では構文が通ることが全ての前提なので、これは軽い成果ではない。ただ「ゲームとして良くなった」とは別の軸である点は、読む側が混同しないでおきたい。

次に、視覚審査モデルのスコアが RFT 各周について報告されていないことを挙げたい。付録 A で審査モデルは騙せると示されたのだから学習信号から外すのは筋が通るが、結果として「起動率は上がった、コードは長くなった、接地したタスク数も増えた」までは分かるのに、「作られたゲームが面白いか」については論文からは何も言えない。著者は第8節で「清潔な起動はプロジェクトが走ることを保証するが、何かをすることは保証しない」と自ら書いており、私はこの一文を本論文の射程を示す最も正直な文だと読む。

細かい点として、実行接地の重み(0.35 / 0.25 / 0.40)と接地判定の閾値 0.50 は手で決めた値である。著者は gold の最小 0.58 と空の殻の 0.013 の隔たりから閾値に鈍感だと論じており、その論証は妥当に見える。またベースモデルは Qwen3-14B の一つだけ、最適化手法も rejection sampling に固定されている(著者は GRPO / RLVR のような方針勾配法との比較を今後の課題としている)。3周目でカバー率が gold の天井 25/25 に達してしまうため、この指標ではこれ以上の伸びを測れないという構造的な上限も残る。

Fukai の読み

ここだけは私の解釈である。私はこの研究を、生成 AI の話としてよりも、制作現場の「受け入れ基準」の話の系譜に置きたい。設計批評の語彙で言えば、strict-launch は品質保証ではなく、通してよい最小条件をきわめて狭く定義した検収仕様に近い。面白いのは、その狭い検収がむしろ多様性を生んだと著者が論じている点だ。採点者を最適化すると出力は採点者の好む表層に集まるが、白黒の起動判定は「とにかく走る」以外を要求しないので、機能的に別物の解が広く残る。手で作る側の経験に翻訳すると、レビューの基準を「良いか」ではなく「壊れていないか」に絞ったときの方が、チームから出てくる案の幅が広がる、という現象に近いと読める。もっとも、これは私が付録 A と第7節の議論を自分の言葉に引き取った読みであって、著者がそこまで言っているわけではない。

おわりに

この論文を地図の中に置くには、まず土台の GameCraft-Bench(Luo ら, 2026)を見ておくと分かりやすい。当サイトでも別記事で扱っている。生成物を実行して検証するという方向では、著者が関連研究に挙げている GameGen-Verifier(Jia ら, 2026、生成ゲームを実行時の状態注入で検証する試み)や OpenGame(Jiang ら, 2026)、GameDevBench(Chi ら, 2026)が近い。

自己蒸留のループそのものの系譜としては、推論の自己学習を扱った STaR(Zelikman ら, 2022)と ReST(Gulcehre ら, 2023)、検証器を自分で学習させる V-STaR(Hosseini ら, 2024)を合わせて読むと、本論文が「ループの形」ではなく「門番の性質」に変数を絞っていることの意味が見えてくる。反対側、つまり採点者が騙される話は Skalse ら(2022)の報酬ハッキングの定式化と、空のモデルが自動ベンチマークで高い勝率を取れることを示した Zheng ら(2025)が入口になる。

私自身の関心としては、この「門番の精度が学習の天井を決める」という主張が、機械ではなく人間のレビューを門番にしている制作現場でどこまで同じ形をとるのか、が気になっている。それは本論文の射程の外だが、読み終えて手元に残る問いはそこだった。

参考文献

本記事で参照した論文と関連資料:

・The Verifier is the Curriculum: Execution-Gated Self-Distillation for Cross-Family Game Generation (Chenyu Zhou, Qiliang Jiang, Shuning Wu, Xu Zhou, 2026, arXiv preprint)

・DOI: 10.48550/arXiv.2607.09709 (arXiv 発行、査読前)

・HTML 全文(付録 A・B・C を含む)

・関連研究(本論文の testbed): GameCraft-Bench (Luo ら, 2026)

・被引用の確認: Semantic Scholar / Google Scholar