Kiroでインフラ要件定義～テスト を実施してみた

2025/8/02 JAWS-UG 名古屋 8月会①「クラウド女子会コラボ会」

Transcript

1. JAWS-UG 名古屋 8月会①「クラウド女子会コラボ会」 Kiroでインフラ要件定義～テスト
 を実施してみた クラウド女子会運営 五味なぎさ（X： @nagisa_53 ）
2. 自己紹介 勤務先：日鉄ソリューションズ株式会社 仕事内容：インフラ部門クラウド推進グループマネージャー 　 趣味：キックボクシング、スキューバダイビング 　 好きなAWSサービス：NW系サービス全般 　 AWSに関わる活動： 　 　 JAWS-UG （AWS User Group – Japan） クラウド女子会 / 彩の国埼玉支部運営 　 AWS Community Builders（Networking and Content Delivery） 　 　 2024, 2025 AWS Japan Top Engineers 　 　 AWS Ambassador（2025～）
3. 注意事項 6 本登壇内容は個人の見解です。
 所属組織の公式見解とは異なる可能性があります。
4. Kiroとは？ … AWSが提供するAgentic ID$ … 7/14に公開され、現在Preview版が提供されてい~ … 与えられたプロンプトから要件定義を行い、要件定義に沿ったタスクを 実行していく「仕様駆動開発」を支援するツー9 … 大きく以下2つの特長的な機d … Spec：「要件定義 - 設計 - タスクリスト作成」の一連を実施。 タスクリストの内容を元にKiroでタスクを実行できるe … hook：特定のイベント時（例：ファイル保存時）に処理を実行
5. 今回やってみたモチベーション ‚ 仕事上、SI型である程度大規模なAWS環境のインフラ構築を担当する ことが多く、生成AIをどのように活用できるかは検討事項の1' ‚ 上記理由から、特徴や各フェーズでどのように使えそうか？を把握した いという思いがあった
6. 作りたい構成 ‚ 東京リージョンに検証用VPC2つ
 ※Network Firewall設定は手動で行いたかったためその前段構成を作成した• ‚ マルチAV ‚ サブネット等一般的なVPCに必要なコンポーネン# ‚ Network Firewallを配置できるようなサブネット設 ‚ 将来的にVPC間をTransit Gatewayで接続する可能性あり
7. 環境等前提 s Windows 1w s Kiro Preview版（Builder IDでログイン） + WSL s あらかじめKiroで以下のMCP Serverへの接続設& s AWS Documentation MCP Serve` s AWS Knowledge MCP Server（PreviewX s AWS Terraform MCP Server… s steeringファイルに以下を記載し、チャットと成果物の日本語化を指示 


8. Specを利用した 要件定義 - 設計 - タスクリスト作成
9. 要件定義 この時点でAWS Knowledge MCP Serverを 使用し、AWSとして押さえておきたい要件に 漏れがないようにした
10. 要件定義 3 前頁程度のやり取りで
 ある程度納得のいく要求ドキュメントが
 作成された
11. 設計 特に指定していなかったが、 AWS Terraform MCP Serverに接続してい たからか、Terraform利用前提となった （今回はスキップしたが） パフォーマンステストも含めた設計をして くれようとしていた
12. 設計 設計時に合わせて.drawio形式の 構成図も生成してもらった ※AWS Diagram MCP Serverを使う方法もあるが、 .drawio形式で作りたかったのであえて使用せず
13. 設計 $ 要件定義時にある程度細かい仕様まで
 決めたためか、
 少ないやり取りである程度満足できる
 設計書が作成できた
14. タスクリスト作成 ‰ 以下のタスクリストが生成されY ‰ Terraformコードの生i ‰ ドキュメント生i ‰ README.m7 ‰ terraform-docsによるドキュメント生i ‰ 各リソースの実1 ‰ 単体テス‚ ‰ テスト仕様書作i ‰ Terraform validationブロックの実装とテス‚ ‰ terratestを利用した単体テス‚ ‰ テストコード作成含 ‰ 統合テストとデプロイメント検 ‰ terraform init/plan/applyの実行テス‚ ‰ リソース作成後の検 ‰ クリーンアップテスト 出力イメージ
15. 以降タスクの実行結果
16. Terraformコードの生成 x コード作成後terraform fmt / init / validate / planまでが実行されi x 認証情報はアクセスキー/シークレットキーが設定済みの場合はそのまま実行されるが、 環境変数にセットやsso loginのケースの場合（IAM Identity Center利用時など）、Kiro が操作する対象セッション上でセットする必要あ’ x 設計の時点でAWS Terraform MCP Serverを参照していたため、
 Terraformのベストプラクティスに従った形でコードが生成された。
 （ファイル分割などもベストプラクティスに従っていたY x 更にこのフェーズで再度AWS Terraform MCP Serverを利用することによ り、Checkovによるセキュリティチェックまで行われた 特段問題なし
17. 【参考】セキュリティスキャン結果
18. ドキュメント生成 振り返り点あり i READMEにもう少し設計根拠の情報を載せたかっv i プロンプトへのインプット次第で追記は可能と思われT i terraform-docsによる生成部分がいまいちだった$ i Terraformのmodule構成やコメントの書き方などコード側で考慮が必要
 なため、コード生成時にその点のインプットが必要そう
19. 各リソースの実装 振り返り点あり g “実装”となっていたが環境へのデプロイは行われず、コードの中身が要件を 満たしているかを確認する動作となっていˆ g あくまでコードとしての実装が正しく行われているかをチェックする動8 g terraform init / validate / plan の実行など、コード生成のタスクと重複する 動きもあったので、タスクリスト作成時にもう少し各タスクの実施内容につ いて深堀しておくべきだった
20. 単体テスト b “テスト仕様書作成”、”validationブロックの実装とテスト”については特に 問題なく動X b terratest部分には以下課題あq b 実行が中途半端にしか行われなかったがそれで良しとなってしまっ! b エラーの内容によっては自動でテストコード側に修正が入っており、 帳尻を合わせにいっていないかが懸念
 ※今回時間切れでそこまで確認できなかった 課題あり
21. 統合テストとデプロイメント検証 H 認証情報の設定が漏れていた際に、勝手にplan/applyをスキップして
 完了報告してきた → 認証情報設定 / プロンプトでの指示で続行 振り返り点あり
22. 統合テストとデプロイメント検証 T apply後の処理としては、要件と作成されたリソースとの突合が行われ ており（リソース情報を取得してきて要件と突合するスクリプトが自動 生成された）、最後にdestroyまでが行われC T terratestと重複した観点の確認も含まれているように見えるので、スク リプトでの確認内容についてはもう少し精査してみたい
 ※今回時間切れでそこまで確認できなかった 振り返り点あり
23. やってみた所感
24. 所感 <全体感> ˜ インフラ構築においても、ドキュメントやテストも含め一通り生成してくれることが分かっA ˜ （それはそうであるが）“インフラの構築をする”という考え方より”IaCコードを実装する”とい う考え方なので、インフラ構築プロジェクトで利用するにはその点のフォローは必要そD ˜ 上流フェーズでいかに後続フェーズでブレをなくすインプットができるかがこれまで以上に重 要になると感じA ˜ 要件定義をした人に寄らず設計以降のブレを少なくするため、steeringファイルにあらかじめ順守 ルールや利用ツールなどを定義し、ブレをなくしていく取り組みe ˜ 人の目でどこまでチェックすべきかが難しい
25. 所感 <個別フェーズ> e コード生成はMCP Serverを利用することでそれなりに品質が高いものが作成できそう
 （複雑な構成になった場合の検証は必要だがt e ドキュメンテーションは工夫次第だがそこまで課題は大きくなさそう。情報の与え方次第“ e テストは品質担保の考え方と合わせてもう一歩踏み込んだ確認/検討が必要