AI個人ゲーム開発で
直面した10の課題と
その解決策

1. 仕様が決まっていないまま作り始めてしまう

何が起きたか

個人開発では、着手時点で仕様のすべてが固まっていることはまずない。今回も数値バランスや融合の組み合わせ、解放順、使用技術などは未定のままスタートした。この状態でAIに「いい感じに作って」と頼むと、AIは未定の余白を独自の解釈で埋めてしまう。結果として、どこが人間の意図で、どこがAIの独自解釈なのか、後から見分けがつかなくなる。

どう解決したか

仕様書側で「決定事項」と「未定事項」を明確に分離した。その上で、「未定項目はAI側で仮決めして進めてよいが、仮決めした内容は必ず一覧に記録する」という運用ルールを敷いた。これにより、テストプレイ後に見直す際、どれがAIの仮決定だったのかを一覧で追えるようになった。

ほかの開発者の例

Claude Codeでパズルゲームを開発した開発者も、AIが実装を急ピッチで進めるからこそ、詳細な要件定義や、実装スコープ・タスク粒度の管理が必要だったと振り返っている[1]。また対話型AIでWebゲームを制作した別の開発者も、AIは指示を好きなように解釈するため、指示は極めて具体的でなければならないと指摘している[2]。

すべてを事前に決めておくアプローチと、未定事項を未定として明示して渡すアプローチは、向きは逆だが、ねらいは同じだ。決まっていないところを、AIに勝手に埋めさせないことだ。

2. コード肥大化による命名の衝突と、別画面の破壊

何が起きたか

「醸造所」というゲームのスタイル（CSSクラス）を追加した際、既存の「ボール落とし」画面と同じクラス名を付けてしまった。その結果、ボール落としの画面が12ピクセルに縮み、斜めに回転した状態で表示される事故が発生した。修正していたのは醸造所だったにもかかわらず、全く別のゲーム画面が壊れていたのだ。

どう解決したか

該当のクラス名を変更して修正した。再発防止策として、「スタイルに名前を追加する際は、同じ名前が存在しないか事前に検索する」ことをルールとして明文化した。コードベースが1万行を超える規模になると、人間もAIも全体構造を記憶しきれない。記憶に頼るのではなく、「検索を挟む」という手順を決まりにすることが有効だった。

ほかの開発者の例

前述のパズルゲーム開発者も、AIが次々と実装を進めることでリポジトリ構成の把握が難しくなり、コードが雑多になりやすいと述べている。対策として、コーディング規則や用語の定義を明記することを挙げている[1]。

3. AIは会話（セッション）が切り替わるとルールを忘れる

何が起きたか

3日間にわたる開発は、単一の対話セッションでは完結しない。別のセッションに移ると、AIはそれまでに決めた設計方針も、過去の失敗も知らない状態でリスタートする。そのままでは、同じミスを繰り返しかねない。

どう解決したか

プロジェクト共通のルールと過去の失敗事例を、セッション起動時に必ず読み込まれる指示ファイル（Claude Codeにおける CLAUDE.md）に簡潔にまとめた。「日英テキストを同時に更新する」「過剰な説明文を置かない」といった方針に加え、「名前を追加する前に重複検索すること（同名追加で別画面を壊したことがある）」「ブラウザのセーブを書き換えないこと（書き換えてしまったことがある）」のように、実際の失敗事例を理由として併記した。

公式の説明

Claude Codeの公式ドキュメントでも、セッションは毎回まっさらな状態で開始されること、CLAUDE.md は毎セッションの冒頭で読み込まれること、そして指示は具体的かつ簡潔であるほど守られやすいことが説明されている[3]。長文で網羅するのではなく、要点を絞って伝えるのが鉄則だ。

4. 「確認完了」の報告が、実は一部しか見ていなかった

何が起きたか

AIから「全画面の確認が完了した」と報告を受けた。しかし、AIが検証していたのはグラフィックの中身だけで、ページ全体のレイアウトや文字の重なり、大画面での余白バランスなどは見ていなかった。AIは明示的に指示されない限り、自身が出力したコードがブラウザ上で実際にどう描画されているかを「画面」として見ていない。

どう解決したか

全画面をページ単位で自動キャプチャするスクリプトを構築した。16本のゲーム、実験室、本部、設定画面、マイルストーン演出に至るまで、日本語・英語の両環境で1枚ずつスクリーンショットを書き出す。AIはその実画像をもとに検証を行い、人間も同じ画像を目視チェックする。レビューのプロセスそのものをツール化した形だ。

ほかの開発者の例

AIエージェントに作業成果を視覚的に証明させる手法（Visual Verification）を論じた記事でも、AIの「修正しました」という報告はしばしば誤りを含むと指摘されている。成功報告のたびにスクリーンショットを撮影させること、リファレンス画像をプロジェクト内に保持すること、コンソールエラーも併せて確認することが推奨されている。ただし静止画キャプチャでは、画面のチラつきやタイミングの不具合までは検知できない点にも言及されている[4]。

5. 見ていた画面が、修正前の旧グラフィックだった

何が起きたか

グラフィック素材を新しいものへ差し替えた後、確認用に画面キャプチャを実行した。しかし、写っていたのは差し替え前の旧グラフィックだった。素材を「該当ゲームを開いてから」読み込み始める実装になっていたため、読み込みが完了するまでの数秒間は旧グラフィックが表示されていたのだ。修正したはずのものを、未修正の状態でチェックしていた。

どう解決したか

ゲームの起動時に素材の読み込みを始める設計へと改修した。これにより、テスト時の誤認を防げるだけでなく、実際のプレイヤーにとっても、画面を開いた瞬間に旧グラフィックが見えてしまう問題が解消された。「検証プロセスの課題」だと思っていたものが、結果的に「ゲーム体験自体の品質向上」につながった一例だ。

6. 確認のつもりで、テストプレイ中のセーブデータを書き換えた

何が起きたか

ゲーム終盤の画面を検証するには、終盤まで進めた状態が必要になる。AIが検証用の状態を作ろうとブラウザを操作した際、人間が実際に進めていたテストプレイ中のセーブデータを書き換えてしまった。確認用のつもりで操作した画面が、そのセーブデータを使っていたのだ。ブラウザゲームは同じ場所で開く限り、同じセーブデータを参照してしまう。

どう解決したか

「検証用の状態づくりは、通常プレイのセーブとは切り離されたサンドボックス（使い捨て環境）のみで行う」という鉄則を設けた。専用の検証環境でゲームを起動し、序盤・中盤・終盤の各状態をスクリプトで作ってキャプチャする仕組みを整備。人間がプレイ中の画面に対しては、AIは「見るだけ」にした。

この教訓はゲーム開発に限らない。AIに作業を任せるなら、「検証環境と本番環境の分離」が重要になる。

7. 進行が速すぎる。遅くすると今度は止まる

何が起きたか

放置ゲームの面白さの根幹は、数値の成長曲線にある。初期バージョンは進行速度が速すぎたため、数値を調整したところ、ある地点を境に「急激に暴走する」か「足踏みして進まなくなる」かの極端な2択に陥った。原因は、倍々で増える計算式と、べき乗で増える計算式が混在していたことだった。

どう解決したか

成長曲線の計算モデルを「べき乗」ベースへと統一した。さらに、100時間分のゲーム進行を4分弱でシミュレーションする自動試走スクリプトを構築。パラメータを調整するたびにこの試走を回し、どのタイミングで進行が停滞し、どこで暴走するかを確認できるようにした。

ただし、「単に進行を遅くするだけでは退屈になる」というゲームデザイン上の課題は、数式だけでは解決できない。数時間おきに新たな機能やゲームがアンロックされるよう、後半のコンテンツ自体を増やすことで対応した。

参考になる資料

放置ゲームの数学的モデルに関しては、Anthony Pecorellaによる連載記事「The Math of Idle Games」が参考になる。基本設計として、コストは指数関数で増加させ、生産量は線形または多項式で伸ばす。序盤は生産がコストを上回るが、やがてコストが追いつく。倍率強化や「転生（プレステージ）」は、その力関係を一時的に動かすための装置であると解説されている[5]。

8. 自動キャプチャツールが無限ループでフリーズする

何が起きたか

全画面の自動キャプチャを実行中、処理が途中で止まった。画面内のオブジェクトを積み上げる描画のループ処理が、特定の条件下で終わらなくなっていたのだ。人間が目視していればすぐに気づく異常も、バックグラウンドの自動処理は沈黙したまま止まり続けてしまう。

どう解決したか

該当のループ処理に上限回数を設け、キャプチャツール側にも一定時間で処理を打ち切るタイムアウト機能を実装した。AIに長時間の自動処理を委ねるほど、「異常停止に気づける仕組み」が不可欠になる。

9. グラフィックのトーンが揃わず、安っぽく見える

何が起きたか

開発初期は幾何学図形だけで画面を構成していた。動くには動くものの、プロトタイプ感が抜けずチープに見える。配布されている素材へ置き換えるにしても、出どころの違う素材をそのまま並べたのでは統一感が出ない。当初予定していたキャラクター素材は、最終的に採用を見送った。

どう解決したか

本格的な3D制作ソフトは使わず、軽量なレンダリングツールをPython（Pillow）で自作した。CC0ライセンスの3Dモデルを読み込み、すべて同一の条件で2D画像として書き出すパイプラインを作ったのだ。具体的には「カメラ角度は正面から24度の俯瞰」「光源は左上手前の単一ライト」「外周に濃紺の細いアウトライン」「書き出し時にネイビーとゴールドの画面に合わせて色を塗り替える」といった条件を固定。合うモデルがないものは、同じツール上で箱や円柱を組み合わせて作成した。ライティングが統一されているので、異なる素材を並べても浮かない。

開発フローにも工夫を加えた。まず「工場」の1本に絞って素材を使った描き方を作り込み、3回のリテイクを経てスタイルを確立。基準となるパイプラインが固まった段階で、残りの15本へ横展開した。基盤が整ったあとの15本は速かった。

なお、配布モデルに置き換えることが常に正解とは限らない。「精錬所」の炉は、配布モデルを適用したところ四角くて素っ気なくなってしまったため、自作の形状へ戻した。

ほかの例

ゲーム向け画像生成サービスを提供する会社のブログでも、多くの画像生成AIは1枚ずつの素材の問題は解決するが、全体の一貫性の問題は解決しない、という趣旨の指摘がされている。自社製品のプロモーションという側面はあるものの、「単体では優れていても並べると揃わない」という課題感は、今回の開発実感とも一致している[6]。

10. 素材のライセンス混在と、AI生成素材の管理

何が起きたか

不足する素材を配布サイトから集める際、ライセンスは素材ごとにまちまちだった。さらに今回採用した3Dモデルのうち13点は、配布元において「AIで作った」と申告されているものだった。後から「どの素材が使ってよいものか」「どれがAI由来か」を洗い出し直すのは難しい。

どう解決したか

素材を導入する都度、1点ずつライセンスを確認し、「入手元」「ライセンス」「AI生成の有無」を記録する管理台帳を作成した。ライセンス条件が分からない素材は採用しない方針を徹底。今回使用した素材は、グラフィックのもとになった3DモデルがCC0（Kenney、3DAssets.dev）、効果音もCC0（Kenney）、フォントはSIL OFLだ。このクレジット一覧はゲーム本体にも同梱して配布している。

使った素材の配布サイト

• Kenney: 3Dモデルおよび効果音（CC0）
• 3DAssets.dev: 3Dモデル（CC0 / 使用した13点は配布元にてAI生成と申告）
• Shippori Mincho と Zen Maru Gothic: 書体（SIL OFL 1.1）
• ライセンスの本文：CC0 1.0 / SIL Open Font License

※配布サイトの条件は更新される可能性があるため、利用時は必ず各素材の個別ページを確認してほしい。

公式の説明

Kenney公式サイトでは、素材はCC0であり、商用利用可能かつクレジット表記も任意である旨が説明されている[7]。

一方、将来的にSteamで配信する場合はAI生成素材の扱いに注意が必要だ。Steamworksの公式ドキュメントによると、コンテンツ調査（Content Survey）にAIについての項目があり、ゲームに含まれてプレイヤーが目にするコンテンツ（画像、音声、テキスト、翻訳等）が対象となる。開発時にAIの助けで作った「事前生成コンテンツ」と、実行時に生成する「ライブ生成コンテンツ」に分類され、該当する場合はその内容を説明しなければならない[8]。現時点ではブラウザ公開のみだが、将来のプラットフォーム展開を見据えて、AI生成素材を一覧にまとめた。