はじめに
お客様から「シンプルなECサイトを作りたい」という相談を受けたとします。
最初にやるのはヒアリングです。「扱う商品は何か」「ターゲットは誰か」「決済はどうするか」「管理画面は必要か」などを確認しながら、要望を具体化していきます。
ただ、ヒアリングで出てきた内容をそのまま実装に落とせるわけではありません。ユーザーストーリーとして整理したり、例外ケース（エッジケース）を洗い出したり、受け入れ基準として言語化したり……ここが意外と時間がかかります。経験や勘に寄る部分も出やすく、担当者によって粒度がブレるのも悩みどころです。
そこで本記事では Kiro の Spec-Driven Development（仕様駆動開発） を使い、「ヒアリング結果 → 構造化された仕様書」までの変換をどう進めるかを紹介します。Kiro に要件を入力すると、Requirements（要求仕様）→ Design（技術設計）→ Tasks（実装タスク） の3フェーズに分けて成果物を生成できます。人手だと抜けやすいエッジケースまで提案されるため、レビューやお客様との認識合わせにも使いやすいのが特徴です。
題材としては、ゼロからECサイトを新規構築するケースを扱います。実際の操作手順とスクリーンショットを交えながら、Kiroで要件を仕様に落としていく流れを解説します。
対象読者: AWSで生成AIを活用した開発に興味があるエンジニア、PM、テックリード
Kiro とは
Kiro は AWS が提供するエージェント型 AI 開発環境だ。VS Code ベースの IDE として動作し、通常のコーディング支援（Vibe モード）に加えて、Spec モードという構造化された開発ワークフローを提供する。
公式サイト: https://kiro.dev/
Kiro には以下の主要機能がある。
- Spec-Driven Development: 要件→設計→タスクの3フェーズワークフロー
- Agent Hooks: ファイル変更をトリガーにバックグラウンドで自動実行されるエージェント
- Steering Files: プロジェクトのコンテキスト（技術スタック、コーディング規約等）をエージェントに伝える設定ファイル
- Kiro CLI: ターミナルから同じエージェント機能を利用可能
本記事では、この中の Spec-Driven Development に焦点を当てる。
Spec-Driven Development の3フェーズ
Kiro の Spec-Driven Development は、以下の3フェーズで構成される。各フェーズの成果物はマークダウンファイルとしてリポジトリの .kiro/specs/ ディレクトリに保存され、バージョン管理される。
Kiro IDE では、フェーズの進行状況がエディタ上部のパンくずリストに 「1 Requirements > 2 Design > 3 Task list」 として表示され、現在どのフェーズにいるかが一目で分かる。
フェーズ1: Requirements（要求仕様）
自然言語の要望をもとに、ユーザーストーリーと受け入れ基準を構造化した requirements.md を生成する。
受け入れ基準は EARS（Easy Approach to Requirements Syntax）記法 で記述される。EARS 記法は以下の形式をとる。
WHEN [条件/イベント] THE SYSTEM SHALL [期待される振る舞い]
例:
WHEN ユーザーが無効なデータでフォームを送信した場合
THE SYSTEM SHALL 関連するフィールドの横にバリデーションエラーを表示する
フェーズ2: Design（技術設計）
Requirements をもとに、技術アーキテクチャ、シーケンス図、データモデル、API 設計 などを含む design.md を生成する。新規プロジェクトの場合、Kiro はゼロからアーキテクチャを設計する。
フェーズ3: Tasks（実装タスク）
Design をもとに、依存関係を考慮して順序付けされた 実装タスクのリスト を tasks.md として生成する。各タスクは Requirements のどの要件に対応するかがトレース可能になっている。
実践: ECサイトをゼロから Spec で定義する
ここからは、実際に Kiro を使って EC サイトの新規構築プロジェクトの仕様書を生成する手順を示す。
前提条件
- Kiro IDE がインストール済み（https://kiro.dev/ からダウンロード）
- Google、GitHub、Builder ID、または AWS SSO で認証済み
- 空のプロジェクトフォルダを Kiro で開いている
補足: Kiro は AWS アカウントが必須ではない。認証には Google アカウントや GitHub アカウントも使用できる。
手順1: Steering Files でプロジェクトの方向性を決める!
新規プロジェクトでは、最初に Steering Files を設定することが重要だ。Steering Files はプロジェクトの .kiro/steering/ ディレクトリに配置するマークダウンファイルで、Kiro にプロジェクト固有のコンテキストを伝える。
Kiro を起動すると、Vibe（チャット型）と Spec（仕様駆動型）の2つのモードが表示される。
Steering Files の生成にはチャットベースの操作が必要なため、まず Vibe モードを選択し、以下のように依頼する。
このプロジェクトのステアリングファイルを生成してください。
以下の情報をもとにしてください。
- プロダクト: シンプルなECサイト（日本国内向け）
- 技術スタック: TypeScript, Next.js (App Router), AWS (Lambda, DynamoDB, API Gateway, S3, Cognito)
- インフラ: AWS CDK (TypeScript) で IaC 管理
- テスト: Jest (ユニット), pytest + Nova Act (E2E)
- コーディング規約: ESLint + Prettier, 関数コンポーネント + Hooks, サーバーコンポーネント優先
Kiro はプロジェクトの情報を分析し、.kiro/steering/ ディレクトリに Steering Files を自動生成する。今回の実行では、project-standards.md というファイルに以下の情報がまとめて生成された。
| 含まれる内容 | 説明 |
|---|---|
| プロダクト概要 | ECサイトの概要、ターゲットユーザー、主要機能 |
| 技術スタック | TypeScript, Next.js, AWS サービス、使用フレームワーク |
| コーディング規約 | ESLint/Prettier、関数コンポーネント、型安全性 |
| ディレクトリ構造 | 推奨されるディレクトリ構成 |
| テスト方針 | Jest、pytest + Nova Act |
| セキュリティ・パフォーマンス | ガイドライン |
補足: Steering Files の生成パターンは Kiro のバージョンや入力内容によって異なる場合がある。
product.md、structure.md、tech.mdのように複数ファイルに分割されることもあれば、今回のように1ファイルにまとめて生成されることもある。いずれの場合も、inclusion: alwaysが設定されるため、すべての会話で自動的に参照される。
Steering Files を先に設定しておくことで、後続の Spec 生成の品質が大きく向上する。
手順2: Spec ワークフローの開始
Steering Files の設定が完了したら、新しいセッションを開き、Spec モードを選択する。
Spec モードは「Plan first, then build（まず計画、それから構築）」というコンセプトで、要件と設計を先に固めてからコーディングに入るワークフローだ。
プロンプトには、お客様へのヒアリングで整理した要件を入力する。ここでは、ヒアリングの結果、以下の要件が確定したものとする。
シンプルなECサイトをゼロから構築する。お客様へのヒアリングで確定した要件は以下のとおり。
1. ユーザー認証（サインアップ、ログイン、パスワードリセット）
2. 商品一覧の表示（カテゴリ別、検索、ソート）
3. 商品詳細ページ（画像、説明、価格、在庫状況）
4. カート機能（追加、数量変更、削除）
5. 注文機能（配送先入力、注文確定、注文確認メール）
6. 注文履歴の確認（一覧、詳細、配送ステータス追跡）
7. 管理者向け機能（商品管理、注文管理、在庫管理）
対象は日本国内の個人ユーザー。決済は外部決済サービス（Stripe）と連携する想定。
すると、Kiro は入力された要件を分析し、以下のように返答した。
ECサイトの要件を確認しました。これは大規模なプロジェクトなので、段階的に構築していくのが良いでしょう。
まず最初の機能として「ユーザー認証」のspecを作成することをお勧めします。これは他の機能の基盤となる重要な部分です。
Kiro 自身が機能ドメインごとの Spec 分割を提案してきた。 これは後述する「Spec 分割戦略」の考え方と一致しており、大規模プロジェクトでは Kiro 側でも分割アプローチを推奨していることが分かる。Kiro の提案に従い、まずユーザー認証機能の Spec から作成を進めた。
手順3: Requirements の生成とレビュー
Kiro はユーザー認証機能に関する requirements.md を自動生成した。以下は生成された内容のイメージだ。
エディタ上部には 「1 Requirements > 2 Design > 3 Task list」 のフェーズ表示があり、現在 Requirements フェーズにいることが分かる。生成された requirements.md には、以下の10個の要件がユーザーストーリーと受け入れ基準のセットとして展開されていた。
# 要件定義書：ユーザー認証機能
## 要件1：新規ユーザー登録
**ユーザーストーリー:** ユーザーとして、アカウントを作成したい。
そうすることで、ECサイトの機能を利用できるようになる。
### 受入基準
1. WHEN ユーザーが有効なメールアドレス、パスワード、氏名を入力して
登録ボタンをクリックした場合、
THEN 認証システムは新しいユーザーアカウントを作成する
2. WHEN ユーザーアカウントが作成された場合、
THEN 認証システムは入力されたメールアドレスに検証コードを送信する
3. WHEN ユーザーが既に登録済みのメールアドレスで登録を試みた場合、
THEN 認証システムは登録を拒否し、適切なエラーメッセージを表示する
...
## 要件2：パスワード要件
## 要件3：ユーザーログイン
## 要件4：パスワードリセット
## 要件5：セッション管理
## 要件6：入力検証
## 要件7：セキュリティ
## 要件8：エラーハンドリング
## 要件9：ユーザーインターフェース
## 要件10：AWS Cognito統合
入力したプロンプトでは「サインアップ、ログイン、パスワードリセット」の3つだけを指定したが、Kiro は 10個の要件・50の受入基準 に自動展開した。特に注目すべきは、以下のようなエッジケースが AI によって自動的に洗い出された点だ。
- ログイン5回失敗でアカウントをロック（要件3）── セキュリティ上の考慮
- 存在しないメールアドレスでのパスワードリセット要求にも成功メッセージを返す（要件4）── メールアドレスの存在を攻撃者に知らせない
- 検証コードの30分有効期限（要件4）── 時間ベースのセキュリティ
- セッションの60分維持とリフレッシュトークンの30日有効期限（要件5）── UX とセキュリティのバランス
- すべてのエラーメッセージを日本語で表示（要件8）── ローカライゼーション
ポイント: Kiro はヒアリングで得た要件をもとに、エッジケースを含めた詳細な要件を自動的に展開する。生成された内容は必ず人間がレビューし、不要な要件の削除や不足している要件の追加を行うこと。また、生成結果をお客様に共有して認識のズレがないか確認するのも有効だ。
レビュー後、チャットペインに表示される 「Move to design phase」ボタンをクリックして次のフェーズに進む。
手順4: Design の生成
Requirements が確定すると、Kiro は design.md を自動生成する。新規プロジェクトでは、Steering Files で指定した技術スタックをもとにゼロからアーキテクチャが設計される。
生成された design.md には以下の内容が含まれていた。
- システム構成図（Mermaid）: フロントエンド（Next.js App Router → 認証UI コンポーネント → 認証クライアント）→ API層（API Gateway → Lambda）→ 認証サービス（Cognito User Pool → Identity Pool）の接続関係
-
TypeScript インターフェース定義:
SignupFormProps、LoginFormState、IAuthClient、AuthError等、すべてのコンポーネントに型定義 -
API エンドポイント設計: 9つのエンドポイント（
/auth/signup、/auth/signin、/auth/signout等）のパス、メソッド、リクエスト/レスポンス形式 - AWS CDK のインフラコード: Cognito User Pool、Identity Pool、Lambda、API Gateway の CDK 定義がそのまま実装に使えるレベルで生成
- 正確性プロパティ: 23個の検証可能なプロパティが定義され、各要件とのトレーサビリティが明記
- セキュリティ考慮事項: CSRF対策、レート制限、トークン管理、パスワードハッシュ化
- 日本国内向け対応: ローカライゼーション、メールテンプレートの日本語化、全角文字サポート
- テスト戦略: プロパティベーステスト（fast-check）とユニットテスト（Jest）の使い分け
## API エンドポイント
| メソッド | パス | 説明 |
|---------|------|------|
| POST | /auth/signup | 新規ユーザー登録 |
| POST | /auth/confirm-signup | メールアドレス確認 |
| POST | /auth/resend-code | 確認コード再送信 |
| POST | /auth/signin | ログイン |
| POST | /auth/signout | ログアウト |
| POST | /auth/forgot-password | パスワードリセット要求 |
| POST | /auth/confirm-forgot-password | パスワードリセット確認 |
| POST | /auth/refresh | トークンリフレッシュ |
| GET | /auth/user | 現在のユーザー情報取得 |
Design のプレビューは、エディタ上部のタブに表示される 「Preview design.md」 をクリックすることで、Mermaid 図がレンダリングされた形式で確認できる。
レビュー後、チャットペインの 「Move to implementation plan」ボタンをクリックして次のフェーズに進む。
手順5: Tasks の生成
Design が確定すると、Kiro は tasks.md を自動生成する。各タスクは依存関係に基づいて順序付けされ、対応する要件番号がトレースできるようになっている。
# 実装計画：ユーザー認証機能
## タスク
- [ ] 1. プロジェクト基盤とAWS CDKインフラストラクチャのセットアップ
- AWS CDKで認証スタックを作成（Cognito User Pool、User Pool Client、Identity Pool）
- 環境変数の設定
- TypeScript型定義ファイルの作成
- _要件: 10.1, 10.2, 10.5_
- [ ] 2. 認証クライアント（AuthClient）の実装
- [ ] 2.1 AuthClientインターフェースと基本構造の実装（_要件: 7.1, 8.1, 8.2_）
- [ ] 2.2 サインアップ機能の実装（_要件: 1.1, 1.2, 1.4, 1.5_）
- [ ]* 2.3 サインアップ機能のプロパティテスト
- [ ] 2.4 ログイン機能の実装（_要件: 3.1, 3.2, 3.3, 7.4_）
...
- [ ] 3. チェックポイント - 認証クライアントのテスト確認
- [ ] 4. 入力検証ロジックの実装
- [ ] 5. UIコンポーネントの実装
- [ ] 6. チェックポイント - UIコンポーネントのテスト確認
- [ ] 7. バックエンドAPI（Lambda関数）の実装
- [ ] 8. API GatewayとLambda関数の統合（AWS CDK）
- [ ] 9. Next.jsページとServer Actionsの実装
- [ ] 10. Cognitoメールテンプレートの日本語化
- [ ] 11. 統合とエンドツーエンドテスト
- [ ] 12. 最終チェックポイント
最終的に、ユーザー認証機能だけで 12の主要タスクが生成された。注目すべき特徴は以下の通り。
-
要件へのトレーサビリティ: 各タスクに
_要件: 10.1, 10.2, 10.5_のように対応する要件番号が明記されている - チェックポイント: タスク3、6、12にチェックポイントが設けられ、段階的な検証を促す設計
-
オプションタスク: テスト系のタスクには
*マークが付いており、MVP 優先の開発ではスキップ可能 - Start Task リンク: 各タスクの横に「Start task」リンクが表示され、クリックすると Kiro がそのタスクの実装を自動的に開始する
- Run all tasks ボタン: エディタ上部の「Run all tasks」ボタンで未完了タスクを一括実行することも可能
これで、Requirements → Design → Tasks の3フェーズが完了し、ユーザー認証機能の仕様書一式が .kiro/specs/user-authentication/ ディレクトリに生成された。
.kiro/
├── specs/
│ └── user-authentication/
│ ├── .config.kiro
│ ├── requirements.md # 10要件・50受入基準
│ ├── design.md # アーキテクチャ・23正確性プロパティ
│ └── tasks.md # 12主要タスク
└── steering/
└── project-standards.md # プロジェクト標準
新規プロジェクトにおける Spec 分割戦略
ECサイトのような複数機能を持つプロジェクトでは、Spec の分割方法が開発効率に大きく影響する。
推奨: 機能ドメインごとに分割
今回の実践でも確認できたように、Kiro 自身が大規模プロジェクトでは Spec の分割を提案してくる。1つのプロンプトですべての機能を含む Spec を生成することも可能だが、Requirements が膨大になりレビューが困難になる（実際、ユーザー認証機能だけで10要件・50受入基準・12タスクが生成された）。
以下のように機能ドメインごとに Spec を分割し、依存関係のある順序で作成するのが効果的だ。
1. user-auth（ユーザー認証）← 他の機能の前提
2. product-catalog（商品カタログ）← カート・注文の前提
3. cart-and-checkout（カート・注文・決済）← 認証と商品が必要
4. order-history（注文履歴）← 注文機能が必要
5. admin（管理者機能）← 全体が揃ってから
分割した場合のディレクトリ構成は以下のようになる。
.kiro/specs/
├── user-authentication/ # ユーザー認証
│ ├── requirements.md
│ ├── design.md
│ └── tasks.md
├── product-catalog/ # 商品カタログ
│ ├── requirements.md
│ ├── design.md
│ └── tasks.md
├── cart-and-checkout/ # カート・注文
│ ├── requirements.md
│ ├── design.md
│ └── tasks.md
└── admin/ # 管理者機能
├── requirements.md
├── design.md
└── tasks.md
各 Spec は #spec:spec名 で相互参照できるため、分割しても設計の一貫性を保てる。
Agent Hooks で仕様書の更新を自動化する
Kiro の Agent Hooks を使うと、ファイル変更をトリガーにしてバックグラウンドでエージェントを自動実行できる。新規プロジェクトでは、以下のような Hooks が特に有用だ。
- ドキュメント自動更新: ソースコードが変更されたら、関連する README やドキュメントを自動更新
- 自動 Git コミット: Kiro がタスクを完了するたびに自動的に Git コミットを作成
- コード品質チェック: ファイル保存時にコードの改善提案を自動生成
Agent Hooks は自然言語のプロンプトで Kiro に作成を依頼できる。
従来の仕様書作成プロセスとの比較
注: 以下の比較は「ヒアリング後の仕様書作成・構造化」工程の比較であり、お客様へのヒアリングや合意形成の時間は含まない。ヒアリングは従来もKiro活用時も同様に必要だ。
| 観点 | 従来のプロセス | Kiro Spec-Driven |
|---|---|---|
| 仕様書作成の所要時間 | 数日〜1週間（社内会議・レビュー含む） | 数十分〜数時間 |
| 成果物の構造化 | 担当者のスキルに依存 | EARS 記法で統一的に構造化 |
| エッジケースの網羅性 | レビューアーの経験に依存 | AI が自動的にエッジケースを展開 |
| 仕様↔コードのトレーサビリティ | 手動管理 | タスクと要件番号が自動リンク |
| バージョン管理 | Wiki / Confluence 等で別管理 |
.kiro/specs/ にコードと同居 |
| 共有 | ドキュメントの URL 共有 | Git リポジトリで自然に共有 |
今回の実践では、ユーザー認証機能の Requirements → Design → Tasks の生成に約10分（Credits 使用量: 0.42）で完了した。従来のプロセスで同等の品質の仕様書（10要件・50受入基準・API設計・CDKコード・テスト戦略を含む）を作成する場合、少なくとも数日はかかるだろう。
注意点とベストプラクティス
注意点
- Kiro はヒアリングの代替ではない。 Kiro が効率化するのは「要件の構造化・文書化」であり、お客様の要望を引き出すヒアリングや合意形成は人間が行う必要がある。入力する要件の質がそのまま出力の質に直結する
- 仕様書は必ず人間がレビューすること。 AI が生成する仕様は網羅的だが、ビジネス要件の優先度や組織固有の制約は人間が判断する必要がある
- 大きなプロジェクトは Spec を分割すること。 1つの Spec にすべてを詰め込むと、タスクが膨大になり品質が低下する。Kiro 自身も分割を提案してくる
- 生成された仕様とコードは乖離しうる。 実装が進むにつれて仕様を更新する運用ルールを決めておく
ベストプラクティス
- Steering Files を最初に設定する。 技術スタックやアーキテクチャ方針が明確であるほど、生成される仕様の品質が上がる。新規プロジェクトでは特に重要。今回の実践でも、Steering Files に AWS CDK や Cognito を指定したことで、Design に CDK のコードが含まれるレベルまで具体化された
-
チームで仕様をレビューする。 生成された
requirements.mdは PR として共有し、チームでレビューする -
仕様ファイルをリポジトリにコミットする。
.kiro/specs/はコードと一緒にバージョン管理することが推奨されている -
#spec コンテキストプロバイダーを活用する。 チャットで
#spec:機能名と入力すると、該当 Spec のコンテキストを参照した回答が得られる - Vibe モードとの使い分け。 小さなバグ修正や単純な変更には Vibe モードを、複雑な機能開発には Spec モードを使い分ける
まとめ
Kiro の Spec-Driven Development は、要件定義の中でも特に時間がかかる「ヒアリング結果の構造化」を AI で効率化する。Requirements → Design → Tasks の3フェーズワークフローにより、ヒアリングで整理した要件から実装可能なタスクリストまでを一気通貫で生成できる。
今回の実践では、ユーザー認証機能のヒアリング結果（3つの要件）を入力し、約10分で以下の成果物が得られた。
| 成果物 | 内容 |
|---|---|
| requirements.md | 10要件・50受入基準（EARS記法） |
| design.md | システム構成図・API設計・CDKコード・23正確性プロパティ |
| tasks.md | 12主要タスク（要件トレース付き） |
特にゼロからの新規構築では、Steering Files による技術スタックの事前定義と、機能ドメインごとの Spec 分割が品質の鍵になる。
ただし、これは「人間が不要になる」という話ではない。お客様へのヒアリングと合意形成、ビジネス判断と優先度付けは人間が行い、AI が構造化と網羅性を担うという役割分担だ。この組み合わせが、開発プロセスの最上流である要件定義を大幅に効率化する。