1行もコードを書かずにGeminiだけでUnityの大富豪ゲームを作って公開した話
こんにちは。普段はPdMをしているフリーランサーです。
今回は「自分では1行もコードを書かない」という縛りで、生成AI（Gemini+GeminiCLI）だけを使ってUnityでゲーム開発を行いました。
作ったのはCPU対戦型の「大富豪」 です。
8切り、Jバック、5スキップ、縛り…といったローカルルールも採用し、最終的にGitHub Actionsでの自動デプロイまで漕ぎ着けました。
この記事では、AIとのペアプロ（というか丸投げ）で起きた泥酔コーディングによる謎機能や指示が通じずブチギレて全消しリビルドといった事件、そして得られた知見を時系列順に共有します。
いわゆるハウツー記事ではなく、事例紹介にあたります。
📅 今回の開発ルール（縛りプレイ）
開発にあたり、以下の鉄の掟を自分に課しました。
- コードはすべてGeminiCLIに書かせる（僕は一切コードを触らない。READMEもGeminiCLIが書く）
- どんな小さな修正も必ずGeminiCLIにやらせる（手修正禁止）
- バグったらエラーログを渡して修正も丸投げ
- ソースコードの正しさはチェックしない（そもそもUnityもC#も詳しくないので無理）
- 最終ゴールはCIを回して一般公開すること
要するに、私は「PM兼テスター」に徹し、実装はすべて「AIエンジニア（Gemini+GeminiCLI）」に任せるスタイルです。
🚀 開発ログ：カオスと再生の1週間
ここからは、実際のコミットログと共に何が起きたのかを振り返ります。
1. 爆速の立ち上げとAIの優秀さ (Day 1)
ちょうど1週間前、開発は以下のプロンプトから始まりました。
CPUと1対1で対戦する大富豪を作ってください。
特殊ルールとして、8切り、5スキップ、Jバック、縛りを追加してください。
CPUとユーザーがサイコロを1つずつ振って合計値で配るカードの枚数を決めてください。
通常のルールですべて配りきると、1vs1では相手の手札が完全に透けてしまうため、あえてこの「サイコロ手札制限ルール」を採用しました。
驚くべきことに、この指示だけでゲームのコアロジック（4544269）は一発で動作しました。カードを配る、役を判定する、特殊ルールを発動する。これらが数秒で実装された時、「これは勝った」と確信しました。
リポジトリを作ってからプレイできるようになるまで、2時間しかかかりませんでした。
2. UIレイアウトという鬼門 (Day 1 - Day 2)
しかし、Unity初心者の私とテキストベースのAIにとって、最大の壁は「UI（見た目）」でした。
-
3900534：見て見ぬふり
カードが横長に表示されていたため、縦長に直そうと指示するも、AIが修正に失敗。
心の声：「まあ、ロジックは動いてるし後で直せばいいか……」 と放置。これが後の悲劇の始まりでした。 -
6bc8a75：ユーザーテストでの敗北
知人にプレイさせたところ「ルールが全くわからん」と一蹴される。慌てて「ルール説明画面」の実装を指示。 -
751e1fb：泥酔コーディング
深夜、酒を飲みながら開発を続行。「戦績機能」を追加したようですが、正直この時の記憶がありません。
翌日見たらちゃんと勝率計算やデータ保存が実装されていて、過去の自分（とGeminiCLI）に感謝しました。
3. 崩壊、そして奇策 (Day 2)
UIの修正指示を繰り返すうち、コードはつぎはぎだらけのスパゲッティ状態に。AIも文脈を見失い始めました。
-
855ca36：AIに「目」を与えようとするも…
「ボタンが重なってる」「テキストがはみ出てる」と言葉で伝えても直らないため、「ゲーム画面のスクリーンショットを撮影して保存する機能」**をGeminiCLIに実装させました。「スクショを撮る → 画像をGeminiCLIに投げる → 直させる」というマルチモーダル・デバッグを試みましたが、期待したほどの精度は出ず。 やはり複雑なUI崩れをAIに認識させて直させるのは、まだ一筋縄ではいかないようです。
-
9afc67f：ビルドへの逃避
エディタ上の表示が信じられなくなり、「ビルドすれば直るかも」という謎の期待でWebGLビルドに挑戦。当然直りません。
4. 決断：全消しリビルド (Day 2 夕方)
ついに限界が来ました。繰り返される修正によりコードはカオスを極め、修正が新たなバグを生む無限ループに突入。
-
2528cb5 〜 1bf0b0e：破壊と再生
ここで私は決断しました。「今のコード、全部捨てよう」。ただし、ただ捨てるのではありません。
bf2dcaf で、現在のゲーム仕様（ルール、挙動、UI構成）をすべて文章化し、「仕様書」としてドキュメント化しました。もちろんGeminiCLIが。「コード」ではなく「仕様書」を正とすることで、Geminiにゼロからクリーンなアーキテクチャで書き直させることに成功しました。
生成した仕様書
# Duel Daifugo (デュエル大富豪) ゲーム仕様書
## 1. ゲーム概要
プレイヤーとCPUが対戦する、1対1の「大富豪」カードゲーム。
Unity WebGLビルドを想定し、スマートフォン（縦画面）でのプレイに最適化されたUIを持つ。
## 2. ルール仕様
### 基本ルール
- **人数**: 1対1 (Player vs CPU)
- **カード**: ジョーカーを除く52枚 (各スート A, 2..10, J, Q, K)
- **強さ**: 3 < 4 < ... < 13(K) < 1(A) < 2
- **革命時**: 2 < 1(A) < 13(K) < ... < 3
- **勝利条件**: 先に手札を全て出し切ったプレイヤーの勝利。
### 採用ローカルルール
1. **8切り (8 Cut)**
- 8を含むカードが出された場合、その場で場が流され（Field Clear）、出したプレイヤーの親ターンとなる。
（以下略）
5. 自動化と公開 (Day 3以降)
リビルド後は驚くほどスムーズでした。
-
479a632：GitHub Actions導入
Unityのビルドはめんどくさいので、GitHub Actionsで自動化。 -
ba0c282：.geminiignore の発見
コンテキスト制限を避けるため、UnityのLibraryフォルダなどをAIに読み込ませない.geminiignoreファイルを追加。 今回は明確な効果までは実感できませんでしたが、トークン節約やノイズ除去の観点で、今後効果を確認する余地がありそうです。 -
ca8c73e：一般公開
ついに完成。READMEにURLを貼り、リリース完了です。
💡 Geminiだけで開発して得られた知見
1. 「コード」より「日本語の仕様書」を書け
コードがぐちゃぐちゃになった時、プログラマーならリファクタリングをしますが、非エンジニア（今回はそのスタンス）は仕様書の整備をするべきです。
正確な仕様ドキュメントさえあれば、AIは何度でもきれいなコードを生成してくれます。「プロンプト駆動」ではなく「仕様書駆動」 が、バイブコーディングの正解だと痛感しました。
2. UI調整とマルチモーダルの壁（今後の課題）
ロジックの生成は完璧に近い一方、UnityのUIの調整はテキスト指示だけでは限界がありました。
今回「スクショを撮ってAIに見せる」という手法も試しましたが、劇的な解決には至りませんでした。「視覚情報をどうAIに正しくフィードバックして修正させるか」 は、フルAI開発における今後の大きな挑戦テーマになりそうです。
3. 諦めて寝る、あるいは捨てる勇気
執着して修正を繰り返すとロクなことになりません。
AIがループに入ったら、一度チャットをリセットするか、コードを捨てて仕様書から再生成する方が、結果的に早いです。
📝 まとめ
UnityもC#もわからない人間が、「PMとして仕様を定義し、QAとしてバグを報告する」 だけで、そこそこ複雑なルールのゲームを作り切ることができました。
「AIにコードを書かせる」というと、プロンプトエンジニアリングのような魔法の言葉を探しがちですが、実際に必要だったのは 「何をどう作りたいか」を言語化する力 と、うまくいかない時に構造を見直す（リビルドする）決断力でした。
今回作成したゲームのリポジトリはこちらです。遊んでみた感想をもらえると喜びます。
皆さんもぜひ、AIとのペアプロであなたなりの「バイブコーディング」に挑戦してみてください。
ちなみに、この記事自体もGitログをGeminiに渡して生成させました。 「何を書くか」のディレクションは私が行いましたが、構成と執筆はAIが担当。最後の細かい言い回しを二人三脚で修正して完成させました。ここでも徹底して「PMと実務者」という役割分担を貫いています。
Discussion