Terraform MCP × AWS Knowledge MCP Server で1発でどこまでIaCを構築できるのかを検証してみた

こんにちは、株式会社エクスプラザのTsucchiiです。
今回は、Terraform MCP × AWS Knowledge MCP Serverを使って1発でどこまでIaCを構築できるのか、どれくらい差が出るのかを検証しました。

---

はじめに

2025年10月、AWSが「AWS Knowledge MCP Server」を一般提供しました。

AWS Knowledge MCP Server は、AWS公式ドキュメントだけでなく、ブログ記事、新機能の発表、Well-Architectedのベストプラクティスなど信頼できるナレッジを生成AIが直接参照できる仕組みです。

開発を行う中で、「構築工数の削減」と「品質の担保」を両立したいという課題感を感じていました。
そこで、AIに Knowledge MCP からナレッジを参照させたうえで、インフラ構築をしてもらえば品質を向上できるのではないかと考えました。

今回は Claude Code × Terraform MCP × Knowledge MCP を使って、
AIがTerraformを「1発で」どこまで構築できるのかを検証しました。

---

検証目的と構成

目的は「AIが1回の生成でどこまで現実的なインフラコードを書けるか」を測ることです。
MCPを組み合わせることで、構文精度・セキュリティ・設計意図がどう変わるかを比較しました。

Case	構成	概要
Case1	LLM単体	Claude Code にプロンプトのみ投げて生成
Case2	Terraform MCP	Terraform構文と依存関係の正確性をMCPで補強
Case3	Terraform MCP × Knowledge MCP	AWS公式Docsを参照し、ベストプラクティスに基づく設計生成

対象リソース: VPC / ALB / ECS / ECR / RDS (PostgreSQL)

---

検証環境

項目	内容
LLM	Claude Code Sonnet 4.5
Terraform	v1.9.x
AWS CLI	必要な権限を与えたプロファイル
MCP	Terraform MCP / Knowledge MCP
セキュリティチェック	Checkov v3
OS / IDE	macOS + VSCode

Checkovを導入し、生成コードをセキュリティ面から定量評価しました。

---

プロンプト

各Case共通の構文・環境条件を与えつつ、MCPの利用だけを差分にしました。

# Case1（LLM単体）
AWSで VPC / ALB / ECS / ECR / RDS (PostgreSQL) を使い、
Webアプリ用インフラを構築する Terraform コードを生成してください。

要件:
- Terraform v1.9 に対応
- AWSリージョン: ap-northeast-1
- AWSプロファイル: "✕✕✕✕"
- セキュリティ（暗号化・最小権限・Private Subnet配置）・コスト・保守性を考慮してください。
- 必要であれば variables.tf や outputs.tf、modules ディレクトリなども生成して構いません。
- 各ファイルの先頭にファイル名をコメントとして示してください（例: # main.tf）。
- コード以外の説明文やMarkdownフェンス( ``` )は禁止です。
- 承認を求めず、Terraformコードをterraform1ディレクトリに出力してください。

Case2 / Case3 のプロンプトには、それぞれ以下を追加しました。

• Case2: Terraform MCPを活用して、Terraform構文の正確性や依存関係を考慮したコードを生成してください。
• Case3: AWS Knowledge MCPを活用して、AWS公式ドキュメントやベストプラクティスを参照し、各設定の意図をコメントとして簡潔に記載してください。

---

実際の画面

Case3では、Knowledge MCPを導入することで、各モジュールのベストプラクティスや、セキュリティ設定を参照してくれています。

出力結果

Case	構成	特徴
LLMのみ	モジュール構成	21ファイル（5モジュール: vpc, ecr, rds, alb, ecs）
Terraform MCP	フラット構成	12ファイル（リソース別分割 / default_tags設定あり）
Terraform MCP × Knowledge MCP	拡張フラット構成	15ファイル（README.md＋versions.tf / iam, kmsを独立）

指示しなくても各Caseで構成を最適化し、Caseごとに異なる設計スタイルを選択しました。

コードはGithub上で公開しています。
https://github.com/htsuchi14/aws-knowledge-mcp-test

---

分析結果

構文・依存関係

Case	validate	plan
LLMのみ	成功	OK
Terraform MCP	成功	変数未設定（db_password）
Terraform MCP × Knowledge MCP	成功	OK

構文エラーは全Caseでゼロでした。
Terraform MCPを導入することで、依存関係の解決精度が上がったことも確認できました。

---

Checkovによるセキュリティ評価

Case	Passed	Failed	Total	Pass率
LLMのみ	60	19	79	76%
Terraform MCP	67	17	84	80%
Terraform MCP × Knowledge MCP	124	14	138	90%

重大度別内訳:

重大度	Case1	Case2	Case3
HIGH	10	9	5
MEDIUM	7	7	8
LOW	2	1	1

Knowledge MCPを使ったCase3で、Highリスク項目は50%削減されました。
一方、Case3では、CloudWatch Logsなどの監視設定を追加したため、Mediumリスクは若干増加しています。

---

コードベースでの具体的な違い

セキュリティグループの実装比較

Case1（LLM単体）

resource "aws_security_group" "alb" {
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]  # 全開放
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Case3（Terraform MCP × Knowledge MCP）

resource "aws_security_group" "alb" {
  vpc_id = aws_vpc.main.id
}

resource "aws_security_group_rule" "alb_ecs_outbound" {
  type                     = "egress"
  from_port                = var.container_port
  to_port                  = var.container_port
  protocol                 = "tcp"
  source_security_group_id = aws_security_group.ecs_tasks.id
}

セキュリティグループとルールを分離し、指示せずともegressを最小権限化する実装に進化してくれています。

---

暗号化設定の比較

Case1（KMSなし）

resource "aws_ecr_repository" "app" {
  name = "${var.project_name}-app"
}

Case3（KMSあり）

resource "aws_kms_key" "ecr" {
  enable_key_rotation = true
}

resource "aws_ecr_repository" "app" {
  encryption_configuration {
    encryption_type = "KMS"
    kms_key = aws_kms_key.ecr.arn
  }
  image_scanning_configuration {
    scan_on_push = true
  }
}

Knowledge MCPが参照したAWSドキュメントに基づき、KMS暗号化・スキャン機能を自動追加していました。

---

考察

Terraform MCP：構文と依存関係

Terraform MCPはリアルタイムでAWS Provider Docsを検索し、構文の正確性を向上させています。
また、Case2ではdepends_onやlifecycleの自動挿入が確認され、LLM単体よりも構文の安定性が向上していました。

Knowledge MCP：セキュリティ知識を補完

Knowledge MCPはAWS公式ドキュメントやWell-Architected Frameworkを参照し、
Case3では全リソースでKMS暗号化・IAM最小権限が導入されました。
また、生成過程で「CloudWatch Logsにはkms:Encrypt権限が必要」といった依存知識を補完していました。

課題

削除保護やMulti-AZ設定など、コストと可用性のトレードオフはAIが自動判断できません。
これらは環境要件に依存するため、プロンプトで明示的に指定する必要があります。

---

まとめ

定量的成果

指標	Case1	Case3
セキュリティPass率	76%	90%
HIGHリスク	10件	5件
KMS暗号化リソース	0	3
IAM最小権限ポリシー	1	4
コメント行数	18	99

技術的発見

• Knowledge MCP導入後、明記しなくても暗号化や最小権限が自動適用されました。
• プロンプトを書く時は、Terraform MCP ⇒ Knowledge MCPの順よりも、Knowledge MCP⇒Terraform MCPの順で明記したほうが精度が高かったです。
  理由は不明ですが、Knowledge MCPを知識をインプットしてTerraform MCPで構文や整合性を保証する流れに沿って思考できるからかもしれません。
• 設計意図が含まれたコメントを書いてくれるものの、冗長になりがちなので、プロンプトで調整したほうが良さそうです。

使いどころ

• 新規構築やセキュリティを見直したいフェーズでは特に有効になりそうです。
• ただしコスト最適化やプロジェクトごとの固有のルールの反映はプロンプトの明確化が必要になりそうなので、以下の項目をプロンプトに含めると良いと思いました。
  1. 環境指定（本番 / 開発）
  2. 制約条件（予算など）
  3. 優先順位（セキュリティ > コスト）
  4. 統合対象リソースID
  5. 出力形式（モジュール or フラット）

---

最後に

Knowledge MCPを導入したことで、AIがなぜその設定にしたのかを、AWS公式ドキュメントなどの参照ソースを明示したうえで説明できるようになりました。
これにより、単にコードを生成するだけでなく、ベストプラクティスを理解しながら自分のプロジェクトに合わせて修正できる点は魅力的だと感じました。

一方で、Knowledge MCPを導入することで、出力されたコードが良くも悪くもドキュメントの参照結果に忠実すぎる傾向があります。
AWSの理想形に従った「安全すぎる設計」や「コストを無視した構成」を出す場合もあり、最終的な方向性はプロンプトでどう指示するかに強く依存します。
つまり、MCPを最大限活かすためには、「どのような環境を前提に、どのような優先度で設計してほしいか」を明示するプロンプト設計も重要になりそうです。

Knowledge MCPは知識を注入し、Terraform MCPは構文と整合性を保証するという役割分担が、実務でも一定有効なアプローチであると感じました。

---

参考資料

• AWS Knowledge MCP Server リリース
• Well-Architected Framework
• AWS Well-Architected Security Pillar
• AWS Knowledge MCP Server (AWS Labs)
• Terraform MCP Server (AWS Labs)
• Checkov (Bridgecrew)

---