【2026年最新】Claude Code×Terraformでインフラコード管理

「Claude Code に Terraform を触らせても大丈夫なんですか？」

インフラコードの相談で、かなり高い確率で出てくる質問です。アプリケーションコードならテストで落とせばよい場面も多いのですが、Terraform は違います。たった1行の差分で公開範囲、課金、ネットワーク、削除保護、IAM 権限が変わることがあります。

正直に言うと、私自身も Terraform を Claude Code に任せるときは、最初から「全部やって」とは言いません。最初に見たいのは、ディレクトリ構成、state の置き場所、tfvars の扱い、CI の承認フローです。ここを見ずにプロンプトだけ整えても、運用では必ず詰まります。

この記事は、実在案件の成果数値を語る記事ではありません。事例区分：実装パターン解説として、Claude Code を Terraform 管理に組み込むための設計・手順・プロンプト・設定例をまとめます。Claude Code の機能名と設定項目は、2026年7月7日時点で Claude Code 公式ドキュメント、Permissions、Hooks guide、MCP を確認した範囲で書いています。

Claude Code×Terraformで任せる範囲、任せない範囲

Terraform 管理で最初に決めるべきことは、「Claude Code に何をさせるか」ではなく「何を絶対にさせないか」です。Claude Code はコードベースを読んで編集し、コマンドを実行できます。公式ドキュメント上も、Bash、Read、Edit、Grep などのツールや、細かな権限ルールが用意されています。だからこそ、IaC では境界線を先に引きます。

実務では、次の4層に分けると整理しやすいです。

層	Claude Codeに任せやすい作業	人間の承認を残す作業
理解	モジュール構成、依存関係、変数、出力値の把握	本番環境の意図、組織ポリシー、例外ルールの判断
編集	resource / variable / output / module 呼び出しの追加、README 更新	削除保護、IAM 管理者権限、公開ネットワークの変更
検証	terraform fmt、terraform validate、plan の差分要約	plan の業務影響判断、セキュリティ承認、費用判断
反映	PR 説明、レビュー観点、ロールバック手順の下書き	terraform apply、destroy、state 操作、認証情報の発行

ここで大切なのは、Claude Code を「Terraform の実行者」ではなく「IaC レビューを速くする相棒」として置くことです。plan の読み取り、差分の要約、影響範囲の洗い出しは得意です。一方で、クラウドアカウントの本番権限を持たせたまま apply まで任せる設計は、組織の監査・変更管理と衝突しやすいんです。

Terraform の変更レビューだけに絞った考え方は、関連する Terraform IaC変更レビューをClaude Codeで進める実践記事 でも扱っています。本記事ではさらに、リポジトリ設定、権限、Hooks、チーム運用まで広げます。

初期設定：CLAUDE.mdでインフラの前提を読ませる

Terraform リポジトリで Claude Code を起動する前に、まず CLAUDE.md を整えます。Claude Code 公式ドキュメントでは、プロジェクト固有の永続指示として CLAUDE.md を使う設計が説明されています。Terraform ではここに「構成図」「禁止操作」「検証コマンド」「レビュー観点」を短く入れるのが効果的です。

自分が最初に見るのは、modules/ と envs/ の分離です。たとえば次のような構成なら、Claude Code にも人間にも意図が伝わりやすくなります。

infra/
  CLAUDE.md
  .claude/
    settings.json
    hooks/
  modules/
    network/
    app/
    iam/
  envs/
    dev/
    stg/
    prod/
  docs/
    change-template.md
    rollback-runbook.md

CLAUDE.md の例です。ポイントは、抽象的な「安全にやって」ではなく、実行してよいコマンドと禁止する操作を具体名で書くことです。

# Terraform運用ルール

このリポジトリはTerraformでクラウドインフラを管理する。

## ディレクトリ
- modules/: 再利用モジュール
- envs/dev/: 開発環境
- envs/stg/: 検証環境
- envs/prod/: 本番環境
- docs/: 変更手順、ロールバック手順、ADR

## Claude Codeへの依頼範囲
- Terraformコードの読解
- 変更案の作成
- terraform fmt / validate の実行
- terraform plan 出力の要約
- PR説明文、レビュー観点、ロールバック手順の下書き

## 禁止
- terraform apply / destroy を実行しない
- terraform state 系コマンドを実行しない
- .tfstate、.tfvars、.env、秘密鍵、認証情報を読まない
- 本番環境 envs/prod/ の変更は、事前に変更方針を提示して承認を待つ

## 回答ルール
- 変更前に影響範囲を箇条書きで説明する
- 不足している情報があれば、最初に質問してから作業を開始する
- 仮定した点は必ず「仮定」と明記する
- 数字と固有名詞は、根拠または計算式を添える

この段階でのプロンプトは、コードを書かせるより先に「棚卸し」を頼むのが安全です。

このTerraformリポジトリを読み、次の観点で現状を整理してください。

1. ディレクトリ構成
2. 環境ごとの差分
3. 主要moduleの責務
4. stateやtfvarsの扱いで注意すべき点
5. Claude Codeに任せてよい作業と、人間承認が必要な作業

ファイル編集はまだ行わず、まず調査結果だけを出してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

ここでいきなり「VPC を作って」「ECS を追加して」と頼むと、既存の命名規則、タグ、バックエンド、プロバイダ制約を見落としやすくなります。最初の1回は、Claude Code にリポジトリの地図を作らせる。これだけで後続の精度がかなり変わります。

権限設計：/permissionsとsettings.jsonでapplyを止める

Claude Code の権限管理は、Terraform 運用の中核です。公式ドキュメントでは /permissions で許可ルールを確認・管理でき、allow、ask、deny のルールが使えると説明されています。また、権限ルールは deny、ask、allow の順に評価されます。これは Terraform ではかなり重要です。

おすすめは、fmt と一部の読み取り系は許可、plan は確認、apply、destroy、state は拒否です。たとえば .claude/settings.json に次のような方針を置きます。

{
  "permissions": {
    "allow": [
      "Bash(terraform fmt*)",
      "Bash(terraform validate*)",
      "Bash(terraform version*)",
      "Bash(terraform providers*)",
      "Bash(terraform workspace show*)"
    ],
    "ask": [
      "Bash(terraform init*)",
      "Bash(terraform plan*)"
    ],
    "deny": [
      "Bash(terraform apply*)",
      "Bash(terraform destroy*)",
      "Bash(terraform state*)",
      "Bash(terraform import*)",
      "Bash(terraform force-unlock*)"
    ]
  }
}

注意点があります。deny は強いルールなので、「基本は deny だが、この1パターンだけ allow」のような例外設計には向きません。公式ドキュメントでも、広い deny は狭い allow より先に効くと説明されています。例外が必要な場合は、最初から ask にして人間の承認で止めるほうが扱いやすいです。

--dangerously-skip-permissions も公式 CLI リファレンスに存在しますが、Terraform リポジトリでは原則使わないでください。公式ドキュメントでも bypass permissions は承認プロンプトをスキップするモードとして説明され、隔離されたコンテナや VM のような環境で使うべきものとされています。IaC で本番クラウド権限を持つ端末からこのモードを使うのは、便利さよりリスクが上回ります。

チーム展開時の権限設計は、Claude Code権限設計のチーム導入ガイド もあわせて読むと理解しやすいです。Terraform では特に、個人の好みではなく、組織の変更管理ルールとして設定するのがポイントです。

実務手順：変更要求からplanレビューまでの流れ

Claude Code を Terraform 管理に入れるとき、作業を小さなステップに分けると事故が減ります。私なら、1回のセッションに「調査」「変更案」「編集」「検証」「PR説明」の5段階を置きます。いきなり最後まで走らせないのがコツです。

1. 調査：既存構成、module、変数、影響範囲を読む。
2. 変更案：どのファイルをどう変えるか、先に計画を出す。
3. 編集：承認後に Terraform コードを修正する。
4. 検証：terraform fmt、validate、必要に応じて plan を実行する。
5. レビュー：差分、plan、リスク、ロールバックをPR説明にまとめる。

たとえば「stg に S3 バケットを追加し、prod はまだ触らない」という依頼なら、最初のプロンプトはこうします。

envs/stg にアプリケーションログ用のS3バケットを追加したいです。

まず次を調査してください。
- 既存のS3関連moduleがあるか
- 命名規則とtag規則
- stgとprodの差分管理方法
- 変更が必要なファイル一覧

まだ編集しないでください。
最後に「変更計画」と「人間が確認すべきリスク」を出してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

変更計画が妥当なら、次に編集を依頼します。

変更計画に沿って、envs/stg のみ編集してください。

制約:
- envs/prod は変更しない
- 新規moduleを作るより、既存moduleが使えるなら既存moduleを優先
- 変更後に terraform fmt を実行
- terraform apply / destroy / state / import は実行しない

編集後に、変更ファイル、意図、未確認事項をまとめてください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

編集後は、plan の出力をそのまま貼るだけではレビューしづらいので、Claude Code に差分の読み替えを頼みます。

以下の terraform plan 出力をレビュー用に要約してください。

出してほしい内容:
1. 作成・更新・削除されるリソース数
2. セキュリティ上の注意点
3. 課金に関わる可能性がある変更
4. 本番反映前に確認すべき項目
5. ロールバック時に注意する点

planに出ていない事項は推測で断定しないでください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

この運用にすると、Claude Code は「編集担当」だけでなく「レビュー観点を出す担当」になります。特に Terraform は、コード差分だけ見ても実リソースへの影響が読みづらいことがあります。plan の要約をPR説明に入れるだけで、レビューの質が上がります。

Hooksでfmt・validate・保護ファイルチェックを自動化する

Claude Code の Hooks は、公式ドキュメントで説明されている通り、セッションやツール実行の特定タイミングでシェルコマンドなどを実行する仕組みです。Terraform では、PostToolUse で編集後の fmt を走らせ、PreToolUse で保護ファイルへの編集を止め、Stop で最後の確認コマンドを促す、という使い分けが実務的です。

まず、編集後に Terraform ファイルだけを整形チェックする hook です。

#!/bin/bash
# .claude/hooks/terraform-post-edit.sh
set -euo pipefail

INPUT="$(cat)"
FILE_PATH="$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')"

case "$FILE_PATH" in
  *.tf)
    DIR="$(dirname "$FILE_PATH")"
    terraform -chdir="$DIR" fmt
    ;;
esac

exit 0

次に、state、tfvars、環境変数、秘密鍵らしきファイルを編集対象から外す hook です。ここでは exit 2 でブロックします。公式 Hooks guide でも、保護ファイルに対して PreToolUse hook を使うパターンが紹介されています。

#!/bin/bash
# .claude/hooks/protect-terraform-files.sh

INPUT="$(cat)"
FILE_PATH="$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')"

PROTECTED_PATTERNS=(
  ".tfstate"
  ".tfvars"
  ".env"
  ".pem"
  ".key"
  ".terraform/"
  ".git/"
)

for pattern in "${PROTECTED_PATTERNS[@]}"; do
  if [[ "$FILE_PATH" == *"$pattern"* ]]; then
    echo "Blocked: $FILE_PATH matches protected pattern '$pattern'" >&2
    exit 2
  fi
done

exit 0

最後に .claude/settings.json へ登録します。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-terraform-files.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/terraform-post-edit.sh"
          }
        ]
      }
    ]
  }
}

この設定を入れたら、次のプロンプトで Claude Code に確認させます。

.claude/settings.json と .claude/hooks/ の内容を確認し、Terraform運用として危険な点がないかレビューしてください。

観点:
- apply / destroy / state 操作が止まるか
- .tfstate / .tfvars / .env / 秘密鍵への編集が止まるか
- terraform fmt が編集後に走るか
- チームで共有してよい設定と、個人ローカルに置くべき設定が分かれているか

ファイル編集はまだ行わず、問題点と修正案だけ出してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

Hooks の詳しい使い方は、内部記事の Claude Code Hooks実践ガイド と、公式の Automate actions with hooks を参照してください。ここでは Terraform 用に最低限の設定に絞りました。

環境分離：dev、stg、prodをClaude Codeに混ぜさせない

Terraform でよくある事故は、dev のつもりで prod のファイルを変えることです。Claude Code を使うと編集速度が上がるぶん、環境の境界が曖昧なリポジトリでは危険も増えます。ここはディレクトリ設計とプロンプトで二重に守ります。

まず、環境ごとの作業ディレクトリを明確にします。

envs/
  dev/
    backend.tf
    main.tf
    variables.tf
  stg/
    backend.tf
    main.tf
    variables.tf
  prod/
    backend.tf
    main.tf
    variables.tf

次に、Claude Code に「今回の作業対象はどこか」を毎回明示します。自分なら、prod を触るセッションでは最初から plan mode 相当の進め方に寄せ、編集前に必ず差分計画を出させます。

今回の作業対象は envs/stg のみです。

ルール:
- envs/prod 配下は読み取りだけにしてください
- envs/prod を編集する必要があると判断した場合は、編集せず理由を説明してください
- module変更がprodにも影響する場合は、影響範囲を先に説明してください
- applyは実行しないでください

まず対象ファイルを特定し、変更計画だけを出してください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

module 変更にも注意が必要です。modules/network を直すと、dev だけでなく stg、prod も影響を受ける可能性があります。環境ディレクトリだけ見ていると、この横断影響を見落とします。Claude Code には「この module を参照している環境を全部列挙して」と依頼するとよいです。

modules/network の変更を検討しています。

このmoduleを参照しているすべての環境と呼び出し元を列挙してください。
そのうえで、今回の変更が dev / stg / prod に与える可能性がある影響を分けて整理してください。

まだ編集しないでください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

この確認を挟むだけで、「stg のつもりが共通 module を変えて prod にも効く」という事故をかなり避けやすくなります。IaC では、ファイルパスの変更範囲と実際の影響範囲が一致しないことを、常に前提にしてください。

PRレビュー：plan出力をレビュー可能な言葉に変える

Terraform のレビューでつらいのは、差分の意味が読み手によって変わることです。cidr_block、security_group_rule、iam_policy_document、lifecycle の1行変更は、アプリケーションコードの1行変更より重いことがあります。

Claude Code のコマンドリファレンスには、差分を確認する /diff やコードレビュー系のコマンドが掲載されています。Terraform では、これに加えて plan 出力を人間向けのレビュー文脈へ翻訳させると効果が出ます。

このPRのTerraform差分をレビューしてください。

観点:
1. 意図しないdestroyがないか
2. IAM権限が広がっていないか
3. public access / ingress / egress が広がっていないか
4. 暗号化、ログ、バックアップ、削除保護が落ちていないか
5. タグ、命名規則、環境分離に違反していないか
6. plan出力とコード差分が矛盾していないか

指摘は「ブロッカー」「要確認」「改善提案」に分けてください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

PR説明文も、Claude Code に下書きさせる価値があります。ただし「安全です」と断定させるのではなく、「確認したこと」と「未確認のこと」を分けさせます。

このTerraform変更のPR説明文を作成してください。

含める項目:
- 変更目的
- 変更ファイル
- 作成・更新・削除されるリソース
- セキュリティ影響
- 費用影響の可能性
- ロールバック方針
- レビュアーに確認してほしい点
- apply前チェックリスト

未確認の内容は「未確認」と明記し、断定しないでください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

ここでのゴールは、Claude Code に承認を代行させることではありません。レビュアーが短時間で正しい論点を見られるようにすることです。SRE や運用チームの文脈では、関連する Claude Code×SRE/インフラ運用ガイド も参照すると、インシデント対応や運用手順との接続が見えやすくなります。

チーム運用：個人設定と共有設定を分ける

Claude Code の設定は、ユーザー設定、プロジェクト設定、ローカル設定、管理設定などのスコープがあります。公式 settings ドキュメントでは、.claude/settings.json や .claude/settings.local.json、~/.claude/settings.json などの使い分けが説明されています。Terraform では、この分離がかなり重要です。

置き場所	用途	Terraformでの例
.claude/settings.json	チームで共有するプロジェクト設定	apply禁止、protect hook、fmt hook、共通のask/denyルール
.claude/settings.local.json	個人ローカル設定	個人の通知、ローカルパス、実験的なhook
~/.claude/settings.json	ユーザー全体設定	全リポジトリ共通の禁止コマンド、個人の環境変数
管理設定	組織で強制する設定	bypass権限の無効化、MCPサーバー制限、サンドボックス方針

個人の通知やローカルの認証情報パスを、共有の .claude/settings.json に入れるのは避けてください。反対に、terraform apply 禁止のようなチーム全員に必要なルールを個人設定だけに置くと、メンバーごとに安全性が変わってしまいます。

設定ファイル全体の考え方は、内部記事の Claude Code settings.json設定ガイド が参考になります。Terraform では、settings を「便利設定」ではなく「変更管理の一部」として扱うのがコツです。

よくある失敗パターンと回避策

失敗1：Claude Codeにapplyまで任せる

❌「変更して、そのまま apply まで実行して」

⭕「変更案を作り、fmt / validate / plan まで実行。apply はCIの承認ジョブで人間が実行」

なぜ重要か：Terraform はクラウド上の実リソースを変えます。Claude Code の出力がどれほど自然でも、本番反映は組織の変更管理、監査、承認フローに従うべきです。

失敗2：tfvarsやstateを普通のコードとして読ませる

❌「リポジトリ全体を読んで、よしなに直して」

⭕「.tfstate、.tfvars、.env、秘密鍵は読まず、必要な変数名だけをコードから推測せず質問する」

なぜ重要か：state や変数ファイルには、リソースID、出力値、場合によっては機微情報が含まれることがあります。AI ツール以前に、IaC 運用として扱いを分けるべき領域です。

失敗3：module変更の横断影響を見ない

❌「dev のために module を少し直す」

⭕「module の参照元を列挙し、dev / stg / prod への影響を分けてから変更する」

なぜ重要か：Terraform の module は複数環境から呼ばれます。ファイル上は1箇所の変更でも、実際には複数環境の plan に差分が出ることがあります。

失敗4：planの要約だけを信じる

❌「Claude Code が『問題なし』と言ったのでマージ」

⭕「plan 原文、コード差分、CI、セキュリティレビュー、人間の承認をセットで確認」

なぜ重要か：AI は補助ツールであり、最終判断者ではありません。特に IAM、ネットワーク、削除、課金に関わる変更は、チームのレビューポリシーに従ってください。

導入チェックリスト：小さく始めて本番に広げる

最初から全環境・全moduleで Claude Code を使う必要はありません。おすすめは、読み取りとレビューから始め、次に dev/stg の小さな変更、最後に prod 変更のPR説明補助へ広げる順番です。

1. 1日目：CLAUDE.md を作り、禁止操作と検証コマンドを書く。
2. 1週目：/permissions で Terraform コマンドの allow / ask / deny を整理する。
3. 2週目：dev または stg の小さな変更で、調査・編集・fmt・validate・plan要約を試す。
4. 3週目：Hooks で .tfstate、.tfvars、.env、秘密鍵の編集ブロックを入れる。
5. 4週目：PRテンプレートに plan 要約、リスク、ロールバック、確認事項を追加する。

チームで共有する導入プロンプトは次の形が使いやすいです。

このTerraformリポジトリにClaude Codeを安全に導入するための初期レビューをしてください。

確認対象:
- CLAUDE.md に不足している運用ルール
- .claude/settings.json に入れるべきpermissions
- .claude/hooks/ に入れるべき保護hook
- dev / stg / prod の環境分離
- applyをCI承認に残すための運用案
- PRテンプレートに追加すべき項目

実在しないClaude Code機能を前提にしないでください。
公式Docsで確認できない機能は「要確認」と書いてください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

参考・出典

• Claude Code Overview — Claude Code Docs（参照日：2026-07-07）
• Configure permissions — Claude Code Docs（参照日：2026-07-07）
• Claude Code settings — Claude Code Docs（参照日：2026-07-07）
• Automate actions with hooks — Claude Code Docs（参照日：2026-07-07）
• Hooks reference — Claude Code Docs（参照日：2026-07-07）
• Connect Claude Code to tools via MCP — Claude Code Docs（参照日：2026-07-07）
• Explore the .claude directory — Claude Code Docs（参照日：2026-07-07）

まとめ：今日から始める3つのアクション

1. 今日やること：CLAUDE.md に Terraform の禁止操作、検証コマンド、prod 変更時の承認ルールを書く。
2. 今週中：.claude/settings.json で terraform fmt は allow、plan は ask、apply / destroy / state は deny にする。
3. 今月中：dev または stg の小さな変更で、調査、変更案、編集、plan 要約、PR説明までを1本の標準手順にする。

あわせて読みたい：Terraform IaC変更レビュー、SRE/インフラ運用ガイド、Hooks実践ガイド、settings.json設定ガイド。

次回予告：次の記事では、Terraform の plan 出力を PR コメントに変換し、セキュリティ・費用・削除リスクを自動で分類するレビュー運用を扱います。

あわせて読みたい

• ▸ Claude CodeでOpenAPI仕様駆動開発｜APIファースト実践ガイド