はじめに

AWSが提供するAI IDE「Kiro」を使った簡単なアプリケーションを作成してみました。
今回のアプリ作成にあたって、特に印象敵だったSpec(スペック)機能について使用してみた感想をまとめてみます。

Kiroとは

Kiroは、コンセプトからプロダクションまでをAIエージェントと共に進められる、新しい開発者体験を提供するAI IDE（統合開発環境）です。
通常のAI IDEが備えるバイブコーディングはもちろん、Kiroには特徴的な2つの機能があります。
ひとつは、要件定義から設計・タスク分解までを自動で生成する Spec(スペック)機能。
もうひとつは、ファイルの追加や保存などをトリガーに、あらかじめ設定したプロンプトを実行するフック(Hooks)機能があります。
この2つによって、Kiroならではの開発体験を生み出しています。

Kiroは公式サイトから利用を開始できます。
Kiro 公式ページ

今回の目標

今回作成するアプリケーションはToDo管理アプリケーションのバックエンド側のアプリケーションを作成します。
このシンプルなアプリを題材にSpec機能の実力を確認してみます。

アプリの要件は以下の通りです。

  • RESTful APIを作成する
  • 言語は Python 3.13、フレームワークは FastAPI を使用
  • データは PostgreSQL (17.5) に保存可能とする
  • プロジェクトフォルダでは、ToDoアプリのバックエンド部分のみを作成
  • 最終目標は、ローカル環境で Docker 上にアプリケーションを構築し、Swagger UI を通じて動作確認できること
  • 単体テストを実施する

前提条件

アプリ作成に際して使用した環境は以下の通りです。

  • 実行環境：Windows 11 Home
  • Docker 環境を利用
  • Windows のため WSL2 を使用可能であること
  • クライアントツールとして “Rancher Desktop” を使用
  • Python 3.13 をインストール済み（ただし、事前ライブラリは未インストール）

Spec機能を使用してみた

KiroにおけるSpec機能は、要件定義から設計、実装計画を作成し、実装計画を基に開発を行います。
ユーザーは「作りたいアプリの概要」をプロンプトとして入力するだけで、KiroがMarkdown形式で必要な仕様やタスクを整理してくれます。

要件(requirements)の作成

「プロジェクトフォルダを開くと」を開くと、まずはSpec機能で要件を作成します。
Spec を選択し、チャット欄に「作りたいアプリの概要」を入力します。
今回は『今回の目標』で示した内容をプロンプトとして入力しました。

生成された要件は .kiro/specs/<プロジェクト名>/requirements.md にMarkdown形式でまとめられます。
内容を確認し、必要に応じて修正していきます。

requirements.md(一部抜粋)

## 要件定義書
### 概要
Windows11のローカル環境でDockerを使用して動作するToDoアプリケーションのバックエンドAPIを開発する。Python 3.13とFastAPIを使用してRESTful APIを構築し、PostgreSQL 17.5でデータを永続化する。ユーザーはSwagger UIを通じてAPIの動作確認を行うことができる。

### 要件
#### 要件 1: ToDoアイテムの基本CRUD操作
**ユーザーストーリー:** 開発者として、ToDoアイテムの作成、読み取り、更新、削除ができるAPIエンドポイントが欲しい。これにより基本的なToDoアプリケーションの機能を提供できる。
・・・

設計(design)の作成

要件の内容に問題がなければ、次に設計フェーズに移ります。
ここでは要件の内容を元に設計書ファイルを作成します。
生成はとても簡単で、チャット欄の Move to design phase をクリックするだけです。

生成された設計書は.kiro/specs/<プロジェクト名>/design.md にMarkdown形式でまとめられます。
Kiroが生成する設計書は、システム構成図やデータモデル、具体的なエンドポイントといった主要な設計要素に加え、プロジェクト全体のファイル構成や具体的なエラーハンドリング戦略など、開発者がすぐに実装に取り掛かれるための詳細な情報も標準的に含んでいます。
例えば、アプリケーションのレイヤー分割に基づいた推奨ディレクトリ構造や、HTTPステータスコードを用いた具体的なエラーレスポンスの設計までが記述されており、一貫性のある高品質なコードを目指す上でも非常に有用だと感じました。
design.mdの内容は以下のように出力されます。今回は生成された設計の中から特に印象に残った箇所として、
システム構成図やデータスキーマ（テーブル定義）、具体的なエンドポイントを抜粋します。

design.md（書き出し）
設計書の冒頭部分には、プロジェクトの全体像と採用されたアーキテクチャが記述されます。
実際に生成してみると要件の内容を踏まえてまとめていることが確認できました

# 設計書
## 概要
ToDoアプリケーションのバックエンドAPIは、FastAPIフレームワークを使用したRESTful APIとして設計される。システムはレイヤードアーキテクチャを採用し、API層、ビジネスロジック層、データアクセス層に分離される。PostgreSQLデータベースを使用してデータを永続化し、Dockerコンテナ環境で実行される。

design.md（データスキーマ）
データベースのテーブル設計（スキーマ）も自動で生成されます。
通常のカラム設計のみならず、細かなインデックスやDB特有の設計もしてくれることに驚きでした。

### 1. データベーススキーマ

#### todosテーブル

CREATE TABLE todos (
id SERIAL PRIMARY KEY,
title VARCHAR(200) NOT NULL,
description TEXT,
completed BOOLEAN DEFAULT FALSE,
end_date TIMESTAMP WITH TIME ZONE,
created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- パフォーマンス向上のためのインデックス
CREATE INDEX idx_todos_completed ON todos(completed);
CREATE INDEX idx_todos_created_at ON todos(created_at);
CREATE INDEX idx_todos_end_date ON todos(end_date);

-- 複合インデックス：よくある検索パターンを最適化
CREATE INDEX idx_todos_completed_created ON todos(completed, created_at DESC);
CREATE INDEX idx_todos_incomplete_end_date ON todos(completed, end_date);

-- 部分インデックス：未完了タスクのみ（PostgreSQL特有の最適化）
CREATE INDEX idx_todos_incomplete_only ON todos(created_at DESC) WHERE completed = FALSE;

design.md（APIエンドポイント）
RESTful APIの各操作（CRUD）について、メソッド、エンドポイント、リクエスト/レスポンスの具体的なパラメータを設計します。
要件にToDoアプリと指定したため基本的な構造を踏まえつつ、エンドポイントを網羅してくれているため、生成する内容の理解にとても助かります。

### 1. APIエンドポイント

#### ToDoアイテム管理エンドポイント

| メソッド | エンドポイント | 説明 | リクエスト | レスポンス |
|---------|---------------|------|-----------|-----------|
| POST | `/todos` | ToDoアイテム作成（期限設定対応） | `TodoCreate` | `TodoResponse` (201) |
| GET | `/todos` | 全ToDoアイテム取得（期限情報含む） | - | `List[TodoResponse]` (200) |
| GET | `/todos/{id}` | 特定ToDoアイテム取得（期限情報含む） | - | `TodoResponse` (200) |
| PUT | `/todos/{id}` | ToDoアイテム更新（期限変更対応） | `TodoUpdate` | `TodoResponse` (200) |
| DELETE | `/todos/{id}` | ToDoアイテム削除 | - | - (204) |
| GET | `/todos/search` | 条件付きToDoアイテム検索 | Query Parameters | `List[TodoResponse]` (200) |

#### 条件付き検索エンドポイント

**エンドポイント**: `GET /todos/search`

**クエリパラメータ**:
- `completed` (optional): boolean - 完了状態での絞り込み
- `end_date_from` (optional): datetime - 期限開始日時（ISO 8601形式）
- `end_date_to` (optional): datetime - 期限終了日時（ISO 8601形式）
- `skip` (optional): int - ページネーション用スキップ数（デフォルト: 0）
- `limit` (optional): int - 取得件数制限（デフォルト: 100、最大: 1000）

実装計画(tasks)を作成する

設計の内容に問題がなければ、次に実装計画フェーズに進みます。
ここでは、要件と設計をもとに実装計画を生成します。
生成は設計フェーズ同様にとても簡単で、チャット欄の Move to implementation plan をクリックするだけです。

作成された実装計画は .kiro/specs/<プロジェクト名>/tasks.md にMarkdown形式で保存されます。
この内容を確認し、問題がなければチャット欄の Finalize task list をクリックします。
これで次の実装フェーズに進む準備が整います。

tasks.md の内容は以下のようにまとめられています。
tasks.md(一部抜粋)

# 実装計画
- [] 1. プロジェクト構造とコア設定の作成
- プロジェクトディレクトリ構造を作成し、基本的な設定ファイルを実装する
- requirements.txt、Dockerfile、docker-compose.ymlを作成する
- _要件: 4.1, 4.2, 4.3_
- [] 2. データベース設定とモデルの実装
- [] 2.1 データベース接続設定の実装
- SQLAlchemyを使用したデータベース接続設定を作成する
- 環境変数による設定管理を実装する
- _要件: 3.1, 3.3_
- [] 2.2 SQLAlchemyモデルの実装
・・・

タスクを実行する

次にタスクを実行し、実装に必要なプログラムやファイルを生成します。
tasks.md を開き、各タスクの上にある Start task を順にクリックします。

タスクを実行すると、チャット欄にそのタスクで実施する内容が表示されます。
開発者は内容を確認しながら、タスクが完了するまで待ちます。

タスクの実行が完了すると、タスクの先頭にチェック x が入り、進捗を確認できます。
問題がなければ次のタスクの Start task をクリックします。
もし実行したタスクが意図しないものであれば、差し戻すことも可能です。

一部のタスクではコンソールでコマンドが実行されます。
チャット欄に提示されたコマンドに問題なければ Run ボタンをクリックして実行します。

他にもタスク実行ではエラーが出た場合、Kiroは内容を解析して解決策を提示してくれます。
今回のようにライブラリが未インストールの場合も、必要なインストール用コマンドを提示してくれます。

タスクが完了後の確認

全てのタスクが完了したら、Docker上でアプリケーションが正常に動作するか確認します。
Dockerが正常に立ち上がれば、ブラウザから Swagger UI を通じて動作確認が可能です。

まとめ

良かった点

実際に Spec 機能を使ってみて、良かった点は以下の2点です：
– タスク一覧で開始からゴールまでの状況が確認できること
→ タスク完了後は確認とコマンド実行の判断だけで済む
– タスク内容を後からでも確認できること
→ 翌日からでも途中のタスクを簡単に再開できる

注意が必要だと思った点

一方、注意が必要だと感じた点は以下です：

タスクは小さく分けて実行する

今回バックエンドだけを生成しましたが、生成されたコード量が多くなると理解が大変になります。
大きなタスクは分割して実行・確認するのがおすすめです。

単体テストは実施する

生成されたプログラムを単体テストすると、NGとなるケースが多く見られました。
テスト結果に応じてコードを修正したことで、実装タスクではカバーできない問題も解決でき、コードの品質は格段に上がりました。
このため、単体テストをタスクに含めて置くことの有用であると感じました。

使用するモジュールやライブラリは要件・設計段階で明示する

ライブラリやバージョンを要件段階で指定しておかないと、意図しないバージョンのライブラリが使用されることがあります。
もちろん実装後に修正は可能ですが、バージョンの齟齬で修正が必要になる場合があるため、早い段階で確認・指定しておくのが望ましいと感じました。

最後に

今回の体験を通して、Spec機能は効率的にタスク管理や実装計画を進められることを実感しました。
まずは小さなアプリからKiroを試してみると、その強力さを体感できると思います。