はじめに

最近、
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 は、
うまく使えばかなり強力な組み合わせだと感じました。

同じようなことを考えている方の参考になれば嬉しいです 🙌