連休を使って、「AI Codingがここまで成熟した2026年、個人ゲーム開発はどこまで加速できるのか？」を検証してみました。
結論から言うと、構想から約12時間で「ゲームループが完結し、実際に動かして遊べるプロトタイプ」を形にすることができました。
AIが存在しなかった頃なら、設計から手触りの検証まで1か月以上溶かしていたであろう作業量です。ただし、実際に手を動かしたことで「AIが爆速で片付けてくれる領域」と「人間が泥臭く介入しなければ絶対に破綻する境界線」が痛烈に見えてきました。
その開発ログと、実際に踏み抜いた落とし穴を共有します。
- なぜGodot 4を選んだのか：AIとの親和性が異常に高い
以前はUnityを触っていた時期もありましたが、個人で小さく素早くプロトタイプを作るなら、現状 Godot 4 が最もストレスフリーだと感じています。
■ 開発体験の比較
・Unity：プロジェクト起動やビルドに数十秒待機し、AIとの往復で思考が止まる
・Godot 4：1秒でデバッグ起動し、Codexとの高速イテレーションが途切れない
特にAI開発目線で優れていると感じたのは以下の3点です。
起動とイテレーションが1秒
とにかく軽量。AIにコードを書かせて「動かして確認する」という往復を数十回繰り返す開発において、この軽さは最大の武器になります。
GDScriptとLLMの相性の良さ
構文がPythonライクで極めて素直なため、Codexが出力するコードのシンタックスエラーやコンパイル落ちがC#に比べて格段に少ないです。
シーンファイル（.tscn）が完全なテキスト
Godotのシーン構成はシンプルなテキストファイルで記述されています。これがAIにとって扱いやすく、ノードの追加やパラメータ修正をプロンプト経由で直接指示できます。
さらに今回は、GitHubで公開されている godot-mcp を導入しました。CodexがMCP経由でGodotのコンソール出力やエラーログを自律的に取得できるようになるため、「エラーが出たからログをコピペしてAIに貼る」という不毛な往復がほぼゼロになりました。
- 仕様決めと市場リサーチ：AIを迷走させないための前提
AIにいきなり「面白いゲームを作って」と頼むと、高確率で機能が肥大化して空中分解します。まずはコアとなるゲームループを絞り込む必要がありました。
今回目指したのは、「終末世界でレストランを営む」というテーマです。
・昼のフェーズ（探索・収集）：敵を倒す → 食材や資材を回収 → 帰還
・夜のフェーズ（調理・提供）：食材を作業台へ運ぶ → 調理 → 来客に提供 → 報酬獲得
・大循環：得た報酬で設備や装備を強化し、次の日の探索範囲を広げる
ただ、個人開発で最も避けたいのは「苦労して実装したのに、そもそも誰も求めていない（または手触りが単調すぎて即離脱される）ゲームループを作ってしまうこと」です。
そこで今回は、Codexに仕様プロンプトを投げる前に、普段アプリの市場動向やリサーチに使っている 
市場で長期的にエンゲージメントを保っているタイトルの傾向を見ていくと、やはり「昼夜の明確なアクション切り替え」や「探索と作業（クラフト/料理）のテンポ良い分離」が、小規模開発でも初期離脱を防ぎやすい鉄板構造であることがデータからも確認できました。
「このループなら需要があり、スコープも1人でコントロールできる」という確証を持てた状態で、Codexとの具体的な設計セッションに入りました。
- progress.txt とセッション自動化：Sprintを機械的に回す
タスクの進行管理では、コンテキスト長の肥大化による「記憶喪失」と「Tokenの無駄遣い」を防ぐため、シンプルな分割スクリプトを組みました。
Codexと壁打ちしながら仕様を16個のステップに細分化する。
それを progress.txt というタスクリストに書き出す。
1つのセッションにつき1つのタスクだけを消化させ、終わったらチェックを入れる。
3ステップごとに独立した「Reviewセッション」を挟み、全体の整合性をチェックする。
■ progress.txt のイメージ
[x] Step 1: プレイヤーの基本移動と入力受付
[x] Step 2: 昼夜切り替えタイマーとステートマシンの構築
[x] Step 3: レビューセッション（コードの肥大化・循環参照チェック）
[ ] Step 4: 食材インベントリと作業台のインタラクション
...
Codexに「次のタスクを読み込んで着手し、完了したら進捗ファイルを更新する」スクリプトを書かせたことで、人間は「コードを直す人」ではなく「出来上がったタスクを承認する人」として動けるようになりました。
- 素材生成と直面した「AIの壁」
ロジックが組み上がった後、プロトタイプを動かすために素材の流し込みを行いました。しかし、ここから一気に「自動化の限界」と手作業の泥臭さが顔を出します。
① スプライトのスタイル崩壊
Codexに「必要なアセット一覧をリスト化し、サブエージェントを立ち上げて画像生成を行え」と指示を出したところ、素材自体は数分で揃いました。しかし、同じ「レトロ調ピクセルアート」と指定しているにもかかわらず、アイテムごとの解像度感やパース、輪郭線の太さがバラバラになります。
結論として、AI出力のそのまま採用は難しいと感じました。「人間がラフを描く → 画像生成でディテールアップ → 最後に手動で色調とパレットを統一する」というパイプラインを挟まないと、統一感のあるゲーム画面にはなりませんでした。
② BGM生成におけるプロンプトの罠
BGMにはSunoを使用しました。最初、ゲームの雰囲気に合わせて日本語で「終末の寂れた酒場、少し哀愁のあるアコースティック」といった指示を出していたのですが、なぜか何度生成しても中華古風なメロディに引っ張られてしまいました。
不思議に思って英語プロンプト（Post-apocalyptic acoustic ambient, dusty diner, melancholic guitar）に切り替えたところ、一発でイメージ通りの空気感になりました。生成AIの学習データの偏りや言語トリガーの癖は、まだまだ意識してハンドリングする必要があります。
③ 手触りとUIの「違和感」はAIには見えない
最も苦労したのは、手触り（ゲームフィール）の調整です。
Codexは「仕様通りに動くコード」や「エラーのない実装」は完璧にこなします。しかし、以下のような問題には全く気づいてくれません。
・UIの文字が2ピクセルだけベースラインからズレていて気持ち悪い
・食材を置いたときの手応え（SEやヒットストップ）がなくて操作感が硬い
・敵の攻撃予兆から発生までのフレームがシビアすぎて理不尽に感じる
画面を見て「なんか触っていて気持ちよくないな」と感じる直感や、プレイヤーが無意識にストレスを感じるポイントは、現状のLLMの推論では拾いきれません。結局、何度も自分でキーボードとマウスを握り、「ここを0.1秒遅らせて」「カメラシェイクを少し足して」と細かく人間がディレクションを出し続けることになりました。
- まとめ：人間がやるべき領域
今回の12時間の実験で感じたのは、「AI Codingによって、コードを書くハードルは劇的に下がったが、ディレクションの重要度はむしろ上がった」という事実です。
■ 企画・設計
・AIが担う領域：仕様の細分化、タスク分解
・人間が手放せない領域：市場データに基づくテーマ選定、ループの採否
■ 実装
・AIが担う領域：GDScriptの記述、エラー解析
・人間が手放せない領域：手触り（ゲームフィール）の官能評価、UI微調整
■ 素材
・AIが担う領域：アセットの叩き台生成、バリエーション展開
・人間が手放せない領域：世界観のトーン＆マナー統一、パレット調整
コードを1行ずつ書く職人から、AIという優秀な実装チームに「何を良しとするか」の基準を提示し続けるディレクターへ。開発の比重が完全にシフトした感覚があります。
個人開発のハードルは間違いなく過去最低になっています。次は今回のプロトタイプをベースに、Steamやitch.ioに向けたブラッシュアップを進めてみるつもりです。