AWS Kiro と Terraform Power で AWS の IaC 作成。テスト作成して plan を完了するまで #AI駆動開発 #AWS #terraform

a-ikedaAIAI駆動開発(AIDD)AWS

はじめに

皆さま、こんにちは。最近の AI 駆動開発の進化には、目を見張るものがありますね。

私自身、AI ツールを活用した IaC のコード作成から AWS リソースのデプロイまで、非常に効率良く、かつスピード感を持って対応できていることを日々実感しています。

しかし、そのスピード感と引き換えに、ある課題を感じるようになりました。それは、README のような説明ドキュメントがおざなりになってしまうことです。

最近自身の AI エージェントによる開発では、リソースを作成した後に「構成や CI/CD の説明」を AI に書かせる流れになっていました。すると、「自分が与えたプロンプトは本当に正確だったのか？」「AI が考えた内容に自分の理解が追いついていないのではないか？」と、実装が先行して設計が不確な部分があり、不安を感じるシーンがありました。

そんな中で知ったのが、仕様駆動開発（Spec-driven development）を掲げる次世代 AI エディタ 「AWS Kiro」 です。

「仕様書ありきの AI エージェント駆動」であれば、リソースを作成する前の段階で「やりたいこと」を可視化し、AI と人間が共通認識を持って進められるはず。そう思ったのが、今回Kiro触ってみようと思ったきっかけです。

今回は、アプリではなくインフラのコード（IaC）を、「Terraform Power」 と共に書いてみた記録をお届けします。

AWS Kiro とは？

AWS Kiro は、単なるコード補完機能を持ったエディタではなく、一言で言えば、「AI エージェントによる自律的な開発」を前提に設計された AWS の統合開発環境（IDE）です。

VS Code をベースにしているため、拡張機能などの操作感はそのままに、AI との高度な共同作業が組み込まれています。最大の特徴は、用途に合わせて切り替えられる 2 つのモードです。

  • Vibe モード: 直感的な指示で、エディタと対話しながらサクサクとコードを書き進めるモード。
  • Spec モード: 実装に手を付ける前に、まず「何を作るか」の仕様を定義・合意するモード。

特に今回の主役である Spec モード では、以下の 3 つのドキュメントを軸に設計を固めていきます。

  • requirements.md: 満たすべき要件（ビジネスロジックや制約）の定義。
  • design.md: 構成案や使用技術の設計。
  • tasks.md: 実装に必要なステップの分解。

前述の通り、AI 駆動開発ではドキュメントが形骸化しがちです。しかし Kiro では、「何を作るかの合意」をドキュメントで取ってから実装に移るため、AI との認識のズレを未然に防ぐことができます。

Terraform Power とは？

Kiro の拡張機能である Kiro powersの中から、HashiCorp Terraform powerを使用しました。

Kiro のサイドパネルから 「Deploy infrastructure with Terraform」をインストールします。

この Power は HashiCorp 公式のパートナーシップにより提供されており、MCP（Model Context Protocol）を介して、Terraform の専門的なナレッジを Kiro に統合します。これにより、以下のような機能が利用可能になります：

  • プロバイダードキュメントの検索: 新しいAWSリソースの使い方を調べる
  • モジュールの検索: 再利用可能なVPCやEKSクラスターのモジュールを見つける
  • 最新バージョンの確認: プロバイダーの最新バージョンを自動取得

AI が自身の学習データだけに頼らず、自ら「最新の公式ドキュメントを確認しに行く」ため、IaC で起こりがちなハルシネーションを大幅に抑えられるのがメリットの一つとなります。

仕様書作成

インストール後のガイドに従ってMCP設定を実施したあとで実際に Kiro を動かしていきます。今回はまず、私の意図を伝えるためのプロンプトを投げ、Kiro に「設計図」を書かせることから始めました。

利用した実際のプロンプト

私が Kiro に投げた具体的な指示がこちらです。

Terraform Powerを使用して、AWSのシンプルな静的ウェブサイトホスティング構成（S3 + CloudFront）の設計とコード作成をお願いします。まずはSpecモードで全体の構成案（design.md）と実装タスク（tasks.md）を作成し、私が承認してからコードを生成してください。また、作成時にTerraform Powerのどのような機能（ドキュメント検索など）を活用したかも教えてください。

Kiro Specsでは上記のような指示を与えなくてもMDファイル(仕様書)を作成してくれますが、今回はきちんとやりたいことを明示してみました。

requirements.md (要件定義ドキュメント) の作成

プロンプトを受けると、Kiro はまず `requirements.md` を作成しました。

以下Chatでのやりとりの引用となります。下記の要件を定義してくれました。

requirements.md に以下の要件を定義しました：

Requirement 1: S3バケットの作成と設定

Requirement 2: CloudFront Distributionの作成

Requirement 3: Origin Access Controlの設定

Requirement 4: Terraform設定ファイルの構造化

Requirement 5: 変数とカスタマイズ性

Requirement 6: 出力値の提供

Requirement 7: エラーハンドリングとバリデーション

Requirement 8: ドキュメンテーション

design.md (設計ドキュメント) の作成

続いて `design.md` が作成されました。以下一部抜粋ですが、概要を説明してくれています。

# Design Document

## Overview

このドキュメントは、TerraformとAWSを使用して静的ウェブサイトホスティング環境を構築するシステムの設計を定義します。S3バケットでコンテンツをホストし、CloudFrontを通じてグローバルに配信する、セキュアでスケーラブルな構成を実現します。

Terraform Powerを活用して、AWS Provider v6.27.0の最新ドキュメントを参照し、ベストプラクティスに基づいた設計を行いました。

ここで注目したいのは、プロンプトの指示どおりKiro がきちんと Terraform Power (MCP) を活用すると宣言した点です。ファイル内には以下の活用内容が明記されていました。

このデザインを作成する際に、以下のTerraform Power機能を活用しました：

1. get_latest_provider_version: AWS Provider v6.27.0の最新バージョンを確認

2. search_providers: S3とCloudFrontリソースのドキュメントを検索

3. get_provider_details: 以下のリソースの詳細ドキュメントを取得：

   - `aws_s3_bucket_website_configuration`

   - `aws_cloudfront_distribution`

   - `aws_cloudfront_origin_access_control`

AI が「自分の知識」だけで書くのではなく、リアルタイムに最新のプロバイダー情報を参照しにいっていることがわかります。

tasks.md (実装タスク) の作成

最後に、実装に向けた具体的なステップが `tasks.md` として書き出されました。

# Implementation Plan: AWS Static Website Hosting

## Overview

このドキュメントは、TerraformとAWSを使用して静的ウェブサイトホスティング環境を構築するための実装タスクを定義します。各タスクは段階的に進み、前のタスクの成果物を活用します。

## Tasks

- [ ] 1. Terraformプロジェクトの初期設定

  - `versions.tf`を作成し、Terraform v1.0以上とAWS Provider v6.27.0の制約を定義

  - `provider.tf`を作成し、AWS providerを設定

  - `.gitignore`を作成し、Terraform関連ファイルを除外

  - Requirements: 4.1, 4.3

- [ ] 2. 変数定義の作成

  - `variables.tf`を作成

  - 各変数にバリデーションルールを追加

  - Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 7.1, 7.2, 7.4

- [ ] 2.1 変数バリデーションのプロパティテストを作成

  - Property 7: 変数バリデーション

- [ ] 3. S3バケットとCloudFrontインフラストラクチャの実装

  - [ ] 3.1 `main.tf`を作成し、S3バケットリソースを定義

  - [ ] 3.2 S3バケットのセキュリティ設定を追加

  - [ ] 3.3 S3バケット設定のプロパティテストを作成

- [ ] 4. Origin Access Control (OAC)とCloudFront Distributionの実装

  - [ ] 4.1 Origin Access Controlリソースを作成

  - [ ] 4.2 CloudFront Distributionリソースを作成

  - [ ] 4.3 CloudFrontのキャッシュ動作とセキュリティ設定を追加

  - [ ]* 4.4 CloudFront設定のプロパティテストを作成

- [ ] 5. S3バケットポリシーの作成

  - CloudFrontからのアクセスのみを許可するポリシーを定義

- [ ]* 5.1 OACとバケットポリシーのプロパティテストを作成

- [ ] 6. Checkpoint - インフラストラクチャ設定の確認

  - terraform planが期待通りの変更を生成することを確認

- [ ] 7. 出力値の定義

  - outputs.tfを作成

- [ ] 7.1 出力値のプロパティテストを作成

- [ ] 7.2 リソース依存関係のプロパティテストを作成

- [ ] 8. ドキュメンテーションの作成

  - README.mdを作成

- [ ] 9. サンプルファイルの作成

  - terraform.tfvars.example / index.html の作成

- [ ] 10. Final Checkpoint - 統合テストと検証

  - すべてのプロパティテストが通過することを確認

このように、Kiro の Spec モードを使うことで、「何を、なぜ、どのような手順で作るのか」が実装前に可視化されました。

仕様駆動による AWS IaC 作成

設計図（Spec）が完成したところで、いよいよ実装フェーズです。

今回は `tasks.md` に定義された 10 個のタスクを一つずつ順番に確認しながら進めていきました。以下はStep3が完了した時点のtasks.mdの内容です。

各タスクを実行するたびに、Kiro は該当する Terraform コードと併せて、その要件を検証するための テストスクリプト も同時に生成してくれます。

単なるリソースの存在確認にとどまらず、変数のバリデーションやセキュリティ設定まで踏み込んでチェックしてくれていました。生成されたテストの中身が意図通りかは人間が精査する必要がありますが、実装と検証をセットで進めてくれるこの試みは、開発者として非常にありがたいと感じます。

terraform plan の実行

すべてのタスクを完了し、生成された大量のテスト（トータル575 個）をパスした状態で、 `terraform plan` を実行しました。

S3 Bucket securityテストの例

======================================================================
Property-Based Test: S3 Bucket Security Configuration
Feature: aws-static-website, Properties 1, 4, 5
Validates: Requirements 1.2, 1.3, 1.4, 3.5

Reading Terraform configuration from /mnt/c/Users/a-ikeda/Desktop/kiro-terraform/main.tf…
✓ Terraform configuration loaded successfully

======================================================================
Testing Property 1: S3バケットはプライベートアクセスのみ
Validates: Requirements 1.2, 3.5

✓ Test 1: Public access block resource exists - PASSED
✓ Test 2: block_public_acls is enabled - PASSED
✓ Test 3: block_public_policy is enabled - PASSED
✓ Test 4: ignore_public_acls is enabled - PASSED
✓ Test 5: restrict_public_buckets is enabled - PASSED
✓ Test 6: All public access block settings are properly configured - PASSED

terraform planの結果抜粋

Terraform will perform the following actions:

  # random_id.bucket_suffix will be created
  + resource "random_id" "bucket_suffix" {
      + b64_std     = (known after apply)
      + b64_url     = (known after apply)
      + byte_length = 4
      + dec         = (known after apply)
      + hex         = (known after apply)
      + id          = (known after apply)
(中略)

Plan: 8 to add, 0 to change, 0 to destroy.

まとめ

AWS Kiro と Terraform Power を組み合わせたインフラ実装を試してみました。アプリ開発だけではなく、インフラ構築においてもこれからの IaC 開発を感じる体験となりました。最後に、実際に触れてわかったポイントを整理します。

  • 仕様から入る「着手」のしやすさ: 実装前に構成を固めるフロー（Specモード）が標準化されているため、実装する上で安心感があり迷いなくスムーズに作業に入れました。
  • テスト自動生成による「品質」の向上: 実装と同時にテストコードが積み上がるのは大きな利点です。ただし、そのテストが要件を正しく網羅できているかの精査も必要となります。
  • Terraform Power を「使いこなす」上での課題: AI がツール（MCP）の活用を宣言していても、実際には使っていない場合がありました。その際は明示的に「Power を使って」と再依頼することをしましたが、仕様通りにMCPを利用しているかKiroから返ってくるプロンプトで分かるので意識が必要です。
  • 「人」が介在する重要性: 構成の最終判断や責任を持つという人間の役割は、今後 AI の精度が上がっても変わることはありません。人による精査は必要だと改めて感じています。

AI という強力なパートナーを賢く使いこなしながら、より品質の高いコードをスピーディーに構築していきたいですね。

Author

a-ikeda

    将来はいろいろな都市に住んでみたいリモート好きなエンジニア

    a-ikedaの記事一覧

    新規CTA