〜仕様駆動開発の理想と現実〜
（結論）
Kiro で仕様を定義し、Claude Code で実装することで
タスク順守は高いレベルで実現できたが、人間の監督は依然として不可欠だった。
はじめに
「AIに仕様書を書かせて、別のAIに実装させたらどうなるのか？」
この素朴な疑問から、私は Kiro（AWS が提供する仕様駆動開発IDE）と Claude Code（Anthropic のコーディングエージェント）を組み合わせた開発スタイルを試してみました。
1週間の実験で分かったこと、想定外だったこと、そして「人間の役割はどう変わるのか」について、正直にレポートします。
なぜこの構成を試したのか
仕様駆動開発への期待
私が検証したかったのは、以下の2点です：
-
仕様書を中心にClaude Codeが動くか
- tasks.md に書いたタスク順に実装が進むのか
- design.md の設計を守ってくれるのか
-
Kiroで仕様書を正確に作れるか
- 要件の抜け漏れを防げるか
- Claude Codeが理解しやすい仕様書になるか
想定した役割分担
| Kiro（チームリーダー） | 役割の流れ | Claude Code（プログラマー） |
|---|---|---|
| 要件定義 | → | コード実装 |
| 設計書作成 | → | テスト実行 |
| タスク分解 | → | フェーズ管理 |
| レビュー | ← | レポート生成 |
人間（私）は、このサイクルを監督する立場になれるのか？ という実験です。
実験1：新規プロジェクト「KiroBookmark」
プロジェクト概要
| 項目 | 内容 |
|---|---|
| アプリ名 | KiroBookmark（技術ブログ管理アプリ） |
| 技術スタック | Swift / SwiftUI / Core Data / iOS |
| 開発期間 | 1週間（Phase 1A MVP） |
| 結果 | 7タスク完了、68テスト成功 |
Kiro側の設定
Kiroが生成・管理する仕様書は以下の5ファイルです：
.kiro/specs/bookmark-manager/
├── requirements.md # 要件定義（EARS形式、22要件）
├── design.md # 設計書（Swift Protocol、Mermaid図）
├── tasks.md # タスク計画（7タスク、完了条件付き）
├── usecase.md # ユースケース（10シナリオ）
└── screen-design.md # 画面設計（UIコンポーネント仕様）
https://github.com/miyakawa2449/KiroBookmark
requirements.md の書き方
Kiroは EARS形式（Easy Approach to Requirements Syntax）で要件を生成します：
Requirement 1: 記事ブックマーク管理
User Story: AIエンジニアとして、技術ブログの記事を
ブックマークとして保存・管理したい。
Acceptance Criteria
-
WHEN ユーザーがURLを入力してブックマーク追加を実行する
THEN THE Blog_Manager SHALL 新しい記事ブックマークを作成して
リストに追加する -
WHEN ユーザーがブックマークを削除する
THEN THE Blog_Manager SHALL そのブックマークと関連する
すべてのメモをリストから完全に削除する
この形式は Claude Code が理解しやすく、テストケースにも変換しやすいのが利点です。
design.md のポイント
design.md で特に重要なのは、Claude Code との連携セクションです：
開発環境・ツール
Agent Skills（Claude Code用）
| Skill | 目的 | 設計への影響 |
|---|---|---|
| ios-security | OWASP準拠チェック | Keychain必須、ATS無効化禁止 |
| swiftui-review | コード品質 | Viewは200行以下、MVVM遵守 |
| swift-build | ビルド手順 | SwiftLint警告0が必須 |
制約事項
- セキュリティSkillでNGになるコードはタスクから除外
- ビルドSkillの手順を通過しないとタスク完了としない
設計段階で Claude Code の制約を明示しておくことで、実装時の手戻りを防ぎます。
Claude Code側の設定
CLAUDE.md（メイン設定ファイル）
プロジェクトルートに置く CLAUDE.md で、Claude Code の振る舞いを定義します：
CLAUDE.md - Project Context & Rules
🌐 言語設定
- ユーザーとの会話・説明: 日本語
- コード内のコメント: 英語（Swift標準に従う）
📚 参照ドキュメント（★Kiro連携）
| 用途 | ファイルパス |
|---|---|
| 要件定義 | .kiro/specs/bookmark-manager/requirements.md |
| 設計書 | .kiro/specs/bookmark-manager/design.md |
| タスク計画 | .kiro/specs/bookmark-manager/tasks.md |
⛔ 禁止事項
- ユーザーの指示なしにGit操作しない
- 設計書・承認なしに新機能を実装しない
- Phase 1Bの機能をPhase 1Aで実装しない
- 既存のアーキテクチャを無断で変更しない
📏 Coding Standards
| 項目 | 制約 | 超過時の対応 |
|---|---|---|
| メソッド行数 | 最大20行 | プライベートメソッドに切り出し |
| クラス行数 | 最大150行 | 責務分割 |
| View行数 | 最大100行 | ViewComponentに分割 |
ポイント: 参照ドキュメント セクションで Kiro の仕様書を明示的に指定しています。
実験結果：良かった点
1. tasks.md に従って実装が進む
Claude Code が生成したレポートを見ると、タスク単位で着実に進んでいることが分かります：
# Session Report: 2025-12-25 (1st)
## Task 3: メモ種類別管理機能 - 完了
### 実装内容
- MemoRepository.swift（CRUD + 140文字バリデーション）
- MemoListViewModel.swift（種類別フィルタリング）
- AddMemoView.swift（文字数カウンター付き）
## 進捗状況
| Task | Status |
|------|--------|
| Task 1 | ✅ 完了 |
| Task 2 | ✅ 完了 |
| Task 3 | ✅ 完了 |
| Task 4 | ⏳ 未着手 |
## Next Action
### Task 4: タグ管理機能
tasks.md の構造（Task番号、サブタスク、対応Requirement）を理解し、順序通りに実装している様子が確認できました。
2. Property Test と design.md の連携
design.md で定義した Correctness Properties：
### Property 1: ブックマーク追加の一貫性
*For any* valid URL, when a user adds it as a bookmark,
the bookmark list should contain exactly one more item
than before the operation
**Validates: Requirements 1.1**
これが実際のテストコードに反映されていました：
func testBookmarkAdditionConsistency() {
property("Adding bookmark increases list size by one") <- forAll { (url: URL) in
let initialCount = bookmarkManager.getBookmarks().count
try! bookmarkManager.addBookmark(url: url)
let finalCount = bookmarkManager.getBookmarks().count
return finalCount == initialCount + 1
}
}
仕様書の番号体系とコードが一致しており、トレーサビリティが確保されています。
3. Kiro によるレビューが機能
Claude Code の実装を Kiro にレビューさせると、具体的な改善提案が返ってきました：
# Task6 Implementation Review by Kiro
## コード品質評価
| 項目 | 評価 |
|------|------|
| アーキテクチャ | ⭐⭐⭐⭐⭐ |
| テストカバレッジ | ⭐⭐⭐⭐⭐ |
## 改善提案
### 1. メニュー状態の永続化
**提案: メニュー開閉状態を記憶**
```swift
@AppStorage("sideMenuLastState") private var menuLastState = false
func loadMenuState() {
isSideMenuOpen = menuLastState
}
仕様策定者の視点でレビューし、コード例付きで改善提案を出してくれます。
実験結果：想定外だった点
1. 別プロジェクトとの仕様混同（重大な発見）
これは正直に書きます。
claude.ai のプロジェクト機能で「読書メモアプリ開発」のプロジェクトも並行して進めていたのですが、Webブックマーク管理と読書メモ管理の仕様を混同したコーディングが発生しました。
CLAUDE.md に「禁止事項」を書いていましたが、別プロジェクトの影響は防げませんでした。
教訓
- プロジェクトごとに明示的なスコープ宣言を追加すべき
- 「このプロジェクトは○○であり、△△ではない」を冒頭に記載
- 仕様駆動開発はコンテキスト汚染に弱い
2. requirements.md と design.md の境界
当初、私はこう理解していました：
- requirements.md = 要求定義書
- design.md = 要件定義書
しかし実際の design.md は：
## Components and Interfaces
protocol BlogManagerProtocol {
func addBookmark(url: URL) async throws -> ArticleBookmark
}
## Correctness Properties
Property 1: ブックマーク追加の一貫性
## 開発環境・ツール（Claude Code連携）
Swift Protocol を直接定義しているのは詳細設計レベルです。
結論: Kiro の design.md は「要件定義 + アーキテクチャ設計 + テスト設計 + 開発プロセス設計」のハイブリッド。従来のソフトウェア工学の文書体系と1:1対応しないと理解すべきでした。
実験2：既存プロジェクトへの Kiro 導入
新規プロジェクトでの実験に続き、デプロイ済みのWebシステムに Kiro を後から導入してみました。
導入プロセス
Step 1: プロジェクト理解
Kiro に以下を読み込ませました：
- 既存の要求定義書
- 基本設計情報
- 現在のフェーズ状態
元々 Claude Code だけで仕様駆動開発を進めていたので、フェーズ管理や仕様書の構造は整理されていました。これが土台になりました。
Step 2: 適応的な仕様書生成
新規プロジェクトでは requirements.md, design.md, tasks.md のフルセットを生成しましたが、既存プロジェクトでは違いました。
既存の仕様書体系を邪魔しない形で、追加機能ごとに仕様書を生成：
既存プロジェクト/
│
├── 🤖 AIメモリーファイル（セッション開始時に読み込む）
│ ├── KIRO.md ..................... Kiro用メモリー（役割・作業フロー）
│ └── CLAUDE.md ................... Claude Code用メモリー（役割・実装ガイド）
│
├── 📂 docs/
│ │
│ ├── 📂 handoff/ ................. AI間引き継ぎドキュメント
│ │ ├── README.md ............... 概要・使い方
│ │ ├── kiro_context.md ......... Kiro用詳細コンテキスト
│ │ ├── claude_context.md ....... Claude Code用詳細コンテキスト
│ │ └── conventions.md .......... 共通コーディング規約
│ │
│ ├── 📂 specifications/ .......... 仕様書（Kiroが作成・管理）
│ │ ├── spec.md ................. 総合仕様書
│ │ ├── project_spec.md ......... プロジェクト仕様
│ │ └── 📂 features/ ............ 機能仕様書
│ │ ├── README.md ........... 仕様書ガイド
│ │ ├── _TEMPLATE.md ........ テンプレート
│ │ └── phase4_*.md ......... 各機能仕様書
│ │
│ └── 📂 development/ ............. 開発管理（共同で更新）
│ ├── phase_plan_rails_8_1_1.md Phase計画書・進捗管理 ⭐
│ └── implementation_log.md ... 実装ログ
│
└── 📂 docs/（人間向け）
├── OPERATION_MANUAL.md ......... 運用マニュアル
└── QUICK_REFERENCE.md .......... クイックリファレンス
https://github.com/miyakawa2449/cms_ruby_public
この臨機応変な仕様書管理ができる仕組みに驚きました。
Step 3: 役割分担の確立
Kiro Claude Code
├── 要求定義 ├── 淡々と実装
├── 要件定義 ├── フェーズ管理
├── アーキテクチャ整理 → └── テスト実行
└── 基礎コード準備
人間（私）
├── Kiroの仕様書に目を通す
├── ユーザテスト結果のフィードバック
└── 作業を淡々とこなす（介入は最小限）
人間の役割の変化
| 新規プロジェクト | 既存プロジェクト | |
|---|---|---|
| 人間の役割 | 監督者 | 承認者 |
| 介入頻度 | 時々 | 最小限 |
| 主な作業 | 方向性指示 | 確認とフィードバック |
「Kiroが作る仕様書に目を通して作業を淡々とこなすだけになりました」
これは理想的な状態に近いと感じています。
新規 vs 既存：導入パターンの違い
【新規プロジェクト】
Phase 0: Kiro で仕様書フルセット生成
↓
Phase 1: Claude Code が tasks.md に従い実装
↓
Phase N: Kiro レビュー → Claude Code 修正
【既存プロジェクト】
既存状態: Claude Code で仕様駆動開発中
↓
Kiro導入: プロジェクト理解・フェーズ把握
↓
運用: Kiro が追加機能の仕様書を生成
↓
Claude Code が仕様に従い実装
成功要因:
- 事前の仕様駆動開発習慣（Claude Code 単体で既に仕様書中心だった）
- Kiro の適応力（既存構造を壊さない）
- 役割分担の明確化
開発者としての所感
AI-to-AI サイクルの評価
Kiro（仕様策定）→ Claude Code（実装）→ Kiro（レビュー）→ Claude Code（修正）
↑ ↓
└─────────────────────────────────────────────────────────────┘
このサイクルは一定程度機能します。ただし：
- Kiro レビューは「仕様との整合性」を見れる
- しかし「仕様自体の妥当性」は人間が判断する必要がある
- コンテキスト汚染（別プロジェクト混同）は人間が気づく必要がある
結論: AI-to-AI サイクルは「監督付き」が現実解。ただし習熟すると「承認者」レベルまで人間の介入を減らせる。
仕様駆動開発の評価
| 観点 | 評価 | コメント |
|---|---|---|
| 仕様書の品質 | ⭐⭐⭐⭐ | Kiroの生成能力は高い |
| 実装の仕様準拠 | ⭐⭐⭐⭐ | tasks.md順守は確認できた |
| レビューの有効性 | ⭐⭐⭐ | 形式的チェックは機能、本質的判断は人間 |
| コンテキスト管理 | ⭐⭐ | 別プロジェクト混同は要対策 |
| 全体効率 | ⭐⭐⭐⭐ | 1週間でMVP完成は成功 |
まとめ
Kiro + Claude Code の併用開発を試した結果：
うまくいったこと
- Claude Code は tasks.md に従って淡々と実装を進める
- Property Test と design.md の連携でトレーサビリティ確保
- Kiro レビューは仕様整合性のチェックに有効
- 既存プロジェクトへの導入も、既存構造を壊さず可能
課題
- 別プロジェクトとのコンテキスト混同は CLAUDE.md では防げない
- requirements.md / design.md の位置づけは従来の文書体系と異なる
- 仕様自体の妥当性判断は人間が必要
人間の役割
- 新規プロジェクト: 監督者
- 既存プロジェクト（習熟後）: 承認者
仕様駆動開発は有効だが万能ではない。人間は「監督者」または「承認者」として関与し続ける必要がありますが、その介入レベルは確実に下がります。
「AIがAIをレビューする世界」は、もう始まっています。
付録：設定ファイル一覧
Kiro 側
| ファイル | 役割 |
|---|---|
| .kiro/specs/*/requirements.md | 要件定義（EARS形式） |
| .kiro/specs/*/design.md | 設計書 + Claude Code連携 |
| .kiro/specs/*/tasks.md | タスク計画 |
| .kiro/specs/*/usecase.md | ユースケース |
| .kiro/specs/*/screen-design.md | 画面設計 |
Claude Code 側
| ファイル | 役割 |
|---|---|
| CLAUDE.md | プロジェクトルール、Kiro参照設定 |
| reports/YYYY-MM-DD/*.md | 日次レポート |
| .claude/skills/*/SKILL.md | Agent Skills |
この記事が、Kiro + Claude Code 併用開発を検討している方の参考になれば幸いです。