Spec-Driven DevelopmentSDDSpecKitKiroAIGitHub CopilotIDEDevelopment Workflow

仕様駆動開発(Spec-Driven Development: SDD)環境の比較: SpecKit vs Kiro

Sloth255
Sloth255
·6 min read·1,169 words

はじめに

本記事では、最近注目されている「仕様駆動開発(Spec-Driven Development: SDD)」を実現する2つの代表的なアプローチを比較しています。

  • VSCode + GitHub Copilot + SpecKit: 既存のエディタにSDDツールキットを追加する方式
  • Kiro IDE: SDD機能を統合したオールインワンIDE

仕様駆動開発(Spec-Driven Development)とは

従来の開発では、コードが中心で仕様書は補助的な存在でした。SDDはこれを逆転させ、仕様を実行可能な成果物として扱います。

SDDの主要な利点

  • 要件の明確化と文書化
  • AIエージェントへの正確な指示
  • チーム間の認識齟齬の削減
  • 反復的な改善プロセスのサポート

環境1: VSCode + GitHub Copilot + SpecKit

概要

SpecKitは、既存の開発環境でSDDを実現するためのオープンソースツールキットです。GitHubが提供し、スラッシュコマンドを通じてAIエージェントと対話します。

セットアップ

# Specify CLIのインストール
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# プロジェクトの初期化
specify init my-project --ai copilot

# または既存プロジェクトで
specify init . --ai copilot

開発フロー

1. プロジェクト憲法の確立

/speckit.constitution Create principles focused on code quality, 
testing standards, user experience consistency, and performance requirements

このコマンドにより.specify/memory/constitution.mdが生成され、プロジェクト全体のガイドラインが定義されます。

2. 仕様の作成

/speckit.specify Build an application that can help me organize my photos 
in separate photo albums. Albums are grouped by date and can be re-organized 
by dragging and dropping on the main page.

生成されるファイル:

  • .specify/specs/001-feature-name/spec.md: 機能要件とユーザーストーリー

3. 技術実装計画の作成

/speckit.plan The application uses Vite with minimal number of libraries. 
Use vanilla HTML, CSS, and JavaScript as much as possible.

生成されるファイル:

  • plan.md: 技術アーキテクチャ
  • data-model.md: データモデル定義
  • contracts/api-spec.json: API仕様
  • research.md: 技術調査ドキュメント

4. タスク分解

/speckit.tasks

生成されるファイル:

  • tasks.md: 実装タスクリスト(依存関係と並列実行マーカー付き)

5. 実装の実行

/speckit.implement

タスクリストに基づいて順次実装が実行されます。

SpecKitのプロンプトファイル詳細

SpecKitは.github/prompts/ディレクトリに複数のプロンプトファイルを生成します。

speckit.constitution.prompt.md

目的: プロジェクトの基本原則と開発ガイドラインを定義

構造:

---
description: Create or update project governing principles
---

# Project Constitution

Create a comprehensive constitution document that includes:

1. **Code Quality Standards**
   - Naming conventions
   - Documentation requirements
   - Code review processes

2. **Testing Standards**
   - Unit test coverage requirements
   - Integration test strategies
   - Test documentation

3. **Architecture Principles**
   - Design patterns to follow
   - Technology stack constraints
   - Performance requirements

4. **User Experience Guidelines**
   - Accessibility standards
   - Responsive design requirements
   - Internationalization considerations

特徴:

  • AIエージェントが以降の全フェーズでこのドキュメントを参照
  • プロジェクト固有のベストプラクティスを強制
  • チーム間の一貫性を保証

speckit.specify.prompt.md

目的: 機能要件をユーザーストーリー形式で構造化

構造:

---
description: Define requirements and user stories
---

# Specification Template

## User Stories

**As a** [user type]
**I want** [goal]
**So that** [benefit]

### Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2

## Functional Requirements

### FR-001: [Requirement Name]
**Priority**: High/Medium/Low
**Description**: Detailed requirement description
**Dependencies**: [Other requirements]

生成プロセス:

  1. ユーザーの自然言語説明を解析
  2. ユーザーストーリーに変換
  3. 受け入れ基準を明確化
  4. 機能要件IDを付与

speckit.plan.prompt.md

目的: 技術的な実装計画を詳細化

構造:

---
description: Create technical implementation plans
---

# Implementation Plan

## Technology Stack
- Frontend: [Framework/Library]
- Backend: [Framework]
- Database: [Type]
- Deployment: [Platform]

## Architecture Overview
[システム構成図、コンポーネント図]

## Data Model
[エンティティ関係図、テーブル定義]

## API Specifications
[エンドポイント定義、リクエスト/レスポンス形式]

## Implementation Phases
1. Phase 1: [Core features]
2. Phase 2: [Advanced features]

## Technical Considerations
- Security requirements
- Performance optimization
- Scalability concerns

特徴:

  • Constitution.mdの原則に準拠
  • spec.mdの要件を技術的に解決
  • 複数の技術選択肢を比較検討

speckit.tasks.prompt.md

目的: 実装可能な具体的タスクに分解

構造:

---
description: Generate actionable task lists
---

# Task Breakdown

## User Story: [Story ID]

### Task 1: [Task Name]
**File**: `src/components/Feature.tsx`
**Type**: Implementation
**Dependencies**: None
**Parallel**: [P] (if parallelizable)
**Description**: Detailed task description
**Acceptance**: How to verify completion

### Task 2: [Task Name]
**File**: `tests/Feature.test.tsx`
**Type**: Testing
**Dependencies**: Task 1

生成ルール:

  • 依存関係を明示的に管理
  • ファイルパスを具体的に指定
  • テスト駆動開発(TDD)の順序を考慮
  • 並列実行可能なタスクをマーク

speckit.implement.prompt.md

目的: タスクリストに基づいて実装を実行

実行フロー:

---
description: Execute implementation plan
---

# Implementation Execution

1. **Validate Prerequisites**
   - Constitution exists
   - Spec is complete
   - Plan is approved
   - Tasks are defined

2. **Parse Tasks**
   - Read tasks.md
   - Build dependency graph
   - Identify parallel tasks

3. **Execute Tasks**
   For each task in order:
   - Create/modify specified files
   - Run tests (if TDD)
   - Validate against acceptance criteria
   - Update task status

4. **Progress Reporting**
   - Mark tasks as In Progress/Done
   - Report errors with context
   - Suggest next steps

speckit.clarify.prompt.md

目的: 仕様の曖昧な部分を質問形式で明確化

構造:

---
description: Clarify underspecified areas
---

# Clarification Questions

## Coverage Analysis
[仕様で言及されていない領域を特定]

## Sequential Questions
1. **Question**: [Specific question]
   **Context**: [Why this is important]
   **Options**: [Possible answers]

[回答が記録されるとClarificationsセクションに追加]

特徴:

  • Plan作成前に実行推奨
  • 構造化された質問で回答を引き出す
  • 回答は仕様に統合される

生成ドキュメントの例

実際のプロジェクトでは以下のようなディレクトリ構造になります:

my-project/
├── .specify/
│   ├── memory/
│   │   └── constitution.md          # プロジェクト原則
│   ├── specs/
│   │   └── 001-photo-albums/
│   │       ├── spec.md               # 機能仕様
│   │       ├── plan.md               # 実装計画
│   │       ├── tasks.md              # タスクリスト
│   │       ├── data-model.md         # データモデル
│   │       ├── contracts/
│   │       │   └── api-spec.json    # API仕様
│   │       └── research.md           # 技術調査
│   ├── scripts/
│   │   ├── create-new-feature.sh
│   │   └── setup-plan.sh
│   └── templates/
│       ├── spec-template.md
│       ├── plan-template.md
│       └── tasks-template.md
├── .github/
│   └── prompts/
│       ├── speckit.constitution.prompt.md
│       ├── speckit.specify.prompt.md
│       ├── speckit.plan.prompt.md
│       ├── speckit.tasks.prompt.md
│       ├── speckit.implement.prompt.md
│       ├── speckit.clarify.prompt.md
│       └── speckit.analyze.prompt.md
└── src/
    └── [実装ファイル]

長所

オープンソース: MITライセンスで無料利用可能
柔軟性: 複数のAIエージェント対応(Claude, Gemini, Copilot等)
段階的導入: 必要な機能から段階的に導入可能

短所

手動セットアップ: 初期設定に複数のステップが必要
統合の複雑さ: 複数のツールを組み合わせる必要がある
UI体験: コマンドライン中心で視覚的なフィードバックが限定的
学習曲線: 各コマンドの役割と順序を理解する必要がある

環境2: Kiro IDE

概要

Kiroは、プロトタイプから本番環境までをサポートするAgenticなIDEで、SDD機能がネイティブに統合されています。

セットアップ

  1. kiro.devからIDEをダウンロード
  2. インストールして起動
  3. VS Codeの設定とプラグインを自動インポート可能

開発フロー

1. Steering Docsの生成

Kiroパネルから「Generate Steering Docs」を選択すると、.kiro/steering/に以下が生成されます:

  • プロジェクトの技術スタック情報
  • コーディング規約
  • ワークフローガイドライン

2. Spec作成の3フェーズ

Requirements Phase

EARS(Easy Approach to Requirements Syntax)形式でユーザーストーリーと受け入れ基準を記述:

WHEN [条件/イベント]
THE SYSTEM SHALL [期待される動作]

生成ファイル: .kiro/specs/feature-name/requirements.md

Design Phase

技術アーキテクチャとシーケンス図を文書化:

生成ファイル: .kiro/specs/feature-name/design.md

Tasks Phase

実装タスクの詳細計画:

生成ファイル: .kiro/specs/feature-name/tasks.md

3. Hooksによる自動化

ファイル変更に応じて自動的にタスクを実行するイベント駆動の自動化機能:

例: 「Reactコンポーネントを保存したら、自動的にテストファイルを生成」

{
  "hooks": [
    {
      "trigger": "onFileSave",
      "pattern": "**/*.tsx",
      "action": "generateTests"
    }
  ]
}

Kiroのドキュメント構造

my-project/
├── .kiro/
│   ├── steering/
│   │   ├── tech-stack.md
│   │   ├── coding-standards.md
│   │   └── workflows.md
│   └── specs/
│       └── photo-albums/
│           ├── requirements.md    # EARS形式の要件
│           ├── design.md          # アーキテクチャ設計
│           └── tasks.md           # 実装タスク
└── src/
    └── [実装ファイル]

長所

統合体験: すべての機能がIDEにネイティブ統合
視覚的UI: Specリスト、タスクステータスの視覚的管理
自動化: Hooksによるバックグラウンドタスク実行

短所

専用IDE必須: 既存のエディタから移行が必要
ベンダーロックイン: Kiro固有の機能に依存

詳細比較表

観点 SpecKit Kiro
セットアップ CLI経由で手動セットアップ ダウンロード&インストールのみ
学習曲線 コマンド習得が必要 直感的なUI
仕様形式 Markdown with templates EARS + Markdown
タスク管理 tasks.md内でテキスト管理 IDE内で視覚的に管理
自動化 スクリプトベース Hooksによるイベント駆動
Git統合 ブランチベースの自動管理 手動 or IDE機能
AIエージェント 10+ 対応 Kiro統合エージェント
拡張性 テンプレートカスタマイズ可 MCP + Powers
コスト 無料(OSS) プレビュー期間無料
チーム共有 Git経由で完全共有 Git + Kiro固有機能

生成ドキュメントの比較

Constitution/Steering

SpecKit:

  • .specify/memory/constitution.md: 単一ファイル
  • プロジェクト全体の原則を記述
  • すべてのコマンドで参照される

Kiro:

  • .kiro/steering/: 複数ファイル
  • 技術スタック、コーディング規約、ワークフローを分離
  • 自動生成 + カスタマイズ可能

Specification

SpecKit:

# spec.md

## User Stories
As a user, I want to...

## Functional Requirements
FR-001: Feature description

## Review Checklist
- [ ] Requirements are clear
- [ ] Acceptance criteria defined

Kiro:

# requirements.md (EARS形式)

WHEN user clicks upload button
THE SYSTEM SHALL display file selection dialog

WHEN file size exceeds 10MB
THE SYSTEM SHALL display error message

Implementation Plan

SpecKit:

# plan.md

## Architecture
- Frontend: React
- Backend: Node.js

## Implementation Details
[詳細な実装ガイド]

# data-model.md
[データベーススキーマ]

# contracts/api-spec.json
{OpenAPI仕様}

Kiro:

# design.md

## Component Architecture
[システム構成図]

## Sequence Diagrams
[フロー図]

## Technical Considerations
[パフォーマンス、セキュリティ等]

Tasks

SpecKit:

# tasks.md

## User Story: US-001

### Task 1: Setup database schema
File: src/db/schema.sql
Dependencies: None
[P] Parallel: Yes

### Task 2: Create API endpoint
File: src/api/upload.ts
Dependencies: Task 1

Kiro:

# tasks.md

## Phase 1: Core Implementation

- [ ] Task 1: Database setup
  Status: Not Started
  Assignee: [Auto]
  
- [ ] Task 2: API development
  Status: Not Started
  Dependencies: Task 1

使い分けのガイドライン

SpecKitを選ぶべきケース

  1. 既存のVSCode環境を維持したい

    • 豊富なプラグインや設定をそのまま使いたい
    • エディタの移行コストを避けたい
  2. チーム全員がSDD初心者

    • コマンドベースで段階的に学習
    • Gitでドキュメントを共有しやすい
  3. 複数のAIエージェントを試したい

    • Claude, Gemini, Copilot等を切り替え
    • ベンダーロックインを避けたい
  4. オープンソース優先

    • コミュニティ主導の開発
    • カスタマイズの自由度

Kiroを選ぶべきケース

  1. 生産性の最大化

    • 統合されたUIで素早く作業
    • Hooksで反復作業を自動化
  2. ビジュアル重視

    • Specやタスクを視覚的に管理
    • 進捗状況をダッシュボードで確認
  3. 高度な自動化が必要

    • イベント駆動のワークフロー
    • MCPで外部サービスと連携
  4. 新規プロジェクト

    • 既存の環境に縛られない
    • 最新のSDD体験を試したい

SpecKitのプロンプトファイルを活用した高度な使い方

カスタムプロンプトの作成

SpecKitのプロンプトファイルは自由にカスタマイズ可能です:

---
description: Custom quality checklist generator
---

# /speckit.custom-checklist

Generate a quality checklist for:

1. **Security Review**
   - Authentication check
   - Authorization verification
   - Input validation

2. **Performance Review**
   - Database query optimization
   - Caching strategy
   - Load testing results

[Output format: Markdown checklist in spec directory]

複数スペックの管理

# Feature 1
specify init . --ai copilot
/speckit.specify Build user authentication system

# Feature 2 (新しいブランチで)
git checkout -b feature/002-payment
/speckit.specify Integrate payment gateway

実践的なワークフロー例

SpecKitでのチーム開発

graph TD
    A[Product Manager] -->|要件定義| B["speckit.specify"]
    B --> C["spec.md生成"]
    C --> D[Tech Lead]
    D -->|技術選定| E["speckit.plan"]
    E --> F["plan.md, data-model.md生成"]
    F --> G[Developer]
    G -->|タスク確認| H["speckit.tasks"]
    H --> I["tasks.md生成"]
    I --> J["speckit.implement"]
    J --> K["コード生成"]
    K --> L[Pull Request]
    L --> M[Code Review]
    M -->|承認| N[Merge]

SpecKitを使ったチーム開発フロー: 役割ごとにコマンドを使い分け、Git経由でドキュメントを共有

Kiroでのソロ開発

graph TD
    A[アイデア] --> B[Spec Chat]
    B --> C[Requirements生成]
    C --> D[Design生成]
    D --> E[Tasks生成]
    E --> F[#spec参照してコーディング]
    F --> G[ファイル保存]
    G --> H[Hooks起動]
    H --> I[自動テスト生成]
    I --> J[バックグラウンドで実行]

Kiro IDEを使ったソロ開発フロー: 統合UIとHooksによる自動化で効率的な開発サイクルを実現

まとめ

SpecKitは、既存の開発環境を活かしながらSDDを導入したいチームに最適です。オープンソースで柔軟性が高く、段階的な導入が可能です。

Kiroは、最新のAgenticなIDE体験を求める開発者に向いています。統合されたUI、自動化機能、視覚的なフィードバックにより、生産性を最大化できます。

どちらの環境も、従来の「vibe coding」からの脱却を目指し、仕様を中心とした体系的な開発プロセスを実現します。プロジェクトの性質、チーム構成、既存の開発環境を考慮して選択しましょう。