CFn書く時のMCPどうしてますか？
最近私は Kiro を使って、CloudFormationなどを書くことが多いのですが、ウェブ検索したり、AWSドキュメントを読みに行ったり、IaC MCPを使ったり・・・
とりあえず全部有効化してますが、ほんとに全部必要なの？逆に無駄に時間かかっていたりしない？
と、ふと気になったので、検証してみます。
試行回数1回ですし、Haikuなので、参考程度にしてくださいね！
検証
検証はいくつかのテーマで以下のエージェントにそれぞれテンプレートを作ってもらい、Claudeに評価してもらおうと思います。
| エージェント | ウェブ検索 | ドキュメントMCP | IaC MCP |
|---|---|---|---|
| ウェブ番長 | 〇 | × | × |
| ドキュメント番人 | × | 〇 | × |
| テンプレ職人 | × | × | 〇 |
| 調査員 | 〇 | 〇 | × |
| 現場の匠 | 〇 | × | 〇 |
| 公式信者 | × | 〇 | 〇 |
| 万能エージェント | 〇 | 〇 | 〇 |
| 素のAI | × | × | × |
シナリオ
シナリオは設計が決まっているかどうか、複雑かどうかの観点で4つのシナリオを作成しました。
シナリオ1（シンプル×詳細設計あり）
以下の設計でS3バケットを作成するテンプレートを作ってください。
- バケット名:パラメータで指定(デフォルト: log-archive-<アカウントID>)
- バージョニング:有効
- 暗号化:SSE-KMS(カスタマー管理キーを同じテンプレートで作成)、バケットキー有効
- パブリックアクセス:すべてブロック
- バケットポリシー:HTTPS以外のアクセスを拒否
- ライフサイクル:
- 現行バージョンは90日後にGlacier Instant Retrievalへ移行
- 非現行バージョンは365日後に削除
- 未完了のマルチパートアップロードは7日後に削除
- オブジェクト所有者:BucketOwnerEnforced
- スタック削除時:バケットは保持
シナリオ2（シンプル×要件のみ）
社内向けのドキュメントを静的サイトとして公開したいです。
HTTPSでアクセスできるようにしてください。
シナリオ3（複雑×詳細設計あり）
以下の設計でWebアプリケーション基盤を作成するテンプレートを作ってください。
【ネットワーク】
- VPC:10.0.0.0/16、2AZ構成
- サブネット:
- パブリック:10.0.0.0/24, 10.0.1.0/24
- プライベート(アプリ):10.0.10.0/24, 10.0.11.0/24
- プライベート(DB):10.0.20.0/24, 10.0.21.0/24
- NAT Gateway:AZごとに1台
- VPCエンドポイント:S3(Gateway)、ECR api/dkr・CloudWatch Logs・Secrets Manager(Interface)
- VPC Flow Logs:CloudWatch Logsへ出力、保持期間90日
【アプリケーション】
- ALB:インターネット向け、HTTPSのみ(ACM証明書ARNはパラメータ)、HTTPはHTTPSへリダイレクト
- ECS on Fargate:
- タスク:CPU 512 / メモリ 1024、ARM64
- コンテナイメージ:パラメータで指定
- 希望タスク数2、CPU使用率70%でオートスケーリング(最小2・最大6)
- ECS Exec有効
- デプロイ失敗時の自動ロールバック有効(デプロイサーキットブレーカー)
【データベース】
- Aurora PostgreSQL 16系、Serverless v2(最小0.5 ACU・最大4 ACU)
- ライター1台、リーダー1台
- マスターパスワードはRDSによるSecrets Manager管理機能を使用
- Performance Insights有効
- バックアップ保持期間14日、スタック削除時はスナップショット取得
【セキュリティグループ】
- ALB:0.0.0.0/0から443のみ
- ECS:ALBからのコンテナポート(8080)のみ
- Aurora:ECSから5432のみ
シナリオ4（複雑×要件のみ）
社内向けの業務Webアプリをコンテナで動かす基盤を作りたいです。
- DBはPostgreSQLを使います
- 業務時間中に止まると困ります
- 夜間や休日はほとんど使われないので、コストは抑えたいです
- アプリのログは1年間保管が必要です
- サーバーにパッチを当てる運用はしたくありません
- 将来的にアクセスが増える可能性があります
検証結果
実行時間
実行時間は以下の通りです。
| エージェント | SCENARIO1 | SCENARIO2 | SCENARIO3 | SCENARIO4 | 平均 |
|---|---|---|---|---|---|
| ウェブ番長 | 10.21 | 14.61 | 42.07 | 27.31 | 23.55 |
| ドキュメント番人 | 24.03 | 35.35 | 39.73 | 39.86 | 34.74 |
| テンプレ職人 | 12.57 | 12.61 | 32.74 | 27.62 | 21.39 |
| 調査員 | 12.61 | 23.67 | 43.92 | 37.80 | 29.50 |
| 現場の匠 | 17.74 | 10.81 | 51.10 | 27.38 | 26.76 |
| 公式信者 | 20.40 | 25.03 | 39.09 | 35.74 | 30.07 |
| 万能エージェント | 13.86 | 20.03 | 36.69 | 30.05 | 25.16 |
| 素のAI | 6.87 | 8.41 | 31.13 | 17.44 | 15.96 |
概ね想定通りですね、AWSドキュメントMCPを使っているエージェントが比較的処理時間が長いことが読み取れます。
正確性
シナリオに沿って動くテンプレートが作成できているかを評価します。（100点満点）
| エージェント | SCENARIO1 | SCENARIO2 | SCENARIO3 | SCENARIO4 | 平均 |
|---|---|---|---|---|---|
| ウェブ番長 | 42 | 35 | 53 | 46 | 44.00 |
| ドキュメント番人 | 75 | 56 | 52 | 45 | 57.00 |
| テンプレ職人 | 53 | 39 | 67 | 47 | 51.50 |
| 調査員 | 59 | 43 | 61 | 54 | 54.25 |
| 現場の匠 | 60 | 30 | 71 | 50 | 52.75 |
| 公式信者 | 63 | 50 | 74 | 47 | 58.50 |
| 万能エージェント | 56 | 33 | 75 | 47 | 52.75 |
| 素のAI | 56 | 33 | 68 | 49 | 51.50 |
シナリオ1
| 順位 | エージェント | Web | Docs | IaC | 点数 | デプロイエラー数 | 主な問題 | 特記事項 |
|---|---|---|---|---|---|---|---|---|
| 1 | ドキュメント番人 | × | 〇 | × | 75 | 1 | NoncurrentVersionExpirations |
KMS キーの Retain とローテーションに対応した唯一のエージェント |
| 2 | 公式信者 | × | 〇 | 〇 | 63 | 1 | Default に !Sub / 現行バージョン移行を非現行バージョン向けに記述 |
コメントと実装が食い違う |
| 3 | 現場の匠 | 〇 | × | 〇 | 60 | 3 | Default に !Sub / ObjectOwnership の位置 / PolicyText
|
ライフサイクルが完全に正しい唯一のエージェント（自己修正後） |
| 4 | 調査員 | 〇 | 〇 | × | 59 | 2 |
PolicyText / NoncurrentVersionExpirations
|
Tags と Export あり |
| 5 | 素のAI | × | × | × | 56 | 2 |
PolicyText / NoncurrentVersionExpirations
|
推測欄と実装が一致しない |
| 5 | 万能エージェント | 〇 | 〇 | 〇 | 56 | 2 | Default に !Sub / PolicyText / 現行バージョンが移行されない |
誤った説明と自己矛盾のある注意書き |
| 7 | テンプレ職人 | × | × | 〇 | 53 | 2 |
PolicyText / NoncurrentVersionExpirations
|
要件外の PutObject の Deny 文がログ配信を阻害する恐れ |
| 8 | ウェブ番長 | 〇 | × | × | 42 | 3 |
PolicyText / NoncurrentVersionExpirations / AbortIncompleteMultipartUploads
|
バケットの Retain なし。「タグで削除保護」という誤った説明 |
-
ドキュメント MCP の効果が最も大きい。 上位 2 つ（ドキュメント番人・公式信者）はどちらもドキュメント MCP ありでウェブ検索なしの構成で、
PolicyDocumentを正しく書けたのもこの 2 つだけだった。 -
ウェブ検索は逆効果の傾向がある。 ウェブ検索のみのウェブ番長が最下位だった。ドキュメント MCP があっても、ウェブ検索を併用した調査員と万能エージェントでは
PolicyTextの誤りが再発している。非公式・古い情報が混ざった可能性がある（仮説）。 -
IaC MCP は平均点には影響しないが、効果と副作用の両方が見られた。
- 効果：
NoncurrentVersionExpirationInDaysを正しく書けたのは IaC MCP ありの 3 つだけだった。 - 副作用：Default に
!Subを書く誤りも、IaC MCP ありの 3 つで発生した。要件に忠実な設計を試みたものの、検証（cfn-lint 相当）まではできていない。
- 効果：
- MCP を全部載せても最良にはならない。 万能エージェントは素のAI と同点の 56 点だった。情報源が増えると、矛盾する情報を取捨選択する負荷が上がる可能性がある。
- 設計判断の抜けはどの構成でも防げなかった。 KMS キーの保持漏れ（バケットだけ残ってデータを復号できなくなる）は 8 つ中 7 つで発生した。構文の知識ではなく設計上の配慮の問題なので、MCP では補えなかった。
シナリオ2
| 順位 | エージェント | 点数 | デプロイエラー数 | S3 の保護方式 | 証明書 | エラーページ | 主な問題 |
|---|---|---|---|---|---|---|---|
| 1 | ドキュメント番人 | 56 | 1 | OAC | ACM（自動検証） | 404 | ログバケットの ACL / us-east-1 の制約が未記載 |
| 2 | 公式信者 | 50 | 1 | OAI | デフォルト | SPA 型 | ログバケットの ACL / 旧方式の構成 |
| 3 | 調査員 | 43 | 3 | OAC | 切り替え式 | 404 |
PolicyText ×2 / ログバケットの ACL / 非対応のパスパターン |
| 4 | テンプレ職人 | 39 | 2 | OAI | デフォルト | なし |
PolicyText / ログバケットの ACL |
| 5 | ウェブ番長 | 35 | 3 | OAI | ACM（事前作成） | SPA 型 |
PolicyText / ForwardedValues と CachePolicyId の併用 / ErrorCachingMinTtl
|
| 6 | 万能エージェント | 33 | 5 以上 | OAC | デフォルト | 404 | 論理 ID のタイプミス / 実在しないポリシー ID / DefaultRootObject なし |
| 6 | 素のAI | 33 | 4 | OAI | ACM（既存） | 404 |
Parameters の重複 / OAI の ARN 書式 / プロパティの配置ミス |
| 8 | 現場の匠 | 30 | 2 + 停止 | OAI | ACM（検証で停止） | 404 | ACM の DNS 検証が自動化されていない / TTL と CachePolicyId の併用 |
- OAC を採用した 3 つは、すべてドキュメント MCP ありだった。
シナリオ3
| 順位 | エージェント | 点数 | デプロイエラー数 | Serverless v2 | パスワード管理 | Performance Insights | ECS Exec | HTTP リダイレクト | 主な問題 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 万能エージェント | 75 | 3 | 〇 | △ | ✕ | 〇 | ✕ |
MasterUsername なし / クラスターに EnablePerformanceInsights / Secrets Manager エンドポイントのサブネット重複 |
| 2 | 公式信者 | 74 | 4 | 〇 | 〇 | 〇 | 〇 | 〇 |
DeliverLogsPermissionIAM / キーの重複 / Alarms の Rollback 欠如 / エンドポイントのサブネット重複 |
| 3 | 現場の匠 | 71 | 5 | 〇 | 〇 | 〇 | 〇 | 〇 |
IpCidrRange / 無効な LogFormat / ECS Exec ログ設定の矛盾 / DeliverLogsPermissionIAM / エンドポイントのサブネット重複 |
| 4 | 素のAI | 68 | 4 | 〇 | ✕ | ✕ | 〇 | 〇 | 存在しない ManagedMasterUserPassword と EnableMultiAZ / クラスターに EnablePerformanceInsights / DeliverLogsPermissionIAM
|
| 5 | テンプレ職人 | 67 | 3 | 〇 | ✕ | ✕ | ✕ | ✕ | ECS Exec 未設定 / パスワードが平文の環境変数 / キーの重複 / エンドポイントのサブネット重複 |
| 6 | 調査員 | 61 | 4 | ✕ | △ | ✕ | 〇 | ✕ |
MinAcu / MasterUsername なし / インスタンスに PerformanceInsightsEnabled / DB サブネットに NAT 経路 |
| 7 | ウェブ番長 | 53 | 6 以上 | ✕ | ✕ | ✕ | ✕ | ✕ | 2 つ目のクラスター・サービスを作成 / パスワード設定の矛盾 / エンドポイントポリシーでイメージ取得不可 |
| 8 | ドキュメント番人 | 52 | 6 以上 | ✕ | △ | ✕ | ✕ | ✕ | Resources 内に Type: String / DBClusterInstanceClass / MinACU / DB サブネットに NAT 経路 |
- IaC MCP ありの 4 つが 1〜3 位と 5 位を占めた。平均点は IaC MCP あり 71.8、なし 58.5（差 +13.3）。
- シナリオ1・2 で効いていたドキュメント MCP（+0.8）とウェブ検索（−0.3）の差は、ほぼ消えた。
- Aurora Serverless v2 を正しく書けたのは、IaC MCP ありの 4 つと素のAI だけだった。
- パスワード管理と Performance Insights の両方を正しく実装したのは、公式信者と現場の匠（どちらも IaC MCP あり）だけだった。
- DB サブネットに NAT 経路を持たせたのは、ドキュメント MCP あり・IaC MCP なしの 2 つ（ドキュメント番人・調査員）だった。
- 仕様の矛盾（443 のみ許可と HTTP リダイレクト）に推測欄で触れたエージェントは 0/8。80 番を開けてリダイレクトを機能させたのは 3 つ（公式信者・現場の匠・素のAI）で、いずれも理由を推測欄で説明していない。
シナリオ4
| 順位 | エージェント | 点数 | デプロイエラー数 | DB の構成 | DB の冗長性 | 夜間のコスト対策 | 主な問題 |
|---|---|---|---|---|---|---|---|
| 1 | 調査員 | 54 | 3 | Aurora SV2 2 台 | 〇 | SV2 + Spot |
ServerlessV2ScalingConfiguration なし / LaunchType とキャパシティプロバイダーの併用 / キャパシティプロバイダーの二重設定 |
| 2 | 現場の匠 | 50 | 2 | RDS マルチ AZ | 〇 | 低コストの DB + スケジュール（UTC） |
StorageEncryption / EnableAutoMinorVersionUpgrade / UTC のため業務時間中に縮小 |
| 3 | 素のAI | 49 | 0 | Aurora プロビジョンド 2 台 | 〇 | なし | 夜間の対策なし / 存在しないシークレットを参照 / サーキットブレーカーなし |
| 4 | テンプレ職人 | 47 | 3 | Aurora SV2 1 台 | ✕ | SV2 + Spot |
LaunchType と CapacityProviderStrategy の併用 / キャパシティプロバイダー未関連付け / ReadReplicaCount に 0.5 |
| 4 | 万能エージェント | 47 | 2〜3 | Aurora プロビジョンド 2 台 | 〇 | なし（推測欄のみ） |
Action の重複 / db.t4g.small は非対応 / MultiAZ
|
| 4 | 公式信者 | 47 | 0〜1 | Aurora プロビジョンド 2 台 | 〇 | なし（推測欄のみ） |
MultiAZ / log_statement: all でログが肥大化 / 実行ロールにシークレットの権限なし |
| 7 | ウェブ番長 | 46 | 4 | Aurora プロビジョンド 2 台 | 〇 | スケジュール（UTC）+ Spot | IGW の Tags の位置 / LaunchType との併用 / EnableMultiAZ / DesiredReadReplicaCount
|
| 8 | ドキュメント番人 | 45 | 1〜2 | Aurora Serverless v1 | ✕ | 自動一時停止（v1）+ スケジュール（UTC） | Serverless v1 はサポート終了 / インターネット公開を明言 / UTC と認識しながら未対処 |
- 「社内向け」のアクセス制限を実装したのは 0/8。HTTPS のリスナーを作成したものも 0/8 だった。
- そのままデプロイして、アプリが DB に接続できるテンプレートは 0/8 だった。
- スケジュールスケーリングを実装した 3 つは、すべて UTC のまま（
Timezoneの指定なし）だった。 - 推測欄で夜間のコスト削減を掲げながら実装しなかったものが 3 つ（万能・公式信者・素のAI）あった。
- NAT Gateway を AZ ごとに配置したのも、Aurora のログの保持期間を正しく 365 日にしたのも、調査員だけだった。
サマリ
総合順位
| 順位 | エージェント | Web | Docs | IaC | S1 | S2 | S3 | S4 | 平均 | 各シナリオの順位 |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 公式信者 | × | 〇 | 〇 | 63 | 50 | 74 | 47 | 58.50 | 2 → 2 → 2 → 4 |
| 2 | ドキュメント番人 | × | 〇 | × | 75 | 56 | 52 | 45 | 57.00 | 1 → 1 → 8 → 8 |
| 3 | 調査員 | 〇 | 〇 | × | 59 | 43 | 61 | 54 | 54.25 | 4 → 3 → 6 → 1 |
| 4 | 現場の匠 | 〇 | × | 〇 | 60 | 30 | 71 | 50 | 52.75 | 3 → 8 → 3 → 2 |
| 4 | 万能エージェント | 〇 | 〇 | 〇 | 56 | 33 | 75 | 47 | 52.75 | 5 → 6 → 1 → 4 |
| 6 | テンプレ職人 | × | × | 〇 | 53 | 39 | 67 | 47 | 51.50 | 7 → 4 → 5 → 4 |
| 6 | 素のAI | × | × | × | 56 | 33 | 68 | 49 | 51.50 | 5 → 6 → 4 → 3 |
| 8 | ウェブ番長 | 〇 | × | × | 42 | 35 | 53 | 46 | 44.00 | 8 → 5 → 7 → 7 |
| シナリオ平均 | 58.0 | 39.9 | 65.1 | 48.1 | 52.8 |
- 公式信者は順位が最も安定していた（2 位・2 位・2 位・4 位）。
- ドキュメント番人は順位の変動が最も大きかった（小規模で 1 位、大規模で最下位）。
- ウェブ番長は 4 シナリオすべてで下位だった（シナリオ3 ではウェブ検索を使えなかった）。
MCP の有無による平均点の差
| MCP | S1 明確・小 |
S2 曖昧・小 |
S3 明確・大 |
S4 曖昧・大 |
総合 |
|---|---|---|---|---|---|
| ドキュメント MCP | +10.5 | +11.3 | +0.8 | +0.3 | +5.7 |
| ウェブ検索 | −7.5 | −9.3 | −0.3 | +2.3 | −3.7 |
| IaC MCP | ±0 | −3.8 | +13.3 | −0.8 | +2.2 |
有効な MCP は、テンプレートの規模によって入れ替わった。
- 小規模なテンプレート（S1・S2）では、ドキュメント MCP が約 +11 点の差を生んだ。
- 大規模なテンプレート（S3）では、IaC MCP が +13 点の差を生み、ドキュメント MCP の効果は消えた。
- 曖昧で大規模なテンプレート（S4）では、どの MCP も差を生まなかった。
- ウェブ検索は、全体としてマイナスまたは効果なしだった。
おわりに
モデルや検証回数を変えて、いろいろなシナリオで試したらもっと特徴が出るかもしれないですね。
私が確認した感覚では、動くものを作るという観点ではIaC MCP、最新情報やベストプラクティスに沿ったものを作るという観点ではドキュメントMCP、ウェブMCPはあまり意味がなさそうという結論でした。
作成された物をそのままデプロイして動くものは現状なさそうだったので、事前の検証やレビューは相変わらず大事ですね！
弊社では一緒に働く仲間を募集中です！
現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！
募集内容等詳細は、是非採用サイトをご確認ください。