システム構成図だけを元にCloudFormation MCP ServerにAWSリソースを作らせてみた

#AWS
#Model Context Protocol (MCP)
とーち
2025.05.22
お疲れさまです。とーちです。
前回、CloudFormation MCP Serverについて紹介しました。
https://dev.classmethod.jp/articles/1100-aws-resources-cloudformation-mcp-server-natural-language-creation/
これを使えば、システム構成図だけ読み込ませればAWSリソース一式を作ってもらえるのでは？と思い立ったので試してみました。今回はその結果をご紹介します。
 今回試してみる内容今回試してみるシステム構成図は以下の弊社ホームページにあったものです。
https://classmethod.jp/aws/services/simple-build/
この中の以下の部分だけを切り取ってみました。この画像でシステムを作ってもらいます。なお、MCPクライアントはCline、LLMはBedrockのClaude 3.7 Sonnetを使用しています。
 作成するリソースの確認まず作成するリソース一覧を提示してもらいました。
ほうほう、なんとなく必要なものは網羅されてる気がしますね。
まずどのリソースから作るのかを聞かれたのでVPCからと答えています。
 VPCの作成すると早速リソースを作り始めました。今回は構成図以外の情報を与えていないので適当なCIDR、名前で作られていますが、このあたりも設計書をコンテキストとして与えてあげればちゃんと反映してくれそうな気がします。
VPCはサブネットやルートテーブルなど様々な要素をつくる必要があります。また2AZ分ありますが、まとめて作るといったことはできないので、1AZずつリソースを作っていました。どういった出力がされていたかは割愛しますが、以下のような順序で作っていました。
AWS::EC2::VPC
AWS::EC2::InternetGateway
AWS::EC2::VPCGatewayAttachment（InternetGatewayをVPCに紐づけ）
AWS::EC2::Subnet
AWS::EC2::RouteTable（パブリックサブネット用）
AWS::EC2::Route（インターネットゲートウェイへのルートを追加）
AWS::EC2::SubnetRouteTableAssociation（パブリックサブネットとパブリックルートテーブルの関連付け）
AWS::EC2::EIP（NATGW用）
AWS::EC2::NatGateway
AWS::EC2::RouteTable（プライベートサブネット用）
AWS::EC2::Route（NatGatewayへのルートを追加）
AWS::EC2::SubnetRouteTableAssociation（プライベートサブネット（EC2用）をプライベートルートテーブルに関連付け）
AWS::EC2::SubnetRouteTableAssociation（プライベートサブネット（RDS用）をプライベートルートテーブルに関連付け）
途中のNAT Gatewayの作成時には、NAT Gatewayの作成には数分かかることがあります。 と発言しており、このあたり理解しているのはすごいなと思ったりしました。また途中で以下のように聞かれたので待ち続けるを選択しています。
出来上がったVPCがこちらです。命名規則にばらつきがあるのがちょっとアレですが、ちゃんと意図したものが作られています。
 セキュリティグループの作成続いてEC2のセキュリティグループを作ろうとしていました。
プライベートサブネットに置かれる想定とはいえ、SSHポートの全開放はちょっと頂けないですね。今回のコンセプトは「システム構成図だけで作ってもらう」なので、一旦そのまま作ってもらいます。
RDSのセキュリティグループは以下のように作るようです。DBエンジンの指定が構成図には書かれていませんでしたが、どうやらMySQLで作るようです。
ALB用のセキュリティグループは以下でした。
 EC2インスタンスの作成続いてEC2インスタンスを作っていました。
{
  "resource_type": "AWS::EC2::Instance",
  "properties": {
    "InstanceType": "t2.micro",
    "ImageId": "ami-0d52744d6551d851e",
    "SubnetId": "subnet-04cc191bc1dbfbfab",
    "SecurityGroupIds": ["sg-0cd34d83b37408696"],
    "UserData": "IyEvYmluL2Jhc2gKeXVtIHVwZGF0ZSAteQp5dW0gaW5zdGFsbCAteSBodHRwZApzeXN0ZW1jdGwgc3RhcnQgaHR0cGQKc3lzdGVtY3RsIGVuYWJsZSBodHRwZAplY2hvICc8aHRtbD48Ym9keT48aDE+SGVsbG8gZnJvbSBFQzIgV2ViIFNlcnZlciE8L2gxPjwvYm9keT48L2h0bWw+JyA+IC92YXIvd3d3L2h0bWwvaW5kZXguaHRtbA==",
    "Tags": [
      {
        "Key": "Name",
        "Value": "WebServer-EC2"
      },
      {
        "Key": "Environment",
        "Value": "Demo"
      }
    ]
  }
}
ami-0d52744d6551d851e は 「amazon/ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-20230516」のイメージのようです。ちょっと古いイメージを使っていますね。
ユーザーデータの渡し方で若干苦戦（最初base64エンコーディングせず渡したりしていた）していましたが、２度ほどリトライして見事に成功させていました。
なおユーザーデータをデコードすると以下のような形です。Ubuntuを使っているのでこれは通らない気がしますね。
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo '<html><body><h1>Hello from EC2 Web Server!</h1></body></html>' > /var/www/html/index.html
 RDSの作成（失敗）続いて以下のようなRDSのリソース一式を作り始めました。
AWS::RDS::DBSubnetGroup
AWS::RDS::DBInstance
AWS::RDS::DBInstanceの作成に失敗していたので、get_resource_schema_information でRDSインスタンス作成のためのプロパティ一覧を読み込んでいたのが印象的でした。
RDSインスタンスのスキーマ情報を確認しました。RDSインスタンスの作成に必要なパラメータを修正して、再度試してみます。特に以下の点に注意します：

1. DBSubnetGroupNameには、DBサブネットグループの名前を指定する必要があります（IDではなく）。
2. VPCSecurityGroupsの形式を修正します。
3. 必須パラメータを確認します。

また、RDSインスタンスを作成する前に、DBサブネットグループの詳細情報を取得して、正確な名前を確認します。
いけるかなと思ったのですが、数回リトライしてもうまく作れませんでした。RDSはIaC等で作るときでもパラメータには気を使うのでやむなしという感じでしょうか。
RDSインスタンスの作成でまだバリデーションエラーが発生しています。エラーの詳細が表示されていないため、原因を特定するのが難しいです。と言っていたのでツール（及びツールの中で実行するAPI等）で適切なエラーメッセージを出すのが重要な気がしますね。
 ALBの作成一旦、RDSを作るのを諦めてALBを作り始めました。ALBの作成にも少し時間がかかるのでNAT Gatewayの作成時と同様に待つかどうかを聞かれました。
続いてターゲットグループを以下のパラメータで作成しています。
{
  "resource_type": "AWS::ElasticLoadBalancingV2::TargetGroup",
  "properties": {
    "Name": "SystemDiagramTG",
    "Port": 80,
    "Protocol": "HTTP",
    "VpcId": "vpc-0ceb221477ca1c612",
    "TargetType": "instance",
    "HealthCheckPath": "/",
    "HealthCheckProtocol": "HTTP",
    "HealthCheckIntervalSeconds": 30,
    "HealthCheckTimeoutSeconds": 5,
    "HealthyThresholdCount": 2,
    "UnhealthyThresholdCount": 2,
    "Matcher": {
      "HttpCode": "200"
    },
    "Tags": [
      {
        "Key": "Name",
        "Value": "SystemDiagram-TG"
      },
      {
        "Key": "Environment",
        "Value": "Demo"
      }
    ]
  }
}
ターゲットグループ作成後に、update_resource ツールを使ってちゃんと作成したEC2インスタンスをターゲットグループに登録していました。
続いてリスナーを作っています。ポートはHTTPで作るようです。
ここまでを作成し、一旦タスクとしては完了となりました。
 動作確認RDSはつくられていないものの、ALBとEC2は作成されたので、うまく設定されていればブラウザからアクセスできるはずです。さてアクセスできるでしょうか？
残念ながら、アクセスできませんでした。上でも書いたようにおそらくEC2上でhttpdサーバの設定がうまくできていないのでしょう。
EC2にセッションマネージャで接続するためにIAMロールの変更などを行い、接続して調べてみたところやはりhttpdがインストールされていませんでした。
root@ip-10-0-2-118:~# systemctl status httpd
Unit httpd.service could not be found.
 EC2の再作成ec2ですが、userdataがyumを使用した手順になっています。今回使用しているAMIはubuntu-jammy-22.04なので、aptコマンドでインストールする必要があると思います。作成済みのEC2を削除して、EC2を正しいユーザーデータで作り直してください。またターゲットグループの設定変更も実施してください。 と依頼して作り直してもらいました。
以下の手順で作業をするとのことです。
既存のEC2インスタンスを削除する
正しいUserData（aptコマンドを使用）で新しいEC2インスタンスを作成する
ターゲットグループの設定を変更する
今度は以下のユーザーデータでEC2を作り直していました。（base64デコードしたものを記載）
#!/bin/bash
apt-get update -y
apt-get install -y apache2
systemctl start apache2
systemctl enable apache2
echo '<html><body><h1>Hello from Ubuntu EC2 Web Server!</h1></body></html>' > /var/www/html/index.html
さて、今度は正常にアクセスできるでしょうか？
おお、ちゃんとアクセスできる！RDSは作れなかったもののいいところまでいけました。
 お片付け一通り検証できたので、今回作ったリソースを全て削除してとお願いしました。以下のようにちゃんと依存関係を考えてリソースを消していってくれるようです。
以下の順序でリソースを削除します：

1. リスナー
2. ターゲットグループ
3. ALB
4. EC2インスタンス
5. セキュリティグループ
6. NAT Gateway
7. ルートテーブルの関連付け
8. ルートテーブル
9. サブネット
10. インターネットゲートウェイのデタッチ
11. インターネットゲートウェイ
12. VPC

まず、リスナーから削除を開始します。
削除はほぼほぼ詰まることなくいきましたが、EIPの削除になぜか失敗していたのとルートテーブルの消し忘れが発生していますね。ルートテーブルを消していないので、VPCも削除できていないようです。とはいえ、ここまでちゃんと削除できれば上出来ですね。
# AWSリソース削除の結果報告

システム構成図に基づいて作成したAWSリソースの削除作業を実施しました。

## 削除完了したリソース

以下のリソースの削除が正常に完了しました：

1. __ロードバランシングリソース__

   - リスナー
   - ターゲットグループ
   - ALB (Application Load Balancer)

2. __コンピューティングリソース__

   - EC2インスタンス (Ubuntu 22.04 Webサーバー)

3. __セキュリティリソース__

   - EC2用セキュリティグループ (sg-0cd34d83b37408696)
   - RDS用セキュリティグループ (sg-0d390eb60a66f64b0)
   - ALB用セキュリティグループ (sg-0feba893c90301871)

4. __ネットワークリソース__

   - NAT Gateway (nat-0e6136d8b4101ed6f)

   - インターネットゲートウェイ (igw-0e58f4696dc707dd0)

   - VPC Gateway Attachment

   - サブネット (6つすべて)

     - AZ1パブリックサブネット (subnet-067579e69fb4d06a2)
     - AZ2パブリックサブネット (subnet-056a98b43694b299d)
     - AZ1プライベートサブネット(EC2用) (subnet-04cc191bc1dbfbfab)
     - AZ1プライベートサブネット(RDS用) (subnet-0901a9f517edcd252)
     - AZ2プライベートサブネット(1) (subnet-06cae0cf8deec3820)
     - AZ2プライベートサブネット(2) (subnet-08eba065fc5575398)

## 削除進行中のリソース

以下のリソースは現在削除処理が進行中です：

- VPC (vpc-0ceb221477ca1c612)

VPCの削除には時間がかかる場合があります。これは、VPC内の残りのリソース（ルートテーブルなど）の削除処理が行われているためです。

## 注意点

- Elastic IPアドレスの削除はバリデーションエラーにより実行できませんでした。必要に応じて手動で削除してください。
- RDSインスタンスは作成時に検証エラーが発生したため、削除対象には含まれていません。

以上で、ほぼすべてのAWSリソースの削除が完了しました。
 まとめというわけで、システム構成図だけを元にCloudFormation MCP ServerにAWSリソースを作ってもらいました。
いかがでしたでしょうか？思いつきでやってみたものの、思いのほかうまくいきましたね。なんというか、ここまでできるようになったかという気持ちです。
今回は失敗しましたが、パラメーターシートなどを適切に読み込ませてあげればRDSの作成もできると思います。
以上、とーちでした。
システム構成図だけを元にCloudFormation MCP ServerにAWSリソースを作らせてみた

今回試してみる内容

作成するリソースの確認

VPCの作成

セキュリティグループの作成

EC2インスタンスの作成

RDSの作成（失敗）

ALBの作成

動作確認

EC2の再作成

お片付け

まとめ

関連記事

主なカテゴリ

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

お問い合わせ

運営会社
