Terraform/Pulumi/CloudFormationのMCP比較 — IaCサーバー選びの基準

Terraform・Pulumi・CloudFormation/CDKのMCPサーバーは、いずれもHashiCorp・Pulumi Corporation・AWS Labsという開発元自身が公開する実装です。3つとも非公式実装という空白はありません。ただし守備範囲は大きく異なります。RegistryのドキュメントをClaudeに検索させるだけの実装もあれば、実際にデプロイまで実行する実装もあります。IaCコードを書かせる前に、どこまでの操作を任せるつもりかで選ぶツールが変わります。

3つのMCPサーバーは何が違うのか

比較の軸は3つです。対応クラウド(マルチクラウドかAWS限定か)、状態管理への関与(Terraform/Pulumiの状態ファイルやCloudFormationのスタックにどう触れるか)、既定で書き込みができるか(接続しただけでデプロイ系のツールが有効になるか)です。この3つを押さえると、検証用途とデプロイ用途のどちらに向くツールかが見えてきます。

3つの実装を並べる

デプロイまで踏み込むのはPulumiだけ

aws-iac-mcp-serverには、そもそもインフラを変更するツールがありません。validate_cloudformation_templateとcheck_cloudformation_template_complianceはテンプレートをローカルで検証するだけで、troubleshoot_cloudformation_deploymentもCloudTrailとDescribe系APIを読むだけです。AWS認証情報を渡しても、書き込みが発生する経路自体が存在しません。

Terraform MCPサーバーは既定でregistryツールセットのみが有効です。Provider・Module・Sentinelポリシーのドキュメントを検索する読み取り系ツールに限られ、HCP Terraformのワークスペースを操作するterraformツールセットは明示的な有効化とTFE_TOKENが要ります。接続しただけでは書き込みは起きません。

@pulumi/mcp-serverはこの2つと対照的です。pulumi-cli-preview・pulumi-cli-up・pulumi-cli-refreshという実際にデプロイを実行するツールが、接続した時点で既定で登録されています。Registry検索だけならPULUMI_ACCESS_TOKENは不要ですが、ローカルのPulumiプロジェクトに対してpulumi-cli-upを呼び出すこと自体を止める仕組みはサーバー側にありません。3つの中で唯一、書き込み操作を無効化するフラグを持たない実装です。

状態管理への関わり方が3者3様

3つのツールは、いわゆる「状態」の持ち方が根本的に違います。Terraformはローカルまたはリモートバックエンドに状態ファイルを持ちますが、Terraform MCPサーバーのRegistryツールはこの状態ファイルに一切触れません。状態を操作するのはHCP Terraformのワークスペースを操作するで扱うterraformツールセットです。

Pulumiも独自の状態バックエンド(ローカルファイル・S3・Pulumi Cloud等)を持ちますが、@pulumi/mcp-serverはpulumi-cli-upで状態を直接更新し、pulumi-cli-refreshで実際のクラウドリソースとの差分(ドリフト)を検出・同期します。MCPサーバー自身が状態の読み書きに直接関与する設計です。

CloudFormationには、TerraformやPulumiのようなクライアント側の状態ファイルという概念がありません。スタックの状態はAWS側でCloudFormationサービスそのものが管理します。aws-iac-mcp-serverはこの状態に書き込む手段を持たず、DescribeStacks等の読み取り専用APIでスタックの現在の状態を確認するだけです。

対応クラウドの範囲

TerraformとPulumiはどちらもマルチクラウド対応で、AWS・Azure・Google Cloud等、各社のRegistryプロバイダーを横断検索できます。一方aws-iac-mcp-serverはAWSネイティブのCloudFormationとCDKに特化し、対応範囲はAWSのみです。マルチクラウド環境でIaCの調べ物をするならTerraformかPulumiのRegistryツール、AWS単体でCloudFormation/CDKのテンプレート品質を上げたいならaws-iac-mcp-server、という切り分けになります。

Pulumiだけ同名の別サーバーが存在する

Pulumiには紛らわしい落とし穴があります。Pulumiのドキュメントが前面に案内しているのは、本記事で比較した@pulumi/mcp-server(npmパッケージ・ローカルstdio実行)ではなく、https://mcp.ai.pulumi.com/mcpというホスト型のMCPサーバーです。同じ「Pulumi MCPサーバー」という名前でも、実行場所・認証方式・できることが別物です。ホスト型はOAuth認証でPulumi Cloud上にあり、CLIの実行(preview・up・refresh)はできず、Pulumi Cloud API経由の照会と自律実行エージェントNeoへのタスク委任に限られます。案内されている手順をそのままなぞると、ローカルのIaCをpreview・deployさせたいのに照会専用のサーバーにつながってしまう、というつまずきが起こります。TerraformとCloudFormationにはこの二重構造はなく、READMEとドキュメントが指すサーバーは1つだけです。

3つのサーバーが共有する脅威モデル

HashiCorpが公開するセキュリティモデルは、ハルシネーション・プロンプトインジェクション・ツールポイズニング・Rug pull attack(承認後にツールの動作が悪意ある内容へ差し替わる攻撃)・Tool shadowing(別のツールになりすまして意図しない呼び出しを誘発する攻撃)の5つを主な脅威として挙げています。これはTerraform固有の話ではなく、PulumiやCloudFormation向けのMCPサーバーを使うときにも共通して当てはまる前提です。インフラへの変更を適用する前に、生成された内容を人間が確認するという原則は、3つのどのツールを使う場合でも変わりません。書き込み系ツールを持たないaws-iac-mcp-serverであっても、生成したテンプレートを別の手段でデプロイするなら同じ確認が要ります。

導入の前提条件も揃っていない

3つとも、動かすために必要な手元の環境が異なります。Terraform MCPサーバーはDockerイメージにGoバイナリが同梱されているため、Terraform CLI自体のインストールは不要です。Docker以外にもgo installでホストに直接導入する経路があります。@pulumi/mcp-serverはローカルのPulumi CLIが前提で、npx実行の場合はクライアントマシンにPulumi CLIとログイン済みのアカウントが必要です。Docker版イメージ(mcp/pulumi)を使う場合のみこの前提が不要になります。aws-iac-mcp-serverはuvとuv python install 3.10で入るPython 3.10が前提で、Dockerイメージは公開レジストリに配布されておらず自分でビルドする必要があります。前提環境が最も軽いのはDocker配布のTerraform MCPサーバーで、Pulumiは既存プロジェクトがあるチームなら追加作業なしに使えます。aws-iac-mcp-serverはPython環境の用意が一手間増える一方、AWS認証情報が無くてもテンプレート検証だけならすぐ試せる点は他の2つと変わりません。

実際に試す

Terraform MCPサーバーはDocker経由での起動が推奨されています。既定のregistryツールセットのみが有効なので、追加設定なしで読み取り専用運用になります。

claude mcp add terraform -s user -t stdio -- docker run -i --rm hashicorp/terraform-mcp-server

aws-iac-mcp-serverは検証系ツールだけならAWS認証情報も不要です。

claude mcp add --transport stdio aws-iac -- uvx awslabs.aws-iac-mcp-server@latest

どのツールを選ぶか

よくあるつまずき

Pulumiのpulumi-cli-upが既定で使える前提を忘れる。TerraformやCloudFormationと同じ感覚で接続すると、意図せずデプロイまで任せてしまう構成になります。プレビューの内容を確認してからupに進む運用を徹底します。

Terraformのワークスペース操作系ツールを混同する。registryツールセットだけでは書き込みは起きませんが、terraformツールセットを有効化してTFE_TOKENを渡すと状況が変わります。読み取り専用のRegistry検索と実行系ツールは別ツールセットです。

aws-iac-mcp-serverにデプロイまで任せられると誤解する。このサーバーは検証と診断に特化しており、実際のcloudformation deployは別のツール(aws-api-mcp-server等)の役割です。

まとめ

Terraform・Pulumi・CloudFormation/CDKのMCPサーバーはどれも開発元自身の実装ですが、既定で書き込みができるかは3者で異なります。aws-iac-mcp-serverは書き込みツール自体を持たず、Terraform MCPサーバーは既定でRegistry検索のみ、Pulumi MCPサーバーだけが接続した時点でデプロイ系ツールを使える状態です。マルチクラウドかAWS限定かも選定軸になります。各ツールの導入手順はTerraform MCPサーバーの使い方、Pulumi MCPサーバーの使い方、CloudFormation/CDKをMCPで自動検証するにまとめています。書き込み権限をどう設計するかの一般論は本番環境でMCPを使う権限設計、MCPサーバーの権限ルール全般はMCPセキュリティガイドを参照してください。