はじめに
本記事では、最近注目されている「仕様駆動開発(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]
生成プロセス:
- ユーザーの自然言語説明を解析
- ユーザーストーリーに変換
- 受け入れ基準を明確化
- 機能要件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機能がネイティブに統合されています。
セットアップ
- kiro.devからIDEをダウンロード
- インストールして起動
- 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を選ぶべきケース
-
既存のVSCode環境を維持したい
- 豊富なプラグインや設定をそのまま使いたい
- エディタの移行コストを避けたい
-
チーム全員がSDD初心者
- コマンドベースで段階的に学習
- Gitでドキュメントを共有しやすい
-
複数のAIエージェントを試したい
- Claude, Gemini, Copilot等を切り替え
- ベンダーロックインを避けたい
-
オープンソース優先
- コミュニティ主導の開発
- カスタマイズの自由度
Kiroを選ぶべきケース
-
生産性の最大化
- 統合されたUIで素早く作業
- Hooksで反復作業を自動化
-
ビジュアル重視
- Specやタスクを視覚的に管理
- 進捗状況をダッシュボードで確認
-
高度な自動化が必要
- イベント駆動のワークフロー
- MCPで外部サービスと連携
-
新規プロジェクト
- 既存の環境に縛られない
- 最新の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」からの脱却を目指し、仕様を中心とした体系的な開発プロセスを実現します。プロジェクトの性質、チーム構成、既存の開発環境を考慮して選択しましょう。
- SpecKitを試す: GitHub repo
- Kiroを試す: 公式サイト
