Claude Fable 5 のゲーム制作能力は、今までのモデルより頭一つ抜けて優れているかも

Claude Fable 5 がリリースされた。Fable 5は、Anthropic が “Mythos級” と呼ぶ、長期自律タスクや高度な研究・サイバー領域で従来モデルを大きく上回る能力層のモデルを、一般提供向けに安全制御付きで公開した高性能モデルである。Fable 5 は長期・複雑なタスクに強いが、サイバー、生物、モデル蒸留など一部の高リスク領域では、分類器により Claude Opus 4.8 へフォールバックする仕組みがある。

さっそく前に作ったゲーム制作ベンチマークをさせてみた。Claude Code + Claude Fable 5 (high) できたものが以下である。

ちなみに Opus 4.7 のものはこれ。

明らかに出来が違う。レベルデザインは複雑で解きごたえがある。プレイヤーがジャンプしたり着地した時のアニメーションやパーティクルも心地よい。ジャンプ・鍵取得・クリアなどに対応した効果音も良い感じ。今までのエージェントと比べて、ゲームに対する解像度が高い。

なんでこんなに良いレベルデザインができるのか？ Fable 5 本人に聞いてみた。

❯ あなたはどのようにレベルデザインおよびゲームの調整を行った？

レベルデザインと調整は「先に解析的に設計し、後から探索ソルバーで裏付ける」という二段構えで行いました。

１．物理を先に固定し、決定論的にする

設計の前に、検証可能性を最優先して物理パラメータを決めました:

  • 歩行速度 2px/フレーム、重力 0.5px/f²、終端速度 8px/f、プレイヤー 18×26px、タイル 32px(60fps固定ステップ)
  • すべて整数・0.5刻みの値なので、座標が浮動小数点誤差なく正確に再現される → 状態空間が有限になり、総当たり探索が可能になる
  • フリップは接地中のみ許可。これで「分岐が起きる瞬間」が限定され、パズルとして読みやすくなる

２．紙上(頭の中)での設計: 廊下の積層と「ドリフト合わせ」

レベルは4本の水平廊下をスラブ(梁)で区切り、スラブの隙間で接続する構造にしました。核になる調整は落下中の横ドリフトの計算です。歩行が止まらないので、フリップしてから天井/床に着くまでに必ず横に流されます。例えば最下層は廊下が高さ4タイル(上昇102px ≈ 20フレーム ≈ ドリフト40px)なので、「隙間 (5,6) を通すにはフリップ位置が x∈[120,166]でなければならない」という形で、各障害ごとに有効窓を px 単位で逆算しました。

その窓をスパイクで両側から削るのが調整の本体です:

  • 床スパイクが「これ以上歩くと死ぬ」期限を作り、フリップを強制する
  • 隙間の脇に置いた「番人スパイク」(例: 中層の col 12 の吊りスパイク)が、早すぎるフリップで天井伝いに迂回するズルを潰す
  • 窓の広さで難易度カーブを付けました — 最初の障害は約47フレームと寛容、中盤は約20フレーム前後、ミスしても死かやり直しループに落ちるだけにする

また「壁で反転する」仕様を活かすため、鍵取得後に右壁でバウンドして帰りのガントレットに入る構成にし、ドアはスタート真上に置いて「最初から見えているが最後まで届かない」目標にしました。

３．ソルバーによる裏付けと品質指標

simulate.js はゲーム本体と同じ game-core.js を1フレームずつ探索します(各フレームの選択肢は「フリップする/しない」だけ)。単なる「クリア可能か」以上のものを測りました:

  • フレームBFS: 最速解 665フレーム・10フリップと、そのSpace押下タイミングを出力
  • 0-1 BFS(フリップ回数最小化): どんな解でも最低8フリップ必要と証明 — 「意図した障害が全部スキップ不能」であることの定量的な裏付けです
  • ソフトロック監査: 到達可能な全88,786状態から「勝利か(リスポーンできる)死」に必ず到達できることを逆方向BFSで確認 — 永久に閉じ込められる袋小路がない

最後に Playwright で実機ブラウザ上に最速解の入力列をフレーム精度で再生し、Node のシミュレーションと同一の665フレーム目 で勝利することを確認しました。シミュレーションと実ゲームの挙動が完全一致している証明になります。

正直に言うと、マップは初回のソルバー実行で一発で通りました(反復修正を見込んでいましたが不要でした)。これは手順2でフリ ップ窓を事前に px 単位で計算してから配置したためで、「設計→検証」の分離がそのまま効いた形です。

本人の申告なので、すべてを信じるわけにはいかない。だが、Fable 5のゲーム制作における強みとして、おおむね以下が挙げられるだろう。

  • ルールから面白さの発生源を抽出する能力が高い。自動歩行＋重力反転という制約を、単に実装条件として処理せず、「横ドリフト」「接地中フリップ」「壁反転」「見えるが届かないドア」といったゲーム制作向けの考え方に置き換えている。

  • 試行錯誤だけに頼らず、解析的にレベルを設計できる。多くのエージェントのレベルデザインは「配置してはソルバーにかけ、落ちたら直す」という反復になるが、今回Fable 5は廊下の高さから上昇フレーム数と横ドリフトを計算し、各障害のフリップ有効窓をpx単位で逆算してから配置している。マップは初回のソルバー実行で一発で通っており、レベルデザインを試行錯誤だけでなく制約充足問題として扱えている。

  • 検証可能性を組み込んだ実装ができる。物理パラメータを探索可能にし、ゲーム本体とシミュレータで同じコアを使い、BFS（最短時間の解）や0-1 BFS（最小操作回数）で品質を測っている。

  • 暗黙の品質基準を補完できる。ユーザーは「面白い」「よくできた」「気持ちよく解ける」といった曖昧な依頼をすることが多い。Fable 5はそれら曖昧な要求を、「押すタイミングの余裕」「攻略ルートの想定」「想定通りに解けるかの検証」という制作上の操作可能な変数に変換している。この補完はルール設計だけでなく、演出のレイヤーにも及ぶ。プロンプトでは要求していない着地アニメーション、パーティクル、重力反転・鍵取得・クリアに対応した効果音を自発的に実装しており、よくできたゲームに何が含まれるかをモデル側が知っている。

  • 評価軸が単一ではない。「クリアできる」「見た目が良い」「コードが動く」だけではなく、「極端に少ないフリップ数でのショートカットがない」「各状態から勝利か死亡へ進める経路がある」「特定の解で実機とシミュレーションが一致する」「難易度が段階的に上がる」という複数軸で見ている。「どんな解でも最低8フリップ必要」「到達可能な88,786状態のすべてから勝利か死亡へ進める経路がある」のような、状態空間の全体探索による裏付けも行っている。

ゲームを、コード生成タスクではなく、制約・体験・検証・演出を結ぶ設計タスクとして扱えるのがFable 5の偉いところだ。

上記のページにこのゲーム制作ベンチマークでの様々なコーディングエージェント、モデルでの結果がある。少なくとも今回選んだ生成結果では、Fable 5のゲームは明らかに出来が良いのが分かるだろう。コーディング能力から見ると、Fable ５は 着実な進歩 というくらいの評価になるかもしれないが、今回のゲーム制作結果を感覚的に評価すると、突然のジャンプアップという感じがする。

ただ、今回は短いプロンプトからそのまま生成されたゲームを、特定のジャンルで比較したにすぎない。より優れたゲーム生成ワークフローや、人間による評価・修正を含む改善ループを整備した場合、最終的に出来上がるゲームのモデル間差は変わってくる可能性がある。ゲーム制作一般における能力差を見るには、ジャンルや制作条件を変えた追加の試行が必要そうだ。

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/ をプロジェクトにコピーするだけで利用できる。