Kiro（プレビュー版）によるはじめてのスペックコーディング

こんにちは。
アプリケーションサービス部、DevOps担当の兼安です。
今回は先日発表されたKiroとその特徴的な機能を使ってコーディングを試してみようと思います。

Kiroとは
- VibeとSpec
Kiroのセットアップ
Kiroのフックを使ってみる
Kiroのスペックを使ってみる
Kiroのスペックを使った開発の感想
まとめ

Kiroとは

Kiroは2025年7月14日に発表されたAWS製のAI機能を備えたIDE（統合開発環境）です。
本資料作成時点（2025年7月16日）ではプレビュー版として公開されています。

aws.amazon.com

最大の特徴はスペックとフックという新たな考え方の機能を備えていることです。

スペックは入力された要件に対して、要件定義書、設計書、実装計画をファイルとして保存し、その上で実装を行う機能です。
フックは開発の各工程において、自動処理を走らせる機能です。

VibeとSpec

Kiroはチャットを起動すると、VibeとSpecという2つのモードが選べます。
VibeはGitHub Copilotのようなチャットベースの開発支援機能で、Copilotと同じような感覚で使えます。
SpecがKiro特有の機能となっています。

私はチャットベースのAIコーディングは、どうしてもプロンプトを都度入力してしまうので、成果物に必要なプロンプトをまとめておくことが難しいという課題があると思っています。
これに対してメタプロンプトなどのテクニックがあります。

blog.serverworks.co.jp

対してKiroのSpecは、要件からの実装を段階的に、都度ファイルを保存しながら進めていくので、成果物に必要な情報が残るようになっています。
そのため、レビューがしやすく、仮に同じようなことをするとしても使い回しがしやすいメリットがあると思います。

.kiro/
└── specs/
    └── admin-notification/ # Kiroのスペックを開発すると要件ごとにスペックファイル一式が残る
        ├── design.md
        ├── requirements.md
        └── tasks.md

Kiroのセットアップ

では、Kiroを試すためにセットアップしていきます。
Kiroは公式ページからダウンロードしてインストールします。

kiro.dev

基本的にインストーラーの指示に従って進めていけばOKです。
ポイントは以下の通りです。

Kiroは事前にアカウントなどを用意しておく必要があります。
Cursorと同じように、VS Codeの設定をインポートすることができます。
Amazon Q Developerのサインインが必要です。

Kiroのフックを使ってみる

今回はスペックの方を使っていきますが、フックも少し触れておきます。
フックは、Kiroでプロジェクトを開いた状態で、Kiroのアイコンをクリック、AGENT HOOKSの＋アイコンではじめます。
（隠れていますがAGENT HOOKSの右横にカーソルを合わせると＋アイコンが出ます。）

＋アイコンをクリックすると、フックの内容を自然言語で入力する画面が出てきます。
今回は簡単な動作確認として、以下の内容を入力してみます。
実用性のないフックですが、動作確認が目的なのでご了承ください。

TypeScriptファイルを修正したらその修正内容をhistory.mdに記録してください。

内容を入力して、送信するとフック処理のファイルができます。
経過は、チャット欄に表示されます。

ファイルは.kiro/hooks配下にできます。
この拡張子.kiro.hookというファイルがフックの定義ファイルです。

.kiro/
├── hooks/
│   └── ts-history-tracker.kiro.hook
└── specs/

できたファイルの内容はこちらです。
このファイルができたことで、TypeScriptファイルを編集すると、history.mdに編集内容が記録されるようになります。

{
  "enabled": true,
  "name": "TypeScript History Tracker",
  "description": "Automatically records modifications to TypeScript files in history.md",
  "version": "1",
  "when": {
    "type": "fileEdited",
    "patterns": [
      "**/*.ts",
      "**/*.tsx"
    ]
  },
  "then": {
    "type": "askAgent",
    "prompt": "A TypeScript file has been modified. Please analyze the changes and append a summary of the modifications to history.md file. Include the file path, timestamp, and a brief description of what was changed."
  }
}

例えば、あるファイルの文言を修正すると自動で以下のように記録されました。

# Change History

## 2025-01-16 (Wednesday)

### calendar/app/page.tsx

- **Time**: 2025-01-16
- **Change**: Updated share text terminology from "ウェブアプリケーション" to "Webアプリケーション" for consistency with modern Japanese web terminology
- **Type**: Text content update

実際の開発では、「特定のディレクトリのコードを直したら必ずテストコードを書く」などのフックを作ると良いと思います。

Kiroのスペックを使ってみる

次はKiroのスペックを使って開発を試してみます。
題材として、私が以前作成したIT勉強会カレンダーというWebアプリを改造してみようと思います。

この、IT勉強会カレンダーの構成はこのような感じです。

一般ユーザー向けの画面でデータ登録、管理者が管理画面でデータを確認して承認してカレンダーに反映するという流れになっています。
このWebアプリはデータ登録時に管理者が気づく仕組みを設けていません。
なので、Kiroのスペック機能を使ってデータ登録時に通知する機能を実装してみようと思います。

Kiroとのやりとりは右上の吹き出しをクリックします。
次に、チャットのモードを選択、スペック機能が使いたいのでSpecを選択します。

要件の入力と要件定義書

まずはこんな要件を入力してみます。
初回なのでちょっとだけ構成の説明も入れておきます。

このWebアプリは一般ユーザー向けの画面と、管理者向け画面の2つがあります。  
一般ユーザー向けの画面で勉強会が登録されたら、管理者に通知がいく機能を実装してください。

要件定義書を作ってくれました。
素晴らしい。

場所はこちらです。

.kiro/
├── hooks/
│   └── ts-history-tracker.kiro.hook
└── specs/
    └── admin-notification/
        └── requirements.md # 要件定義書ができました

ファイルの中身はこちらです。

# 管理者通知機能 要件定義書

## はじめに

この機能は、一般ユーザーが勉強会を登録した際に、管理者に自動的に通知を送信する機能です。  現在、管理者は手動で管理画面をチェックして新しい登録を確認する必要がありますが、この機能により即座に新規登録を把握できるようになります。  

## 要件

### 要件1: リアルタイム通知

**ユーザーストーリー:** 管理者として、新しい勉強会が登録されたときに即座に通知を受け取りたい。  そうすることで、迅速に承認・却下の判断ができる。  

#### 受入基準

1. WHEN 一般ユーザーが勉強会登録フォームを送信し、データベースに正常に保存された THEN システムは管理者に通知を送信する
2. WHEN 通知が送信される THEN 通知には勉強会のタイトル、開催日時、登録者の連絡先（提供されている場合）、詳細確認用のリンクが含まれる
3. WHEN 通知送信に失敗した THEN システムはエラーをログに記録し、勉強会登録処理は正常に完了する

### 要件2: メール通知

**ユーザーストーリー:** 管理者として、メールで通知を受け取りたい。  そうすることで、管理画面にアクセスしていない時でも新規登録を把握できる。  

#### 受入基準

1. WHEN 新しい勉強会が登録される THEN システムは設定された管理者メールアドレスに通知メールを送信する
2. WHEN メール通知を送信する THEN メールの件名は「【広島IT勉強会カレンダー】新しい勉強会が登録されました」の形式とする
3. WHEN メール通知を送信する THEN メール本文には勉強会の詳細情報と管理画面へのリンクを含める
4. IF 複数の管理者が設定されている THEN 全ての管理者にメール通知を送信する

### 要件3: 管理画面内通知

**ユーザーストーリー:** 管理者として、管理画面にアクセスした際に未確認の新規登録があることを視覚的に把握したい。  そうすることで、対応が必要な項目を見落とすことがない。  

#### 受入基準

1. WHEN 管理者が管理画面にアクセスする THEN 承認待ちの勉強会数がヘッダーまたは目立つ場所に表示される
2. WHEN 承認待ちの勉強会がある THEN 該当する勉強会項目が視覚的に強調表示される
3. WHEN 承認待ちの勉強会が0件の場合 THEN 通知バッジは表示されない

### 要件4: 通知設定の管理

**ユーザーストーリー:** システム管理者として、通知先メールアドレスや通知の有効/無効を設定できるようにしたい。  そうすることで、運用に応じて柔軟に通知設定を変更できる。  

#### 受入基準

1. WHEN システムを初期設定する THEN 環境変数またはパラメータストアで管理者メールアドレスを設定できる
2. WHEN 通知機能を無効にしたい THEN 環境変数で通知機能のオン/オフを切り替えられる
3. WHEN 複数の管理者に通知したい THEN カンマ区切りで複数のメールアドレスを設定できる

### 要件5: エラーハンドリング

**ユーザーストーリー:** システム管理者として、通知送信に失敗した場合でも勉強会登録処理が正常に完了することを保証したい。  そうすることで、通知システムの障害が本来の機能に影響しない。  

#### 受入基準

1. WHEN メール送信サービスが利用できない THEN エラーをログに記録し、勉強会登録処理は正常に完了する
2. WHEN 通知送信処理でタイムアウトが発生する THEN 適切なタイムアウト時間（5秒以内）で処理を中断し、エラーログを記録する
3. WHEN 通知送信でエラーが発生する THEN エラーの詳細をCloudWatchログに記録し、監視可能にする

### 要件6: セキュリティとプライバシー

**ユーザーストーリー:** システム管理者として、通知に含まれる情報が適切に保護されることを確保したい。  そうすることで、登録者の個人情報が適切に扱われる。  

#### 受入基準

1. WHEN メール通知を送信する THEN 通知には登録者の個人情報（連絡先）は含めず、管理画面でのみ確認できるようにする
2. WHEN 管理画面へのリンクを含める THEN リンクは認証が必要な管理画面へのリンクとし、直接データにアクセスできないようにする
3. WHEN 通知メールを送信する THEN メール送信はAWS SESなどのセキュアなサービスを使用する

作成された要件定義書を見てみると、メールアドレスを環境変数で指定するようになっています。
通知はAmazon SNS (Simple Notification Service) を使った方が柔軟性が高いと思うので修正依頼を出します。

通知はAmazon SNS (Simple Notification Service)を使いましょう。  
サブスクライバは私が手動で登録します。  
その方が柔軟性が高いです。

要件定義書が修正されました。
これでOKとして次に進めてもらいます。

# 管理者通知機能 要件定義書

## はじめに

この機能は、一般ユーザーが勉強会を登録した際に、管理者に自動的に通知を送信する機能です。  現在、管理者は手動で管理画面をチェックして新しい登録を確認する必要がありますが、この機能により即座に新規登録を把握できるようになります。  

## 要件

### 要件1: リアルタイム通知

**ユーザーストーリー:** 管理者として、新しい勉強会が登録されたときに即座に通知を受け取りたい。  そうすることで、迅速に承認・却下の判断ができる。  

#### 受入基準

1. WHEN 一般ユーザーが勉強会登録フォームを送信し、データベースに正常に保存された THEN システムは管理者に通知を送信する
2. WHEN 通知が送信される THEN 通知には勉強会のタイトル、開催日時、登録者の連絡先（提供されている場合）、詳細確認用のリンクが含まれる
3. WHEN 通知送信に失敗した THEN システムはエラーをログに記録し、勉強会登録処理は正常に完了する

### 要件2: SNS通知

**ユーザーストーリー:** 管理者として、Amazon SNSを通じて通知を受け取りたい。  そうすることで、管理画面にアクセスしていない時でも新規登録を把握でき、メール、SMS、Slackなど様々な方法で通知を受け取れる。  

#### 受入基準

1. WHEN 新しい勉強会が登録される THEN システムは設定されたSNSトピックにメッセージを発行する
2. WHEN SNS通知を送信する THEN メッセージには勉強会のタイトル、開催日時、登録日時、管理画面へのリンクを含める
3. WHEN SNS通知を送信する THEN メッセージの件名は「【広島IT勉強会カレンダー】新しい勉強会が登録されました」の形式とする
4. WHEN SNSトピックにメッセージを発行する THEN 管理者が手動で設定したサブスクライバー（メール、SMS、Webhookなど）に通知が配信される

### 要件3: 管理画面内通知

**ユーザーストーリー:** 管理者として、管理画面にアクセスした際に未確認の新規登録があることを視覚的に把握したい。  そうすることで、対応が必要な項目を見落とすことがない。  

#### 受入基準

1. WHEN 管理者が管理画面にアクセスする THEN 承認待ちの勉強会数がヘッダーまたは目立つ場所に表示される
2. WHEN 承認待ちの勉強会がある THEN 該当する勉強会項目が視覚的に強調表示される
3. WHEN 承認待ちの勉強会が0件の場合 THEN 通知バッジは表示されない

### 要件4: 通知設定の管理

**ユーザーストーリー:** システム管理者として、SNSトピックの設定や通知の有効/無効を設定できるようにしたい。  そうすることで、運用に応じて柔軟に通知設定を変更できる。  

#### 受入基準

1. WHEN システムを初期設定する THEN 環境変数またはパラメータストアでSNSトピックARNを設定できる
2. WHEN 通知機能を無効にしたい THEN 環境変数で通知機能のオン/オフを切り替えられる
3. WHEN 管理者が通知方法を変更したい THEN SNSコンソールで手動でサブスクライバー（メール、SMS、Webhookなど）を追加・削除できる

### 要件5: エラーハンドリング

**ユーザーストーリー:** システム管理者として、通知送信に失敗した場合でも勉強会登録処理が正常に完了することを保証したい。  そうすることで、通知システムの障害が本来の機能に影響しない。  

#### 受入基準

1. WHEN メール送信サービスが利用できない THEN エラーをログに記録し、勉強会登録処理は正常に完了する
2. WHEN 通知送信処理でタイムアウトが発生する THEN 適切なタイムアウト時間（5秒以内）で処理を中断し、エラーログを記録する
3. WHEN 通知送信でエラーが発生する THEN エラーの詳細をCloudWatchログに記録し、監視可能にする

### 要件6: セキュリティとプライバシー

**ユーザーストーリー:** システム管理者として、通知に含まれる情報が適切に保護されることを確保したい。  そうすることで、登録者の個人情報が適切に扱われる。  

#### 受入基準

1. WHEN メール通知を送信する THEN 通知には登録者の個人情報（連絡先）は含めず、管理画面でのみ確認できるようにする
2. WHEN 管理画面へのリンクを含める THEN リンクは認証が必要な管理画面へのリンクとし、直接データにアクセスできないようにする
3. WHEN 通知メールを送信する THEN メール送信はAWS SESなどのセキュアなサービスを使用する

設計フェーズへの移行と設計書

要件定義処理が完了したので、次は設計フェーズに移ります。
次に進むかどうかを確認する、Move to design phaseが出ているのでこれをクリックします。

次のフェーズの設計へ移り、設計書を作ってくれます。

設計書ができた場所はこちらです。

.kiro/
├── hooks/
│   └── ts-history-tracker.kiro.hook
└── specs/
    └── admin-notification/
        ├── design.md # 設計書ができました
        └── requirements.md

設計書を見ると、E2Eテストまで用意してくれるようです。

# 管理者通知機能 設計書

## 概要

この設計書は、一般ユーザーが勉強会を登録した際に管理者に自動通知を送信する機能の技術的な実装方針を定義します。  Amazon SNSを使用してリアルタイム通知を実現し、管理画面での視覚的な通知表示も含みます。  

## アーキテクチャ

### システム構成図

```mermaid
graph TB
    A[一般ユーザー] --> B[勉強会登録フォーム]
    B --> C[API Gateway]
    C --> D[CreateStudySession Lambda]
    D --> E[DynamoDB]
    D --> F[SNS Topic]
    F --> G[管理者メール]
    F --> H[管理者SMS]
    F --> I[Slack Webhook]

    J[管理者] --> K[管理画面]
    K --> L[API Gateway]
    L --> M[GetStudySessions Lambda]
    M --> E

    subgraph "通知フロー"
        D --> N[NotificationService]
        N --> F
    end

    subgraph "管理画面通知"
        K --> O[承認待ち件数表示]
        K --> P[視覚的強調表示]
    end
```

### 通知フロー

1. **勉強会登録**: ユーザーが勉強会を登録
2. **データ保存**: DynamoDBに勉強会データを保存
3. **通知送信**: SNSトピックにメッセージを発行
4. **配信**: 設定されたサブスクライバー（メール、SMS、Webhook等）に通知配信
5. **管理画面更新**: 管理者が画面アクセス時に承認待ち件数を表示

## コンポーネントと インターフェース

### 1. NotificationService

新しく作成する通知サービスクラス

```typescript
interface NotificationService {
  sendNewStudySessionNotification(session: StudySession): Promise<void>
  isNotificationEnabled(): boolean
}
```

**責務:**
- SNS通知の送信
- 通知設定の管理
- エラーハンドリング

### 2. SNS Topic

**リソース名:** `admin-notification-topic`

**メッセージ形式:**
```json
{
  "Subject": "【広島IT勉強会カレンダー】新しい勉強会が登録されました",
  "Message": {
    "title": "勉強会タイトル",
    "datetime": "2024-01-15T19:00:00.000Z",
    "endDatetime": "2024-01-15T21:00:00.000Z",
    "url": "https://勉強会のURL",
    "registeredAt": "2024-01-10T10:30:00.000Z",
    "adminUrl": "https://管理者画面のURL"
  }
}
```

### 3. 環境変数

**新規追加する環境変数:**
- `SNS_TOPIC_ARN`: SNSトピックのARN
- `NOTIFICATION_ENABLED`: 通知機能の有効/無効フラグ（true/false）
- `ADMIN_URL`: 管理画面のURL

### 4. 管理画面の拡張

**承認待ち件数表示:**
- ヘッダーに承認待ち件数のバッジを表示
- 0件の場合は非表示

**視覚的強調表示:**
- 承認待ちの勉強会項目を黄色背景で強調
- 新規登録から24時間以内の項目に「NEW」バッジを表示

## データモデル

### StudySession（既存）

既存のStudySessionインターフェースに変更はありません。  

```typescript
interface StudySession {
  id: string
  title: string
  url: string
  datetime: string
  endDatetime?: string
  contact?: string
  status: 'pending' | 'approved' | 'rejected'
  createdAt: string
  updatedAt: string
}
```

### NotificationMessage（新規）

SNS通知用のメッセージ構造

```typescript
interface NotificationMessage {
  title: string
  datetime: string
  endDatetime?: string
  url: string
  registeredAt: string
  adminUrl: string
}
```

## エラーハンドリング

### 通知送信エラー

1. **SNS送信失敗**
   - エラーをCloudWatchログに記録
   - 勉強会登録処理は正常に完了
   - リトライは行わない（運用コストを考慮）

2. **タイムアウト**
   - 5秒でタイムアウト
   - エラーログを記録
   - 勉強会登録処理は正常に完了

3. **設定エラー**
   - SNSトピックARNが未設定の場合は通知をスキップ
   - ログに警告を記録

### ログ出力

```typescript
// 成功時
logger.info('Notification sent successfully', { sessionId, topicArn })

// エラー時
logger.error('Failed to send notification', {
  sessionId,
  error: error.message,
  topicArn
})

// 設定エラー時
logger.warn('Notification skipped: SNS topic not configured')
```

## テスト戦略

### 1. 単体テスト

**NotificationService**
- 通知送信の成功ケース
- SNS送信エラーのハンドリング
- 設定無効時のスキップ処理
- タイムアウト処理

**CreateStudySession Lambda**
- 通知送信を含む勉強会登録フロー
- 通知エラー時でも登録が完了すること

### 2. 統合テスト

**E2Eフロー**
- 勉強会登録から通知送信まで
- 管理画面での承認待ち件数表示
- 視覚的強調表示

### 3. 手動テスト

**SNS設定**
- メール通知の受信確認
- SMS通知の受信確認（設定した場合）
- Webhook通知の受信確認（設定した場合）

## セキュリティ考慮事項

### 1. 個人情報保護

- 通知メッセージには登録者の連絡先を含めない
- 管理画面でのみ連絡先を表示

### 2. アクセス制御

- SNSトピックへの発行権限をLambda関数のみに制限
- 管理画面へのリンクは認証が必要

### 3. データ暗号化

- SNSメッセージは転送時に暗号化
- 機密情報は含めない設計

## パフォーマンス考慮事項

### 1. 非同期処理

- 通知送信は勉強会登録処理と並行実行
- 通知エラーが登録処理に影響しない

### 2. タイムアウト設定

- SNS送信のタイムアウト: 5秒
- Lambda全体のタイムアウト: 30秒（既存）

### 3. コスト最適化

- SNS使用量は月間数十件程度を想定
- 追加コストは月額数円程度

## 運用考慮事項

### 1. 監視

- CloudWatchログでの通知送信状況監視
- SNS配信失敗の監視

### 2. 設定管理

- 環境変数での設定管理
- SNSサブスクライバーはAWSコンソールで手動管理

### 3. 障害対応

- 通知システム障害時でも勉強会登録は継続
- 通知再送は手動対応（運用コストを考慮）

## 実装優先度

### Phase 1: 基本通知機能
1. NotificationServiceの実装
2. SNSトピックの作成
3. CreateStudySession Lambdaの修正
4. 基本的なエラーハンドリング

### Phase 2: 管理画面拡張
1. 承認待ち件数表示
2. 視覚的強調表示
3. NEWバッジ機能

### Phase 3: 運用改善
1. 詳細なログ出力
2. 監視設定
3. テストの充実

実装計画フェーズへの移行と実装計画書

設計書の内容を確認して、問題がなければMove to implementation planをクリックして次に進みます。

今度は実装計画の作成が始まり、実装計画ができます。

.kiro/
├── hooks/
│   └── ts-history-tracker.kiro.hook
└── specs/
    └── admin-notification/
        ├── design.md
        ├── requirements.md
        └── tasks.md # 実装計画書ができました

# 実装計画

- [ ] 1. 通知サービスの基盤実装
  - NotificationServiceクラスを作成し、SNS通知の基本機能を実装する
  - AWS SNS SDKを使用してメッセージ送信機能を実装する
  - 環境変数からの設定読み込み機能を実装する
  - _要件: 1.1, 2.1, 4.1, 4.2_

- [ ] 2. SNSメッセージ形式の定義と実装
  - NotificationMessageインターフェースを定義する
  - 勉強会情報をSNSメッセージ形式に変換する関数を実装する
  - メッセージの件名と本文のフォーマット機能を実装する
  - _要件: 2.2, 2.3_

- [ ] 3. エラーハンドリングとログ機能の実装
  - SNS送信エラーのキャッチとログ出力を実装する
  - タイムアウト処理を実装する（5秒制限）
  - 設定エラー時のスキップ処理を実装する
  - CloudWatchログへの詳細なエラー情報出力を実装する
  - _要件: 5.1, 5.2, 5.3_

- [ ] 4. CreateStudySession Lambdaの通知機能統合
  - 既存のcreateStudySession関数にNotificationServiceを統合する
  - 勉強会作成成功後に通知送信を呼び出す処理を追加する
  - 通知エラーが勉強会登録処理に影響しないことを保証する
  - _要件: 1.1, 1.3, 5.1_

- [ ] 5. CDKスタックにSNSリソースを追加
  - SNSトピックをCDKスタックに定義する
  - Lambda関数にSNS発行権限を付与する
  - 環境変数にSNSトピックARNを設定する
  - _要件: 2.1, 4.1_

- [ ] 6. 管理画面の承認待ち件数表示機能
  - 承認待ち勉強会の件数を取得する関数を実装する
  - ヘッダーに承認待ち件数バッジを表示するコンポーネントを作成する
  - 件数が0の場合はバッジを非表示にする処理を実装する
  - _要件: 3.1, 3.3_

- [ ] 7. 管理画面の視覚的強調表示機能
  - 承認待ち勉強会項目の背景色変更を実装する
  - 新規登録から24時間以内の項目にNEWバッジを表示する機能を実装する
  - 勉強会一覧での視覚的な区別を明確にする
  - _要件: 3.2_

- [ ] 8. 通知機能の単体テスト作成
  - NotificationServiceの各メソッドのテストを作成する
  - SNS送信成功・失敗・タイムアウトのテストケースを実装する
  - 設定無効時のスキップ処理テストを作成する
  - _要件: 5.1, 5.2, 5.3_

- [ ] 9. Lambda関数の統合テスト作成
  - 勉強会登録から通知送信までのE2Eテストを作成する
  - 通知エラー時でも勉強会登録が完了することを検証するテストを作成する
  - _要件: 1.1, 1.3, 5.1_

- [ ] 10. 管理画面機能のテスト作成
  - 承認待ち件数表示のテストを作成する
  - 視覚的強調表示のテストを作成する
  - NEWバッジ表示のテストを作成する
  - _要件: 3.1, 3.2, 3.3_

- [ ] 11. 環境変数とデプロイ設定の更新
  - 必要な環境変数をCDKスタックに追加する
  - パラメータファイルに設定例を追加する
  - デプロイ手順書を更新する
  - _要件: 4.1, 4.2_

- [ ] 12. セキュリティ設定の実装と検証
  - 通知メッセージに個人情報が含まれないことを検証する
  - SNS発行権限が適切に制限されていることを確認する
  - 管理画面リンクの認証要求を検証する
  - _要件: 6.1, 6.2, 6.3_

ここで、通知機能が環境変数でON/OFFできるようになったのに気づいて、別にON/OFFできる必要ないんだけどなと思いましたが、まあよしとして先に進めることにします。
Finalize task listをクリックして、実装計画を確定します。

実装の開始

Kiroに指示された通り、.kiro/specs/admin-notification/tasks.mdを開いてみます。
タスクごとに、Start taskリンクがあるのでこれらをクリックしていきます。

タスクは連続でクリックしてもOKでした。
実行自体は1個ずつで他はキューに溜まっていきました。

タスクを実行すると、最初は実行を続けるかどうかや、このコマンドを実行していいかなどを聞いてきます。
これらを許可していくと、どんどん自動で進めてくれるようになります。

タスクが全て完了となれば実装は完了です。
この後、デプロイして無事通知機能が正常に動作することを確認できました。

Kiroのスペックを使った開発の感想

冒頭で述べた通り、Kiroのスペック機能は要件定義から設計、実装計画までを自動化してくれるので、実装内容の確認が都度できて確実性が高く感じます。
各工程のドキュメントが残るので、後からの振り返りや別の要件での再利用もできそうだと思っています。

また、スペックのディレクトリ構造を見ると、要件ごとでディレクトリが分かれることがわかります。
要件ごとにスペックファイル一式ができるので、新規開発・改修両方で活用できるでしょう。

.kiro/
├── hooks/
│   └── ts-history-tracker.kiro.hook
└── specs/
    └── admin-notification/ # 要件ごとにスペックファイル一式ができる
        ├── design.md
        ├── requirements.md
        └── tasks.md

実装計画（tasks.md）を作ってくれるのも、非常にありがたいです。
適切なタスク粒度と適度な粗結合で実装計画を作るのは実は高度な作業なので、誰しもができるわけではありません。
これを自動で作ってくれるのは、開発者にとって大きな助けになると思います。

一方で、スペック機能による実装は、重厚かつ慎重なプロセスになっているので従来のVibe Codingと比較して時間がかかると感じました。
成果物が多くタスクも細分化しているので、仕方がないところはあります。
体感的に、今回の内容を手動実装または従来のVibe Codingでの実装をしていたら、半分以下の時間で終わっていたと思います。
これは、Kiroのスペック機能が悪いのではなく、スペックでやる必要のない要件に対してスペックを利用してしまったからだと思っています。
KiroのチャットメニューにVibeとSpec両方があるのが示すように、全てをスペックでやる必要はないのでしょう。
適材適所で使い分けないと生産性を下げてしまう可能性があると理解しました。