11
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【テンプレ配布】Kiroの仕様駆動開発をClaude Codeで再現する方法!ドキュメント3点セットで実現

Last updated at Posted at 2025-07-30

こんにちは、とまだです。

Claude Codeを使って開発を進めていると、アイデアを形にしやすくていいですよね。

ですが「これって仕様書を最初に作った方が効率的なのでは?」と思ったことはありませんか?

私も最初は思いつきでClaude Codeに指示を出していました。
しかし、それだと途中で方向性がブレたり、重要な機能を忘れたりすることが多かったのです。

そして最近、AWSがリリースした「Kiro」というAI IDEが話題になっています。

このツールは「仕様駆動開発」という手法を採用していて、開発前に自動で仕様書を作成してくれるのです。

今回は、Kiroのアプローチを参考にしながら、Claude Code で Kiro のような仕様駆動開発を実現してみました。

テンプレートリポジトリも配布しているので、どの技術スタックでも、誰でもスタートできるようにしてます。

なぜClaude Codeで事前仕様書が必要なのか

「AIに任せるのに、なんで仕様書なんて必要なのか?」

そう思うかもしれません。

ですが、改めて考えてみてください。料理を作る時、レシピなしで「美味しい料理を作って」と言われても困りますよね。それと同じで、Claude Codeも明確な指示があった方が効率的に動けるのです。

実際に、仕様書なしでアプリを作ろうとすると、こんな問題が起きがちです。

  • 設計の一貫性が保てない
  • 実装が競合してしまう
  • 完成後の動作確認中に追加機能の必要性に気づく

そこで Kiro というエディタでは、最初に仕様を固めることでこの問題を解決しています。

Kiroスタイルの仕様駆動開発をClaude Codeで実現

私は普段から Claude Code をめちゃめちゃ使っているので、できれば Kiro の考え方だけ取り入れた Claude Code 開発をしたいと思いました。

そして、Claude Code は既存のワークフローに柔軟に適応できるツールなので、Kiroのアプローチを取り入れることで、両方の良さを活かすことにしました。

今回用意したのは、kiro_style_claude_codeというテンプレートです。

このテンプレートは、Kiroエディタの「仕様駆動開発」のエッセンスをClaude Code用に再現したものです。

前提知識として、Kiroでは以下の3つのドキュメントを自動生成します。

  • requirements.md - ユーザーストーリーと受け入れ基準
  • design.md - 技術アーキテクチャとコンポーネント設計
  • tasks.md - 具体的な開発手順

このテンプレートを使えば、専用のコマンドで同じような仕様書を自動生成できます。

言うなれば、経験豊富なプロジェクトマネージャーが横についてくれているような感覚です。

kiro_style_claude_codeテンプレートの仕組み

シンプルだけど強力な3ファイル構成

このテンプレートで大事にしたところは、そのシンプルさです。

Claude Codeが理解すべき仕様は、たった3つのファイルに集約されています。

  1. requirements.md - 「何を作るか」を定義
  2. design.md - 「どう作るか」を設計
  3. tasks.md - 「作業手順」を管理

これだけで、Claude Codeが迷わず実装を進められるようになります。

実際のディレクトリ構成もシンプルです。

.
├── .claude/
│   ├── CLAUDE.md          # プロジェクトルール
│   └── commands/
│       └── kiro.md        # 仕様生成
├── specs/
│   ├── requirements.md    # 要件定義
│   ├── design.md          # 設計文書
│   └── tasks.md           # タスク一覧

もし既存のプロジェクトに組み込むなら、上記ファイルをコピーしてあげるだけでOKです。

専用コマンドで開発フローを自動化

テンプレートには、Kiroスタイルの開発を支援する専用コマンドが含まれています。

/kiro コマンド

このコマンドを実行すると、Claude Codeが自動的に3つの仕様ファイルを生成します。

例えば、以下のような使い方です。

/kiro TODOアプリに優先度機能を追加

たったこれだけで、Claude Codeが以下のような構造化された要件定義を作成してくれます。

### ストーリー1: TODOの作成

**As a** ユーザー
**I want** 新しいTODOタスクを作成できる
**So that** やるべきことを記録できる

**受け入れ基準:**
- [ ] タスクのタイトルを入力できる
- [ ] 作成日時が自動的に記録される

なぜこのテンプレートが効果的なのか

従来のClaude Code開発では、場当たり的に指示を出しがちでした。

一方、このテンプレートを使えば、Claude Codeが参照すべき仕様が明文化されるので以下のような恩恵を受けられます。

  • Claude Codeが一貫性のあるコードを生成できる
  • 実装の途中で方向性がブレない
  • 複雑な機能も段階的に実装できる

特に効果的なのは、Claude Codeが「次に何を実装すればいいか」を常に把握できることです。

tasks.mdを参照することで、Claude Codeはこんな感じで進捗を管理しながら実装を進めます。

たとえば以下のようなタスク表が作られます。

## フェーズ1: 基盤構築

- [x] **Task 1**: プロジェクトセットアップ
- [x] **Task 2**: 開発環境の設定

## フェーズ2: コア機能実装

- [ ] **Task 3**: TODOの作成機能
- [ ] **Task 4**: TODOの一覧表示

## 進捗追跡
- 完了: 2/6
- 進行中: 1
- 未着手: 3

Claude Codeは自動的にタスクの完了をチェックし、次のタスクに移っていきます。

では、実際に何かアプリを作りながら開発の流れを見ていきましょう。

Kiroスタイル テンプレートのセットアップ

まず、GitHubからテンプレートをコピーします。

# テンプレートから新しいリポジトリを作成
# GitHubで「Use this template」をクリック

今回はゼロから React アプリを作ってみるので、このリポジトリの中に React プロジェクトを生成します。

npm create vite@latest todo-app

Kiroスタイル用のファイルをコピーします。

# Kiroスタイル用ファイルをコピー
cp -r example-project/ todo-app/
cd todo-app/

なお、ご自身のフォルダに持ってくる場合は以下ファイルをそのままコピーするだけでOKです。

CLAUDE.md は各々で作成済みだと思いますので、中身だけを貼り付けていただければと思います。

├── .claude/
│   ├── CLAUDE.md          # プロジェクトルール
│   └── commands/
│       ├── kiro.md        # 仕様初期化
│       └── sync-spec.md   # 仕様同期
├── specs/
│   ├── requirements.md    # 要件定義
│   ├── design.md          # 設計文書
│   └── tasks.md           # タスク一覧

KiroスタイルでTodoアプリを作ってみよう

では、React の空プロジェクトから Todo アプリを作ってみましょう。

要件定義書(requirements.md)を作成

/kiro コマンド実行

まずはターミナルでClaude Codeを起動します。

claude

そして、以下の専用コマンドを入力します。

/kiro に続けて半角スペースを空け、実現してほしい内容について文章を続けます。

/kiro TODOアプリの作成

こちらは、Claude Code で作れるオリジナルコマンドです。わかりやすく kiro と名づけました。

すると、Claude Codeが勝手に要件定義から始めてくれます。

ここでは TODOアプリの作成 という目的を達成するため、要件定義からスタートしてくれます。

こんな感じでスタートします。
要件定義書、設計書、タスクに分かれていますね。

/kiro is running… todoアプリ作成

⏺ TODOアプリ作成の仕様を順次作成していきます。まず要件定義から始めます。

⏺ Update Todos
  ⎿ ☐ specs/requirements.md -
      ユーザーストーリーと受け入れ基準を作成
    ☐ specs/design.md -
      システムアーキテクチャと技術スタックを定義
    ☐ specs/tasks.md -
      実装タスクの一覧と依存関係を整理

生成された要件定義書をレビュー&承認する

少し待つと、以下のような結果が返ってきました。

⏺ 要件定義を作成しました。これを確認してから、設計とタスクの仕様を作成しま
  す。

  要件の概要:

  - 7つのユーザーストーリー: タスクの作成、一覧表示、完了切り替え、編集、
  削除、フィルタリング、データ永続化
  - 非機能要件: パフォーマンス、使いやすさ、ブラウザサポート

  要件に問題がなければ、次に設計仕様(design.md)を作成しますが、よろしい
  でしょうか?

実際に生成された要件定義書を見てみましょう。結構モリモリです。

specs/requirements.md

# TODOアプリ要件定義

## プロジェクト概要
シンプルで使いやすいTODOアプリケーションを作成する。ユーザーが日々のタスクを効率的に管理できるWebアプリケーション。

## ユーザーストーリー

### 1. タスクの作成
**As a** ユーザー
**I want** 新しいタスクを作成できる
**So that** やるべきことを記録できる

**受け入れ基準:**
- [ ] タスクのタイトルを入力できる
- [ ] Enterキーまたは追加ボタンでタスクを作成できる
- [ ] 空のタスクは作成できない
- [ ] 作成したタスクはリストに即座に表示される

### 2. タスクの一覧表示
**As a** ユーザー
**I want** すべてのタスクを一覧で見る
**So that** 何をすべきか把握できる

**受け入れ基準:**
- [ ] すべてのタスクがリスト形式で表示される
- [ ] 各タスクにはタイトルが表示される
- [ ] 完了/未完了の状態が視覚的に区別できる
- [ ] タスクがない場合は適切なメッセージが表示される

### 3. タスクの完了/未完了の切り替え
**As a** ユーザー
**I want** タスクの完了状態を切り替える
**So that** 進捗を管理できる

**受け入れ基準:**
- [ ] チェックボックスまたはクリックで状態を切り替えられる
- [ ] 完了したタスクは打ち消し線が表示される
- [ ] 状態の変更は即座に反映される
- [ ] 完了したタスクも一覧に残る

### 4. タスクの編集
**As a** ユーザー
**I want** 既存のタスクを編集する
**So that** 内容を更新できる

**受け入れ基準:**
- [ ] タスクをクリックまたは編集ボタンで編集モードに入れる
- [ ] タイトルを直接編集できる
- [ ] Enterキーまたは保存ボタンで変更を保存できる
- [ ] Escキーでキャンセルできる
- [ ] 空の内容には更新できない

### 5. タスクの削除
**As a** ユーザー
**I want** 不要なタスクを削除する
**So that** リストを整理できる

**受け入れ基準:**
- [ ] 各タスクに削除ボタンがある
- [ ] 削除ボタンをクリックすると確認ダイアログが表示される
- [ ] 確認後、タスクがリストから削除される
- [ ] 削除は取り消しできない

### 6. タスクのフィルタリング
**As a** ユーザー
**I want** 完了/未完了でタスクをフィルタリングする
**So that** 必要なタスクだけを見ることができる

**受け入れ基準:**
- [ ] 「すべて」「未完了」「完了済み」のフィルターオプションがある
- [ ] フィルターの切り替えが即座に反映される
- [ ] 現在のフィルター状態が視覚的にわかる
- [ ] フィルター適用中もタスクの操作が可能

### 7. データの永続化
**As a** ユーザー
**I want** タスクがブラウザを閉じても保存される
**So that** データを失わない

**受け入れ基準:**
- [ ] ブラウザのローカルストレージにデータが保存される
- [ ] ページをリロードしてもタスクが復元される
- [ ] タスクの作成/編集/削除が自動的に保存される
- [ ] ストレージエラー時は適切なエラーメッセージが表示される

## 非機能要件

- **パフォーマンス**: タスクの追加/編集/削除は100ms以内に完了する。1000件のタスクでも快適に動作する
- **使いやすさ**: レスポンシブデザインでモバイルでも使いやすい。キーボードショートカットをサポート。アクセシビリティに配慮(WAI-ARIA対応)
- **ブラウザサポート**: Chrome(最新版)、Firefox(最新版)、Safari(最新版)、Edge(最新版)

こんな感じで、ユーザー視点での機能が明確に定義されていきます。

技術的な要件というよりはちゃんと要件定義書らしく、機能要件としてまとまっていますね。

地味に、ローカルストレージを用いた データの永続化 まで考慮されていたのはいいですね。

要件定義書を承認する

作ってもらった要件定義書で特に問題なかったので、承認してみましょう。

あくまで人間が仕様の観点でチェックしながら進めるのがポイントです。

> ok

ここで入力するのは「承認」でも「OK」でもなんでも大丈夫です。

設計書 (design.md) とタスク(task.md)を作成

では、次は設計書とタスクを作成してもらいましょう。
ここは一気にやってくれるかと思います。

とは言っても、先ほど承認した時点ですでに作成がスタートしているはずです。

⏺ Update Todos
  ⎿  ☒ specs/requirements.md - ユーザーストーリーと受け入れ基準を作成
     ☐ specs/design.md - システムアーキテクチャと技術スタックを定義
     ☐ specs/tasks.md - 実装タスクの一覧と依存関係を整理

しばらく待つと、以下のように完了報告されます。

⏺ TODOアプリの仕様ファイルをすべて作成しました:

  📁 作成した仕様ファイル

  1. specs/requirements.md - 7つのユーザーストーリーと受け入れ基準
  2. specs/design.md - React/TypeScript/Viteを使用したSPAアーキテクチャ
  3. specs/tasks.md - 20個の実装タスクを5つのフェーズに分割

  これで仕様定義が完了しました。実装を開始する準備ができています。

設計ファイルを見てみる

実際に作成された設計ファイルがこちらです。

型定義やファイル構成など、処理フローにデザインなど、詳細に作られていることが分かります。

ここまで細かく書かれていれば、ぶれることは無さそうです。

# TODOアプリ設計文書

## アーキテクチャ概要

シングルページアプリケーション(SPA)として実装。フロントエンドのみで完結し、データはブラウザのローカルストレージに保存する。

## 技術スタック

- **言語**: TypeScript 5.x
- **フレームワーク**: React 18.x
- **ビルドツール**: Vite 5.x
- **スタイリング**: CSS Modules
- **状態管理**: React Context API + useReducer
- **テスト**: Vitest + React Testing Library
- **リンター**: ESLint + Prettier

## コンポーネント構成

```
src/
├── components/
│   ├── App.tsx                 # ルートコンポーネント
│   ├── TodoInput.tsx           # タスク入力フォーム
│   ├── TodoList.tsx            # タスク一覧表示
│   ├── TodoItem.tsx            # 個別タスクコンポーネント
│   ├── TodoFilter.tsx          # フィルターボタン
│   └── EditModal.tsx           # 編集用モーダル(インライン編集の場合は不要)
├── contexts/
│   └── TodoContext.tsx         # TODOの状態管理
├── hooks/
│   ├── useTodos.ts             # TODO操作のカスタムフック
│   └── useLocalStorage.ts      # ローカルストレージ同期フック
├── types/
│   └── todo.ts                 # 型定義
└── utils/
    └── storage.ts              # ローカルストレージ操作

```

## データフロー

1. **タスク作成**: TodoInput → useTodos → TodoContext → LocalStorage
2. **状態更新**: TodoItem → useTodos → TodoContext → LocalStorage
3. **フィルタリング**: TodoFilter → TodoContext → TodoList(表示の更新)
4. **初期化**: App起動時 → LocalStorage → TodoContext → 各コンポーネント

## 型定義

```typescript
// types/todo.ts
interface Todo {
  id: string;           // UUID
  title: string;        // タスクのタイトル
  completed: boolean;   // 完了状態
  createdAt: Date;      // 作成日時
  updatedAt: Date;      // 更新日時
}

type FilterType = 'all' | 'active' | 'completed';

interface TodoState {
  todos: Todo[];
  filter: FilterType;
}
```

## 状態管理設計

### TodoContext

```typescript
interface TodoContextValue {
  todos: Todo[];
  filter: FilterType;
  addTodo: (title: string) => void;
  updateTodo: (id: string, title: string) => void;
  toggleTodo: (id: string) => void;
  deleteTodo: (id: string) => void;
  setFilter: (filter: FilterType) => void;
}
```

### Reducer Actions

```typescript
type TodoAction =
  | { type: 'ADD_TODO'; payload: { title: string } }
  | { type: 'UPDATE_TODO'; payload: { id: string; title: string } }
  | { type: 'TOGGLE_TODO'; payload: { id: string } }
  | { type: 'DELETE_TODO'; payload: { id: string } }
  | { type: 'SET_FILTER'; payload: { filter: FilterType } }
  | { type: 'LOAD_TODOS'; payload: { todos: Todo[] } };
```

## ローカルストレージ設計

- **キー**: `todo-app-data`
- **形式**: JSON文字列
- **保存タイミング**: 全ての状態変更時
- **エラーハンドリング**: try-catchで包み、エラー時はコンソールに出力

## UI/UX設計

### レイアウト

```
┌─────────────────────────────────────┐
│          TODOアプリ                  │
├─────────────────────────────────────┤
│  [          入力フィールド        ]  │
│  [追加]                             │
├─────────────────────────────────────┤
│  [すべて] [未完了] [完了済み]       │
├─────────────────────────────────────┤
│  □ タスク1              [編集][削除] │
│  ☑ タスク2              [編集][削除] │
│  □ タスク3              [編集][削除] │
└─────────────────────────────────────┘
```

### スタイリング方針

- モバイルファースト設計
- 最小幅: 320px
- 最大幅: 800px(中央寄せ)
- カラーパレット:
  - プライマリ: #007bff
  - 完了: #6c757d
  - 削除: #dc3545
  - 背景: #f8f9fa

## パフォーマンス最適化

- React.memoを使用してコンポーネントの再レンダリングを最小化
- useCallbackでイベントハンドラをメモ化
- 大量のタスクに対応するため、仮想スクロールの実装を検討(1000件以上の場合)

## アクセシビリティ

- すべてのインタラクティブ要素にaria-label
- キーボードナビゲーション対応
- フォーカス管理
- スクリーンリーダー対応

タスクファイルを見てみる

同様にタスクファイルの方も見てみましょう。

いくつかのフェーズに分かれており、依存関係も示されているので、順番に迷わず進めることができるようになっています。

# TODOアプリ実装タスク一覧

## フェーズ1: 基盤構築

- [ ] **Task 1**: プロジェクトセットアップ
  - Viteでプロジェクトを初期化
  - TypeScript設定
  - 基本的なディレクトリ構造の作成
  - 依存関係: なし

- [ ] **Task 2**: 開発環境の設定
  - ESLint、Prettierの設定
  - CSS Modulesの設定
  - package.jsonのスクリプト設定
  - 依存関係: Task 1

- [ ] **Task 3**: 型定義の作成
  - types/todo.tsの作成
  - 基本的な型インターフェースの定義
  - 依存関係: Task 1

## フェーズ2: コア機能実装

- [ ] **Task 4**: ローカルストレージユーティリティの実装
  - utils/storage.tsの作成
  - 保存・読み込み・エラーハンドリング
  - 依存関係: Task 3

- [ ] **Task 5**: TodoContextとReducerの実装
  - contexts/TodoContext.tsxの作成
  - Reducerロジックの実装
  - 依存関係: Task 3, Task 4

- [ ] **Task 6**: カスタムフックの実装
  - hooks/useTodos.tsの作成
  - hooks/useLocalStorage.tsの作成
  - 依存関係: Task 5

- [ ] **Task 7**: TodoInputコンポーネントの実装
  - components/TodoInput.tsxの作成
  - 入力フォームとバリデーション
  - 依存関係: Task 6

- [ ] **Task 8**: TodoItemコンポーネントの実装
  - components/TodoItem.tsxの作成
  - チェックボックス、編集、削除機能
  - 依存関係: Task 6

- [ ] **Task 9**: TodoListコンポーネントの実装
  - components/TodoList.tsxの作成
  - タスク一覧表示とフィルタリング
  - 依存関係: Task 8

- [ ] **Task 10**: TodoFilterコンポーネントの実装
  - components/TodoFilter.tsxの作成
  - フィルターボタンの実装
  - 依存関係: Task 6

- [ ] **Task 11**: Appコンポーネントの実装
  - components/App.tsxの作成
  - 全体レイアウトとContextProvider
  - 依存関係: Task 7, Task 9, Task 10

## フェーズ3: スタイリングとUX

- [ ] **Task 12**: 基本スタイルの実装
  - CSS Modulesファイルの作成
  - レスポンシブデザインの実装
  - 依存関係: Task 11

- [ ] **Task 13**: アニメーションとトランジションの追加
  - タスク追加・削除時のアニメーション
  - 状態変更時のトランジション
  - 依存関係: Task 12

- [ ] **Task 14**: キーボードショートカットの実装
  - Enter/Escキーのハンドリング
  - フォーカス管理
  - 依存関係: Task 11

## フェーズ4: テストと品質保証

- [ ] **Task 15**: ユニットテストの作成
  - コンポーネントテスト
  - カスタムフックのテスト
  - Reducerのテスト
  - 依存関係: Task 11

- [ ] **Task 16**: 統合テストの実施
  - ユーザーフロー全体のテスト
  - ローカルストレージとの連携テスト
  - 依存関係: Task 15

- [ ] **Task 17**: アクセシビリティの実装
  - ARIA属性の追加
  - スクリーンリーダー対応
  - 依存関係: Task 14

## フェーズ5: 最適化とデプロイ準備

- [ ] **Task 18**: パフォーマンス最適化
  - React.memoの適用
  - useCallbackの適用
  - 大量データ対応の検討
  - 依存関係: Task 11

- [ ] **Task 19**: ビルド設定の最適化
  - Viteのビルド設定
  - 本番環境用の最適化
  - 依存関係: Task 18

- [ ] **Task 20**: ドキュメント作成
  - README.mdの作成
  - 使用方法とセットアップ手順
  - 依存関係: Task 19

## 進捗追跡

- 完了: 0/20
- 進行中: 0
- 未着手: 20

## 実装順序の推奨

1. フェーズ1を順番に実施(基盤が必要)
2. フェーズ2はTask 4-6を先に実施(状態管理の基盤)
3. フェーズ2のTask 7-11は並行実施可能
4. フェーズ3-5は順次実施

タスクを修正してもらう

今回はすでに React プロジェクトはセットアップ済みの状態からスタートしました。

そのため、上記の **Task 1**: プロジェクトセットアップ の部分は不要となります。

こう言った場合は、手動でタスクファイルを修正するのではなく、Claude Code に指示を出して修正した方が安定するかと思います。

> Reactプロジェクトをセットアップ済みなので Task1 は不要です

/init コマンドを実行して CLAUDE.md を更新しておく

デフォルトの CLAUDE.md には Kiro スタイルに関する記述しかありません。

このタイミングで Claude Code 内で /init コマンドを実行することで、プロジェクトの内容を反映させておくといいでしょう。

> /init

おそらく specs フォルダ内の仕様ドキュメント3点セットの内容も反映してくれるはずです。

Todoアプリの開発を進めてもらう

では、実際に開発をスタートしてみます。

ぶれないように specs/tasks.md に沿って開発を進めて と伝えるのがおすすめです。

> specs/tasks.md に沿って開発を進めて

あとはタスクファイルに従って自動的に開発が進みます

実際に完成したアプリの画面

基本的なTODOアプリが完成しました。

一通り触ってみた限り、事前の要件定義通りに作られています

image.png

見た目もシンプルで使いやすく、何よりバグなく動作しているのが素晴らしいです。

ちゃんと作られることは正直想定内ですが、完成系を事前にイメージできたので安心感がありました。

まとめ:仕様駆動開発で開発効率を最大化しよう

Claude Codeを使った開発で、事前に仕様書を作成することの重要性をお伝えしました。

そして、私が用意した kiro_style_claude_code テンプレート(のコマンド)を使えば、この仕様書作成がわずか数分で完了します。

特に以下のような場合は、ぜひこの方法を試してみてください。

  • 中規模以上のアプリケーションを作る時
  • チームで開発する時
  • 後から機能追加の可能性がある時

最初の数分の投資で、開発時間を大幅に短縮できるはずです。

仕様駆動開発は単なるツールの使い方ではなく、開発手法の採用です。
この考え方を身につければ、AI駆動開発の質が格段に向上します。

ぜひ、次のプロジェクトで試してみてください!!

カスタマイズ案や、使ってみた話も大歓迎でございます。

他にも Claude Code や AI 駆動開発の記事を書いていますので、よかったらこちらもご覧ください。

ちょっと宣伝: Claude Code などの Udemy コース作ってます

Claude Code での Vibe Coding や Next.js、Ruby on Rails などの Udemy コースを開講しており、ありがたいことに複数のベストセラーをいただいてます。

image.png

自社サイトでは最低価格で受講できるクーポンも配布しているので、よかったら見てやってください。

ご意見や、新講座の要望も大歓迎です!

11
16
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
11
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?