- Spec-Driven Development: 従来の開発では補助手段だった 仕様書（Spec） を 実行可能な仕様 へと昇格させ、仕様から直接 動作する実装 を生成しようとするアプローチ
- コード中心だった慣行を転換し、まず 何を・なぜ を定義し、その後で どのように を具体化する 意図中心の開発 を強調
- 中核となるアイデアは、仕様を通じて一貫した成果物を作り、反復作業を 自動化 して、開発者が製品上の課題に集中できるよう支援すること
- Spec Kitは、このように 仕様 を 実行可能な成果物 に変換し、実装の自動化を支援するツール群
- インストール後、
/specify で 何を/なぜ を記述し、/plan で スタック/アーキテクチャ を宣言し、/tasks で 作業単位 を生成
- 目標は、組織が 差別化されない共通コード の作成から離れ、製品シナリオ に集中できるようにすることであり、仕様主導の方式を通じて品質と速度の両方を高めようとする実験的フレームワーク
中核思想: Core philosophy
- 意図中心の開発 により 何を を先に据え、どのように は後から具体化する 仕様優先 の思考法
- ガードレール と組織的な原則を備えた 豊かな仕様 を作成し、一度きりのコード生成 ではなく 多段階の精緻化 プロセスを経る
- 高度なAIモデル の解釈能力に 積極的に依存 し、仕様を実行可能な結果へ変換する活用法を志向
Spec Kitを用いた仕様主導プロセス
- Spec Kit は、仕様をエンジニアリングプロセスの中心に据え、実装、チェックリスト、作業分解を主導し、開発者は主に指示役を担う
- プロセスは 4段階 で構成され、各段階に明確なチェックポイントがあり、現在の作業が完全に検証されるまで次の段階へ進まない
- Specify段階: 高水準の説明を与えると、コーディングエージェントが詳細な仕様を生成し、これは技術スタックではなくユーザージャーニー、体験、成功指標に焦点を当てる
- ユーザーが誰なのか、どの問題を解決するのか、どのように相互作用するのか、重要な結果は何か、などをマッピング
- これはユーザー理解に応じて進化する 生きたアーティファクト の形を取る
- Plan段階: 望ましいスタック、アーキテクチャ、制約条件を与えると、コーディングエージェントが包括的な技術計画を生成
- 会社標準の技術、レガシーシステム統合、コンプライアンス、性能目標などを含む
- 複数の計画バリエーションを要求して比較でき、社内ドキュメントを与えればアーキテクチャパターンを直接統合
- Tasks段階: 仕様と計画に基づいて、コーディングエージェントが作業を小さくレビュー可能なチャンクに分解
- 各作業は独立して実装・テスト可能で、AIが作業を検証・追跡できるよう設計される
- たとえば「認証を構築する」ではなく「メール形式を検証するユーザー登録エンドポイントを作成する」のように具体的
- Implement段階: コーディングエージェントが作業を1つずつ、または並列で処理し、開発者は焦点の絞られた変更をレビュー
- 仕様が何を構築するか、計画がどう構築するか、作業が何に取り組むかを示す
- 各段階で開発者は振り返りと精緻化を行い、仕様が意図を捉えているか、計画が現実の制約を考慮しているか、欠落やエッジケースがないかを確認する 検証役 を担う
エージェンティックワークフローでのSpec Kitの使い方
- Spec Kitは GitHub Copilot, Claude Code, Gemini CLI のようなコーディングエージェントと連携し、簡単なコマンド列を通じてエージェントを指示し、アーティファクトを生成
- これにより曖昧なプロンプトを明確な意図へ変換し、信頼性高く実行する
- プロジェクト初期化後、
/specify コマンドで高水準プロンプトを与えると、コーディングエージェントがプロジェクト全体の仕様を生成し、プロジェクトの「何」と「なぜ」に焦点を当てる
/plan コマンドで高水準の技術的方向性を与えると、コーディングエージェントがアーキテクチャと制約を尊重した詳細計画を生成/tasks コマンドで仕様と計画を実行可能な作業一覧へ分解し、コーディングエージェントがそれを基にプロジェクト要件を実装
開発段階: Development phases
- 0-to-1（グリーンフィールド） 段階: 高水準の要件に基づき、仕様生成 → 計画策定 → プロダクション級アプリ 生成の流れを支援
- 創造的探索 段階: 多様なスタック/アーキテクチャ と UXパターン を 並列実装 で実験するプロセスを重視
- 漸進的改善（ブラウンフィールド） 段階: 機能追加、レガシー近代化、プロセス適応 を繰り返す 進化型開発
このアプローチがうまく機能する3つのシナリオ
- グリーンフィールド（zero-to-one）: 新規プロジェクト開始時にすぐコーディングせず、事前に仕様と計画を作成して、AIが意図どおりのものを構築するよう保証し、一般的なパターンベースの汎用解ではなく、カスタムな結果を提供
- 既存システムでの機能開発（N-to-N+1）: 複雑なコードベースに機能を追加する際、仕様によって新機能と既存システムの相互作用を明確にし、計画によってアーキテクチャ上の制約をエンコードすることで、ネイティブに感じられるコードを生成
- これにより継続的な開発をより速く、より安全にし、高度なコンテキストエンジニアリング手法が必要になる場合がある
- レガシー近代化: レガシーシステムを再構築する際に元の意図が失われている場合、Spec Kitのプロセスで必須のビジネスロジックを現代的な仕様に取り込み、新しいアーキテクチャを計画することで、AIが技術的負債なしに再構築
Prerequisites
- Linux/macOS または WindowsのWSL2 が必要
- AIエージェントとして Claude Code, GitHub Copilot, Gemini CLI, Cursor から選択
9件のコメント
Copilot Workspaceを思い出しますね。
自然言語ベースのAIプログラミングの土台になりそうですね
GitHubのSpec Kitの利点は、GitHub Copilotでも活用できます。
GitHubが作ったものなので当然？かもしれませんが、ほかのツールはClaudeベースのものが多かったですね。
Kiro IDEを思い出しますね
面白いですね。理にかなっている気もします。
記事の途中にあるSDDの詳細紹介リンクは内容が良いですね。以下はAIで要約してみたものです。
仕様駆動開発（Specification-Driven Development, SDD）
The Power Inversion
The SDD Workflow in Practice
Why SDD Matters Now
Core Principles
Implementation Approaches
Streamlining SDD with Commands
/specify: 機能説明を構造化された仕様へ変換し、自動採番、ブランチ作成、テンプレートベースのディレクトリ構成を自動化する/plan: 仕様分析 → 憲法準拠レビュー → 技術翻訳 → データモデル・API契約・テストシナリオ文書化 → クイックスタート検証を生成する/tasks:plan.mdと関連設計を読み、実行可能なタスクリストを出力し、並列可能タスクの表示と安全な並列グルーピングを提供するThe Power of Structured Automation
Template-Driven Quality
[NEEDS CLARIFICATION]マーカーで推測禁止と明示的な質問を促すimplementation-details/へ分離して可読性を維持するThe Constitutional Foundation
memory/constitution.mdの不変原則により、すべての実装を一貫・単純・高品質に保つ開発憲法を採用するThe Transformation
どのAIで整理されたのでしょうか？
GPT-5でやりました。要約用に自分で整理した、かなり長いプロンプトを使っています。
コンセプトにはとても共感したので、新規プロジェクトで週末に少し試してみたのですが、思ったほどうまくはいきませんでした。まだ多くの改善が必要そうです。ひとまず大まかな動作はこれまで何度も紹介されているとおり、次のような流れです: 仕様原則の作成 → スペック作成 → タスク作成 → 実装
問題は、
constitution.mdファイルは「どう開発するか」に関する中核ガイドですが、「このアプリが最終的に何になるのか」は含まれていませんspec.mdは1つの機能を説明する文書です/specifyと/tasaksコマンドを通じて多くの文書を成果物として生成するのですが（望んでいた結果です）、そのせいかコンテキストをすぐ消費します（Claude Codeを使用中）tasks.mdに定義された作業を進めていると、先にちゃんと作っていたものを上書きしてしまうこともありますし、バグ修正の過程で新しい機能を作ることもあって、tasks.mdからだんだん離れていきます。tasks.mdを永続保存する意味がよく分かりませんひとまず私が出した結論は次のとおりです