はじめに
こんにちは。Tsukasaです!
皆さん、Kiroは触ったことありますか?
私の記憶だと7月頃突如リリースされて現れたような印象がありましたが、当時は物凄い人気だったので、敢えて9月まで待ってみました。
今回はKiroを実際に触ってみたので、その内容を記事にしていこうと思います。
Kiroとは
そもそもKiroとは何でしょうか?
リリースされた頃、調べてはみたのですが、イマイチよくわかりませんでした。
ChatGPTに聞いてもリリースされたばかりでデータがなかったので、かなり頓珍漢な回答が返ってきたことを覚えています。
Kiroでできることは主に以下のようなものになります。
コーディング支援
コードの作成・修正・最適化
バグ検出・デバッグ
テストコード生成・コードレビュー
インフラ構築
AWS / Docker / Kubernetes の設定サポート
CI/CD パイプラインの構築
IaC(CloudFormation / Terraform)の作成
プロジェクト管理
仕様書や要件定義の作成・管理
設計〜実装計画のサポート
タスクの段階的実行
開発ツール
CLIコマンド実行
ファイル操作・構造管理
自動化スクリプト作成
因みにこの内容はKiro自身に聞きました!
ざっと整理すると、開発に必要な工程をKiro一つで全てやってくれるものという認識で良いかなと思います。
公式のドキュメントも載せておくので、気になる方は是非ご覧ください。
余談ですが、最初私もKiroと聞いた時頭に浮かんだのは「もう大丈夫心配ないと、泣きそうな私の側で」という沖縄出身の有名な歌手の代表曲の1フレーズでした!笑
わかる方にはわかるかと思います!
Kiroの使い方
Kiroを使うためにはまずKiroをダウンロードする必要があります。
下記のリンクからダウンロードできるので、興味のある方はこちらからお願いします。
Kiroはダウンロードをしただけでは使えません。
使うためには申請が必要になります。
このような画面に遷移した際に注意すべきことがあります。
ログイン方法をBuilders IDにしてしまうと、いかにも使えそうなUIに遷移します。
使っていただくとわかりますが、何をKiroに聞いてもエラーとなります。
そのため、ここではGithubやGoogleでログインをする必要があります。
キャプチャは撮り忘れたのですが、その後Kiroのコードを入力する画面に遷移しますので、コードを持っていない方は、コード入力画面をクリックして申請をします。
その後、申請が終わると下記のように申請完了画面が表示されます。

Kiroの申し込みから許可が降りるまでは、2週間〜1ヶ月程かかるそうです。
※私は2週間かかりました。
メールにコードが付いているので、そのコードを入力すると使えるようになります。
実際にKiroを使ってみた
ここまで来たら使えるようになるので、実際に使ってみました!
まずは冒頭でも紹介しましたが、Kiroがそもそも何なのか?という質問をKiro自身にしてみました。
Kiroで3層ウェブアーキテクチャを作ってみた
Kiroが無事に使えることを確認したので、早速他のことをやってみました。
今回はKiroを用いて3層ウェブアーキテクチャを構築してみました。
ゴールとしては最終的にブラウザにHello World!と表示させられればOKです。
開発をする上で一番最初にやることとは何でしょうか?
そうです。要件定義ですよね。
まずは要件定義を行います。
Kiroは要件定義も作ってくれるので、下記の画像のように要件定義の作成をお願いしてみました。
こちらが完成した要件定義書です。
# 要件定義書
## はじめに
AWS上に3層Webアーキテクチャを構築し、シンプルな「Hello World!」メッセージを表示するWebアプリケーションを開発します。このプロジェクトは、プレゼンテーション層、アプリケーション層、データ層の3つの層で構成される標準的なWebアーキテクチャの実装を目的としています。
## 要件
### 要件1: プレゼンテーション層の実装
**ユーザーストーリー:** ユーザーとして、Webブラウザからアプリケーションにアクセスして「Hello World!」メッセージを表示したい。これにより、アプリケーションが正常に動作していることを確認できる。
#### 受入基準
1. ユーザーがWebブラウザでアプリケーションのURLにアクセスした時、システムは「Hello World!」メッセージを含むHTMLページを表示すること
2. Webページが10秒以内に読み込まれること
3. レスポンシブデザインでモバイルデバイスでも適切に表示されること
4. HTTPSでの安全な接続が提供されること
### 要件2: アプリケーション層の実装
**ユーザーストーリー:** システム管理者として、ビジネスロジックを処理するアプリケーションサーバーを構築したい。これにより、フロントエンドとデータベース間の処理を適切に管理できる。
#### 受入基準
1. フロントエンドからのリクエストを受信した時、アプリケーションサーバーは適切なレスポンスを返すこと
2. アプリケーションサーバーがデータベースから情報を取得できること
3. 複数のリクエストを同時に処理できること
4. アプリケーションサーバーが異常終了した場合、自動的に再起動されること
5. ログが適切に記録されること
### 要件3: データ層の実装
**ユーザーストーリー:** システム管理者として、アプリケーションデータを安全に保存・管理するデータベースを構築したい。これにより、データの永続化と整合性を保証できる。
#### 受入基準
1. アプリケーションサーバーからのデータベース接続要求があった時、システムは安全な接続を提供すること
2. データベースが高可用性を保つため、複数のアベイラビリティゾーンに配置されること
3. データベースへの不正アクセスを防ぐため、プライベートサブネットに配置されること
4. データベースの自動バックアップが設定されること
5. データベースの監視とアラート機能が設定されること
### 要件4: インフラストラクチャとセキュリティ
**ユーザーストーリー:** システム管理者として、スケーラブルで安全なインフラストラクチャを構築したい。これにより、トラフィックの増減に対応し、セキュリティを確保できる。
#### 受入基準
1. 負荷分散器がトラフィックを複数のアプリケーションサーバーに分散すること
2. Auto Scalingによりトラフィック量に応じてサーバー数が自動調整されること
3. 各層が適切なセキュリティグループで保護されること
4. データベースがパブリックインターネットから直接アクセスできないこと
5. CloudWatchによる監視とログ収集が設定されること
### 要件5: 運用と保守
**ユーザーストーリー:** 運用担当者として、システムの状態を監視し、問題が発生した際に迅速に対応したい。これにより、システムの安定稼働を維持できる。
#### 受入基準
1. システムの稼働状況がダッシュボードで確認できること
2. 異常が発生した時、アラート通知が送信されること
3. ログファイルが適切に管理・保存されること
4. システムのパフォーマンスメトリクスが収集されること
5. 定期的なヘルスチェックが実行されること
しっかりAWSを用いた要件になっていますね!
要件定義書に続いて設計書の作成もやってみます。
設計書の作成
Kiroに設計書の作成もお願いしてみました。
下記のような設計書が出来上がりました。
設計書
概要
AWS上に構築する3層Webアーキテクチャは、プレゼンテーション層(Web層)、アプリケーション層(App層)、データ層(DB層)で構成されます。各層は独立してスケールでき、高可用性とセキュリティを確保した設計となっています。
アーキテクチャ
全体構成図
ネットワーク設計
VPC構成
- VPC CIDR: 10.0.0.0/16
- アベイラビリティゾーン: 2つのAZ(us-east-1a, us-east-1b)
サブネット設計
-
パブリックサブネット:
- Public Subnet 1: 10.0.1.0/24 (us-east-1a)
- Public Subnet 2: 10.0.2.0/24 (us-east-1b)
-
プライベートサブネット(Web層):
- Private Web Subnet 1: 10.0.11.0/24 (us-east-1a)
- Private Web Subnet 2: 10.0.12.0/24 (us-east-1b)
-
プライベートサブネット(App層):
- Private App Subnet 1: 10.0.21.0/24 (us-east-1a)
- Private App Subnet 2: 10.0.22.0/24 (us-east-1b)
-
プライベートサブネット(DB層):
- Private DB Subnet 1: 10.0.31.0/24 (us-east-1a)
- Private DB Subnet 2: 10.0.32.0/24 (us-east-1b)
コンポーネントとインターフェース
プレゼンテーション層(Web層)
Application Load Balancer (ALB)
- 目的: トラフィックの負荷分散とSSL終端
-
設定:
- リスナー: HTTPS (443), HTTP (80 → 443リダイレクト)
- ターゲットグループ: Web層のEC2インスタンス
- ヘルスチェック: /health エンドポイント
Web Server (EC2)
- インスタンスタイプ: t3.micro (開発用)、t3.small (本番用)
- AMI: Amazon Linux 2
-
ソフトウェア:
- Nginx (リバースプロキシ)
- Node.js (フロントエンドサーバー)
-
Auto Scaling:
- 最小: 2インスタンス
- 最大: 6インスタンス
- 目標CPU使用率: 70%
アプリケーション層(App層)
Application Server (EC2)
- インスタンスタイプ: t3.small (開発用)、t3.medium (本番用)
- AMI: Amazon Linux 2
-
ソフトウェア:
- Java 11 (OpenJDK)
- Spring Boot アプリケーション
-
Auto Scaling:
- 最小: 2インスタンス
- 最大: 4インスタンス
- 目標CPU使用率: 70%
API設計
-
エンドポイント:
/api/hello - メソッド: GET
-
レスポンス:
{ "message": "Hello World!", "timestamp": "2024-01-01T12:00:00Z", "server": "app-server-1" }
データ層(DB層)
RDS MySQL
- エンジン: MySQL 8.0
- インスタンスクラス: db.t3.micro (開発用)、db.t3.small (本番用)
- Multi-AZ: 有効(高可用性)
- ストレージ: 20GB GP2(自動拡張有効)
- バックアップ: 7日間保持
- 暗号化: 有効
データベーススキーマ
CREATE DATABASE hello_world_app;
CREATE TABLE app_logs (
id INT AUTO_INCREMENT PRIMARY KEY,
message VARCHAR(255) NOT NULL,
timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
server_name VARCHAR(100)
);
-- 初期データ
INSERT INTO app_logs (message, server_name)
VALUES ('Hello World!', 'initial-setup');
データモデル
アプリケーションデータフロー
- ユーザーリクエスト: ブラウザ → ALB
- 負荷分散: ALB → Web Server
- API呼び出し: Web Server → App Server
- データ取得: App Server → RDS
- レスポンス返却: RDS → App Server → Web Server → ALB → ブラウザ
セキュリティグループ設計
ALB Security Group
-
インバウンド:
- HTTP (80): 0.0.0.0/0
- HTTPS (443): 0.0.0.0/0
Web Tier Security Group
-
インバウンド:
- HTTP (80): ALB Security Group
- SSH (22): 管理者IPアドレス
App Tier Security Group
-
インバウンド:
- HTTP (8080): Web Tier Security Group
- SSH (22): 管理者IPアドレス
DB Tier Security Group
-
インバウンド:
- MySQL (3306): App Tier Security Group
エラーハンドリング
アプリケーションレベル
- 接続エラー: データベース接続失敗時のリトライ機能
- タイムアウト: 30秒でタイムアウト、エラーページ表示
- 500エラー: カスタムエラーページの表示
インフラストラクチャレベル
- ヘルスチェック: 各層で定期的なヘルスチェック実行
- Auto Scaling: 異常インスタンスの自動置換
- Multi-AZ: データベースの自動フェイルオーバー
テスト戦略
単体テスト
- フロントエンド: Jest を使用したコンポーネントテスト
- バックエンド: JUnit を使用したAPIテスト
- データベース: テストデータを使用したCRUD操作テスト
統合テスト
- API統合テスト: Postman/Newman を使用
- エンドツーエンドテスト: Selenium を使用したブラウザテスト
インフラストラクチャテスト
- 負荷テスト: Apache JMeter を使用
- セキュリティテスト: AWS Config Rules を使用
- 災害復旧テスト: RDSフェイルオーバーテスト
監視とログ
CloudWatch設定
-
メトリクス:
- EC2: CPU使用率、メモリ使用率、ディスク使用率
- ALB: リクエスト数、レスポンス時間、エラー率
- RDS: 接続数、CPU使用率、ディスクI/O
-
アラーム:
- CPU使用率 > 80%
- エラー率 > 5%
- データベース接続数 > 80%
ログ管理
- アプリケーションログ: CloudWatch Logs に集約
- アクセスログ: S3 バケットに保存
- ログ保持期間: 30日間
デプロイメント戦略
CI/CD パイプライン
- ソースコード管理: GitHub
- ビルド: AWS CodeBuild
- デプロイ: AWS CodeDeploy
- パイプライン: AWS CodePipeline
デプロイメント方式
- ブルーグリーンデプロイメント: ゼロダウンタイムデプロイ
- ロールバック: 問題発生時の自動ロールバック機能
設計書もちゃんとしたものができましたね!
特にアーキテクチャはしっかり図としても出来上がったのでクオリティの高いものが出来上がりました!
実装計画の作成
続いて実装計画の作成を行います。
下記に作成をしたものを載せますが、こちらはKiroで実際に実行を行います。
-
1. AWS基盤インフラストラクチャの構築
- VPC、サブネット、インターネットゲートウェイ、NATゲートウェイを作成
- セキュリティグループとNACLを設定
- Terraformまたは CloudFormation テンプレートを作成
- 要件: 4.1, 4.3, 4.4
-
2. データベース層の実装
-
2.1 RDS MySQL インスタンスの作成
- Multi-AZ構成でRDS MySQLインスタンスを作成
- データベースセキュリティグループを設定
- 自動バックアップとメンテナンスウィンドウを設定
- 要件: 3.1, 3.2, 3.4
-
2.2 データベーススキーマとテーブルの作成
- hello_world_app データベースを作成
- app_logs テーブルを作成
- 初期データを挿入するSQLスクリプトを作成
- 要件: 3.1
-
2.3 データベース接続テストの実装
- データベース接続確認用のテストスクリプトを作成
- 接続プールの設定をテスト
- データベースヘルスチェック機能を実装
- 要件: 3.1, 3.5
-
3. アプリケーション層の実装
-
3.1 Spring Boot アプリケーションの基盤構築
- Spring Boot プロジェクトの初期化
- Maven/Gradle 依存関係の設定
- アプリケーション設定ファイル(application.yml)を作成
- 要件: 2.1, 2.5
-
3.2 データベース接続とJPA設定の実装
- JPA/Hibernate設定を追加
- データベース接続プールの設定
- エンティティクラス(AppLog)を作成
- リポジトリインターフェースを実装
- 要件: 2.2, 3.1
-
3.3 Hello World API エンドポイントの実装
- REST コントローラーを作成(/api/hello)
- サービス層でビジネスロジックを実装
- データベースからメッセージを取得する機能を実装
- JSON レスポンス形式を定義
- 要件: 2.1, 2.2
-
3.4 ヘルスチェックエンドポイントの実装
- /health エンドポイントを作成
- データベース接続状態をチェック
- アプリケーション状態を返すロジックを実装
- 要件: 2.4, 5.5
-
3.5 アプリケーションサーバーのDockerイメージ作成
- Dockerfile を作成
- アプリケーションをコンテナ化
- Docker イメージのビルドとテスト
- 要件: 2.1
-
4. プレゼンテーション層の実装
-
4.1 フロントエンド HTML/CSS/JavaScript の作成
- Hello World を表示するHTMLページを作成
- レスポンシブデザインのCSSを実装
- API呼び出し用のJavaScriptを作成
- 要件: 1.1, 1.3
-
4.2 Node.js サーバーアプリケーションの実装
- Express.js サーバーを作成
- 静的ファイル配信の設定
- アプリケーション層へのプロキシ設定を実装
- 要件: 1.1, 2.1
-
4.3 Nginx リバースプロキシの設定
- Nginx 設定ファイルを作成
- アプリケーションサーバーへのプロキシ設定
- 静的ファイル配信の最適化設定
- 要件: 1.2
-
4.4 Web層のDockerイメージ作成
- Web層用のDockerfileを作成
- Nginx + Node.js のマルチステージビルド
- Docker イメージのビルドとテスト
- 要件: 1.1
-
5. EC2インスタンスとAuto Scalingの設定
-
5.1 EC2起動テンプレートの作成
- Web層用の起動テンプレートを作成
- App層用の起動テンプレートを作成
- ユーザーデータスクリプトでアプリケーション自動起動を設定
- 要件: 2.4, 4.2
-
5.2 Auto Scaling グループの設定
- Web層のAuto Scaling グループを作成
- App層のAuto Scaling グループを作成
- スケーリングポリシーを設定(CPU使用率ベース)
- 要件: 4.2
-
5.3 Application Load Balancer の設定
- ALBを作成してパブリックサブネットに配置
- ターゲットグループを作成してヘルスチェックを設定
- HTTPS リスナーとSSL証明書を設定
- 要件: 1.4, 4.1
-
6. 監視とログ設定の実装
-
6.1 CloudWatch メトリクスとアラームの設定
- EC2、ALB、RDS のメトリクス監視を設定
- CPU使用率、エラー率のアラームを作成
- SNS トピックでアラート通知を設定
- 要件: 5.1, 5.2, 5.4
-
6.2 CloudWatch Logs の設定
- アプリケーションログをCloudWatch Logsに送信
- ログストリームとロググループを作成
- ログ保持期間を設定
- 要件: 2.5, 5.3
-
6.3 CloudWatch ダッシュボードの作成
- システム全体の監視ダッシュボードを作成
- 主要メトリクスの可視化
- アラーム状態の表示
- 要件: 5.1
-
7. セキュリティ設定の実装
-
7.1 IAM ロールとポリシーの作成
- EC2インスタンス用のIAMロールを作成
- CloudWatch、S3アクセス用のポリシーを設定
- 最小権限の原則に従ったポリシー設計
- 要件: 4.3
-
7.2 セキュリティグループの詳細設定
- 各層のセキュリティグループルールを実装
- 不要なポートのブロック
- ソースIPの制限設定
- 要件: 4.3, 4.4
-
8. テストの実装
-
8.1 単体テストの作成
- Spring Boot アプリケーションのJUnitテストを作成
- API エンドポイントのテストケースを実装
- データベース操作のテストを作成
- 要件: 2.1, 2.2, 3.1
-
8.2 統合テストの実装
- API統合テスト用のPostmanコレクションを作成
- データベース接続テストを実装
- エンドツーエンドテストスクリプトを作成
- 要件: 1.1, 2.1, 3.1
-
8.3 負荷テストの実装
- JMeter負荷テストスクリプトを作成
- Auto Scalingの動作確認テストを実装
- パフォーマンステストケースを作成
- 要件: 2.3, 4.2
-
9. CI/CD パイプラインの構築
-
9.1 CodeBuild プロジェクトの作成
- アプリケーションビルド用のbuildspec.ymlを作成
- Docker イメージビルドの自動化
- テスト実行の自動化
- 要件: 2.4
-
9.2 CodeDeploy アプリケーションの設定
- Blue/Green デプロイメント設定を作成
- デプロイメントスクリプト(appspec.yml)を作成
- ロールバック機能の設定
- 要件: 2.4
-
9.3 CodePipeline の構築
- GitHub連携の設定
- ビルド、テスト、デプロイの自動化パイプラインを作成
- 承認ステップの設定
- 要件: 2.4
-
10. 最終統合とデプロイ
-
10.1 全体システムの統合テスト
- 全ての層が正常に連携することを確認
- エンドツーエンドの動作テストを実行
- パフォーマンスとセキュリティの最終確認
- 要件: 1.1, 2.1, 3.1, 4.1, 5.1
-
10.2 本番環境へのデプロイ
- 本番環境用の設定ファイルを作成
- 段階的デプロイメントの実行
- 本番環境での動作確認
- 要件: 1.1, 1.2, 1.4
-
10.3 運用ドキュメントの作成
- システム運用手順書を作成
- トラブルシューティングガイドを作成
- 監視とアラート対応手順を文書化
- 要件: 5.1, 5.2, 5.3
全ての実行にかかった時間は10分程でした。
成果物
上記の実装計画を実行してHello World!を表示することができました!

最後に
今回Kiroでできたものは、要件定義書、設計書、実装の3つです。
この3つはどんな開発でも必要なものになりますよね?
本来であればこの工程を分けて行いますが、Kiro1つで作ることができました!
Kiroの利便性や機能性についてはわかりましたが、これを実際の業務にどのように活かすのかはよくわかりませんでした。今後ともどのようにKiroを業務に使うのか等、より深く学べたらと思います!



