はじめに
こんにちは。インフラエンジニアの鈴木です。
この記事は、株式会社asken (あすけん) Advent Calendar 2025の12/12の記事です。
今回は「開発の手動構築を、AWS MCP ServerでサッとIaC管理へ移行する」方法を紹介します。 (ここでのIaC管理とは、インフラの構築や設定を手作業ではなくコードで自動化・管理することを指します。)
スピードが求められる場面では、まず開発環境を手動で素早く構築することがあります。
しかし、ステージングや本番へ進める段階で、既存リソースの棚卸しや依存関係の把握、IaC化に時間がかかり停滞しやすいのが課題です。
この問題を解決する手段として「AWS MCP Server」を活用できます。 既存リソースを自動で読み取り、TerraformやCDKなどのIaC管理へ簡単に移行する方法を紹介します。
概要
AWS MCP Server でできること
ClaudeCodeやCursorなどのAIツールで使えて、AWS操作を自然言語で実現できます。 AWS製のMCP サーバは複数あり、例えば以下のようなものがあります。
- aws-documentation-mcp-server: ドキュメント検索、APIリファレンス確認
- aws-api-mcp-server: AWS API/CLI の実行
詳細:https://awslabs.github.io/mcp/
MCPサーバを利用して、私はよく以下を実施しています。
- ベストプラクティスの調査
- CLIの実行
- 既存リソースの読み取り
- Design Doc向けの構成図や構成情報の作成
- 手動構築を IaC 管理へ移行 ←今回はここを紹介
実施の流れ
以下の手順で実施します。
AWS MCP Serverを設定 ↓ MCPでリソース読み取り・Terraform生成 ↓ import 実行
準備
本記事で環境の想定は以下とします。
- AWS環境で開発環境を作成
- ローカル端末(Mac)でTerraformを実行
- CursorやVSCodeなどのエディタを利用
- MCPを利用するAIは Claude Codeを利用
AWS MCP Server セットアップ
まずはAWS MCP Serverをセットアップします。 2025/12時点で方法は2つありますのでそれぞれ記載します。
方法1: Documentation + API の組み合わせ(推奨)
ナレッジ(ドキュメント検索)とAPI(リソース操作)を組み合わせる構成です。
.mcp.json(プロジェクトルート)または ~/.claude.json
{ "mcpServers": { "awslabs.aws-documentation-mcp-server": { "command": "uvx", "args": ["awslabs.aws-documentation-mcp-server@latest"], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_DOCUMENTATION_PARTITION": "aws" } }, "awslabs.aws-api-mcp-server": { "command": "uvx", "args": ["awslabs.aws-api-mcp-server@latest"], "env": { "AWS_REGION": "ap-northeast-1", "FASTMCP_LOG_LEVEL": "ERROR", "READ_OPERATIONS_ONLY": "true" } } } }
- 各MCPの役割
| サーバー | 役割 |
|---|---|
| aws-documentation-mcp-server | AWSドキュメント検索、ベストプラクティス取得、APIリファレンス参照 |
| aws-api-mcp-server | AWS API/CLIの実行 リソース情報取得 |
方法2: AWS MCP Server 統合版(Preview)
AWSがホストするフルマネージドの統合MCP(Knowledge + API + Agent SOPs)も出てます。 2025年12月発表のPreviewのため、まずは方法1を推奨します。
参考
- https://awslabs.github.io/mcp/#available-aws-mcp-servers
- https://dev.classmethod.jp/articles/aws-mcp-server-preview/
補足:権限について
AIによる誤操作を防ぐため、読み取り専用の権限を設定します。
- MCP側は ReadOnly 実行
- AWS IAM側も ReadOnly ポリシーのみ付与
Terraform構成を考える(型を先に用意)
手動構築したリソースをTerraformで管理するときのフォルダやファイル構成を先に用意します。
リソースの種類ごとに分け、import.tfに実際のリソースをimportするためのIDを記述します。
infra/
└── dev/
├── network.tf # ネットワーク関連:VPC, Subnet, Route, SG
├── storage.tf # ストレージ関連:S3, RDS, DynamoDB
├── app.tf # アプリ関連:ALB, ECS, Lambda, StepFunctions
├── monitoring.tf # 監視関連:CloudWatch, Alarm, Dashboard
└── import.tf # インポート設定:terraform import用のID
手順
実際に手動構築した内容をTerraformでimportして管理するまでの手順を記載します。
Step 1: 既存リソースの取得→Terraform生成
プロンプト例:
AWS MCP Serverを使って、XXXXの名前のついたリソース情報を取得してください。 その後、取得したリソース情報をTerraformの構成(network/app/storage/monitoring)のファイルに対応付けてtfファイルを生成してください。 ファイルと対象の対応は次の通りです。 network: VPC, Subnet, Route, Security Group app: ALB, ECS, Lambda, Step Functions storage: S3, RDS, DynamoDB monitoring: CloudWatch, Alarm, Dashboard あわせて、リソース情報からimport.tf(terraform importに必要なリソース情報)を生成してください。
Step 2: 生成物のチェックと微調整
名前や設定などを微調整します。具体的には以下などを実施します。
- 命名規則の統一(AWSリソース名とterraformリソース名の対応)
- インポートするリソースの各設定で過不足ないか
Step 3: Terraform実行(import)
Terraformを実行して、既存リソースを取り込みます。
cd infra/dev terraform init terraform plan terraform apply
これだけです。取り込んだリソース一覧とかも指示すれば出せます。
1つ1つ手動で確認して、実施していたころが嘘のようです。
CDKの場合
Terraformと同様に既存リソースを取り込めます。CDKの場合はcdk importを活用します。
プロンプト例:
AWS MCP Serverを使って、XXXXの名前のついたリソース情報を取得してください。 取得したALBリソースをCDK TypeScriptでimportするためのコマンドとコードを生成してください。
実施して嬉しいこと
手動で素早く作った開発環境から、ステージング以降のIaC管理へ移行する手間が大幅に減ります。
丸1日かかるようなのが、チェック含めて1-2時間程度でできます。
大体、インフラ構築はこの開発リソースをIaC化するところに一番手間がかかります。
(本番リリースまでにはIaCができてて、むしろそこは手間そんなにかからないんですよねぇ)
Before
開発環境(手動) ↓ ← 依存関係調査とimport作業で停滞、、、 ステージング環境(IaC) ↓ 本番環境(IaC)
After
開発環境(手動) ↓ MCP棚卸し(自動) ↓ import.tf / cdk import 生成(自動) ステージング環境(IaC) ↓ 本番環境(IaC)
まとめ
- 開発初期はスピード優先で手動構築でOK
- AWS MCP Server による棚卸し自動化でimport作業を短縮
- Terraform / CDK どちらにも対応可能
- ステージング以降はIaC化で細かく管理できる
いかがでしたでしょうか。
今回紹介した内容だけではなく、AWS MCP Server ではいろんなことができます。
ドキュメント調査に使うだけでも役立ちますので、AWSを利用していて使ったことがなかった方は、ぜひ試してみてください。
採用について
askenではエンジニアを絶賛募集中です。まずはカジュアルにお話しできればと思いますので、ぜひお気軽にご連絡ください!
https://hrmos.co/pages/asken/jobs