Kiro のウェイトリストは終了、今日から仕様駆動開発を始めてみました

はじめに

ウェイトリストのなが～い行列が終わり Kiro とついに出会えました。使っている人の話を聞きながら Kiro の仕様駆動開発がどんなものか気になっておりましたが、ついに触ってみます。

90 日前のローンチ以来、数十万人の開発者が Kiro を試すためにウェイトリストに参加してくれました。本日（2025 年 10 月 16 日）をもって、ウェイトリストは廃止されます。AI を使った仕様駆動型コーディングアプローチを試したい方は、このブログの残りを飛ばして今すぐサインアップしてください。

（本記事内の凡例）

私の発言

Kiro の発言

Kiro とは

私
Kiro 君はなにができるの？

Kiro
私はKiroというAIアシスタント兼IDEで、開発者をサポートするために作られています。以下のようなことができます：

コード関連

• ローカルファイルシステムやコードの編集提案
• シェルコマンドの推奨
• ソフトウェア開発のアシスタンスと推奨事項
• インフラコードと設定のヘルプ
• ベストプラクティスのガイダンス
• リソース使用量の分析と最適化
• 問題やエラーのトラブルシューティング
• CLIコマンドと自動化タスクのサポート
• ソフトウェアコードの記述と修正
• ソフトウェアのテストとデバッグ

スペック駆動開発

• 機能のアイデアを要件、設計、実装計画に変換
• EARS（Easy Approach to Requirements Syntax）パターンを使った要件作成
• 包括的な設計ドキュメントの作成
• 実行可能なタスクリストの生成

その他の特徴

• チャットで#Fileや#Folderを使って特定のファイルやフォルダを参照可能
• 画像ファイルをドラッグ＆ドロップで処理
• #Problems、#Terminal、#Git Diffなどの現在の状況を確認
• #Codebaseでコードベース全体をスキャン（インデックス化後）

仕様駆動開発

Kiro に仕様駆動でタスク管理アプリ開発をさせます。

.kiro/specs/機能名 のフォルダ配下に3つのドキュメントが作られます。

• 要件ドキュメント： requirements.md
• 設計ドキュメント： design.md
• 実装計画： tasks.md

要件定義

要件定義書は以下のように作られます。これに対してコメントを入れて方向性をすり合わせることは可能です。

# 要件ドキュメント

## 概要

個人やチーム向けのタスク管理アプリケーション。ユーザーがタスクを作成、編集、削除、完了マークができ、効率的にタスクを管理できるシステムです。

## 用語集

- **TaskApp**: タスク管理アプリケーションシステム
- **User**: アプリケーションを使用する個人ユーザー
- **Task**: 実行すべき作業項目
- **TaskList**: タスクの集合体
- **Priority**: タスクの重要度レベル（高、中、低）
- **Status**: タスクの状態（未完了、完了）
- **DueDate**: タスクの期限日

## 要件

### 要件 1

**ユーザーストーリー:** ユーザーとして、新しいタスクを作成したい。そうすることで、やるべきことを記録できる。

#### 受け入れ基準

1. WHEN ユーザーがタスク作成ボタンをクリックしたとき、THE TaskApp SHALL タスク作成フォームを表示する
2. WHEN ユーザーがタスクタイトルを入力したとき、THE TaskApp SHALL 入力内容を受け付ける
3. WHEN ユーザーがタスク作成を完了したとき、THE TaskApp SHALL 新しいタスクをタスクリストに追加する
4. THE TaskApp SHALL タスクタイトルが空でないことを検証する
5. WHERE ユーザーが説明を入力する場合、THE TaskApp SHALL 説明をタスクに保存する

### 要件 2

**ユーザーストーリー:** ユーザーとして、タスクの詳細を編集したい。そうすることで、タスク情報を最新に保てる。

#### 受け入れ基準

1. WHEN ユーザーがタスクの編集ボタンをクリックしたとき、THE TaskApp SHALL タスク編集フォームを表示する
2. THE TaskApp SHALL 現在のタスク情報を編集フォームに事前入力する
3. WHEN ユーザーが編集を保存したとき、THE TaskApp SHALL 更新されたタスク情報を保存する
4. THE TaskApp SHALL 編集されたタスクをタスクリストに反映する

（以下略）

設計

設計書は以下のように出力されます。中身は抜粋しています。主要な設計観点を洗い出しているようです。

# 設計ドキュメント

## 概要

タスク管理アプリケーションは、モダンなWebアプリケーションとして設計されます。フロントエンドはReactを使用し、バックエンドはNode.js/Express、データベースはローカルストレージまたはSQLiteを使用したシンプルな構成とします。レスポンシブデザインでモバイルデバイスにも対応します。

## アーキテクチャ
### システム構成
（略）
### 技術スタック
- **フロントエンド**: React 18, TypeScript, CSS Modules
- **バックエンド**: Node.js, Express, TypeScript
- **データベース**: SQLite (開発用), PostgreSQL (本番用対応)
- **状態管理**: React Context API + useReducer
- **HTTP通信**: Axios
- **日付処理**: date-fns
- **スタイリング**: CSS Modules + CSS Variables

## コンポーネントとインターフェース
### フロントエンドコンポーネント構造
（略）
### バックエンドAPI構造
（略）
### APIエンドポイント
- `GET /api/tasks` - 全タスク取得（クエリパラメータでフィルタリング対応）
- `POST /api/tasks` - 新規タスク作成
- `PUT /api/tasks/:id` - タスク更新
- `DELETE /api/tasks/:id` - タスク削除
- `PATCH /api/tasks/:id/status` - タスクステータス更新

## データモデル
### Task エンティティ
interface Task {
  id: string;
  title: string;
  description?: string;
  priority: 'high' | 'medium' | 'low';
  status: 'pending' | 'completed';
  dueDate?: Date;
  createdAt: Date;
  updatedAt: Date;
}

### データベーススキーマ
（略）

## コンポーネント詳細設計
### TaskList コンポーネント
（略）
### TaskItem コンポーネント
（略）

## 状態管理
### TaskContext 設計
（略）
## エラーハンドリング

### フロントエンド
- ネットワークエラー: トースト通知で表示
- バリデーションエラー: フォーム内でインライン表示
- 予期しないエラー: エラーバウンダリでキャッチ

### バックエンド
- 400 Bad Request: バリデーションエラー
- 404 Not Found: リソースが見つからない
- 500 Internal Server Error: サーバーエラー

### エラーレスポンス形式
（略）


## テスト戦略

### フロントエンド

- **単体テスト**: React Testing Library + Jest
  - コンポーネントの描画テスト
  - ユーザーインタラクションテスト
  - カスタムフックのテスト

- **統合テスト**: 
  - TaskContext とコンポーネントの連携テスト
  - API通信のモックテスト

### バックエンド

- **単体テスト**: Jest
  - サービス層のビジネスロジックテスト
  - データベース操作のテスト

- **統合テスト**:
  - APIエンドポイントのテスト
  - データベース連携テスト

### E2Eテスト

- Playwright または Cypress を使用
- 主要なユーザーフローのテスト
  - タスク作成から完了までの流れ
  - フィルタリング機能
  - 編集・削除機能

## パフォーマンス考慮事項
### フロントエンド最適化
（略）

### バックエンド最適化
（略）

## セキュリティ考慮事項
（略）

## デプロイメント
### 開発環境
（略）

### 本番環境（将来的な拡張）
- フロントエンド: Vercel または Netlify
- バックエンド: Railway または Heroku
- データベース: PostgreSQL (Supabase または Railway)

実装

要件定義書に沿ってタスクが設定されています。

# 実装計画
- [x] 1. プロジェクト構造とコア設定のセットアップ
  - プロジェクトディレクトリ構造の作成
  - package.json とTypeScript設定ファイルの作成
  - 基本的な開発環境の構築
  - _要件: 1.1, 2.1, 3.1, 4.1, 5.1, 6.1, 7.1_

- [ ] 2. データモデルとタイプ定義の実装
  - Task インターフェースとタイプ定義の作成
  - TaskFilter インターフェースの定義
  - API レスポンス/リクエストタイプの定義
  - _要件: 1.1, 2.1, 3.1, 4.1, 5.1, 6.1, 7.1_

Kiro の IDE には Start task と表示されており、クリックすると Kiro が作業をはじめます。

タスクが完了すると成果物が出力されています。

View Changes を押すと作業結果の差分を確認できます。

タスクを実行する中でコマンドを実行することもあります。コマンドに失敗したら原因を考えて対策前進していきます。

Kiro の機能紹介

私
Kiro のコマンドを教えて

Kiro

Kiroで使える主要なコマンドと機能をご紹介します：

チャット機能

ファイル・フォルダ参照

• #File - 特定のファイルを参照
• #Folder - 特定のフォルダを参照
• #Codebase - コードベース全体をスキャン（インデックス化後）

現在の状況確認

• #Problems - 現在のファイルの問題を確認
• #Terminal - ターミナルの状況を確認
• #Git Diff - Gitの差分を確認

コマンドパレット

コマンドパレット（Ctrl+Shift+P / Cmd+Shift+P）から以下が利用可能：

MCP関連

• MCP関連のコマンドを検索して設定

Agent Hooks

• フック作成・管理のコマンド
• 「Open Kiro Hook UI」でフック作成画面を開く

Agent Hooks（自動化）

ファイル保存時やボタンクリック時に自動でエージェントを実行：

例：

• ファイル保存時にテストを自動実行
• 翻訳ファイル更新時に他言語も自動更新
• 手動でREADMEの文法チェック

設定場所：

• エクスプローラーの「Agent Hooks」セクション
• コマンドパレットから「Open Kiro Hook UI」

Steering（プロジェクト設定）

場所: .kiro/steering/*.md

種類：

• Always included - 常に含まれる設定（デフォルト）
• Conditional - 特定ファイル読み込み時のみ
• Manual - #でチャット時に手動指定

MCP（Model Context Protocol）

設定ファイル：

• ワークスペース: .kiro/settings/mcp.json
• ユーザー全体: ~/.kiro/settings/mcp.json

例（AWS ドキュメント）：

{
  "mcpServers": {
    "aws-docs": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "disabled": false,
      "autoApprove": []
    }
  }
}

実行モード

• Autopilot: ファイル変更を自動適用
• Supervised: 変更前にユーザー確認

画像処理

• ドラッグ&ドロップで画像をチャットに追加
• チャット入力欄のアイコンから画像選択

Agent Steering

Kiro にプロジェクト設定を作成してもらいました。中身はプロジェクトごとに異なるので雰囲気を掴んで貰えればと思います。

product

# Product Overview

Task Management App - 個人やチーム向けのタスク管理アプリケーション

## Core Features

- Task CRUD operations (create, read, update, delete)
- Task completion tracking
- Priority levels (high, medium, low)
- Due date management
- Filtering capabilities
- Responsive design

## API Endpoints

- `GET /api/tasks` - Retrieve all tasks
- `POST /api/tasks` - Create new task
- `PUT /api/tasks/:id` - Update task
- `DELETE /api/tasks/:id` - Delete task
- `PATCH /api/tasks/:id/status` - Update task status

## Target Users

Personal and team task management for productivity enhancement.

structure

# Project Structure

## Root Level
task-management-app/
├── frontend/          # React application
├── backend/           # Express API server
├── package.json       # Root package with workspace scripts
└── README.md          # Project documentation

## Frontend Structure (`frontend/`)
frontend/
├── src/
│   ├── components/    # Reusable React components
│   ├── hooks/         # Custom React hooks
│   ├── services/      # API service functions
│   ├── types/         # TypeScript type definitions
│   ├── context/       # React Context providers
│   ├── utils/         # Utility functions
│   └── test/          # Test setup and utilities
├── .env.example       # Environment variables template
├── vite.config.ts     # Vite configuration
├── tsconfig.json      # TypeScript configuration
└── package.json       # Frontend dependencies

## Backend Structure (`backend/`)
backend/
├── src/
│   ├── routes/        # Express route handlers
│   ├── models/        # Data models and schemas
│   ├── services/      # Business logic services
│   ├── database/      # Database connection and setup
│   ├── middleware/    # Express middleware functions
│   └── types/         # TypeScript type definitions
├── dist/              # Compiled JavaScript output
├── .env.example       # Environment variables template
├── tsconfig.json      # TypeScript configuration
└── package.json       # Backend dependencies

## Configuration Files
- **TypeScript**: Strict mode enabled, path aliases in frontend
- **Environment**: Separate `.env` files for frontend/backend
- **Build Output**: `dist/` for backend, Vite handles frontend builds
- **Testing**: Vitest (frontend), Jest (backend)

## Naming Conventions
- Use camelCase for variables and functions
- Use PascalCase for React components and TypeScript types
- Use kebab-case for file names where appropriate
- API routes follow REST conventions (`/api/tasks`)

tech

# Technology Stack

## Frontend
- **Framework**: React 18 with TypeScript
- **Build Tool**: Vite
- **State Management**: React Context API + useReducer
- **HTTP Client**: Axios
- **Date Utilities**: date-fns
- **Testing**: Vitest with Testing Library
- **Linting**: ESLint with TypeScript rules

## Backend
- **Runtime**: Node.js (v18+)
- **Framework**: Express with TypeScript
- **Database**: SQLite (development)
- **Testing**: Jest
- **Development**: Nodemon with ts-node

## Development Setup

### Prerequisites
- Node.js v18 or higher
- npm package manager

### Common Commands

```bash
# Install all dependencies
npm run install:all

# Development (runs both frontend and backend)
npm run dev

# Individual development servers
npm run dev:frontend  # http://localhost:3000
npm run dev:backend   # http://localhost:3001

# Build production
npm run build

# Run tests
npm test

# Linting (frontend)
cd frontend && npm run lint

### Environment Configuration
- Frontend: Copy `frontend/.env.example` to `frontend/.env`
- Backend: Copy `backend/.env.example` to `backend/.env`

## Code Standards
- Strict TypeScript configuration enabled
- ESLint with React hooks rules
- Path aliases: `@/*` maps to `src/*` (frontend only)
- CommonJS modules (backend), ESM modules (frontend)

私
Agent Steering を育てることがKiroを使いこなす上で重要かな？

Kiro

その通りです！Agent Steeringを育てることは、Kiroを効果的に使いこなす上で非常に重要です。

Agent Steeringの重要性

一貫性の確保

• プロジェクト全体で統一された技術選択
• コーディング規約やアーキテクチャパターンの維持
• チーム開発での標準化

効率性の向上

• 毎回同じ説明をする必要がない
• プロジェクト固有の知識を蓄積
• 開発速度の向上

品質の向上

• ベストプラクティスの自動適用
• エラーの予防
• 保守性の高いコードの生成

Steeringを育てるコツ

段階的な改善

• プロジェクトを進めながら学んだことを追加
• 繰り返し発生する問題の解決策を記録
• 成功パターンをドキュメント化

具体的な内容

• 抽象的でなく、実行可能な指示
• コード例やテンプレートの提供
• 「なぜ」その選択をするかの理由も記載

継続的な更新

• プロジェクトの成長に合わせて更新
• 新しい技術や手法の採用時に反映
• チームフィードバックの取り込み

おわりに

AIによって開発スピードが速まる中で、仕様駆動開発という基本に立ち返った開発が効果的だという状況が印象的です。

AIと共に開発をする上で、いかにAIと正しく対話をしていくのかが重要になってきていることを感じます。