お問い合わせ

資料ダウンロード

IaCAI_人工知能

Terraform MCPサーバーでAWSプロバイダーを試してみた

HashiCorp社は今年5月、Terraform MCPサーバーのベータ版をリリースしました。7月にはアップデートが行われ、LLMがHashiCorp公式のTerraformコーディングスタイルやモジュール開発ガイドも参照するようになり、より精度の高いコードを生成できるようになりました。ここでは、AWSプロバイダーを使った簡単な例を通じて、Terraform MCPサーバーの概要をご紹介します。

Terraform MCPサーバーとは

Terraform MCPサーバーは、Terraform Registryに保存された情報やTerraformコーディングスタイルの情報をLLMツールに提供することで、より信頼性の高いTerraformコードの生成を可能にするツールです。Terraform MCPサーバーは下記の表の通り複数のツールで構成されており、Terraform Registryにあるプロバイダー、モジュール、ポリシーなどの情報を取得してLLMに渡すことができます。

ツールセット モジュール 説明
providers resolveProviderDocID プロバイダードキュメントIDの一覧とそれぞれのタイトルおよび
カテゴリを取得します。
providers getProviderDocs resolveProviderDocID ツールで取得したドキュメントIDを使用
して、プロバイダーのリソースやデータソース、関数などに
関するドキュメント内容を取得します。
modules searchModules Terraform Registry 内のモジュールを検索し、モジュールIDや
モジュール名、モジュールなどの説明を取得します。
modules moduleDetails searchModules ツールで取得したモジュールIDを使用して、
モジュールの入力値や出力値、設定方法などに関する
ドキュメント内容を取得します。
policies searchPolicies Terraform Registryから該当するSentinel ポリシーを検索し、
ポリシーID やポリシー名、タイトルなどの一覧を取得します。
policies policyDetails searchPolicies ツールで取得したポリシーID を使用して、
ポリシーのREADMEや実装方法などに関するドキュメント
内容を取得します。

Terraform MCPサーバーのセットアップ

Terraform MCPサーバーはDockerコンテナ上で動作するため、作業端末にDockerをインストールしておく必要があります。また、Terraform MCPサーバーはVS CodeのCopilotなどのコードエディターから呼び出すため、それらのツールのインストールも必要です。この記事の執筆時点（2025年8月）では、Terraform MCPサーバーは以下のツールをサポートしています。

  • VS Code & Copilot
  • Cursor
  • Anthropic Claude Desktop

Terraform MCPサーバーのインストール方法については、以下のGitHubリポジトリのREADMEをご参照ください。

https://github.com/hashicorp/terraform-mcp-server

本記事では、Cursorを使用しています。CursorからTerraform MCPサーバーを呼び出すには、~/.cursorフォルダに以下のような「mcp.json」ファイルを作成します。

{
  "mcpServers": {
    "terraform-mcp-server": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "hashicorp/terraform-mcp-server:0.2.1"
      ]
    }
  }
}

Terraform MCPサーバーの利用

ここでは、AWSの東日本リージョンと西日本リージョンそれぞれにVPCを作成し、VPCピアリング接続を行うTerraformコードを作成してみます。まずは、Terraform MCPサーバーを使わずに、コード作成を依頼してみます。以下のように、Cursor設定でTerraform MCPサーバーを無効にします。なお、同じプロンプトを実行しても、応答内容が筆者の例と異なる場合がありますのでご了承ください。

次のように依頼しました。

Terraformの最新のAWSプロバイダーを使って、東日本リージョンと西日本リージョンでVPCを作成して、ピアリングするコードを作ってください。
コードは、main.tfというファイルで保存して下さい。

そうすると、以下のコードが生成されました。

Terraform MCPサーバーを使わないコード（コードは▶をクリック） 
# Configure the AWS Provider
terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Provider for Tokyo region (ap-northeast-1)
provider "aws" {
  region = "ap-northeast-1"
  alias  = "tokyo"
}

# Provider for Osaka region (ap-northeast-3)
provider "aws" {
  region = "ap-northeast-3"
  alias  = "osaka"
}

# VPC in Tokyo region
resource "aws_vpc" "tokyo_vpc" {
  provider = aws.tokyo

  cidr_block           = "10.1.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "Tokyo-VPC"
    Environment = "Production"
  }
}

# VPC in Osaka region
resource "aws_vpc" "osaka_vpc" {
  provider = aws.osaka

  cidr_block           = "10.2.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "Osaka-VPC"
    Environment = "Production"
  }
}

# Internet Gateway for Tokyo VPC
resource "aws_internet_gateway" "tokyo_igw" {
  provider = aws.tokyo

  vpc_id = aws_vpc.tokyo_vpc.id

  tags = {
    Name = "Tokyo-IGW"
  }
}

# Internet Gateway for Osaka VPC
resource "aws_internet_gateway" "osaka_igw" {
  provider = aws.osaka

  vpc_id = aws_vpc.osaka_vpc.id

  tags = {
    Name = "Osaka-IGW"
  }
}

# Public Subnet in Tokyo (AZ a)
resource "aws_subnet" "tokyo_public_subnet_a" {
  provider = aws.tokyo

  vpc_id            = aws_vpc.tokyo_vpc.id
  cidr_block        = "10.1.1.0/24"
  availability_zone = "ap-northeast-1a"

  map_public_ip_on_launch = true

  tags = {
    Name = "Tokyo-Public-Subnet-A"
  }
}

# Public Subnet in Tokyo (AZ c)
resource "aws_subnet" "tokyo_public_subnet_c" {
  provider = aws.tokyo

  vpc_id            = aws_vpc.tokyo_vpc.id
  cidr_block        = "10.1.2.0/24"
  availability_zone = "ap-northeast-1c"

  map_public_ip_on_launch = true

  tags = {
    Name = "Tokyo-Public-Subnet-C"
  }
}

# Public Subnet in Osaka (AZ a)
resource "aws_subnet" "osaka_public_subnet_a" {
  provider = aws.osaka

  vpc_id            = aws_vpc.osaka_vpc.id
  cidr_block        = "10.2.1.0/24"
  availability_zone = "ap-northeast-3a"

  map_public_ip_on_launch = true

  tags = {
    Name = "Osaka-Public-Subnet-A"
  }
}

# Public Subnet in Osaka (AZ b)
resource "aws_subnet" "osaka_public_subnet_b" {
  provider = aws.osaka

  vpc_id            = aws_vpc.osaka_vpc.id
  cidr_block        = "10.2.2.0/24"
  availability_zone = "ap-northeast-3b"

  map_public_ip_on_launch = true

  tags = {
    Name = "Osaka-Public-Subnet-B"
  }
}

# Route Table for Tokyo VPC
resource "aws_route_table" "tokyo_route_table" {
  provider = aws.tokyo

  vpc_id = aws_vpc.tokyo_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.tokyo_igw.id
  }

  route {
    cidr_block                = "10.2.0.0/16"
    vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_osaka_peering.id
  }

  tags = {
    Name = "Tokyo-Route-Table"
  }
}

# Route Table for Osaka VPC
resource "aws_route_table" "osaka_route_table" {
  provider = aws.osaka

  vpc_id = aws_vpc.osaka_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.osaka_igw.id
  }

  route {
    cidr_block                = "10.1.0.0/16"
    vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_osaka_peering.id
  }

  tags = {
    Name = "Osaka-Route-Table"
  }
}

# Route Table Association for Tokyo Public Subnet A
resource "aws_route_table_association" "tokyo_public_subnet_a_association" {
  provider = aws.tokyo

  subnet_id      = aws_subnet.tokyo_public_subnet_a.id
  route_table_id = aws_route_table.tokyo_route_table.id
}

# Route Table Association for Tokyo Public Subnet C
resource "aws_route_table_association" "tokyo_public_subnet_c_association" {
  provider = aws.tokyo

  subnet_id      = aws_subnet.tokyo_public_subnet_c.id
  route_table_id = aws_route_table.tokyo_route_table.id
}

# Route Table Association for Osaka Public Subnet A
resource "aws_route_table_association" "osaka_public_subnet_a_association" {
  provider = aws.osaka

  subnet_id      = aws_subnet.osaka_public_subnet_a.id
  route_table_id = aws_route_table.osaka_route_table.id
}

# Route Table Association for Osaka Public Subnet B
resource "aws_route_table_association" "osaka_public_subnet_b_association" {
  provider = aws.osaka

  subnet_id      = aws_subnet.osaka_public_subnet_b.id
  route_table_id = aws_route_table.osaka_route_table.id
}

# VPC Peering Connection between Tokyo and Osaka VPCs
resource "aws_vpc_peering_connection" "tokyo_osaka_peering" {
  provider = aws.tokyo

  vpc_id      = aws_vpc.tokyo_vpc.id
  peer_vpc_id = aws_vpc.osaka_vpc.id
  peer_region = "ap-northeast-3"

  auto_accept = false

  tags = {
    Name = "Tokyo-Osaka-VPC-Peering"
  }
}

# Accept the VPC Peering Connection in Osaka region
resource "aws_vpc_peering_connection_accepter" "osaka_peering_accepter" {
  provider = aws.osaka

  vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_osaka_peering.id
  auto_accept               = true

  tags = {
    Name = "Osaka-Peering-Accepter"
  }
}

# Security Group for Tokyo VPC
resource "aws_security_group" "tokyo_sg" {
  provider = aws.tokyo

  name        = "Tokyo-Security-Group"
  description = "Security group for Tokyo VPC"
  vpc_id      = aws_vpc.tokyo_vpc.id

  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTP"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTPS"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "VPC Peering Traffic"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["10.2.0.0/16"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "Tokyo-Security-Group"
  }
}

# Security Group for Osaka VPC
resource "aws_security_group" "osaka_sg" {
  provider = aws.osaka

  name        = "Osaka-Security-Group"
  description = "Security group for Osaka VPC"
  vpc_id      = aws_vpc.osaka_vpc.id

  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTP"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTPS"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "VPC Peering Traffic"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["10.1.0.0/16"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "Osaka-Security-Group"
  }
}

# Output values
output "tokyo_vpc_id" {
  description = "ID of the Tokyo VPC"
  value       = aws_vpc.tokyo_vpc.id
}

output "osaka_vpc_id" {
  description = "ID of the Osaka VPC"
  value       = aws_vpc.osaka_vpc.id
}

output "tokyo_vpc_cidr" {
  description = "CIDR block of the Tokyo VPC"
  value       = aws_vpc.tokyo_vpc.cidr_block
}

output "osaka_vpc_cidr" {
  description = "CIDR block of the Osaka VPC"
  value       = aws_vpc.osaka_vpc.cidr_block
}

output "vpc_peering_connection_id" {
  description = "ID of the VPC peering connection"
  value       = aws_vpc_peering_connection.tokyo_osaka_peering.id
}

output "tokyo_public_subnets" {
  description = "IDs of the Tokyo public subnets"
  value = [
    aws_subnet.tokyo_public_subnet_a.id,
    aws_subnet.tokyo_public_subnet_c.id
  ]
}

output "osaka_public_subnets" {
  description = "IDs of the Osaka public subnets"
  value = [
    aws_subnet.osaka_public_subnet_a.id,
    aws_subnet.osaka_public_subnet_b.id
  ]
}

提案されたコードの説明を見てみます。

# Terraformの最新のAWSプロバイダー（バージョン5.x）を使用して、東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-3）にVPCを作成し、ピアリングするコードをmain.tfファイルに作成しました。
# このコードには以下の機能が含まれています：
## 主要な構成要素

1. マルチリージョンプロバイダー設定
   - 東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-3）の両方にプロバイダーを設定

2. VPC構成
   - 東京VPC: CIDR 10.1.0.0/16
   - 大阪VPC: CIDR 10.2.0.0/16
   - 両方のVPCでDNSサポートを有効化

3. サブネット構成
   - 東京: 2つのパブリックサブネット（ap-northeast-1a, ap-northeast-1c）
   - 大阪: 2つのパブリックサブネット（ap-northeast-3a, ap-northeast-3b）

4. VPCピアリング
   - 東京と大阪のVPC間のピアリング接続
   - 自動承認設定
   - ルートテーブルにピアリング経路を追加

5. ネットワーク構成
   - インターネットゲートウェイ
   - ルートテーブル（インターネットアクセス + ピアリング経路）
   - セキュリティグループ（SSH、HTTP、HTTPS、ピアリングトラフィック）

6. セキュリティ
   - 各VPC用のセキュリティグループ
   - ピアリング間のトラフィックを許可するルール

VPCには、異なるアベイラビリティーゾーンにパブリックサブネットがあり、また一般的によく使われるTCPポートへのアクセスを制限するセキュリティグループも設定されています。ただし、すべての送信元からのアクセスが許可されている点がセキュリティ面で気になるところです。

では今度は、Terraform MCPサーバーを有効にした状態で、コード作成を依頼してみます。Cursorの設定画面で、Terraform MCPサーバーを有効にします。以下のように、Cursor設定でTerraform MCPサーバーを有効にします。

先ほどと同じ依頼を行うと、今度はTerraform MCPサーバーのツールセットに接続しに行きました。

最初にresolveProviderDocIDを呼び出し、最新のAWSプロバイダードキュメントを検索しようとしています。「Run tool」ボタンをクリックして、次に進みます。

今度はgetProviderDocsを呼び出して、AWSプロバイダードキュメントからVPC作成に関するコードの記述方法を取得しようとしています。「Run tool」ボタンをクリックして、次に進みます。

再び、getProviderDocsを呼び出して、今度はAWSプロバイダードキュメントからVPCピアリング作成に関するコードの記述方法を取得しようとしています。「Run tool」ボタンをクリックして、次に進みます。

更に、getProviderDocsを呼び出して、今度はAWSプロバーダードキュメントからVPCピアリングのアクセプター作成に関するコードの記述方法を取得しようとしています。「Run tool」ボタンをクリックして、次に進みます。

そうすると、以下のコードが生成されました。

Terraform MCPサーバーを使ったコード-1（コードは▶をクリック） 
# AWS Provider Configuration
terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.7.0"
    }
  }
}

# Provider for Tokyo region (ap-northeast-1)
provider "aws" {
  region = "ap-northeast-1"
  alias  = "tokyo"
}

# Provider for Osaka region (ap-northeast-3)
provider "aws" {
  region = "ap-northeast-3"
  alias  = "osaka"
}

# VPC in Tokyo region
resource "aws_vpc" "tokyo_vpc" {
  provider = aws.tokyo

  cidr_block           = "10.1.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "Tokyo-VPC"
    Environment = "Production"
    Region = "ap-northeast-1"
  }
}

# VPC in Osaka region
resource "aws_vpc" "osaka_vpc" {
  provider = aws.osaka

  cidr_block           = "10.2.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "Osaka-VPC"
    Environment = "Production"
    Region = "ap-northeast-3"
  }
}

# VPC Peering Connection (requester side - Tokyo)
resource "aws_vpc_peering_connection" "tokyo_to_osaka" {
  provider = aws.tokyo

  vpc_id      = aws_vpc.tokyo_vpc.id
  peer_vpc_id = aws_vpc.osaka_vpc.id
  peer_region = "ap-northeast-3"
  auto_accept = false

  tags = {
    Name = "Tokyo-to-Osaka-Peering"
    Side = "Requester"
  }
}

# VPC Peering Connection Accepter (accepter side - Osaka)
resource "aws_vpc_peering_connection_accepter" "osaka_accepter" {
  provider = aws.osaka

  vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_to_osaka.id
  auto_accept               = true

  tags = {
    Name = "Tokyo-to-Osaka-Peering"
    Side = "Accepter"
  }
}

# Route Table for Tokyo VPC
resource "aws_route_table" "tokyo_route_table" {
  provider = aws.tokyo

  vpc_id = aws_vpc.tokyo_vpc.id

  tags = {
    Name = "Tokyo-Route-Table"
  }
}

# Route Table for Osaka VPC
resource "aws_route_table" "osaka_route_table" {
  provider = aws.osaka

  vpc_id = aws_vpc.osaka_vpc.id

  tags = {
    Name = "Osaka-Route-Table"
  }
}

# Route from Tokyo to Osaka VPC
resource "aws_route" "tokyo_to_osaka_route" {
  provider = aws.tokyo

  route_table_id            = aws_route_table.tokyo_route_table.id
  destination_cidr_block    = aws_vpc.osaka_vpc.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_to_osaka.id

  depends_on = [aws_vpc_peering_connection_accepter.osaka_accepter]
}

# Route from Osaka to Tokyo VPC
resource "aws_route" "osaka_to_tokyo_route" {
  provider = aws.osaka

  route_table_id            = aws_route_table.osaka_route_table.id
  destination_cidr_block    = aws_vpc.tokyo_vpc.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_to_osaka.id

  depends_on = [aws_vpc_peering_connection_accepter.osaka_accepter]
}

# Main Route Table Association for Tokyo VPC
resource "aws_main_route_table_association" "tokyo_main_rt_association" {
  provider = aws.tokyo

  vpc_id         = aws_vpc.tokyo_vpc.id
  route_table_id = aws_route_table.tokyo_route_table.id
}

# Main Route Table Association for Osaka VPC
resource "aws_main_route_table_association" "osaka_main_rt_association" {
  provider = aws.osaka

  vpc_id         = aws_vpc.osaka_vpc.id
  route_table_id = aws_route_table.osaka_route_table.id
}

# Outputs
output "tokyo_vpc_id" {
  description = "ID of the Tokyo VPC"
  value       = aws_vpc.tokyo_vpc.id
}

output "osaka_vpc_id" {
  description = "ID of the Osaka VPC"
  value       = aws_vpc.osaka_vpc.id
}

output "peering_connection_id" {
  description = "ID of the VPC Peering Connection"
  value       = aws_vpc_peering_connection.tokyo_to_osaka.id
}

output "tokyo_vpc_cidr" {
  description = "CIDR block of the Tokyo VPC"
  value       = aws_vpc.tokyo_vpc.cidr_block
}

output "osaka_vpc_cidr" {
  description = "CIDR block of the Osaka VPC"
  value       = aws_vpc.osaka_vpc.cidr_block
}

提案されたコードの説明を見てみます。

# 作成したコードの概要
## 主な構成要素：

1. プロバイダー設定
   - 東京リージョン（ap-northeast-1）用のプロバイダー
   - 大阪リージョン（ap-northeast-3）用のプロバイダー
   - 最新のAWSプロバイダー（~> 6.7.0）を使用

2. VPC作成
   - 東京VPC: CIDR 10.1.0.0/16
   - 大阪VPC: CIDR 10.2.0.0/16
   - 両方ともDNSサポートとDNSホスト名を有効化

3. VPCピアリング接続
   - 東京から大阪へのピアリング接続を作成
   - リクエスター側（東京）とアクセプター側（大阪）を適切に設定
   - クロスリージョンピアリングのためauto_accept = falseで設定

4. ルートテーブル設定
   - 各VPC用のルートテーブルを作成
   - 双方向のルートを設定（東京→大阪、大阪→東京）
   - メインルートテーブルとの関連付け

5. 出力値
   - VPC ID、ピアリング接続ID、CIDRブロックなどの重要な情報を出力

Terraform MCPサーバーを利用して生成されたコードでは、AWSプロバイダーの最新バージョン6.7.0が使用されています。ただし、サブネットやセキュリティグループの設定は含まれておらず、指示したリソースのみが作成される内容となりました。

AWSプロバイダー6.0では、複数リージョンでリソースを作成する際に、providerブロック内でaliasを使わずにregion属性を直接指定できる機能が追加されました。この機能を使って、コードを作成できるか試してみます。以下の依頼してみます。

AWSプロバイダー6.0の新機能で、Providerブロックを1つにして、Resourceブロックでaliesを使わず直接regionを指定する書式にしてください。

そうすると、指示通り以下のコードが生成されました。

Terraform MCPサーバーを使ったコード-2（コードは▶をクリック） 
# AWS Provider Configuration
terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.7.0"
    }
  }
}

# Single AWS Provider
provider "aws" {
  region = "ap-northeast-1"
}

# VPC in Tokyo region
resource "aws_vpc" "tokyo_vpc" {
  region = "ap-northeast-1"

  cidr_block           = "10.1.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "Tokyo-VPC"
    Environment = "Production"
    Region = "ap-northeast-1"
  }
}

# VPC in Osaka region
resource "aws_vpc" "osaka_vpc" {
  region = "ap-northeast-3"

  cidr_block           = "10.2.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "Osaka-VPC"
    Environment = "Production"
    Region = "ap-northeast-3"
  }
}

# VPC Peering Connection (requester side - Tokyo)
resource "aws_vpc_peering_connection" "tokyo_to_osaka" {
  region = "ap-northeast-1"

  vpc_id      = aws_vpc.tokyo_vpc.id
  peer_vpc_id = aws_vpc.osaka_vpc.id
  peer_region = "ap-northeast-3"
  auto_accept = false

  tags = {
    Name = "Tokyo-to-Osaka-Peering"
    Side = "Requester"
  }
}

# VPC Peering Connection Accepter (accepter side - Osaka)
resource "aws_vpc_peering_connection_accepter" "osaka_accepter" {
  region = "ap-northeast-3"

  vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_to_osaka.id
  auto_accept               = true

  tags = {
    Name = "Tokyo-to-Osaka-Peering"
    Side = "Accepter"
  }
}

# Route Table for Tokyo VPC
resource "aws_route_table" "tokyo_route_table" {
  region = "ap-northeast-1"

  vpc_id = aws_vpc.tokyo_vpc.id

  tags = {
    Name = "Tokyo-Route-Table"
  }
}

# Route Table for Osaka VPC
resource "aws_route_table" "osaka_route_table" {
  region = "ap-northeast-3"

  vpc_id = aws_vpc.osaka_vpc.id

  tags = {
    Name = "Osaka-Route-Table"
  }
}

# Route from Tokyo to Osaka VPC
resource "aws_route" "tokyo_to_osaka_route" {
  region = "ap-northeast-1"

  route_table_id            = aws_route_table.tokyo_route_table.id
  destination_cidr_block    = aws_vpc.osaka_vpc.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_to_osaka.id

  depends_on = [aws_vpc_peering_connection_accepter.osaka_accepter]
}

# Route from Osaka to Tokyo VPC
resource "aws_route" "osaka_to_tokyo_route" {
  region = "ap-northeast-3"

  route_table_id            = aws_route_table.osaka_route_table.id
  destination_cidr_block    = aws_vpc.tokyo_vpc.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.tokyo_to_osaka.id

  depends_on = [aws_vpc_peering_connection_accepter.osaka_accepter]
}

# Main Route Table Association for Tokyo VPC
resource "aws_main_route_table_association" "tokyo_main_rt_association" {
  region = "ap-northeast-1"

  vpc_id         = aws_vpc.tokyo_vpc.id
  route_table_id = aws_route_table.tokyo_route_table.id
}

# Main Route Table Association for Osaka VPC
resource "aws_main_route_table_association" "osaka_main_rt_association" {
  region = "ap-northeast-3"

  vpc_id         = aws_vpc.osaka_vpc.id
  route_table_id = aws_route_table.osaka_route_table.id
}

# Outputs
output "tokyo_vpc_id" {
  description = "ID of the Tokyo VPC"
  value       = aws_vpc.tokyo_vpc.id
}

output "osaka_vpc_id" {
  description = "ID of the Osaka VPC"
  value       = aws_vpc.osaka_vpc.id
}

output "peering_connection_id" {
  description = "ID of the VPC Peering Connection"
  value       = aws_vpc_peering_connection.tokyo_to_osaka.id
}

output "tokyo_vpc_cidr" {
  description = "CIDR block of the Tokyo VPC"
  value       = aws_vpc.tokyo_vpc.cidr_block
}

output "osaka_vpc_cidr" {
  description = "CIDR block of the Osaka VPC"
  value       = aws_vpc.osaka_vpc.cidr_block
}

提案されたコードの説明を見てみます。

AWSプロバイダー6.0の新機能を使用して、コードを更新しました。
## 主な変更点：

### 1. Providerブロックの簡素化
- 複数のプロバイダー（aws.tokyo、aws.osaka）を削除
- 単一のプロバイダー（aws）のみを使用
- デフォルトリージョンを東京（ap-northeast-1）に設定

### 2. Resourceブロックでの直接region指定
- 各リソースでprovider = aws.tokyoやprovider = aws.osakaを削除
- 代わりに各リソースで直接regionパラメータを指定
- 東京リージョンのリソース: region = "ap-northeast-1"
- 大阪リージョンのリソース: region = "ap-northeast-3"

### 3. メリット
- コードの簡素化: プロバイダーのエイリアスが不要になり、コードがよりシンプルに
- 可読性の向上: 各リソースがどのリージョンで作成されるかが一目で分かる
- 保守性の向上: プロバイダーの設定が集中化され、管理が容易

### 4. 互換性
- AWSプロバイダー6.0以降でサポートされる新機能
- 既存の機能はすべて同じように動作
- クロスリージョンピアリングも正常に動作

この新しい書式により、コードがより簡潔で理解しやすくなり、AWSプロバイダーの最新機能を活用できます。

メリットや互換性までコメントされており、納得感のある提案になっています。一見すると、期待通りのコードが生成されているようなので、実際にTerraformを実行し、リソースが正しく作成されるか確認してみます。まずは構文チェックを行います。
terraform init → terraform fmt → terraform validate の順に実行します。

Success! The configuration is valid.

全て正常に完了しましたので、terraform apply を実行します。

Plan: 10 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + osaka_vpc_cidr = "10.2.0.0/16"
  + osaka_vpc_id = (known after apply)
  + peering_connection_id = (known after apply)
  + tokyo_vpc_cidr = "10.1.0.0/16"
  + tokyo_vpc_id = (known after apply)

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

Planに問題なくApplyも無事に完了し、作成されたVPCの属性も出力されました。

Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Outputs:
osaka_vpc_cidr = "10.2.0.0/16"
osaka_vpc_id = "vpc-00940ccfc063711b9"
peering_connection_id = "pcx-0dd6583231cdfb031"
tokyo_vpc_cidr = "10.1.0.0/16"
tokyo_vpc_id = "vpc-0f6a1da73ba15ef5c"

確認のため、AWS管理コンソールにログインし、東京リージョンと大阪リージョンのVPC設定を確認したところ、正しく作成されており状態も正常であることが確認できました。

東京リージョンの設定

大阪リージョンの設定

 

このように、Terraform MCPサーバーを利用することで、常にHashiCorp社の公式ドキュメントに基づいた最新情報を参照できるため、精度の高いコード作成支援が期待できることが分かりました。現在はベータ版ですが、今後はHashiCorp Validated Designsの参照など、有償版ならではの機能を活用したさらなる機能拡張にも期待しています。

 

 

 

M.Nakabayashi

この記事の投稿者M.Nakabayashi

HashiCorp製品の技術を担当しています。野球観戦やサウナに行くのが好きです。

この記事をシェア

  • X（旧twitter）
  • facebook

この記事に関連する製品・サービス

HashiCorp Terraform

お問い合わせ

資料ダウンロード