バイブコーディングでちゃんとした開発ができるか試してみた

### PDF概要

**タイトル**: バイブコーディングでちゃんとした開発ができるか試してみた

---

#### 1. 目的

* **AIだけを使って 1 行もコードを読まずにサービス開発を完走できるか**を検証する試み。
* 将来的には “イケてる PM が AI と二人三脚で安定的に本格サービスをリリースできる” 世界を想定。

---

#### 2. 実験対象

* リアルタイムストラテジー系のゲーム（バトルコマンダー風）をサンプルプロダクトに設定。
* 部隊移動・拠点・アイテム・兵器開発など多機能が必要で、**“バイブスだけで作るのは無理”** な規模をあえて選定。

---

#### 3. ワークフローとツール

| フェーズ | AI にさせること | 補足 |
| -------- | --------------------------------- | --------------------------------------- |
| PRD 作成 | ざっくり要望 → **MVP 前提で PRD**生成 | o3 / Claude Opus4 / Gemini 2.5 Pro など推奨 |
| タスク分解 | PRD から **Epic & タスク**を自動生成 | Epic は「システム単位」がコツ |
| 実装サイクル | Epic / タスク単位で **ClaudeCode に丸投げ** | 進行中も PRD・タスクを常に更新 |
| 品質保証 | 各タスクで **ユニット & 統合テスト**生成・実行 | デグレは ClaudeCode が検知し自動修正 |
| ドキュメント統制 | **CLAUDE.md** に開発フロー・コマンド・ルールを明文化 | /init でアーキテクチャ概要を随時再生成 |
| Git 運用 | PRD/タスク更新・実装変更ごとに **自動 commit** | 専用コマンドで粒度を保つ |

---

#### 4. MUST ルール（抜粋）

1. **要望追加 → PRD 更新 → Epic/タスク更新 → 実装**の順を厳守。
2. フェーズ区切りで必ず **テスト実行 & commit**。
3. 五月雨仕様は後追いでドキュメントを整備し、**“仕様の出元”** を残す。

---

#### 5. 成果

* **8 時間で 88 commit** のスピード感で、

* 部隊クリック → 移動指示 UI
* 移動先選択
* 敵発見 → 攻撃 → ダメージ判定
といったコア機能を実装完了。
* 適切にタスクを刻めば、**微エンジニアの PM でもフル AI 開発が可能**と確認。
* テストを徹底すればデグレも自動検知・自動修正できる。

---

#### 6. 考察・推奨事項

* “バイブス” でなく **現場レベルのプロダクトマネジメント**を AI に代行させるのが鍵。
* **PRD とタスク粒度**が粗いと品質低下・やり直しが増える。
* **テストコード生成をルール化**すると、AI が自己修復しやすい。
* **ドキュメント（CLAUDE.md）を中心に据えた開発統制**が、長期のプロジェクト維持に有効。

---

##### ひとことで

> **「AI を労働力として使い倒すには、 　
> 仕様とタスクを刻んで “AI に説明できる言語” に翻訳し続ける PM 力が不可欠！」**

Transcript

1. バイブコーディングで ちゃんとした開発が できるか試してみた
2. 目的 - AIを使って非エンジニアが独力で開発を遂行できるか検証したい - そのために1行も実コードを見ずにAI駆動開発してみた
3. 想定する未来 イケてるPMがAIを使って 一人で本格的サービスを「安定的に」 リリースできる！！
4. バトルコマンダーみたいなゲームを作ってみる 引用: https://note.com/wade3direct/n/nb6e6290695ab リアルタイムストラテジーゲーム 戦争シミュレーション ・軍団システム ・アイテムシステム ・拠点システム ・移動システム ・内制システム ・トラップシステム ・兵器開発システム ・etc…etc…
5. バイブスでやるには無理がある！！！！！
6. よくある開発手法を 技術的な詳細に踏み込まずに(重要) 適用することで開発可能なのでは?
7. 開発の流れ - 最低限の要求定義を作らせる - ↑をもとにAIにタスク分解させる - タスクごとにAIにやらせる
8. 開発の流れ - 最低限の要求定義を作らせる - ↑をもとにAIにタスク分解させる - タスクごとにAIにやらせる
9. PRDを作らせる ・ざっくりとした要望を伝え、 PRD(Product Requirements Documen)を作らせる ・参考資料があれば伝える ・(重要)「MVP(Minimum Viable Product)でお願い！」と伝える。過剰になるので ・モデルはo3やClaude Opus4あたりがおすすめ。最低でも Gemini 2.5 Proが使えるとベター(2025/7月時点)
10. 精緻なPRDができた！
11. ClaudeCodeとPRDをブラッシュアップ - ざっくりチェックして 過剰なものを更に削らせる - 必要だと思われるものを追記させる
12. 開発の流れ - 最低限の要求定義を作らせる - ↑をもとにAIにタスク分解させる - タスクごとにAIにやらせる
13. ClaudeCodeにエピックとタスク一覧を作らせる
14. タスクが作成された！
15. タスクをClaudeCodeとブラッシュアップする - Epicはシステム単位で作らせる - 機能が疎になって後続のエラー祭りが軽減される - ざっとEpicとタスクを見て、不要そうなものがあれば意図を聞いて削る - どの順番で実施すればよいかも相談し、順番を並び替える
16. PRD, Epic, タスクは常に更新し続ける 開発が進んでいくと、PRDもタスクもどんどん変わっていく 違和感を感じたら適宜ClaudeCodeに相談し、変更をしてもらう
17. なにか実装を行うときのMUSTルール - 要望の追加があるときは、要望を伝え、PRDを更新させる -> Epicとタスクを更新さ せる -> 作業させる の順番を徹底 - ドキュメントにまとめずに追加要望を行うのは、PMがチケットも発行せずに Slackで要件を伝えて五月雨実装させる行為に近い - 仕様の出元がわからなくなり、終わる - リアル現場でも大炎上するパターンw - 五月雨で実装させた場合は、後追いでPRDとEpicとタスクを更新させる - そういうCLAUDE.mdルールを作っておくと楽(あとで説明する)
18. なにか実装を行うときのMUSTルール - 作業の節目で必ずgit commitしておく - PRD更新したとき - Epicとタスクを更新したとき - 実装を変更したとき - git commitをClaudeCodeにやらせるカスタムコマンドを作っておく - https://gist.github.com/yheihei/8c7561ed76367181ab59990e15c1b986 - 下記をやるだけで適切な粒度でcommitしてくれる
19. ここまでやると もはやバイブスではない...w 現場レベルのプロダクトマネージメント → しかしAIに命令できるので圧倒的に簡単 → 無茶言ってもすぐにやるし質も高い
20. 開発の流れ - 最低限の要求定義を作らせる - ↑をもとにAIにタスク分解させる - タスクごとに AIにやらせる
21. エピック or タスク単位でClaudeCodeにやらせていく
22. これを繰り返した結果 軍団をクリックすると移動指示のメニューが出る
23. これを繰り返した結果 移動地点を選び
24. これを繰り返した結果 敵軍団を発見したら敵軍団を表示 -> 装備で攻撃開始
25. これを繰り返した結果 あたったらダメージ。攻撃力と防御を勘案してヒットするか判定
26. システムのトロ部分を完成させることが できました！
27. 検証結果 - 微エンジニアなPMなら、完成までフルAIで 行ける可能性 PRDとタスク粒度が適切であれば、十分にイケる。 あとテストでのデグレ検知 - 圧倒的なスピード。8時間稼働で88コミット
28. 【超重要】 その他やったほうがよいこと
29. エピックとタスク単位でテストコードを作らせる - 期待値だけ見て変な方向に行ってないか確認 - ClaudeCodeがデグレを検知し修正する ルールファイルで必ずテスト実行せよと厳命
30. CLAUDE.mdで開発フローを定義する - フェーズごとにやることを箇条書きで書く - 汎用知識は外出しでmdファイルを作り、@で言及して読ませる https://github.com/yheihei/cn-commander/blob/main/CLAUDE.md
31. CLAUDE.mdで開発フローを定義する - テスト作成ルールはちゃんと作っておく (次ページで解説) https://github.com/yheihei/cn-commander/blob/main/CLAUDE.md
32. CLAUDE.mdで開発フローを定義する - エピックごとに統合テストを作らせる - ある機能Aを作ったときに、機能Bがバグる、みたいなのを自動検出する https://github.com/yheihei/cn-commander/blob/main/.claude/rules/integration-test. md
33. CLAUDE.mdで開発フローを定義する - 作業の最後に - PRDや基本設計書を更新させる - テストを実行させる → これでバグったときに自律的に修正を始める https://github.com/yheihei/cn-commander/blob/main/CLAUDE.md
34. CLAUDE.mdに開発に必要なコマンドを書いておく - 開発に必要なコマンドをClaudeCodeに「書かせる」 https://github.com/yheihei/cn-commander/blob/main/CLAUDE.md
35. たまに/init コマンドを使ってCLAUDE.mdを更新させる - 機能追加したタイミングで /init コマンドを実行してアーキテクチャ概要を更新する - この情報があると、ClaudeCodeがより効率よく開発できるようになる https://github.com/yheihei/cn-commander/blob/main/CLAUDE.md
36. おしまい