バイブコーディングで20回修正したとき、最初に動いていたログイン機能が壊れた。これはAIが「壊した」のではない。仕様書のない開発の、当然の結果だ。
なぜバイブコーディングは大規模で崩壊するのか
バイブコーディングが威力を発揮するのは、最初の段階だ。「こういうアプリを作って」という一言でプロトタイプが動く。その体験は本物だ。問題は、そこから先にある。
機能を10個、20個と追加していくうちに、何かがおかしくなる。ログイン機能を修正したら検索が壊れた。スタイルを変えたらフォームが動かなくなった。AIに「直して」と言うと直るが、また別の場所が壊れる。この「追いかけっこ」に入ったとき、多くの人が「AIが悪い」と思う。でも根本原因は別にある。
AIはセッションをまたぐと、前の会話を忘れる（正確には、会話が長くなるとコンテキストが圧縮・切り捨てられる）。2週間前に「このデータベース設計にした理由」「この関数がこういう動作をすべき理由」を話していても、AIは覚えていない。目的地を持たずに走り続けるGPSナビのようなもので、再起動するたびにどこへ向かっていたかを忘れる。
さらに深刻なのは、自然言語の指示がブレることだ。同じ機能を追加する指示でも、毎回の言い方が微妙に異なる。AIは毎回、その言い方に合わせてコードを解釈する。一貫した設計思想なしに指示が積み重なるから、コードが矛盾し始める。
仕様書駆動開発（SDD）とは何か
仕様書駆動開発（Spec-Driven Development、SDD）は、コードより先に仕様書（スペック）を書く開発手法だ。
料理で言えば、「なんとなく今日の夕食を作る」から「レシピを書いてから調理する」への転換だ。食材（コード）を鍋に入れる前に、完成形（仕様書）を決める。レシピがあれば、途中でシェフが変わっても（新しいAIセッションに切り替えても）同じものが作れる。
仕様書はAIへの「永続的な指示書」だ。セッションが変わっても、仕様書を読めばAIは同じ判断ができる。
バイブコーディングとSDDの違いを整理しよう。
| 観点 | バイブコーディング | SDD |
|---|---|---|
| 指示の形式 | その場の自然言語 | 仕様書に文書化 |
| 文脈の持続 | セッションごとにリセット | ファイルとして永続 |
| バグの原因追跡 | どこで何を変えたか不明 | 仕様書との差異で特定 |
| 完了の基準 | 「なんとなく動く」 | 受け入れ条件に合格 |
SDDはエンジニア向けの手法ではない。AIと協働するための設計図術だ。コードを書く技術は不要で、必要なのは「何を作るか」「誰のためか」「どうなったら完成か」を言語化する力だけだ。
4ステップのSDDワークフロー
SDDの実践は、以下の4ステップで完結する。
Step 1：並列リサーチ
実装を始める前に、AIに調査をさせる。Claude CodeのSubagents（複数のAIエージェントを並列で動かす機能）を使えば、技術調査・競合調査・実装方法の比較を同時進行できる。
個人実践者の報告では、Subagentsを活用することで仕様作成に要する時間を7時間から1時間に短縮できたケースがある。
Step 2：3つの仕様書を作成する
調査結果をもとに、3つのファイルを作成する。
- requirements.md（要件定義）：「誰が、何を、なぜ必要か」と受け入れ条件
- design.md（設計書）：「どう作るか」のアーキテクチャと技術選定
- tasks.md（タスクリスト）：「何をどの順番で実装するか」の分解
この3ファイルが、AIに対する「唯一の情報源（Single Source of Truth）」になる。コードを書く前にすべての判断をここに集約する。
Step 3：仕様のブラッシュアップ
仕様書の草稿ができたら、AIに読ませて曖昧な部分を質問してもらう。「この条件が矛盾しています」「この場合はどう動くべきですか」という指摘を受けて、仕様を洗練させる。
コードを書き始める前に設計の問題を発見できるのが、SDDの本質的な価値だ。コードを書いた後に「設計が間違っていた」と気づくのと、前に気づくのでは、修正コストがまったく違う。
Step 4：タスク単位の実装
仕様書が完成したら、tasks.mdのタスクを1つずつ実行する。「1タスク = 1コミット」というルールを守る。実装後には仕様書も更新し、コードと仕様書の乖離をゼロに保つ。
エンジニアのAlexey Oparin氏はこのワークフローを実際のプロジェクトに適用し、SQLiteからIndexedDBへのデータベース移行を45分で完了させた。14タスク、14のアトミックコミット（1タスク＝1コミットの原則で記録された変更単位）、15以上のファイル変更を、Claude Codeの200Kトークンコンテキスト（約15万語分のAIの作業記憶）の71%で処理した。
仕様書の中身：具体的に何を書くか
仕様書と言うと身構えてしまうかもしれないが、要点はシンプルだ。
❌ バイブコーディング（場当たり的な指示の積み重ね）
「ログイン機能を追加して」
「やっぱりソーシャルログインも追加して」
「なんかバグってるから直して」
「あ、さっきの機能が壊れた」
↓ セッションが変わると全文脈を失う
✅ SDD（仕様書ファースト）
requirements.md に記述:
「ユーザーとして、メールアドレスとパスワードでログインしたい。
理由：個人のデータにアクセスするため。
受け入れ条件：
- 正しい認証情報でホームページにリダイレクトされること
- 3回失敗でアカウントがロックされること
- セッションは30分で期限切れになること」
→ AIはこの仕様書をセッションをまたいで参照し、一貫した実装を行う
「受け入れ条件」を書くことがポイントだ。「ログイン機能を作って」という指示だけでは、AIは最も素直な——つまり最低限の——実装をする。「3回失敗でロック」「セッション30分」という条件が書いてあれば、AIはセキュリティも考慮した設計を選ぶ。
tasks.mdはこんなイメージだ。
# タスクリスト: ログイン機能
## Phase 1: 認証基盤
- [ ] 1. 認証ライブラリの設定 → requirements.md#SEC-01 参照
- [ ] 2. ログインフォームUIの作成 → design.md#COMP-LOGIN 参照
- [ ] 3. セッション管理の実装 → requirements.md#SEC-03 参照
## Phase 2: セキュリティ強化
- [ ] 4. ログイン試行制限（3回失敗でロック）
- [ ] 5. セッション期限切れ処理（30分）
# 1タスク = 1コミット。実装後に仕様書も更新する。
タスクに仕様書のどのセクションを参照すべきかを明記しておくと、AIがコードを書きながら仕様書を参照しやすくなる。
どのツールを使うか
CLAUDE.mdだけでも始められる
Claude Codeを使っているなら、CLAUDE.mdが最小限のSDD基盤になる。プロジェクトのルートに置いたCLAUDE.mdは、すべてのセッションで最初に読み込まれる。Anthropic社内ではCLAUDE.mdを約2,500トークンで管理している。
# CLAUDE.md（プロジェクトの永続記憶）
## アーキテクチャ原則
- このプロジェクトはSupabase + Next.jsを採用
- データベース: Row Level Securityを必ず有効化
- 認証: Supabase Auth（独自実装禁止）
## 仕様書の場所
- 要件定義: docs/requirements.md
- 設計書: docs/design.md
- タスクリスト: docs/tasks.md
## AIへの指示
- コードを書く前に必ず上記の仕様書を確認すること
- 仕様書に記載のない変更を勝手にしないこと
これだけで、新しいセッションを始めるたびにAIがプロジェクトの設計方針を読み込むようになる。
cc-sdd：コマンド一発でSDDをセットアップ
cc-sddは、SDDのセットアップを自動化するOSSツールだ。Amazon Kiro IDEのAI-DLCに影響を受けて開発され、Claude Code・Cursor・Gemini CLIなど8つのAIエージェントに対応している。
# cc-sddのセットアップ（日本語対応）
npx cc-sdd@latest --claude --lang ja
# 仕様書の初期化
/kiro:spec-init
# 要件定義（requirements.md生成）
/kiro:spec-requirements
# アーキテクチャ設計（design.md生成）
/kiro:spec-design
# タスク分解（tasks.md生成）
/kiro:spec-tasks
# 実装開始
/kiro:spec-impl
GitHub Spec Kit：GitHub公式のSDD拡張
GitHub公式が提供するClaude Code向けのSDD拡張だ。5つのスラッシュコマンドで標準化されたSDDフローを使える。
どのツールを使うにしても、本質は同じだ。「仕様書を先に書き、AIはその仕様書に従う」という順序を守ること。
Plan Modeとの組み合わせ
SDDはPlan Modeと矛盾しない。むしろ補完関係にある。
Plan Mode（Claude CodeではShift + Tabを2回押して起動）は、セッション内の計画に有効だ。AIがコードを書く前にファイルを読み、構造を調べ、実装の計画を作る。計画フェーズでは何も変更しない。
SDDは、そのPlan Modeの成果物をファイルとして永続化するアプローチだと考えるといい。Plan Modeで作った計画を仕様書として保存しておけば、次のセッションでも同じ文脈からスタートできる。
Claude Codeの作者Boris Chernyは、実際のワークフローとして「Plan Modeで計画 → 自動承認モードで一発実装」を使っている。SDDはそこに「仕様書という下地」を加えることで、セッションをまたいでも一貫性が保たれる拡張だ。
いつSDDを使うか、使わないか
SDDは万能ではない。すべての変更に仕様書を書こうとすると、仕様書の管理自体がボトルネックになる。
SDDを使うべき場面
- 実装に1日以上かかる機能
- 複数のファイルにまたがるリファクタリング
- 要件が曖昧で、後から変更が予想されるもの
- チームで複数人がAIを使う場合（認識を揃えるための文書として）
SDDを使わなくていい場面
- 1時間以内で終わるバグ修正
- 捨てる前提のプロトタイプ・動作確認
- 緊急のホットフィックス
建築の例えで言えば、コンビニに行くのに地図と設計図は要らない。でも家を建てるなら図面なしに始めてはいけない。SDDは「家を建てる」ときに使う手法だ。
過大な期待は禁物だ。SDDを導入しても、仕様書の品質が低ければAIは低品質なコードを書く。「ゴミを入れればゴミが出る（Garbage In, Garbage Out）」はSDDでも変わらない。仕様書を書く練習そのものが、開発力を上げる本質だ。
「仕様が主役」という発想の転換
バイブコーディングでプロトタイプが作れるようになったとき、多くの人が「次はもっと大きなものを作りたい」と思う。そこで直面するのが「機能を足すたびに壊れる」という壁だ。
この壁は、コードをうまく書けない問題ではない。設計という作業を飛ばしていることから来る問題だ。
SDDは、その設計をAIとの対話で行う方法論だ。プログラミングの知識は不要だ。「何を作るか」「誰のためか」「どうなったら完成か」を言語化する力だけがあればいい。
コードを書く前に仕様書を書く。AIは仕様書に従ってコードを書く。仕様書とコードの乖離があればそれが問題の場所だ。診断が明確になる分、修正も速くなる。
まず今のプロジェクトのCLAUDE.mdに、「このプロジェクトで守るべき原則」を3行書くことから始めてみてほしい。仕様書駆動開発の入口はそこにある。コードを書く前に、言葉を書く習慣から始める。
コードの品質をさらに高めたいなら、AIを使ったテスト手法もあわせて読んでほしい。