はじめに
2025/12/03、AWS re:Invent期間中にKiroにPowersという機能が発表されました。
今回はこのPowersの紹介と、軽く検証してみた記事となります！
Kiro Powersとは？
私は最初に以下の動画で概要を把握しました。
AWS re:Invent 2025 - Accelerate development with Kiro's new agentic AI capabilities (DVT228)
また以下の記事でも紹介されています。
少しまとめさせていただくと、
Kiro Powersは、元々備わっていたステアリング、フック、MCP機能を一つにまとめた機能です。
動画の説明によると、AIエージェントが「何でも屋（ジェネラリスト）」であるがゆえに抱える専門知識の欠如や、過剰な情報による「コンテキストの腐敗（Context Rot）」といった一般的な問題を以下のアプローチで解決してくれるみたいです。
1. 「コンテキストの腐敗」を防ぐprogressive disclosure
Kiro Powersをインストールしても、初期状態ではエージェントはそのパワー（特定の技術やツール）が「利用可能である」という最小限の情報しか受け取りません。
ユーザーがAPIやデータベースに関連する質問をしたときなど、特定のキーワードやタスクが発生した時点ではじめて、エージェントが自動的に適切なKiro Powersを検出し、詳細なコンテキストやツールをロードします。
これにより、エージェントを圧倒することなく、必要な専門能力を拡張することが可能になります。
2. 「Steering」による専門知識と手順の強制
単にツール（MCP）を与えるだけでは、エージェントはその使い方がわからなかったり、手順を飛ばしたり、誤った使い方をすることがあります。
AIモデルの学習データが古く、最新のSDKやフレームワークに対応していない場合も多々あります。
そのため、Kiro Powersは、power.mdというマークダウンファイル（Steeringファイル）を含めることで、エージェントに対する「オンボーディングマニュアル」を提供します。
3. MCPとHooksによる実環境との連携・自動化
Kiro Powersは、指示書だけでなく実際の操作を行うためのMCP（ツール）と、開発ライフサイクルに介入する「Hooks（フック）」を統合しています。
動画ではPostmanの事例が紹介されていました。
ファイルの保存を検知し、自動的に変更後のソースでPostmanで作ったモック環境での試験を実施するような感じです。
では試してみます。
今回はシンプルなAPIを構築しながら、Kiro Powersを使ってみます。
Kiro Powers（Postman API Testing）のインストール
Postman API Testingの設定
Try powerを選択すると、内容の紹介や必要な初期設定をしてくれます。
最初は全部英語なので、私は「日本語で進めて！」とお願いして対応しています。
私が試した際は以下のような対応をしてくれました。
1. Postman Powerの有効化確認
PostmanのPowerが有効になっているかを確認します。
2. Postmanパワーの概要の説明
以下のような説明をしてくれました。
Postmanパワーは、API開発とテストを自動化するための強力なツールです。以下のことができます：
主な機能：
ワークスペース管理 - プロジェクト用のワークスペースを作成・管理
コレクション管理 - APIリクエストをまとめたコレクションを作成・実行
環境管理 - 開発・ステージング・本番環境の変数を管理
モックサーバー - APIのモックを作成してテスト
API仕様書 - OpenAPI仕様書からコレクションを自動生成
自動テスト実行 - コレクションを実行してAPIの動作を検証
3. オンボーディング手順
以下のステップでオンボーディングをします。
ステップ1: Postman APIキーの設定
ステップ2: 自動テスト用フックの作成
MCPの設定、hooksの設定などをしてくれます。
ここでAPIキーなどを設定し、MCPが利用できるようにします。
4. 簡単な使用例
実際にKiroがMCPを使い、コレクションを作成するなどし、問題なければ完了になります。
MCPのツールの使用許可を出すくらいで特にすることはないです。
5. 設定の完了とまとめ
最後にまとめを表示してくれました。
設定完了とまとめ
✅ Postmanパワーの設定が完了しました！
確認できたこと：
✅ Postman APIキーが正常に動作
✅ ワークスペース「My Workspace」が利用可能
✅ 既存のコレクション「User API」と「AppRunner」を確認
✅ 自動テスト用フックを作成
✅ 新しい環境「ローカル開発環境」を作成
✅ コレクション実行のテスト（APIサーバー未起動のため失敗は正常）
次にできること：
APIサーバーを起動してからコレクションを実行
新しいAPIリクエストをコレクションに追加
OpenAPI仕様書からコレクションを自動生成
モックサーバーを作成してAPIをテスト
何か特定のAPIをテストしたい場合や、新しいコレクションを作成したい場合は、お気軽にお声かけください！
Hookの設定を確認してみると、以下のような感じでした。
ソースコードの変更を検知し、自動でPostmanコレクションのテストを実施してくれるみたいですね。
なお、ステアリングファイルはKiro上で確認できません。
確認してみると、~/.kiro/powersは以下に作成されてました。
Specモードでの開発準備
以下のようなプロンプトで、開発を開始します。
簡単なユーザ管理のAPIを作成したい。
ユーザの登録および、登録情報の取得のみです。
データは永続化する必要はないので、インメモリで管理してください。
以下の要件定義を作ってくれたので、そのまま採用します。
# 要件文書
## 概要
シンプルなユーザ管理APIシステム。ユーザの登録と登録情報の取得機能を提供し、データはインメモリで管理する。
## 用語集
- **User_Management_System**: ユーザの登録と情報取得を行うAPIシステム
- **User**: システムに登録されるユーザエンティティ
- **Registration**: 新しいユーザをシステムに追加するプロセス
- **User_Information**: ユーザに関連付けられたデータ（ID、名前、メールアドレスなど）
- **In_Memory_Storage**: データベースを使用せず、アプリケーションのメモリ内でデータを保持する方式
## 要件
### 要件 1
**ユーザストーリー:** 開発者として、新しいユーザを登録できるAPIエンドポイントが欲しい。これにより、ユーザ情報をシステムに保存できる。
#### 受入基準
1. WHEN 開発者が有効なユーザ情報でPOSTリクエストを送信する THEN User_Management_System SHALL 新しいUserを作成し、一意のIDを割り当てる
2. WHEN ユーザ登録が成功する THEN User_Management_System SHALL 201ステータスコードと作成されたユーザ情報を返す
3. WHEN 開発者が無効なユーザ情報を送信する THEN User_Management_System SHALL 400ステータスコードとエラーメッセージを返す
4. WHEN 同じメールアドレスで複数回登録を試行する THEN User_Management_System SHALL 409ステータスコードとエラーメッセージを返す
### 要件 2
**ユーザストーリー:** 開発者として、登録済みユーザの情報を取得できるAPIエンドポイントが欲しい。これにより、ユーザ詳細を確認できる。
#### 受入基準
1. WHEN 開発者が有効なユーザIDでGETリクエストを送信する THEN User_Management_System SHALL 該当するUser_Informationを返す
2. WHEN 存在しないユーザIDでリクエストを送信する THEN User_Management_System SHALL 404ステータスコードとエラーメッセージを返す
3. WHEN ユーザ情報の取得が成功する THEN User_Management_System SHALL 200ステータスコードとユーザ情報を返す
### 要件 3
**ユーザストーリー:** 開発者として、全ての登録済みユーザの一覧を取得できるAPIエンドポイントが欲しい。これにより、システム内の全ユーザを確認できる。
#### 受入基準
1. WHEN 開発者がユーザ一覧のGETリクエストを送信する THEN User_Management_System SHALL 全てのUser_Informationのリストを返す
2. WHEN ユーザが登録されていない場合 THEN User_Management_System SHALL 空のリストと200ステータスコードを返す
3. WHEN ユーザ一覧の取得が成功する THEN User_Management_System SHALL 200ステータスコードとユーザリストを返す
### 要件 4
**ユーザストーリー:** システム管理者として、データがメモリ内で適切に管理されることを確認したい。これにより、永続化なしでシンプルな運用ができる。
#### 受入基準
1. WHEN User_Management_System が起動する THEN システムは空のIn_Memory_Storageで初期化される
2. WHEN アプリケーションが再起動される THEN 以前に登録されたUser_Informationは失われる
3. WHEN 複数のユーザが同時に登録される THEN User_Management_System SHALL データの整合性を保持する
4. WHEN メモリ内でユーザデータを管理する THEN User_Management_System SHALL 各Userに一意のIDを割り当てる
```
設計については以下の注文をし、下記のような形になりました。
* フレームワークはHonoを使うこと
* OpenAPI形式のyamlを使ったAPI定義を作ること
```markdown:design.md
# 設計文書
## 概要
ユーザ管理APIは、Honoフレームワークを使用したRESTful APIとして実装されます。データはJavaScriptのMapオブジェクトを使用してインメモリで管理し、ユーザの登録、取得、一覧表示機能を提供します。OpenAPI 3.0仕様に基づいたYAML形式のAPI定義を含みます。
## アーキテクチャ
```
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Hono Routes │───▶│ Handlers │───▶│ Services │
│ + OpenAPI │ │ │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│
▼
┌─────────────────┐
│ In-Memory │
│ Storage │
│ (Map) │
└─────────────────┘
```
### レイヤー構成
- **Hono Routes + OpenAPI**: HTTPリクエストのルーティングとAPI仕様定義
- **Handlers**: リクエスト/レスポンスの処理とバリデーション
- **Services**: ビジネスロジックの実装
- **Storage**: インメモリデータストレージ
## コンポーネントとインターフェース
### 1. User Model
```typescript
interface User {
id: string;
name: string;
email: string;
createdAt: Date;
}
interface CreateUserRequest {
name: string;
email: string;
}
```
### 2. UserService
```typescript
interface UserService {
createUser(userData: CreateUserRequest): User;
getUserById(id: string): User | null;
getAllUsers(): User[];
isEmailExists(email: string): boolean;
}
```
### 3. API Endpoints (Hono Routes)
- `POST /api/users` - ユーザ登録
- `GET /api/users/:id` - 個別ユーザ取得
- `GET /api/users` - 全ユーザ一覧取得
### 4. OpenAPI仕様
API定義はOpenAPI 3.0形式のYAMLファイルで管理され、以下を含みます：
- エンドポイント定義
- リクエスト/レスポンススキーマ
- バリデーションルール
- エラーレスポンス定義
### 5. Error Response Format
```typescript
interface ErrorResponse {
error: string;
message: string;
statusCode: number;
}
```
## データモデル
### User Entity
- **id**: 一意識別子（UUID v4形式）
- **name**: ユーザ名（必須、1-100文字）
- **email**: メールアドレス（必須、有効な形式、一意）
- **createdAt**: 作成日時（自動設定）
### Storage Structure
```typescript
// インメモリストレージ
const users: Map<string, User> = new Map();
const emailIndex: Set<string> = new Set(); // 重複チェック用
```
## 正確性プロパティ
*プロパティとは、システムの全ての有効な実行において真であるべき特性や動作です。本質的に、システムが何をすべきかについての形式的な記述です。プロパティは、人間が読める仕様と機械で検証可能な正確性保証の橋渡しとして機能します。*
### プロパティ 1: ユーザ作成の成功レスポンス
*任意の*有効なユーザデータに対して、ユーザ作成は201ステータスコードを返し、一意のIDを持つ新しいユーザを作成し、作成されたユーザ情報をレスポンスに含むべきです
**検証対象: 要件 1.1, 1.2**
### プロパティ 2: 無効データの拒否
*任意の*無効なユーザデータ（空の名前、無効なメール形式など）に対して、システムは400ステータスコードとエラーメッセージを返すべきです
**検証対象: 要件 1.3**
### プロパティ 3: メールアドレスの一意性
*任意の*既に登録されているメールアドレスに対して、同じメールでの再登録は409ステータスコードとエラーメッセージを返すべきです
**検証対象: 要件 1.4**
### プロパティ 4: ユーザ取得の成功レスポンス
*任意の*存在するユーザIDに対して、ユーザ取得は200ステータスコードと正しいユーザ情報を返すべきです
**検証対象: 要件 2.1, 2.3**
### プロパティ 5: 存在しないユーザの処理
*任意の*存在しないユーザIDに対して、システムは404ステータスコードとエラーメッセージを返すべきです
**検証対象: 要件 2.2**
### プロパティ 6: ユーザ一覧の完全性
*任意の*システム状態において、ユーザ一覧取得は200ステータスコードと、システム内の全てのユーザを含むリストを返すべきです
**検証対象: 要件 3.1, 3.3**
### プロパティ 7: 同時実行でのデータ整合性
*任意の*複数の並行ユーザ登録操作において、全ての操作が完了した後、各ユーザは一意のIDを持ち、データの整合性が保たれるべきです
**検証対象: 要件 4.3, 4.4**
## エラーハンドリング
### エラータイプ
1. **バリデーションエラー** (400): 無効な入力データ
2. **重複エラー** (409): 既存メールアドレスでの登録試行
3. **リソース未発見エラー** (404): 存在しないユーザIDでの取得試行
4. **サーバーエラー** (500): 予期しない内部エラー
### エラーレスポンス形式
```json
{
"error": "ValidationError",
"message": "Invalid email format",
"statusCode": 400
}
```
## テスト戦略
### デュアルテストアプローチ
このシステムでは、単体テストとプロパティベーステストの両方を使用します：
- **単体テスト**: 具体的な例、エッジケース、エラー条件を検証
- **プロパティベーステスト**: 全ての入力にわたって保持されるべき普遍的なプロパティを検証
両者は補完的であり、包括的なカバレッジを提供します：単体テストは具体的なバグを捕捉し、プロパティテストは一般的な正確性を検証します。
### プロパティベーステスト要件
- **テストライブラリ**: fast-check（JavaScript/TypeScript用）を使用
- **実行回数**: 各プロパティテストは最低100回の反復を実行
- **タグ付け**: 各プロパティベーステストは設計文書の正確性プロパティを明示的に参照
- **タグ形式**: `**Feature: user-management-api, Property {number}: {property_text}**`
- **実装**: 各正確性プロパティは単一のプロパティベーステストで実装
### 技術スタック
- **フレームワーク**: Hono（軽量で高速なWebフレームワーク）
- **ランタイム**: Node.js または Bun
- **API仕様**: OpenAPI 3.0 (YAML形式)
- **バリデーション**: Honoの組み込みバリデーション + OpenAPIスキーマ
- **テスト**: Vitest + fast-check
- **型定義**: TypeScript
### 単体テスト要件
単体テストは以下をカバーします：
- 具体的な例による正しい動作の実証
- コンポーネント間の統合ポイント
- 重要なエッジケースとエラー条件
### テスト実装ガイドライン
- 新機能の実装時は単体テストとプロパティベーステストの両方を作成
- 既存のテストファイルを確認し、重複を避ける
- 実際の機能を検証し、モックやフェイクデータでテストを通すことは避ける
- テストは核となる機能ロジックと重要なエッジケースに焦点を当てる
最後にタスクリストを確認します。
タスクは以下の通り、先にMVPを作るか、全て作るかを選択できますが、今回はコア機能のみ作成するようにします。
# 実装計画
- [ ] 1. プロジェクト構造とコアインターフェースの設定
- Honoプロジェクトのディレクトリ構造を作成
- TypeScript設定とビルド環境の構築
- テストフレームワーク（Vitest + fast-check）の設定
- _要件: 4.1_
- [ ] 2. OpenAPI仕様の定義
- [ ] 2.1 OpenAPI YAML ファイルの作成
- API エンドポイント定義（POST /api/users, GET /api/users/:id, GET /api/users）
- リクエスト/レスポンススキーマの定義
- エラーレスポンス形式の定義
- _要件: 1.1, 1.2, 1.3, 1.4, 2.1, 2.2, 2.3, 3.1, 3.2, 3.3_
- [ ] 3. データモデルとバリデーションの実装
- [ ] 3.1 User型とCreateUserRequest型の定義
- TypeScriptインターフェースの作成
- バリデーション関数の実装（メール形式、必須フィールド）
- _要件: 1.3, 1.4_
- [ ]* 3.2 データモデルのプロパティテスト
- **プロパティ 2: 無効データの拒否**
- **検証対象: 要件 1.3**
- [ ] 4. インメモリストレージサービスの実装
- [ ] 4.1 UserServiceクラスの実装
- Map ベースのインメモリストレージ
- ユーザ作成、取得、一覧表示メソッド
- メールアドレス重複チェック機能
- UUID生成による一意ID割り当て
- _要件: 1.1, 1.4, 2.1, 3.1, 4.3, 4.4_
- [ ]* 4.2 ユーザ作成成功のプロパティテスト
- **プロパティ 1: ユーザ作成の成功レスポンス**
- **検証対象: 要件 1.1, 1.2**
- [ ]* 4.3 メールアドレス一意性のプロパティテスト
- **プロパティ 3: メールアドレスの一意性**
- **検証対象: 要件 1.4**
- [ ]* 4.4 同時実行データ整合性のプロパティテスト
- **プロパティ 7: 同時実行でのデータ整合性**
- **検証対象: 要件 4.3, 4.4**
- [ ] 5. Honoルートハンドラーの実装
- [ ] 5.1 ユーザ登録エンドポイント（POST /api/users）
- リクエストバリデーション
- ユーザ作成処理
- 適切なHTTPステータスコードとレスポンス
- _要件: 1.1, 1.2, 1.3, 1.4_
- [ ] 5.2 個別ユーザ取得エンドポイント（GET /api/users/:id）
- パラメータバリデーション
- ユーザ検索処理
- 404エラーハンドリング
- _要件: 2.1, 2.2, 2.3_
- [ ] 5.3 ユーザ一覧取得エンドポイント（GET /api/users）
- 全ユーザ取得処理
- 空リストの適切な処理
- _要件: 3.1, 3.2, 3.3_
- [ ]* 5.4 ユーザ取得成功のプロパティテスト
- **プロパティ 4: ユーザ取得の成功レスポンス**
- **検証対象: 要件 2.1, 2.3**
- [ ]* 5.5 存在しないユーザ処理のプロパティテスト
- **プロパティ 5: 存在しないユーザの処理**
- **検証対象: 要件 2.2**
- [ ]* 5.6 ユーザ一覧完全性のプロパティテスト
- **プロパティ 6: ユーザ一覧の完全性**
- **検証対象: 要件 3.1, 3.3**
- [ ] 6. エラーハンドリングとミドルウェアの実装
- [ ] 6.1 グローバルエラーハンドラーの作成
- 統一されたエラーレスポンス形式
- 適切なHTTPステータスコード設定
- _要件: 1.3, 1.4, 2.2_
- [ ] 6.2 バリデーションミドルウェアの実装
- OpenAPIスキーマとの統合
- リクエストデータの自動バリデーション
- _要件: 1.3_
- [ ] 7. Honoアプリケーションの統合
- [ ] 7.1 メインアプリケーションファイルの作成
- Honoアプリインスタンスの設定
- ルートとミドルウェアの登録
- OpenAPI統合の設定
- _要件: 4.1_
- [ ]* 7.2 統合テストの作成
- エンドツーエンドAPIテスト
- 全エンドポイントの動作確認
- _要件: 1.1, 1.2, 1.3, 1.4, 2.1, 2.2, 2.3, 3.1, 3.2, 3.3_
- [ ] 8. チェックポイント - 全テストの実行確認
- 全てのテストが通ることを確認し、問題があれば質問する
- [ ] 9. 開発サーバーとドキュメント設定
- [ ] 9.1 開発サーバーの設定
- Honoアプリケーションの起動スクリプト
- 開発用設定とホットリロード
- _要件: 4.1_
- [ ]* 9.2 API ドキュメント生成の設定
- OpenAPI仕様からのドキュメント自動生成
- Swagger UI または類似ツールの統合
- [ ] 10. 最終チェックポイント - 全テストの実行確認
- 全てのテストが通ることを確認し、問題があれば質問する
開発開始！
では、タスクリストに沿って開発していきます。
1. プロジェクト構造とコアインターフェースの設定
このタスクで、userのインターフェースや、基本的なディレクトリ構成ができました。
この時点で、hookが動作し、設計書をベースにコレクションを作成してくれました。
この時点でPostmanを確認すると、すでにコレクションができていることが確認できます！
2. OpenAPI仕様の定義
ここでタスクは以下のようなI/F定義を作ってくれますね。
Hookはここで以下のような動作をしました。
まだAPIの実装ができていないので、テストが失敗し、そこから実装まで進めてしまいました。
理由を聞いてみました。うーん。Hookの調整が必要かな？
3. データモデルとバリデーションの実装以降
これ以降、タスクは特に問題なく進んでいくのですが、Hookは常にコレクションのテスト実施→失敗→対策・・・といった動きをします。
RunCollectionで毎回コレクションを実行しますが、そもそもまだ公開前なので、リモートからlocalhost上のサーバーでテストできません。
同じ動作を繰り返してしまうのはおそらく、Hookごとにコンテキストが継承されていないみたいですね。
なお、対策の中でモックサーバも作ってくれていました。
が、複数モックサーバを構築していたりもしました。
まとめ
私のプロンプトが悪いせいか、Hookがなかなか思うようには動いてくれませんでした。
Hookは初期状態ではファイルを保存するたびにコレクションのテストを実施する設定なのですが、クラウド上で動くため、どこかにデプロイしないといけない感じです。
このあたりのアプローチを自動的に提案してくれるといいかなと感じました。
冒頭で紹介した動画を見ても、Hookも条件をカスタマイズしてそうですね。
ただし、KiroIDEから離れることなく、Postmanのコレクション・モックサーバを作成・更新できることはとても魅力的だなと感じました！