本記事は「2025 Japan AWS Jr. Chanpions 夏のQiitaリレー 」の45日目の記事です。
過去の投稿はこちらからご覧ください!
はじめに
Terraformのコードはプロジェクトが成長するにつれて肥大化し、モジュールの複雑化や設定の重複といった問題が発生しがちです。
そこで今回は、AWS Labsが提供している AWS Terraform MCP Server を、普段使っているエディタである Cursor と組み合わせて、実際のTerraformコードを丸ごと読ませてリファクタリングプランを生成してみました。
AWS Terraform MCP Serverとは
MCP(Model Context Protocol) は、LLMが外部ツールやサービス、データと連携するための仕組みです。
AWS Labsが公開している AWS Terraform MCP Server を使うと、
- TerraformコードがAWSのベストプラクティスに沿っているかをチェック
- 構造化されたプロセスに従って安全なコードを作成
- Checkov統合によりセキュリティとコンプライアンスのスキャン
- AWS および AWSCC プロバイダードキュメントの検索
- Terraformコマンドの直接実行
などが可能です。
検証環境
- コードエディタ:Cursor(version 1.3.9)
- 使用モデル:Claude-4-sonnet
- MCPツール:awslabs.terraform-mcp-server
- Terraformコード:
- 全コード中でaws_lambda.tfが最大で約1600行
- その他は中規模〜小規模のファイル多数
- 実案件コードをベースに、機密情報は削除して検証
実案件で使用しているコードなので現状でも、リソース毎にファイルは分けられていたり、変数の扱いや命名規則なども定めており、ある程度はちゃんとしているはずです。
そこで、試しにMCPを使って、現状のコードがどれくらい"ちゃんとしているか"をチェックしてもらいました。
改善の余地はあるものの、なかなかの評価ですね。
全体的に致命的な問題はなさそうなので、やはり肥大化したaws_lambda.tfの圧縮が叶うと嬉しい感じです。
MCPをCursorに追加する手順
- 「ファイル」タブ → 「ユーザー設定」→ 「 Cursor Settings 」 を開く
- 「 Tools & Integrations 」を開く
- MCP Tools の「 New MCP Server 」をクリック
- mcp.json の空ファイルが開くので、次のようにファイルを編集し保存
{
"mcpServers": {
"awslabs.terraform-mcp-server": {
"command": "uvx",
"args": ["--from", "awslabs.terraform-mcp-server@latest", "awslabs.terraform-mcp-server.exe"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
},
"disabled": false,
"autoApprove": []
}
}
}
公式ドキュメントでは "args" は ["awslabs.terraform-mcp-server@latest"] と記載ありますが、私の環境では上手くいかず、 ["--from", "awslabs.terraform-mcp-server@latest", "awslabs.terraform-mcp-server.exe"] としたことによって、CursorにMCPの追加が成功しました。
5. Cursor Settingsの画面に awslabs.terraform-mcp-server が表示されるため、
トグルをONにしてCursorを 再起動
※このような画面の状態(赤色の点+0tools enabledと表示)ではMCPはまだ使えない

※緑色の点になり、〇(0以上) tools enabled と表示されたら利用可能となる

展開すると、このMCPサーバーで実際に利用可能なツールが表示される

このような画面にならない場合は、ここまでの設定にミスがあるか、
再起動による設定変更の反映が上手くいっていない可能性が高いです。
(私はここがなかなか上手くいきませんでした…)
実際にMCPを呼び出す
MCPに追加出来たら、あとはCursorのチャットからMCPを実行できます。
今回はこのような指示を出しました。
/devのTerraformコードを確認し、リファクタリングのプランを提供してください。
その際、必ずMCPを利用してください。
明示的にMCP利用を指示することで、確実に呼び出しが行われます。
指示しないと、Terraformに関する質問をしてもMCPを使わない場合があったので、明示的に指示するのが良さそうです。

ちゃんとMCPを呼び出せていると、「Calling 〇〇(ツール名)」が自動で実行されます
MCPの出力結果
先ほどの指示により、以下のような出力が得られました。
主要な箇所をピックアップしています。
1.分析結果のサマリ
やはり、aws_lambda.tf は巨大ファイルのため修正すべきと判断されました。
これは期待通りですね。
Lambda関数が増えるたびにコピペで書き足しているのですが、その点を見抜かれて指摘されています。
その他に、約500行ある locals.tf が複雑すぎる点や、AWS Well-Architected Frameworkに完全に準拠できていない点が問題点として挙げられています。
2.実装ロードマップ
どのようなステップで、リファクタリングを進めていけばよいか、というロードマップを示してくれました。共通化可能なモジュールを整理したうえで、段階的に移行していくような流れになっています。
特に実案件で使用しているコードだと、迂闊に変えずらい面があるので、段階的移行などを組み込んだロードマップを示してくれると作業に取り掛かるうえでの足掛かりにしやすそうです。
LLM全般に言えることですが、指示にそのまま従うのはリスクが大きいため、このリファクタリングプランをベースとしてプロジェクト内で十分に検討すべきです。
3.期待される成果
実際の修正内容などといった詳細は省きますが、提示されたリファクタリングプランを完遂した場合の想定結果です。
全て指示通りにできた場合、
- 全ファイル10KB以下
- コードの重複を80%以上排除
- デプロイ時間の40%短縮
と、かなりの改善が見込めるようです。
また、ここはAWS Terraform MCP Serverの強みでもありますが、AWS Well-Architected Framework完全準拠の状態まで持って行けるとのことです。この辺は通常のLLM単体では実現が難しいでしょう。
使ってみた感想
良かった点
- 改善点がロードマップ化され、リファクタリング実行のハードルが下がる
- Cursor内でコード編集と改善提案がシームレスに行える
- 特にaws_lambda.tf のモジュール共通化によるコード削減は現実的に採用できそう
- Well-Architectedな構成を作るサポートとして優秀
(AWS Well-Architected Frameworkに人力で準拠させようとするのはなかなか難しい)
気になった点
- MCPを使うとLLMの回答が遅くなる(ツールの実行や、検索などの処理が追加で走るため)ので、不要なときはMCPを使わないようにした方が良さそう
- 今回使ったMCPに限らず、LLMの出力は鵜呑みにはできないため、注意が必要
- 実案件におけるインフラ構成は「要件の制約上、あえてWell-Architectedから外れる」ケースがかなり多い
- 上記の点を無視してWell-Architected完全準拠に飛びつくと他の問題が発生し得る
まとめ
AWS Terraform MCP Serverは、既存の大規模Terraformコードの棚卸しや改善計画の作成に、とても有効だと感じました。
AWSのTerraformコードという特定分野に特化したとき、LLMだけでは不十分だったところをAWS Terraform MCP Serverによって補う事ができていました。
また、本記事ではCursorとの組み合わせをご紹介しましたが、別のツール(特にAWS産のKiroなど)を使う事によって、違いはあるのかも気になる所なので、また試してみたいと思います。



