「１行もコードを書かない」Unityゲーム開発

今回は生成AI（Gemini+GeminiCLI）だけを使ってUnityでゲーム開発を行いました。
ノウハウではなく、AIとのペアプロで起きた「事件」と「得られた知見」を共有します。

Transcript

1. 「１行もコードを書かない」 Unityゲーム開発 杉田知至 フリーランスPdM
2. 自己紹介 杉田 知至（すぎた ともゆき） 💼フリーランスPdM / 新規事業創造パー トナー 📈スタートアップ3社でプロダクト開発を主 導。元・取締役CPO。 📙著書：「エンジニアのための WordPress開発入門」（技術評論社）
3. 本日のテーマ • 今回は生成AI（Gemini+GeminiCLI）だけを 使ってUnityでゲーム開発を行いました。 • ノウハウではなく、AIとのペアプロで起きた 「事件」と「得られた知見」を共有します。
4. 元記事： https://zenn.dev/tomotomobile/articles/b5cf31891b77e2
7. 作ったもの：CPU対戦型「大富豪」 • CPUと1対1で対戦する大富豪アプリ • 8切り、Jバック、5スキップ、縛りなどの ローカルルールを実装 • 最終的にGitHub Actionsで自動デプロイ完遂
9. 今回の開発ルール（縛りプレイ） • コードはすべてAIに書かせる（手修正禁止❌） • バグったらエラーログを渡して修正も丸投げ • ソースコードの正しさはチェックしない （そもそも読めない） • 役割：私は「PM兼テスター」、AIは「実装」
10. Day 1: 爆速の立ち上げ
11. Day 1: 爆速の立ち上げ • ルールのプロンプトを投げただけで、 コアロジックが一発で動作 • カードを配る、役の判定、特殊ルールの発動が 数秒で実装される • リポジトリ作成から2時間でプレイ可能になる
13. 「これは勝った」
14. Day 1-2: UIレイアウトという鬼門
15. Day 1-2: UIレイアウトという鬼門 • テキストベースのAIにとって、 最大の壁は「UI（見た目）」でした • 修正指示が通らず「見て見ぬふり」をするも、 テストプレイで不評 • UIは後で直せばいっかー（希望的観測）
16. Day 2: 崩壊と奇策
17. Day 2: 崩壊と奇策 • UIの修正指示を繰り返すうち、収拾がつかない状態 に。。。 • 奇策：AIにゲーム画面のスクショを撮らせて画像を渡 し直させる（マルチモーダルデバッグ） • 結果：期待したほどの精度は出ず、泥沼化
18. 🤯「ああ、終わった」
19. Day 2 夕方: 決断
20. Day 2 夕方: 決断 • 繰り返される修正でUIはカオスを極め、 無限バグループに突入 • AIへの指示が全く通らなくなりました • そして、限界を迎え、決断へ・・・
21. 「今のコード、全部捨てよう」
22. Day 2 夕方: 決断「全消しリビルド」 • ただ捨てるのではなく、現在のゲーム仕様をすべて Markdownの仕様書化 （もちろん仕様書もAIに書かせました） • 「コード」ではなく「仕様書」を正とすることで、ゼロから クリーンな再構築に挑戦
25. 直った😆
26. Day 3以降: 自動化と公開
27. Day 3以降: 自動化と公開 • リビルド後は驚くほどスムーズ • 面倒なUnityビルドをGitHub Actionsで自動化 • 無事に一般公開！▶リリース完了
28. https://tomotomo.github.io/vibe-game/
29. 「１行もコードを書かない」Unityゲーム開発 を通して得られた知見
30. 得られた知見 ①「コード」より「日本語の仕様書」 ② UI調整とマルチモーダルの壁 ③ 諦めて寝る、捨てる勇気
31. 知見①「コード」より「日本語の仕様書」 • 非エンジニアは、コードの書き方を指示する のでなく「仕様書の整備」をすべき • 正確な仕様書があれば、AIは何度でも いい感じのコードを生成する • 「プロンプト駆動」▶「仕様書駆動」が正解
32. 知見② UI調整とマルチモーダルの壁 • ロジック生成はいい感じだが、 UIの調整はテキスト指示だけでは限界がある • 「視覚情報をどうAIに正しくフィードバック 　させるか」が、フルAI開発の今後の課題
33. 知見③ 諦めて寝る、捨てる勇気 • 執着して細かい修正を繰り返すと☠ • AIがループに入ったら、一度チャットをリセット または、コードを捨てて仕様書から再生成する方が、 結果的に早い
34. まとめ：PMとQAに徹する UnityもC#もわからない人間でも、「PMとして仕様を定義 し、QAとしてバグを報告する」だけで、そこそこ複雑な ゲームを作り切ることが可能です。
35. まとめ：魔法の呪文は不要 プロンプトエンジニアリング以上に、本当に必要だったの は以下の2つです。 1. 「何をどう作りたいか」を正確に言語化する力 2. うまくいかない時に構造を見直す決断力 ◦ 今回はリビルドを決断しました
36. ご清聴ありがとうございました