こんにちは、Algomatic AXの大塚（@ootsuka_techs）です。
本記事では、いま話題の仕様駆動開発（Spec Driven Development; SDD）を調べ、社内で試した学びをまとめます。
今回は以下の4つのツールを使用し、それぞれの特徴や使い勝手を詳しく検証しました。
比較した結果は以下の通りです。
機能比較表
| 機能 | Kiro | Spec Kit | spec-workflow-mcp | cc-sdd |
|---|---|---|---|---|
| 日本語対応 | △ | △ | ○ | ◎ |
| 承認フロー | ○ | ○ | ◎ | ○ |
| プロジェクトガバナンス | ○ | ◎ | ○ | ○ |
| IDE統合 | ○（専用IDE） | ○ | ○ | ○ |
| オープンソース | × | ○ | ○ | ◎ |
| エンタープライズ対応 | ◎ | ○ | ○ | ○ |
| 学習コスト | △ | ◎ | ○ | ◎ |
| カスタマイズ性 | △ | ○ | ○ | ◎ |
以降は仕様駆動開発（Spec Driven Development; SDD）とそのツールについて実際にご紹介します。
Spec Driven Developmentとは？
ソフトウェア開発の世界では、アジャイル開発、テスト駆動開発（TDD）、振る舞い駆動開発（BDD）など、数多くの開発手法が提案されてきました。
その中で近年注目を集めているのが Spec-Driven Development（SDD／仕様駆動開発）です。
名前の通り「仕様（specification）」を中心に据え、設計・実装・テスト・ドキュメントすべてを仕様から逆算して進めていくスタイルです。
従来の開発では実装が先行して仕様が後付けになることも多かったのですが、SDDでは仕様を最初に固め、そこから一貫性を持って開発を進めていきます。
今回は、この仕様駆動開発を実践するための4つのツールを使い比べ、それぞれの強みと課題を探ってみました。
1. AWS Kiro – エンタープライズ向けの本格的なSDD環境
Kiroの概要と設計思想
最近、「Vibe Coding」と呼ばれるスタイルが話題になっています。
これは、AIを使って対話形式でコードを書いたりアイデアを形にする方法で、自由でスピーディーな開発が可能になります。
しかしその一方で、生成されたコードの「何を前提にしているか」が曖昧になったり、保守性や品質に不安が残るという声もあります。
そんな中で登場したのが、Amazonの「Kiro」というAI統合開発環境（IDE）です。
これはVibe Codingの手軽さに加えて、仕様をしっかり定めてから設計し、その上でタスクを洗い出していくという「仕様駆動開発（Spec-Driven Development）」を前面に押し出しています。
曖昧さを排除してチーム開発や大規模開発でも整合性を保てるよう設計されているのが特徴です。
Kiroのワークフローと3つのステップ
Kiroの基本的なワークフローについて説明すると、3つのステップで構成されています。
-
要求定義（requirements.md）
まず「誰が」「何を」「なぜ」求めているのかを明確にします。
ステークホルダーの期待値を言語化し、機能要件と非機能要件を整理します。 -
設計（design.md）
アーキテクチャ構成やモジュール設計、データモデルなど、どう設計するかをAIと共に設計していきます。
技術選定の根拠も含めて文書化されます。 -
タスク化（tasks.md）
設計した内容を実装可能な細かいタスクに分解し、進捗を管理できる形にします。
各タスクには優先度や依存関係も含まれます。
Agent HooksとAgent Steering
技術面では、Kiroには「Agent Hooks」という機能があり、ファイルの保存などのイベントをきっかけにテスト実行やドキュメント更新など定型的な作業を自動化できるようになっています。
例えば、コードを保存するたびに自動でユニットテストが走り、カバレッジレポートが更新される、といった仕組みを簡単に構築できます。
さらに「Agent Steering」という仕組みで、プロジェクト全体の方針（コーディング規約、使用技術、設計原則など）をあらかじめ指示ファイルで定義し、AIにその指示を守らせることができます。
これにより、生成されるコードの一貫性が保たれやすくなり、チーム開発において特に重要な「コードの統一性」が実現されます。
実際に使ってみた印象では、このAgent Steeringの効果は想像以上でした。特にチーム開発において、AIが生成するコードの品質や一貫性を保つ仕組みとして非常に有効だと感じました。
Kiroの課題と注意点
技術的な制約としては、プレビュー版であるため動作の遅さや未完成な部分、データプライバシーの懸念などが指摘されています。
日本語対応が不十分なため、英語以外で使用した場合に意図しない挙動をする可能性があります。
また、AWS環境への依存度が高いため、他のクラウドプロバイダーやオンプレミス環境での利用には制約があります。
「Kiro」は、AIによるコード生成だけでなく、仕様→設計→実装という流れをきちんと踏むことで開発の透明性・保守性を高めようというコンセプトを感じました。
特にチーム開発や企業での利用を想定した場合、ドキュメントによって仕様の統一性が高まり、その結果としてチーム開発のスピード向上につながると感じました。
2. GitHub Spec Kit – シンプルで直感的なSDDツール
Spec Kitの基本コンセプト
Spec Kitは、仕様を中心にしてソフトウェアを作る新しい開発スタイルを支援するツールです。
GitHubが提供するこのツールの最大の特徴は、そのシンプルさと直感的な操作性にあります。
従来のやり方ではコードを書いて初めて成果が見えるものでしたが、この仕組みでは「仕様そのものが動き、コードを生み出す」ことができます。
開発者は「何を、なぜ作るのか」に集中でき、実装の詳細は後から仕様に沿って補われていきます。
実践的な使い方とコマンド体系
実際の操作はシンプルです。
プロジェクトの初期化には specify init を使います。
AIアシスタントの指定や、PowerShell版かbash/zsh版スクリプトの選択ができます。
カレントディレクトリに作りたい場合は --here 、Git初期化を省略したい場合は --no-git を使用します。
次に仕様を記述します。/specify コマンドで「どんなアプリを作りたいか」を言葉で表現します。
このとき大切なのは「どんな技術を使うか」ではなく「どういう機能を持たせたいか」という意図です。
例えば「ユーザーがタスクを管理できるWebアプリケーション」といった高レベルの要求から始めることができます。
技術計画とタスク分解
仕様をもとに、/plan コマンドで技術的な計画を立てます。
例えば「Viteを使ってできるだけライブラリを減らし、HTML・CSS・JavaScriptでシンプルに実装する」などと記述します。
この段階で、フレームワークの選定やアーキテクチャの概要が決まります。
Spec Kitの優れた点は、技術選定の理由も含めて文書化される点で、後から「なぜこの技術を選んだのか」を振り返ることができます。
そして実際の開発を進める段階になると、/tasks コマンドを使って仕様を細かなタスクに分解します。
これにより「まずデータベースを準備する」「次にUIを整える」といった具体的な進め方が見えてきます。
各タスクには見積もり時間や依存関係も設定でき、プロジェクト管理ツールとの連携も容易です。
環境チェックと依存関係管理
環境に必要な依存関係が揃っているかを確認したい場合は、specify check でツールの有無をチェックできます。
Node.jsのバージョンやnpmパッケージの存在確認、必要な環境変数の設定状況などを自動的に検証し、不足している要素があれば具体的な対処法を提示してくれます。
仕様の定義からタスク分解までを一貫して行うことで、アイデアを素早く実際のアプリケーションに変換できることがわかりました。
Claude Code等と組み合わせることでコードの解釈や生成もスムーズになり、試行錯誤を繰り返しながら仕様を磨き上げることが可能になります。
constitutionコマンドによるプロジェクトガバナンス
Spec Kitの特に注目すべき機能として、/constitutionコマンドがあります。
これは、プロジェクトの根本的な仕様や開発ガイドラインを作成・更新するための機能で、開発チーム全体が共有すべき「プロジェクトのルール」を明文化できます。
この機能の優れた点は、単なる文書管理にとどまらず、以下のような高度な機能を提供していることです：
- セマンティックバージョニング対応：ルールの更新にMAJOR/MINOR/PATCHのバージョン管理を導入
- 包括的な検証プロセス：曖昧な表現の排除、日付の統一、宣言的な記述の確保
- 依存関係の自動同期：ルールを更新すると関連テンプレートやドキュメントが自動同期
- 同期影響レポート：変更による影響範囲を明確に把握可能
実際に使ってみると、この機能によってプロジェクトの「なぜそう決めたのか」という根拠を体系的に管理できるようになりました。
特にチーム開発において、新しいメンバーが参加した際の学習教材や、技術選定の記録として非常に有効です。
Spec Kitは、ゼロからの開発、既存システムの改善など、さまざまな場面で活用できる柔軟な開発ツールです。
constitutionコマンドのような機能により、単なる仕様管理ツールから「プロジェクトのガバナンス」まで含めた包括的な開発支援ツールとなっています。
個人的な印象としては、特にスタートアップや小規模チームでの利用に適しており、素早いプロトタイピングと仕様の可視化を同時に実現できる点が魅力的だと感じました。
3. spec-workflow-mcp – 堅牢な承認フローを持つSDDフレームワーク
実際に使ってみた第一印象
最初に感じたのは「流れがしっかりしている」ということでした。
spec-workflow-mcpは、Model Context Protocol（MCP）を活用したSDDツールで、各フェーズで明確な承認プロセスが組み込まれているのが特徴です。
プロジェクトを始めると、まず requirements.md が生成されて「どんな機能が必要か」「非機能要件は何か」といった要件定義が文章化されます。
AIが細かく拾ってくれるため、ざっくりした指示がきちんとした要件リストになります。
例えば「ToDoアプリを作りたい」という簡単な要求から、「タスクの優先度設定」「カテゴリ分類」「期限管理」「検索機能」といった詳細な機能要件を自動的に導き出してくれます。
段階的な承認プロセス
次のステップでは設計に進みます。design.md が用意されて、アーキテクチャやデータ構造が文章化され、それをブラウザのダッシュボード上で確認・承認できます。
ここで承認ボタンを押すと次の段階に進む仕掛けになっていて、自分が「OK」を出さない限り勝手に進まないのは安心感がありました。
この承認プロセスは単なるゲートではなく、各段階での品質を保証する仕組みとして機能します。
要件定義の段階で不明瞭な部分があれば、AIが質問を投げかけてきて、より詳細な仕様を固めていきます。
設計段階では、技術的な実現可能性やパフォーマンスへの影響なども考慮され、必要に応じて代替案が提示されることもあります。
タスク分解と実装の自動化
設計を通過すると tasks.md が出てきて、実装用のタスクに分解されます。
実際にToDoアプリを作らせてみると、単純な追加や削除だけでなく、検索やフィルタリングまで盛り込まれていて、設計通りに動くものができました。
各タスクには以下のような情報が含まれます：
- タスクの概要と目的
- 実装の詳細手順
- 必要な依存関係
- 推定作業時間
- テストケースの概要
- 完了条件（Definition of Done）
ダッシュボードによる可視化
特に良いと感じたのは「要件 → 設計 → 実装」の流れが視覚的にも管理できる点です。
ダッシュボードで進捗を眺めながらAIとやりとりできるのは、まさに”仕様駆動”という感じでした。
プロジェクトの全体像が一目で把握でき、どの段階で問題が発生しているか、どこがボトルネックになっているかも即座に確認できます。
ダッシュボードでは以下の情報が表示されます：
- プロジェクトの進捗率
- 各フェーズの承認状態
- タスクの完了状況
- 生成されたドキュメントへのリンク
- AIとの対話履歴
spec-workflow-mcpの課題
一方で、Cursorとブラウザを行き来する必要があるのは面倒で、文書量が増えてくると管理が大変になりそうです。
また、MCPサーバーのセットアップが必要なため、初期設定に多少の技術的知識が求められる点も、初心者にはハードルが高いかもしれません。
しかし、これらの課題を差し引いても、spec-workflow-mcpの提供する「確実性」と「透明性」は、特にミッションクリティカルなシステムの開発において大きな価値があると感じました。
4. cc-sdd – 日本発のオープンソースSDDツール
国産ツールならではの強み
cc-sddは、日本人エンジニアが開発したオープンソースの「仕様駆動開発（Spec-Driven Development）」ツールです。
AmazonのKiroに近い思想を持ち、「要件 → 設計 → タスク → 実装」という流れをIDE上で、AIと一緒に進められるようになっています。
日本の開発現場の実情を踏まえた設計になっているのが特徴です。
日本語での仕様記述が自然にできることはもちろん、日本企業でよく使われる開発プロセスや文書フォーマットにも対応しています。
簡単な導入と使いやすいインターフェース
導入は簡単で、プロジェクトにスラッシュコマンド群を追加すると /kiro:spec-init などを実行できるようになります。
これにより最初に要件定義ファイルが生成され、承認すると設計に進み、さらに承認するとタスク分解が行われて実装へ進むというワークフローになります。
cc-sddの技術的な優れた点は、既存の開発環境にスムーズに統合できることです。
以下のような環境で動作確認されています：
- Claude Code
- Cursor
- Gemini CLI
- VS Code（拡張機能経由）
- JetBrains系IDE（プラグイン経由）
Project Memoryによる文脈の保持
興味深い機能として「Project Memory（ステアリング）」と呼ばれる仕組みがあり、プロジェクト固有の文脈やコーディングパターン、スタイルをAIに覚えさせることができます。
これによって繰り返し仕様を伝え直さなくても一貫性のあるコードを得られる点は、KiroのAgent Steeringに相当する機能です。
Project Memoryには以下のような情報を保存できます：
- プロジェクトの背景と目的
- チームのコーディング規約
- 使用するライブラリとそのバージョン
- ドメイン固有の用語集
- 過去の設計決定とその理由
- よく使うコードパターンやテンプレート
多言語対応と柔軟な設定
さらに、日本語を含む多言語に対応していることや、OSを自動判別してくれること、Kiro IDEとの互換性があることなど、実際の現場で使いやすい工夫が随所に盛り込まれています。
特に注目すべき機能は以下の通りです：
自動翻訳機能
英語で書かれた仕様を日本語に、日本語で書かれた仕様を英語に自動翻訳する機能があり、国際的なチーム開発にも対応できます。
テンプレート機能
よく使う仕様パターンをテンプレート化でき、似たようなプロジェクトを素早く立ち上げることができます。
バージョン管理との統合
Gitと深く統合されており、仕様の変更履歴を自動的にコミットメッセージに反映させることができます。
cc-sddの実践的な活用
個人の小さな開発からチームでの利用まで幅広く対応でき、仕様を中心に据えた開発スタイルを自分の手元の環境でも再現できるのが魅力です。
実際に使ってみると、以下のような場面で特に効果を発揮しました：
-
レガシーコードのリファクタリング
既存のコードから仕様を逆生成し、改善点を洗い出す -
新規機能の追加
既存の仕様に新しい要件を追加し、影響範囲を自動分析 -
ドキュメントの自動生成
仕様からAPIドキュメントやユーザーマニュアルを生成
cc-sddは、Kiroのような仕様駆動開発の体験をオープンソースで再現しつつ、日本語環境にも対応した「国産のSpec-Driven Development実装」だと言えます。
各ツールの比較と使い分け
機能比較表
| 機能 | Kiro | Spec Kit | spec-workflow-mcp | cc-sdd |
|---|---|---|---|---|
| 日本語対応 | △ | △ | ○ | ◎ |
| 承認フロー | ○ | ○ | ◎ | ○ |
| プロジェクトガバナンス | ○ | ◎ | ○ | ○ |
| IDE統合 | ○（専用IDE） | ○ | ○ | ○ |
| オープンソース | × | ○ | ○ | ◎ |
| エンタープライズ対応 | ◎ | ○ | ○ | ○ |
| 学習コスト | △ | ◎ | ○ | ◎ |
| カスタマイズ性 | △ | ○ | ○ | ◎ |
各ツールの適用シーン
使用体験を踏まえて、各ツールが適している場面をまとめると以下のようになります。
適用シーン比較表
| 適用シーン | Kiro | Spec Kit | spec-workflow-mcp | cc-sdd |
|---|---|---|---|---|
| 大規模エンタープライズ開発 | ◎ | △ | ○ | ○ |
| 小規模チーム・スタートアップ | △ | ◎ | ○ | ◎ |
| AWS環境での開発 | ◎ | ○ | ○ | ○ |
| 厳格な品質管理 | ◎ | ○ | ◎ | ○ |
| 承認プロセス重視 | ○ | ○ | ◎ | ○ |
| 素早いプロトタイピング | △ | ◎ | ○ | ○ |
| 日本語での開発 | △ | △ | ○ | ◎ |
| GitHub中心のフロー | ○ | ◎ | ○ | ○ |
| 既存環境との統合 | △ | ○ | ○ | ◎ |
| オープンソース重視 | × | ○ | ○ | ◎ |
| カスタマイズ性 | △ | ○ | ○ | ◎ |
| 複数ステークホルダー | ○ | △ | ◎ | ○ |
まとめ – SDDがもたらす開発の未来
全体を通して、SDDは仕様を中心に据えることで設計から実装、テスト、ドキュメントまでを一体的に進められることがわかりました。
今回紹介したツールはそれぞれに違った強みがあり、Kiroの自律性と堅牢性、Spec Kitのシンプルさと直感性、spec-workflow-mcpの承認フローによる品質保証、そしてcc-sddの日本語対応と柔軟性が特に印象に残りました。
実際に試してみると、仕様から逆算する開発には以下のような明確な価値があることがわかりました：
-
コミュニケーションコストの削減
仕様が明文化され、全員が同じドキュメントを参照することで、認識の齟齬が大幅に減少します。
特に、AIとの対話を通じて仕様を洗練させていく過程で、曖昧さが自然に排除されていきます。 -
品質の早期確保
要件定義の段階から品質を意識することで、後工程での手戻りが減少します。
設計段階でのレビューも仕様に基づいて行われるため、より建設的な議論が可能になります。 -
ドキュメントの自動生成と保守
仕様からドキュメントが自動生成されるため、「コードとドキュメントの乖離」という古典的な問題が解決されます。
また、仕様を更新すれば自動的にドキュメントも更新される仕組みは、長期的な保守性を大きく向上させます。 -
AIとの効果的な協業
SDDツールを使うことで、AIの能力を最大限に活用できます。
仕様という明確な指針があることで、AIが生成するコードの品質と一貫性が保たれ、人間とAIの役割分担も明確になります。
一方で、SDDは開発の未来を変える可能性を秘めていますが、いくつかの課題も見えてきました：
ツールの成熟度
まだ多くのツールが開発初期段階にあり、安定性や機能の充実度には改善の余地があります。
特に、既存の開発プロセスとの統合や、レガシーシステムへの適用には工夫が必要です。
組織文化の変革
SDDを効果的に活用するには、「まず仕様を固める」という文化の醸成が必要です。
アジャイル開発に慣れたチームにとっては、この転換は容易ではないかもしれません。
AIへの過度な依存
AIが仕様から自動的にコードを生成してくれる便利さの反面、開発者の実装スキルが衰退する懸念もあります。
バランスの取れた活用方法を模索する必要があります。
結論として、仕様駆動開発は単なる新しい開発手法ではなく、ソフトウェア開発の本質的な課題に対する一つの解答だと感じました。
「何を作るか」を明確にしてから「どう作るか」を考えるという、一見当たり前のプロセスを、最新のAI技術と組み合わせることで実現可能にしています。
今回紹介した4つのツールは、それぞれ異なるアプローチでSDDを実現していますが、共通しているのは「仕様の重要性」への認識です。
最後にAlgomaticは一緒に働くメンバーを募集しています！
以下よりカジュアル面談お待ちしています！
