🐡

AI時代の開発：Spec-Driven Development（SDD）とSpec kit

に公開
AI
sdd
zennfes2025ai
zennfes2025free
speckit
tech

Spec-Driven Development（SDD）とSpec kit

先日、GitHubからSpec Kitがリリースされましたね👀

https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

Spec駆動開発(Spec-Driven Development: SDD, 仕様駆動開発)を支援するツールですが、

  • そもそもSDDってなんだ？
  • Spec Kitとは

というテーマで書いていこうと思います。

従来のAI開発の課題："Vibe Coding"問題

これまでのAI支援開発は、開発者が「写真共有機能を追加して」のような曖昧な指示を出し、
AIが推測でコードを生成する(GitHubが「Vibe Coding」と呼ぶ)アプローチが主流だった。

この手法の問題点：

  • 要件の曖昧性: AIが数千の未定義要件を推測せざるを得ない
  • アーキテクチャの一貫性欠如: プロジェクト全体の設計方針が反映されない
  • 保守性の低さ: なぜそのコードが生まれたのか、背景がドキュメント化されない
  • 技術的負債の蓄積: プロトタイプレベルのコードが本番環境に紛れ込む

GitHub CopilotやCursorなどのツールは確かに開発生産性を向上させたが、
新たな技術的負債を生み出している面もある。

この問題を解決するアプローチとして注目されているのが
Spec-Driven Development（SDD：仕様駆動開発）　だ。

What is spec-driven development?

仕様駆動開発では、まずコードを書いて後でドキュメントを作成するのではなく、
（ご想像の通り）仕様書から始めます。
これはコードの動作を規定する契約であり、ツールやAIエージェントがコードを生成・テスト・検証する際に参照する真実の源となります。
その結果、推測作業が減り、予期せぬ事態が少なくなり、より高品質なコードが実現します。

SDDでは 「なぜそのコードが必要なのか」を先に明確化 することで、
以下の問題を解決します

1. 要件の曖昧性を排除：まず仕様で明確化
→ "ユーザーはメール/パスワードでログインし、2要素認証をオプションで設定できる"
→ 技術計画で具体化: "JWT + Redis、Google Authenticator対応"
2. 設計判断の透明性
コードを見ただけでは「なぜこの設計にしたのか」が分からない問題を、仕様書で解決。
→将来の開発者（未来の自分も含む）が、設計意図を理解できるようになる
3. AIの「幻覚」を防ぐ
コンテキストが曖昧だと間違った前提でコードを生成してしまうので、
明確な仕様があることで、AIが正しい方向性でコードを生成できるようにする。

"SDDの価値提案開発速度 × コード品質の両立"

従来は「速度を重視すると品質が下がる」トレードオフが存在したが、
SDDでは仕様の明確化により、AIが高品質なコードを高速生成することができる。
後からのリファクタリングや仕様変更コストも大幅削減できる。

「とりあえず動く」から「設計された」コードへ
将来の機能拡張や変更を考慮した構造的な実装で
ドキュメントとコードの自動同期により、腐ったドキュメント問題も解決できるようになります。

構造化された4つのフェーズ

SDDは、このようなアドホックな開発を構造化されたプロセスに変換する。
AIの「パターン認識は得意だが心読みは苦手」という特性を踏まえ、
明確な指示を段階的に提供する手法だ。

  1. Specify（仕様化）
  2. Plan（計画）
  3. Tasks（タスク分解）
  4. Implement（実装）

1. Specify（仕様化）

目的: ユーザー体験と要件の明確化

  • 「何を作るか」「なぜ作るか」に焦点
  • ユーザージャーニーと成功指標の定義
  • 技術的詳細は含めない
ex
## 仕様例：レビューシステム
### ユーザーストーリー
- ユーザーは商品にレビューを投稿できる
- ユーザーは他のユーザーのレビューを閲覧できる
- ユーザーはレビューを評価（Like/Dislike）できる

### 成功指標
- レビュー投稿完了率：90%以上
- レビュー表示応答時間：2秒以内

2. Plan（計画）

目的: 技術実装の詳細化

  • 使用技術スタック、アーキテクチャパターンの決定
  • 既存システムとの統合方針
  • セキュリティ、パフォーマンス要件の具体化
ex
## 技術計画：レビューシステム
### アーキテクチャ
- Frontend: React + TypeScript
- Backend: Node.js + Express
- Database: PostgreSQL
- API Design: RESTful

### データモデル
- User, Product, Review, ReviewRating エンティティ
- Review → Product: Many-to-One
- User → Review: One-to-Many

3. Tasks（タスク分解）

目的: 実装可能な単位への分割

  • 独立してテスト可能な小さなタスクに分解
  • 依存関係の明確化
  • 各タスクに対する受け入れ基準の定義
ex
## タスクリスト
1. Review データモデルの作成
   - PostgreSQLテーブル定義
   - TypeScriptインターフェース
   - バリデーションルール

2. レビュー投稿APIエンドポイント
   - POST /api/reviews
   - 入力検証
   - ユニットテスト

4. Implement（実装）

目的: 構造化された実装の実行

  • AIが各タスクを順次実行
  • 開発者は変更を段階的にレビュー
  • 仕様との整合性を継続的に検証

What is the spec-driven process with Spec Kit?

https://github.com/github/spec-kit

SDDを実践するためのオープンソースツールキット"Spec Kit"

Spec Kitの核となる思想は、仕様を開発プロセスの中心に据え、
AIコーディングエージェントが一貫した品質でソフトウェアを実装できる環境を提供することだ。

やってみた

README見ながらやってみました。

インストールと初期化

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>

対応AIアシスタント：現在は以下のAIツールがサポートされていました👀

copilot (GitHub Copilot)
claude (Claude Code)  
gemini (Gemini CLI)
cursor (Cursor)
qwen (Qwen Code)
opencode (opencode)
windsurf (Windsurf)

利用可能なコマンド

/constitution - プロジェクトの原則を設定
/specify - 仕様書作成  
/plan - 実装計画作成
/tasks - タスク分解
/implement - 実装実行

実際に使ってみた個人的感想

[良かった点]

  • 仕様書作成時、想定より大きく作られていないか?
    作りたいものと認識が一致してるか？当たり前だがしっかり確認して進めたら、
    その通りに実装してくれた。
  • 実装ではそこまで暴走はしないでやってくれる

[注意すべきだと思った点]

  • どんどん作り進めてしまうので、開発方針で「フェーズごとにコミット」などを明記すべき
  • 制限をしっかり上げることが重要 （これは他のAIツールでも共通）
  • 型エラーの修正と依存関係を最後に一気にという傾向は他と一緒であってそこではちゃんとみてあげないと暴走するので注意、もしくは開発原則で書くといいかも。もしくは使うエージェントにはよるが、CursorならRuleに書いてもいいし、Claude Codeでhookで解決もできそう。
/constitution
<!-- EX -->
## 開発原則
- 各フェーズ完了時には必ずコミットを作成
- 型安全性を最初から考慮した実装
- 依存関係は各タスク実装時に同時解決
- レビュー可能な単位での実装（一度に変更するファイル数制限）

\Spec Kitはあくまでサポートなので、やはり使うエージェントの理解と使いこなしが大事//

Discussion