仕様駆動開発を AI で実践する｜cc-sdd の使い方と Kiro・GitHub Spec Kit との違い (2026 年 10 月版)

AI 駆動開発ほど「仕様」が効く理由

AI にコードを書かせる開発で最初にぶつかる壁は、コードの書けなさではなく「何を作るかが曖昧なまま実装が進む」ことです。Claude Code や Cursor は指示された範囲を高速で形にしますが、指示が曖昧なら曖昧なまま、それらしい実装を作り上げてしまいます。レビューの段階で「そもそも作るものが違った」と気づき、作り直しになります。これが AI 駆動開発でよくある手戻りの原因です。

先に結論を述べると、AI 駆動開発で品質と速度を両立させる鍵は、仕様 (spec) を一次情報として固定し、その仕様から実装・テスト・レビューを駆動すること にあります。これが本記事で扱う仕様駆動開発です。人間がコードを書いていた時代は、仕様が多少曖昧でも実装者が文脈を補って帳尻を合わせていました。ところが AI は文脈の暗黙の補完をしないか、しても勝手な前提で補ってしまいます。だからこそ、人間時代より厳密に「何を作るか」を言語化しておく価値が跳ね上がります。

AI 駆動開発そのものの全体像は AI 駆動開発とは？従来開発との違い・進め方 で解説しているので、本記事では「仕様を起点に AI へ実装を委ねる」具体的な進め方に絞って掘り下げます。後半では、この流れを Claude Code や Codex に型として入れる OSS の cc-sdd を取り上げ、Kiro・GitHub Spec Kit との違いを 2026 年 10 月 5 日時点の公式情報で比べます。

FIXIT

AI が賢くなったなら、仕様なんて省けるんじゃないの？

逆です。賢くなるほど、書いていない前提を補う幅も広がります。

Tsumiki

人なら曖昧な指示を文脈で補ってくれますが、AI は曖昧なまま形にしてくるんですよ。

FIXIT

じゃあ仕様って、誰のために書くの？

Tsumiki

AI と人間の両方が読む一次情報ですね。同じ仕様を見て実装して、レビューする前提です。

仕様駆動開発とは — vibe coding・AI 駆動 TDD との違い

仕様駆動開発 (spec driven development) は、仕様を人間と AI が共有する一次情報として扱い、その仕様から実装とテストを導く開発スタイルです。仕様は「あとで読む資料」ではなく「実装を駆動する入力」であり、変更が起きるたびに仕様を更新し、仕様・テスト・実装を常に同期させます。

近い言葉と並べると位置づけがはっきりします。

これらは排他的ではなく層になっています。仕様駆動開発が「何を作るか」を固め、AI 駆動 TDD がその仕様を「失敗するテスト」へ翻訳し、実装で Green にします。vibe coding は要件が固まる前の探索で動くものを作る局面で使い、確定したら仕様へ昇格させます。AI 駆動 TDD の具体的なループは AI 駆動 TDD — テストを AI に先に書かせる開発フロー で詳述しているので、本記事はその一段上の「仕様」を扱います。

vibe coding をそのまま本番投入したときに何が起きるかは vibe coding を本番投入する前のレビュー観点 で整理しました。探索で作ったものを仕様へ昇格させずに本番へ流すと、まさにこの記事で挙げた事故が起きます。仕様駆動はその対極で、最初に「何を作るか」を確定させてから AI に手綱を渡します。

spec を一次情報にするドキュメント設計

仕様駆動開発の成否は、仕様の書き方でほぼ決まります。重要なのは、AI が読んで実装でき、人間がレビューで参照でき、変更履歴を Git で追える形にすることです。推奨する配置は、仕様をリポジトリ内の Markdown としてコードと同じ場所に置き、機能単位のディレクトリに spec.md を置く形です。チャットや会議の口頭合意に仕様を閉じ込めないことが、最初にして最大の原則です。

仕様に書くべき要素は大きく 3 つに分かれます。

ひとつ目は要件です。この機能が解決する課題、対象ユーザー、想定する利用シーンを書きます。ここが抜けると、AI は技術的には正しいが目的に合わない実装を作りがちです。「ログイン機能を作る」ではなく「既存会員がメールアドレスとパスワードでログインでき、5 回連続で失敗したらアカウントを 15 分ロックする」まで具体化します。

ふたつ目は受け入れ条件です。仕様駆動開発で最も重要な部分で、「この条件を満たせば完成」と言える観測可能な振る舞いを箇条書きで列挙します。受け入れ条件は後でそのままテストになるため、曖昧語を避けて「〜のとき、〜になる」の形で書きます。たとえば「パスワードが 8 文字未満のとき、登録は失敗し、エラーメッセージを表示する」のように、入力・条件・期待結果が揃った文にします。

みっつ目は非機能要件と制約です。性能の目安、扱うデータの上限、使用してよいライブラリやアーキテクチャの制約、既存システムとの境界を書きます。AI は明示しなければ平気で新しい依存を増やしたり、既存の規約を無視した書き方をします。制約を仕様に書いておくと、その範囲内で実装を組み立てさせられます。

仕様は最初から完璧を目指さず、要件と受け入れ条件を骨組みとして先に置き、実装しながら判明した前提を追記していく運用が現実的です。ただし「実装が先に進んで仕様が後追いで陳腐化する」状態だけは避けます。仕様の更新を実装と同じ Pull Request に含めるルールにすると、この陳腐化を構造的に防げます。

Claude Code / Cursor に spec を読み込ませる実装フロー

仕様が整ったら、AI に実装を委ねます。基本のフローは次のとおりです。

flowchart LR
  SPEC["仕様 (spec)<br/>要件・受け入れ条件・制約<br/>(人間が確定)"]
  TEST["受け入れ条件をテスト化<br/>(AI 生成 → 人間レビュー)"]
  IMPL["実装<br/>(AI 生成 → 人間レビュー)"]
  REV["仕様との差分レビュー<br/>(人間)"]
  CI["CI: 仕様由来テスト全通過"]
  SPEC --> TEST --> IMPL --> REV --> CI
  CI -- 仕様変更あり --> SPEC

実務での進め方を順に説明します。

まず仕様をリポジトリに置き、CLAUDE.md やルールファイルから参照できるようにします。Claude Code なら CLAUDE.md に「機能の仕様は各ディレクトリの spec.md を一次情報とすること」と書いておき、Cursor なら Project Rules に同様の方針を記述します。CLAUDE.md の整え方そのものは CLAUDE.md のベストプラクティス にまとめています。

次に、実装を依頼するときの指示が肝心です。「ログイン機能を作って」ではなく「spec.md の受け入れ条件をすべて満たす実装とテストを書き、各実装が仕様のどの条件に対応するか説明して」と依頼します。仕様のどのセクションを根拠にしたかを言語化させることで、AI が仕様を読み飛ばしていないかを確認でき、仕様にない機能を勝手に足す動きも抑えられます。

仕様が長い場合は、機能単位に分割して該当ファイルだけをコンテキストに渡します。AI に「仕様全体」を一度に渡すと、関係ない箇所に引っ張られて精度が落ちます。今から実装する機能の仕様セクションに絞ると、受け入れ条件への追従が安定します。

実装と同時にテストを書かせる点も重要です。受け入れ条件は観測可能な振る舞いとして書いてあるので、それぞれをテストケースへ一対一で対応させられます。「受け入れ条件 3 に対応するテストがどれか」を AI に明示させると、条件の取りこぼしが見つけやすくなります。ここで AI 駆動 TDD のループに接続し、失敗するテストを先に書いてから実装を Green にする流れに乗せると、仕様 → テスト → 実装の鎖が一本に繋がります。

ここまでの流れは、仕様のひな形と依頼の文面をチームで揃えれば手作業でも回せます。ただ、メンバーごとに仕様の書き方や AI への依頼の仕方がばらつくと、レビューの観点も揃いません。この手順そのものをエージェントに持たせる道具として、次に cc-sdd を取り上げます。

cc-sdd とは — Kiro 互換の仕様駆動ワークフローを AI エージェントに入れる OSS

cc-sdd は、要件 → 設計 → タスク → 実装の順に AI に仕様を書かせ、人が各段階を承認してから実装へ進む仕様駆動開発の流れを、AI コーディングエージェントに入れる OSS です。README は「承認済みの仕様を、長時間の自律実装ワークフローに変える」と説明しています。入るのは、エージェントが必要なときに読み込む 17 個の Agent Skills と、仕様書のテンプレート・生成ルールです。Agent Skills の仕組みは Agent Skills とは で解説しています。

FIXIT は cc-sdd を使った実案件の記録を持っていません。以下は 2026 年 10 月 5 日に GitHub のリポジトリ・npm のページ・Releases で確認した公式の情報です。

提供元・ライセンス・最新版

企業の製品ではなく、個人が公開している OSS です。README が案内するサポートの窓口は GitHub の Issues (バグ報告と質問) で、有償のサポートの案内はありません。社内の標準にするなら、MIT ライセンスで改変と再配布が認められている点と、更新が止まったときに自分たちで保守できるかを合わせて判断してください。

v3.0.0 (2026 年 4 月) で、Agent Skills を主にした「Skills モード」、/kiro-discovery を入口にする流れ、自律実装の /kiro-impl が入りました。v3.1.0 では Devin Local / CLI への対応 (beta) が加わり、Windsurf 向けのフラグは移行用の非推奨扱いになっています。

対応エージェント

README の対応表のうち、Skills モードのフラグと安定度を抜き出すと次のとおりです。

Devin Local / CLI は、Devin Desktop の中の Devin Local と、Devin CLI を指します。Devin の製品構成は Devin とは で整理しています。

Claude Code をまだ入れていない場合は、先に Claude Code の使い方 の手順で導入しておきます。どのエージェントを主に使うかで迷っているなら、Cursor と Claude Code の違いと使い分け が判断の材料になります。

インストールとコマンドの流れ

プロジェクトのディレクトリで次を実行します。既定では、Claude Code 向けの skills と英語のテンプレートが入ります。

cd your-project
npx cc-sdd@latest                           # Claude Code 向け (既定)
npx cc-sdd@latest --lang ja                 # 仕様書を日本語で書かせる
npx cc-sdd@latest --codex-skills --lang ja  # Codex 向け、日本語
npx cc-sdd@latest --dry-run --backup        # 変更内容を先にプレビューし、バックアップも取る

npx を使うため、Node.js が入った環境が前提です。必要な Node.js のバージョンは、README と package.json のどちらにも書かれていません。

インストール後は、エージェントのチャットで skills を呼び出します。README の「よくあるワークフロー」を、Claude Code での呼び出し方で並べると次のとおりです。呼び出し方は、エージェントと設定によって変わります。

どこから始めるか迷ったら、/kiro-discovery <やりたいこと> を実行します。依頼を「既存の仕様を広げる」「仕様なしで直接実装する」「新しい仕様を 1 つ作る」「複数の仕様に分ける」などに振り分け、次に実行するコマンドを示してくれます。/kiro-impl は、subagent を使えるエージェントでは、タスクごとに新しい実装役がテストを先に書いてから実装し (RED → GREEN)、別のレビュー役が検証します。subagent を使えない場合は、同じコンテキストの中で実装とレビューを順に行います。

v2 以前の解説記事にある /kiro:spec-init のようなコロン付きのコマンドは、--claude などのフラグで入る旧来のコマンドモードです。README では非推奨とされています (Codex の --codex は使えません)。古い記事の手順のまま入れると、このモードになる点に注意してください。

生成されるファイルと、人がレビューする箇所

仕様は .kiro/specs/<機能名>/ に、プロジェクトの前提 (技術スタックや規約) は .kiro/steering/ に、どちらも Markdown で置かれます。リポジトリに入るので、前半で述べた「仕様をコードと同じ場所に置く」原則はそのまま満たせます。

EARS (Easy Approach to Requirements Syntax) は、「WHEN 条件 THE SYSTEM SHALL 振る舞い」の形で要件を書く記法です。前半で勧めた「〜のとき、〜になる」と同じ発想で、受け入れ条件をテストへ一対一で落としやすくなります。

テンプレートと生成ルールは .kiro/settings/templates/ と .kiro/settings/rules/ に置かれ、チームの書式に合わせて書き換えられます。仕様の置き場所を .kiro 以外にしたい場合は、インストール時に --kiro-dir docs のように指定します。

チームで入れる前に決めること

cc-sdd を入れても、仕様を読んで承認する人がいなければ、AI が書いた仕様を AI が実装するだけになります。README も、エージェントが仕様を書き、人が各フェーズの区切り (phase gate) で承認する前提で説明しています。チームで使う前に、次の 4 点を決めておきます。

• 要件・設計・タスクの各フェーズを、誰が承認するか。発注側の要件に関わる requirements.md は、要件を出した側の担当者にも読んでもらう
• 安定版の Claude Code・Codex だけで始めるか、beta のエージェントも認めるか
• 既存の CLAUDE.md・AGENTS.md とどう共存させるか。導入前に --dry-run で、追加・変更されるファイルを確かめる
• 生成された仕様を、後述の品質ゲート (受け入れ条件のテスト化と、同じ Pull Request での仕様の更新) に載せるか

ツールの選定から利用ルールの整備、チームへの定着までをまとめて進めたい場合は、FIXIT の AI 開発ツール定着支援 で伴走しています。

cc-sdd・Kiro・GitHub Spec Kit の違いと選び方

仕様駆動開発を道具で支えるものとして、cc-sdd のほかに Kiro と GitHub Spec Kit がよく並べられます。3 つとも、仕様 → 設計 (計画) → タスク → 実装の順に進める点は同じです。違いは、提供元と、いま使っているエージェントを使い続けるかどうかに出ます。

上表は 2026 年 10 月 5 日に、Kiro の公式サイト・Kiro の Specs のドキュメント・Kiro の料金ページ・GitHub Spec Kit のリポジトリ・Spec Kit の連携先の一覧 で確認した内容です。Spec Kit の最新版は v1.1.0 でした。cc-sdd と Spec Kit はツール自体が無料でも、エージェントの利用料は別にかかります。Kiro の料金は公式ページの表示額で、税は含みません。同じページに、請求先住所が日本の場合は日本の消費税がかかると書かれています。

Kiro の機能の仕様 (Feature Specs) は、cc-sdd と同じく requirements.md・design.md・tasks.md の 3 ファイルで、requirements.md は EARS 形式で書かれます。cc-sdd の README は「Kiro スタイル」と名乗り、既存の Kiro の仕様書もそのまま使えるとしています。一方の Spec Kit は、プロジェクトの原則 (constitution) を先に決め、機能ごとに specify → plan → tasks → implement と進め、converge が「Converged」と報告するまで implement と converge を繰り返す流れです。バグ修正とアイデアの評価の手順も、拡張として用意されています。

選ぶときの軸は 3 つです。

1. いま使っているエージェントを使い続けるか。Claude Code や Codex、Copilot をそのまま使うなら cc-sdd か Spec Kit、タスクの進捗表示などを含めて仕様駆動の作業環境ごと欲しいなら Kiro が候補です
2. 既存の Kiro の仕様があるか。Kiro と Claude Code を併用するチームなら、同じ .kiro/specs/ を読める cc-sdd が合います
3. 提供元と実行環境の制約。OSS の採用に提供元の審査がある組織では、個人が公開する cc-sdd と、GitHub が公開する Spec Kit とで扱いが分かれることがあります。開発端末に Node.js と Python (uv) のどちらを入れられるかも確かめます

FIXIT

3 つもあると迷うね。結局どれを入れればいいの？

Tsukasa

結論から言うと、いまのエージェントを変えるかどうかで決まります。

FIXIT

変えないなら、cc-sdd と Spec Kit のどっち？

Tsukasa

判断の軸は、Kiro の仕様を使い回すかです。使い回すなら cc-sdd、GitHub が出す道具を選ぶなら Spec Kit です。

どのツールを選んでも、仕様を読んで承認する工程は人に残ります。道具が揃えるのは仕様の書式と手順までです。仕様が正しいかは承認する人が決め、実装が仕様どおりかは次の品質ゲートで確かめます。

仕様と実装の差分をレビューで検知する品質ゲート

仕様とのずれを見つけるには、人間のレビューをコードの細部より「仕様どおりか」に寄せるほうが効きます。仕様駆動開発のレビューは、次の 3 つの問いに集約できます。

第一に、受け入れ条件をすべて満たしているか。仕様の受け入れ条件を 1 つずつ、対応するテストと実装が存在するかを確認します。条件をそのままチェックリストにして、漏れがないかを見ます。

第二に、仕様にない挙動が混入していないか。AI は親切心や推測で、仕様に書いていない機能やエラーハンドリングを付け足すことがあります。それ自体は悪くないこともありますが、仕様に書かれていない以上は誰もレビューで意図を保証できません。発見したら、仕様へ昇格させるか実装から削るかを判断します。

第三に、仕様が更新されているか。実装の過程で仕様の前提が変わったなら、同じ Pull Request で仕様も更新されているべきです。コードだけ変わって仕様が古いままなら、それは次の手戻りの種です。

これらを人手の善意に頼らず、機械的なゲートに落とすのが品質ゲートの考え方です。CI では仕様の受け入れ条件から導いたテストが全て通ることをマージ条件にします。Pull Request のテンプレートに「対応する仕様セクション」「受け入れ条件のチェックリスト」「仕様の変更有無」の記入欄を設け、書かれていなければレビューを始めない運用にすると、仕様駆動が形骸化しません。

よくある失敗と対策

仕様駆動開発を導入したチームがつまずく典型を、対策とともに挙げます。

仕様が実装に追い越されて陳腐化する。 よくある失敗です。実装が先行し、仕様が「初版のまま」放置されます。対策は単純で、仕様の更新を実装と同じ Pull Request に含めることをルール化し、仕様変更のない機能変更を原則認めないことです。仕様・テスト・実装を 1 つの変更単位として動かせば、三者は構造的にずれません。

受け入れ条件の粒度が荒い。 「ユーザーが快適にログインできる」のような曖昧な条件は、テストにできず、AI も人間も解釈が割れます。対策は「入力・条件・期待結果」の三点が揃った観測可能な文に書き直すことです。テストに落とせない受け入れ条件は、まだ受け入れ条件になっていないと考えます。

仕様を会話に閉じ込める。 Claude Code や Cursor のチャットの中だけで合意し、ファイルに残さないと、次のセッションで AI はその合意を知りません。対策は、合意した仕様を必ずリポジトリの Markdown に書き戻すことです。AI との対話は仕様を作る手段であって、仕様の保管場所ではありません。

仕様を厚く書きすぎて初期が重くなる。 探索段階の機能にまで網羅的な仕様を求めると、書くだけで疲れて形骸化します。対策は、探索フェーズは vibe coding で動くものを作り、確定した機能から仕様へ昇格させる段階運用にすること。すべてを仕様駆動にする必要はありません。

ツールを入れれば仕様駆動になると考える。 cc-sdd や Spec Kit を入れると、仕様の書式と手順は揃います。それでも承認者とレビューの観点が決まっていなければ、AI が書いた仕様を誰も読まないまま、実装が始まります。対策は、フェーズごとの承認者を決め、生成された requirements.md の受け入れ条件を前述の品質ゲートに載せることです。

FIXIT の実案件での運用

10 年もののレガシーシステムを通常見積もり半分でリプレイス では、ドキュメントの無い既存コードから現状の仕様を起こし、既存の挙動をテストで固定してから Claude Code と Cursor で書き直しました。期間は 4 ヶ月 (通常見積もり 8 ヶ月) でした。

仕様を書く初期コストは確かにかかりますが、AI が高速に実装する以上、ボトルネックは実装速度ではなく「何を作るかの確定速度」へ移ります。仕様駆動はそのボトルネックを正面から扱う方法だと考えています。

こうした仕様駆動を含む AI 駆動開発の進め方は、案件ごとに最適な型が変わります。AI 駆動開発 のサービスでは、仕様設計から品質ゲートの整備まで含めて伴走しています。

まとめ

AI が実装を肩代わりする時代に、開発の主導権を握り続ける手段が仕様です。仕様を一次情報として固定し、受け入れ条件をテストへ落とし、仕様と実装の差分をレビューと CI で機械的に検知します。この流れを作れば、Claude Code や Cursor に安心して実装を委ねながら、品質も速度も落とさずに進められます。仕様駆動は AI 駆動開発を堅実に回すための土台です。仕様を書く手順をエージェントに持たせたいなら cc-sdd や GitHub Spec Kit、作業環境ごと仕様駆動に寄せるなら Kiro が選択肢になります。仕様策定を含む要件定義から運用までの工程・体制・成果物の全体像は AI 駆動開発の進め方が一目でわかる|工程・体制・成果物の全体像 で一望できます。

AI 駆動開発の進め方を相談する

仕様設計から品質ゲートの整備、Claude Code・Cursor を実プロジェクトへ組み込む進め方まで、AI 駆動開発のクリエイティブスタジオである FIXIT が伴走します。自社のプロジェクトでどう仕様駆動を始めればよいか、まずは 無料で相談 してください。