記事公開日
Kiro Powersとは？ インストールしてAWS環境を構築してみた①
この記事のポイント
Kiroの新機能「Kiro Powers」を導入することで、要件定義や設計プロセスがどのように高度化するかを、実機検証を通じて解説します。同一の指示文を用いた「Powersあり・なし」の比較により、生成される設計の具体性やアーキテクチャの質の差を明らかにします。
- インフラ構造を重視した具体的設計：
「Build AWS infrastructure with CDK and CloudFormation」Powerを活用することで、単なる機能定義に留まらず、AWS CDKでの実装を意識したデータモデルや、セキュリティグループの443ポート通信（Inbound/Outbound）の詳細な表文化が可能になります。 - ベストプラクティスの自動適用：
AWS公式ドキュメントやWell-Architectedな設計を自律的に参照。NAT Gatewayを排除したコスト最適化の提案や、最小権限の原則（Least Privilege）に基づいたIAMロール構成など、高度なセキュリティ・コスト管理が設計に組み込まれます。 - 自律型AIエージェントによる検証：
筆者の独自検証では、Powersあり版においてKiroが「自律型AIエージェント」として動作し、不足している情報を自ら調べて補完する挙動を確認。ビジネス的正当性を備えた設計ドキュメントの生成プロセスを実証しました。
はじめに
こんにちは。DXソリューション営業本部の岡田です。
先日、「Kiro Powers」というKiroの新機能が発表されました。
実際のところ、 「Kiro Powersって何？」 「Kiro Powersを使うと何ができるの？」 といった疑問をお持ちの方も多いのではないでしょうか。
今回は、Kiro Powersを導入した場合してない場合で簡単なCloudFormationテンプレートの生成を依頼する同一の指示文を実行してSpec機能を使用したらどのように要件定義／設計は変わるのかをご紹介します。
Kiroの概要については下記ブログをご覧ください。
Kiro Powersとは？
Kiro Powerとは一言でいうと「特定の専用のマニュアル」を持たせて、必要なときだけ使わせる機能です。
「正確な情報を求めるあまり、大量のドキュメントをAIに読み込ませたら、かえって意図しない回答がきた」
これはAIに情報を与えすぎることでAIが混乱し、どれを優先すべきか判断できなくなってしまうからです。
この課題を解決してくれるのがKiro Powersです！
Kiro Powersの詳しい説明は下記AWS公式ブログをご覧ください。
【検証】Kiro Powersを導入した場合してない場合でSpec機能を使用したらどのように要件定義／設計は変わるのか
Kiro Powersを導入した場合、してない場合にSpec機能を使用し要件定義、設計はどのような差異がでるか確認するため今回は下記の簡単な検証を行っていきたいと思います。
検証概要
CloudFormationテンプレートの生成を依頼する簡単で曖昧な同一の指示文をPowersあり・なしで行い
Spec機能を使用したらどのように要件定義／設計は変わるのか
指示文
AWSのプライベートサブネットにあるEC2に、安全にログインできるようにして。なるべく安く運用が楽な方法がいい。
検証1：Powersなし
はじめにPowersなしで行います。
Specモードで先述した指示文を実行します。
指示文の実行結果、要件定義が返ってきました。
これから作成するものの整理を行ってくれました。
今回はPowersあり版との差異を確認したいためこのまま要件ドキュメントを承認します。
要件定義を承認すると設計ドキュメントが返ってきました。
このPowersなしで確認した要件定義、設計がPowersありだとどのように変わるか確認します。
検証2：Powersあり
今度はPowersありで全く同様の手順を行いたいと思います。まずは対象のPowersをインストールします。
サイドバーにあるイナズママークのPowersアイコンを選択し、今回は
「Build AWS infrastructure with CDK and CloudFormation」をインストールします。
Installedに表示されていれば準備完了です。
Powersなし同様先述した指示文をSpecモードで貼り付け実行します。
すると今度はKiro PowersがActiveになった旨が伝えられています。
中身をのぞいてみると
①「aws-infrastructure-as-code」という名前の拡張機能（Powers）がオンになったこと
②AWS CDKを使って、設計の優れた（Well-Architectedな）インフラを構築できる
③最新のドキュメントやベストプラクティス（推奨される設計）、サンプルコードを参照してコードを書ける
④ デプロイ前のコード検証やセキュリティチェック、エラー時のトラブルシューティングも支援してくれる
などといったことが述べられています。
指示文の実行結果、要件定義が返ってきました。
Powersなし版では見られなかった「AWS管理サービスによる自動更新」が明示されています。
また、Powersなし版では具体的な実装ツールを明示されていませんでしたが、「AWS CDKでのデプロイ」の表記が明示されています。
Powersなし版同様、Powersあり版、なし版の差異を確認したいため要件ドキュメントを承認し、設計へと進みます。
Powesなし版ではなかった挙動ですが、Powersあり版では自ら調べて「自律型AIエージェント」として動作してくれています。
設計ドキュメントをKiroにまとめてもらいました。
また、設計ドキュメントの中身を見ると、セキュリティグループの方向性が「443ポート」だけでなく、どちらからどちらへ通信を許可すべきか（Inbound/Outbound）が詳細に表文化されています。
- Inbound: HTTPS (443) from VPC CIDR range
- Outbound: All traffic (default) **EC2 Instance Security Group**: - Outbound: HTTPS (443) to VPC Endpoint Security Group
また、コスト最適化においても「NAT Gatewayを排除しコストを最適化する」といった、ビジネス的な正当性をテスト対象として組み込んでいます。
*For any* deployment configuration, the system should use VPC endpoints instead of
NAT Gateways to minimize data transfer costs
さらに、最小権限においても単にアクセスできるだけでなく、「最小権限が守られているか」というセキュリティ上の正しさをプロパティとして定義しています。
*For any* IAM role configuration, the system should enforce least privilege principles for both EC2 instances and users
まとめ
比較表| 項目 | Powersあり版 (CDK/インフラ構造重視) | Powersなし版 (機能/振る舞い重視) |
|---|---|---|
| 設計の焦点 | 「どう構築するか（How）」 AWS CDKでの実装を意識したデータモデルやインフラ設定が中心。 |
「何を実現するか（What）」 マネージャー単位のコンポーネント定義と、詳細な機能要件が中心。 |
| データモデル | Jest / CDK Testing Framework インフラコードとしての妥当性検証にフォーカス。 |
Jest / CDK Testing Framework インフラコードとしての妥当性検証にフォーカス。 |
| エラーハンドリング | 接続失敗やデプロイエラーなど、運用・構築時のトラブルに重点。 | タイムアウトや権限不足など、ユーザー利用時の挙動制御に重点。 |
今回は比較した2つの設計ドキュメントは、どちらも「Session Managerによる安全なアクセス」と接続方式は同一でした。
しかし、Powersあり版は実装でCDKでの実装を意識したインフラ設定が中心になっており、どう構築するかが設計の焦点となっていると感じました。
Powersは先述の手順で誰でも簡単にインストールが可能ですので一度お試しください。
次回は設計ドキュメントをもとに実装フェーズに入っていきたいと思います。
今回の要件定義、設計の段階では明確な差異ははっきりと出ませんでしたが、実装フェーズにて違いがでてくるか引き続き確認していきます。
次回のブログにご期待ください！
↓QESではKiroについて積極的に情報発信していきますので是非ご覧ください！
もし「このサービスについて知りたい」「AWS環境の構築、移行」などのリクエストがございましたら、弊社お問合せフォームまでお気軽にご連絡ください。 複雑な内容に関するお問い合わせの場合には直接営業からご連絡を差し上げます。 また、よろしければ以下のリンクもご覧ください！
＜QES関連ソリューション/ブログ＞
＜QESが参画しているAWSのセキュリティ推進コンソーシアムがホワイトペーパーを公開しました＞
※Amazon Web Services、”Powered by Amazon Web Services”ロゴ、およびブログで使用されるその他のAWS商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
