小さく作り、作り直しゼロで実装する。4フェーズ方法論
実装前に「企画書 → 仕様書 → 要件定義書」の3点を作り、整合性を潰し切ってからコードを書く。手戻りは下流ほど高くつくので、安い上流（人間の思考＝壁打ち）で詰め、高い下流（AI実装のやり直し）を発生させないのが最大のコスパ。
「課題が解ける最小限の機能だけ」で作る最初のプロダクト。全部盛りで作らず、まず“効くかどうか”を最小コストで検証する。
なぜコスパに効く？作る量が減る＝実装コスト・トークン・時間が減り、外したときの損失も小さい。だから「最小で作る＝MVP」とこの方法論は相性が良い。
バイブコーディングはAIに実装を任せる。だからこそ「作る量」が失敗率に直結する。盛るほど崩れ、絞るほど通る。
AIが一度に把握できる情報量には上限がある。機能を盛るほど仕様とコードが膨れ、AIが全体像を保持できず、整合性が崩れて“ちぐはぐな実装”になる。
MVPなら仕様が1つの文脈に収まり、AIが最初から最後まで一貫したコードを出せる。
機能が増えるほど依存関係が絡み合い、1箇所の修正が別の機能を壊す。「直す → また壊れる」ループでトークンと時間が溶ける。
MVPなら影響範囲が小さく、修正が局所で完結する。
全部盛りで作ると、どの機能がユーザーに効いたのか切り分けられない。市場に当てる前に作り込むので、外したときの損失が最大化する。
MVPなら“効くコア”だけ先に出して、当たり外れを最小コストで検証できる。
バイブコーディングはAIが仕様の隙間を勝手に埋める。機能が多いほど曖昧な隙間が増え、意図しない挙動が量産される。
MVPなら仕様を詰め切れる範囲に収まり、隙間＝バグの余地が生まれない。
完成が遠いほどリリースが見えず、挫折・放置に向かう。その間もAPI課金と工数だけが積み上がる。
MVPなら短期でリリースに到達し、収益と学びを早く回収して次に再投資できる。
思考がすべてドキュメントに残るから、人にも案件にも依存しない。
3つの文書がそのままプロンプトになるから、指示は「これを正として作れ」の一行で済む。
バイブコーディングで金と時間を溶かす原因は、実装力ではなく上流の曖昧さにある。安い工程（壁打ち）にコストを寄せ、高い工程（実装）を最短化する。
| 溶けるコスト | 発生原因 | この方法論での対策 |
|---|---|---|
| トークン浪費 | 仕様が曖昧 → AIが何度も作り直す | 上流で仕様を確定させ、実装を一発で通す |
| 手戻り工数 | 実装後に「これ違った」が判明 | 整合性チェックで実装前に矛盾を潰す |
| 判断のブレ | 途中で目的がすり替わる | 企画書で「ブレない軸」を先に固定 |
| 意思決定の後戻り | WHYが定義されていない | 5W1H＋FABで根拠を言語化 |
手戻りコストは「企画 ＜ 仕様 ＜ 要件 ＜ 実装 ＜ リリース後」の順で指数関数的に増える。だから、コストの安い上流ほど徹底的に壁打ちする。
Goalこの開発が「誰の・どんな課題を・なぜ今・どう解くのか」を1文で言える状態にする。ここがブレると全工程がブレる。
| 項目 | 定義 | 問い |
|---|---|---|
| Fact（ファクト） | 機能・数値・スペック | 何ができる機能か？ |
| Advantage（メリット） | その機能で何が可能になるか | それによって何が起きる？ |
| Benefit（ベネフィット） | 理想の未来像 | 使う人はどうなりたい？ |
Goal選んだ解決方法の「具体的な作り方」を確定する。ここは何度も何度も壁打ちする工程。
| 項目 | 内容 |
|---|---|
| 機能一覧 | MVPに必要な機能を優先度順（Must（必須）／Should（重要）／Could（あれば良い））で列挙 |
| 画面・UI | 画面数、各画面の要素、遷移 |
| 導線設計 | 入口 → CV までのユーザーフロー |
| データ構造 | 扱うデータ、テーブル／項目のイメージ |
| 外部連携 | API、認証、決済など |
| 非機能要件 | 性能・セキュリティ・想定件数・同時利用 |
| 対象外（やらないこと） | スコープ外を明記して肥大化を防ぐ |
Goal企画書＋仕様書からAIに要件定義を生成させる。AIに変換させること自体が、抜け漏れ・矛盾のあぶり出しになる。
添付の kikaku.md と spec.md を唯一の正とし、要件定義書 requirements.md を作成せよ。
条件：
- 企画書・仕様書に書かれていない内容を勝手に追加しないこと
- 曖昧な箇所・矛盾する箇所・記述漏れは「【要確認】」タグを付けて末尾にリスト化
- 機能要件と非機能要件を分けて記述すること
- 各要件に企画書のどの課題に対応するかを紐づけること
出力：requirements.md（本文）＋【要確認】リスト
AIが吐く「【要確認】リスト」こそが上流のバグ。実装前にこれを潰せば、実装後の手戻りがほぼ消える。
Goal企画書・仕様書・要件定義書を突き合わせ、違い・違和感をピックアップして潰し切る。ここを飛ばすと実装で必ず崩れる。
kikaku.md / spec.md / requirements.md の3つを突き合わせ、以下を出力せよ。
1. 3文書間の「矛盾点」一覧（どことどこが食い違うか明記）
2. 片方にしか存在しない「片側記述」一覧
3. 目的（企画書）に対して過剰・不足している機能（仕様書）
4. 各項目に対する違和感・リスクの指摘
各指摘に対して、解消のための選択肢を提示せよ。
Goal矛盾ゼロの3文書が揃った状態なら、AIは一発で通りやすい。
添付の requirements.md / spec.md を唯一の正として実装せよ。 仕様に書かれていない挙動を勝手に実装しないこと。 不明点は実装を止めて質問すること。
| Phase | 何を固めるか | 成果物 | 主体 |
|---|---|---|---|
| 1 企画書 | WHY（目的・課題・ベネフィット） | kikaku.md |
人間×AI（壁打ち） |
| 2 仕様書 | HOW（作り方） | spec.md |
人間×AI（壁打ち） |
| 3 要件定義 | WHAT（整理・検証） | requirements.md |
AI生成 |
| 4 整合性 | 矛盾ゼロ化 | 修正済み3文書 | 人間 × AI |
| 5 実装 | コード化 | 動くプロダクト | AI（Claude Code） |
このホワイトペーパーには、AI開発を安定させるコツが詰まっている。「壁打ち」（一緒に考える）と「整合性チェック」（矛盾を見つける）を習慣にするだけで、実装のブレと作り直しが驚くほど減る。
結果、実装が一発で通り、トークンも時間もムダが消える。やってみると、バイブコーディングが驚くほど安定するのがわかる。
企画の壁打ちから、仕様・要件の整合性チェック、Claude Codeでの実装まで。この方法論を、あなたのプロダクトで一緒に回します。まずは「何を・なぜ作るか」の壁打ちから。
お問い合わせ →