Vibe Coding × 仕様駆動開発 × テスト駆動開発

作成日：2026年2月28日(土)

１．この記事で伝えたいこと

対象読者： Vibe Codingに興味があるが、AIが生成したコードの品質管理に不安を感じている方。プログラミング初心者〜中級者を想定しています。

• Vibe Coding の楽しさと危うさを理解する
• 仕様駆動開発（SDD）・テスト駆動開発（TDD）がなぜ必要かを直感的に理解する
• cc-sdd を使った具体的な開発フローのイメージを掴む

２．Vibe Codingってなに

キーメッセージ：「AIに話しかけるだけでコードが書ける時代が来た」

• Vibe Coding の定義
  • 自然言語（日本語・英語）でAIに指示してコードを生成する開発スタイル
  • 「雰囲気（Vibe）」でコーディングするというニュアンス
  • Andrej Karpathy が提唱した概念
• Vibe Coding の魅力
  • プログラミング経験が浅くても動くものが作れる
  • アイデアをすぐ試せる爆発的なスピード感
  • Claude Code / Cursor / GitHub Copilot などのツールが普及
• 具体的なイメージ（ビフォー/アフター）
  • Before：「ログイン機能を実装したい → 何時間もかけてコードを書く」
  • After：「ログイン機能を作って → 数分でコードが生成される」

３．Vibe Coding の落とし穴

キーメッセージ：「雰囲気だけで作ると、雰囲気だけで壊れる」

• よくある失敗パターン
  • AIが「それっぽいけど間違ったコード」を生成してしまう
  • どんどん機能を追加するうちに、前の機能が壊れる
  • 「なぜ動いているのか」「なぜ壊れたのか」がわからない
  • AIへの指示が曖昧なので、毎回違う結果が出る
• 問題の本質
  • 「何を作るか」が曖昧なまま作り始めている
  • 「ちゃんと動いているか」確認する仕組みがない
  • AIは「意図」を読み取れず「文字」を処理している
• たとえ話
  • 設計図なしに大工に「いい感じの家を作って」と頼むようなもの
  • 途中で「やっぱりここ変えて」を繰り返すと、どんどんおかしくなる

４．仕様駆動開発（SDD）で「何を作るか」を明確にする

キーメッセージ：「AIへの指示書＝仕様書を先に書く」

• SDD（Specification-Driven Development）とは

  • コードを書く前に「仕様書」を書くアプローチ
  • 仕様書＝AIへの設計図・指示書
  • 「何を」「どう動くべきか」を人間が先に定義する

• 仕様書に書くべきこと（初心者向けシンプル版）

  • 機能の目的（何のために作るか）
  • 入力と出力（何を渡して何が返るか）
  • 正常系・異常系のシナリオ（どんな場合に何が起きるか）
  • 制約・前提条件

• SDD のメリット

  • AIへの指示がブレなくなる → 再現性が上がる
  • 「作るもの」が人間・AIの間で共有される
  • 後から「何を作ろうとしていたか」を追跡できる

補足：SDD の変遷と提唱者

SDD は一夜にして生まれた概念ではなく、ソフトウェア工学の長い歴史の中で育まれてきた。各時代の知見が積み重なり、AI時代の開発スタイルとして結実している。

５．テスト駆動開発（TDD）で「ちゃんと動くか」を確認する

キーメッセージ：「テストが通れば安心、テストがあれば壊れても気づける」

• TDD（Test-Driven Development）とは
  • コードを書く前にテストを書くアプローチ
  • Red（失敗）→ Green（成功）→ Refactor（整理）のサイクル
• なぜVibe Codingにこそテストが必要か
  • AIが生成したコードが正しいかどうか、見た目ではわからない
  • 機能を追加するたびに「前の機能が壊れていないか」を自動で確認できる
  • テスト＝AIへの「合格基準の伝え方」にもなる
• テストの種類（入門レベル）
  • 単体テスト：1つの関数・モジュールが正しく動くか
  • 統合テスト：複数の部品を組み合わせて正しく動くか
  • E2Eテスト：ユーザー操作を模倣して全体が動くか
• TDD のメリット（初心者の言葉で）
  • 「なんか壊れた」を「どこが壊れた」に変えられる
  • AIに「このテストを通らせるコードを書いて」と依頼できる
  • リファクタリング（コード整理）が怖くなくなる

６．Vibe Codingと仕様駆動開発、テスト駆動開発をつなぐcc-sdd

キーメッセージ：「cc-sdd は Vibe Coding を"本物の開発"に変えるレール」

• cc-sdd とは
  • Claude Code をベースにした仕様駆動開発ワークフロー
  • 仕様書テンプレート → コード生成 → テスト生成 を一貫してサポート
  • 「何を作るか（SDD）」と「ちゃんと動くか（TDD）」をセットで管理
• cc-sdd が解決する問題

• cc-sdd の基本的なファイル構成イメージ

  プロジェクト/
  ├── .kiro/
  │   ├── specs/      # 仕様書（SDDのコア）
  │   └── steering/   # プロジェクト全体の方針・ルール
  ├── src/            # AIが生成したコード
  └── tests/          # AIが生成したテスト
  

  ※ cc-sdd では仕様書を .kiro/specs/ に、プロジェクト全体の方針（コーディング規約やアーキテクチャ指針など）を .kiro/steering/ に格納します。

７．実際の開発フロー

キーメッセージ：「仕様を書いて → 生成して → テストして → 繰り返す」

• Step 1：仕様を書く
  • 作りたい機能を仕様書テンプレートに記述
  • 「何を作るか」「どう動くか」「何が成功か」を定義
• Step 2：AIにコードを生成させる
  • cc-sdd の仕様書をもとにClaude Codeへ依頼
  • コードと同時にテストも生成させる
• Step 3：テストを実行する
  • テストが通ればOK（Green）
  • テストが失敗したら仕様を見直すか、AIに修正依頼
• Step 4：仕様→コード→テストを繰り返す
  • 小さな単位でサイクルを回す
  • 積み上げることで複雑な機能も安全に実装できる
• Step 5：仕様を同期する（ドキュメント・ドリフト対策）
  • 開発を繰り返すうちに仕様書と実装がズレていく問題への対処。詳細は 7.3 節を参照

7.1. AI駆動開発 cc-sdd 開発フロー

7.2. 既存のプロジェクトのコードに「仕様駆動」を導入

仕様駆動開発は比較的新しい手法のため、すでに動いているプロジェクトに途中から導入したいケースも多いでしょう。その場合は以下のステップで進められます。

1. まず既存コードをAIに読み込ませ、現状の仕様書を逆生成する
2. 生成された仕様書を人間がレビューし、意図と合っているか確認する
3. 以降の変更から cc-sdd のフローに乗せていく

7.3. ドキュメント・ドリフト

バグ修正や機能変更を繰り返すうちに、仕様書と実装が少しずつズレていく現象を ドキュメント・ドリフト（スペック・ドリフト）と呼びます。SDD を採用していても「コードは直したが仕様書は古いまま」は必ず起きます。

実際に仕様駆動開発を繰り返すと、バグ対策などをしているうちにAIが仕様変更を勝手にしてしまい、仕様書よりもコードが先に進んでしまうケースがあります。
cc-sdd が生成した .kiro/specs や .kiro/steering は、以下のようなプロンプトで乖離を防止できます。

現在の実装を詳細に解析し、変更内容を.kiro/specsや.kiro/steeringにフィードバックして更新してください。
cc-sddのフォーマットを維持しつつ、実装と仕様が100%一致するように調整してください。
特に[具体的に変えた機能名]の部分を重点的に反映してください。

このひと手間で仕様書が"現在の地図"であり続け、次のAI指示もブレなくなります。

８．まとめと今後

キーメッセージ：「Vibe Coding は楽しい。でも SDD+TDD+cc-sdd があれば、楽しく"ちゃんと"作れる」

• この記事の振り返り
  • Vibe Coding：AIと対話してすばやくコードを作るスタイル
  • SDD：「何を作るか」を先に決めることでAIへの指示を明確にする
  • TDD：「ちゃんと動くか」をテストで自動確認する
  • cc-sdd：この3つを統合したワークフロー・ツール
• 初心者への推奨ステップ
  1. まず cc-sdd の仕様書テンプレートを眺めてみる
  2. 小さな機能（関数1つ）の仕様書を書いてみる
  3. Claude Code で「この仕様に沿ったコードとテストを書いて」と頼んでみる
  4. テストを実行して Red → Green を体験する

９．参考リソース

• cc-sdd リポジトリ
  • https://github.com/gotalab/cc-sdd
  • READMEに導入手順があります。Claude Code がインストール済みであれば、数分で始められます。
• 関連 Zenn記事
  • Kiroの仕様書駆動開発プロセスをClaude Codeで徹底的に再現した
• 関連 Qiita 記事
  • cc-sdd で始める仕様駆動開発
• gotaさんのSpeakerdeck
  • Claude Codeは仕様駆動の夢を見ない

１０．付録：用語集（初心者向け）

No	用語	説明
1	Vibe Coding	自然言語でAIにコードを生成させる開発スタイル
2	SDD	Specification-Driven Development。仕様書を先に書いてから開発する手法
3	TDD	Test-Driven Development。テストを先に書いてから実装する手法
4	cc-sdd	Claude Code ベースの SDD ワークフロー・ツール
5	仕様書	「何をどう作るか」を定義したドキュメント。AIへの設計図
6	単体テスト	1つの関数やモジュールが正しく動くかを確認するテスト
7	Red/Green	TDDの状態。Red＝テスト失敗、Green＝テスト成功
8	リファクタリング	動作を変えずにコードの構造を整理・改善すること
9	ドキュメント・ドリフト	実装変更が繰り返される中で、仕様書と実際のコードがズレていく現象。スペック・ドリフトとも呼ぶ