この記事でわかること
  • spec-kitの正体——GitHub公式の「仕様駆動開発(SDD)」ツールキットとは何か
  • なぜ今「仕様」が再注目されているのか——vibe codingの限界
  • specify→plan→tasks→implementの4ステップと実際のインストール手順
  • cc-sdd(CCSD)・AI-DLC・Kiro・OpenSpecとの違い——同じ看板でもレイヤーが違う
  • 結局どれを選ぶべきか——目的別の判定フローチャート
  • spec-kitの限界と落とし穴、そして正直な注意点

「AIにコードを書かせると速い。でも、何を作らせたかったのか、3日後には誰も思い出せない」——AIコーディングが当たり前になった今、多くのチームがこの壁にぶつかっている。その答えとしてGitHubが出したのが、仕様（スペック）を先に書き、そこからAIに実装させるという発想の公式ツールキット、github/spec-kitだ。

spec-kitの公式オーバービュー動画。仕様→実装の流れがそのまま動く（出典: The ONLY guide you'll need for GitHub Spec Kit（Den Delimarsky）、READMEリンク動画）

spec-kitは公開から1年足らずで★120,308（2026-07-13時点）を集めた。だが人気と同時に、読者の頭を悩ませているのが似た名前・似た主張のツールが乱立していることだ。「CCSD（Claude Code Spec Driven）」、AWSの「AI-DLC」、同じくAWSの「Kiro」、そして「OpenSpec」——どれも“仕様駆動”を名乗る。本記事は、spec-kit本体の使い方を公式リポジトリから丁寧に解説したうえで、この混同しやすい5つを提唱者・出典付きで腑分けする。

Claude Code全体の基礎から本番運用までは、まず Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き を土台にすると、本記事の位置づけがつかみやすい。

先に結論：spec-kitは「AIにコードを書かせる道具」ではなく「AIに“何を作るか”を先に確定させる道具」だ。仕様書を唯一の真実（source of truth）に据え、そこから計画・タスク・コードを機械的に生成する。cc-sdd(CCSD)・AI-DLC・Kiro・OpenSpecは看板こそ同じ“仕様駆動”だが、ツール／方法論／IDEというレイヤー（高度）が違う。混同の正体はここにある。

30秒でわかる：spec-kitは「仕様をコンパイルする」ツール

spec-kitのサマリー。github/spec-kit・★120,308・MIT。/speckit.constitutionで開発原則を定義し、specify→plan→tasks→implementで仕様から実装コードまで生成。30以上のAIエージェント(Copilot/Claude Code/Cursor/Gemini)に対応。仕様駆動系OSSの★数はspec-kit 120,308が突出、OpenSpec 60,524、cc-sdd 3,562、aidlc-workflows 3,463。Python 3.11+ / uv で導入
spec-kitを1枚で。GitHub公式・★120,308・仕様→実装を一気通貫（出典: github/spec-kit README と GitHub API 実測、MIT）

課題はシンプルだ。AIコーディングは速いが、意図が残らない。 プロンプトで場当たり的に書かせたコードは、なぜそうなっているのか、何を満たすべきなのかが会話ログの中に溶けていく。数週間後にバグを直そうとすると、仕様が誰の頭にも無い——これがAI時代の新しい技術的負債だ。

spec-kitの解決策は「仕様を先に、明文化して固める」こと。人間は「何を作りたいか（What）」と「どう作るか（How）」を構造化されたMarkdownとして書き、AIエージェントはその仕様を実行可能な入力として扱い、計画・タスク・コードへと“コンパイル”する。READMEはこれを「specifications become executable（仕様が実行可能になる）」と表現する。以下がひと目でつかむための要点だ。

・提供元：GitHub公式。CLIの名前は specify（パッケージ名 specify-cli）
・中身：/speckit.* という一連のスラッシュコマンド群（後述）
・対応エージェント：GitHub Copilot・Claude Code・Cursor・Gemini CLI・Codex CLIなど30以上
・ライセンス：MIT／★120,308／最新版 v0.12.11（2026-07-10）
・必要環境：Python 3.11+・uv・Git（Linux/macOS/Windows）

spec-kitとは何か——GitHub公式の仕様駆動開発ツールキット

specify CLIがターミナルで新規プロジェクトを初期化していくデモ。エージェントを選び、テンプレートとスラッシュコマンドを展開する様子
specify CLIが新規プロジェクトをブートストラップする様子（出典: github/spec-kit README（media/specify_cli.gif）、MIT）

spec-kitが実装しているSpec-Driven Development（仕様駆動開発, SDD）は、従来の常識をひっくり返す。これまでは「コードが王様（code has been king）」で、仕様はコードを書くための足場に過ぎず、実装が終われば捨てられていた。SDDはこれを逆転させ、仕様を捨てずに“真実の源”として持ち続け、そこから実装を生成し続ける。

仕組みは、プロジェクトに導入される一連のスラッシュコマンドだ。コマンドには /speckit. という接頭辞が付く（以前の /constitution などから変更された。ここを間違える記事が多いので注意）。中核となる流れは次のとおり。

flowchart TD A["📜 /speckit.constitution
プロジェクトの開発原則を定義"] --> B["📋 /speckit.specify
何を作るか（要件・ユーザーストーリー）"] B --> C["❓ /speckit.clarify
曖昧な点を対話で詰める（任意）"] C --> D["🛠 /speckit.plan
技術スタックと実装計画"] D --> E["✅ /speckit.tasks
実行可能なタスクリストに分解"] E --> F["🔍 /speckit.analyze
仕様・計画・タスクの整合性を検査（任意）"] F --> G["🤖 /speckit.implement
タスクを順に実装コードへ"]

各コマンドが生み出す成果物を整理するとこうなる。

・/speckit.constitution：憲法（constitution）。プロジェクトを貫く原則・規約を定義し、以降の全生成がこれに従う
・/speckit.specify：仕様書。実装の詳細ではなく「何を・なぜ」を書く。ユーザーストーリーと受け入れ条件が中心
・/speckit.plan：技術計画。使う言語・フレームワーク・アーキテクチャなど「どう作るか」を確定
・/speckit.tasks：タスクリスト。計画を、AIが順に実行できる粒度の作業へ分解
・/speckit.implement：実装。タスクを1つずつコードに落とす

さらに新しめのコマンドとして、タスクをGitHub Issueへ変換する /speckit.taskstoissues、既存コードと仕様の乖離を評価して残作業を追記する /speckit.converge、品質チェックリスト（“英語で書く単体テスト”）を生成する /speckit.checklist もある。ポイントは、人間がレビューするのは膨大なコードではなく、その手前の“仕様・計画・タスク”という短い文書だということ。実装が走る前に方向性を正せるのが、SDDの一番の狙いである。

GitHub公式でありながら特定エージェントに縛られないのも特徴だ。READMEは「Spec Kit works with 30+ AI coding agents（30以上のAIコーディングエージェントで動く）」と明記し、初期化時に --ai copilot --ai claude のようにエージェントを選ぶ。つまりClaude CodeでもCopilotでもCursorでも、同じ仕様駆動の“型”を持ち込めるわけだ。この点は、後述するcc-sddやKiroとの決定的な違いになる。

なぜ今、Spec-Driven Developmentが必要になったのか

vibe codingと仕様駆動の違い。vibe codingは意図が会話ログにしか残らない・再現も引き継ぎもできない・コード量が増えると破綻・レビューの拠りどころが無い。仕様駆動は仕様書が唯一の真実・仕様から実装をAIが機械的に生成・実装前に仕様をチームでレビュー・仕様を直せば実装もやり直せる
SDDが解決するのは「速いが再現できない」vibe codingの弱点（出典: 本記事編集部作成）

SDDが生まれた背景を理解するには、対義語である「vibe coding」を知る必要がある。この言葉は2025年2月2日、Andrej Karpathy氏がXで名付けたもので、「コードの存在すら忘れて、AIの出すdiffをひたすらAcceptしていく」ようなフィーリング頼りの開発を指す。試作やデモには最高だが、チームで長く保守するプロダクトには向かない。理由は3つある。

・意図が揮発する：なぜその実装なのかが、AIとの会話にしか残らず、他人が引き継げない
・レビューの基準が無い：出てきたコードが“正しい”かを判断する拠りどころが存在しない
・規模で破綻する：ファイルが増えるほど、場当たりの指示は矛盾し、AIも過去の意図を見失う

spec-kitのREADMEはこの状況を踏まえ、SDDを「instead of vibe coding every piece from scratch（すべてを場当たりで書く代わりに）」仕様から実装を導くアプローチだと位置づける。仕様書という“共通の真実”を挟むことで、AIの速さを保ちながら、人間のレビューと再現性を取り戻す。これがSDDの核心であり、spec-kitだけでなくcc-sdd・Kiro・OpenSpec・AI-DLCが揃って掲げる共通の動機でもある。

言い換えれば、これらのツールは全員が「vibe codingへのアンチテーゼ」だ。だからこそ主張が似て見える。違いは“何を”ではなく“どのレイヤーで”仕様駆動を実現するかにある——次章以降で、その高度差をはっきりさせていく。

spec-kitの実際の使い方——インストールと4ステップ

spec-kitがClaude Code環境をブートストラップする様子。スラッシュコマンドとテンプレートがClaude Codeに展開される
Claude Code環境にspec-kitを導入する様子（出典: github/spec-kit README（media/bootstrap-claude-code.gif）、MIT）

「spec-kit 使い方」で検索してたどり着いた人が一番知りたいのは、おそらくこの章だろう。結論から言えば、導入は驚くほど短い。公式が主要ルートとして案内するのは、uv でCLIを常駐インストールする方法だ。

# specify CLI をインストール（uv を利用）
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# 新規プロジェクトを初期化（使うエージェントを指定）
specify init my-project --ai claude      # Claude Code の場合
# specify init my-project --ai copilot   # GitHub Copilot（既定）
# specify init . --ai cursor             # 既存ディレクトリに導入

# 導入状態のセルフチェック / アップグレード
specify self check
specify self upgrade

uv を使わない場合は pipx、あるいはインストールせずに一度だけ実行する uvx --from git+https://github.com/github/spec-kit.git specify init my-project も使える（従来の一行コマンドも引き続き動作する）。初期化すると、指定したエージェント向けのテンプレートと /speckit.* スラッシュコマンドがプロジェクトに展開される。

あとは、エージェント（Claude CodeやCopilot Chat）のチャットからスラッシュコマンドを順に叩くだけだ。

# 1. 開発原則を定義
/speckit.constitution 品質・テスト・UX・パフォーマンスの基本方針を定める

# 2. 何を作るかを仕様化（実装ではなく要件を書く）
/speckit.specify 写真をアルバムにグルーピングするアプリ。日付でタイル表示し、
                 ドラッグでまとめ替えできる。ネストは作らない。

# 3. 技術計画を作成（どう作るか）
/speckit.plan Vite + 最小限のライブラリ。DBは使わずローカルにメタデータを保存

# 4. タスク分解 → 5. 実装
/speckit.tasks
/speckit.implement

書き方のコツは、/speckit.specify では“実装”を語らないことだ。「何を・誰のために・どうなれば完成か」を書き、技術選定は /speckit.plan に回す。この分離こそがSDDの肝で、仕様と実装を混ぜないから、後から仕様だけを直して作り直せる。曖昧さが多いテーマなら、/speckit.plan の前に /speckit.clarify を挟むと、AIが不明点を質問で潰してくれる。実装前の最終チェックには /speckit.analyze で仕様・計画・タスクの食い違いを洗い出しておくと安全だ。

なお、この「スラッシュコマンドで開発工程を型化する」考え方自体は、Claude Codeのコマンド機能と地続きだ。コマンドの作り方や使いどころは Claude Codeのコマンド完全ガイド が詳しい。spec-kitは、その型を“仕様駆動”という一貫した流れに仕立てた公式パッケージだと捉えるとわかりやすい。

cc-sdd(CCSD)・AI-DLC・Kiro・OpenSpecとの違い【本命】

同じ仕様駆動でもレイヤーが違う。方法論=AI-DLC（AWS提唱、開発プロセス全体を再設計・ツール非依存）、IDE製品=Kiro（AWS・商用、EARS記法で仕様→実装する専用IDE）、OSSツール=spec-kit / cc-sdd / OpenSpec（既存のAIエージェントに仕様駆動フローを導入）
混同の正体は「高度差」。方法論・IDE製品・OSSツールは別レイヤー（出典: 本記事編集部作成、各公式情報より）

ここが、多くの読者が一番知りたい部分だろう。結論から言うと、5つは競合ではなく、レイヤー（高度）が違う。まず、言葉を実体に正しく対応させるところから始める。

・cc-sdd（俗称CCSD）：日本の開発者 Gota氏（gotalab／@gota_bara） が作ったOSS。npx cc-sdd@latest で、Kiro風の仕様駆動フローをClaude Codeなどに導入するCLIツール。★3,562・MIT。/kiro-spec-init→/kiro-spec-requirements→/kiro-spec-design→/kiro-spec-tasks→/kiro-impl という流れをスキル／コマンドとして展開する。
・AI-DLC（AI-Driven Development Life Cycle）：AWSが提唱する方法論。ツールではない。AWSのRaja SP氏らが2025年7月に発表し、SDLCそのものをAI前提に再設計する。
・Kiro：AWSの商用IDE製品。EARS記法で requirements.md／design.md／tasks.md を生成する仕様駆動の統合開発環境。
・OpenSpec：Fission-AI製のOSS（★60,524・MIT）。軽量で反復的な仕様駆動フレームワーク。「変更提案（change proposal）」単位で回す。

honest framing（正直な但し書き）：調査時点で「CCSD」という正式名称の単一プロダクトは確認できていない。実在して普及しているのは表記 cc-sdd（gotalab/cc-sdd）であり、「Claude Code Spec-Driven Development」の頭文字を取った俗称・総称としてCCSDが使われている、というのが実態だ。本記事ではcc-sddを実体として扱う。

本命の比較表（spec-kit / cc-sdd(CCSD) / AI-DLC / Kiro / OpenSpec）

ツール／手法 種別 提唱者・メーカー 対象エージェント OSS／商用 生成する成果物 学習コスト・重さ
spec-kit ツール（CLI） GitHub 公式 30+（Copilot/Claude Code/Cursor/Gemini…） OSS（MIT・★120,308） constitution／spec／plan／tasks の各Markdown＋実装 重め（厳格なフェーズゲート）
cc-sdd（CCSD） ツール（CLI/インストーラ） Gota（gotalab、個人・日本） Claude Code中心（Codex/Cursor/Copilot等も） OSS（MIT・★3,562） Kiro風のspec/requirements/design/tasks＋steering 中（npxで即導入・日本語対応）
AI-DLC 方法論（プロセス） AWS（Raja SP 他） ツール非依存（Q Developer/Kiroが実装） 方法論（無償公開）＋steering rules awslabs/aidlc-workflows（MIT-0・★3,463） Inception/Construction/Operationsの成果物、Bolt単位 高め（組織・進め方の変更を伴う）
Kiro IDE製品 AWS（Amazon） Kiro専用（自社エージェント） 商用（無料枠あり・クローズド） EARS記法の requirements／design／tasks.md 中（IDE習得が必要）
OpenSpec ツール（CLI） Fission-AI 30+（Claude Code/Cursor/Copilot等） OSS（MIT・★60,524） change proposal（proposal/specs/design/tasks） 軽量（fluid・反復重視）

補足を1段落ずつ。spec-kitはGitHub公式の“重厚な標準”。フェーズゲートを丁寧に踏むぶん、大規模・複数エージェントに強い。cc-sddは、そのKiro由来の型をClaude Codeに1コマンドで日本語込みで持ち込む軽快さが武器で、個人・日本語ユーザーに人気。AI-DLCだけは毛色が違い、ツールではなく“進め方”——スプリントの代わりに数時間〜数日の「Bolt」で回し、チーム全員でAIの提案を検証する「Mob Elaboration／Construction」を行い、重要な意思決定は必ず人間に残す（AI proposes, human approves）。KiroはAWSが出した専用IDEそのもので、EARS記法（”WHEN [トリガー] the system shall [応答]”）で仕様を書く。OpenSpecはspec-kitの対極で、軽さと反復に振り切っている。

系譜のメモ：cc-sddは自らを「Kiro-inspired」と称し、KiroのスペックメソッドをClaude Codeへ移植したもの。AI-DLCもAWS発で、KiroやAmazon Q Developerがその方法論を実装する道具にあたる。つまりcc-sddとAI-DLCは、どちらもAWSのKiroという同じ源流に触れている——ただし高度が違う（片や具体ツール、片やチーム方法論）。この一点を押さえると、混乱はほぼ解ける。

さらに一歩踏み込んで、それぞれの“中身”を具体的に見ておこう。表だけでは伝わらない設計思想の違いが、選択の決め手になる。

AI-DLC（方法論）の三段構え——AI-DLCはSDLCを3フェーズに再設計する。①Inception：AIが業務要求を要件・ユーザーストーリー・「Units of Work（従来のEpicに相当）」へ変換し、チームが「Mob Elaboration」で検証する。②Construction：AIが論理アーキテクチャ・ドメインモデル・コード・テストを提案し、チームが「Mob Construction」で技術判断を詰める。③Operations：蓄積した文脈をもとにInfrastructure-as-Codeやデプロイを管理する。特徴的なのが、週単位のスプリントではなく数時間〜数日の「Bolt」という高密度サイクルで回すこと。掲げる4つの価値は「孤立した解より人間とAIの協調」「個人の閃きより集合知」「分析麻痺より迅速な意思決定」「開発速度よりビジネスインパクト」。AWSは大幅な生産性向上を報告しているが、これらはAWS自身の公表値（自己申告）であり、第三者の独立検証ではない点は正直に付記しておく。

Kiro（IDE製品）のEARS記法——KiroはVS CodeフォークではなくCode OSSベースの独立IDEで、旧Amazon Q Developerの実質的後継として2026年5月に国際GAした。仕様はEARS記法（”WHEN [トリガー] the system shall [応答]” の型）で requirements.md／design.md／tasks.md の三点セットに落とし、Property-Based Verificationで仕様と実装の乖離を検証する。モデルはClaude Sonnet 4.5＋自動ルーティング。無料枠＋有料枠のクレジット課金だが、具体的な料金額は本記事調査時点で公式から拾いきれなかったため、導入前に kiro.dev で最新の価格を確認してほしい。

cc-sdd（CCSD）とOpenSpecの軽快さ——cc-sddは一行で、Claude Code・Codex・Cursor・Copilot・Windsurf・OpenCode・Gemini CLIなどにKiro風フローを展開する。導入の手軽さがspec-kitとの体感差になる。

# Claude Code に日本語でKiro風の仕様駆動ワークフローを導入（cc-sdd＝俗称CCSD）
npx cc-sdd@latest --claude --lang ja
# 以後、エージェント側で /kiro-spec-init → /kiro-spec-requirements
#            → /kiro-spec-design → /kiro-spec-tasks → /kiro-impl と進める

/kiro-impl は長時間の自律実装（タスクごとにTDDのRED→GREEN、独立レビュー、自動デバッグ）まで面倒を見るのが特徴だ。一方OpenSpecは、変更を「change proposal」フォルダで扱い、propose（提案作成）→ apply（仕様どおり実装）→ archive（完了を退避）の3ステップで回す。「fluid not rigid（硬直でなく流動的）／iterative not waterfall」を標榜し、spec-kitの重厚さと真っ向から対照をなす。

なお、Aiderは“非・仕様駆動の対照”として覚えておくと輪郭が締まる。Aider（Paul Gauthier製・Apache-2.0・★47,338）はターミナルのAIペアプロで、requirements→design→tasksという仕様文書を持たず、diff／編集ベースで即コードを直す。architectモードで「計画と編集」を分けはするが、フォーマルな仕様を駆動する設計ではない。「仕様を作らずに即書く」Aiderと、「仕様を作ってから書く」spec-kit勢を対比すると、SDDが何を足しているのかがくっきりする。

結局、どれを選ぶべきか——目的別の判定チャート

同じ“仕様駆動”でもレイヤーが違う以上、選び方も「良し悪し」ではなく「目的の高度」で決まる。次のフローチャートが最短の道案内だ。

flowchart TD Q1["仕様駆動を取り入れたい"] --> Q2{"チーム全体の
開発プロセスを
変えたい？"} Q2 -->|Yes（進め方から）| AIDLC["AI-DLC を読む
AWSの方法論・ツール非依存"] Q2 -->|No（今の作り方で）| Q3{"専用IDEに
乗り換えてよい？
（商用可）"} Q3 -->|Yes| KIRO["Kiro
AWSの仕様駆動IDE"] Q3 -->|No（既存環境で）| Q4{"主に使う
エージェントは？"} Q4 -->|Claude Code中心| CCSDD["cc-sdd（CCSD）
npxで即・日本語対応"] Q4 -->|複数/公式志向| SPECKIT["spec-kit
GitHub公式・厳格な型"] Q4 -->|軽く反復したい| OPENSPEC["OpenSpec
軽量・変更提案型"]

さらに噛み砕いた「こういう人はこれ」早見表も置いておく。

こんな人・状況 おすすめ 理由
複数エージェントで統一した仕様駆動を回したい／公式の安心感が欲しい spec-kit GitHub公式・30+対応・厳格なフェーズゲート
Claude Code中心で、今すぐ日本語のKiro風フローを入れたい cc-sdd（CCSD） npx cc-sdd@latest --claude --lang ja の手軽さ
チーム／組織の開発プロセスそのものを再設計したい AI-DLC ツールでなく方法論。Bolt・Mobで進め方を変える
専用IDEごと乗り換えてよい／EARS記法で厳密に書きたい Kiro AWS製の仕様駆動IDE。仕様と実装の乖離を検証
重い手続きは避け、軽く反復しながら仕様を育てたい OpenSpec 変更提案単位でpropose→apply→archive

迷ったらspec-kitかcc-sddから始めるのが現実的だ。前者は「公式・多エージェント・堅牢」、後者は「Claude Code特化・即導入・日本語」。どちらも無料で、仕様駆動の“体験”を最短で掴める。合わなければ、より上位のAI-DLC（方法論）やKiro（IDE）に視野を広げればよい。この段階的な入り方は、Smart Ralph｜Claude Code/Codexにspec-driven開発を持ち込む14コマンド・6エージェント基盤 のような、より作り込まれたspec-driven基盤へ進む前の助走にもなる。

spec-kitの限界と落とし穴

spec-kitでつまずくポイント。Python/uv必須で非Python環境は導入がやや重い、Markdown肥大で仕様・計画・タスクの文書が増える、フェーズゲートは手数が多く小さな修正には過剰、コマンド変更(/speckit.接頭辞など)で仕様が流動的、結局モデル依存で実装品質はエージェントの性能次第
導入前に知っておきたい5つの注意点（出典: 本記事編集部作成、READMEと実運用の観点より）

公式で強力なspec-kitにも、正直に言うべき弱点がある。誇張せず並べておく。

・Python／uv前提の導入コスト：CLIはPython 3.11+とuvを要求する。JS/Goしか触らないチームには、環境準備が地味に重い
・Markdownが肥大しがち：constitution・spec・plan・tasksと文書が増える。小さな機能追加に毎回フルフェーズは過剰で、OpenSpecのような軽量型が好まれる理由でもある
・フェーズゲートの手数：「型どおり進める」強みは、裏を返せば手続きの多さ。ワンショットの修正には向かない
・コマンド仕様が流動的：本記事執筆時点で /speckit. 接頭辞へ変更されたばかり。バージョン（v0.12.x）で名前や挙動が動くので、古い記事のコマンドをそのまま真似ると失敗する。必ず公式ドキュメントで最新のコマンド名を確認すること
・結局はエージェント／モデル依存：spec-kitは“型”を与えるが、実装コードの品質は動かすエージェント（Claude Code等）とモデルの性能に大きく左右される。仕様が良くても、実装が伴うとは限らない

裏を返せば、spec-kitが効くのは「仕様を明文化する価値がある、そこそこの規模の開発」だ。使い捨てのスクリプトや一発ネタには、vibe codingのほうが速い。ツールの向き不向きを見極めるのも、SDDを使いこなす一部である。他エージェントとの比較検討をしたい場合は、Claude CodeとCursorを徹底比較 のような比較記事も合わせて読むと、自分の開発スタイルに合う組み合わせが見えてくる。

まとめ

spec-kitは、GitHubが「AIコーディング時代に仕様を取り戻す」ために出した公式ツールキットだ。/speckit.specify→plan→tasks→implementという一本道で、プロンプトから仕様・計画・タスク・実装コードまでをAIに一気通貫させる。vibe codingの速さを保ちつつ、意図・再現性・レビューを取り戻すのがその本質である。

そして本記事の主眼だった区別を、もう一度だけ。spec-kit・cc-sdd(CCSD)・OpenSpecは“既存エージェントに仕様駆動を入れるOSSツール”、Kiroは“AWSの専用IDE製品”、AI-DLCは“AWSが提唱する開発プロセスの方法論”。同じ看板でもレイヤーが違う。この高度差さえ掴めば、乱立する“仕様駆動”に振り回されることはない。まずはspec-kitかcc-sddで手を動かし、必要になったら上位のレイヤーへ——それが、遠回りしない仕様駆動開発の始め方だ。

参照ソース

・github/spec-kit — GitHub 公式リポジトリ・README（★120,308・MIT・v0.12.11、2026-07-13 実測）
・Spec Kit ドキュメント（github.github.io/spec-kit）
・gotalab/cc-sdd — Claude Code向け仕様駆動ワークフロー（CCSD）
・AI-Driven Development Life Cycle (AI-DLC) — AWS DevOps Blog（Raja SP, 2025-07-31）
・awslabs/aidlc-workflows — AI-DLC steering rules（MIT-0）
・Kiro — AWSの仕様駆動エージェンティックIDE
・Fission-AI/OpenSpec — 軽量な仕様駆動フレームワーク
・Andrej Karpathy「vibe coding」命名投稿（2025-02-02）