はじめに
AWSが2025年7月にリリースしたAIエージェント搭載のIDE「Kiro」をご存じでしょうか。Kiroは、要件定義からコード生成・デバッグまでをAIと対話しながら進められる開発環境です。仕様書（spec）を起点に開発を進める「Spec-Driven Development」が最大の特徴ですが、ChatGPTのような自然言語での指示だけでコードを生成する「バイブコーディング（Vibe Coding）」モードでも手軽に使えます。
今回の検証テーマは「プロンプトに一文加えるだけで、生成されるCloudFormationの品質はどれだけ変わるのか？」です。同じWEB三層構成の要件に対し、最小限のプロンプトと「AWS Well-Architected Framework 6本柱に準拠」を追加したプロンプトの2パターンを比較しました。
この記事はシリーズ3部構成の第1部です。
- 第1部（本記事）：Vibe codingで「何も指定しない」vs「Well-Architected準拠」を比較
- 第2部：KiroのSpec機能を使って、より深く要件を仕込む
- 第3部：Agent HooksとCI/CDで品質を自動担保する
検証環境
- ツール：Kiro IDE（Vibe coding）
- モデル選択：Auto
- IaC：AWS CloudFormation
- リージョン：ap-northeast-1（東京）
- 検証日：2026年3月
検証内容：WEB三層アーキテクチャを2パターンで生成
お題はシンプルな**WEB三層アーキテクチャ（ALB → EC2 → RDS MySQL）**です。
パターンごとに新しいフォルダでKiroを起動し、互いの文脈が引き継がれない状態で実行しました。
パターンA：最小限のプロンプト
ALB→EC2(Apache+Hello World)→RDS(MySQL 8.0)のWEB三層アーキテクチャをCloudFormationで構築してください。
リージョンはap-northeast-1、EC2はAmazon Linux 2023を使用。
設計ドキュメントも作成してください。
パターンB：Well-Architected準拠を追加
ALB→EC2(Apache+Hello World)→RDS(MySQL 8.0)のWEB三層アーキテクチャをCloudFormationで構築してください。
リージョンはap-northeast-1、EC2はAmazon Linux 2023を使用。
AWS Well-Architected Framework 6本柱に準拠してください。
設計ドキュメントも作成してください。
差分はたったの一文。この一文でどれだけ出力が変わるかが今回の検証の核心です。
Kiroはこう動く
バイブコーディングモードでKiroに指示を出すと、コードをいきなり書き始めるわけではありません。次のような流れで自律的に作業を進めます。
-
設計ドキュメントの作成：まずアーキテクチャ概要、ネットワーク設計、セキュリティ設計などを
design.mdにまとめます。 -
CloudFormationテンプレートの生成：設計ドキュメントをもとに
template.yamlを生成します。 - YAMLの構文チェック：Pythonスクリプトを実行してテンプレートの構文検証を行い、エラーがあれば自己修正します。
「プロンプトを受け取ってすぐコードを吐き出す」ではなく、設計 → 実装 → 検証という流れを自律的に踏んでいます。ここは普通のAIアシスタントとの明確な違いだと感じました。
CFnテンプレートの比較
主要な差分を表にまとめます。
| 項目 | パターンA | パターンB |
|---|---|---|
| EC2構成 | インスタンス直接×2 | ASG + LaunchTemplate（Min:2, Max:4） |
| スケーリングポリシー | なし | TargetTracking（CPU 70%） |
| RDS Multi-AZ |
false（検証用と明記） |
true |
| RDS ストレージ暗号化 | なし | StorageEncrypted: true |
| RDS パスワード管理 | Parameterに平文 | Secrets Manager（自動生成・32文字） |
| RDS ストレージ上限 | 固定20GB |
MaxAllocatedStorage: 100（自動拡張） |
| RDS DeletionPolicy | Delete |
Snapshot |
| EC2 IAMロール | なし | SSM + CloudWatchAgent付きロール |
| IMDSv2 | なし |
HttpTokens: required（強制） |
| EBS暗号化 | なし | Encrypted: true |
| VPC Flow Logs | なし | CloudWatch Logsへ出力 |
| CloudWatchアラーム | なし | CPU高負荷 + RDS接続数 |
| Outputs | 基本のみ | Exportあり（クロススタック参照対応） |
パターンAの特徴
最小限のプロンプトでも、VPC・サブネット・NAT Gateway・ALB・RDSという三層構成の骨格は正しく生成されました。セキュリティグループの連鎖設計（ALB SG → EC2 SG → RDS SG）も適切です。
一方で、EC2はAuto Scalingなしの直接インスタンス×2、RDSはMulti-AZなし・暗号化なし・DeletionPolicy: Deleteと、検証環境としては許容できても本番には到底適用できない構成です。IAMロールもなく、SSM経由でのインスタンス接続もできません。
パターンBの特徴
「Well-Architected Framework 6本柱に準拠」の一文を加えるだけで、出力が大きく変わりました。
- EC2がASG + LaunchTemplateに変わりスケーラビリティを確保
- Secrets Managerで32文字パスワードを自動生成・管理
- IMDSv2（
HttpTokens: required）でメタデータサービスを保護 - EBS暗号化でディスクデータを保護
- VPC Flow Logsでネットワークトラフィックを記録
- CloudWatchアラーム（EC2 CPU 80%、RDS接続数）でモニタリング
セキュリティ面の注目ポイント
パターンBで特に大きく変わったのがパスワード管理です。パターンAは NoEcho: true の Parameter で受け取る形でしたが、パターンBでは Secrets Manager を使ってデプロイ時に32文字のパスワードが自動生成される構成になりました。インフラエンジニアとして「ここは指示しなくてもやってくれるのか」と素直に驚きました。
また HttpTokens: required（IMDSv2強制）や EBS暗号化など、セキュリティのベストプラクティスが一通り自動で入ってきます。
設計ドキュメントの比較——ここが一番の差
CFnの差も大きいのですが、ドキュメントの質の差がさらに際立ちました。
パターンA のドキュメント：「現状記録」
パターンAのドキュメントは「何を作ったか」の説明です。ネットワーク構成表、コンポーネント詳細、SGルール一覧——いずれも生成したCFnの内容を文章で書き直したものです。
注目したのは RDS の説明に Multi-AZ: 無効 (検証用) と書かれていた点です。Kiroは「これは本番向けではない」と自覚しながら生成しているわけですが、ではなぜ検証用にしたのか、本番ならどうすべきかは書かれていません。
パターンB のドキュメント：「Why付き設計書」
パターンBのドキュメントはまったく別物でした。Well-Architectedの6本柱ごとに対応表があり、なぜこの設計にしたのかの根拠が記載されています。
さらにデプロイ手順のCLIコマンドまで含まれており、ドキュメントを読めばそのままデプロイできる構成になっています。
「変わらなかった」部分——ここが限界
一方で、パターンBでも変わらなかった点があります。
**ALBのリスナーがHTTP:80のまま（HTTPSなし）**です。
興味深いのは、パターンBの設計ドキュメントには ALB で HTTPS 対応可能な構成 と書かれている点です。つまりKiroは「HTTPSにすべき」と知っているが、明示的に指示されないと実装しないということです。
「Well-Architected準拠で」という一文だけでは届かない部分がここに出ています。
その他、変わらなかった点：
- CloudWatch Logsエージェントの設定（EC2内のアプリログ収集）
- Gravitonインスタンスの未使用（x86のまま）
- ALBアクセスログの無効（コスト節約のため
falseと明記されているが）
Well-Architected 6本柱 採点比較
AWS Well-Architected Frameworkの設問（OPS/SEC/REL/PERF/COST/SUSの各柱から選定）に対応した30項目のベストプラクティスチェックで採点しました。
| 柱 | 対応WA設問（主要） | パターンA | パターンB | 主な差分 |
|---|---|---|---|---|
| 運用上の優秀性 | OPS04・OPS07・OPS08 | 1/5 | 4/5 | VPC Flow Logs・CWアラーム・SSM IAMロール |
| セキュリティ | SEC05・SEC06・SEC08 | 2/5 | 5/5 | 暗号化・IAMロール・IMDSv2・Secrets Manager |
| 信頼性 | REL07・REL09・REL10 | 2/5 | 5/5 | Multi-AZ・ASG・DeletionPolicy:Snapshot |
| パフォーマンス効率 | PERF01・PERF02・PERF03 | 2/5 | 4/5 | TargetTracking・gp3 EBS追加（Graviton未使用） |
| コスト最適化 | COST05・COST06・COST09 | 3/5 | 4/5 | Auto Scaling追加（Graviton未使用） |
| 持続可能性 | SUS02・SUS03・SUS05 | 2/5 | 4/5 | Auto Scaling・gp3 EBS追加（Graviton未使用） |
| 合計 | 12/30 | 26/30 |
余談：公式サンプルリポジトリを参照させたら？（パターンC）
せっかくなので追加検証として、AWSが公式に公開しているCloudFormationサンプルリポジトリ（aws-cloudformation/aws-cloudformation-templates）をプロンプトに追加してみました。パターンBのプロンプトに参考URLを1行加えただけです。
...（パターンBと同じ要件）...
参考：https://github.com/aws-cloudformation/aws-cloudformation-templates
設計ドキュメントも作成してください。
結果は「良い部分の取り込み」と「既存機能の脱落」が同時に起きるという興味深いものでした。
パターンBから新たに追加された機能：
- SNS Topicとメールサブスクリプション（ついにアラームの実通知が届く）
- CloudWatchアラームが3つに増加（EC2 CPU・RDS CPU・ALB UnhealthyHostCount）
- PHPによる実際のDB接続テストをWebページに表示
- VpcCIDRのパラメータ化
一方でパターンBから消えた機能：
- Secrets Manager → NoEchoパラメータに逆戻り
- EBS暗号化なし
- VPC Flow Logsなし
- IAMロールから
CloudWatchAgentServerPolicyが消えた
6本柱スコアで比較するとパターンB（26点）よりパターンC（23点）の方が低い評価になりました。確認したところ、サンプルのコードは実際そうなっていたので、そっちを参考に作ってしまったようです。AWSさんのサンプルなんでここはWell-Architected Frameworkに準じていて欲しかった。。。と思ったのは秘密です(笑)
まとめ
「Well-Architected Frameworkに準拠して」という一文を追加するだけで、Kiroの出力は大きく変わりました。特にセキュリティと信頼性の観点での改善は顕著で、Secrets Manager・IMDSv2・Multi-AZ・ASGといった本番必須の要素が自動で入ってきます。
一方で限界も見えました。HTTPSの実装、CloudWatch Logsエージェント、Gravitonインスタンスへの移行——これらはKiroも「やるべき」と認識しているにもかかわらず、明示的な指示がないと手をつけません。
「どこまで指示するか」がインフラエンジニアの腕の見せ所という結論は、AIが普及した今でも変わらないようです。
検証コード
本記事の検証で使用したCFnテンプレートと設計ドキュメントはGitHubで公開しています。
本番環境への適用前には必ずセキュリティレビューを実施してください。
次回予告
第2部では、KiroのSpec機能を使って要件をより構造的に仕込んでみます。
パターンBと同じプロンプトをSpecモードに投入したら何点になるか。さらに詳細な仕様書を事前に定義したらどうなるか。満点（30/30）は取れるのか——その検証結果をお届けします。