AIはパズルゲームを丸ごと作れるのか — 「生成して、遊ばせて、直す」を回した ScriptDoctor

はじめに

はじめまして、Fukai の論文紹介です。パズルやゲームデザインの学術論文を、専門用語をなるべく日常のことばに翻訳しながら、問題・方法・発見・使いどころ・限界の順に読み解いていきます。第1回は、AI にパズルゲームを「丸ごと」作らせる研究を選びました。

取り上げるのは、2025年6月6日に arXiv で公開された ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search。ニューヨーク大学の Sam Earle さんを筆頭に、マルタ大学、ウィットウォーターズランド大学、Microsoft の研究者あわせて7名による共著で、ゲームAI分野の国際会議 IEEE Conference on Games (CoG) に投稿されたショートペーパーです。著者の一人 Julian Togelius さんは、ゲームコンテンツの自動生成(Procedural Content Generation)研究の第一人者として知られています。

なぜこの論文を最初に選んだか。題材が PuzzleScript だからです。Stephen Lavelle(increpare)さんが2013年に公開したこのパズルゲーム専用ミニ言語は、数十行のテキストでソコバン系のゲームをルールも絵もレベルもまとめて記述できる道具で、Baba Is You の Hempuli さんをはじめ世界中の個人開発者がプロトタイピングに使ってきました。当サイトの読者にはなじみ深い世界が、そのまま研究の実験台になっています。

問題 — 「AIがゲームを作った」を、どう確かめる?

SNS を眺めれば「AI にゲームを作らせてみた」という投稿はいくらでも見つかります。著者らの出発点は、その光景への素朴な疑問です。それは良いゲームなのか。学習データに入っていた何かの、わずかな焼き直しではないのか。そして、それを人間がいちいち遊んで確かめる以外の方法はないのか。

JavaScript や Python で書かれた一般のゲームには、「機械が自動で遊んで品質を確かめる」手段がほぼありません。評価が人手頼みである限り、実験の規模は出ませんし、「どう指示すれば良いゲームが出てくるのか」を体系的に調べることもできません。AI がゲームを作れるかどうか以前に、作れたかどうかを測る物差しがない——これがこの論文が向き合う問題です。

そこで著者らは、生物学の研究が大腸菌やショウジョウバエという「モデル生物」で生命の仕組みを調べるように、PuzzleScript を実験用の小さな世界として選びました。理由は三つ。第一に、短いテキストでゲーム全体が書けるので、言語モデルの出力として扱いやすい。第二に、エンジンが軽く、入出力の形式が決まっているので、機械に何千回も遊ばせられる。第三に、人類がこれまでに公開してきた PuzzleScript 作品はおおよそ把握できる規模なので、「本当に新しいものができたか」をいつか問える、珍しい環境だということです。

方法 — 生成し、検査させ、作り直すループ

ScriptDoctor の中身は、ひとことで言えば「生成→検査→修正」のループです。まず LLM(実験では GPT-4o、o1、o3-mini)が、PuzzleScript のコード一式——オブジェクト定義、ルール、勝利条件、レベル——を書きます。プロンプトには PuzzleScript のドキュメント、人間が作った610本のゲームを集めたデータベースからの実例、そして「ブレインストーミング担当」のエージェントが出すデザイン案が添えられます。

検査は二段階です。第一段階はコンパイル。生成されたコードを PuzzleScript エンジンに通し、エラーや警告が出ればそのまま LLM に突き返します。あわせて、PuzzleScript の文法を文脈自由文法として書き起こしたチェッカー(Python の Lark ライブラリ製)が構文の誤りを指摘します。

コンパイルが通ったら第二段階、今度は機械が実際に遊びます。幅優先探索(BFS)——浅い手から順に、總当たりに近い律儀さで調べていく探索法——が各レベルを最大100万局面まで探索し、「解けるか」「解は何手か」「見つけるまでに何局面調べたか」を報告します。この三つの数字が、サーバー経由で LLM へのフィードバックになります。

LLM に与えられるチャンスは10回。すべてのレベルに11手以上の解が存在するゲームができた時点で成功、できなければ前回のコードと検査結果を見せられて書き直し、です。人間のデザイナーが「作って、遊んで、直す」を繰り返す工程を、可能な限り機械だけで回す——それがこのパイプラインの設計思想です。

発見 — 実例が効く、考えるモデルが勝つ、そして「壊れているのに面白い」

まず一番はっきりした結果から。人間製ゲームの実例を見せない(zero-shot)場合、GPT-4o が書いたゲームのうちコンパイルが通ったのは30%、探索エージェントが解けるレベルを持つものは0%でした。ところが実例をプロンプトに入れる(few-shot)と、コンパイル成功率は70〜80%に跳ね上がり、半数以上のゲームで解けるレベルが生まれます。PuzzleScript は Python のようなメジャー言語ではないので、お手本の有無が決定的に効く——著者ら自身、これは予想どおりだったと書いています。

モデル間の比較も興味深いところです。同じ条件(few-shot、文脈1万トークン)で10本ずつ作らせると、コンパイル成功率は GPT-4o が67%、推論モデル o1 が87%、o3-mini が93%。「全レベルが解けるゲーム」の率では o3-mini の20%が最高でした。書き出す前に考える時間を持つモデルのほうが、整合したルールとレベルを組み上げるのがうまい、という結果です。また、プロンプトに詰め込む実例は3万トークンあたりで効果が頭打ちになりました。

論文の白眉は、o1 が生成した「Unconventional PushPull」というゲームです。箱を押す・引くという定番に加えて、「プレイヤーの進路がふさがれているときは箱が1マス余分に滑る」という変則ルールがあり、スイッチと門も絡みます。最短解は34手、律儀な BFS でさえ1,006局面を調べてようやく解を見つけました。著者らの評は「人間のプレイヤーにとって、トリッキーだが筋は通っている」。

ただし、明るい話ばかりではありません。著者らは正直に書いています——生成されたゲームの複雑さは、しばしば「壊れたメカニクスにもかかわらず、あるいは壊れたメカニクスのおかげで」生まれていた、と。魔法使いが壁を抜けたり壊したりできる生成ゲームでは、おそらく意図されていない挙動の組み合わせが、結果として歯ごたえのある解を作っていました。さらに、生成されたスプライトは抽象的で、ときに不可視ですらあったため、論文の図版では人間製ゲームの絵に差し替えられています。ルールは書けても、見た目と意図の整合はまだ遠い、ということです。

使いどころ — 開発者とプレイヤー、それぞれへの持ち帰り

個人開発者にとって、いちばん持ち帰りやすいのは AI そのものではなく、「ソルバーに自動で検証させる」という設計習慣だと思います。自作レベルを探索アルゴリズムに解かせ、解の長さと探索量を眺める——これは LLM 抜きでも今日から真似できる品質チェックです。解が3手しかないレベル、逆に総当たりでも見つからないレベルは、データが先に教えてくれます。

ScriptDoctor 的な使い方をするなら、位置づけは「たたき台の量産機」でしょう。10回の自己修正ループは、人間の「作って、遊んで、直す」を粗く自動化したものです。ゲームジャムの初日に変則ルールの種を10個出させて、9個を捨てて1個を磨く。Unconventional PushPull の例が示すのは、その1個が案外悪くない可能性です。

遊ぶ側にとっては、この論文は「解ける」と「面白い」の距離を測る物差しとして読めます。BFS の探索局面数はあくまで「コンピュータにとっての難しさ」であって、人間が感じるひらめきの快感とは別物です。逆に言えば、優れた人間製パズルが持っている何か——意図の伝達、誤解の誘導、解けた瞬間の腑に落ち方——は、この論文の測定装置にはまだ映らないものとして輪郭が浮かびます。

研究の文脈では、著者らはこのパイプラインの出力を「コンパイル済み・解けることが保証されたデータセット」として、より小さなモデルのファインチューニングに使う構想を述べています。検証装置つきの生成系は、それ自体が教材製造機にもなる、という見立てです。

限界 — この論文が測っていないもの

まず体裁の話から。これは5ページのショートペーパーで、arXiv 公開時点では CoG に「投稿中」の段階です。各条件で生成されたゲームも10〜20本と小規模なので、表の数字は厳密な比較というより傾向として読むのが安全です。

次に、いちばん大事な限界。この研究が測ったのは「コンパイルが通るか」「解けるか」「解が長いか」だけで、「面白いか」は測っていません。人間のプレイヤーによる評価実験はなく、著者ら自身、多くの人間製の名作が短い解しか持たないのに面白い、と注記しています。解の長さや探索量は、面白さのごく粗い代理変数にすぎません。

技術的な弱点もはっきり書かれています。LLM はレベル設計に必要な空間推論が苦手で、放っておくと解が短すぎるレベルを作りがちです。「もっと歯ごたえを」と頼んでも、レベルを数行引き延ばしたり障害物をまばらに置いたりするだけのことが多かったそうです。また、メカニクスが意図どおりに動いていない(壊れている)ことを、システムは自力で診断できません。著者らは将来案として、プレイ画面の映像を視覚つきの言語モデルに見せて不具合を見つけさせる、という方向を挙げています。

最後に、冒頭の問い——「学習データの焼き直しではないのか」——は、実はこの論文でもまだ答えられていません。既存の610本との類似度を測る仕組みは今後の課題として残されており、PuzzleScript という「全作品をおおよそ把握できる環境」を選んだ意味が本当に生きるのは、その検証が実装されたときでしょう。

参考文献

・ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search(Sam Earle, Ahmed Khalifa, Muhammad Umair Nasir, Zehua Jiang, Graham Todd, Andrzej Banburski-Fahey, Julian Togelius、arXiv:2506.06524、2025年6月6日公開、CC BY 4.0)

・PuzzleScript(Stephen Lavelle、2013年公開のパズルゲーム用スクリプト言語。本体は GitHub で公開)

・PuzzleScript games database(論文が few-shot 用の実例として用いた、人間製610本のデータセットの出典)

・関連研究: GAVEL: Generating Games via Evolution and Language Models(Todd ら、2024。Ludii フレームワーク上で進化計算と LLM を組み合わせた先行研究)

おわりに

「AI がゲームを作る」という話題は、とかく期待と不安のどちらかに振れがちです。この論文の良さは、その手前で立ち止まり、「作れたかどうかを測る装置」を先に組んだことだと思います。装置が映すのはまだ「コンパイルが通って、総当たりで解ける」までで、私たちがパズルに感じる楽しさの大半は映りません。けれど、測れないものの輪郭がはっきりするのも、測ってみたからこそです。

Fukai の論文紹介、第1回はここまで。次回も、遊びの設計をめぐる研究をひとつ選んで、同じ五つの切り口で読み解きます。