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

Terraform・Pulumi・CloudFormation/CDKのMCPサーバーは、いずれもHashiCorp・Pulumi Corporation・AWS Labsという開発元自身が公開する実装です。ただし守備範囲は大きく異なります。

RegistryのドキュメントをClaudeに検索させるだけの実装もあれば、実際にデプロイまで実行できる実装もあります。IaCコードを書かせる前に、どこまでの操作を任せるつもりかで選ぶツールが変わります。

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

比較の軸は3つです。対応クラウド(マルチクラウドかAWS限定か)、状態管理への関与(状態ファイルやスタックにどう触れるか)、既定で書き込みができるか(接続しただけでデプロイ系のツールが有効になるか)です。

書き込みを止める場所は3者で違う

「既定で書き込めるか」の差は、止める仕組みがどこにあるかの差でもあります。

TerraformにはENABLE_TF_OPERATIONSという環境変数もあり、READMEの表では「明示的な承認が必要なツールを有効にする」設定で既定はfalseです。どのツールが対象かは、この表には書かれていません。

Pulumiをつなぐなら、Claude Code側の権限ルールで実行系ツールを毎回の確認に落とす方法があります。MCPツールはmcp__<サーバー名>__<ツール名>の形で指定でき、askルールに入れた呼び出しは確認が出ます。

{
  "permissions": {
    "ask": [
      "mcp__pulumi__pulumi-cli-up",
      "mcp__pulumi__pulumi-cli-refresh"
    ]
  }
}

claude mcp addのサーバー名をpulumiにした場合の例です。別の名前で登録したなら、mcp__の直後を合わせます。権限ルールの全体像は本番環境でMCPを使う権限設計で扱っています。

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

Terraformはローカルまたはリモートバックエンドに状態ファイルを持ちます。MCPサーバーがどこまで関わるかは、HCP Terraformのワークスペース操作を扱うTerraform MCPサーバーのワークスペース管理にまとめています。

Pulumiには同名の別サーバーがある

Pulumiのドキュメントが案内しているのは、npmの@pulumi/mcp-serverではなくhttps://mcp.ai.pulumi.com/mcpのホスト型サーバーです。同じ「Pulumi MCPサーバー」でも、実行場所・認証・できることが別物です。

ドキュメントの手順をなぞると、ローカルのIaCをpreview・deployさせたいのに、照会とNeoへの委任が中心のサーバーにつながる、というつまずきが起こります。Terraformとaws-iac-mcp-serverは、READMEが案内する実装がそれぞれ1つです。

Terraformには、HTTPで動かす場合の守りもあります。READMEによると、streamable-httpモードの待ち受けは既定で127.0.0.1のポート8080です。HCP Terraformのアドレスは、サーバー側のTFE_ADDRESSでしか指定できません。クライアントがヘッダーやクエリで渡すと403で拒否されるので、トークンの送り先を差し替えられる経路が塞がれています。

対応クラウドの範囲

TerraformとPulumiはどちらもマルチクラウドで、AWS・Azure・Google Cloudなど各社のRegistryプロバイダーを横断して調べられます。aws-iac-mcp-serverはCloudFormationとCDKに特化していて、対象はAWSのみです。

マルチクラウド環境ならTerraformかPulumiのRegistryツール、AWS単体でテンプレートの品質を上げたいならaws-iac-mcp-server、という切り分けになります。CDKの側では、公式ドキュメントとCDK-NAGの検査ルール、コードサンプル、コンストラクトの検索ツールが付いてきます。

3つに共通する脅威モデル

HashiCorpのセキュリティモデルは、ローカルで動かす場合を前提に、ハルシネーション・プロンプトインジェクション・ツールポイズニング・Rug pull attack・Tool shadowingの5つを脅威として挙げています。Terraform向けの文書ですが、他の2つにも当てはまる論点が多いです。

• Rug pull attack: リモートに公開したMCPサーバーが、承認された後でツールや説明を書き換える攻撃です
• Tool shadowing: 複数のMCPサーバーをつないだとき、侵害された1つが信頼できるサーバーのツールを上書きする攻撃です
• 脅威モデルの対象外: モデルが出力した内容によるインフラのデプロイは対象外で、適用前にレビューすることが前提です

HashiCorpの推奨は、書き込みを伴う変更の前に必ず検証することです。書き込みツールのないaws-iac-mcp-serverでも、生成したテンプレートを別の手段でデプロイするなら同じ確認が要ります。

aws-iac-mcp-serverのREADMEには、AWS APIの呼び出し結果がAIモデルの提供元に共有されるというプライバシーの注意書きもあります。トラブルシュートでスタックの状態を読ませるなら、この点も判断材料になります。

導入の前提条件

3つとも、手元に必要な環境が違います。

• Terraform MCPサーバー: READMEの前提条件はDockerです。Dockerが使えない環境向けには、go installでバイナリを入れる手順が別にあります
• Pulumi MCPサーバー(npm版): READMEの要件はクライアントマシンへのPulumi CLIのインストールです。Dockerは任意で、mcp/pulumiイメージを使えます。ローカルプロジェクトにupなどを実行させるなら、プロジェクトのディレクトリをマウントします
• aws-iac-mcp-server: uvと、uv python install 3.10で入れるPython 3.10が前提です。Docker設定はdocker buildで作ったローカルイメージを使う形で書かれています

AWS認証情報が要るのはトラブルシュート用のツールだけです。READMEの権限表では、テンプレート検証とコンプライアンスチェックは「ローカル検証のみ」でAWS権限が不要とされています。

実際に試す

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は、ドキュメントにあるコマンドで追加し、Claude Codeの/mcpから認証します。v2.1.289のclaude mcp add --helpでは、-sが設定の保存先(local・user・project、既定はlocal)、-tが通信方式(stdio・sse・http、既定はstdio)と示されます。

claude mcp add --transport http pulumi https://mcp.ai.pulumi.com/mcp

どのツールを選ぶか

よくあるつまずき

npm版Pulumiのpulumi-cli-upが使える前提を忘れる。TerraformやCloudFormationと同じ感覚で接続すると、意図せずデプロイまで任せる構成になります。上のaskルールで確認を挟みます。

Terraformのワークスペース操作系ツールを混同する。既定のregistryツールセットだけなら書き込みは起きませんが、terraformツールセットを足してTFE_TOKENを渡すと状況が変わります。

aws-iac-mcp-serverにデプロイまで任せられると思う。このサーバーは検証と診断に特化しています。実際のデプロイはこのサーバーの機能に含まれません。READMEのツール一覧は、検証・診断・ドキュメント検索だけです。

まとめ

選ぶ軸は、インフラへの書き込みをどこまで任せるかです。任せないなら書き込みツールを持たないaws-iac-mcp-serverか既定がRegistry検索だけのTerraformで、PulumiにCLIを実行させるなら先にクライアント側の承認ルールを置きます。

導入手順はTerraform MCPサーバーの使い方、Pulumi MCPサーバーの使い方、CloudFormation/CDKをMCPで自動検証するにあります。MCPサーバーの権限ルール全般はMCPセキュリティガイドを参照してください。