スペック駆動開発とは

はじめに

2025年10月、GitHubはSpec Kitというツールキットをオープンソース化し、「スペック駆動開発」（Spec-Driven Development）という概念をAIプログラミングの世界に正式に持ち込みました。一見レトロに思えるこのアイデア――スペックを先に書いてからコードを書く――は、AIプログラミングツールを使いこなすための新しいパラダイムになりつつあります。

Claude Code、Cursor、GitHub Copilotなどの AIコーディングアシスタントを日常的に使っている方であれば、こんなフラストレーションを経験したことがあるのではないでしょうか。「ユーザーログイン機能を追加して」とお願いすると、AIは張り切って大量のコードを生成しますが、よく見てみると――使い慣れていないフレームワークを使っていたり、セキュリティ方針が期待と違っていたり、UIスタイルが合っていなかったり……そこから何度も修正を繰り返し、疲弊してしまいます。

問題はどこにあるのでしょうか。AIが賢くないのではなく、提供した情報が足りないのです。「ユーザーログイン機能を追加して」は一見明確に見えますが、実際には何百もの未指定の判断が隠れています。どの認証方式を使うのか？パスワードの要件は？ログイン失敗時はどう処理するのか？ログイン状態を記憶する必要はあるのか？サードパーティログインに対応するのか？……AIは推測するしかなく、推測は必ずズレを生みます。

スペック駆動開発は、まさにこの問題を解決するために生まれました。

Vibe Coding：スピードの代償

2025年初頭、元Tesla AI ディレクターの Andrej Karpathy が「Vibe Coding」という言葉を生み出しました。これは「AIの提案を深くレビューせずに受け入れる」開発スタイルを表す言葉です。この用語は瞬く間に広まり、Collins辞書の2025年のWord of the Yearにも選ばれました。

Vibe Codingの魅力は明白です。アイデアを説明すれば、AIがコードを生成し、動いているように見えればそれでよし。ラピッドプロトタイピング、ハッカソン、使い捨てスクリプトであれば、この方法は確かに効率的です。しかし、本番システムに適用すると問題が生じます。

このような話は業界では珍しくありません。AI生成のデータベースクエリが小規模テストでは問題なく動作するものの、実際のトラフィック下ではシステムが這うように遅くなったり、つぎはぎの認証モジュールがQAを通過したのに、2週間後に無効化されたアカウントがまだ管理ツールにアクセスできることが判明したり。Final Round AIの2025年の調査によると、18人のCTOのうち16人がAI生成コードによる本番障害を経験しています。

これはVibe Codingに価値がないということではありません。重要なのは境界を見極めることです。

スペック駆動開発は、AIの効率性を維持しつつ、Vibe Codingの落とし穴を避けることを目指しています。

スペック駆動開発とは

スペック駆動開発のコアとなる考え方は一言で要約できます。「何を作るか」を先に定義し、「どう作るか」はその後に考える。

これはソフトウェアエンジニアリングでは当たり前のことのように聞こえますが、AIプログラミングの時代においては新たな意味を持ちます。従来の要件定義書は人間向けに書かれており、往々にして冗長で曖昧で、専門用語に満ちていました。スペック駆動開発における「スペック」はAI向けに書かれるものであり、簡潔で構造化され、実行可能なものです。

家を建てる場面を想像してみてください。従来のAIプログラミング方式は、施工チームに「快適な3LDKの家を建てて」と伝えて、あとはお任せするようなものです。結果は良いかもしれませんが、想像とは大きくかけ離れたものになる可能性が高いでしょう。スペック駆動開発は、まず建築設計図を描くことに相当します。何階建てか、各階の面積はどれくらいか、窓の向きは、使用する資材の規格は……施工チームは設計図通りに施工するため、結果は自然と期待通りになります。

AIプログラミングにおいて、この設計図が**スペック（仕様書）**です。どのプログラミング言語やフレームワークを使うかには触れず、機能が何を達成すべきか、ユーザーがどんなタスクを完了する必要があるか、成功の基準は何かだけに焦点を当てます。

従来の開発フローと比較すると、スペック駆動開発には根本的な違いがあります。

この「段階的な精緻化」のプロセスこそが、スペック駆動開発の真髄です。一足飛びにコードに到達するのではなく、複数のステージを通じて要件を段階的に明確化していきます。各ステージでレビューと調整が可能です。

Speckit ワークフロー概要

GitHubのSpec KitとClaude Codeのspeckitコマンドは、どちらも同様のワークフローに従っており、大まかに6つのステージに分けられます。

Constitution → Specify → Clarify → Plan → Tasks → Implement
     ↓            ↓          ↓        ↓       ↓         ↓
 プロジェクト   機能スペック   曖昧さの    技術計画   タスク分解   実行・実装
   憲法                     解消

1. Constitution（プロジェクト憲法）

プロジェクト憲法は、プロジェクト全体の基本原則と制約を定義します。例えば「テストファースト」「シンプル至上」「APIファースト」などです。これらの原則は後続のすべてのステージに適用され、AIが生成するソリューションが技術的な好みに合致することを保証します。

2. Specify（機能スペック）

これが最も重要な最初のステップです。自然言語で望む機能を記述すると、AIがそれを構造化されたスペックドキュメントに整理してくれます。内容は以下を含みます。

• ユーザーストーリー：誰が何をしたいのか、なぜか
• 機能要件：システムが備えるべき能力
• 成功基準：機能が基準を満たしているかをどう判断するか

重要なのは、スペックドキュメントは**「何を作るか」にのみ焦点を当て、「どう作るか」には触れない**ことです。具体的な技術スタックやコード構造は含みません。

3. Clarify（曖昧さの解消）

AIがスペック内の曖昧な点をチェックし、最大5つの重要な質問を投げかけます。これらの質問は通常、機能の境界、ユーザータイプ、セキュリティ要件などに関するものです。この質疑応答を通じて、スペックはより明確になります。

4. Plan（技術計画）

明確なスペックが揃って初めて、技術的なアプローチの検討に入ります。このステップでは以下が成果物として生まれます。

• 技術選定（言語、フレームワーク、データベース）
• データモデル設計
• APIコントラクト定義
• リサーチレポート（技術的な判断の解決）

5. Tasks（タスク分解）

技術計画を実行可能なタスクリストに分解します。各タスクには明確なID、説明、ファイルパスがあり、AIに直接渡して実行させることができます。タスクはユーザーストーリーごとにグループ化され、並行開発に対応しています。

6. Implement（実行）

タスクリストに従って一つずつ実行していきます。各タスクの完了時にマークをつけ、トレーサビリティを確保します。

これら6つのステージの成果物は、明確なチェーンを形成します。

なぜこのアプローチが有効なのか

スペック駆動開発が「AIに直接コードを書かせる」方法で失敗する場面で成功するのは、AIプログラミングの根本的な矛盾である情報の非対称性を解決するからです。

「写真共有機能を追加して」と言ったとき、あなたの頭の中には完全なイメージがあるかもしれませんが、AIにはその数文字しか見えません。AIは推測するしかありません。どこに共有するのか？誰が見られるのか？圧縮は必要か？ウォーターマークは？一括処理は対応するのか？……一つ一つの推測が間違っている可能性があります。

スペック駆動開発は、「まず考え抜くことを強制する」ことでこの問題を解決します。ユーザーストーリー、機能要件、成功基準を書き出すことを求められると、「当たり前」だと思っていた詳細が浮かび上がってきます。このプロセス自体に価値があります。AIを使わなくても、要件を明確に書き出すだけでコミュニケーションコストを削減できるのです。

さらに、段階的な精緻化により、エラーがより早く表面化します。Specifyステージで要件のズレを発見すれば、修正コストはほぼゼロです。コードを書き終わってから発見すると、やり直しになるかもしれません。

もちろん、スペック駆動開発は万能ではありません。明確な適用場面があります。

適している場合：

• 複雑な機能開発（複数のモジュールやインタラクションが関わる）
• チーム開発プロジェクト（スペックドキュメントがコミュニケーションの媒体になる）
• 品質要件が高い場面（トレーサビリティと検証可能性が求められる）

適していない場合：

• 単純なバグ修正や軽微な変更
• 探索的プログラミング（何を作るかまだ決まっていない）
• 時間が極度に限られている場合（スペックを書く余裕がない）

重要なのは、タスクの複雑さを見極めることです。1時間で完了できるものに1時間かけてスペックを書く必要はありません。しかし、1週間かかる機能開発であれば、2時間かけてスペックを書く価値は十分にあります。

ただし、スペックは銀の弾丸ではない

よくある誤解を一つ明確にしておきます。スペック駆動開発は推測を減らしますが、レビューの必要性をなくすわけではありません。

完全なスペックがあっても、AIは以下のような問題を起こす可能性があります。

• エッジケースの見落とし（スペックがカバーしていない極端なシナリオ）
• パフォーマンス要件を満たさないコードの生成
• 潜在的なセキュリティ脆弱性の混入
• スタイルが一貫しない実装の生成

これは建築と同じです。詳細な設計図があっても、検査は必要です。施工チームが設計図通りに家を建て終えたからといって、そのまま引っ越したりはしないでしょう。配線が安全か、配管が正常に機能しているか、ドアや窓がしっかりしているかを確認するはずです。

スペック駆動開発の価値は、エラーを発見しやすくすることにあります。エラーそのものをなくすことではありません。

まとめ

スペック駆動開発の核心はシンプルな真理です。タスクが複雑であればあるほど、着手する前にしっかり考え抜く必要がある。AIプログラミングツールはこの真理の重要性を増幅させます。なぜなら、AIはあなたの指示を忠実に実行しますが、あなたの意図を本当に理解することはできないからです。

3つのキーワードを覚えておきましょう。

理念を理解したところで、次の記事『Speckit 実践ガイド』では、実際に手を動かしていきます。speckitコマンドを使って、一つの機能のスペック駆動開発フローを完成させる方法を紹介します。

『Claude Skills』と組み合わせることで、スペックの実行をさらに自動化・標準化することができます。