【Vibe Codingその6】requirements.mdから詳細設計書へ。Codexが作った detailed_design.md の目次を公開
はじめに：要件定義の次は「実装できる仕様」に落とす
前回（その5）では、Geminiが出力した要件定義（設計指示プロンプト）を実物公開しました。
今回はその次のステップとして、**詳細設計書（実装できるレベルの仕様）**を作った話です。
要件定義は「何を作るか」までは決まりますが、Vibe Codingで実装に入るときは、
- 画面でどう操作する？（導線）
- データはどう持つ？（DB/CSV）
- どこから作る？（タスク分割）
が曖昧だと、AIも人間も迷子になりやすい。
そこで今回は、要件定義をベースに Codexに詳細設計書を作らせてから 次に進む形にしました。
これまでの記事（その1〜その5）
- その1：https://comp.make-all.net/vibe_coding_01
- その2：https://comp.make-all.net/vibe_coding_02
- その3：https://comp.make-all.net/vibe_coding_03
- その4：https://comp.make-all.net/vibe_coding_04
- その5：https://comp.make-all.net/vibe_coding_05
結論：requirements.md を“唯一の正”にして、Codexに詳細設計書を書かせる
今回やったことはかなりシンプルです。
- Geminiが作った要件定義を
requirements.mdにまとめる requirements.mdを GitHub にコミット＆プッシュ（AIが参照できる状態にする）- Codexへ「GitHub上の requirements.md を見て、詳細設計書を作って」と指示
- Codexが
detailed_design.md（詳細設計書）を作成
ポイントは、要件定義をコピペで渡すのではなく、リポジトリ上のファイルとして置いた上で参照させたところ。
あとでIssue化・実装・修正を回すときに、「どれが最新？」がブレにくくなります。
なぜ詳細設計書を作ったか：次に何をすべきかGeminiに聞いた
詳細設計書を作るきっかけは、要件定義書を作った後に
次に何をすべき？
とGeminiに相談したら、
詳細設計書を作る
と提案されたからです。
要件定義があるだけだと、「実装の粒度」が足りず、結果的に
- 画面はあるけど押せない
- 追加の導線がない
- どこにデータが入るのか曖昧
みたいなズレが出やすい（このあたりは、後の“その8”にも繋がる話です）。
だから、実装前に「仕様」を固める工程として詳細設計書を挟むことにしました。
生成された成果物：detailed_design.md（目次を公開）
Codexが出力した詳細設計書の見出し（目次）は以下です。
この時点で「実装に必要な論点」が一通り揃っているのが分かります。
# 株式投資統合管理システム 詳細設計書
## 改訂履歴
## 1. 詳細エンティティ定義（データベース設計）
## 2. iDeCOスイッチングのステートマシン図
## 3. リバランス計算アルゴリズム
## 4. AI分析用エクスポート仕様
## 5. リスク管理計算ロジック
## 6. GUI画面遷移図とレイアウト詳細案
## 7. 技術スタック推奨
## 8. 次のステップ
目次を見て「何が決まったか」をざっくり解説（その6の価値ポイント）
この目次の並びを見るだけでも、要件定義から一段降りて「仕様」になっているのが分かります。
1. 詳細エンティティ定義（データベース設計）
保有・口座・目標配分・売買履歴・為替…みたいなデータの持ち方がここで決まる想定です。
私はCSVヘッダーや項目のイメージはできる一方で、型や制約など細かいところは理解しきれていません（正直ここは難しい）。
3. リバランス計算アルゴリズム / 5. リスク管理計算ロジック
ここは「投資支援システムの中核」になる部分。
要件定義では“やりたいこと”だったものが、数式やロジックとして記述される段階です。
4. AI分析用エクスポート仕様
外部AIで分析するためのCSV設計や、プロンプトテンプレなどが固まるパート。
後の実装（CSV出力機能）に直結します。
6. GUI画面遷移図とレイアウト詳細案
「画面はどう分ける？どこからどこへ遷移する？」が決まるパート。
この段階で導線を詰められると、後で“使えないUI”になりにくいはず。
8. 次のステップ
ここが、次回の「Issue化」へつながる場所。
設計書を見ながら「実装チケットに分割する」工程に移ります。
正直、詳細設計書は“全部理解できてはいない”
今回のリアルな話として、詳細設計書は見たけど、正直よく分からない部分も多かったです。
- DB設計（型・制約・リレーション）は難しい
- ただ、CSVヘッダーや項目の考え方はイメージできる
- そして「この設計書を元にIssue化できる」状態になったのが大きい
Vibe Coding的には「全部を理解してから進む」より、成果物を作り、次の工程に渡し、動かしながら学ぶのが現実的だと感じました。
次回（その7）予告：詳細設計書をIssue 1〜23に分割して実装へ
次回は、この詳細設計書を元に作った GitHub Issue（1〜23） の話です。
YouTubeで見た「チケット駆動（細かい作業に分割して管理する）」を参考にして、GitHubのIssueとして管理しました。
そしてCodexに、Issueを1つずつ投げて実装を進めました。
おわりに
要件定義の次に迷ったら、requirements.mdを唯一の正として置き、AIに詳細設計書を書かせるのはかなりアリだと思いました。
次回は、その詳細設計をどうIssue化したか、実例ベースでまとめます。