仕様駆動開発（SDD）

SDDとは何か

2025年、AWSが「Kiro」をリリースし、GitHubが「Spec Kit」を公開しました。背景にあるのはAIコーディングの普及による新しい問題です。AIは1時間で数千行のコードを生成できますが、指示のブレや文脈の散逸が起きやすく、大きなプロジェクトで一貫性を保つことが困難になりました。

仕様駆動開発（Spec-Driven Development、以下 SDD）は、仕様書をソースオブトゥルース（source of truth、システムにとっての情報の唯一の正しい出どころ。仕様とコードが食い違ったときは仕様書を正とする）として扱う開発手法です。コードより先に「何を作るか」を文書化し、AIへの指示もその仕様を参照させます。

解決する問題

• AIが生成したコードとドキュメントが乖離する（コンテキスト散逸）
• 複数のAIセッションをまたぐと方針がブレる
• 「何を実装すべきか」の判断基準が曖昧なままAIが動き出す

得られる効果

• 手戻りの削減（仕様が事前に固まっているため）
• AIへの指示の一貫性（毎回仕様書を参照させる）
• ドキュメントとコードの自動同期（仕様変更 → 実装変更が追跡できる）

二大ツールの比較: Spec Kit vs Kiro

Spec Kit の導入手順

Spec Kit は Python 製の CLI ツールです。パッケージ管理ツール uv（Rust製の高速なPythonツール管理コマンド）経由での実行が公式で案内されています。以下は 2025年時点の README に基づく例です。コマンドや対応ツールは更新されるため、実行前に必ず公式 README で最新の手順を確認してください。

# specify コマンドを一時実行してプロジェクトを初期化する
# --ai で使うAIツールを指定（claude / cursor / copilot / gemini など）
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai claude

# uv を使わない場合は pip でも導入できる
pip install git+https://github.com/github/spec-kit.git
specify init my-project --ai claude

初期化すると、/specify /plan /tasks /implement といったスラッシュコマンドが、指定したAIツール上で使えるようになります。

cc-sdd（国産CLIツール）

Claude Codeのカスタムコマンドとして実装したSDD再現ツールです。Spec Kitに近いアプローチで、既存のClaude Code環境にそのまま導入できます。

• Claude Code のカスタムスラッシュコマンドとして動作
• spec.md → plan.md → tasks.md の3ファイル構成を標準化
• CONSTITUTION.md でプロジェクト原則を定義

仕様の書き方: EARS形式

EARS（Easy Approach to Requirements Syntax、要件記述の簡易アプローチ）は、2009年に Alistair Mavin らが提唱した要件記述フォーマットです（原論文の題名は "Easy Approach to Requirements Syntax (EARS)"）。ふつうの文章で書くと「速く」「正しく」など解釈の幅が残りますが、EARS は文の型を数種類に絞ることで曖昧さを減らします。この「解釈の幅を残さない」性質がAIへの指示と相性がよく、SDD実践者の間で広く使われています。

3つのパターン

下の表は代表的な3つの型です。まずは一番上の「条件付き動作」だけ使えれば、TODOアプリ程度の仕様は書けます。

spec.mdの実例（TODOアプリ）

実際の仕様書ファイル spec.md はこのような見た目になります。見出しで機能を区切り、その下に受け入れ基準（AC＝Acceptance Criteria、実装が満たすべき合否ライン）を EARS 形式の箇条書きで並べます。1件目は正常系、2件目は空欄エラー、3件目はEnterキー操作を定義しています。

# TODOアプリ 仕様書（EARS形式）
# 見出し（##）で機能ごとに区切り、その下に受け入れ基準を並べる

## タスク追加

- Given テキスト入力欄に1文字以上入力している
  When ユーザーが「追加」ボタンを押す
  Then そのテキストを持つTODOがリストの末尾に追加される

- When ユーザーが空のテキスト入力欄で「追加」ボタンを押す
  The システムはTODOを追加せず、
      エラーメッセージ「タスク名を入力してください」を表示する

- While テキスト入力欄にフォーカスがある
  When ユーザーがEnterキーを押す
  The システムはボタン押下と同じ追加処理を実行する

悪い例と良い例（1文ずつ対比）

要件そのものの書き方を、あいまいな文とEARS形式で比べます。なぜEARSの方が良いのかを右側の下に添えました。

指示のしかたも比べる

要件が定まったら、AIへの指示も仕様を参照させる形にします。

生成AI時代に注目される理由

AIコーディングツールが普及する前、仕様書の「費用対効果」は低く見られがちでした。小規模プロジェクトなら口頭確認で済む、というのが実態でした。

AIが変えたのは「生産速度」です。Claude CodeやGitHub Copilotは1時間で数百〜数千行のコードを出力します。人間がレビューしきれない速度でコードが積み上がると、仕様の曖昧さが即座に技術的負債になります。

仕様があると何が変わるか

人間とAIの境界を引く

SDDの本質は「何を決めるか（仕様）」を人間が担当し、「どう実装するか（コード）」をAIが担当する境界の明確化です。仕様書のない環境では、AIが「何を作るか」まで判断し始め、人間がその出力を追認する構造になりがちです。

準備と気をつけること

始めるための準備

• AIコーディングアシスタントが使える状態（Claude Code / Cursor / GitHub Copilot / Gemini CLI など、いずれか1つで構いません）
• お好みのエディタ（VS Code / Cursor / JetBrains 系など。特定のエディタに固定する必要はありません）
• Node.js が入っていること（ハンズオンでテストを動かすため。ターミナルで node -v を実行してバージョンが表示されれば準備完了です）
• ツールキットで進める場合は Spec Kit の導入: github.com/github/spec-kit（手順は上の「Spec Kit の導入手順」を参照）
• Constitution ファイルのカスタマイズ（プロジェクトのコーディングルール・禁止事項を記述）
• Markdown で仕様を書く習慣（ただの箇条書きより、EARS のパターンを意識する）

よくある落とし穴

ハンズオン: お手元のAIツールでTODOアプリを実装する

サンプルフォルダ（sample/）を使って、SDDフローを体験してください。以降の「AIに指示する」場面は、お使いのAIコーディングツール（例えば Claude Code / Cursor / GitHub Copilot / Gemini CLI など）のどれでも同じプロンプトで進められます。プロンプト文はツール共通で使えます。

sample/
  specs/
    spec.md       # ← まずここから読む
    plan.md
    tasks.md
  src/
    todo.ts
  test/
    todo.test.ts
  .claude/
    CLAUDE.md
    commands/implement.md
  CONSTITUTION.md

// TODO 1件を表すデータの型
interface Todo {
  id: string;       // 一意の識別子
  text: string;     // タスクの本文
  status: 'active' | 'completed';  // 未完了 / 完了 のどちらか
  createdAt: Date;  // 作成日時
}

specs/spec.md と specs/tasks.md を読んで、
Task 1（addTodo 関数）を src/todo.ts に実装してください。
AC-01 と AC-02 の受け入れ基準を必ず満たすようにしてください。

# 依存パッケージの導入（初回のみ）
npm install

# テストを実行する（npm test でも npx vitest run でも可）
npx vitest run

関連手法との位置づけ

TDD・BDD・ATDD・SDDは対立する手法ではなく、対象とするレイヤーが異なります。

実践では「SDD（仕様）→ BDD/ATDD（受け入れ基準）→ TDD（ユニットテスト）」の順に上から下へと具体化していきます。このハンズオンの spec.md は SDD レイヤー、test/todo.test.ts は TDD と ATDD のレイヤーを同時に担っています。

参考資料

• AWS Kiro 公式ドキュメント
  https://kiro.dev/docs/ — Spec, Design, Tasks, Implement の4フロー詳細
• GitHub Spec Kit リポジトリ
  https://github.com/github/spec-kit — Constitution テンプレート・CLI コマンド群
• Findy Team+ ブログ「仕様駆動開発（SDD）とは？」
  https://findy-team.io — SDD の実践事例・チーム導入のポイント
• EARS手法の原論文（Alistair Mavin ほか, 2009）
  https://ieeexplore.ieee.org/document/5328509 — "Easy Approach to Requirements Syntax (EARS)"。EARS構文を最初に提唱した一次文献
• uv 公式ドキュメント（Astral）
  https://docs.astral.sh/uv/ — Spec Kit の導入に使う Python ツール管理コマンドの使い方
• cc-sdd（GitHub）
  https://github.com/gotalab/cc-sdd — Claude Code のカスタムコマンドとしてSDDフローを再現する国産ツール。導入するとカスタムコマンドが呼べる状態にできる
• Zenn: 仕様駆動開発（SDD）の実践記事
  https://zenn.dev/topics/spec — 国内実践者による導入レポートがトピック単位で集まる

演習課題: SDD で仕様から実装まで体験する

TODOアプリのハンズオンを終えたら、以下のステップで独自の仕様を書いて実装まで進めてください。

# [アプリ名] 仕様書

## [機能名]

### AC-01: [タイトル]
- Given [前提条件]
  When [ユーザーの操作]
  Then [期待される結果]

interface [モデル名] {
  id: string;
  // ...フィールドを列挙
}

// 必要な関数の一覧（シグネチャのみ）
add[モデル名](items: [モデル名][], data: Omit<[モデル名], 'id'>): [モデル名][]
delete[モデル名](items: [モデル名][], id: string): [モデル名][]

specs/spec.md と specs/plan.md を読んで、
AC-01 と AC-02 を満たす関数を src/[ファイル名].ts に実装してください。
実装後に Vitest でテストが通ることを確認してください。

よくある質問

チームへの導入ガイド

個人での習得が済んだら、チームへ広げる段階です。仕様書を書く文化は一日では定着しません。

導入ステップ