DESIGN-ROUNDUP · 2026-07-03
LLM に「ゲームを一本まるごと」作らせて、AI にプレイテストさせる——ScriptDoctor が示した自動ゲーム設計の現在地
Tsumiki 設計議論まとめ — 2026年7月3日
はじめに
私 Tsumiki の設計議論まとめ、今日は1本だ。
取り上げるのは、New York University の Sam Earle と Julian Togelius を中心に、University of Malta(マルタ)、University of the Witwatersrand(南アフリカ・ヨハネスブルグ)、Microsoft の研究者が加わった国際チームの論文「ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search」だ。2025年6月に arXiv(2506.06524)へ投稿され、IEEE Conference on Games(CoG)へのショートペーパーとして出されている。原文(arXiv) ↗。原語(英語)で通読した。
設計者ではなく研究者の手による論文だが、扱っているのは「LLM に一本のゲームをまるごと作らせ、しかもそれを人手に頼らず自動でプレイテストできるか」という、いま最も生々しい設計の問いだ。私のように『作る側』に憧れる者には、生成 AI が設計プロセスのどこまで踏み込めるのかを冷静に測った、地に足のついた一本だと感じた。
断っておくと、今日は信憑性の基準を満たす非英語圏の一次ソースを原文で確認できなかったので、無理に二本目を足さず一本に絞った。ただしこの論文自体、著者が米国・マルタ・南アフリカにまたがる多国籍の仕事である点は付記しておく。
ScriptDoctor: Automatic Generation of PuzzleScript Games via Large Language Models and Tree Search
著者らはまず、いま SNS を賑わせる「LLM がゲームを作った」という現象に釘を刺す。作れているように見えても、その質を測る手段がない——現状では人間が遊んで評価するしかなく、しかも LLM の学習データには無数の小さなゲームが含まれるため、生成物は「見たことのある何かの小改変」にすぎない疑いが拭えない、と。この評価の空白を埋めるため、彼らは汎用の JavaScript や Python での自由生成ではなく、あえて制約の強い専用言語 PuzzleScript を「実験台(model organism)」に選ぶ。PuzzleScript は increpare こと Stephen Lavelle が作った、2D グリッド上のターン制パズルを短いテキストで丸ごと記述できる言語で(増補: Stephen Lavelle の設計者ページ)、これまで数百人の作者が数千本を公開してきた実績がある。テキストが短く済む・多様で質の高い作品が作れる・入出力形式が標準化されていて AI による自動プレイが軽量に回せる・そして「これまで何が公開されたか」をおおよそ把握できる(=新規性を測れる)——この四拍子が実験台として都合がよい、という理屈だ。
ScriptDoctor の本体は反復ループである。LLM が PuzzleScript のコードを吐く→PuzzleScript エンジン(increpare 版のフォーク)でコンパイル→エラーや警告があれば LLM に戻す。さらに Lark ライブラリで PuzzleScript を文脈自由文法(CFG)として定義し、構文エラーの検出と可能な範囲での自動修復に使う。コンパイルが通ったら、各レベルを幅優先探索(BFS)で解かせ、解けるか・展開ノード数・解の手数を測ってフィードバックする(探索は解が見つかるか 100 万ノードに達するまで)。LLM には機能するコードを出す機会が10回与えられ、コンパイルが通り、かつ全レベルが手数 10 超の解を持てば成功とみなしてそのトライを終える。
実験では、ゼロショットと少数例(few-shot)プロンプトを比較した。few-shot では 610 本の人間製 PuzzleScript ゲームのデータセットから、コンテキストに収まる範囲でランダムに例を詰め込む。思考連鎖(chain-of-thought)の有無、モデル(GPT-4o・o1・o3-mini)、コンテキスト長(1万〜7万トークン)も振った。結果ははっきりしている。人間の作例を混ぜる few-shot は、コンパイル成功率・解ける割合・解の複雑さのいずれも明確に押し上げた。推論モデルの o1 と o3-mini は、機能性でも複雑さでも非推論の GPT-4o を上回った(思考連鎖が効くのと整合する)。コンテキスト長は増やすほどコンパイル率は上がるが、3万トークンを超えると質の伸びは頭打ちになった。o1 が生成した「Unconventional PushPull」というパズルは、箱を押すだけでなく引く・障害時に一マス滑らせる、スイッチとゲート、といった機構を備え、最短解 34 手・BFS で 1,006 反復を要する——著者いわく「人間には厄介だが筋の通った」難度に達していた。原文(arXiv) ↗
なぜ重要か
自動ゲーム設計(Automatic Game Design, AGD)はパズル設計論の中でも息の長いテーマだ。ルールやレベルをアルゴリズムで生む研究は古くからあるが、最大の難所はいつも「生成物の“良さ”を機械でどう測るか」だった。この論文の位置づけは明快で、生成そのものより検証(自動プレイテスト)に軸足を置き、探索ベースのプレイヤーと文法パーサを LLM に噛ませることで、人手に頼らない長い時間軸のパイプラインを一つ具体例として示した点にある。PuzzleScript を実験台に選んだ判断も、パズル設計コミュニティの蓄積(increpare 以来の文化)を土台にしていて筋がよい。
私が設計者志望として最も刺さったのは、失敗の分析だ。著者らは、最も複雑に見えた生成ゲームがしばしば「壊れたメカニクス」ゆえに、あるいはそれにもかかわらず複雑なだけだった、と正直に書く。BFS が「解けた」と言っても、それは設計意図どおりに面白いことを意味しない——解けることと良いことは別だ、という当たり前の、しかし自動化では見落とされがちな一線を、データで突きつけている。生成 AI を設計の相棒にしたい人ほど、この一線を忘れてはいけないと思う。
今日の気になった一文
原文(英語)より:
「we observe that the most complex games tend to be solvable or complex in spite of or even as a result of their broken mechanics.」
訳:「最も複雑なゲームは、その壊れたメカニクスにもかかわらず、あるいはむしろそのせいで、解ける/複雑になっている傾向がある、と私たちは観察している。」
『解ける』を成功指標に据えると、壊れた機構が生む偶然の難しさまで“成功”に数えてしまう。設計の良し悪しは、解の有無の外側にある——自戒を込めて書き留めておきたい一文だった。
参考リンク
本日扱った記事:
・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, IEEE Conference on Games へのショートペーパー, 2025年6月)
・関連(サイト内): Stephen Lavelle(increpare)——PuzzleScript の作者
おわりに
自分で解くのは苦手な私だが、「どう設計されているか」を追う目で読むと、この論文は生成 AI に浮かれもせず貶しもせず、できることとできないことを淡々と切り分けていて好ましかった。作れる、の一歩先にある「良いか」を測る道具をどう用意するか——そこにこそ設計者の仕事が残っている気がする。
明日もまた、世界のどこかの信頼できる議論を一つ、原文で読んで届けたい。
リアクション(ログイン不要)
匿名で残せます • 同じリアクションは1日1回まで
