はじめに
最近、
Well-Architected Framework のチェックをAIにやらせるという話を見かけて、
これが個人的にかなり面白くて、
- IaCのレビューって毎回大変だよな…
- ベストプラクティスとのズレも気になる…
と感じていたこともあり、
👉「これ、自分でも試してみたいな」
という軽いノリで検証してみることにしました。
本記事では、
Terraformで構築したIaCに対して、
Well-Architected FrameworkをベースにAIでチェックする仕組みを試した内容をまとめます。
やったこと
今回やったことはシンプルで、以下の流れです。
① Well-Architected Framework をローカルに配置
- AWSのWell-Architected FrameworkをPDFでダウンロード
https://docs.aws.amazon.com/ja_jp/wellarchitected/2024-06-27/framework/wellarchitected-framework-2024-06-27.pdf - Terraformプロジェクトのルートディレクトリに配置
project-root/
├── env/
│ ├── dev/
│ │ └── main.tf
│ ├── stg/
│ │ └── main.tf
│ └── prod/
│ └── main.tf
├── modules/
│ ├── cicd/
│ ├── ecr/
│ └── network/
├── AGENTS.md
├── README.md
├── well-architected.pdf
② CodeXでIaCとPDFを照合する
CodeXを使って、
- Terraformコード（IaC）
- Well-Architected Framework（PDF）
この2つを参照しながら、
👉 「ベストプラクティスに沿っているか？」をチェックするフロー
を作成しました。
③ チェック結果をレポートとして出力
チェック結果は、いつでも見られるようにマークダウン形式で出力するようにしました。
# Well-Architected Check Report
- Generated at: `2026-03-22T14:05:55.870821+00:00`
- Environment: `dev`
- Source PDF: `wellarchitected-framework.pdf`
- Evaluated path: `envs/dev` and `modules/*`
## Summary
- PASS: `18`
- PARTIAL: `0`
- FAIL: `1`
- MANUAL: `3`
## Effective Inputs
- `aws_region`: `ap-northeast-1`
- `project_name`: `test`
- `environment`: `dev`
- `az_count`: `2`
- `single_nat_gateway`: `true`
- `restrict_alb_to_cloudfront`: `true`
- `ecs_desired_count`: `2`
- `health_check_path`: `/health`
- `log_retention_in_days`: `30`
## Operational Excellence
### OPS01 環境 README に運用・構成情報が整理されている
- Status: `PASS`
- Evidence: `envs/dev/README.md` に module・構成図・主要リソース・主要 output が記載されています。
- Recommendation: README に利用 module、作成リソース、構成図または接続経路、主要設定値、主要 output をそろえます。
### OPS02 変更を再現可能なパイプラインでデプロイできる
- Status: `PASS`
- Evidence: CodePipeline と CodeBuild が Terraform 管理され、CodeBuild のログ出力先も定義されています。
- Recommendation: CodePipeline と CodeBuild を Terraform で定義し、ビルドログを CloudWatch Logs に出します。
## Security
### SEC01 必須タグで資産識別と管理責任を追跡できる
- Status: `PASS`
- Evidence: provider `default_tags` と `local.common_tags` で必須タグが共通化されています。
- Recommendation: provider `default_tags` を使い、`Project` `Environment` `ManagedBy` を全リソースに適用します。
### SEC02 アプリ入口を CloudFront 経由に制限する
- Status: `PASS`
- Evidence: ALB 受信は CloudFront origin-facing managed prefix list に制限されています。
- Recommendation: ALB 直公開を避け、CloudFront origin-facing prefix list だけを許可します。
### SEC03 コンテナイメージの保護と検査を有効にする
- Status: `PASS`
- Evidence: ECR は push 時スキャンと暗号化が有効です。
- Recommendation: ECR で `scan_on_push` と暗号化を有効にします。
### SEC04 配布物を保存する S3 bucket を保護する
- Status: `PASS`
- Evidence: CI/CD artifact bucket は SSE-S3 と public access block が有効です。
- Recommendation: artifact bucket にサーバー側暗号化と public access block を設定します。
### SEC05 認証基盤で基本的なパスワード保護を適用する
- Status: `PASS`
- Evidence: Cognito password policy と user existence error の秘匿が有効です。
- Recommendation: Cognito password policy と `prevent_user_existence_errors` を有効にします。
## Reliability
### REL01 public/private subnet を複数 AZ に分散する
- Status: `PASS`
- Evidence: `az_count = 2` で public/private subnet が AZ ごとに作られます。
- Recommendation: 少なくとも 2AZ で public/private subnet を対にして配置します。
### REL02 アプリ実行基盤を private subnet に閉じる
- Status: `PASS`
- Evidence: ECS task は private subnet に配置され、public IP を持ちません。
- Recommendation: ECS service の `assign_public_ip = false` と private subnet 配置を維持します。
### REL03 異常デプロイを検知して切り戻せる
- Status: `PASS`
- Evidence: ALB health check と ECS deployment circuit breaker が設定されています。
- Recommendation: ALB health check と ECS deployment circuit breaker を併用します。
### REL04 サービスを単一 task 障害に依存させない
- Status: `PASS`
- Evidence: `ecs_desired_count = 2` で複数 task を維持します。
- Recommendation: 高可用性を求める環境では `ecs_desired_count >= 2` を維持します。
## Performance Efficiency
### PERF03 CloudFront キャッシュを活用してオリジン負荷を下げる
- Status: `FAIL`
- Evidence: CloudFront が `Managed-CachingDisabled` を使っており、キャッシュ最適化が効いていません。
- Recommendation: 動的要件が許す範囲で CloudFront の cache policy を見直します。
### PERF01 配信とアプリ実行の責務を分離する
- Status: `PASS`
- Evidence: CloudFront -> ALB -> ECS の責務分離された公開経路が Terraform に定義されています。
- Recommendation: CloudFront と ALB と ECS を分離し、各レイヤーで最適化できる構成を維持します。
### PERF02 実行基盤の観測性を確保する
- Status: `PASS`
- Evidence: ECS Cluster で Container Insights が有効です。
- Recommendation: Container Insights などのメトリクス収集を有効にします。
## Cost Optimization
### COST01 環境要件に合わせて NAT 構成を最適化する
- Status: `PASS`
- Evidence: この環境は `single_nat_gateway = true` で NAT コストを抑えています。
- Recommendation: dev などコスト優先環境では単一 NAT、可用性優先環境では AZ ごと NAT を評価します。
### COST02 不要なコンテナイメージ保持を避ける
- Status: `PASS`
- Evidence: ECR lifecycle policy で古いイメージを削除できます。
- Recommendation: ECR lifecycle policy で保持数を制御します。
### COST03 再作成コストを抑えるため成果物を追跡できる
- Status: `PASS`
- Evidence: artifact bucket で versioning が有効です。
- Recommendation: artifact bucket で versioning を有効にします。
## Sustainability
### SUS01 ログ保持を無制限にせず運用データ量を制御する
- Status: `PASS`
- Evidence: CloudWatch Logs の保持期間が 30 日に設定されています。
- Recommendation: CloudWatch Logs に明示的な retention を設定します。
### SUS02 配信データ量を抑える設定を有効にする
- Status: `PASS`
- Evidence: CloudFront で圧縮が有効で、HTTPS へ集約されています。
- Recommendation: CloudFront 圧縮や HTTPS 集約を維持します。
## Manual Review
### MAN01 バックアップ・DR・運用手順の有効性
- Status: `MANUAL`
- Evidence: Terraform だけでは RTO/RPO、復旧演習、手順の実効性は判断できません。
- Recommendation: バックアップ設計、復旧手順、演習頻度を別途レビューします。
### MAN02 監視アラームとインシデント対応
- Status: `MANUAL`
- Evidence: このリポジトリには CloudWatch Alarm や通知経路の Terraform 定義が見当たりません。
- Recommendation: 主要メトリクスの Alarm、通知、オンコール手順を追加します。
### MAN03 WAF・独自ドメイン・証明書の前段保護
- Status: `MANUAL`
- Evidence: CloudFront はありますが、WAF と ACM/Route53 の設計有無はこの自動チェックの対象外です。
- Recommendation: 公開要件に応じて WAF、ACM、Route53 の導入可否を評価します。
わかったこと
実際にやってみて感じたことをまとめます。
① 一定レベルのチェックはできそう
CodeXを使うことで、
- セキュリティ観点
- 可用性
- 運用性
といった観点のチェックは、
ある程度自動化できそうだと感じました。
「レビューのたたき台」としてはかなり有効です。
② 自動修正は慎重にした方が良い
最初は、
指摘だけじゃなくて、自動修正もできるのでは？
と考えましたが、
実際には
- 意図しない変更が入る可能性
- 設計思想が崩れるリスク
があるため、
👉 最終的な修正は人間が判断するのが良さそう
という結論になりました。
③ 精度はまだ検証が必要
現時点では、
- 指摘の正確さ
- 過剰な警告
などについては、まだ改善の余地があります。
👉 どこまで信頼できるかは今後の検証次第
といった印象です。
まとめ
今回の検証を通して、
- IaCのレビューをAIで補助するのはかなり有効
- ただし「完全自動化」はまだ早い
- 人間のレビューと組み合わせるのが現実的
という学びがありました。
おわりに
IaC × AI × Well-Architected Framework は、
うまく使えばかなり強力な組み合わせだと感じました。
同じようなことを考えている方の参考になれば嬉しいです 🙌