1. はじめに
こんにちは！株式会社iimonでエンジニアをしている「みよちゃん」です！
いや〜来てますねAIの波。開発現場でもAIは「あると便利なもの」から「ないと困るもの」に変化しつつありますよね。この記事もAIに添削してもらいながら執筆しています。
弊社でも、AIを活用するための試行錯誤を日々行なっています。全エンジニアにClaude CodeのMax Planを配布しており、日々活用法を共有し、開発効率の向上を目指しています！
AIを使った開発手法が主流になる中、最近注目を集めているのがSpec-Driven Development(仕様駆動開発 / SDD)という手法です。
私は、最近新しいプロジェクトにジョインしており、そこでは弊社初の「AI駆動開発」に取り組んでいるのですが、このSDDの導入を検討することになりました。
そんな流れで、SDDに用いる代表的な2つのツール「Spec Kit」と「cc-sdd」を試してみたので、これらのツールの特徴と使ってみた感想についてお話しできればと思います！
2. そもそもSDDとは
SDD(Spec-Driven Development / 仕様駆動開発)とは、コードを書き始める前に、まず仕様を明確に定義し、その仕様を起点に開発を進める手法です。
従来の開発では「とりあえず動くものを作ってから仕様を固める」というアプローチも珍しくありませんでしたが、SDDではその逆を行います。
SDDの基本的な流れは以下のとおりです:
- 仕様の定義 - 何を作るのか、なぜ作るのかを明文化する
- 仕様の詳細化 - AIと対話しながら曖昧な部分を潰していく
- 技術設計 - 仕様をもとに、どう作るかを設計する
- タスク分解 - 設計をもとに、実装タスクに分解する
- 実装 - タスクに沿ってコードを書く
AIを活用した開発では、コンテキストが曖昧なまま実装を任せると意図しないコードが生成されがちです。SDDでは仕様という「共通言語」を先に整えることで、AIに正確な指示を出せるようになり、手戻りを減らすことができます。
では、このSDDを実践するための2つのツールを見ていきたいと思います！
3. Spec Kitを使ってみた
Spec KitはGitHubが公開しているSDDツールです。仕様の定義から実装まで、9つのフェーズに分かれた体系的なワークフローが特徴です。
開発フロー
Spec Kitの開発フローは以下の9ステップで構成されています。
| # | フェーズ | コマンド | やること | 主な成果物 |
|---|---|---|---|---|
| 1 | init | /speckit.init |
プロジェクトの初期化 | プロジェクトディレクトリ、設定ファイル |
| 2 | constitution | /speckit.constitution |
プロジェクトの原則・方針を定義 | constitution.md |
| 3 | specify | /speckit.specify |
ユーザーストーリーに沿ってwhat/whyを定義(技術的なことは決めない) | spec.md |
| 4 | clarify | /speckit.clarify |
仕様の不明瞭な部分をAIと対話しながら解消 | spec.mdの更新 |
| 5 | plan | /speckit.plan |
技術スタック・ディレクトリ構成などの技術設計 | plan.md, research.md, data-model.md |
| 6 | analyze | /speckit.analyze |
仕様・設計の一貫性チェック | 分析レポート |
| 7 | tasks | /speckit.tasks |
実装タスクの生成・整理 | tasks.md |
| 8 | checklist | /speckit.checklist |
QA用チェックリストの生成 | checklist.md |
| 9 | implement | /speckit.implement |
タスクに沿ってAIが実装 | 実装コード |
特徴的なのは constitution(原則定義) と clarify(仕様の明確化) のフェーズです。
constitutionでは「シンプルさ優先」「テスタビリティ重視」といったプロジェクト全体の方針を最初に宣言します。この原則はanalyzeフェーズで一貫性チェックの基準としても使われるため、開発全体を通して方針がブレにくい仕組みになっています。
clarifyでは、Spec Kitが仕様の中から不明瞭な箇所を自動で検出し、選択肢付きの質問を提示してくれます。
Question 1: カテゴリ削除時のタスクの扱い Context: FR-014でカテゴリの削除が可能とされていますが、 そのカテゴリに属するタスクがある場合の動作が定義されていません。 What we need to know: カテゴリを削除した際、そのカテゴリに属するタスクはどうなりますか？ Recommended: Option A - 「未分類」に自動移動することで、 タスクデータの損失を防ぎ、ユーザーの操作ミスによるデータ消失リスクを排除できます。 | Option | Description | | ------ | -------------------------------------------- | | A | 「未分類」カテゴリに自動的に移動する | | B | タスクも一緒に削除する（確認ダイアログあり） | | C | タスクが存在する場合はカテゴリ削除を禁止する |
このように、実装に入る前に仕様の穴を潰せるのでとても安心感がありますね！
感想
- 最初にAIと仕様を明確にするフェーズがあるため、要件の漏れが少ない
- 仕様書をきっちり作るため手戻りが生まれにくい
- 個人的にドキュメントが少し読みづらい
- フェーズが9つと多く、ドキュメントの管理が煩雑になりそう
- 既存プロジェクトへの途中導入はやや工夫が必要そう
4. cc-sddを使ってみた
cc-sddは、Claude CodeやCursor、Gemini CLIなどの複数のAIコーディングエージェントに対応したSDDツールです。Spec Kitと比べるとフェーズ数が少なく、シンプルなワークフローが特徴です。日本語ドキュメントが用意されているのも嬉しいポイントです。
開発フロー
cc-sddの開発フローは以下の7ステップで構成されています。
| # | フェーズ | コマンド | やること | 主な成果物 |
|---|---|---|---|---|
| 1 | steering | /kiro:steering |
プロジェクトの既存コンテキストを読み込む | ステアリングドキュメント |
| 2 | spec-init | /kiro:spec-init |
プロジェクトの要件を伝え、仕様の初期化 | spec.json, requirements.md |
| 3 | spec-requirements | /kiro:spec-requirements |
AIと要件を詰めて仕様を充実させる | requirements.mdの更新 |
| 4 | spec-design | /kiro:spec-design |
requirementsを元に技術設計を作成 | design.md |
| 5 | spec-tasks | /kiro:spec-tasks |
requirements・designを元にタスクを生成 | tasks.md |
| 6 | spec-impl | /kiro:spec-impl |
タスクに沿ってTDDで実装 | 実装コード |
| 7 | spec-status | /kiro:spec-status |
機能ごとの進捗状況を確認 | - |
この工程は機能単位で繰り返していきます。spec-initを実行するたびに.kiro/specs/配下に機能ごとのディレクトリが作成されるため、機能が増えるとドキュメントのディレクトリも増えていく構造です。
Spec Kitとの大きな違いは、1ステップずつコマンドで指示して進めるスタイルであることです。各フェーズでインタラクティブな承認確認が入るため、AIが勝手に進みすぎることがなく、開発者がコントロールを保ちやすくなっています。
また、生成されるtasks.mdが非常にわかりやすいのも特徴です。各タスクがどのRequirementsに対応しているかが明記されており、末尾には機能とタスクの対応表もまとまっています。タスクごとにコンテキストをクリアできるため、チーム開発で複数人がタスクを分担する場面にも向いていそうです。
感想
- 日本語ドキュメントがあるのがありがたい
- Spec Kitと比較するとドキュメントがかなり読みやすい
- タスクごとにコンテキストをクリアできるので、チーム開発に向いていそう
- 1ステップずつコマンドで進めるため、SDDに慣れていなくても拒否感なく進められる
- フェーズがシンプルな分、Spec Kitのconstitutionやanalyzeのような品質チェックの仕組みは自分で補う必要がある
5. 両者の比較
ここまでの内容と公式ドキュメントの情報をもとに、両ツールを比較してみます！
基本情報
| Spec Kit | cc-sdd | |
|---|---|---|
| 開発元 | GitHub | gotalab |
| フェーズ数 | 9 | 7 |
| 日本語ドキュメント | なし | あり |
| 対応AIエージェント | 指定なし | Claude Code, Cursor, Gemini CLI, Qwen Code |
| 仕様の保存先 | specs/ |
.kiro/specs/ |
フロー比較
| SDDの工程 | Spec Kit | cc-sdd |
|---|---|---|
| プロジェクト方針の定義 | constitution | - |
| 仕様の定義 | specify | spec-init |
| 仕様の詳細化 | clarify | spec-requirements |
| 技術設計 | plan | spec-design |
| 一貫性チェック | analyze | - |
| タスク生成 | tasks | spec-tasks |
| QAチェック | checklist | - |
| 実装 | implement | spec-impl |
| 進捗確認 | - | spec-status |
Spec Kitはconstitution / clarify / analyze / checklistといった品質を担保するフェーズが充実しています。一方、cc-sddはspec-statusによる進捗管理や、タスクごとのコンテキストクリアなど、チーム運用を意識した機能が特徴的です。
どちらが向いている？
Spec Kitが向いているケース:
- 仕様の品質を徹底的に高めたい場合
- プロジェクトの原則や方針を明文化して、一貫性を保ちたい場合
- 新規プロジェクトを一から始める場合
- チームと内で「AI駆動開発」が成熟している場合
cc-sddが向いているケース:
- SDDを初めて導入する場合(ステップバイステップで進めやすい)
- チームで複数人がタスクを分担して進める場合
- 日本語のドキュメントで進めたい場合
- 既存プロジェクトに段階的に取り入れたい場合
6. まとめ
「Spec Kit」「cc-sdd」どちらのツールも使い込んだわけではないので、あくまでも使ってみた感想止まりですが、それぞれの特徴をなんとなく感じることができました。
SDDは実装の流れとしては、ウォーターフォールに近い(先に仕様をガッツリ定める)ですが、AIを使用して機能ごとに高速でサイクルを回すため、ウォーターフォールの欠点とされていた「後戻りコスト」問題がうまく解消されているように思いました！
両ツールを比較してきましたが、自分が最も驚いたことは、これらのツールはどちらもそのほとんどがmdファイルで構成されていることでした。仕様書(mdファイル)を作るためのコマンドや指示書までもがmdファイルで構成されている。従来では考えられなかったなぁという感想を抱きました。
使い古された言い回しですが、時代の変化とともに我々エンジニアに求められることは変わっていくんだなぁと思う日々でございます。
「時代に取り残されない」かつ「可能であれば早めに流れに乗る」という視点において、今回の調査は大変有意義であったなーと思いました！
最後まで読んでいただきありがとうございます！
本記事には個人的な解釈も含まれています。記事の内容に誤りがありましたら、ご指摘いただけると幸いです。
また、弊社ではエンジニアを募集しております。
ご興味がありましたらカジュアル面談も可能ですので、下記リンクより是非ご応募ください！
iimon採用サイト / Wantedly
