![]() |
世界の国からこんにちは。masedatiです。好きな音楽は、椎名林檎 と ずっと真夜中でいいのに。 です。
今回は、AWSが発表した次世代エージェント型IDE「Kiro」を実際に触ってみて、Webアプリケーションを自由工作してみた体験記となります。
👻 Kiroって何?
生成AIの話題が尽きない中、皆さんKiroを触ってみましたでしょうか?
(Kiroで遊ぶことを、私は勝手に「ゴーストダイブ」と呼んでいます)
Kiroは、AIエージェントと協調しながら動作する次世代のエージェント型IDE(統合開発環境)で、開発プロセスを「プロンプト → プロトタイプ → プロダクション」へとシームレスに進化させます 。「vibe coding」での課題であった「実運用への移行への設計の不確実性やドキュメントの欠如」を解決します。最大の特徴は、「Specによる仕様駆動開発」と「Hookによる自動化アシスト」です。
Specはプロンプトから自動でユーザーストーリーや受け入れテスト基準を含む仕様書(スペック)を生成し、Hookによってコードの保存、作成、削除などのタイミングでドキュメントの更新やテスト追加などを自動化を行います。その仕様をもとに、設計や実装のタスクを構造的に自動生成してくれるのが、「Kiro」です。
詳細はAWS公式ブログをご参考ください。
🎯 本記事の要約
いきなりですが、本記事少し長くなるので、以下要約です。
- 開発未経験のインフラエンジニアでもKiroを使って、簡単なWebアプリを作ることができた
- KiroのSpecsモードを活用することで、現場に近い仕様駆動開発を体験できた
- 各工程で感じたメリット
- 要件フェーズ
- 作りたいものに基づく要件の言語化・詳細化と受け入れ基準の自動作成
- 詳細フェーズ
- 構成提案やフロー図作成、エラー処理・テスト方針の自動生成
- 実装計画&構築フェーズ
- タスクに沿った自動構築、エラー発生時の修正提案、ビルド・テスト自動実行
- デプロイ
- CloudFormationを用いた一貫性のあるデプロイ
- デプロイ時のエラーもログ情報から原因特定し、自動で修正
- 要件フェーズ
🎮️ 遊んでみた。
作りたいものを整理する
私は普段、好きな音楽をSpotifyのプレイリストに保存しています。
1つのプレイリストに追加し続けていった結果、現在1010曲と膨大な曲数となってしまいました。
そのため、その日の気分にあった最適な音楽を探すのに時間がかかっています。次の曲へ…次の曲へ…スキップする毎日。
_人人人人人人人人人人_
> これを解決したい <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄
そこで、気分に合わせてSpotifyのプレイリストから打線形式で9曲を選び出すWebアプリを作成します。
Specモードで要件定義から構築まで一気通貫
要件フェーズ
私の要望を以下にまとめました。
# 背景・目的
現在、Spotifyの1つのプレイリストに約1000曲を追加しており、膨大な曲数の中からその日の気分に合う曲を選ぶのが大変。
そのため、気分に応じた「打線形式」での楽曲レコメンドを自動化する、WebアプリケーションPoCを作成したい。
# PoC仕様
* 対象データ
Spotifyの固定IDのプレイリスト(ユーザー本人のもの)
* 気分の入力方法
ラジオボタン形式で選択(例:「元気」「落ち込んでいる」「悲しい」など)
* レコメンドロジック
Spotify APIで取得できる楽曲メタデータを活用
* 出力形式
打線形式で9曲を選出し、Spotify埋め込みプレイヤーで表示
* 打線の生成方法
AWS Bedrockを活用し、曲リストからポジション付きで打順を生成
* 想定ユーザー
開発者本人のみ(PoC目的)
# 想定AWS構成(フルサーバレス)
* フロントエンド
Amazon S3 + CloudFront
* バックエンドAPI
API Gateway + AWS Lambda
* 打線形式の生成(自然言語による楽曲選出と順番付け)
AWS Bedrock
上記をそのまま最初のプロンプトとしてKiroに投げてみます。
数秒で以下のような要件定義書っぽいものを作成してくれました。
# 要件定義書
## 概要
この機能は、ユーザーの現在の気分に基づいてSpotifyプレイリストから野球の打線形式で楽曲推薦を生成するWebアプリケーションを作成します。
システムは固定のSpotifyプレイリストに存在する約1000曲を分析し、ユーザーがラジオボタンで気分を選択できるようにし、AWS Bedrockを使用して9曲を野球の打順形式でインテリジェントに配置し、埋め込みSpotifyプレイヤーで即座に再生できるようにします。
## 要件
### 要件1
**ユーザーストーリー:** 音楽リスナーとして、事前定義された選択肢から現在の気分を選択したい。そうすることで、自分の気持ちに合ったパーソナライズされた楽曲推薦を受けることができる。
#### 受入基準
1. ユーザーがアプリケーションにアクセスした時、システムはラジオボタンオプション付きの気分選択インターフェースを表示する
2. ユーザーが気分オプションを表示した時、システムは「元気」「落ち込んでいる」「悲しい」およびその他の関連する気分を含む少なくとも4つの異なる気分カテゴリを提供する
3. ユーザーが気分オプションを選択した時、システムは選択された選択肢をハイライトし、推薦生成を有効にする
4. 気分が選択されていない場合、システムは推薦生成ボタンを無効にする
### 要件2
**ユーザーストーリー:** 音楽リスナーとして、システムに既存のSpotifyプレイリストを分析してもらいたい。そうすることで、すでに知っていて好きな曲から推薦を受けることができる。
#### 受入基準
1. システムが初期化された時、有効な認証情報を使用してSpotify APIに接続する
2. Spotifyに接続する時、システムは特定の事前定義されたプレイリストIDから楽曲を取得する
3. プレイリストデータを取得する時、システムはオーディオ機能、アーティスト情報、トラック詳細を含む楽曲メタデータを取得する
4. プレイリストに1000曲以上含まれている場合、システムは利用可能なすべての楽曲を処理する
5. APIエラーが発生した時、システムは適切なエラーメッセージと再試行メカニズムを表示する
### 要件3
**ユーザーストーリー:** 音楽リスナーとして、野球の打順形式で配置された9曲の推薦を受けたい。そうすることで、楽しく構造化された方法で音楽を体験できる。
#### 受入基準
1. ユーザーが推薦をリクエストした時、システムは正確に9曲を選択して生成する
2. 推薦を生成する時、システムはAWS Bedrockを使用して楽曲メタデータを分析し、選択された気分に楽曲をマッチングする
3. 楽曲を配置する時、システムは各楽曲を戦略的な理由付きで特定の打順ポジション(1番から9番)に割り当てる
4. 結果を表示する時、システムは各楽曲を打順ポジション、楽曲タイトル、アーティスト、埋め込みSpotifyプレイヤーと共に表示する
5. Bedrock分析が失敗した場合、システムはルールベースの推薦システムにフォールバックする
### 要件4
**ユーザーストーリー:** 音楽リスナーとして、推薦された楽曲をインターフェース内で直接再生したい。そうすることで、推薦をすぐに聴いて評価できる。
#### 受入基準
1. 推薦が表示された時、各楽曲は機能的なSpotify埋め込みプレイヤーを含む
2. ユーザーが埋め込みプレイヤーの再生をクリックした時、楽曲はすぐに再生を開始する
3. 複数のプレイヤーが存在する時、一度に1曲のみが再生される(他は自動一時停止)
4. 楽曲のSpotify埋め込みが失敗した場合、システムはSpotifyで開くリンク付きの楽曲情報を表示する
### 要件5
**ユーザーストーリー:** このPoCをデプロイする開発者として、アプリケーションをAWSサーバーレスインフラストラクチャで実行したい。そうすることで、運用オーバーヘッドとコストを最小化できる。
#### 受入基準
1. フロントエンドをデプロイする時、システムはCloudFrontディストリビューション付きのAmazon S3を静的ホスティングに使用する
2. APIリクエストを処理する時、システムはAWS Lambda関数付きのAPI Gatewayを使用する
3. 推薦を生成する時、システムはAI駆動の楽曲分析と打線生成のためにAWS Bedrockと統合する
4. システムがアイドル状態の時、サーバーレスアーキテクチャにより最小限のコストが発生する
5. いずれかのAWSサービスが利用できない場合、システムは適切な劣化とエラーハンドリングを提供する
ユーザーストーリーと受け入れ基準が明確になり、初期段階で「完了の定義」が揃います。
なんとなく良さそうです!そのまま設計に進もうと思います。
設計フェーズ
requirements.mdに問題なければ、「Move to design phase」ボタンを押せばKiroは設計に進みます。
以下Kiroが考えた設計書です。
# 設計文書
## 概要
Spotify気分別打線推薦システムは、ユーザーの気分に基づいてSpotifyプレイリストから9曲を野球の打線形式で推薦するWebアプリケーションです。
フロントエンドはReactとTypeScriptで動作し、バックエンドはAWSサーバーレス構成で実装されます。
## アーキテクチャ
### システム全体構成
```mermaid
graph TB
subgraph "AWS Cloud"
CF[CloudFront Distribution]
S3[S3 Static Hosting<br/>React Frontend]
AG[API Gateway]
LF1[Lambda Function<br/>Playlist Fetcher]
LF2[Lambda Function<br/>Recommendation Engine]
BR[AWS Bedrock<br/>Claude/GPT]
end
subgraph "外部API"
SP[Spotify Web API]
end
CF --> S3
S3 --> AG
AG --> LF1
AG --> LF2
LF1 --> SP
LF2 --> BR
LF2 --> SP
## テスト戦略
### フロントエンドテスト
1. **単体テスト**: Jest + React Testing Library
- コンポーネントレンダリング
- ユーザーインタラクション
- 状態管理
2. **統合テスト**:
- API通信モック
- エラーハンドリング
- ローディング状態
## パフォーマンス最適化
### フロントエンド最適化
1. **コード分割**: React.lazy()による動的インポート
2. **メモ化**: React.memo()とuseMemo()
3. **画像最適化**: WebP形式とlazy loading
4. **CloudFront最適化**:
- Gzip圧縮有効化
- キャッシュ戦略設定
- エッジロケーション活用
### 監視とログ
1. **CloudWatch**: Lambda実行時間とエラー率
2. **フロントエンド**: パフォーマンス指標収集
3. **アラート**: 異常検知と通知
mermaidでのシステム構成フロー作成からパフォーマンス、セキュリティ設計やテスト方針まで考えてくれています。
【参考】mermaidでのシステム構成フロー図
実施計画フェーズ
「Move to implementation plan」ボタンを押せば、Kiroは実施計画作成に進みます。
実施計画とは、構築手順から統合テスト、デプロイ方法等いわばタスクリストのようなものです。
以下のようなものとなりました。
⚡️Start task [ ] 1. プロジェクト構造とコア設定のセットアップ - Reactプロジェクトの初期化とTypeScript設定 - AWS CDKプロジェクトの初期化とディレクトリ構造作成 - 環境変数管理とSpotify API認証情報設定 - _要件: 2.1, 5.2_ ⚡️Start task [ ] 3. Spotify API統合の実装 - [ ] 3.1 Spotify認証とプレイリスト取得Lambda関数の作成 - OAuth 2.0 Client Credentials Flowの実装 - プレイリストデータ取得機能の実装 - オーディオ特徴量取得機能の実装 - _要件: 2.1, 2.2, 2.3_ - [ ] 3.2 Spotify API統合のテスト作成 - Lambda関数の単体テスト実装 - モックデータを使用したテストケース作成 - エラーハンドリングのテスト - _要件: 2.5_ ⚡️Start task [ ] 4. AWS Bedrock推薦エンジンの実装 - [ ] 4.1 Bedrock統合Lambda関数の作成 - AWS Bedrock Claude/GPTとの統合実装 - 気分ベース楽曲分析ロジックの実装 - 打線形式での楽曲配置ロジックの実装 - _要件: 3.1, 3.2, 3.3_ - [ ] 4.2 ルールベースフォールバック機能の実装 - Bedrock障害時の代替推薦ロジック作成 - 気分マッピングに基づく楽曲フィルタリング実装 - 打順ポジション割り当てアルゴリズムの実装 - _要件: 3.5_ - [ ] 4.3 推薦エンジンのテスト作成 - Bedrock統合の単体テスト実装 - フォールバック機能のテスト - 推薦結果の妥当性検証テスト - _要件: 3.1, 3.5_ ⚡️Start task [ ] 10. 統合テストとエンドツーエンドテストの実装 - [ ] 10.1 フロントエンド統合テストの作成 - コンポーネント間連携テスト - API通信モックテスト - ユーザーフロー全体のテスト - _要件: 1.1, 3.1, 4.1_ ⚡️Start task [ ] 11. パフォーマンス最適化の実装 - [ ] 11.1 フロントエンド最適化 - React.lazy()による動的インポート実装 - メモ化(React.memo, useMemo)の適用 - バンドルサイズ最適化 - _要件: 6.2, 6.3_ - [ ] 11.2 バックエンド最適化 - Lambda関数のコールドスタート最適化 - 接続プーリングの実装 - レスポンス時間改善 - _要件: 6.2_ ⚡️Start task [ ] 12. 最終統合とデプロイメント [ ] 12.1 本番環境デプロイメント - CDKスタックの本番デプロイ実行 - 環境変数と認証情報の本番設定 - DNS設定とドメイン設定(オプション) - _要件: 5.1, 5.2, 5.4_ [] 12.2 動作確認とテスト実行 - 全機能の動作確認テスト - パフォーマンステスト実行 - エラーケースの検証 - _要件: 1.1, 2.1, 3.1, 4.1, 6.2_
要件とリンクした形で実装タスクが12段階で細分化され、生成AIがこれからどのように構築を実行しようとしているのか一目でわかります。
また、Task 3, 4のように各Taskごとにテスト工程が実施されます。このように単体テストや統合テスト、API通信テスト等のテストファイル作成・実施・修正を自動でKiroが行ってくれるのも大きな魅力の一つです。
開発構築フェーズ
あとは実施計画に基づいて開発構築を進めるだけです。tasks.md上の「⚡️Start task」ボタンを押すだけでステップバイステップで構築を進めることができます。
各タスクが完了すると✔️Task completedとなります。例えば、Task 1が完了すると以下のようにKiroから報告があがります。
✔ Task completed
- [x] 1. プロジェクト構造とコア設定のセットアップ
- Reactプロジェクトの初期化とTypeScript設定
- AWS CDKプロジェクトの初期化とディレクトリ構造作成
- 環境変数管理とSpotify API認証情報設定
- _要件: 2.1, 5.2_
✅ 完了したサブタスク:
1. Reactプロジェクトの初期化とTypeScript設定
・frontend/ディレクトリにReact + TypeScriptプロジェクトを作成
・必要な依存関係(axios)をインストール
・TypeScript設定ファイル(tsconfig.json)が自動生成
2. AWS CDKプロジェクトの初期化とディレクトリ構造作成
・infrastructure/ディレクトリにCDKプロジェクトを初期化
・backend/ディレクトリ構造を作成(lambda, types, utils)
・バックエンド用のpackage.jsonとtsconfig.jsonを設定
・必要な依存関係をインストール
3. 環境変数管理とSpotify API認証情報設定
・プロジェクトルートに.env.exampleを作成
・フロントエンド用の.env.exampleを作成
・Spotify API認証情報の設定項目を定義
・AWS設定項目を定義
📁 作成されたプロジェクト構造:
├── frontend/ # React + TypeScript (完了)
├── backend/ # Lambda関数用コード (構造作成完了)
│ ├── src/
│ │ ├── lambda/ # Lambda関数
│ │ ├── types/ # TypeScript型定義 (基本型作成完了)
│ │ └── utils/ # ユーティリティ関数
├── infrastructure/ # AWS CDK (初期化完了)
├── .env.example # 環境変数設定例 (完了)
├── .gitignore # Git設定 (完了)
└── README.md # プロジェクト説明 (完了)
たとえ、Taskでの構築やテスト工程でにエラーが出力されたとしてもKiroは自身でエラー原因を特定し、修正します。
開発知識が不足している私でもスムーズに工程を進めることができました。
そして本番デプロイへ
Task 12終了時のKiroからのメッセージは以下です。
タスク12「最終統合とデプロイメント」完了!
タスク12の両方のサブタスクを完了しました:
✅ 12.1 本番環境デプロイメント
以下のスクリプトとツールを作成しました:
deploy-production.sh - 包括的な本番デプロイメントスクリプト
環境変数の検証
バックエンド・フロントエンド・インフラのビルドとテスト
CDKを使用したAWSリソースのデプロイ
フロントエンドのS3アップロードとCloudFront無効化
setup-production-env.sh - 環境変数設定支援スクリプト
Spotify認証情報の対話的設定
AWS設定の構成
セキュリティベストプラクティスの適用
setup-custom-domain.sh - カスタムドメイン設定スクリプト(オプション)
Route 53とACM証明書の設定支援
CloudFrontカスタムドメイン設定
✅ 12.2 動作確認とテスト実行
包括的なテストスイートを作成しました:
comprehensive-test.sh - 全機能の動作確認
ユニットテストとインテグレーションテスト
API機能テスト
フロントエンドテスト
セキュリティテスト
モニタリング確認
performance-test.sh - パフォーマンステスト
レスポンス時間測定
同時リクエスト処理テスト
スループットテスト
リソース使用量分析
コールドスタート分析
error-case-test.sh - エラーケース検証
無効なパラメータテスト
HTTPメソッドエラーテスト
レート制限テスト
セキュリティ攻撃テスト
エッジケーステスト
run-all-tests.sh - マスターテストランナー
全テストスイートの統合実行
詳細なレポート生成
結果の集約と分析
quick-verification.sh - クイック検証スクリプト
デプロイ後の基本動作確認
スモークテスト
🎯 要件対応状況
要件5.1, 5.2, 5.4(本番環境デプロイ):
✅ CDKスタックの本番デプロイ実行
✅ 環境変数と認証情報の本番設定
✅ DNS設定とドメイン設定(オプション対応)
要件1.1, 2.1, 3.1, 4.1, 6.2(動作確認):
✅ 全機能の動作確認テスト
✅ パフォーマンステスト実行
✅ エラーケースの検証
🚀 次のステップ
本番デプロイメントを実行するには:
環境設定: ./setup-production-env.sh
デプロイ実行: ./deploy-production.sh
動作確認: ./quick-verification.sh
包括的テスト: ./run-all-tests.sh
これでSpotify Mood Lineupアプリケーションの本番環境への完全なデプロイメントと検証が可能になりました!
今回本番デプロイは、環境設定⇒デプロイ実行⇒動作確認⇒包括的テストの順番でスクリプトを実施すればよさそうです。
環境設定スクリプトでは、デプロイ先のAWSアカウントやSpotify Playlist ID等を入力しました。
🎉 完成
前述のスクリプト実施時にいくつかのエラー※が発生し、すぐにデプロイ完了とはならなかったのですが、Kiroとの対話を重ねることで無事Webアプリケーションの動作を確認することができました!
最初のプロンプトに記載のとおり、「気分の入力方法⇒ラジオボタン形式で選択(例:「元気」「落ち込んでいる」「悲しい」など)」が実装されています。
「打線を生成する」ボタンを押すと。。。
本日の気分に基づきスタメンが発表されます。
それでは、「元気」なメンバーを紹介して終わりにしようと思います。
1 中 フラットウッズのモンスターみたいに(Eve, Deu)
2 二 フロントメモリー - の子vo.ver(Shinsei Kamattechan)
3 遊 ミッドナイト・リフレクション(NOMELON NOLEMON)
4 左 海馬成長痛(ZUTOMAYO)
5 一 夢(The Rolling Girls)
6 三 勝手にシンドバッド(サザンオールスターズ)
7 捕 ゴーストダイブ(POLKADOT STINGRAY)
8 右 ミス・パラレルワールド (Soutaiseiriron)
9 投 お勉強しといてよ(ZUTOMAYO)
まとめ
アプリ開発未経験者が数時間でここまで構築することができました!
これは業務で取り入れたら、開発速度が爆速になりそうです。
しかし、改めて私の開発知識の無さを痛感しました。(恥ずかしながらKiroが何をやっているのか理解できていない…)
今回は生成AIを全面的に信頼しましたが、本来であれば要件定義・設計書・実施計画・詳細手順の正否は人間が判断を行うべきと考えています。
何が正しくて、何が誤っているのか、判断できるよう引き続き研鑽を積みたいと思います。
Appendix
アーキテクチャ図
Kiroは「Claude Sonnet 3.7/4.0」で動いており、指示を出せばアーキテクチャ図出力も可能です。
以下はClaude Sonnet 4.0が作成したアーキテクチャ図となります。(修正なし)
Amazon CloudFrontの色が公式と異なるといった点など修正ポイントはありますが、綺麗なアーキテクチャ図を生成してくれました。
デプロイスクリプトでのエラーについて
本番デプロイの際に判明したのですが、楽曲の雰囲気情報(danceability、acousticness など)を取得できる Spotify API(audio_features)が、2024年11月に廃止されていました。
この情報は Kiro 側でも把握されておらず、原因不明のエラーとして私を悩ませることに。今回の本番デプロイでは、雰囲気パラメータを一時的にランダムな数値に置き換えて対応しました。
せっかく作成したアプリなので、今後は代替策を探りつつ、Kiro 側が提示した要件定義や設計書はやはりレビューしておくべきだと強く感じた出来事でした。