自作ゲームの作成の継続が難しいのと作成が難しい現実

AIと自作ゲーム作成の現実 ── 夢は描けるのに、なぜ完成しないのか

「誰もが作りたいゲームを持っている。しかし完成するゲームは、そのごくわずかだ」── インディーゲーム開発者の間で語られる、静かな真実

AIが「民主化」したはずの夢

2023年以降、生成AIの爆発的な普及によって、「ゲーム開発の民主化」という言葉がよく聞かれるようになった。

ChatGPTにコードを書いてもらう。Midjourneyでキャラクターのイラストを生成する。Suno AIで BGM を作る。AIによる音声合成でボイスをつける。かつては数人のチームと膨大な予算が必要だったことが、一人でも、お金をあまりかけずにできる時代になった。

しかし現実はどうか。

AIを使い始めたゲーム開発者の多くが、数ヶ月後に同じ場所で立ち止まっている。フォルダの中には未完成のプロジェクトが積み重なり、Discordのサーバーには「開発日誌 #1」の投稿だけが残り、あの高揚した「ゲームを作るぞ」という気持ちはどこかに消えてしまっている。

AIは夢を見せてくれた。しかし夢を完成させてはくれなかった。

なぜか。何が難しいのか。そしてAIとどう付き合えばいいのか。

この記事では、自作ゲーム開発の「本当の難しさ」を、AIとの関係を軸に正直に語っていく。

第一章：最初の罠 ── 「AIがあれば作れる」という幻想

プロトタイプは2時間で動く

AIを使ったゲーム開発の最大の魔力は、最初の手応えが異常に速いことだ。

「簡単なRPGを作りたい」とChatGPTに伝えれば、数分でPythonやUnityのコードが生成される。「見下ろし型のアクションゲーム」を作りたければ、GodotやUnityの基本的なコードをAIが書いてくれる。画像もAIで生成できる。UIのデザインもAIに提案してもらえる。

数時間後には、なんとなく動くプロトタイプができている。キャラクターが動く。当たり判定がある。画面が出る。

この瞬間の興奮は本物だ。「俺、ゲーム作れるじゃん」という確信が生まれる。SNSに開発日誌を投稿したくなる衝動が起きる。

しかしここが罠だ。

プロトタイプと「ゲーム」の間にある深淵

動くプロトタイプは、ゲームではない。

ゲームとは何か。それは**「遊べる体験」の完結した形**だ。そこには以下のすべてが必要だ。

明確なゲームループ（始まりと終わり、目的、フィードバック）
バランス調整（難しすぎず、簡単すぎず）
バグのない安定した動作
UI/UXの整合性
セーブ・ロード機能
タイトル画面、ゲームオーバー画面、クリア画面
チュートリアルまたは直感的な操作説明
音響（BGM、効果音）
最終的なパッケージングと配布

AIが一瞬で作ってくれたプロトタイプは、この一覧の最初の一歩を踏み出しただけだ。残り95%が待っている。そしてその95%のほとんどは、AIが「全部やってくれる」ものではない。

第二章：継続できない本当の理由

理由①：「楽しいフェーズ」と「辛いフェーズ」の非対称性

ゲーム開発には、大きく分けて「楽しいフェーズ」と「辛いフェーズ」がある。

楽しいフェーズ

アイデアを考える
コンセプトアートを描く（またはAIで生成する）
新しいシステムのプロトタイプを作る
「これ面白いかも！」という発見をする

辛いフェーズ

既存のコードのバグを延々と直す
バランス調整で同じステージを100回プレイする
UIを1ピクセル単位で調整する
セーブシステムを一から設計する
エラーメッセージと格闘する

AIの登場によって、「楽しいフェーズ」のコストが劇的に下がった。アイデアをすぐ形にできる。コンセプトアートを数秒で生成できる。新機能のプロトタイプをAIが書いてくれる。

しかし「辛いフェーズ」は、AIが来ても本質的には変わっていない。

むしろ問題はここにある。楽しいフェーズが速くなったことで、辛いフェーズとの落差がより大きく感じられるようになったのだ。

アイデア出しが2時間でできるなら、バグ修正で3日費やすことへの忍耐がより一層難しくなる。「また新しいゲームを始めたほうが楽しいんじゃないか」という誘惑に負けやすくなる。

これが、AIが普及して以降に「未完成プロジェクトの墓場」が増えた理由の一つだ。

理由②：スコープクリープ ── 終わらない「もっと良くしたい」

自作ゲームが完成しないもう一つの大きな理由は、**スコープクリープ（scope creep）**だ。

当初の計画：「シンプルなパズルゲームを作る」

1週間後：「戦闘システムも入れたら面白くない？」

2週間後：「キャラクターに個性を持たせてセリフを入れよう」

3週間後：「ストーリーがあったほうがいいな。世界観を作ろう」

1ヶ月後：「このゲーム、RPGにしてもいいかも」

気がついたら、当初の10倍の規模になっている。そしてその規模に自分のスキルと時間が追いつかなくなり、プロジェクトは沈没する。

AIはこのスコープクリープを加速させる側面がある。

「こんな機能も追加したい」と思ったとき、昔はそれが技術的に難しければ諦められた。しかし今はAIに聞けばコードが出てくる。「できそう」と思えてしまう。だから追加してしまう。そしてプロジェクトはどんどん膨らんでいく。

理由③：AIコードの「ブラックボックス問題」

AIが書いたコードは動く。しかし自分はそのコードを理解していない、という状況が生まれやすい。

最初のうちはいい。動いているから問題ない。しかし開発が進むと、AIが書いたコードAとAIが書いたコードBが干渉し始める。謎のバグが生まれる。

「AIに聞けばいいや」とAIに問い合わせると、新しいコードが返ってくる。それで直ることもあるが、また別の問題が生まれることも多い。やがて、コードベース全体が「自分が理解していないコードの集積」になっていく。

これは恐ろしい状況だ。何かを変えると何かが壊れる。なぜ壊れるかわからない。AIに聞いても根本を直してくれない。プロジェクトは「触るのが怖いもの」になっていく。

そしてある日、開発者は静かにフォルダを閉じる。

理由④：孤独と承認欲求の問題

一人でゲームを作ることは、極めて孤独な作業だ。

チームで作っていれば、仲間の存在がモチベーションになる。締め切りがある。誰かに見せる機会がある。しかし一人では、自分を動かすのは自分だけだ。

SNSへの開発日誌投稿は、この孤独を和らげる有効な手段だ。しかし諸刃の剣でもある。

いいねが少ないと「誰も興味ないんじゃないか」と感じる。他のゲームが注目を集めているのを見て「自分のは地味すぎる」と思う。完成もしていないのに「どうせ誰もプレイしない」という結論に早々と至る。

AIが作業の効率を上げても、この孤独と承認欲求の問題は解決してくれない。むしろ、AIが高品質なものを素早く作ってくれるほど、「こんなクオリティのものを一人で作って意味があるのか」という比較が辛くなる。

第三章：AIと自作ゲーム開発の本当の関係

AIは「優秀だが無責任な外注先」だ

AIをゲーム開発に使う際、最も適切な比喩は「優秀だが無責任な外注先」だと思う。

外注先に仕事を頼めば、成果物は返ってくる。しかしその成果物の品質管理、統合、最終的な責任はすべてあなたにある。外注先はプロジェクト全体を理解していないし、理解しようともしない。あなたが指示したことをこなすだけだ。

AIもそうだ。「このコードを書いて」と言えば書いてくれる。しかしプロジェクト全体の設計を理解してくれているわけではない。前のコンテキストを引き継いでくれているわけでもない（会話を続けない限り）。最終的にゲームとして成立させる責任は、あなたにある。

この認識がないまま「AIが全部やってくれる」と思い込んで始めると、早晩壁にぶつかる。

AIが得意なこと・苦手なこと

AIとうまく付き合うために、何が得意で何が苦手かを正確に理解しておくことが重要だ。

AIが得意なこと

ボイラープレートコード（繰り返しの定型コード）の生成
特定のアルゴリズムの実装
バグの原因候補の提示（ただし診断は不確実）
コードのリファクタリング提案
ドキュメントのドラフト作成
アイデアのブレインストーミング
画像・音楽・テキストの生成（専門ツール経由）

AIが苦手なこと

プロジェクト全体の一貫した設計
長期にわたるコンテキストの保持
「このゲームが面白いかどうか」の判断
プレイヤーの感情体験の設計
バランス調整（数値の感覚的な調整）
自分のコードが他のコードとどう干渉するかの把握
「完成させる」というモチベーションの提供

要するに、AIは局所的なタスクの実行者として優秀だが、プロジェクト全体のオーナーにはなれない。オーナーはあなただ。

第四章：完成しない構造的な問題

インディーゲーム開発の「完成率」の現実

これは自作ゲームに限った話ではない。ゲーム開発全体の構造的な問題だ。

ゲームジャム（短期間でゲームを作るイベント）のデータを見ると、参加者が提出できる割合は一般に40〜60%程度だ。しかしこれは72時間〜1週間という極めて短い期間での話だ。

長期プロジェクト（数ヶ月〜数年）の完成率はさらに低い。多くの推計によると、個人や小規模チームが始めたゲームプロジェクトのうち、何らかの形でリリースまで至るのは10%以下だと言われている。

これはAI以前からの問題だ。ゲーム開発は本質的に、完成が難しいメディアだ。

なぜか。

ゲームの「完成」はゴールが見えにくい

小説なら「書き終えた」という明確な終わりがある。絵画なら「これ以上描かない」と決めれば終わりだ。しかしゲームの「完成」は曖昧だ。

バグはまだある。直すべきか？どこまで直せば「完成」か？
バランスはまだ悪い。どこまで調整すれば「完成」か？
グラフィックはまだ粗い。どこまで磨けば「完成」か？
コンテンツは少ない気がする。どこまで追加すれば「完成」か？

この「完成の定義がない」という問題が、開発者を永遠の改善ループに引き込む。そしていつか疲弊して、プロジェクトが静かに死んでいく。

技術的負債の蓄積

ゲームを作り続けると、技術的負債が蓄積する。

最初に書いたコードは、後から見ると汚い。拡張性がない。変更すると他のところが壊れる。「最初から設計し直したい」という欲求が生まれる。

しかしリファクタリングには時間がかかる。そしてリファクタリング中には新しい機能が追加できない。「面白くなる作業」をしていない時間が続く。これもモチベーション低下の原因だ。

AIが書いたコードは特にこの問題が深刻だ。AIは一貫した設計思想を持たず、その場その場で最適と判断したコードを書く。それらが積み重なると、保守性の低いカオスなコードベースが生まれやすい。

第五章：それでも作り続ける人たちの共通点

完成させる人は「小さく作る」

完成率の高いインディーゲーム開発者に共通するのは、意図的にスコープを小さく保つことだ。

「1時間で遊べるゲーム」「10個のステージだけのパズルゲーム」「ストーリーなし、とにかく一つのゲームメカニクスだけを磨く」

これは妥協ではない。完成という体験を積み重ねる戦略だ。

一つの小さなゲームを完成させた経験は、次のゲームを完成させる確率を劇的に上げる。完成させたことのない人が大作を作ろうとするより、小さな完成を10回積み重ねた人のほうが、最終的に大作を完成させられる。

AIを使うなら、この原則はより重要になる。AIのおかげで「できそう」に感じる機能が増えるからこそ、意識的に「やらないことリスト」を作る必要がある。

完成させる人は「定義を決める」

完成した人たちはほぼ例外なく、開発初期に「完成の定義」を決めている。

「〇〇という機能が動いて、最初から最後まで一周プレイできれば完成とする」「バグが10個以下になったら完成とする」「制作時間が100時間を超えたら完成とする」

この定義がなければ、ゲームは永遠に「もう少し改善できる」状態のまま未完成であり続ける。

完成させる人は「公開コミットメント」を使う

ゲームジャムに参加する、Twitterで「○月○日に公開します」と宣言する、友人に「来月遊ばせてあげる」と約束する──これらの外部コミットメントは、完成率を大幅に上げる。

人間は他者との約束を破ることに強い心理的抵抗を感じる。この性質を利用して、自分を「退路のない状況」に追い込む。

AIがあっても、この人間的な仕組みは変わらない。むしろAIが作業を楽にしてくれるからこそ、「どうせいつでも作れる」という先延ばしが起きやすい。外部コミットメントは、その先延ばしへの有効な対抗手段だ。

第六章：AIとの正しい付き合い方 ── 実践的提案

提案①：AIはあくまで「コパイロット」として使う

AIを「全部やってくれるもの」ではなく、「隣に座って一緒に考えてくれる相棒」として位置づける。

具体的には：

コードを書かせる前に、自分がやりたいことを言語化する
AIが出したコードを、意味を理解しながら組み込む（コピペだけしない）
わからない部分はAIに説明させ、学びながら進める
AIの提案を批判的に評価する（AIは間違える）

自分がコードを理解していないと、後で必ず詰まる。AIは学習コストを下げてくれるが、ゼロにはしてくれない。

提案②：ゲームジャムを活用する

ゲームジャムは、完成させる訓練として最高の場だ。

期間が決まっている（強制的な締め切り）
テーマが決まっている（スコープを絞るヒントになる）
コミュニティがある（孤独感の緩和）
完成品を評価してもらえる（フィードバック）

itch.ioのGame Off、Ludum Dare、Global Game Jam、**1週間ゲームジャム（国内）**など、規模や難易度の違うゲームジャムが年中開催されている。AIを使ったゲームジャムのカテゴリが設けられているものもある。

提案③：「遊べる状態」を常にキープする

開発のどの段階においても、今すぐ誰かに遊ばせられる状態を保つ、という原則がある。

これは「Playable First」または「Vertical Slice」という考え方で、プロのゲームスタジオでも採用されている開発哲学だ。

完璧ではなくても、荒削りでも、とにかく「起動して遊べる」状態を維持することで：

どこで詰まっているかが明確になる
他者に見せやすくなる（フィードバックを得られる）
達成感を継続的に感じられる
「完成」のゴールが具体的に見える

AIで機能を次々と追加するより、今ある機能を「遊べる状態」に保つことを優先しよう。

提案④：「飽き」をプロジェクトの終了サインとしない

開発中に「飽きた」と感じることは、正常なことだ。

プロのスタジオも飽きる。しかし彼らはそれでも作り続ける。なぜなら「飽きた感覚 ≠ ゲームがつまらない」と理解しているからだ。

制作者がそのゲームを一番多くプレイする。当然、誰よりも早く飽きる。しかしプレイヤーにとっては新鮮なままだ。

AIを使うと、新しいゲームをすぐに始められる誘惑が強くなる。しかし**「飽きた」という感覚は、やめるサインではなく、完成に近づいているサインかもしれない**。その感覚とどう付き合うかが、完成させられる人とそうでない人を分ける。

第七章：AIが変えたこと、変えていないこと

変えたこと

AIは確かに、ゲーム開発の世界を変えた。

一人でもリッチなビジュアルを持つゲームを作れるようになった
プログラミング知識が少なくてもゲームの雛形を作れるようになった
BGMやSEをゼロコストで用意できるようになった
アイデアの試作スピードが劇的に上がった
特定のバグの解決法を探す時間が減った

これらは本物の変化だ。5年前に比べて、個人が作れるゲームのクオリティの上限は確実に上がっている。

変えていないこと

しかし、AIが来ても変わっていないことがある。それがゲーム開発の本質だ。

決断すること：何を入れて何を入れないかを決めるのは人間だ
遊びを設計すること：何が「楽しい」かを感じるのは人間だ
継続すること：机に向かい続けるのは人間だ
完成と向き合うこと：「これでいい」と決めるのは人間だ
責任を持つこと：このゲームを作ったのは自分だと言えるのは人間だ

AIは道具だ。優れた道具は、使う人間の能力を拡張する。しかしそれ以上のことはしない。ゲームを完成させる意志、アイデア、センス、忍耐──これらはすべて、今も昔も、あなたの中にある。

第八章：未完成のゲームは失敗ではない

過程で得られるもの

完成しなかったゲームは、無駄だったのか。

違う、と断言したい。

ゲームを作ろうとした時間は、必ず何かを残す。プログラミングの知識、デザインの感覚、問題解決の経験、自分の限界の理解、次に何をすべきかの教訓──これらは完成したゲームでも未完成のゲームでも、同様に得られるものだ。

むしろ、未完成で終わった理由を分析することは、次のプロジェクトを完成させるための最も有益な学習になる。

「スコープが大きすぎた」「モチベーションが続かなかった」「技術力が足りなかった」「生活が忙しくなった」──原因はさまざまだが、それを理解した上で次を始める人と、漠然と挫折感を持ったまま次を始める人では、結果が変わる。

完成しなかったゲームたちが作ったもの

世界の多くの著名なゲームデザイナーたちが、「自分のキャリアの土台は未完成のプロジェクトの山だ」と語っている。

「The Witness」のジョナサン・ブロウも、「Undertale」のトビー・フォックスも、「Celeste」のマット・メイクも、完成したゲームを出す前に数えきれない未完成プロジェクトがある。

未完成のゲームは墓ではない。それは次のゲームの礎石だ。

それでも、作ることをやめないで

AIによってゲーム開発のハードルは下がった。しかし完成のハードルは、本質的には変わっていない。

それでも、作ることをやめないでほしい。

なぜなら、あなたが作りたいゲームは、あなたにしか作れないからだ。AIが生成する画像は、統計的な「平均的な美しさ」を持つ。AIが書くコードは、標準的な解決策を提示する。しかしあなたのゲームが持つ、あなたの経験から生まれたユーモア、あなたの心に刺さった感動の欠片、あなたが伝えたいメッセージ──それはAIには作れない。

AIは道具だ。鉛筆のように、ピアノのように、コンパスのように、あなたの表現を形にする道具だ。道具が良くなったからといって、芸術家が不要になるわけではない。むしろ、より豊かなものを作れる時代になった。

継続することは難しい。完成させることはもっと難しい。しかしその難しさの向こうに、「自分が作ったゲームを誰かが遊んでいる」という、他のものとは比べられない喜びがある。

小さくてもいい。荒削りでもいい。バグが残っていてもいい。

まず、一つ完成させよう。