はじめに
過去に手組で作成したAWS環境を長年運用しているどうしてもドキュメントと実環境がずれが起きがちです。定期的に棚卸をしていても最後は実環境を見て確かめる。という運用をされている方が多いのではないでしょうか。
今回はKiroの Spec機能を使って、既存 AWS アカウントの構成情報を収集し、設計書と CloudFormation テンプレートを自動生成するワークフローを試してみました。
Kiro とは
Kiro は AWS が提供する AI 搭載の IDE です。VS Code ベースの見た目で、AI エージェントがコード生成やタスク実行を行ってくれます。特徴的なのは「Spec」という機能で、要件定義 → 設計 → タスク分解 → 実装という構造化されたワークフローを AI と一緒に進められます。
やりたかったこと
AWS Organizations で管理している複数アカウントの構成情報を、以下の形式で文書化したい：
- 設計書（Markdown）: アカウントの全体像を俯瞰できるドキュメント
- CloudFormation テンプレート: 既存リソースの構成を再現可能な IaC
対象アカウントは Control Tower 配下のテスト環境で、VPC が 3 つ、S3 バケットが 8 つ、IAM ロールが 55 個ほどある環境です。
Spec 機能のワークフロー
1. 要件定義（requirements.md）
Spec を作成すると、まず要件定義のフェーズに入ります。Kiro に「AWS アカウントの構成情報を設計書にまとめたい」と伝えると、AI が質問を投げかけてきます。
- どのリソースを対象にするか？
- どのリージョンを対象にするか？
対話を通じて要件が整理され、ユーザーストーリーと受入基準が自動生成されます。最終的に 9 つの要件（ネットワーク、コンピューティング、DB、ストレージ、サーバーレス、IaC、IAM、ML、全体像）に整理されました。
2. 設計（design.md）
要件が固まると、次は技術設計のフェーズです。Kiro が以下を自動生成してくれました：
アーキテクチャ図を起こしてくれるのがめちゃくちゃありがたかったです。
- アーキテクチャ図（Mermaid 形式）←これが素晴らしい！
- コンポーネント一覧と詳細仕様
- リソース間の依存関係マップ
- エラーハンドリング方針
3. タスク分解（tasks.md）
設計が完了すると、実装タスクが自動生成されます。今回は以下のような構成になりました：
1. プロジェクト構造セットアップ
2. ネットワークテンプレート作成（Test VPC / Web3Tier VPC）
3. チェックポイント
4. ストレージテンプレート作成
5. サーバーレステンプレート作成
6. IAM テンプレート作成
7. チェックポイント
8. CI/CD パイプラインテンプレート作成
9. 統合・最終整理
10. 最終チェックポイント
各タスクには要件番号への参照が付いており、トレーサビリティが確保されています。
4. 実装
タスクを一つずつ実行していくと、Kiro が AWS MCP 経由で実際のアカウント情報を取得し、CloudFormation テンプレートを生成してくれます。
成果物
設計書
マスターアカウントとワークアカウントの 2 つの設計書が生成されました。内容は：
- アカウント基本情報（ID、メール、Organizations 構成）
- IAM 構成（ユーザー、グループ、ロール一覧）
- ネットワーク構成（VPC、サブネット、SG、IGW）
- セキュリティ・監査（CloudTrail、Config、Security Hub、GuardDuty）
- アーキテクチャ概要図（テキストベース）
CloudFormation テンプレート
6 つのテンプレートファイルが生成されました：
| ファイル | 内容 |
|---|---|
iam-custom-roles.yaml |
CI/CD 用 IAM ロール |
network-test-vpc.yaml |
テスト VPC |
network-web3tier-vpc.yaml |
3 層 Web アーキテクチャ VPC |
storage-s3.yaml |
S3 バケット 8 個 |
serverless-lambda.yaml |
Lambda 関数 |
cicd-pipeline.yaml |
CodePipeline |
テンプレート間の依存関係（Fn::ImportValue）も正しく設定され、デプロイ順序まで README に記載されています。
良かった点
構造化されたアプローチ
「設計書を書いて」と一発で頼むのではなく、要件 → 設計 → タスク → 実装と段階を踏むことで、抜け漏れが少なくなります。途中で「NAT ゲートウェイは？」「SageMaker ドメインは？」といった確認が入るので、見落としがちなリソースも拾えます。
Control Tower 管理リソースの切り分け
「Control Tower が自動管理するリソースはテンプレート対象外」という判断を AI が提案してくれました。これは実務的に正しい判断で、手動で管理すべきリソースと自動管理リソースの境界が明確になります。
再現性
Spec ファイル（requirements.md、design.md、tasks.md）がそのまま残るので、別のアカウントに対して同じワークフローを再実行できます。
注意点・改善したい点
権限は ReadOnly で十分
今回は SSO の AdministratorAccess で実行しましたが、本来は ReadOnlyAccess で十分です。設計書生成で使う API は全て Describe/List/Get 系なので、書き込み権限は不要です。
ReadOnly で実行するメリット：
-
フェイルセーフ: AI が万が一
createやdelete系のコマンドを提案しても、権限不足で弾かれる - 事故防止: 承認ダイアログを見落としても実害がない
- 監査対応: 「読み取りしかできないアカウントで実行した」と説明できる
Control Tower 環境なら、既存の AWSReservedSSO_AWSReadOnlyAccess 権限セットをそのまま使えます。MCP 設定の AWS_PROFILE を ReadOnly 用のプロファイルに切り替えるだけです。
{
"env": {
"AWS_PROFILE": "readonly-profile"
}
}
情報収集系のタスクでは、最小権限の原則に従って ReadOnly アカウントを使うことを推奨します。
情報の鮮度
設計書は実行時点のスナップショットです。リソースが変更されたら再実行が必要です。定期的な更新の仕組みは別途考える必要があります。
テンプレートの完全性
生成された CloudFormation テンプレートは「既存リソースの構成を記録する」目的で作られています。そのまま別アカウントにデプロイすると、アカウント ID やリージョン固有の値でエラーになる可能性があります。パラメータ化はされていますが、実運用にはレビューが必要です。
Spec の学習コスト
Spec 機能自体は直感的ですが、「どこまで要件を詰めるか」「設計のどこで止めるか」の判断は人間側に委ねられます。最初は AI に任せすぎて冗長になったり、逆に情報が足りなかったりする試行錯誤がありました。
まとめ
いや素晴らしい精度です。アーキテクチャ図まで書いてくれるので引き継いだ環境なんかで構成の理解にとても役立ちます。
また、Kiro の Spec 機能は、「AWS アカウントの棚卸し」のような定型的だけど面倒な作業に向いています。要件定義から実装まで一貫したワークフローで進められるので、途中で方針がブレにくいのが利点です。
生成された設計書は完璧ではありませんが、ゼロから書くよりはるかに効率的で、レビューのベースラインとしては十分使えるレベルでした。
環境情報
- Kiro 0.12.200
- AWS MCP Server（mcp-proxy-for-aws）
- 対象: AWS Control Tower 管理下のマルチアカウント環境
- リージョン: ap-northeast-1