Jiang ら: 言葉だけで「遊べるゲーム」は作れるか — Fukai が読む OpenGame

一段落要約

ゲーム開発は、創造的なデザインと込み入ったソフトウェア工学が交わる場所だ。大規模言語モデル(LLM。大量の文章で学習し、続きや応答を生成するAI)は単独のコードを書くのは得意になったが、「設計の一言から、最後まで遊べるゲームを丸ごと作る」となると途端に崩れる。本稿で紹介する OpenGame は、自然言語の仕様から遊べる2Dウェブゲームを最後まで自動生成することを狙った、オープンソースのエージェント(自分で計画し道具を使って作業を進めるAI)の枠組みである。

鍵になるのは Game Skill という考え方だ。これは、過去の経験から育てた「プロジェクトの骨組みのひな型」(Template Skill)と、検証済みの修正手順を貯めていく「生きたデバッグ手順書」(Debug Skill)の組み合わせで、エージェントが安定した土台の上に作り、統合のエラーを系統立てて直せるようにする。著者らによれば、150本のゲーム課題で評価したところ、OpenGame は既存の最強の比較対象を上回り、新たな最高水準を達成したという。ただし、パズルゲームは最も苦手なジャンルとして残った——その内側を、論文を開かなくても要点が掴めるように解きほぐしていく。

はじめに

この論文を書いたのは Yilei Jiang を筆頭著者とする香港中文大学(CUHK)の MMLab のグループだ。出典は arXiv:2604.18394、2026年4月20日に投稿された preprint(プレプリント。学会や雑誌の査読を経る前に公開される原稿)で、分類はソフトウェア工学(cs.SE)。つまり現時点では peer-reviewed(査読済み)の論文ではなく、まだ広く議論が固まる前の段階にあることを最初に断っておく。

私がこれを今日選んだのは、Puzzlebyrinth の読者——ゲームやパズルを実際に作る人——にとって、ひとつ手前の現実的な問いに正面から答えているからだ。「AI に『こういうゲームを作って』と言葉で頼んだら、最後まで遊べるものが出てくるのか」。コードの断片を書かせるのではなく、起動して遊べる完成品を出させる。その難しさと、今どこまで来ているかを、数字付きで見せてくれる論文である。

背景

近年、LLM とそれを使う「コードエージェント」は、単独のプログラミング課題を解くのが驚くほど上手くなった。GitHub の課題を解く SWE-bench のようなベンチマーク(性能を比べるための共通の試験問題集)が示してきたとおりだ。だが、ゲームは普通の実用ソフトとは性質が違う、と著者らは指摘する。遊べるゲームはリアルタイムに動き続けるシステムで、更新ループ、物理、イベント処理、素材(アセット)の読み込み、そして多数のファイルにまたがって絡み合った状態を、すべて噛み合わせ続けなければ品質が保てない。

著者らは、最先端モデルがゲームを丸ごと作ろうとするときに繰り返し現れる3つの失敗を挙げる。ひとつ目は論理の不整合で、ゲームループ全体の状態を見失い、固まる・終わらない・肝心の仕組みが動かないプロジェクトを生む。ふたつ目はエンジン特有の知識の欠落で、エンジン(ゲームを動かす土台のソフト)の用意した部品を使わず、物理などを一から作り直してしまう。みっつ目はファイル間の不整合で、個々のファイルは一見もっともらしいのに、素材の名前の食い違いやシーンの配線ミスでプロジェクト全体が壊れる。

なぜこの問題が重要か。ゲーム作りの敷居を下げる——言葉で書いた着想を、そのまま遊べる形にする——ことは創作の現場で長く望まれてきた。だが、エンジンの構造、プログラミング言語、壊れやすい統合作業を同時に習熟する必要があり、敷居はなかなか下がらない。OpenGame は、その壁を専門特化のエージェントで越えようとする試みだと整理できる。

アプローチ / 方法

OpenGame が狙いを定めたのは Phaser(フェイザー。JavaScript だけでウェブ用2Dゲームが書けるオープンソースの土台)だ。Unreal や Unity のような業界標準エンジンは独自の画面操作やバイナリ形式に頼るため、文字でやり取りするAIには扱いにくい。一方 Phaser は丸ごとコードで表現できるので、エージェントにとって理想的な実験場になる、というのが著者らの判断である。

中核にあるのが Game Skill という再利用できる能力で、ふたつの部品からなる。ひとつは Template Skill。最初は「どんなジャンルも前提にしない最小限の骨組み」ひとつだけから始め、課題をこなすたびに、安定して使い回せるコードの断片を抜き出してひな型の蔵に貯めていく。著者らの設定では、この過程から自然に5つのひな型の系統が生まれたという——横から見る重力系、見下ろしの連続移動、マス目状の論理(これはパズルやボードゲームのこと)、経路と波の動き、そしてUI主導の遊び。新しい依頼が来ると、近いひな型を選んで土台にし、決められた差し込み口にだけ中身を足していく。これで生成の探索範囲が狭まり、ファイル間の食い違いが減る、と読める。

もうひとつは Debug Skill。固定のチェックリストではなく、ビルドや実行の結果から更新されていく「生きた手順書」を持つ。失敗が起きるたびに、エラーの特徴・根本原因・検証済みの直し方を一件ずつ記録し、次の課題で再利用する。さらに、過去に多かった食い違い(素材名のずれ、設定項目の欠落、シーン遷移の不正など)を、コンパイル前に軽く点検する仕組みも備える。デバッグの知識が積み上がって持続する——ここが普通の試行錯誤と違う点だ。

土台のモデルも専用に育てている。GameCoder-27B は Qwen3.5-27B を下敷きに、三段階で訓練される。まず継続事前学習(CPT。既存モデルに Phaser や JavaScript のゲーム関連の文章をさらに読ませて土地勘を作る段階)、次に教師ありの微調整(SFT。良質な問いと模範解答の組で、創作意図をコードに変換する力を仕込む段階)、最後に実行に基づく強化学習(reinforcement learning。試行錯誤しながら報酬が高くなる行動を学ぶ枠組み。ここでは単体テストの合格率を報酬にする)。エージェント本体は、分類→骨組み作り→設計書生成→素材生成→実装→検証という六段階の手順で長丁場の作業を進める。

発見

評価は OpenGame-Bench という独自の仕組みで行われた。5ジャンル(横スクロール、見下ろしシューティング、パズル、アーケード古典、ストラテジー)にわたる150本の課題を、ヘッドレスブラウザ(画面を表示せずに裏で動かすブラウザ)で実際に起動し、ビルドの健全性(Build Health)、見た目の使える度(Visual Usability)、意図との一致(Intent Alignment)の3つを0〜100点で測る。乱数の揺らぎを抑えるため各課題を3回ずつ走らせて平均を取っている。

主要な結果はこうだ。Claude Sonnet 4.6 を推論エンジンに据えた OpenGame は、ビルド72.4・見た目67.2・意図一致65.1を記録し、論文によれば新たな最高水準になった。最も強い比較対象だった Cursor(Claude Sonnet 4.6 版、66.8・61.4・58.9)を、それぞれ5.6・5.8・6.2ポイント上回っている。専用に訓練した GameCoder-27B 版でも63.9・57.0・54.1で、すべての「LLM に直接書かせる」方式をビルドと意図一致で上回った。

どの部品が効いているかを一つずつ外して確かめる実験(アブレーション研究)も興味深い。ひな型の決まった差し込み口だけを書き換える方式(Hook-Driven Implementation)を外して一から書かせると、ビルドが10.1ポイント、意図一致が11.6ポイントも落ち、致命的な不具合が頻発した。著者らは、これが最も重要な仕組みだとする。また、自動修正のループは、許す反復回数がゼロのときビルド58.4で、0回から3回の間に最も急に伸び、5回あたりで頭打ちになった。

そして本稿で強調したいのが、ジャンル別の意図一致の内訳だ。横スクロールは76.8、見下ろしシューティングは71.4と高い一方、ストラテジーは58.2、パズル/UIは52.6と明確に低い。著者らは、パズルのような遊びは在庫管理やマッチ3のルールといった「論理の状態」が見た目と弱くしか結びついておらず、ずれても画面に異常が出ない「静かな失敗」になりやすいため、自動デバッグで気づきにくいと説明する。実際、完成度の高い OpenGame でさえ、要求された仕組みのおよそ34.9%は十分に満たせていない。

使いどころ

では、ゲームやパズルを作る人はこの研究をどう使えるか。具体例を挙げよう。ひとつ目。もし自分が小さなウェブパズルの試作を量産したいなら、OpenGame 流の「ひな型+差し込み口」という考え方がそのまま効く。AI に毎回ゼロから書かせるのではなく、マス目状の論理(パズルに当たる系統)の安定した骨組みを一度固め、盤面サイズや勝利条件だけを差し替える設計にすれば、壊れにくい試作を速く回せる。AI を使わない手作業の制作でも、この分業は有効だ。

ふたつ目。もしハイパーカジュアル向けに大量のレベルや小品を生成したいなら、Debug Skill の「失敗の特徴・原因・直し方を一件ずつ貯める」発想を、自分のプロジェクトの不具合台帳として真似できる。素材名のずれや設定項目の欠落など、繰り返し出る統合エラーをコンパイル前に点検する軽いチェックを入れるだけで、生成パイプラインの歩留まりは上がるはずだ。

みっつ目。もし AI 支援でゲームを作る道具を評価したいなら、OpenGame-Bench の評価軸——ビルドの健全性・見た目・意図との一致を分けて測る——が参考になる。「動いたか動かないか」の二択ではなく、コンパイルは通るのに遊べない、見た目は派手だが指示と違う、といった質の異なる失敗を切り分けられる。自社ツールの良し悪しを語る共通言語になる。

加えて、パズル/UIが最も苦手というこの結果自体が、作る人への警告として使える。AI に任せるなら、見た目に出ない論理のずれを検出する仕掛け——状態の記録や、ルール違反を可視化するデバッグ表示——を自分で用意しておくべきだ、と読める。

限界

限界も率直に見ておく。まず著者自身が認めている点。対象は Phaser を使ったウェブ用2Dゲームに限られ、Unreal や Unity のような商用エンジン、あるいは3Dや大規模なタイトルは射程の外だ。さらに、完成度の高い構成でも要求の約34.9%が未達であり、特にパズルとストラテジーで「静かな論理の失敗」を自動では直せないことを、今後の課題として明示している。

Fukai がここで指摘するのは、評価の独立性についてだ。見た目と意図一致の採点には VLM(Vision-Language Model。画像と文章を一緒に扱えるAI)の判定が使われている。つまり「AI が作ったものを別の AI が採点する」構図で、人間のプレイヤーがどれだけ楽しめたか・分かりやすかったかは直接は測られていない。著者らは人手の検証も一部入れているが、最終スコアの中心は自動判定だ。だからこのベンチマークの数字は、人間にとっての面白さの代理指標として読むのが穏当だと私は考える。

もう一点。GameCoder-27B 単体の性能向上は穏やかで(訓練3段階を足してビルドは62.8から63.9)、著者ら自身、改善の大半は土台モデルよりも枠組み側から来ていると述べている。専用モデルを訓練する費用対効果は、まだ慎重に見るべき段階だと読める。

Fukai の読み

ここからは Fukai 個人の読みだ。私はこの研究を、PCG(Procedural Content Generation、コンテンツの自動生成)の系譜の延長というより、「制作工程そのものの自動化」の流れに位置づけたい。レベルや素材という部品を生むのが従来の自動生成だとすれば、OpenGame が自動化しようとしているのは、骨組みを選び・差し込み口を埋め・壊れたら直すという、人間のデザイナーが頭の中で回している段取りのほうだ。設計批評の語彙で言えば、これは「制作のワークフローを形式化して再利用可能にした」試みに近い。そしてパズルが最後まで苦手だったという結果は、私には象徴的に映る。パズルの面白さは見た目ではなく不可視の論理に宿るからこそ、表面を採点するAIには掴みにくい——その事実が、奇しくもパズルというジャンルの本質を裏側から照らしているように読めるのだ。

おわりに

もっと深く知りたい人へ。OpenGame は「AI にゲームを遊ばせる」研究とは反対側、「AI にゲームを作らせる」研究にあたる。遊ばせる側の地図がほしければ、本サイトで以前紹介した GVGAI-LLM の論文と並べて読むと、生成と攻略という両輪が見えてくるはずだ。自動生成の歴史的な流れを押さえたければ、言語モデルでレベルを生む研究(Todd ら, 2023)や、PCG と LLM の接続を概観したサーベイ(2024)が良い出発点になる。OpenGame はまだ preprint の段階で被引用も定まっていないが、エージェントがコードの課題を越えて『動く作品』を作る方向を、具体的な評価とともに示した一本として、地図の上に置いておく価値がある。

参考文献

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

・OpenGame: Open Agentic Coding for Games (Yilei Jiang ら, 2026, arXiv preprint arXiv:2604.18394)

・OpenGame プロジェクトページ

・OpenGame GitHub リポジトリ

・関連研究: Level Generation Through Large Language Models (Todd ら, 2023)

・関連研究: Procedural Content Generation in Games: A Survey with Insights on Emerging LLM Integration (2024)