バイブコーディングで「おでんのコンニャクが主役のゲーム」を個人開発してみた― AIと進める個人ゲーム開発 ―【後編】

前編に引き続き、「おでんのコンニャクが主役のゲーム」制作に関する記録です。今回は、実際にどんなふうにバイブコーディングで開発を進めたか、具体的なプロセスをご紹介します。

AIと進めた開発プロセス全体像

今回私が作った個人開発ゲーム「ROAD TO ODEN」は全4Stage構成。実際の開発で、AIを活用しながらどのように進めたかを振り返ります。

ゲームのソースコードとプレイ画面はこちら。

①まずはAIにざっくり要件を投げて要件を定義

お風呂に入ってボケーっとしていたとき、ふとおでんのゲームのアイデアが浮かびました。「土の中のコンニャクイモが這い出してきて、最終的におでん鍋を目指すストーリーにしよう」「ラスボスはダイコンにしよう」

かなり勢いだけの発想ですが、個人開発なので何でもアリだろ！ということで。思いついた内容を、そのままChatGPTに投げてみました。細かい仕様や技術的な制約は一切考えず、「こんな世界観で、こんなゲームを作りたい」とだけ伝えた形です。

するとChatGPTからは、次の4ステージ構成の案が返ってきました。

• Stage1：土の中から這い出す
• Stage2：工場のローラーを避ける
• Stage3：台所のまな板の上で逃げる
• Stage4：おでん鍋へ向かい、ラスボスとバトル

「おでんのコンニャクのゲーム」とか普通に意味わからん内容を、こんなに真面目に考えてくれるなんて…いい子…などと感動しつつ、なるほど複数ステージってアイデアはいいなと思いました。各ステージで、横スクロールとか縦スクロールとか、ぜんぜん違うギミックにしたら面白いんじゃね？みたいな。

ただ、提案で少し引っかかったのが②と③の内容でした。どちらも「カッター系の障害物を避ける」という点で似ており、遊びのバリエーションが出しづらそうに感じたのです。

そこで③は家庭の台所ではなく、「スーパーの売り場」に変更。買い物かごや落下物を避けるステージにすれば、雰囲気もギミックも変えられそうだと考えました。

この時点では、ステージの細かい仕様や操作方法はほとんど決めていません。まずは世界観と大まかな流れだけをAIと一緒に整理し、「4ステージで完結するゲーム」という骨組みを決めることを優先しました。

②ステージごとに分けて作る

ざっくりとですが要件が定まったので、続いてやったのは、ゲーム全体をつなげることではなく、Stage1〜Stage4をそれぞれ単体で作ることでした。

いきなり完成形を目指すと確実に手が止まりそうだったので、「1ステージだけ動けばOK」という小さなゴールを設定した形です。何せ毎日仕事で夜はクタクタな状態なので、まずはブツ切りでもなんとなく続けられることを目指しました。

構成としては、index.html から main.js を読み込み、そこから Stage1.js〜Stage4.js を呼び出すという、かなりシンプルな形にしました。いったんステージ同士のつながりや遷移は一切考えず、各ステージが単体で起動し、遊べることを目標に据えました。

そのため、各ステージは「ここだけ切り出して見ても成立するか？」を常に意識しながら作りました。操作方法、クリア条件、ゲームオーバー判定なども、とりあえずそのステージ内で完結する形にしています。後で調整や共通化をする前提だったので、きれいな設計よりも「まず動く」を優先しました。

コードを書くのと並行して、必要な画像素材もその都度用意しました。最初からすべての素材を揃えるのではなく、「ここに何か足りないな」と感じたタイミングで、AIで画像を生成したり、簡単な加工を加えたりする流れです。実装と素材作成を行き来しながら進めることで、頭の中のイメージと実際の画面をすり合わせやすくなりました。

③ステージをつなぎ合わせる＆メニューを作る

各ステージがそれぞれ単体で動くようになった段階で、いよいよ全体をつなぎ合わせる作業に入りました。

ちなみに、ここまでの所要時間にはかなり差があり、Stage1〜3は1〜3日程度で形になったのに対し、Stage4だけは2週間ほどかかっています。ラスボスやギミックが増えるほど、想定外の問題も一気に増えるもんなんだなと実感しました。

ステージ同士の接続自体は、構造がシンプルだった分、比較的スムーズに進みました。main.js 側でシーンの管理を行い、Stage1→Stage2→Stage3→Stage4と順番に遷移する流れを作ります。この時点で、ようやく「ゲームとして一通り遊べる」状態になりました。

あわせて追加したのが、タイトル画面TitleScene.jsです。スタートボタンから通常の進行ルートに入れるだけでなく、各ステージを個別に選択できるメニューも用意しました。これは、難易度調整やデバッグのためでもありますが、「どこかのステージがクリアできなくても、全部の面を遊べるようにしたい」という意図もありました。

個人開発のゲームでは、必ずしも順番通りにクリアできることが正解ではなかったりしますよね。途中で詰まってしまっても、「じゃあ別のステージを触ってみよう」と思える余地を残しておくことで、遊ぶ側のストレスを減らせると考えました。

タイトル画面とステージ遷移が入ったことで、画面構成は一気にゲームらしくなりました。単体で作っていたときには見えなかった全体のバランスも、この段階で初めて見えてきます。ここから先は、細かな調整や共通化など、「仕上げ」のフェーズに入っていくことになります。

④共通化できる部分を後から整理する

ステージをつなぎ合わせて全体を通して遊んでみると、気になり始めたのが細かな表記や挙動のばらつきでした。

たとえばステージ開始時に表示するメッセージの文言や出し方、ゲームオーバー時の表示やリスタート方法などが、ステージごとに微妙に違っていたのです。単体で作っていたときには気にならなかった部分ですが、並べて見るとどうしても目につきます。

そこで、このあたりは思い切って共通部品BaseStage.jsとしてまとめることにしました。ステージ開始メッセージ、クリア・ゲームオーバー時の表示、入力待ちの処理などを共通化することで、表記が統一されるだけでなく、コードの見通しもかなり良くなります。

この作業をして改めて感じたのは、「作り終わってから全体を見直す時間」の重要性です。最初から完璧な設計を目指していたら、ここまでたどり着けなかったと思います。まずは動くものを作り、最後に全体を俯瞰して整理する。この順番だからこそ、どこを共通化すべきかがはっきり見えました。

個人的には、この共通化のフェーズは、エンジニアとしての見せ所だと感じています。AIにコードを書いてもらうことはできても、「どこをまとめるべきか」「今は整理するタイミングか」を判断するのは人間の役割です。バイブコーディングでも、こうした設計の判断が入る余地はちゃんと残っていて、そこが面白いところだなと思いました。

⑤音楽・効果音を入れる

ゲームの形がだいたい整ってきたところで、次に手を付けたのが音まわりです。

正直に言うと、最初は「音楽や効果音はなくてもいいかな」と思っていました。個人開発ですし、動くだけでも十分達成感はあります。ただ、試しにBGMを入れてみたところ、印象が一気に変わりました。

当初は、「素材も含めて全部AIで生成しよう」と考えていたため、音楽生成AIのSunoを使う予定でした。ただ、無料プランだと著作権の扱いがややグレーに感じられ、かといって有料プランにするほど本気で使うわけでもないな……と判断。今回は無難に、著作権フリー音源サイトのDOVA-SYNDROMEからBGM・効果音をすべて揃えることにしました。

実際にBGMを流してみると、それまで「動くプログラム」だったものが、一気に「ゲーム」になります。画面構成や演出は何も変えていないのに、雰囲気ががらっと変わるのが面白いところです。特にステージごとにBGMを切り替えることで、場面転換がより分かりやすくなりました。

さらに良かったのが効果音です。ジャンプや当たり判定の音など、正直なくても成立はします。ただ、効果音が入ると操作に対する手応えが明確になり、「自分で操作している感覚」が強くなりました。最初は不要だと思っていた分、つけてよかったと強く感じた部分です。

音まわりは後回しにしがちですが、完成度を一段引き上げてくれる要素でもあります。バイブコーディングでも、最後に音を足すだけで達成感がぐっと増すので、この工程はかなりおすすめです。

⑥最終調整

一通りの機能がそろったあとは、通しで何度もプレイしながら最終調整を行いました。

ステージ単体では問題なく動いていても、最初から最後まで遊ぶと想定外の挙動が出てくることがあります。途中で止まらないか、エラーで落ちないか、テンポがおかしくなっていないか、とにかくひたすら確認です。

分かりやすいところでは、音量の調整があります。BGMや効果音を入れた直後は、全体的に音が大きすぎたので、少しずつ下げてバランスを取りました。また、単体でステージを起動すると音が鳴るのに、通しでプレイすると鳴らない、といった問題もあり、音の初期化や再生タイミングを見直す必要がありました。こういう細かい違和感は、通しプレイをしないと気づきにくい部分です。

スマホ対応についても、この段階で一度検討しました。共通部品として組み込めそうだとは思ったものの、想像以上に調整が必要になりそうだったため、今回はいったん断念しています。

仕上げとして追加したのが、エンドロールです。正直、ここまで到達する人がどれくらいいるのかは分かりませんが、エンドロールが流れるだけで、「ああ、ちゃんと完成したな」という気持ちになります。実装そのもの以上に、作り手側の達成感が大きかったポイントかもしれません。

最終調整は地味な作業の連続ですが、ここを丁寧にやるかどうかで、完成度と満足感が大きく変わります。バイブコーディングでも、このフェーズをちゃんと通ったことで、「作った」と胸を張って言える状態になったと感じています。

開発で詰まったところ・悩んだところ

ここでは、実際に詰まったポイントや、最終的に「今回はやめておこう」と判断した部分を振り返ります。うまくいかなかった話も含めて書くことで、バイブコーディングの現実的な一面が伝わればと思います。

アーム演出がうまくいかず断念（Stage2）

Stage2では、上からクレーンゲームのアームのようなものが伸びてきて、プレイヤーをガッとすくい上げる演出を入れようと考えていました。で、AIに相談しながら実装を試みたものの、出来上がったのは「上から下にアームがぼとっと落ちてくる」ような動き。「え、違う……」となりました。

細かく調整すれば理想に近づけそうではありましたが、演出に時間をかけすぎるのも違うなと思い、アームを使う案自体を諦めました。その代わりに、段ボールが次々と流れてくる仕組みに変更しています。

結果的に、工場らしさも出て、操作に集中できるステージになったので、この判断はまあ正解だったかなと思っています。

ダイコンボスが1発で消える（Stage4）

Stage4のラスボスとして登場するダイコンは、複数の弾を撃ち込まないと倒せない想定でした。ところが、実際に動かしてみると、なぜか1発当たっただけで消えてしまうという状態に。HP管理や当たり判定を見直しても、何度修正しても結果は変わりません。

最初はChatGPT（Plusプラン）に相談して修正を重ねましたが直らず、次にGemini（Proプラン）に切り替えてみても改善せず。さらに、Claude（無料版）まで導入してみたものの、状況は同じでした。3つのAIを使っても直らないとなると、「いやもうこれ無理じゃね！？」という気持ちになってきます。

そこで方針を変え、ダイコンボス周りの処理をいったん全部消してもらい、最初から作り直すことにしました。部分的に直そうとするのをやめ、構造ごと入れ替えるように軌道修正した形です。結果として、無事に想定通りの挙動になり、ラスボスとして成立するようになりました。

この経験から、「AIをたくさん使えば必ず解決するわけではない」という当たり前だけど大事な学びを得ました。行き詰まったときは、修正を積み重ねるより、いったん壊して作り直したほうが早いこともある。バイブコーディングでも、その判断は結局、人間が下す必要があるのだと感じました。

スマホ対応

できればスマホでも遊べるようにしたいと思い、スマホ判定の処理を共通部品として入れてみたのですが、これが想像以上に面倒でした。操作方法やUIの問題だけでなく、環境による判定の違いにも悩まされます。

特に困ったのが、GitHubにアップすると、なぜか常にスマホとして判定されてしまう現象です。ローカルでは問題ないのに、本番環境では挙動が変わる。この時点で「これは腰を据えてやらないと厳しいな」と感じました。

今回は「とりあえず完成させる」ことを優先し、スマホ対応はいったん断念しています。中途半端に対応するより、割り切ってPC向けと決めたほうが気持ちよく終われそうだったからです。

ただ、スマホ対応そのものを諦めたわけではありません。次に作るときは、最初からスマホ前提で設計したゲームにも挑戦してみたいなと思っています。

音楽生成と商用利用の壁

今回の開発では、音楽生成AIも使ってみたいと思っていました。ただ、実際に調べてみると、使おうと思っていた音楽生成AI「Suno」は無料プランでは商用利用の扱いが微妙で、この点が大きな壁になりました。

今回は有料ゲームではありませんが、エンジニア兼ライターとして活動している以上、将来的にポートフォリオとして公開する可能性もあります。「完全に関係ない」とは言い切れない以上、曖昧な状態で使うのは避けたいと感じました。

とはいえ、音楽生成のためだけに有料プランへ切り替えるほど頻繁に使うかというと、そこまででもない、というのも正直なところです。悩んだ末、今回は音楽生成AIの利用自体を見送り、著作権フリーの音源を使う判断をしました。

ただ、無料プランで試しにBGMを生成してみたところ、これがなかなか面白かったんですよね。特に歌詞が予想以上にクセ強で面白く、「コンニャクヒーロー」とか独特のワードと世界観が出てきてかなり面白かったです。

今回は見送りましたが、いつかはBGMも含めて、音楽生成まで含めたゲーム開発にも挑戦してみたいと思っています。

バイブコーディングによる個人ゲーム開発で感じた学び

ここまで実際の開発プロセスや詰まったポイントを振り返ってきましたが、今回の個人ゲーム開発を通して、技術的な知識以上に多くの「気づき」がありました。ここでは、そうした試行錯誤を通して得られた学びを整理します。

AIだけではゲームは完成しない

バイブコーディングという言葉が広まり、「誰でも簡単にコーディングできる」「もうエンジニアはいらない」といった話を目にする機会も増えました。ただ、実際に個人ゲーム開発をやってみると、思っていた以上に全然うまくいかなかったというのが正直な感想です。

確かに、AIに任せれば「動くもの」は比較的簡単にできます。ただし、その中身を見てみると、コードはぐちゃぐちゃで、同じような処理があちこちに散らばり、少し仕様を変えただけで一気に壊れそうな状態。あとから手を入れるのはかなり厳しいと感じました。

ここで強く感じたのは、バイブコーディングは「誰でも使えば魔法のようにうまくいく手法」ではなく、ちゃんと分かっている人が使ってこそ効果を発揮するものだということでした。まあ、当たり前っちゃ当たり前の話なんですけど。保守性、可読性、セキュリティといった観点は、AI任せではなかなか担保されないので、最終的には人間が判断し、整える役割を担う必要があります。

少し昔を振り返ると、Excelが普及し、マクロを組める人が重宝された時代がありました。一方で、属人化しすぎたマクロがブラックボックス化し、後から誰も触れなくなる、という問題も頻発しましたよね。今のバイブコーディングを信仰のようにあがめる風潮が続けば、あれと同じようなことがこれからの開発現場でも頻発するのではないか、と危機感を大きくしました。

そう考えると、エンジニアの役割がなくなるどころか、むしろ重要性は増していくのではないでしょうか。AIを使う時代だからこそ、「壊れにくく、読みやすく、引き継げるコード」を作れる人の価値は、まだまだ大きいと感じました。

AIは1つに絞らず、比較しながら使う

今回の開発を通して強く感じたのは、AIにもはっきりと得意・不得意があるということでした。どれか1つを万能ツールとして使うよりも、目的に応じて使い分けたほうが、結果的にうまく進みます。

たとえばChatGPTは、全体の整理や文章表現が得意で、「こういうゲームを作りたい」という抽象的な相談にはとても向いていました。一方で、コードに関しては、感覚的にGeminiのほうがしっくりくる場面が多く、実装寄りの提案をしてくれる印象があります。Claudeはさらに一段エンジニア寄りで、「ここにデバッグログを入れて挙動を確認してみてください」といった、原因切り分けを意識した返しが多いのが特徴的でした。

この違いを体感して、「AIは性能比較の対象であって、信仰の対象ではないな」と感じました。特性を理解したうえで使うからこそ、バイブコーディングは武器になります。

考えてみれば、人間同士の相談でも同じですよね。一人の人にだけ聞くより、複数の人に意見を聞いたほうが視野は広がりますし、医療の世界にはセカンドオピニオンという考え方もあります。AIにも同じ発想が必要で、「このAIがダメなら別のAIに聞いてみる」という姿勢は、これからますます重要になっていくと感じました。

小さく作って、壊して、直すが一番早い

今回は「小さなゲームを作りたい」という起点で、バイブコーディングを使って開発を進めました。正直なところ、もっとサクッと形になるのかなと思っていたのですが、実際にはStage4のように想定以上に詰まるポイントもあり、「誰でも簡単にできる」と言われるほど楽ではなかったというのが率直な感想です。

特に、頭の中にあるイメージ通りの挙動をAIに生成させるには、思った以上に手間がかかります。動くものは出てくるものの、「こうじゃない」というズレを埋める作業が続きました。バイブコーディングでも、完成形に近づけるには試行錯誤が必要です。

それでも、プロジェクトを小さく始めていたからこそ、思い切った判断ができました。Stage4のダイコンボスでは、部分的な修正を重ねるのをやめ、処理を一度すべて壊して作り直す、という大胆なアプローチを取りましたが、最初から大規模なゲームだったらなかなか踏み切れなかったと思います。

小さく作って、ダメなら壊して直す。このサイクルを高速で回せるのが、バイブコーディングと個人開発の相性の良さだと感じました。最初から完璧を目指すよりも、「まず作ってみる」ことの大切さを、改めて実感した経験でした。

おわりに：バイブコーディングは「楽しく開発する」ための手段

バイブコーディングを使って個人ゲーム開発に挑戦するという初めての試みでしたが、素直に「楽しかった」というのが感想です。思い通りにいかない場面も多く、詰まって悩む時間もそれなりにありましたが、それも含めて個人開発らしい体験だったと思います。

バイブコーディングは、何も考えなくてもAIが全部作ってくれる魔法ではありません。実際には、設計を考え、取捨選択をし、壊して作り直す判断をする必要があります。それでも、アイデアを形にするまでのハードルを下げてくれるのは確かで、「ちょっと作ってみよう」と思える距離感にしてくれました。

今回のゲームも、完成度が高いかと言われれば、まだまだ改善の余地はあります。ただ、最後まで作り切り、エンドロールまで用意できたことで、「ちゃんと1本のゲームを作った」という実感が得られたのは大きな収穫でした。

バイブコーディングは、効率化のための手段というよりも、「開発を楽しみ続けるための道具」なのかもしれません。少なくとも今回の自分にとっては、そういう存在でした。

この経験をきっかけに、今後も小さなゲームやツールを、個人プロジェクトとして気楽に作り続けていきたいと思っています。次はどんな形になるか分かりませんが、またAIと一緒に、試行錯誤しながら楽しんでいく予定です！