はじめに
仕様書駆動開発（Spec-Driven Development） は、コードを書く前に仕様を明確にし、AIと人間が「何を作るか」を合意してから実装に入るアプローチです。
仕様書駆動開発のメリット
1. 作る前に認識のズレがわかる
どのツールもspec（仕様）系ファイルとtasks（タスク）系ファイルを生成します。実装に入る前にこれらをレビューすることで、「思ってたのと違う」を防げます。
| ツール | spec（仕様）系ファイル | tasks（タスク）系ファイル |
|---|---|---|
| OpenSpec | spec.md |
tasks.md |
| spec-kit | spec.md |
tasks.md |
| cc-sdd |
requirements.md, design.md
|
tasks.md |
2. AIエージェントのセッション等が変わっても引き継ぎやすい
Claude Codeのセッションが変わったり、AIエージェントツールを変更しても、仕様書ファイルが残っているので、新しいセッションで「このspecとtasksを読んで続きをやって」と言えばスムーズに再開できます。
3. 人間があとから見ても状況がわかる
AIに任せた作業の進捗や内容を、ドキュメントファイルを見れば把握できます。「何をどこまでやったのか」がファイルとして残るので、チームメンバーへの共有も楽です。
今回は、Claude Codeで仕様書駆動開発を実現する3つのツールを実際に使ってみて比較しました。
| ツール | GitHub Stars | 開発元 | 特徴 |
|---|---|---|---|
| OpenSpec | 9k | Fission-AI | 既存サービス改修向け、軽量 |
| spec-kit | 53.9k | GitHub公式 | 新規開発向け、constitutionによる原則遵守 |
| cc-sdd | 1.8k | gotalab | 多言語対応、Kiroスタイル |
結論
用途や重要視点によって使い分けるのが良さそうです：
- 既存サービスの改修 → OpenSpec
- ゼロから新規開発&堅牢なチーム開発 → spec-kit
- ゼロから新規開発&ドキュメントファイルの言語一貫性 → cc-sdd
各ツールの詳細
OpenSpec
基本ワークフロー
-
/openspec:proposal— 変更提案を作成 -
/openspec:apply— 提案に基づいて実装 -
/openspec:archive— 完了した変更をアーカイブ
各ファイルの役割
| ファイル | 役割 |
|---|---|
specs/*/spec.md |
現在の仕様。変更がarchiveされるとここに反映される |
changes/*/proposal.md |
なぜ・何を変更するかの提案書 |
changes/*/tasks.md |
実装タスクのチェックリスト |
changes/*/specs/*/spec.md |
仕様の差分。ADDED/MODIFIED/REMOVEDで記述 |
changes/archive/ |
完了した変更の保管場所 |
アーカイブ機能（他ツールにない強み）
OpenSpec最大の特徴が/openspec:archiveコマンドです。実装が完了すると、変更フォルダがchanges/からchanges/archive/に移動し、差分が本体のspecs/に統合されます。
これにより「何が完了済みで、何が進行中か」がディレクトリ構造を見るだけで一目瞭然になります。spec-kitやcc-sddにはこの機能がないため、完了したタスクの管理は手動で行う必要があります。
強み
- ファイル数が最小限でシンプル
-
specs/とchanges/の分離で差分管理がしやすい - アーカイブ機能で完了/進行中が明確（他ツールにはない機能）
- 既存コード改修に最適化
気になる点
-
project.mdでプロジェクト原則を定義できるが、spec-kitのconstitutionほど全フェーズで強く参照される設計ではない
spec-kit
基本ワークフロー
-
/speckit.constitution— プロジェクト原則（憲法）を定義 -
/speckit.specify— 機能仕様を作成 -
/speckit.plan— 技術スタックと実装計画を策定 -
/speckit.tasks— タスクを分解 -
/speckit.implement— 実装を実行
各ファイルの役割
| ファイル | 役割 |
|---|---|
constitution.md |
プロジェクト全体の原則・方針。全フェーズで参照される |
spec.md |
ユーザーストーリーと機能要件 |
plan.md |
技術スタック選定と実装計画 |
tasks.md |
タスク分解（[P]マーカーで並列実行可能を明示） |
data-model.md |
データベース設計 |
research.md, quickstart.md
|
技術調査、セットアップ手順 |
tasks.mdの並列実行マーカー
spec-kitの特徴としてtasks.mdでは、並列実行可能なタスクに[P]マーカーが付きます：
- T001 [P]: プロジェクト初期化
- T002 [P]: データベーススキーマ作成
- T003: マイグレーション実行（T002に依存）
[P]が付いているタスクは同時に進められるので、チーム開発で分担しやすくなります。
中規模以上の開発チームを想定していることを感じます。
強み
- GitHub公式が開発しているので、継続的なアップデートに期待できる
- constitution（憲法） の遵守率が高い。全フェーズで参照される設計
-
[P]マーカーでチーム分担・並列開発がしやすい - ドキュメントファイルが豊富で、大人数の開発でもブレにくい
気になる点
- 生成されるファイルが多いので、なれないと認知負荷が大きい（
quickstart.mdなど、小規模開発では使わないファイルも出力される） - constitutionに「日本語で書いて」と記載しても、たまにルールを破って英語でドキュメントが出力されることがあり、手直しが地味にストレス
cc-sdd
基本ワークフロー
-
/kiro:spec-init— 仕様書を初期化 -
/kiro:spec-requirements— 要件定義を作成 -
/kiro:spec-design— 設計書を作成 -
/kiro:spec-tasks— タスクを分解 -
/kiro:spec-impl— 実装を実行
各ファイルの役割
| ファイル | 役割 |
|---|---|
requirements.md |
EARS形式の要件定義 |
design.md |
アーキテクチャ設計（Mermaid図含む） |
tasks.md |
依存関係付きの実装タスク |
steering/*.md |
プロジェクトのコンテキスト情報 |
/kiro:spec-status <feature_name>で、タスクの進捗状況を確認できます。
強み
- 12言語対応で、仕様書が意図しない言語になりにくい
-
--lang jaオプションで日本語ドキュメントが生成される。spec-kitのように「日本語で書いて」と指定しても英語になる煩わしさがない - 依存関係追跡付きで並列実行にも対応
- npxで導入が簡単
気になる点
- Kiro IDEベースなので、Kiroを使っていないのに
.kiro/ディレクトリができるのが若干違和感
比較表
| 観点 | OpenSpec | spec-kit | cc-sdd |
|---|---|---|---|
| 開発元 | Fission-AI | GitHub公式 | gotalab |
| 日本語対応 | △（英語中心） | △（英語中心） | ◎（12言語） |
| プロジェクト原則 | △ | ◎（constitution） | ○（steering） |
| 並列実行対応 | △ | ◎（[P]マーカー） | ○（依存関係追跡） |
| アーカイブ機能 | ◎ | △ | △ |
| 既存改修 | ◎ | △ | ○ |
| 生成ファイル数 | 少ない | 多い | 中程度 |
使い分けの指針
OpenSpecを選ぶとき
- 既存プロダクトの機能追加・改修がメイン
- 仕様書を必要最小限にしたい
- 完了/進行中をディレクトリで管理したい
spec-kitを選ぶとき
- 新規プロジェクトをチームで立ち上げる
- プロジェクトの原則（constitution）を定義して遵守させたい
[P]マーカーでタスクを分担したい
cc-sddを選ぶとき
- 日本語で仕様書を管理したい
- npxで手軽に試したい
まとめ
個人的な使い分け：
- 既存サービスの改修 → OpenSpec（シンプルで差分管理しやすい。アーカイブ機能で完了済みが一目瞭然。導入と学習コストも一番少ないので、初めての仕様書駆動開発におすすめ）
- ゼロから作る → cc-sdd（日本語対応しているのが良い）
-
チームで新規開発 → spec-kit（ドキュメントが豊富で大人数でもブレない。
[P]マーカーでタスク分担もしやすい。GitHub公式で今後のアップデートにも期待できる）
Discussion