バイブコーディングに仕様書は不要？現場で痛感した「書くべき仕様」の正体
# バイブコーディングに仕様書は不要？現場で痛感した「書くべき仕様」の正体
「仕様書なんて書かなくていい。AIにざっくり伝えれば動くものができる」——バイブコーディングが広まるにつれて、こんな声をよく聞くようになった。
正直に言おう。私たちも最初はそう思っていた。
2025年後半、あるクライアントのプロジェクトでバイブコーディングを導入した。CursorにReactのダッシュボードを作らせたら、30分で見栄えのいいUIができた。チーム全員が興奮した。「これは開発の常識が変 わる」と。
ところが2週間後、機能追加のたびにUIが崩れ始めた。認証周りのロジックが毎回リセットされる。APIのエラーハンドリングが消える。修正を重ねるほどコードが肥大化し、3週間目には「もう一回ゼロから作り直したほうが早い」という結論になった。
何が足りなかったのか。答えはシンプルだった。仕様書がなかった。
「仕様書不要」という誤解はどこから来たのか
バイブコーディングの提唱者であるAndrej Karpathyの原文を読み返してみると、実は「仕様書を書くな」とは一言も言っていない。彼が言ったのは「コードの細部を気にせず、雰囲気（vibe）で進める」ということだ。
ここに大きな誤解がある。
コードの細部を追わないことと、何を作るかを決めないことはまったく別の話だ。バイブコーディングが省略するのは「実装の詳細設計」であって、「何を・なぜ・誰のために作るか」という仕様ではない。
むしろ逆だ。AIが書くコードを人間がレビューしないからこそ、入力段階の仕様精度がすべてを決める。曖昧な指示から生まれるのは、曖昧なコードだけだ。
Stanford大学とUIUCの共同研究（2024年）では、AIコーディングアシスタントを使う開発者はセキュ リティ脆弱性を混入させる確率が41%高かったという結果が出ている。原因の多くは、生成コードを無検証で受け入れたことにある。仕様がなければ、何が正しい動作なのかを判定する基準すら存在しない。
バイブコーディングで仕様書が「より重要」になる3つの理由
理由1: AIはコンテキストを忘れる
ChatGPTもClaudeもCursorも、コンテキストウィンドウには上限がある。会話が長くなれば古い情報は押し出される。「前に伝えた認証の仕様を覚えてる？」と聞いても、答えは「いいえ」だ。
仕様書はAIの外部メモリとして機能する。セッションが切れても、新しいチャットを始めても、仕様書を読み込ませれば同じ前提条件で開発を再開できる。これは人間のチーム開発でも同じだが、AIの場合はさらに切実だ。
理由2: 「動くコード」と「正しいコード」は違う
バイブコーディングでAIが生成するコードは、ほぼ確実に「動く」。だが「仕様通りに動く」かどうかは別問題だ。
たとえば「ユーザー登録フォームを作って」と指示すれば、フォームはできる。でも、パスワードの最小文字数は？メールアドレスの重複チェックは？登録後のリダイレクト先は？ これらを 指定しなければ、AIは「なんとなく妥当な」デフォルト値で埋める。その「なんとなく」が、後になって致命的なバグになる。
仕様書があれば、生成されたコードが正しいかどうかの判定基準が明確になる。テストコードの生成にも仕様書は不可欠だ。実装コードからテストを書かせると、バグごと肯定する無意味なテストが生まれる。仕様からテストを書かせる——これが仕様駆動開発（SDD）の核心でもある。
理由3: チーム開発ではプロンプト履歴が共有できない
一人でバイブコーディングするなら、プロンプトの履歴が自分の頭の中にある。だがチーム開発になった瞬間、「あのとき何を指示したか」は共有不能だ。
Slackの会話やチャットの履歴を追いかけて仕様を復元する——これは2020年代前半に散々経験した「議事録がない会議」の再来だ。仕様書は、チーム全員とAIが参照できる唯一の「真実の源泉（Single Source of Truth）」になる。
実践：バイブコーディングに最適な仕様書の書き方
では具体的に、どんな仕様書を書けばいいのか。従来のウォーターフォール型の100ページの設計書ではない。バイブコーディング時代の仕様書は、もっとコンパクトで、もっと実用的だ。
私たちが実際のプロジェクトで使っているフォーマットを公開する。
レベル1: プロジェクト概要（必須・最低限これだけ書く）
# プロジェクト概要
## 何を作るか
- 社内向け経費精算ダッシュボード
## 誰が使うか
- 経理部門（承認者）と一般社員（申請者）の2ロール
## 技術スタック
- Next.js 15 / TypeScript / Supabase / Tailwind CSS
## 絶対に守る制約
- 既存の会計システムAPIとの連携が必須
- レスポンシブ対応（モバイルから申請できること）
- 認証はSupabase Authを使用これだけでも、何も書かない状態とは雲泥の差がある。AIはこの制約の中でコードを生成するようになる。
レベル2: 機能仕様（推奨・チーム開発なら必須）
# 機能仕様
## 経費申請機能
- 申請者が金額・日付・カテゴリ・領収書画像を入力して申請
- カテゴリは「交通費」「交際費」「消耗品」「その他」の4種
- 1件あたりの上限額: 50万円（超過時はエラー表示）
- 申請後のステータス: 申請中 → 承認済 / 差戻し
## 承認フロー
- 承認者は一覧画面から申請を確認・承認・差戻し
- 差戻し時はコメント必須
- 承認後は会計システムAPIに自動連携
## 通知
- 申請時: 承認者にメール通知
- 承認/差戻し時: 申請者にメール通知ポイント は選択肢と境界値を明示することだ。「カテゴリを選べる」ではなく「4種のカテゴリから選ぶ」。「上限がある」ではなく「50万円」。AIは具体的な数字があると、バリデーションロジックまで正確に生成してくれる。
レベル3: 振る舞い定義（大規模開発・SDD向け）
ここまで書けば、AIの出力精度は飛躍的に上がる。私たちが仕様駆動開発（SDD）で使っている形式に近い。
# 振る舞い定義
## 経費申請の作成
- Given: ログイン済みの申請者がダッシュボードにいる
- When: 「新規申請」ボタンを押す
- Then: 申請フォームが表示される
## 上限額超過時
- Given: 申請フォームに金額「600,000」を入力
- When: 「申請」ボタンを押す
- Then: 「1件あたりの上限額（50万円）を超えています」とエラー表示
- And: 申請は送信されないGiven/When/Then形式で書くと、そのままテストコードに変換できる。バイブコーディングでも、この仕様書を渡してテストを先に生成し、実装はテストを通すように書かせる——いわゆるTDD的アプローチが可能になる。
やりがちな失敗パターン3つ
失敗1: 仕様書を最初に完璧にしようとする
ウォーターフォール型の発想で、100%の仕様書を最初に作ろうとすると挫折する。バイブコーディングの良さは速度だ。その速度を殺してはいけない。
おすすめはレベル1から始めて、問題が出たらレベル2に書き足すという段階的アプローチだ。最初から完璧を目指さない。ただし、レベル1すら書かずに始めるのは論外だ。
失敗2: 仕様書をプロンプトの中だけに書く
「AIとのチャットの中で仕様を伝えたから大丈夫」——これは仕様書ではない。コンテキストウィンドウから消えた瞬間、その仕様は存在しなくなる。
仕様は必ず独立したファイル（`spec.md`や`requirements.md`）として保存する。AIツールの多くは、プロジェクトのルートにあるドキュメントを自動で読み込む機能がある。Cursorなら`.cursorrules`、Claude Codeなら`CLAUDE.md`に仕様の参照先を書いておくと効果的だ。
失敗3: UIの仕様だけ書いてロジックを書かない
「画面はこんな感じで」とモックアップを渡すプロジェクトは多い。でも、画面の裏側のロジック——バリデーション、エラー処理、状態遷移——が書かれていないと、AIは「見た目は正しいが中身がスカスカ」なコードを生成する。
これがバイブコーディングの「3ヶ月の壁」の正体でもある。見た目はすぐできるが、ビジネスロジックの複雑さに対応できず、破綻する。
仕様書を書く時間は「投資」である
「仕様書を書く時間がもったいない」という声は根強い。だが、私たちの経験では仕様書に1時間かけることで、手戻りに費やす10時間を節約できている。
Google Cloudが提唱する「会話駆動開発」でも、開発プロセスは仕様書をコードに機械的に翻訳する静的な作業から、アイデアを共に育て上げる動的な対話へと変化している、としている。仕様書の形は変わっても、「何を作るかを明文化する」という本質は変わらない。
ちなみに、仕様書そのものもAIに書かせることができる。「こんなアプリを作りたい。仕様書を作って」と指示すれば、たたき台は5分でできる。人間がやるのは、その仕様書に抜け漏れがないかレビューすることだ。AIが書いたコードはレビューしなくても、AIが書いた仕様書はレビューする。この使い分けがバイブコーディング時代の肝だ。
バイブコーディングと仕様駆動開発は対立しない
バイブコーディン グと仕様駆動開発（SDD）の違いについて、「どちらか一方を選ぶべき」と考える人は多い。だが実際は、この2つは補完関係にある。
バイブコーディングは速度を担当する。プロトタイプを素早く形にし、アイデアを検証する。仕様駆動開発は精度を担当する。仕様書でAIの出力品質を保証し、チーム開発でのスケーラビリティを確保する。
私たちのチームでは、プロジェクトのフェーズによって使い分けている。
- アイデア検証フェーズ: バイブコーディング（レベル1仕様書）で素早くプロトタイプ
- MVP開発フェーズ: レベル2仕様書を追加し、機能を固めていく
- 本番開発フェーズ: SDD（レベル3仕様書）で品質とテストを担保
この段階的なアプローチなら、バイブコーディングの速度を殺さずに、プロダクションレベルの品質を実現できる。
仕様書を書くことは、バイブコーディングの否定ではない。むしろ、バイブコーディングを「使える手法」に昇華させるために不可欠なピースだ。
AIにコードを書かせる時代だからこそ、「何を作るか」を言語化する力がこれまで以上に問われている。あなたのチームでは、どのレベルの仕様書から始めるだろうか。
バイブコーディングと仕様駆動開発を組み合わせたAI開発に興味がある方は、株式会社Atsumellの開発パートナーサービスまでお気軽にご相談ください。プロトタイプから本番開発まで、プロジェクトのフェーズに合わせた最適なアプローチをご提案します。
