仕様駆動開発：AIアシストコーディングの解説

概要

この動画では仕様駆動開発（spec-driven development）について解説しています。これはAIアシストコーディングに対する構造化されたアプローチであり、コーディングエージェントの時代にソフトウェア開発ライフサイクル（SDLC）の原則を取り戻すものです。より一般的な「プロンプトを書いて反復する」アプローチであるvibe codingと対比しています。

Vibe Coding：現在のデフォルト

AIコーディングエージェントを使用するほとんどの人は、以下のループに従います：

1. 最初のプロンプトを書く（「PythonでXを作って」）
2. モデルがボイラープレートコードを生成する
3. プロンプトを編集するか、フォローアップの指示を出す
4. 望ましい実装に到達するまで行ったり来たりする

Vibe codingの問題点：

• モデルが毎回異なる解釈をする可能性がある — 100回試すと100通りの結果が出ることもある
• モデルがアーキテクチャの決定をどのように行うかを制御できない
• 従来のSDLC（計画、設計、テスト、デプロイ、保守）をスキップしてしまう
• モデルが特定のアプローチを選んだ理由がわからないため、デバッグが難しくなる

Vibe codingが適している場面： 素早いプロトタイプ、アイデアの検証、その場での小さな編集。

仕様駆動開発：構造化された代替手段

仕様駆動開発は、AI生成による開発にSDLCの要素を再導入します：

ワークフロー

1. 実装ではなく振る舞いをプロンプトする — 「ログインページを作って」ではなく、システムが何をすべきか、その制約、期待される振る舞いを記述する
2. 要件を生成する — LLMが契約として機能する要件仕様書を作成する
3. レビューして承認する — 満足であれば、要件を各実装ステップのTODOを含む設計ドキュメントに変換する。満足でなければ仕様を編集する（まだ何も実装されていない）
4. 実装する — 設計が承認されたら、AIエージェントが仕様に基づいてコードを書く
5. テストする — テストケースは仕様から直接生成できる

例：ユーザー認証

Vibe codingのアプローチ：

「ユーザーが認証するための/loginページが必要です」 → モデルが30通りの実装から1つを選ぶ → 行ったり来たりを繰り返す

仕様駆動のアプローチ：

• 機能： ユーザー認証
• エンドポイント： POST /login
• パラメータ： user, pass
• エラーハンドリング： 特定のエラーコード（例：ユーザー名の欠落）
• テストケース： 有効な認証情報 → 200、欠落フィールド → 特定のエラーコード

仕様は曖昧さを排除します — エージェントは何を実装すべきか、そしてなぜそうするのかを正確に把握できます。

他の開発アプローチとの関係

アプローチ	出発点	フロー
従来型	コードが先	コード → ドキュメント
テスト駆動（TDD）	テストが先	テスト → コード
仕様駆動（SDD）	仕様が先	仕様 → 設計 → コード → テスト

仕様駆動開発は本質的にTDDとBDDの強化版です — 仕様が、実装、テスト、ドキュメント、検証といったすべての下流作業を駆動する主要な成果物となります。

重要なポイント

1. Vibe codingはSDLCをスキップする — プロトタイピングには最適だが、本番アプリケーションでは予測不可能な結果を生む
2. 仕様は曖昧さを減らす — AIモデルは曖昧なプロンプトよりも明確な指示でより良く動作する
3. 承認するまで何も実装されない — コードが書かれる前に要件と設計をレビューする
4. 仕様が契約となる — 実装、テスト、ドキュメントを駆動する
5. 主要なスキルシフト — コードの作成・レビューから、構築したいものを効果的に伝えることへ

---

Claudeによる翻訳