バイブコーディングによる個人ゲーム開発(Godot Japan GAME JAM 2026)

免責事項
本記事の内容は個人の見解であり、所属する企業の公式な見解や方針を代表するものではありません。

はじめに

先日開催された「Godot Japan Game Jam 2026」にて、AI（Gemini CLI）を活用して『RollingStone』というゲームを制作しました。

このゲームジャムへの参加は、会社の同僚が本イベントの存在を教えてくれたのがきっかけでした。普段の業務とはまた違う、純粋に「作る」楽しさを再発見させてくれた彼に、この場を借りて感謝を伝えたいと思います。

本記事では、2日間という限られた時間での開発プロセスや、GeminiCLIを用いたバイブコーディング的な開発手法について振り返ります。

1. プロジェクト概要

• 参加イベント: Godot Japan Game Jam 2026
• お題: 「丸 」 × 「成長 」
• タイトル: RollingStone
• コンセプト: 「とがった石が、川を下る過程で身を削りながら丸くなっていく」
• 開発期間: 2026年5月4日 〜 5月5日（実質2日間）
• 主要ツール: Godot Engine 4.x + Gemini CLI + Zed (Editor)

物理的な「研磨（丸くなる）」と、精神的な「角が取れる（成長）」を掛け合わせたアクションゲームを目指しました。お題をどう解釈し、いかにして「頂点数の変化」というロジックに落とし込んでいったかが今回の肝です。

2. ゲームアイデアの着想：お題の解釈と閃き

今回のお題は「丸 」と「成長 」でした。まずはこの二つのキーワードをどう結びつけるか、解釈の模索からスタートしました。

もっとも素直に解釈するならば、「丸いものが成長して大きくなっていく」という方向性が思い浮かびます。雪玉が斜面を転がって大きくなるようなゲームも検討しましたが、どうにもゲームとしての面白さのビジョンが鮮明に見えず、既存の有名アクションゲームに似たプレイ感になってしまいそうだったため、この案は採用しませんでした。

そんな中、ふと 「成長して角が取れて丸くなる」 という形容表現が頭をよぎりました。若い頃は尖っていた人が、人生経験を経て性格が穏やかになっていく様を「丸くなる」と言いますよね。

この「精神的な成長としての丸さ」をゲームで表現できないか……。そう考えていたGW中の外出時、大きな川を渡る橋の上で一つの光景が繋がりました。 「川の上流にあるゴツゴツした石が、下流へ流される過程で研磨され、丸く小さな砂粒になっていく」 という自然の摂理です。

この「石が研磨されて丸くなる物理的なプロセス」を「人間的な成長」のメタファーとして組み合わせるという閃きが、本作『RollingStone』のアイデアの根幹となっています。

実を言うと、2日間というタイトな制約上、ゲームジャムに提出したバージョンでは人間的なストーリー要素を深く掘り下げるまでは至りませんでした。しかし、ゲーム説明のフレーバーテキストなどにはその構想の痕跡が残っています。主人公である石に人格を与え、旅を通じて内面的にも成長していくという本来のコンセプトの実現は、今後の課題としたいと考えています。

3. 技術スタック・開発体制

今回の開発の特徴は、直接コードを触ることはほとんどせず、AIエージェントに指示を出してコードやシーンを生成・編集する、いわゆるバイブコーディング的な開発スタイルを採用したことです。
バイブコーディングでどこまでゲームが作れるか？という実験的な意図もあります。

• ゲームエンジン: Godot Engine 4.x
• エディタ: Zed
• 開発手法: Gemini CLIによるテキストベース編集
  • .tscn (シーンファイル) や .gd (スクリプト) を直接テキストとしてAIに編集させました。
  • 開発者の役割は、GUIでゲーム中のオブジェクト配置などの微調整を行うにとどめました。
• 言語: C# → GDScript (理由は後述)

4. 開発のタイムライン

Day 1 (5月4日): コアメカニクスの実装

1. プロジェクト初期化:
   AIにGodotプロジェクトの基本構造を作らせることからスタートしました。
2. 頂点制御ロジック:
   • Polygon2D を使い、頂点数 (Vertices) と半径 (Radius) を動的に制御しました。
   • 砂に触れると「丸くなる（頂点数が増える）」ことにより転がりやすくなるが、「身が削れる（HP/半径が減る）」というリスク・リターンの設計を導入しました。
3. 環境物理:
   水流と岩・砂との衝突判定を実装し、石が転がっていく感覚を追求しました。

Day 2 (5月5日): 試行錯誤と「最大の決断」

1. ゲーム性の拡張:
   • 背後から追いかけてくる捕食者(魚)を実装しました。
   • この魚に触れると即ゲームオーバーとなるため、プレイヤーは魚に追いつかれないようにゲームを進める必要があります。ゲームプレイに緊張感を与えることを意図した機能です。
   • game_config.json によるパラメータ調整システムを導入しました。
2. システム完成:
   • HPバー、多言語対応（日/英）、評価システム(ランクS,A,B,Cの4段階評価)を順次実装しました。
3. C# から GDScript への全移植:
   • 提出締め切りの数時間前、致命的な勘違いに気づきました。提出先である「godotplayer」はWeb（HTML5）形式のみの受付でしたが、 現在のGodot 4.xではC#プロジェクトのWebエクスポートがまだサポートされていなかった のです。
   • 提出要件を事前に確認していれば防げた初歩的なミスですが、気づいた瞬間は真っ青になりました。しかし、ここでも Gemini CLIが大活躍してくれました。全スクリプトを読み込ませ、GDScriptへの変換を一気に行わせるという「力技」で、数時間での全移植を完了しました。AIによるスピーディな修正が出来なければ、間違いなく締め切りには間に合っていませんでした。

5. 「AIによる自動生成」と「人間による調整」の境界線

今回の開発でAIが真に威力を発揮したのは、ロジックの記述だけでなく 「Godotのシーンファイルを直接書き換える」 という点にありました。

基本的な構成やスクリプトはAIに任せ、人間はGUIエディタを「最終的なレイアウトの微調整ツール」として使うという役割分担によって、開発スピードを飛躍的に高めることができました。しかし、同時に 「AIには任せきれない領域」 も浮き彫りになりました。

AIに任せたもの：ロジックと土台

AIが最初に生成したコードでは、プレイヤーの操作やオブジェクトに触れた際の挙動などは機能していました。
しかし、障害物があまりに多すぎて物理的にゴールに到達できないなど致命的な問題があり、そのままではゲームとして成立しているとは言い難い状態でした。

人間が担ったもの：手触りとレベルデザイン

ゲームとして「遊んでいて面白いか」という感覚的な部分や、ステージの起伏（レベルデザイン）は、人間が実際にプレイして調整する必要がありました。

具体的には、以下のような意図を持ったステージ設計をGUI上で手作業で行いました：

• 導入部: オブジェクトをまばらに配置し、オブジェクトに触れた際にどのような挙動をするのかをプレイヤーに学ばせるチュートリアル
• 中盤: 砂を大量に設置して石がみるみる丸くなっていく爽快感を演出しつつ、ダメージのみのオブジェクト(鋭い岩)を混ぜて緊張感を持たせた
• 終盤: 難所として大量の鋭い岩を配置し、温存した体力で突破できるかを試すクライマックス

こうしたプレイヤーの体験をコントロールするための繊細な配置や難易度調整は、現時点では人間がGUIで直接操作する方が効率的であり、かつクオリティに直結する部分であると感じました。

ちょっとしたトラブル: 最終日の「重さ」と対処法

開発最終日の追い込み段階で、それまで軽快に動いていたGemini CLIが急に重くなる現象に見舞われました。

明確な原因は不明ですが、新しいセッションに切り替えることで動作がある程度改善したため、長時間のやり取りでコンテキストが増大しすぎたことが影響していたのではないかと推察しています。（※後で知ったことですが、/compress コマンドで会話の要約を行いコンテキストを節約できる機能があるそうです。次回はこれを活用したいところです）

6. 開発におけるAIエージェントの活用ノウハウ

ここで得られた知見は、ゲーム開発に限らず、他のソフトウェア開発一般にも応用できる可能性のあるものです。AIエージェントを最大限に活用するために工夫したポイントをまとめます。

Markdownを活用した情報共有

人間からも読みやすく、AIにとっても扱いやすい Markdown形式の文書 を積極的に用いることが非常に有効でした。

ドキュメント駆動開発の実践

AIへの指示がブレないよう、まずは「ドキュメントを作らせる」ところから始めました。

1. 仕様と前提の共有: ゲームジャムの公式URLをAIに読み込ませ、概要ドキュメントを自動生成させました。これをお題から逸脱しないための「指針」としました。
2. デザインドキュメント: 実装前にコアアイデアを基にAIと「壁打ち」を行い、ゲームデザインをある程度固めて文書化しました。
3. 運用ルールの明文化: GEMINI.md を作成し、Gitの運用ポリシー（「動作未検証のコードは勝手にプッシュしない」など）を明記して制御しました。

タスク管理 (todo.md)

タイトなスケジュールを乗り切るため、チェックリスト形式の todo.md を活用しました。
人間がタスクを思いついた順に雑にAIに伝え、AIに優先度やジャンルごとに分類・整形させました。進捗が可視化され、次に何をすべきかを常に明確にできたのは、短期間の開発において強力な武器となりました。

コードの透明性と「手触り」の担保

AIにコードを任せるとブラックボックス化しやすいため、以下の対策を取りました。

• リバースエンジニアリングによる確認: AIに現在のコードから仕様をまとめた文書を逆生成させ、計算式が妥当か開発者がチェックしました。
• 外部パラメータ化: 物理挙動の各種パラメータなどは game_config.json を参照する設計にして、開発者側で微調整できる体制を整えました。

7. 友人たちからのフィードバックと、作り手としての喜び

提出後、数名の知人に実際に遊んでもらう機会がありました。そこで得られた最大の気づきは、プレイヤーは「遊び方」のセクションを読まないということでした。

ほとんどのプレイヤーはゲームを起動してすぐにプレイを開始しており、「遊び方」のセクションは読んでいませんでした。そのような様子を見て、導入部での自然なチュートリアルの重要性を痛感しました。また、提出時にはそこまで凝っていなかったスコアやランクを上げることに熱中し、何度もリトライしてくれる姿を見て、プレイヤーの挑戦心をくすぐる要素の重要性を再認識しました。

何より、自分が作り上げたものが誰かを楽しませている光景を見られたこと、それにより他では得難い喜びを得られることに気づいたことが、今回のプロジェクトで一番の収穫でした。

おわりに

AIエージェントに指示を出しながらゲームを作る体験は、従来の「開発」というよりは「監督」や「編集」に近い感覚でした。特に、締め切り直前の全移植という困難なタスクを遂行してくれたAIの性能の高さには、改めて驚かされました。

また、AIエージェントを用いた開発で大事なのは、とりあえず不格好でもいいから自分で触ってみてツールの「手触り」を把握し、人やプロジェクトごとに適したスタイルを臨機応変に見つけていくことだと感じました。

今回ゲームジャムに提出したゲームのプレイリンクは記事末尾に記載しております。
Webブラウザ上で手軽に遊べるものとなっていますので、本記事を読んでご興味をもっていいただけましたら是非遊んでいただけると幸いです。

---

使用したツール:

• Godot Engine
• Gemini CLI (AI Agent)

リポジトリ/プレイリンク:

• ゲームプレイ (ブラウザ版): RollingStone on godotplayer
  • 今回は「godotplayer」というプラットフォームを利用させていただきました。Godotから出力したWeb形式のファイル群をアップロードするだけで即座にプレイ環境が整う素晴らしいサービスです。この場を借りて感謝申し上げます。
  • ※ゲームジャム終了後も開発を続けており、現在上記リンクにて遊ぶことができるゲームはゲームジャム終了時に提出したものとは異なるバージョンとなります。ご了承下さい。
• ソースコード: (リポジトリは現在非公開となっております)