バイブコーディングに設計書はどこまで必要か
「AIがコードを書いてくれるなら、設計書はいらないのでは？」
バイブコーディングを始めたチームで、かなり高い確率で出てくる問いだ。実際、最初の数週間はそう見える。プロンプトを書けば画面ができる。エラーを貼れば直してくれる。小さな機能なら、設計書を書く前に動くものが出てくる。
この体験は強い。だからこそ危ない。
設計書を全部捨てると、最初は速くなる。ただし、2回目の修正から急に苦しくなる。AIはコードを読めるが、「なぜその設計にしたのか」は自然には読めないからだ。
捨てていい設計書と、捨ててはいけない設計書
まず分けて考えたい。設計書には、残す価値が薄いものと、AI時代ほど価値が上がるものがある。
捨ててもいいのは、実装をなぞるだけの設計書だ。
- 画面項目をコードと同じ順番で写しただけの一覧
- SQLやAPIレスポンスをそのまま貼っただけの資料
- 実装後に帳尻合わせで作る納品用ドキュメント
こうした文書は、AIがコードを読めるようになった今、価値が下がっている。むしろ更新コストだけが残る。
一方で、捨ててはいけない設計書がある。判断の理由を残す設計書だ。
- なぜこの業務フローにしたのか
- なぜこの制約を入れたのか
- 何をやらないと決めたのか
- どの条件を満たしたら成功なのか
ここはコードだけでは復元しにくい。AIにコードを読ませても、「この例外処理は顧客要望なのか、過去障害の対策なのか、単なる実装都合なのか」は判断でき ない。
以前書いたAI駆動開発とバイブコーディングは何が違うのかでも触れたが、両者の違いはツールではなく運用設計にある。動くコードを速く出すだけならバイブコーディングでいい。チームで継続して直すなら、設計の意図が必要になる。
最小限残すべき3つの設計情報
では、何を残せばいいのか。全部の設計書を復活させる必要はない。最小限でいい。
1. 変更理由
最初に残すべきなのは、変更理由だ。
「なぜこの機能を作るのか」「なぜ今変えるのか」「誰の何を解決するのか」。ここがないと、AIは実装の方向を間違える。
たとえば「検索画面に絞り込み条件を追加する」という依頼がある。コード上は単純だ。でも背景が違えば、実装は変わる。
- 営業担当が商談を探しやすくしたい
- 管理者が監査ログを追いやすくしたい
- 顧客が過去の申請を見つけやすくしたい
同じ「絞り込み」でも、必要な項目、初期値、権限、検索速度の優先度が変わる。AIに伝えるべきなのは、画面部品の名前より先にこの理由だ。
2. 制約
次に必要なのは制約だ。
バイブコーディングで壊れやすいのは、実装そのものより境界条件だ。既存データを消してはいけない。外部APIの呼び出し回数に上限がある。特定ロールでは見せてはいけない項目がある。こうした制約は、コードのあちこちに散らばる。
AIは局所的な修正には強い。ただ、プロジェクト全体の制約を毎回覚えているわけではない。だから制約だけは、短くてもいいので明文化しておく必要がある。
形式は簡単でいい。
## 制約
- 既存の申請データは削除しない
- 管理者以外は金額項目を閲覧できない
- 外部APIは1分60回まで
- CSV出力は既存フォーマットを維持するこれだけでも、AIの提案はかなり変わる。
3. テスト観点
最後に残すべきなのはテスト観点だ。
AIがコードを書けるようになるほど、人間の仕事は「何を確認すればOKか」を決める側に移る。ここを曖昧にすると、AIは動くコードを出すが、業務上使えるかどうかは保証できない。
テスト観点は、詳細なテスト仕様書でなくていい。
- 正常系で何ができればよいか
- 例外系で何が起きてはいけないか
- 権限別に見え方が変わるか
- 既存機能に影響がないか
この4点だけでも、AIにレビューやテスト生成を頼みやすくなる。バイブコーディングで作ったコードは誰がテストするのかで書いた通り、AI時代の品質保証は「テストを書く」より先に「確認すべき観点を固定する」ことから始まる。
設計書を厚くするのではなく、AIが迷う場所だけ残す
ここで誤解してほしくないのは、昔の重い設計書に戻ろうという話ではない。
AI開発で必要なのは、ページ数の多い文書ではない。AIが判断に迷う場所だけを、短く構造化して残すことだ。
実務では、1機能につき次の4ブロックで十分なことが多い。
## 目的
誰の何を解決するか
## 変更内容
何を変えるか
## 制約
守るべき条件
## 確認観点
何が通ればOKかこのくらいなら、実装前に5分で書ける。しかも一度書けば、AIへのプロンプト、レビュー観点、テスト生成の材料として使い回せる。
つまり、設計書は「人間が読むための儀式」ではなく、AIに判断基準を渡すためのインターフェースになる。
バイブコーディングの次に来るのは、軽量な仕様駆動開発
バイブコーディングは、プロトタイプや小さな改善では強い。手を動かしながら形にするには向いている。
ただ、チーム開発や業務システムでは限界が出る。変更理由、制約、テスト観点がないまま進むと、AIは速く書けても、正しく直し続けることが難しい。
そこで必要になるのが、軽量な仕様駆動開発だ。
重い設計書を復活させるのではない。AIが迷う部分だけを先に書く。コードの前に、判断基準を短く置く。これだけで、バイブコーディングの速さを残しながら、後工程の手戻りを減らせる。
「設計書は必要か」と聞かれたら、答えはこうだ。
全部はいらない。でも、判断の理由・制約・テスト観点は必ずいる。
ここを捨てると、AIは速く書く。だが、チームは遅くなる。
