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によってプロジェクトを立ち上げるコストが極端に低下した今、これはさらに困難になっている。

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

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

コーディングエージェントにとってゲームプログラミングは困難、これは本当か？

AIコーディングエージェントにとって、ゲームプログラミングは他のソフトウェアのプログラミングに比べて難しいよね、ということはなんとなく肌感では分かる。だけどそれはどういった要因によるものなんだろう。それを探るために役立ちそうな既存研究をいくつか眺めてみた。

2,219件のPygameタスク評価を行ったV-GameGym (2025)

V-GameGymでの評価は、ゲーム要件から生成されるコード単体の妥当性ではなく、実行後に得られる画像・動画を LLM-as-Judge により判定する点に特徴がある。そのため、単に描画 API を呼び出しているか否かではなく、画面上でオブジェクトが適切な位置関係・スケール・描画順序を保っているか、また時間経過に伴う挙動がゲームとして意味を成しているかが、評価対象となる。

V-GameGym によるマルチモーダル評価では、コードの構文的正しさや実行可能性を測る Code スコアは多くのモデルで高水準（70 点以上、上位モデルでは 90 点台）に達する一方、生成結果の スクリーンショットおよび動画に基づく評価は著しく低い（おおむね 0〜20 点台）。現在のコーディングエージェントには、文法的に整合したコードを生成する能力と、実行結果として現れる視覚的・動的品質を担保する能力との間に大きな乖離があるということを示している。

Godotエンジンを対象としたベンチマークGameDevBench (2026)

GameDevBenchはGodot 4の実プロジェクトに対して特定の機能や表現を実装させるタスクを用いたベンチマークである。このベンチマークによれば、ゲーム開発におけるコードの変更量やファイル数は、ソフトウェア開発の標準的指標であるSWE-benchの3倍以上に達する。これはゲームプログラミングが単なる関数実装に留まらず、スクリプト、シーンツリー、物理的衝突判定、アセットの紐付けといった、複数の要素を同時に統合しなければならないためである。

同ベンチマークでの「成功」は、単なるエラーの不在ではなく、Godotのテストフレームワークに基づき、エンジン内のノード状態や物理的相互作用（例：コライダの衝突やカメラ内可視性）が設計どおりであるかを決定論的に検証する基準に基づいて定義されている。この厳密な評価設定の下での最高成功率（Gemini 3 Pro preview、マルチモーダルフィードバック有り）は54.5%にとどまり、AIエージェントにとってゲームエンジン内の複数要素の整合性を同時に保つことが極めて高い負荷であることを示している。

また、GameDevBenchの実験では、エディタのスクリーンショットや実行動画といった視覚的フィードバックをエージェントに与えることで、成功率が33.3%から47.7%へと大幅に改善することが確認されている（Claude Sonnet 4.5の場合）。これは、ゲームプログラミングが「コードを書く」プロセスと「結果を視覚的に確認し修正する」プロセスの密なループを必要とすることを示唆している。現在の多くのエージェントは、このループを自律的に回すためのマルチモーダル理解が下手だ。

複数ドメイン横断評価DomainCodeBench (2024)

DomainCodeBenchでは、一般的なコーディング問題で高い評価を得ているモデルが、実際の業務に近い開発領域でも同じように通用するとは限らないことを示している。評価は「正解できたかどうか」だけで単純に測るのではなく、出力されたコードがどの程度、正解の実装に近いかという観点で点数化されており、その結果、ブロックチェーン分野では比較的高い点を出すモデルでも、ゲーム分野ではスコアが下がる例が確認されている。

この要因は、ゲーム開発が特定のエンジンやフレームワークの膨大なAPI群、およびそれらが前提とする独自のライフサイクル（更新処理やイベント駆動モデル）に強く依存しているためである。単なるアルゴリズムの知識だけでは、プロジェクト全体の構造やAPI間の複雑な相互作用を解釈できず、適切なゲーム実装が行えない。

なぜコーディングエージェントはゲームプログラミングが下手なのか？

これらの文献を見てみると、コーディングエージェントにとってゲームプログラミングが困難な理由として、以下のような要因が考えられる。

  1. 視覚依存性：出力の正当性を判断するために、高度なマルチモーダルフィードバックを要する
  2. 実行時の不確実性：文法的な正しさが、視覚・動作・ゲームフィールの正しさを保証しない
  3. 深いドメイン知識：汎用ロジックではカバーできない、ゲーム実装のベストプラクティスや、ゲーム固有のフレームワークが存在する

これらの問題を乗り越えるためには、ゲームプログラミング固有のコーディングエージェント向けワークフローを詳細に設計する必要がある。視覚・動作理解の模擬的な実現や、ベストプラクティスの言語化・ツール化など、それを解決するアプローチはいくつか思いつく。だがそれらをゲーム全般に汎用的に整備することは難しい。しばらくはAIにとってゲーム開発は比較的困難なタスクであり続けるであろう。

ゲームプログラミングをエンジョイしていたら自作ゲームが500個になった

以下の私の個人サイト のアニメーションGIFを2分程度見続けると、私の作ったゲームのスクリーンショットを全て確認できる。

500個と言っても、多くは1ゲーム1分程度のミニゲームだ。大作はほとんど無い。せっかくだから内訳を調べてみた。

順位 種類 件数 割合
1 ワンボタンゲーム 245 48.1%
2 Flashゲーム 114 22.4%
3 ブラウザゲーム 88 17.3%
4 Windows用 14 2.8%
5 Palm用 9 1.8%
6 その他 8 1.6%
7 Java製 7 1.4%
8 P/ECE用 5 1.0%
9 iアプリ 5 1.0%
10 Wonder Witch製 3 0.6%
11 プチコン製 3 0.6%
12 PC-9801用 2 0.4%
13 Unity製 2 0.4%
14 Pocket Cosmo用 1 0.2%
15 Ruputer用 1 0.2%
16 Zaurus用 1 0.2%
17 PC-6001用 1 0.2%
合計 509

ワンボタンゲーム、Flashゲーム、ブラウザゲームあたりがミニゲームにあたる。Flashゲームは残念ながら大半がもう遊べない。Windows用は主にシューティングゲーム、一部はXbox 360でも動くXNA製。Wonder WitchはWonder Swan向けだったり、プチコンはSwitch向けだったり、コンシューマ機で動くゲームが少しある。

その他は弾幕記述言語BulletMLやミニゲーム用ライブラリcrisp-game-libなどゲームでない物。なので上の件数にはゲーム以外も入っているけど件数合計は509だからヨシ。

PalmとかP/ECEとか、iアプリ、Pocket Cosmo、Ruputer、Zaurusなどの昔のモバイルデバイス向けに作ったものもある。デバイスごとの特性に応じてプログラムを組むのは楽しい。

私が作ったゲームでWeb上に残っている最古のものは、プログラムの投稿雑誌であるマイコンBASICマガジン、通称ベーマガの1989年9月号に掲載されたPC-6001用ゲームMeteorite だ。N60-BASICで書かれた もので、ベーマガの1ページに収まる短いプログラムで実現されている。

このプログラムの最後の方には、DATA文で定義された謎の数列がある。この数列は当時のベーマガ読者には見慣れた、マシン語の定義部だ。BASICの処理速度では間に合わない、大量の隕石の落下処理などをZ80アセンブラで書き 、それを手作業で16進数のマシン語に変換するのだ。

限られた実行速度、限られた記憶容量の中で、いかに目的のゲームロジックを実現するか、これがマシン語時代のプログラミングの醍醐味だ。ソフトウェアレイヤーの中の極めて低レイヤーを直接扱うため、当時のハードウェアの特性をよく知ることが求められる。

逆に最新の自作ゲームは、ブラウザ上で動くワンボタンアクションミニゲームだ。JavaScriptで書かれた ものだが、ベースのコードはコーディングエージェント に書かせている。

コーディングエージェントに適切なツールセットを渡し、ゲームのアイデア生成から設計、実装、改良まで行わせるというプログラミングスタイル、これはマシン語を直接書くのと比べてはるかに高レイヤーの取り組みだ。ゲームの楽しさはどのような要素で構成されているか、ゲームをメタな視点から俯瞰し、それをLLMにどのように理解させるか、というところにプログラミングの楽しさが移っている。

長い間ゲーム開発を続けていけるのも、こういった低レイヤーから高レイヤーまで、その時代に合わせた様々なゲームプログラミングの楽しみがあるおかげだ。個人ゲーム開発は、その時々の流行りの技術スタックやデバイスを使った色々な試みを行うのにはとても都合が良い。粗削りな技術、言語、ライブラリ、デバイスでも、小さなゲームを個人で作る分にはいくらでもトライ＆エラーができるし、その荒削りさがゲームプログラミング体験の面白さにつながるのだ。

今アセンブラを学ぶ価値はほとんど無いかもしれない。でも長い間個人ゲーム開発を行って得られた広範な技術レイヤーの知識が、次々に現れる新しい技術をどう扱えば楽しめるかという、より良い開発体験を継続するための基礎体力になっている。パフォーマンスに対する肌感覚や、各レイヤーが提供する抽象化を正しく扱う能力、作りたいゲームを実現するのに最適な技術を見極める目利き、こういったものに還元されているのだ。

自分の知識が新しい技術への理解を助け、好奇心を絶やさずに続けられる。結局こういったことが大事なのかもしれない。

遊べるゲームをLLMに一発で作らせる、現在打率3割くらい

このリポジトリREADMEの'Zero-Touch Generation Examples'にあるゲーム群が、LLMにプロンプト・ツールと'Create a game'という指示を与えて一発で出てきたものだ。バランスなどに多少難ありだが、一応遊べるワンボタンゲームになっている。この程度のゲームが作られる確率がだいたい3割くらい。10個のうちの3つは遊べる。

今までは一発で遊べるゲームが出てくることはほぼ無かったので、3割といえども大したものだ。3割程度まで打率が上がった理由は、Claude Opus 4.5の能力の高さによるところが大きいが、今回作成したワークフローによるところもある。

LLM向けミニゲーム制作ワークフロー

LLMに、タグ選択 → 設計 → 実装 → 評価 → 改善という5段階のワークフローでゲームを生成させた。使用したプロンプトやツールは上記リポジトリにある。特徴的な点としては以下が挙げられる。

タグ駆動の発想

107種類のゲームメカニクスタグ （player-rotate, on_pressed-jump, field-auto_scrollなど）からランダムに数個を選び、それをインスピレーションの種としてLLMに渡す。重要なのは、タグを仕様として扱わないことである。矛盾するタグが選ばれた場合でも、それを創造的なチャレンジとして活用する。

強い制約による品質確保

  • ワンボタン操作: 押す・離す・長押しの3パターンのみ
  • 約150行のコード: スコープの肥大化を防ぐ
  • 単一フレームワーク: crisp-game-lib のAPIのみ使用

LLMは自由度が高すぎると一貫性を失いやすい。強い制約を課すことで、出力の品質を安定させている。

自動評価による客観的判定

生成されたゲームを攻略可能な入力パターンを遺伝的アルゴリズム（GA）で生成、プレイさせ、「上手いプレイ」のスコアと「単調入力」（連打、放置、押しっぱなし）のスコアを比較する。

GA比率 = GAのベストスコア / 単調入力の最高スコア

この比率が1.5を超えれば「スキルが報われるゲーム」として合格とする。比率が低ければ、詳細ログを分析して改善を行う。

でもまだ人手でのバランス調整が必要

GA評価を通過したゲームでも、人間がプレイしてバランスを調整することはまだ必要である。自動評価で「スキルが報われる」ことは確認できても、「適切な難易度か」「スコアの伸びがプレイヤースキルを反映しているか」は人間が判断せねばならぬ。スコアリングシステムや難易度曲線の調整はこの段階で行う。

バランス調整後、再度LLMに今度はそのゲームを「ジューシー」に、遊んでいて楽しい視覚的フィードバックを加えることを依頼する。このように「ルール・メカニクス」と「手触り・演出（ジューシーさ）」を分けて生成させることで、まずは純粋な「ゲームシステム」の生成にLLMを集中させることができる。LLMに「ゲームフィール」を加えさせるのはその後だ。

上記リポジトリの'Enhanced Game Feel Versions'にこれら調整を行った版がある。元のバージョンよりはだいぶ遊びやすく、また見た目に楽しくなっている、はず。

LLMにうまくゲームを作らせるコツ

このようなワークフローがそこそこうまくいったことを考えると、LLMに一発でゲームを作らせるには以下のような内容がカギになるだろう。

  • 制約は味方：LLMに「何でも作れる」状況を与えると、出力は発散しがちである。出力形式、使用技術、コード量を厳しく制限することで、品質が安定する。これはゲームに限らず、コード生成全般に適用できる話。

  • 評価の自動化が重要：「良いゲーム」の定義は曖昧だが、「スキルが報われるか」という一側面に絞れば数値化できる。何らかの測定可能な指標を設計できれば、LLMの出力を自動で評価・改善できる。

  • ドメイン知識は外部化：crisp-game-libのAPIや衝突検出の仕様、ワンボタンゲームの設計パターンなどは、すべてマークダウン文書として外部化されている。LLMの事前学習に頼らず、必要な知識をプロンプトとして明示的に与えることで、再現性と制御性が高まる。

  • 反復ループを設計：一発で完璧な出力を期待しない。評価 → 分析 → 修正のループを何回かまわすことを前提としてワークフローを設計した方が良い。

  • 関心の分離：メカニクスとジューシーさを別々のフェーズで扱うことで、各フェーズのタスクが明確になる。LLMは曖昧な指示より具体的な指示で良い結果を出す。「面白いゲームを作れ」より「このゲームにジャンプエフェクトを加えよ」のほうが成功率が高い。

ワンボタンミニゲーム以外のゲームも作れる？

たぶんまだ難しい。現状のワークフローにはいろいろ制約がある。

評価できるのは一側面のみ

GA比率は「スキルが報われるか」を測定するが、驚きや新規性、ゲームバランスの適切さは測定できない。評価数値が良くても、人間がプレイして面白くないゲームは存在する。

ドメイン固有の準備コストが高い

今回のワークフローが機能するのは、ワンボタンゲームという十分に制約されたジャンル、ヘッドレス実行可能なテスト環境、crisp-game-libという適切な抽象度のフレームワークを揃えたからである。これらを揃えるのはそこそこ大変であり、別のジャンルに適用するには同等の準備が必要になる。

シミュレーションの限界

GAは「最適なプレイ」を近似するが、人間のプレイとは異なる。人間が発見しにくい抜け道を見つけたり、逆に人間には自明な操作を見逃したりする。またワンボタンゲーム以外は「最適なプレイ」をさせることがそもそも難しい。

新規性の保証がない

LLMは学習データに含まれる既存ゲームの影響を受ける。タグを「インスピレーションの種」として扱い、類似ゲームとの差異を明示させる工程を設けているが、真に斬新なメカニクスが生まれる保証はない。

LLM自動ゲーム生成の時は近くて遠い

LLMによるゲーム自動生成は、強い制約と自動評価の組み合わせによって「遊べるゲーム」を生成できる段階には達している。現状のワークフローでは人間によるバランス調整を含むが、ゲーム評価指標の多様化、既存ゲームとの比較による新規性担保、プレイ動画などのマルチモーダル評価などを組み合わせれば、完全自動化に近づける可能性はある。

ただし、「面白さ」の完全な数値化は本質的に困難である。人間が面白いと感じる要素には、驚き、達成感、フロー状態への誘導など、単純な指標では捉えきれないものが含まれる。LLMがこれらを捉えるのがすぐそこか、あるいは本質的に難しいままなのか、その辺はまだまだ未知数である。

ゲームのアイデアはふわっと思いつき、その過程は言語化できない。なので、AIには任せられない

ワンボタンアクションミニゲームをAIにワンショットで生成させる試み は相変わらず続けている。今回はゲーム発想の基本方針 をGemini 3 Flashに与えて5つのゲームアイデアを出させた。その中から私はなんとなく以下が一番面白くできそうだと思い選んだ。

５. 角度制御：『ジグザグ・スライサー（Zig-Zag Slicer）』

「Direction Change」を極限までシンプルにした、反射と精度のゲーム。


ビジュアル: 狭い通路（壁は単純な直線）。自機は鋭い矢印。


操作（Press）: 進行方向の90度転換。


ルール: 自機は常に斜め45度の方向に直進する（右上または右下）。 ボタンを押すたびに、進行方向が右上から右下（またはその逆）へ切り替わる。 壁にぶつかると、物理法則に従って跳ね返る。


ゲームオーバー条件: 通路内に配置された静止した赤い球体（地雷）に接触する。


リスク・リターン: 通路の角（コーナー）にある狭い隙間を通ると「テクニカルボーナス」が入るが、わずかな入力遅延が壁への激突や地雷接触に繋がる。

このアイデアを見てうーんと考えているうちに、私の頭の中には以下のような、実際のゲームが動いている絵が直接浮かんできた。

screenshot

画面両端から複数の壁が迫るフィールドの中で、ボタンを押すたびに上下の進行方向が切り替わる自機を操作するゲーム。自機は壁に当たるとX軸方向に跳ね返る。自機が壁に潰されたり、画面左右から外に出るとミス。画面上下はつながっていて、上から出た自機は下から出現する。壁に跳ね返るたびにスコアが入り、またマルチプライヤーが1加算される。マルチプライヤーは1秒ごとに1つ減らされる。左右から迫る壁の間に入って素早くマルチプライヤーを稼ぐのが重要だが、壁に潰されるリスクもある。

ごく基本的なアイデアからこの具体的なゲームプレイ に至るまでの過程は、完全に直観的なもので、なぜ上記のアイデアがこのゲームになるのかはまるで説明できない。無理やり解釈すると、以下のようになるだろうか。

  • 物理法則に従って跳ねるボールを、進行方向をタップで変えながら動かすのは、ありがちだがベースのアイデアとしては良い
  • フィールドを工夫しないとあまりにもありがちなゲームになりそう
  • 左右から迫る壁というフィールドは、ブロック崩し的なフィールドとして分かりやすく、かつ潰されないようにするリスクもあって良さそう
  • 潰されるギリギリまで狭まった壁の間を素早く反射するのは楽しそう。じゃあこれに高得点を与えたい
  • 壁にあたるとマルチプライヤー獲得、だがマルチプライヤーは時間で減る、とするだけで、これに高得点を与えられるし、リスクリターンとして良くできているではないか

ただ、これは実際の発想を無理やりエミュレートしているだけで、本当のひらめきからはほど遠い物だ。こういったエミュレートからは、真に豊かなゲームアイデアの発想は得られないだろう。私がゲームの元となるルール群から、直接唐突に実際のゲームプレイに至るのは、今まで遊んだり作ったりしてきたゲームたちの経験、もっと言えばそれとも関係ない様々な経験に基づいて、謎の直観・直感というものでたどり着いている。この飛躍を今のAIでエミュレートする方法、それを考えることは面白そうだが、その結果得られるプロセスは実際のプロセスとは似ても似つかないものになる。

なぜ人にはこのような謎の考えの飛躍があるのか。結局、その人が今までの経験で得た、マルチモーダルかつその時の感情なども含んだ長大な学習データに基づく思考の連鎖から得られている、なんとも得体の知れない思考の帰結があるのだろう。地球上にいる膨大な人が個々の経験を持ち、かつそれらを組み合わせて物事を考えている。その結果多種多様な考えが世の中に散らばっている。

それに対して今のAIはインターネットという単一の経験に基づいて様々な発想をしなければいけないわけで、その制約はだいぶ大きい。ワンショットでのゲーム制作を可能にするためにも、AIには早く色々な経験をできるようになってもらって、無限ゲーム制作機として働いて欲しい。まずはオールアバウトナムコ掲載のゲームを全て遊んでもらって、その楽しさを分かるようになりたまえ。

Claude Code on the web で実現するどこでもゲーム開発

AI コーディングエージェントの登場により、エディタで直にコードをいじらずともプログラム開発が可能になった。最近はこれらエージェントをブラウザ上からも使えるようになった。たとえばClaude Code on the webがそのようなエージェントの一例だ。

これを使えばスマホでどこでもゲームが開発できるのでは？そう考えて作ったプロンプトやツールを、以下のリポジトリに置いた。

このリポジトリは 2024/3 から作っており、ここで LLM を使ったワンボタンアクションミニゲーム作りをいろいろ試行錯誤している。Claude のチャットインタフェースから、Cursor の IDE、CLI の Claude Code など、いろいろな環境を渡り歩きながら、試行錯誤を続けている。

ある意味この記事はこの試みの第 5 回である。

スマホでブラウザゲーム開発のワークフロー

Claude Code on the web は GitHub と連携して動作する。あるリポジトリを指定してそれに対してチャットを行うと、新たなブランチが作成され、そのブランチに対してエージェントが継続的に作業が行えるようになる。そのブランチでの作業が終わったら、プルリクエストを作成し、できた成果物を main/master に取り込む。

ブラウザゲーム開発であれば、この作業中に作成したゲームをブラウザ上で確認したい。だがこれら作業は個別のコンテナ環境内で行われ、そのネットワークアクセスはネットワークポリシーで管理されている。そのため、この環境で Web サーバを立ててゲームを動かしそれを外部から確認する、などはできない。

そこで役立つのがNetlifyなどのデプロイサービスだ。Netlify は GitHub と連携し、特定リポジトリのブランチの成果物を Web にデプロイすることができる。これを使えば、ブランチで作業中の内容をブラウザ上で確認できる。

これらを使った結果のワークフローは、例えば以下のようになる：

  1. ブラウザ上でコード編集：Claude Code との対話によりゲームロジックを実装
  2. コミット＆プッシュ：エージェントがGitHubブランチへ変更を反映
  3. 自動ビルド＆デプロイ：Netlifyが自動的にビルド、ブランチごとのプレビューURLを生成
  4. モバイルでの即座確認：生成された URL にアクセス、動作確認
  5. フィードバック＆改善：モバイルでの体験をもとに、再びブラウザ上でエージェントと対話して改善

「〇〇ゲームを作って」ではうまくいかない問題

ただ現状のコーディングエージェントはそんなにゲーム作りが得意ではない。単に「〇〇ゲームを作って」と丸投げすると、ゲームとして成り立ってない謎の挙動をするものが返ってくることがままある。そんなものをスマホ上からチャット UI だけで修正し続けるのはかなりの苦行だ。できれば最初からある程度ちゃんと遊べるゲームになっていて欲しい。

なのでブランチ元のリポジトリで、コーディングエージェント向けのゲーム開発指針をある程度プロンプトやツールで補強しておいた方が良い。今回は以下のようなアプローチを取った。

ゲームメカニクスタグのランダム選出による元ネタの生成

前に自作ゲームがどういったメカニクス、例えばプレイヤーの動き方や得点の方法などから構成されているかをタグとして整理した。

これは LLM が新しいゲームを生成するための仕組みでもあった。

今回はこれらのタグをスクリプトでランダムに選択し、それらを新たなゲームの発想の元ネタとした。

また、これらのタグがどのように実現されているかを、対応するゲームコードと紐づけることで示している。これは、そのメカニズムをどう実装すれば良いかを、エージェントが正しく把握するのにある程度役立っている、はずである。

構造化されたゲーム設計・実装プロセス

上記タグ選択に続き、以下の 6 つのフェーズでゲーム設計・実装は行われる。

Phase 0: タグ選択と初期検証
  ↓ ✅ タグ承認
Phase 1: 問題-解決の構造化
  ↓ ✅ ロジック検証
Phase 2: 創造的統合と新規性保証
  ↓ ✅ 創造性確認
Phase 3: 実装とプロトタイピング
  ↓ ✅ 基本動作確認
Phase 4: 検証とバランス調整
  ↓ ✅ バランス承認
Phase 5: 最終検証と完成承認
  ↓ ✅ 最終承認
完成

各フェーズには明確な完了基準と人間の承認ポイントが設定されている。これにより AI が独走することなく、人間の意図が各段階で反映される。

Phase 2 の新規性保証はタグの組み合わせが既存ゲームとどの程度異なるかをスクリプトでチェックしたり、Phase 4 のバランス調整は理想的なボタン入力を遺伝的アルゴリズムで生成・動作確認しその結果に応じてゲーム内パラメタを自動調整したり、みたいな機構もいれているのだが……正直これらがどのくらいうまく機能しているのかはよく分からない。

どちらかというと、途中の人間の承認ポイントで、人間が適切に方向転換させることで、遊べるゲームへの調整が簡単に行えることが、このプロセスにおいては重要である。そのためにも、エージェントに適切な完了基準を示し、あいまいな状態でのフェーズ完了を許さないことが大事だ。

で、実際にどんなゲームができるのか

先ほどのリポジトリのゲーム例一覧にある 4 つのゲーム（MAGNETIC PENDULUM、RICOCHET PINS、ARC SPIN、WIND RANG）ができたゲームの例だ。すごい独創的かと言われるとそうでもないが、ありきたりでもなく、バランスが取れているゲームがある程度できている。

これらゲームの開発が、実際上記のチャットでのフローで完結しているかというと、そうではなく、プルリクエストを受け付けてから PC 上である程度ソースコードを調整して最終バランス調整を行っている。それでもゲームのベースメカニクス実装はスマホ上で完了させることができ、これはなかなか良い開発体験だった。

ゲーム開発の楽しさは、エディタでコードを書いてゲームを実現することだけでなく、こういうメカニクスはどうか？というアイデアを試し、遊び、改良するサイクルにもある。コーディングエージェントは、そのサイクルを劇的に加速する。スマホという制約された環境でさえ、思いついたメカニクスを30分で形にできる。これは、いわゆる創作の民主化と呼ばれる動きの、ゲーム版の一例かもしれない。

いつでも、どこでも、だれでも、ゲームのアイデアを形にできる。そんなゲーム＆ウォッチ感覚の開発体験が、選択肢の一つとして現実的になりつつある。

CodexとClaudeの交互浴でコードベースを整わせる

最近、コーディングエージェントを用いた開発で、ある一つの習慣を導入している。それは、性質の異なる二つの大規模言語モデル（LLM）、CodexとClaudeを、一つのコードベースに対して交互に使い分けるというものだ。これを個人的に「コードベースの交互浴」と呼んでいる。温浴と冷浴が心身を整えるように、このアプローチもコードベースの品質向上に役立つのではないかと考えている。

具体的な手法はシンプルで、1週間の最初の数日はCodex (GPT-5-Codex)を使いコードを開発、残りはClaude Code (Claude Sonnet 4.5)を使う。これだけ。ただ、この二つのコーディングエージェント間には直接の記憶共有がないため、作業の引き継ぎにはBACKLOG.mdという単一のマークダウンファイルを利用する。ここには、次に取り組むべきタスクリストと、直近の作業ログを常に記録しておく。AIを切り替える際には、このファイルの最新の内容をプロンプトに含めることで、プロジェクトの文脈をスムーズに引き継ぐ。

この習慣が始まったきっかけは、品質向上という高尚な目的ではなかった。むしろ、Weekly limitのような利用上限や、多くのLLMサービスに見られる月額20ドルの次が200ドルになるような極端な価格設定といった、現実的なコスト制約が背景にある。200ドルを払うのは難しいが、20x2 = 40ドルならまあ、みたいな感覚。

ただ、このアプローチを続けるうちに、これが単なる次善策ではなく、むしろ積極的にコードの品質を高める有効な戦略なのではないかと考えるようになった。複雑な設計や開発を得意とするCodexがシステムの骨格を組み上げ、その土台の上で、創造的なタスクを得意とするClaudeが新たな発想で機能拡張や改善を行う。あるいは逆に、Claudeが出したユニークなアイデアを、Codexが堅牢なコードとして実装する。そういった良好な補完関係が見られる、ような気がする。

この感覚は、LM vs LM といった近年の研究が示す知見と一致する。これら研究によれば、単一のLLMは、自らが生成した誤った文脈や前提に思考が制約されやすい。そのため、同じ思考プロセスをなぞる形で応答を続けてしまい、結果として根本的な誤りを自ら見つけ出して訂正することが困難になる傾向がある。一度生成した論理に固執し、同じ思考プロセスを繰り返してしまう傾向があり、これは一種の「確認バイアス」とも言える。自身の論理の延長線上では、その根本的な欠陥に気づくことが難しいのだ。そこで、クロスチェックが有効となる。あるAIが生成したコードや設計思想を、全く異なるアーキテクチャを持つ別のAIに評価させることで、人間が同僚にレビューを依頼するのと同様の、客観的なフィードバックが得られるのである。

結局のところ、どんなに優れたLLMでも、それ一つで完璧ということはないのだろう。それぞれに得意なこと、苦手なことがあり、知識にも偏りがある。だとしたら、我々開発者が異なる視点を持つ同僚とコードレビューをし合うように、特性の違うAIたちにコードを交互にレビューしてもらう。この「コードベースの交互浴」は、LLM時代のソフトウェア開発における、一つの有効な品質管理パターンとなり得る、かもしれない。