主要ツールとエコシステム ── Claude Code・Cursor・Kiro
この章では、SDD実践に使える主要ツールとそれぞれの特徴を整理する。
ツールの全体マップ
SDDに関わるツールは大きく4カテゴリに分類できる。
graph TD
A[仕様記述] --> E[AI実装エンジン]
B[テスト生成] --> E
C[API定義] --> E
D[BDDフレームワーク] --> B
A --> A1[SPEC.md / PLAN.md]
A --> A2[GitHub Spec Kit]
A --> A3[specs.md]
B --> B1[Gherkin / Cucumber]
B --> B2[Jest / Vitest]
B --> B3[Playwright]
C --> C1[OpenAPI / Swagger]
C --> C2[AsyncAPI]
E --> E1[Claude Code]
E --> E2[Cursor]
E --> E3[GitHub Copilot Workspace]
E --> E4[AWS Kiro]
Claude Code(Anthropic)
Anthropicが提供するターミナルベースのAIコーディングアシスタント。SDDとの相性が特によい。
CLAUDE.mdによるプロジェクトコンテキスト
プロジェクトルートに置いたCLAUDE.mdは、Claudeが毎セッション冒頭で自動的に読み込む「プロジェクトの憲法」だ。
# CLAUDE.md の例
## プロジェクト概要
ECサイトのバックエンドAPI(Node.js + Express + PostgreSQL)
## テックスタック
- Node.js 22 / TypeScript 5.4
- Express 5.x
- PostgreSQL 16 with Prisma ORM
- Jest + Supertest(テスト)
- Zod(バリデーション)
## コーディングルール
- 全APIエンドポイントはZodでバリデーション
- エラーレスポンスは `{ error: { code, message } }` の形式
- 認証はJWT(`src/middleware/auth.ts`を使用)
- 直接DBクエリ禁止、必ずRepositoryパターンを経由すること
## ディレクトリ構成
- `src/routes/` — APIルート定義
- `src/services/` — ビジネスロジック
- `src/repositories/` — データアクセス層
- `src/middleware/` — 共通ミドルウェア
- `tests/` — テストファイル
効果:毎回「このプロジェクトはどんな構成ですか?」と説明する必要がなくなる。Claudeが文脈を保持したまま実装を進められる。
SPEC.mdによる機能仕様
機能ごとにSPEC.mdを作成し、実装前にClaudeに渡す。詳細は第5章で解説する。
使用パターン
# CLAUDE.mdがある状態で
$ claude
> @SPEC.md を読んでウィッシュリスト機能を実装して。
> テストから先に書いて、テストがパスしたら実装を追加する形で進めて。
Cursor
VS Codeをフォークしたエディタ型AIコーディングツール。.cursor/rules/にMarkdownを置くことで、プロジェクト固有のルールをAIに与えられる。
Cursor Rulesの設定
# .cursor/rules/project-rules.mdc
## アーキテクチャ
- Repositoryパターンを厳守
- ビジネスロジックはServiceに、DB操作はRepositoryに
- コントローラーは薄く(バリデーション + サービス呼び出しのみ)
## テスト
- 新機能には必ずユニットテストを追加
- テストファイルは `__tests__/` ディレクトリに配置
- モック対象: DB・外部API(実際のDBは使わない)
## 命名規則
- インターフェース: `IUserService`(I + PascalCase)
- 型エイリアス: `UserDto`(PascalCase + Dto)
- 定数: `MAX_RETRY_COUNT`(UPPER_SNAKE_CASE)
Composer(Agent Mode)との組み合わせ
CursorのComposerはマルチファイル編集に対応したAIエージェントだ。SPEC.mdを参照させながらComposerを実行することで、複数ファイルを一括生成できる。
Composer:
"SPEC.mdのウィッシュリスト機能を実装して。
まず tests/wishlist.test.ts を作成し、
次に src/routes/wishlists.ts、
src/services/wishlistService.ts を生成して"
GitHub Copilot Workspace
GitHubが提供するIssue→実装の一貫フロー。
フロー概要
1. GitHub Issueを作成
「ウィッシュリスト機能を追加したい」
2. Copilot Workspaceを開く
→ AIがIssueを読んでSpecを自動生成
3. Specを確認・修正
4. Planを確認
→ 作成・変更するファイル一覧
5. Implementを実行
→ コードを自動生成
6. PR作成(自動)
適した用途:既存リポジトリへの機能追加。Issueを書けばそのままPRになる流れは、チーム開発との親和性が高い。
AWS Kiro
2025年にAWSがリリースしたSpec-first IDEツール。
Kiroの特徴
Kiroの設計思想は「SpecがIDEのファーストクラスオブジェクト」であることだ。
Kiro のプロジェクト構成:
.kiro/
├── spec/
│ ├── user-auth.md # 認証機能の仕様
│ ├── wishlist.md # ウィッシュリストの仕様
│ └── payments.md # 決済の仕様
├── hooks/ # ライフサイクルフック
└── steering/ # AI操作の設定
仕様ファイルを更新すると、KiroのAIエージェントが自動的に差分実装・テスト修正を行う。仕様とコードの同期が自動化される点が他ツールとの最大の差別化点だ。
適した用途:新規プロジェクト。仕様を中心とした設計からスタートするプロジェクトに特に強い。
GitHub Spec Kit
GitHubが2026年1月にリリースしたオープンソースのSDDツールキット。
できること
# インストール
npm install -g @github/spec-kit
# 仕様スキャフォルディング
spec-kit init
# 既存コードから仕様を逆生成
spec-kit generate --from src/
# 仕様からタスクリストを生成
spec-kit plan
# 28のAIエージェントと連携(GitHub Actions統合)
spec-kit implement --agent claude
生成されるSPEC.mdの構造
Spec Kitが自動生成する仕様テンプレートは、後述する「6要素」をカバーしている。
# Feature: [機能名]
## Outcomes
<!-- この機能で達成したいことを記述 -->
## Scope
### In Scope
<!-- 含まれる機能 -->
### Out of Scope
<!-- 含まれない機能(明確に除外) -->
## Constraints
<!-- 技術的・ビジネス的制約 -->
## Prior Decisions
<!-- 既存の設計決定・アーキテクチャ上の前提 -->
## Tasks
<!-- 実装タスクのリスト -->
## Verification Criteria
<!-- 完了条件・テスト基準 -->
specs.md
シンプルで軽量なSDD向けMarkdownフレームワーク。特定のツールに依存しない。
3つのフロー
Simple Flow(個人・小規模):
spec.md を書く → AIに渡す → 実装
FIRE Flow(チーム向け):
Feature → Iterate → Review → Execute
AI-DLC Flow(エンタープライズ向け):
Design → Launch → Continuous
適した用途:ツールを問わず使いたい場合。Claude Code・Cursor・どのツールでも動作する。
どのツールを選ぶか
graph TD
Start[どのツールを使う?] --> Q1{チーム規模は?}
Q1 -->|1〜2人| Q2{既存のIDEは?}
Q1 -->|3〜10人| Q3{GitHubを使っている?}
Q1 -->|10人以上| Q4{AWSを使っている?}
Q2 -->|VS Code系| Cursor[Cursor + SPEC.md]
Q2 -->|ターミナル派| ClaudeCode[Claude Code + SPEC.md]
Q3 -->|Yes| CopilotWS[GitHub Copilot Workspace + Spec Kit]
Q3 -->|No| ClaudeCode2[Claude Code + specs.md]
Q4 -->|Yes| Kiro[AWS Kiro]
Q4 -->|No| SpecKit[GitHub Spec Kit + Claude Code]
最強の組み合わせ(2026年4月現在)
実践的な観点から見た推奨スタックはこうだ:
| フェーズ | ツール | 役割 |
|---|---|---|
| 仕様作成 | GitHub Spec Kit / specs.md | SPEC.mdのスキャフォルディング |
| AI実装 | Claude Code + Cursor | SPEC.mdを読ませて実装生成 |
| BDDテスト | Gherkin + Cucumber | 振る舞い仕様のテスト化 |
| APIコントラクト | OpenAPI | フロント・バック間の仕様 |
| CI/CD検証 | GitHub Actions | 仕様テストの自動実行 |
次の章では、SDDの核心である「SPEC.mdの書き方」を実践的に解説する。