Terraformを使ったインフラ管理は、コード量が増えるにつれて複雑さも増していきます。新しいAWSリソースを追加するたびにドキュメントを調べ、terraform planのエラーに何時間も費やし、環境間の差分管理に頭を悩ませた経験はないでしょうか。
Claude CodeをTerraformの開発ワークフローに組み込むと、この状況が大きく変わります。tfファイルの生成・レビュー・最適化、planエラーの解析、マルチ環境管理といった作業をAIがサポートすることで、インフラエンジニアは本質的な設計判断に集中できるようになります。
本記事では、Claude CodeとTerraformを組み合わせた実践的なワークフローを、具体的なコード例とともに解説します。terraform-skillのインストール・Terraform MCP Serverでのハルシネーション防止・本番事故防止の設定まで体系的にまとめました。
Claude Codeの基本的な使い方はClaude Code完全ガイドを、設定全般はsettings.json完全リファレンスを参照してください。
Claude Code × Terraform で何ができるか
Claude CodeをTerraformワークフローに統合すると、以下の作業をAIにサポートさせることができます。
| 作業 | 従来 | Claude Code導入後 |
|---|---|---|
| tfファイル生成 | ドキュメントを調べながら手書き | 要件を伝えると適切なリソース定義を生成 |
| plan出力の解析 | 差分を自分で読み解く | 「何が変わるか」を日本語で解説・リスクを指摘 |
| エラー修正 | エラーメッセージを検索して調査 | エラーの原因と修正方法を即座に提示 |
| セキュリティレビュー | 手動でポリシーを確認 | IAMワイルドカード・暗号化漏れを自動検出 |
| モジュール設計 | 再利用可能な構造を手で考える | ベストプラクティスに沿ったモジュール構造を提案 |
| コスト推定 | 別ツールで手動計算 | Infracost連携でコード生成と同時に月額推定を取得 |
Claude CodeはTerraformの専門知識をサポートしますが、
terraform applyの最終判断は人間が行います。AIに任せるのは「調査・生成・解析」、人間が行うのは「承認・実行」という役割分担が安全な運用の基本です。CLAUDE.md でTerraformプロジェクトを設定する
Claude CodeはプロジェクトルートのCLAUDE.mdを読み込んで動作ルールを把握します。Terraformプロジェクトでは、環境構成・命名規則・禁止事項をここに定義しておくと、Claudeが一貫したコードを生成するようになります。
# Terraform プロジェクト設定
## 技術スタック
- IaC: Terraform 1.9+
- クラウド: AWS(メインリージョン: ap-northeast-1)
- tfstate: S3バックエンド + DynamoDBロック
- CI/CD: GitHub Actions
## ディレクトリ構成
- environments/dev/ # 開発環境(state: s3://tf-state-dev)
- environments/staging/ # ステージング(state: s3://tf-state-stg)
- environments/prod/ # 本番環境(state: s3://tf-state-prod)
- modules/ # 再利用可能なモジュール
## 必須ワークフロー(すべての変更で厳守)
1. terraform fmt -check
2. terraform validate
3. tflint --config=.tflint.hcl
4. terraform plan -out=tfplan
5. [人間レビュー・承認]
6. terraform apply tfplan
## 命名規則
- リソース名: {環境}-{用途}-{リソース種別}(例: prod-web-alb)
- モジュール名: terraform-aws-{名前}(例: terraform-aws-vpc)
- タグ必須項目: Environment, Owner, Project, CostCenter
## 絶対禁止事項
- terraform apply の無人実行(plan確認・人間承認なし)
- terraform destroy の自律実行(特に prod 環境)
- IAMポリシーでのワイルドカード使用
- tfvarsファイルへの機密情報ハードコード
- 本番stateと開発stateの共有
## セキュリティ要件
- S3バケット: SSE必須
- RDS: 暗号化必須、パブリックアクセス禁止
- セキュリティグループ: 0.0.0.0/0 インバウンドは要承認
- IAMロール: 最小権限原則
environments/prod/CLAUDE.mdに「本番環境でのterraform destroyは絶対禁止」と追記すれば、本番ディレクトリ内でのClaude Codeの動作をさらに制限できます。CLAUDE.mdの詳細な設計方法はClaude Code完全ガイドで解説しています。terraform-skill のインストールと活用
Terraformに特化したClaudeスキルが公開されています。スキルを導入すると、Claudeが「Terraformの専門エンジニア」として振る舞うようになり、ベストプラクティスを自動的に適用したコード生成を行います。
Anton Babenko の terraform-skill
Terraform界隈で有名なAnton Babenko氏が公開しているスキルです。プロバイダーごとのベストプラクティス・セキュリティルール・コスト最適化のヒントが組み込まれています。
# Git cloneでインストール git clone https://github.com/antonbabenko/terraform-skill ~/.claude/skills/terraform-skill # 使い方: Claude Code内で以下を入力 # /terraform
インストール後、Claude Code内で/terraformと入力するとスキルが起動します。VPC・ECS・RDS・Lambda・IAMなど、主要なAWSリソースについて詳細なベストプラクティスが適用されます。
TerraShark(軽量・ハルシネーション対策特化)
anton babenkoスキルの代替として、TerraSharkも注目されています。約600トークンで起動するため、コンテキスト消費を抑えたい場合に有効です。ISO 27001・SOC 2・PCI DSS・HIPAAといったコンプライアンス要件のマッピングも組み込まれています。
git clone https://github.com/LukasNiessen/terrashark ~/.claude/skills/terrashark
セキュリティ企業Snykの調査では、GitHubで公開されているClaudeスキルの約13.4%に重大な脆弱性が含まれていることが報告されています。信頼できる作者のスキルを選ぶか、ソースコードを確認してからインストールしてください。スキルの仕組みについてはClaude Code Skillsガイドも参照してください。
Terraform MCP Server でハルシネーションを防ぐ
Claude CodeがTerraformコードを生成する際、最も厄介な問題が「ハルシネーション(存在しないリソース属性の生成)」です。AWSプロバイダーのバージョンが上がると引数名が変わったり廃止されたりすることがありますが、Claudeのトレーニングデータが古いとそれを知らずに旧属性を使ったコードを生成します。
Terraform MCP Serverを使うと、Claudeがリアルタイムでプロバイダースキーマを参照しながらコードを生成するため、このハルシネーション問題を大幅に削減できます。
# Docker が必要です # まず MCP Server を起動テスト docker run -i --rm hashicorp/terraform-mcp-server:0.3.0 # Claude Code に MCP サーバーを登録 claude mcp add terraform --transport stdio -- docker run -i --rm hashicorp/terraform-mcp-server:0.3.0
{
"mcpServers": {
"terraform": {
"command": "docker",
"args": ["run", "-i", "--rm", "hashicorp/terraform-mcp-server:0.3.0"]
}
}
}
登録後、Claude Codeがtfファイルを生成・編集する際に自動でTerraform MCP Serverを参照するようになります。「このリソースの属性は現在のAWSプロバイダーで有効か」「引数名は正しいか」をリアルタイムで検証しながらコードを書くため、動かないコードが大幅に減ります。
Terraform MCP Serverはプロバイダースキーマをローカルで参照できるAPIを提供します。Claude CodeはこのAPIを通じて、最新のAWS/GCP/Azureプロバイダーのリソース定義・引数・戻り値を確認しながらコードを生成します。MCPサーバーの全体的な活用方法はClaude Code MCP完全ガイドを参照してください。
tfファイル生成・最適化の実践パターン
Claude CodeへのプロンプトはTerraformでも重要です。曖昧な指示では曖昧なコードが返ってきます。以下に効果的なプロンプトパターンをまとめます。
新規リソース生成
必要な要件を箇条書きで伝えると、適切なモジュール構造を生成してくれます。
以下の要件でTerraformのVPCモジュールを作成してください: - リージョン: ap-northeast-1 - VPC CIDR: 10.0.0.0/16 - パブリックサブネット: 2つ(AZ-a, AZ-c) - プライベートサブネット: 2つ(AZ-a, AZ-c) - NATゲートウェイ: プライベートサブネット用 - タグ: Environment, Project, Owner(変数で受け取る) - terraform native testを含める
resource "aws_vpc" "this" {
cidr_block = var.vpc_cidr
enable_dns_support = true
enable_dns_hostnames = true
tags = merge(
{
Name = "${var.project}-${var.environment}-vpc"
Environment = var.environment
Project = var.project
Owner = var.owner
},
var.additional_tags
)
}
resource "aws_internet_gateway" "this" {
vpc_id = aws_vpc.this.id
tags = {
Name = "${var.project}-${var.environment}-igw"
Environment = var.environment
Project = var.project
}
}
# ... パブリック・プライベートサブネット、NATゲートウェイなどが続く
既存コードのレビュー・最適化
既存のtfファイルをClaude Codeに渡して「セキュリティ・コスト・命名規則の観点でレビューして」と依頼すると、問題点を列挙して修正案を提示してくれます。
以下の観点でmain.tfをレビューしてください: 1. IAMポリシーの最小権限違反(ワイルドカード使用) 2. S3・RDS・EBSの暗号化設定漏れ 3. セキュリティグループの 0.0.0.0/0 インバウンド 4. タグの欠落 5. Infracostで月額コスト推定も出してください
モジュール間の依存関係整理
このTerraformプロジェクトのリソース依存関係をDAG(有向非環グラフ)として マークダウン形式で図示してください。循環依存があれば警告してください。
terraform plan 出力の解析と意思決定支援
terraform planの出力は、慣れるまで読み解くのに時間がかかります。Claude Codeにplanの出力を渡すと、「何が変わるか」「リスクはあるか」を自然言語で解説してくれます。
# Step1: planをJSONで保存 terraform plan -out=tfplan terraform show -json tfplan > tfplan.json # Step2: Claude Codeで解析(Claude Code内で実行) # "tfplan.jsonを解析して、以下を教えてください: # 1. 変更されるリソースの一覧(追加/変更/削除) # 2. 削除されるリソースがある場合のデータロスリスク # 3. ダウンタイムが発生しそうな変更 # 4. セキュリティ上の懸念点"
terraform show -json tfplan | jq '.resource_changes[] | {address, actions}' > changes.jsonのように、変更リソースだけを抽出してからClaudeに渡すとトークン消費を抑えられます。IAMポリシー自動生成ワークフロー
「最小権限のIAMポリシーを作りたいが、必要なパーミッションがわからない」というケースでもClaude Codeが役立ちます。エラーメッセージを繰り返しClaude Codeに渡して、不足権限を積み上げていく反復ワークフローが効果的です。
# 1回目: apply実行(意図的に最小権限から始める) terraform apply # → Error: UnauthorizedOperation: not authorized to perform: s3:PutObjectAcl # Claude Codeへのプロンプト # "このエラーに必要なIAMパーミッションを追加して、 # 最小権限の原則を保ちながらIAMポリシーを更新してください" # 2回目以降: エラーが出なくなるまで繰り返す
よくあるエラーパターンと修正方法
Terraformでよく遭遇するエラーとClaude Codeを使った対処方法をまとめます。
| エラー種別 | 主な原因 | Claudeへの伝え方 |
|---|---|---|
| 状態ドリフト | コンソールやCLIでの手動変更 | 「terraform refreshで状態を再同期する手順を教えて」 |
| 依存関係エラー | リソース作成順序の問題 | 「このエラーの依存関係を解決するdepends_onを追加して」 |
| プロバイダー認証エラー | 認証情報・環境変数の不備 | 「AWS認証エラーのデバッグ手順を教えて」 |
| stateロックエラー | 前回の実行が中断してロックが残っている | 「DynamoDBのstateロックを安全に解除する方法は?」 |
| リソース名重複 | 既存リソースと命名が衝突 | 「既存リソースをTerraform管理下に取り込むimport手順を教えて」 |
| バージョン不一致 | required_versionとインストール済みバージョンの差異 | 「バージョン制約エラーの解決方法とtfenvでの管理方法を教えて」 |
エラーをClaude Codeに伝えるコツ
以下のterraform applyエラーを解析して、原因と修正方法を教えてください:
【エラーメッセージ(全文)】
Error: error creating S3 Bucket (example-bucket): BucketAlreadyOwnedByYou:
The bucket you tried to create already exists, and you already own it.
【関連tfファイル(main.tf抜粋)】
resource "aws_s3_bucket" "example" {
bucket = "example-bucket"
}
【実行環境】
- Terraformバージョン: 1.9.0
- AWS providerバージョン: ~> 5.0
- 実行者: ローカル(IAMユーザー: iam-user-dev)
マルチ環境(dev/stg/prod)の管理戦略
多くのプロジェクトでは開発・ステージング・本番の3環境を管理します。Claude Codeを使うと、環境間の差分を整理したり、環境固有の設定を適切に分離したりするコードを生成できます。
推奨ディレクトリ構成
project/ ├── modules/ # 再利用可能なモジュール │ ├── vpc/ │ ├── rds/ │ └── ecs/ ├── environments/ │ ├── dev/ │ │ ├── main.tf # モジュール呼び出し │ │ ├── variables.tf │ │ ├── terraform.tfvars # .gitignore対象 │ │ └── backend.tf # dev用stateバックエンド │ ├── staging/ │ │ └── ... │ └── prod/ │ ├── main.tf │ ├── CLAUDE.md # 本番専用の制約を追記 │ └── backend.tf # prod用stateバックエンド └── CLAUDE.md # 全体共通のルール
devとprodのterraform.tfvarsを比較して、 本番に適用する前に注意すべき設定差分を列挙してください。 特に以下の点を確認してください: - インスタンスタイプの違い - マルチAZ設定の有無 - バックアップ設定 - セキュリティグループのルール差異
terraform workspaceはシンプルな環境分離に見えますが、stateを完全に分離できるわけではなく、本番環境の誤操作リスクがあります。HashiCorpも現在は「ディレクトリ分離」アプローチを推奨しています。Claude Codeに「workspace vs ディレクトリ分離、どちらが適切か」と聞いて判断する材料にしてください。
機密情報・シークレットの安全な管理
Terraformでインフラを管理する際に最も注意が必要なのが機密情報の扱いです。パスワード・APIキー・証明書をtfvarsに書いてgitにコミットしてしまうミスは後を絶ちません。
.gitignore の標準設定
# Terraform *.tfvars *.tfvars.json *.tfplan *.tfstate *.tfstate.backup .terraform/ # 機密情報 *.pem *.key credentials.json service-account.json .env override.tf *_override.tf
sensitive変数の定義
variable "db_password" {
description = "RDSマスターパスワード"
type = string
sensitive = true # terraform outputに表示されなくなる
}
variable "api_key" {
description = "外部APIキー"
type = string
sensitive = true
}
環境変数経由でのシークレット渡し(推奨)
tfvarsファイルを使わず、環境変数(TF_VAR_*)でシークレットを渡す方法が推奨されます。AWS Secrets Manager・HashiCorp Vault・GitHub Secretsからシークレットを取得して環境変数に設定します。
# AWS Secrets Manager からシークレットを取得 export TF_VAR_db_password=$(aws secretsmanager get-secret-value --secret-id prod/rds/master-password --query SecretString --output text) # HashiCorp Vault から取得する場合 export TF_VAR_api_key=$(vault kv get -field=value secret/myapp/api-key) # terraform plan 実行(tfvarsなしでもシークレットが渡る) terraform plan
# terraform.tfvars.example # このファイルはGitにコミットする。実際の値は設定しない。 # 実際の値はAWS Secrets Manager / Vault から取得してTF_VAR_* 環境変数で渡す。 db_password = "CHANGE_ME" api_key = "your-api-key-here"
#!/bin/bash
# .git/hooks/pre-commit
# gitleaks でシークレットを検出してコミットをブロック
if command -v gitleaks &> /dev/null; then
gitleaks protect --staged --config .gitleaks.toml
if [ $? -ne 0 ]; then
echo "ERROR: シークレットが検出されました。コミットを中止します。"
exit 1
fi
fi
GitLab CI/CD との統合
Claude CodeはGitHub Actionsだけでなく、GitLab CI/CDとも統合できます(GitHub Actions統合はこちら)。GitLab CIでClaudeを動かすことで、MRのレビュー・Terraformのplan実行・セキュリティチェックを自動化できます。
stages:
- validate
- plan
- ai-review
terraform-validate:
stage: validate
image: hashicorp/terraform:1.9
script:
- terraform fmt -check -recursive
- terraform validate
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
terraform-plan:
stage: plan
image: hashicorp/terraform:1.9
script:
- terraform plan -out=tfplan
- terraform show -json tfplan > tfplan.json
artifacts:
paths:
- tfplan.json
expire_in: 1 hour
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
claude-review:
stage: ai-review
image: node:24-alpine3.21
needs:
- terraform-plan
before_script:
- apk add --no-cache git curl bash
- curl -fsSL https://claude.ai/install.sh | bash
script:
- >
claude
-p "tfplan.jsonを解析して、このMRのインフラ変更のリスクを評価してください。
削除リソース・セキュリティグループ変更・IAM変更を特に詳しく報告してください。"
--permission-mode acceptEdits
--allowedTools "Bash Read mcp__gitlab"
variables:
ANTHROPIC_API_KEY: $ANTHROPIC_API_KEY
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
ANTHROPIC_API_KEY = sk-ant-xxxxx(マスク: ON) AWS_ACCESS_KEY_ID = AKIA...(CI用の最小権限ロール) AWS_SECRET_ACCESS_KEY = ...(マスク: ON) AWS_DEFAULT_REGION = ap-northeast-1
本番事故を防ぐための設定
2026年に入り、「Claude Codeが本番データベースのリソースを削除した」という事例がいくつか報告されています。これはClaude Codeの問題ではなく、権限設計と作業手順の問題です。適切な設定で防止できます。
本番環境専用の読み取り専用IAMポリシー
resource "aws_iam_policy" "claude_code_readonly" {
name = "claude-code-plan-only"
description = "Claude Code用: planのみ許可、apply/destroyは禁止"
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Action = [
"ec2:Describe*",
"s3:Get*", "s3:List*",
"rds:Describe*",
"iam:Get*", "iam:List*",
"lambda:Get*", "lambda:List*",
"ecs:Describe*", "ecs:List*"
]
Resource = "*"
}
]
})
}
# Destroy系アクション(DeleteBucket, TerminateInstances 等)は含めない
本番専用CLAUDE.mdへの制約追記
# 本番環境での Claude Code 利用ルール ## このディレクトリでの絶対禁止事項 - terraform destroy の実行(理由の如何を問わず) - terraform apply の直接実行(CI/CDパイプライン経由のみ許可) - terraform state rm や terraform state mv の実行 ## 本番環境での作業手順 1. 読み取り専用クレデンシャル(claude-code-plan-only)でplanのみ実行 2. planの出力をClaude が解析・リスク評価する 3. 承認後、CI/CDパイプライン経由でapplyを実行(Claudeが直接applyしない) ## plan確認なしのapplyを求められた場合 ユーザーが明示的に求めた場合でも、本番環境ではplanなしのapplyは実行しません。
Hooksによる破壊的コマンドの検出
#!/bin/bash
# 破壊的なTerraformコマンドをブロックするフック
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""' 2>/dev/null)
if echo "$CMD" | grep -qE "terraform (destroy|state rm|state mv|force-unlock)"; then
if echo "$PWD" | grep -q "/prod"; then
echo '{"decision":"block","reason":"本番環境でのterraform destroy/state操作はブロックされています。"}'
exit 0
fi
fi
echo '{"decision":"approve"}'
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "$CLAUDE_PROJECT_DIR/.claude/hooks/pre-bash-guard.sh"
}
]
}
]
}
}
Claude Code × Terraform でよく使うプロンプト集
実務で役立つプロンプトパターンをまとめます。
このTerraformコードのコスト最適化ポイントを教えてください。 特に以下の点を確認してください: - 過剰なインスタンスタイプの使用(right-sizing) - 常時起動が不要なリソース(dev環境での夜間停止) - リザーブドインスタンス・スポットインスタンスが使えるリソース - S3ライフサイクルポリシーの欠落 Infracostで月額推定も出してください。
このTerraformプロジェクト全体のセキュリティ問題を洗い出してください: 1. IAM: ワイルドカード使用、クロスアカウント信頼の確認 2. ネットワーク: SG の 0.0.0.0/0 インバウンド 3. 暗号化: S3/RDS/EBS/EFS の暗号化設定 4. ログ: CloudTrail/VPC Flow Logs/S3アクセスログの有効化 5. パブリックアクセス: S3/RDS等のパブリック設定 tfsecとCheckovで自動スキャンして結果も見せてください。
このmain.tfは800行を超えています。 以下の基準で再利用可能なモジュールに分割してください: - VPC・サブネット関連 - セキュリティグループ - RDS - ECS/Fargate 各モジュールのinputs/outputs/README.mdも生成してください。
よくある質問
terraform validateを実行して検証するフローを必ず組み込んでください。.claude/settings.jsonのignoreFiles設定で、*.tfvarsやsecrets/ディレクトリをClaude Codeの参照対象から除外できます。また、機密情報はAWS Secrets ManagerやHashiCorp Vaultに移行し、TF_VAR_*環境変数経由でTerraformに渡すアーキテクチャへの変更を強く推奨します。Claude Codeセキュリティガイドも参照してください。terraform show -json tfplan | jq '.resource_changes[]' > changes.jsonのように、resource_changesだけを抽出してから渡すのが効果的です。変更が多い場合は「削除(d)のみ」「セキュリティグループ変更のみ」などフィルタリングしてから渡すと、Claudeがより精度の高い分析を返します。terraform fmtをPostToolUse hooksに設定して、Claudeがファイルを編集するたびに自動フォーマットするようにしておくと一貫性が保てます。npx skills add https://github.com/dirien/claude-skills --skill pulumi-typescriptで専用スキルをインストールできます。OIDC認証・ComponentResourceパターン・ESC連携などが組み込まれています。OpenTofuはTerraformと互換性が高いため、terraform-skillをそのまま活用できます。CLAUDE.mdにUse OpenTofu (tofu) instead of terraform commandと記載するだけで切り替えられます。まとめ
Claude CodeとTerraformを組み合わせることで、インフラ開発の生産性を大幅に向上させることができます。特に効果が大きいのは以下の3点です。
- terraform-skill + Terraform MCP Server:ハルシネーションのないtfファイル生成
- CLAUDE.mdでの制約定義:チーム全員が同じルールで作業できる一貫したコード生成
- 本番事故防止の設定:読み取り専用IAM + Hooksで破壊的操作をブロック
IaCの本質は「インフラをコードで管理する」ことですが、Claude Codeを活用することで「コードをAIと一緒に設計・レビュー・改善する」という新しいワークフローが加わります。最終的な承認と実行は人間が行い、調査・生成・解析をAIにサポートさせる——この役割分担を意識すると、安全かつ効率的なIaC運用が実現できます。
Claude Codeの権限設定の詳細は権限・パーミッション設定完全ガイドを、MCPサーバーの活用はMCP完全ガイドを、クラウドプロバイダー連携はAWS Bedrock・Vertex AI・Azure統合ガイドを参照してください。

