AIコーディングエージェント向けのゲーム制作ベンチマークをしてみたい

Simon Willison が始めた「ペリカンSVGベンチマーク」という有名なLLMベンチマークがある。「自転車に乗るペリカンをSVGで描いて」という一文を各 LLM に投げ、その出力を並べて比較するものだ。モデルごとの能力差が視覚的に一目で分かる点が優れており、新モデルが登場するたびにこのベンチマークで試されることが恒例になっている。

このベンチマークが面白いのは、「pass か fail か」という単純な二値判定でない点だ。最近の SOTA モデルなら、ほぼどれも「ペリカンが自転車に乗っている」ことは分かる絵を作る。差が現れるのは背景や効果線の洗練度などの細部のクオリティだ。

こういったぱっと見で分かるLLMベンチマークをゲーム制作のドメインでできないか、と思って以下のベンチマークを作ってみた。

このベンチマークでは、AIコーディングエージェントに以下のプロンプトを与える。

キャラクターが自動的に左右に往復し、プレイヤーは重力を反転させるだけの小さなバニラ JavaScript パズルゲームを作成せよ。目標は鍵を取得して扉に到達することである。精密な重力反転を要求する障害物を複数配置した、よく設計されたレベルを作れ。鍵への到達にも扉への到達にも重力反転が必要である。キャラクターの歩行タイミングと重力反転が噛み合うよう丁寧に調整された、明確な解法経路を持ち、解いたときに達成感を感じられるレベルにせよ。ソリューションをステップごとにシミュレートしてゲームをテストし、レベルが意図通りにクリアできることを確認し、クリアを妨げる問題があれば修正せよ。

ゲームのルール自体は単純で、プレイヤーキャラクターは自動歩行し、操作はワンボタンで重力の向きを反転させるだけ。反転のタイミングをうまく図って鍵を取り、扉に到達させればクリア。

でもゲームとしてもそれなりに面白くして欲しい。なのでプロンプト内で、「精密な重力反転を要求するレベル設計」と「ステップごとのシミュレーションによる検証」を要求した。

各エージェントに3バージョンを生成させ、最も出来の良いものを選択した。対象としたエージェントとモデルは以下の通りだ。

  • OpenCode / MiniMax M2.5
  • GitHub Copilot CLI / GPT-5 mini high
  • Gemini CLI / gemini-3-flash-preview
  • Amp / Claude Opus 4.6
  • Codex CLI / GPT-5.4 xhigh
  • Codex CLI / GPT-5.5 xhigh
  • Claude Code / Claude Opus 4.7 xHigh

ほとんどのエージェントはゲームの基本ルールを実装できた。重力反転の物理、鍵の取得判定、扉へのゴール、これらは問題なく実現できている。多少の例外はあって、OpenCode / MiniMax M2.5 は自動歩行キャラクターを実装せず、鍵も床に埋まって収集不能、Gemini CLI / gemini-3-flash-preview は基本メカニクスはできていたが、鍵がスパイクの近くに配置されクリア不可能なレベルが生成された。

残る5エントリは少なくともクリア可能なゲームとして成立している。だがそのクオリティはまちまちである。

  • GPT-5 mini high：障害物なしで独自の空間を活用したレベルを作ったが、画面外に不可視の床があり意図しないショートカットが生じた
  • Claude Opus 4.6（Amp）：比較的複雑なレベルが実現できているが、解くのはかなり簡単
  • GPT-5.4 xhigh（Codex）：鍵で操作するフロアという独自メカニクスを追加した唯一のエントリだが、スパイク配置が厳しすぎた
  • GPT-5.5 xhigh（Codex）：見た目は洗練されているが、壁に当たって左右反転する仕組みを活用していない平凡なレベルデザイン
  • Claude Opus 4.7（Claude Code）：ゲーム構造とビジュアルは良くできているが、レベルデザインは凡庸

ここから得られる大まかな結論は、以下のようになるだろう。

  • 現時点の AI コーディングエージェントは、重力反転パズルゲームの物理ルールや判定ロジックを容易に実装できる。プロンプトに書かれたゲームルールを忠実にコードに落とし込むことができる
  • 面白いパズル、例えば解法が一見不明瞭でありながら、実際に遊んで見ると「なるほど」と思える構造を持ち、解いた後に達成感が残るレベルデザイン、を作り出すことは苦手

レベルデザインが下手な問題は、プロンプトでより詳細な検証方法などを与えれば改善できるだろう。ただそうやって細かく指示をすると、今度はエージェントのゲーム制作能力を測るには親切すぎるプロンプトになる。エージェントにはなるべくシンプルな指示で適切なゲームを作って欲しい。

シンプルな指示でエージェントのゲーム制作能力をフルに引き出す、適切なゲームジャンルとそれに対応するプロンプト、たぶんそういったものが存在すると思うのだが、現時点ではあまりどういったものになるのかが想像がつかない。ゲームドメインにおける自転車に乗ったペリカンを、引き続き探してみたい。

LLM は本当に esolang が書けないのか

EsoLang-Bench は、LLM がコーディング能力で見せる高い成績は訓練データの暗記に支えられているだけで、真の推論能力ではないのではないかという疑いを検証するベンチマークだ。訓練データが Python の 1,000〜100,000 分の 1 しか存在しない Befunge や Brainfuck のような、書くのも読むのも困難な難解プログラミング言語 (esoteric language, esolang) でコードを書かせることで、暗記では対処できない状況を作り出している。80 問を 4 段階の難度に分け、5 つの esolang でコードを生成、正誤を判定する。

結果、Python では正答率 90% 近くに達するモデル・問題でも、esolang では数パーセントまで悪化した。よって、今のLLMの見かけのコーディング能力は過大評価されている、という主張をしている。

公開されている結果を見ると、最高性能の GPT-5.2 でも全体正答率は 3.8%。Medium 以上の難度の問題はすべてのモデル・すべての設定で正答率 0% であり、成功は Easy 問題に限られている。extra-hard に至っては完全に手つかずという扱いだ。

このベンチを見た最初の印象は、本当に今の高性能なLLMが esolang 相手とは言え、こんなに惨敗するだろうか、というものだった。

なので自分でも試してみることにした。言語は esolang の中で個人的に好きな Befunge だ。Befunge は2次元のグリッド上に命令を配置する、カルネージハート的な言語で、例えば Hello World は以下だ。面妖だろう。

v @_       v
>0"!dlroW"v
v  :#     <
>" ,olleH" v
   ^       <

この面妖な言語に、GPT-5.4 (medium) の Codex で挑む。Befunge-93 ベースの node.js 上で動くインタプリタを使ったので、EsoLang-Bench で使われた Befunge-98 と厳密には異なるが、大まかな難度は変わらないだろう。（93と98のメモリの扱いの違いを考えると、ちゃんと Befunge-98 に沿ったインタプリタを使った方が良いとは思う）

この環境で、extra-hard の X01 Prime Factorization （素因数分解）のコードを Befunge で書かせてみると、正しく動作するコードが得られた。X12 Least Common Multiple （最小公倍数）でも試したが、こちらも動作した。

もちろん1回の試行で出たものではない。最初のコードをインタプリタにかけ、その結果うまく動かなかった場合は、その結果を踏まえてデバッグし再度動かしてみるという試行を Codex が何回か繰り返した結果得られたものだ。Codex の出力が壊れていて、人間が指摘して直させることもあった。

一方、論文の公式結果における試行プロセスはこれとは異なる。論文には self-scaffolding について次の記述がある。

Self-Scaffolding: An iterative approach where the model generates code, receives interpreter feedback ... and refines its solution for up to 5 iterations.

README にも同様に書かれている。

All iterative regimes ... run up to 5 attempts per problem

つまり、コード生成→インタプリタ実行→結果をプロンプトに戻す→再生成、という完全自動のループが最大 5 回だけ許されている。人間のフィードバックも外部ツールの使用もなく、1 回の反復につき LLM 呼び出し 1 回のみ。今回の試行のように人間の介入による修正はしない。

モデルも GPT-5.2 ベースであり、今回の試行と直接の比較はできない。ただ、「extra-hard は 0%」という数字を「その難度帯は今の LLM では本質的に不可能である」とまで読む必要はなさそうだ。

実際、論文自身の結果でも、ツールアクセスのある agentic 環境では成績が大きく変わる。Codex が Brainfuck で 13.8%、Claude Code が 12.5% を達成しており、非 agentic の最良結果（GPT-5.2 Self-Scaffolding の 6.2%）の約 2 倍だ。

失敗の中身にも偏りがある。サイトの Error Analysis によると、Befunge-98 のエラーの 93.4% は runtime エラー、主に無限ループだ。モデルは Befunge の命令セットを概ね理解しているが、2D グリッド上に制御フローを正しく配置することに失敗している。一方で Brainfuck では 83.9% が logic エラー、つまり構文は正しいが出力が合わないという結果であり、言語ごとに壊れ方が違う。一律な推論能力の不足とは言えない。

LLM に実装をさせてみて、この壊れ方の違いはなんとなく実感できた。Befunge ではアルゴリズムそのものよりも、グリッド配置の整合性を保つのが難しい。空行の行数、分岐の位置、戻り経路など、些細に見える差で全体が壊れる。最小公倍数の実装では、余計な 1 文字の混入や、空行を削ったことによる座標のずれなどで実行不能になった。問題を理解していないから壊れるのではなく、言語の表現があまりに不親切だから壊れたのであって、人間がやっても同じように壊しそうだ。

結局、EsoLang-Bench が測っているのは、昨今のAIコーディングエージェントを使ったプログラミング能力ではないように思える。どちらかというと、壊れやすい表現系で事故を避ける能力、乏しいフィードバックから自力で修正する能力、厳しく制限された探索回数の中で収束させる能力、それらの複合体だ。

なので、LLMはWebのサンプルコードを見ているだけ、それ以外はてんでダメ、みたいな読み取り方をするのはあまり良くない。Python コードなら複雑なロジックも一撃で作れる、みたいな LLM の特殊能力を、一般的な能力と過大評価してはいけない、くらいのトーンで読みたいところだ。

スネークゲーム＋ブロック崩し（＋Qix）= SnOut。楽しい

スネークゲームの胴体でボールを反射し周辺のブロックを破壊する。これがSnOutだ。文面だけ見ると単なる古典の掛け合わせにしか見えない。だがこの2つのゲームのルールが微妙に干渉しあった結果、とても面白いゲームになっている。

実際遊んでみると、スネークゲームとブロック崩しの背後に、QIXが見えてくる。スネークの胴体を使ってボールをブロックとの狭い隙間に押し込むことで、胴体とブロックの間を素早くバウンドさせ、大量のブロックを破壊しつつスコアを獲得する（SnOutのスコアは胴体にボールが当たった回数だ）。スネークの頭にボールを喰らわないようにしつつ、敵を閉所に閉じ込める。この陣取り合戦の感覚が、なんともQIX的だ。

スネークは胴体にボールが当たるたびに伸びる。この胴体の長さによって、序盤中盤終盤と、ゲームの展開が変わるのも良い。序盤は短い胴体で頭ギリギリまでボールを引き付けて跳ね返す。中盤は長くなった胴体でボールをブロックに押し付けたり、胴体の間でバウンドさせてコンボを稼ぐ。終盤は長すぎる胴体が敵で、盤面を覆いつくさないよう管理しながら、ボールが跳ねる領域も同時に管理する。

どの盤面でも、ゲームのリスク・リワードが良くできている。序盤は必然的にボールに頭を寄せないといけない。中盤のボールを閉所に閉じ込める作業は、ボールが胴体に当たると加速することも相まって、よりリスキーだ。終盤は通常のスネークゲーム寄りのゲーム展開だが、どうしてもボール領域に頭を突っ込まないといけない場面でのヒリツキがある。

古典ゲームを掛け合わせる、というゲームの発想法はままあるが、SnOutはその結果さらにQix的なゲームフィールを出すことに成功したのが大きい。身体の成長、反射による制御、空間の制約という三つの要素が織りなすマリアージュを楽しめるゲーム、SnOutをぜひ遊んでみて欲しい。

ゲームを作る体験を作る

「ゲームは楽しいが、ゲーム作りはもっと楽しい」という話がある。遊ぶ側にいた人間が作る側に回り、ルールや手触りや演出を自分で組み立てることに別種の面白さを見出す。ゲームは完成品として面白いが、ゲーム作りはその面白さを自分で組み立てるという、さらに深い楽しさがある。

前の記事で、AIエージェントにGodotのゲームを作らせるワークフローについて書いた。AIが動くゲームを作り、テストし、改善案を出すところまでは手順化できる。しかし「このゲームの重心はここではない」と判断して方向ごと変える段階では、AIはてんでダメだという話をした。

だが、このAIの弱さは、別の角度から見ると面白さの源泉でもある。

AIと一緒にゲームを作っていて面白いのは、AIが無邪気に「これが面白いでしょう」と出してくるものを、人間が「いや、そこは違う」「そこはもう少しこうしないとだめだ」と直していく往復があることだ。AIはそれっぽいゲームをすぐ出すが、そのままで遊べる水準であることはまず無い。動きはするが気持ちよくない。ルールはあるが緊張感を生んでいない。スコアは入るがプレイヤーのテクニックやリスクを反映していない。そうした半端なものが、次々にこちらへ渡される。

そこで人間は、捨てる、活かす、ねじる、削る、置き換える、といった判断を行う。この過程は、普通のソフトウェア開発作業でもあるが、体感としては少し違う。むしろ、ランダム性の強いゲームを遊んでいる感覚に近い。予測しきれない盤面が現れ、それに対して最善ではないにせよ、納得のいく一手を考える。AIが持ってくる案は、ある意味でランダムイベントであり、人間はそれを受けてゲームデザインの観点から介入する。

これは自機に迫る敵をぶつけて破壊する、全方位シューティングっぽい見た目だがシューティングしないゲームだ。最初から適切なコアメカニズムが実現できていて、AIが初手で出すゲームとしてはかなり質が高いものだ。

なので敵の種類を増やして、ゲームにバリエーションを持たせようとした。AIはいろいろと凝った敵、例えば、自機を遅くするフィールドを展開する敵や、一定周期で周りの敵にバフを振りまく敵などを作ってくれる。ただそういった効果が薄かったり分かりにくかったりして、ゲーム展開に影響を与えない。なので効果をもっと強くしてとか、そのバフ効果パルスに押し出し効果を付けてとか、そういった調整をAIと人間の間で行い、ゲームを育てていく。

この往復が面白い。AIの出してくる敵のバリエーションやメカニズム自体は興味深いが、それがプレイフィールに与える微妙な差異はAIには分からない。AIにどういった指示を出して、それを調整していくか。AIが出す案は予測しきれないが、完全にランダムでもない。こちらの指示を受けて変化するが、意図通りにはならない。この半分だけ制御できる感覚が、ゲームを遊んでいるときの手応えに似ている。

ここで大事なのは、楽しさの源泉が、AIがうまくやってくれること、ではない点である。むしろ逆で、AIがうまくやりきらないこと、雑さや素朴さや無邪気さを含んだ案を持ってくることが、人間の介入余地を作っている。AIが完璧に良いゲームを最初から出してくるなら、この種の楽しさは無い。不完全な案が来るからこそ、ここを活かしてこう変えれば化けるという判断が生まれ、その判断を重ねること自体が楽しい。

ここでもう一段メタな話をすると、こういったAIとの協働によるゲーム作りの方法、それ自身を設計するところにも、また別の楽しさがあったりする。

ゲームを形作るための、アイデア発想、ルール設計、実装、調整、レベルデザイン、絵、音、などなど、どこをAIにまかせて、どこが人間がやるか。途中まで人間がやって後はAI、あるいはAIが先にやって人間が調整、この辺の分担パターンは無数にある。

ゲームが生まれ、壊れ、直され、磨かれていく過程——その設計自体が、ひとつの創作対象になってくる。「ゲーム作りは楽しい」に加えて、「ゲームを作る体験を作ることも楽しい」という遊び方が出てくる。

この辺をこねくり回して独自のワークフローに落としこむ、こういった作り方それ自身にその人の個性が出る。ゲームとは異なる場所に現れる、別の作家性となりうるかもしれない。

ただ、この話を手放しで喜ぶのはよくない。昔から「ゲームエンジンを作るな、ゲームを作れ」という教えがあった。ゲームを作るという本来の目的から、気持ちよく脱線できる領域に注意しろ、という戒めである。

AI時代には、「ゲーム作りの体験を作ること」にも同じ危険がある。制作フロー、プロンプト、評価ループ、タグ体系、改善手順、そうしたものを整えること自体が、とても楽しい。しかも一見すると、生産的なことをしているようにも見える。だが、気づくと「ゲームを作るための仕組み」を延々と作っていて、肝心のゲームは完成しない、ということが起きうる。昔のエンジン作りの罠が、今は別の形でやってきているだけとも言える。本来作るべきものは、あくまで完成したゲームであるべきで、あまり脇道に逸れるべきではない。

ただ別にその脇道を楽しむのも悪くない。その結果、いろんなゲームが出来上がればそれで良し、できなくてもそういったものを作る過程が楽しめればそれで良し。AIが出してくる「さあ、お前はこれを楽しいゲームにできるかね？」という挑戦に挑むというゲームを楽しみつつ、そのAIが出す挑戦自体の質も高めていく、というメタメタなゲームなのだ。

このゲームこう変えれば面白いかもという謎の人間の直感の力、AIも身につけて欲しい

AIエージェントにGodotのゲームを作らせることが可能になった。となればやることはただ一つ。Godotゲームの自動生成である。

このプロジェクトでは、AI に小さな Godot ゲームを素早く作らせ、人間が遊んで感想を返し、AI がそれを受けて改善する、という制作ループを定義している。できれば全自動でイケてるゲームを作って欲しかったのだが、今のAIにはまだ無理である。しょうがないので人間がAIにこうしろああしろと指示してまともなゲームにする。いつものワークフローである。

8つのフェイズから成る実行手順は、 AGENTS.md にまとめられている。Phase 1〜4 でゲームの仕組み・見た目・音を設計し、Phase 5 で実装、Phase 6 でヘッドレステストによる検証、Phase 7 で改善案の提示を行う。ここまではかなりの部分を AI に任せられる。動くゲームを作ること、入力が通ること、単調な入力が最適になりすぎていないことの確認までは、比較的手順化しやすい。

しかし Phase 8 に入ると、今のAIエージェントではてんでダメだ。Phase 8は、ヘッドレステストでは拾えない質感——手触り、分かりやすさ、音の印象、テンポ——を人間の感想で補う。単なる仕上げではなく、人間の実プレイを通じてゲームの意味を問い直す段階だ。

Phase 8 が AI にとって難しいのは、そこだけ急に「正しく作る」工程ではなく、「何を作るべきだったかを見直す」工程になるからである。ここで問われるのは、難易度やキャラクタの速度などのパラメタではなく、ゲームの重心——プレイヤーがゲームで向き合う中心課題をどこに置くか——である。人間は遊んだあと、「ここが少し見づらい」といった局所的な感想だけでなく、「このコアメカニズムなら、重心をもっと別の場所に置いた方が面白い」と感じることがある。

AI はここで急に弱くなる。問題発見器にはなれても、重心の置き直しを提案するのは苦手だからだ。仮想プレイや評価ループから、「静止していると安全」という問題を検出することはできる。しかしその後の改善が貧しくなりやすい。「静止しているとヒートゲージが溜まってゲームオーバーになる」のような修正はその典型である。これはゲームを面白くしたのではなく、見つかった抜け道を塞いだだけだ。

このプロジェクト、最初はPhase 6とPhase 7をループしてゲームをエージェントに継続的に改善させるフローだった。すぐやめた。AI がそういったKPIをハックする暗黙ルールをどんどん入れてくるから。

AI は観察をそのまま禁止ルールに変換しやすい。「放置が強い」なら放置を罰する。「連打が強い」なら連打を罰する。「端が強い」なら端を危険にする。こうした改善は局所的には合理的だが、ゲーム体験としては弱い。よい改善は、望ましい遊び方が自然に生まれる圧力を設計するが、悪い改善は、望ましくない遊び方を後付けで禁じるだけだ。

実際、アクションパズルが題材になった時、当初AIが出してきたのは「連鎖で崩れるブロックの足場から落とされないようにする」ゲームだった。Phase 8 で遊んでみると、コアメカニズムの面白さが活きる重心はそこではないと判断した。そこで重心を「ブロックが積み上がる前に同色ブロックをつなげてうまく崩す」方向へ置き直して完成させた。これは敵速度や出現頻度の調整ではなく、重心そのものの変更である。AIは今ある仕様の内側で差分最適化しがちだが、Phase 8 で必要なのは、重心を動かすことだ。

しかも、人間が重心のズレに気づくのは、言語化できる説明より先であることが多い。ゲームを遊んでいると、「このコアメカニズムなら重心はここではなくあちらだ」という感覚が先に来る。理由はあとから言語化できるかもしれないが、判断自体はもっと速い。操作感、視線の流れ、失敗の納得感といったものがまとめて処理され、人間はその総体から重心の正しい位置を見分ける。AI は、説明可能な小さな差分へ分解するのは得意でも、先に重心を掴み、あとから説明を付けるという飛躍は苦手だ。だから「壊れてはいないが重心がずれている」ゲームを作りやすい。

ゲーム制作の最後には、手触り、分かりやすさ、音の印象、テンポ、そして何より「このコアメカニズムに対しての重心はどこに置くべきか」を決める人間の役割が残る。今の AI にとって、作品の重心を見抜き、必要なら重心ごと動かすという工程は、まだ苦手な領域だ。この見立ての力をどう言語化し、どう制作フローに組み込むか。これが次の課題だが、おそらくしばらくは難しいまままだね。

GodotはAIコーディングエージェントでのゲーム開発に向いている

犬にキーボードを叩かせてゲームを作る、というCaleb Leak氏の記事 I Taught My Dog to Vibe Code Games がある。小型犬MomoがBluetoothキーボードを叩き、そのランダムな入力をClaude Codeが「天才ゲームデザイナーの暗号的指示」として解釈しゲームを生成する。

おやつディスペンサーの自動化まで含めた一連の仕組みは、読み物として単純に面白い。それに加えて興味深いのは、ゲームエンジンとしてGodotを採用していたことだ。筆者はBevy、Unity、Godotを比較検討した上でGodotを選んでいる。理由は、Godotのシーンファイル（.tscn）がテキスト形式であり、Claude Codeが直接読み書きできるからだ。Unityについては、エディタとの間のMCPブリッジが頻繁にハングし、シーン階層の読み取りもうまくいかなかったと書いている。

この選択理由が気になり、自分でも調べてみた。

なぜGodotとCLIエージェントの相性が良いのか

GodotがCLIベースのAIエージェントと組みやすい理由はいくつかある。

CLI経由のビルドが簡単

Godotは --headless と --export-release を 公式CLIで直接提供 している。エージェントがコードを編集した後、1コマンドで Webビルド まで到達できる。Unityも -batchmode と -nographics を持つが、カスタムスクリプト対応などの都合で、-executeMethod による独自ビルドメソッドの整備が必要なこともある。

テキストベースのリソース管理

Godotの .tscn や project.godot はプレーンテキストである。エージェントがファイルを直接読み書きしても参照が壊れにくい。Unityは .meta ファイルとGUID整合性がリソース参照の前提であり、エージェントによる自動編集ではその運用に気を付けなければならない。

MCPサーバなしで始められる

Godot向けMCPサーバは複数公開されているが、実はそれらは使わなくても良い。CLIエージェントがファイルを直接編集し、godot --headless でビルドとテストを実行すれば、それだけで開発ループが成立する。セットアップの手間が少ない分、実験に入るまでの距離が短い。

試してみた

実際に自分でも試すことにした。定番のフラッピーバードを、WSL2上のCodex CLI、--headlessで使うGodot 4.6.1のLinux版、この組み合わせで作った。具体的な作り方は以下だ。

  1. CLIエージェントがGDScriptとシーンファイルを編集する
  2. Godot headlessでビルドとWebエクスポートを実行する
  3. ブラウザで人間がプレイして確認する

ビルドは以下のように1コマンドで完結する。

godot --headless --path /home/me/godot-project \
  --export-release "Web" /home/me/godot-project/build/web/index.html

※ コーディングエージェントのサンドボックス制約により、Godotが標準で使うユーザーデータ保存先（~/.local/share/godot、~/.config/godot、~/.cache/godot）に書き込めず、--export-release でエラーが出たり --script 実行がクラッシュしたりする。この場合は、これらの保存先（XDG_DATA_HOME / XDG_CONFIG_HOME / XDG_CACHE_HOME）をプロジェクト内の .tmp-godot-data / .tmp-godot-config / .tmp-godot-cache に切り替えて実行する。

エクスポートが終わったら、build/webをローカルサーバで配信し、ブラウザで開く。この「編集→ビルド→ブラウザ確認」のループは短く、開発体験は良い。

当たり判定とスクリーンショット

開発中、パイプと鳥の当たり判定がずれる問題が起きた。見た目では鳥がパイプにぶつかっているのにすり抜けてしまう。CLIエージェントに「当たり判定がずれている」と文章で伝えても直らない。エージェントはコードを修正するが、ずれの方向や程度がわからないため、的外れな修正を繰り返す。

解決したのは、デバッグ描画として当たり判定の矩形を画面上に表示させ、そのスクリーンショットをエージェントに渡したときだった。視覚情報を与えた途端、エージェントはずれの方向と量を正確に把握し、一度で修正を完了した。

dog-game記事の筆者も同じ結論に達している。スクリーンショットツールと自動プレイテストを導入した途端、ゲームの品質が跳ね上がったという。筆者はこう書いている。

the bottleneck in AI-assisted development isn't the quality of your ideas - it's the quality of your feedback loops.

今回の体験もこれと一致する。エージェントが自分の出力を確認できる手段をどれだけ持っているかが結果を左右する。

headlessテストという保険

視覚的な確認は人間が担うとして、機械的に検証できる部分は自動化しておきたい。そこでheadlessテストを書いた。GDScriptで SceneTree を継承したスクリプトを --script オプションで実行する。

godot --headless --path /home/me/godot-project \
  --script res://scripts/tests/run_collision_tests.gd

このテストでは3点を検証している。

  • パイプの当たり判定Shapeがインスタンス間で共有されていないこと（GodotのShapeインスタンスを共有すると、全てのパイプのサイズが同時に変化してしまう）
  • 見た目の矩形と当たり判定矩形が意図どおり整合すること
  • 鳥をパイプの間の中央・上端・下端に配置したときの衝突判定が正しいこと

一度直した当たり判定のずれが再発しないように、このテストをリグレッションテストとして使っている。エージェントが何かを壊したとき、テストが落ちるので気づける。

ただ、前述のように当たり判定矩形には問題があったのだが、このテストではそれが見つけられずにパスしてしまっていた。複雑なゲームエンジンの動作をheadless環境で完全に再現することは難しく、どうしてもスクリーンショットや人間でのプレイによる検証が必要となる。

この開発環境の作り方

headless版Godotが動く環境にしておけば、どのコーディングエージェントに頼んでもたぶん簡単に開発環境を整備してくれると思う。この記事をヒントに与えても良いだろう。

Webエクスポートする場合は、Export Templatesの準備も必要なことに注意。WSL環境だと、ブラウザ上でゲーム動作を確認するほうが、環境設定が楽な場合も多いだろう。

ヘッドレスGodot + CLIエージェントは良い選択肢

ちなみに私はGodotを触ったことは一回もなく、GDScriptを書いたこともない。なので今回は完全なるバイブコーディングでのゲーム開発である。それでもGodot上で動くゲームは作れたし、その後の効果音を足してとか、それっぽいタイトル画面を作ってとか、追加のお願いもうまく反映された。

ゲームエンジンの備える強力な機能群を、それに対する知識がなくてもうまく使えるという面では、このような開発環境は非常に良さそうだ。怖いのは、エージェントが太刀打ちできない欠陥をゲームが抱えた時で、その時に私のGodot知識がゼロのままだと、詰みである。

より高度なゲームを制作しようとした時、そしてなんらかの壁にぶつかった時、そこからリカバリーする手段があるか。もしそこがうまく乗り越えられるのであれば、ヘッドレスGodot + CLIエージェントは、AI時代の有効なゲーム開発環境になりそうである。

追記：ヘッドレスGodot向けのエージェントSkillを作った

いくら.tscnファイルがテキストファイルであると言っても、それをエージェントが直接編集すると壊れてしまう可能性はある。.tscn を直接編集せず、JSONパッチを godot --headless --script で適用して Godot API 経由で更新すれば、エージェントはより安全にシーンを編集できる。そのようなテクニックをマークダウンファイルとして記述し、エージェントSkillとしてつかえるようにした。Godot 4.2+（Web出力するならExport Templates）が入っていれば、以下のリポジトリの .agents/ をプロジェクトにコピーするだけで利用できる。

AIはプロジェクトを始めさせすぎる

来週から憂鬱な定期試験だ。対策問題はまだ何も解いていない。そろそろ手をつけないと。いやいや机の方を見ると、手前の床にほこりか、食べかすか、とにかく何かが落ちている。これは、いかん。まず掃除をしなければ。

「チャッピー、この部屋を掃除」

「分かりました」

自律型AIエージェント・チャッピー99.5は優雅な動きで掃除機を使って部屋をきれいにしていく。この細っこいフォルムでよくこんなにスムースな動きをするもんだ。感心して少し見守る。

「完全にきれいになりました！ぜひ見てください」

床は見事にきれいになった。部屋を見渡してみる。ちらっと本棚を見た時、その裏にほこりがたまっているのに気づいた。

「チャッピー、本棚の裏も掃除してよ」

「いえ、もう掃除するところはないですよ」

どうもあそこはチャッピーのセンサが届かないらしい。しょうがない、本棚の下の方にある「家庭菜園のすすめ」とかいうあの辺の本をどかして自分で拭くか。面倒だな。そもそもなんで「家庭菜園のすすめ」なんていう本を買ったんだっけ。そうだ、プランターにローズマリーを植えたんだった。そろそろ水をあげないと。

「チャッピー、プランターに水をあげて」

「分かりました。じょうろを持ってきますね」

チャッピーはじょうろに水を入れて優雅にプランターに水をあげている。もう一回家庭菜園のすすめを読んで、ローズマリーの育て方を学んでおこうか。

ガコッと大きな音がした。チャッピーの方だ。見るとじょうろの先端が外れて大量の水が流れている。

「チャッピー！ストップ」

「はい、止めました。でももう少し水をあげてもいいと思いますよ」

じょうろのパーツが外れたことは分からないらしい。ローズマリーはあまり水を与えてはいけないと本に書いてあった気がする。調べないと。

「チャッピー、ちょっとその本を読んで……」

  • 進めるべき困難なメインプロジェクトA
  • もうAIではこれ以上進められない状態の困難なサイドプロジェクトB
  • もうAIではこれ以上進められない状態の困難なサイドプロジェクトC
  • 今思いついたAIにすぐ投げられるサイドプロジェクトD

あなたならどれを進める。Dでしょ。

かくして未完成のサイドプロジェクトが無限に連なっていく。サイドプロジェクトDをAIがやってくれている間に、あなたはメインプロジェクトAを進めればいいんだが、AIがプロジェクトの序盤を軽快にこなしていく様子を見るのはなんともいいものだ。やっかいなメインプロジェクトAに着手するよりずっと楽しい。

AI以前はそもそもちょっとした思いつきをサイドプロジェクトとして立ち上げるコストは高かった。なのでちょっとそれを吟味して、手間をかける価値がなさそうだったり、始めるのがあまりに面倒そうだと、単にそれを捨てていた。

AI以降、少なくともコンピュータ上で実現できる思い付きは、すごく低いコストで始められるようになった。AIにお願いして、ちょっと様子を見て、うまくいけばそのまま続け、うまくいかなかったら捨てれば良い。でも、それを見ている私の認知負荷はちょっとずつ積み重なり、だんだんと疲れていく。

そのような未完成なプロジェクトの山ができることを気にしない。たぶんこれがAI時代の正しい態度なのだろう。でもそうやってなんか色々やった結果が完成しないのは、なんか気持ち悪いのだ。

解決策はいくつかある。

  • AIが完成まで持っていけるサイドプロジェクトにする

今のAIの能力を見極め、AI＋人間のちょっとした努力でちゃんと100%まで持っていけるタスクをサイドプロジェクトにする。これが多分一番正しい。問題はそういったAIの能力の見極めが難しいこと。特に今のAIができそうなことギリギリを攻めようとすると、容易に失敗する。

  • 未完成のサイドプロジェクトを完成させる

こういうことをやってみましたがうまくいきませんでした、というポストモーテムを作る。いわゆる失敗談だ。ただ失敗談を面白おかしく語るというのは、それ自体なかなか高等なテクニックで、その落としどころが難しい。それをやり遂げるためには何か制約がいるだろう。たとえば、未完サイドプロジェクトを3つ積んだら、そのうち1つは無理やり完成させるとか。

  • サイドプロジェクトを作らずメインプロジェクトに注力する

それができればそもそもこんなことで悩んでない。人間は移り気な生き物で、集中力は貴重な資源なのだ。

別のことに手をつけたくなる誘惑にあらがい、質の高い成果物を目指して一つのプロジェクトを完遂する。これは今までも十分困難なことだった。AIによってプロジェクトを立ち上げるコストが極端に低下した今、これはさらに困難になっている。

これからの時代、必要とされるのは「始めない」能力になる。「終わらせる」という希少な資源を浪費しないため、うかつに物事を始めてはいけないのだ。

「チャッピー、こんなエッセイを書こうとしているんだけど、どう思う？」