Terraform ワークスペース戦略：環境分離のパターン実務

Terraform の「ワークスペース」は便利ですが、万能な隔離境界ではありません。環境分離はアカウント分離、ディレクトリ分離、ワークスペース分離を組み合わせて設計します。

本稿は公式ドキュメントに基づき、試験（Associate / Pro）で狙われる論点と、チーム運用で迷いがちな判断基準を実例で解説します。

用語と前提：CLI ワークスペースと Terraform Cloud の違い

Terraform CLI のワークスペースは「1 つの設定ディレクトリ内で状態ファイル（state）を名前で分割する仕組み」です。サポートするバックエンド（local、複数のリモートバックエンドなど）では、default 以外のワークスペースごとに別 state が保持されます。

Terraform Cloud/Enterprise（TFC/TFE）の「ワークスペース」は、状態・変数・実行（Run）・ポリシーを内包する一級のオブジェクトです。CLI のワークスペースと名前は同じでも、機能と運用単位が異なります（混同注意）。

重要ポイント：ワークスペースは「権限境界」にはなりません。強い隔離（本番保護、課金・IAM 分離）が必要な場合は、クラウドアカウント/プロジェクトや別バックエンドを用いた分離を優先します。

• CLI コマンド: terraform workspace new / select / list / show / delete
• default ワークスペースは特別扱い（多くのバックエンドで key そのままを利用）
• TFC/TFE のワークスペースは state・変数・RBAC・ポリシーの単位
• ワークスペースは state 分離であって、ネットワーク/IAM 分離ではない

環境分離の全体像（権限境界と state 境界）

Org/Company
  ├─ Cloud Accounts/Projects (強い権限境界)
  │    ├─ prod-account
  │    │    └─ TF Backend (prod) ── Workspaces/TFC Workspace(s): [prod]
  │    └─ nonprod-account
  │         └─ TF Backend (nonprod) ── Workspaces/TFC Workspace(s): [dev, stg]
  └─ Repo/Directory (論理構成の分離)
       ├─ envs/prod
       ├─ envs/stg
       └─ envs/dev

CLI ワークスペースの基本操作

terraform workspace list
terraform workspace new dev
terraform workspace select dev
terraform workspace show

環境分離パターンの比較：どれをいつ使うか

現実装では複数の分離レイヤを組み合わせます。下表は代表パターンの比較です。試験でも「どの分離が要件に最適か」を問われます。

本番の誤操作リスクが許容できないなら、まずアカウント/プロジェクト分離と別バックエンドを検討し、ワークスペースは補助的に使うのが安全です。

• 本番は「別アカウント/課金/権限境界」＋「別バックエンド」で守る
• ステージング/開発はワークスペース分離でコストと運用負荷を抑制
• 大きく異なる構成差はディレクトリ/モジュールで表現（フラグ乱用を避ける）

S3 バックエンド例（ワークスペース対応の状態ファイル配置）

terraform {
  backend "s3" {
    bucket         = "example-tfstate"
    key            = "network/terraform.tfstate"   # default ワークスペースはこの key を使用
    region         = "ap-northeast-1"
    dynamodb_table = "tf-lock"
    encrypt        = true
  }
}
# 例：多くのリモートバックエンドでは default 以外のワークスペースは
# env:/<workspace>/network/terraform.tfstate のように名前空間が分かれる実装がある（バックエンド実装依存）。

ワークスペース活用パターン：命名・変数・モジュール設計

命名は一貫性が最重要です。workspace 名は短く、英小文字で dev/stg/prod のように固定。リソース名やタグに terraform.workspace を利用して可観測性を上げます。

変数は tfvars を環境別に分け、CI で -var-file を選択。TFC では Workspace 変数・Variable Set を使い、機密値は VCS に置かない。

モジュールは「環境差」を入力変数に寄せ、条件分岐は最小化。差が大きくなったらディレクトリを分けて構成自体を変えるほうが安全です。

• workspace 名例：dev / stg / prod（他の派生はタグや var で表現）
• tfvars 例：env/dev.tfvars, env/stg.tfvars を CI で選択
• タグ/リソース名に terraform.workspace を付与して追跡容易化
• 機密は環境変数や TFC 変数ストアへ（VCS に置かない）

リソース命名と変数のベストプラクティス

locals {
  common_tags = {
    managed_by = "terraform"
    env        = terraform.workspace
  }
}

resource "aws_s3_bucket" "logs" {
  bucket = "app-logs-${terraform.workspace}"
  tags   = local.common_tags
}

# 例: CI で環境ごとの tfvars を選択
# dev:
#   terraform workspace select dev
#   terraform apply -var-file=env/dev.tfvars
# prod:
#   terraform workspace select prod
#   terraform apply -var-file=env/prod.tfvars

避けたいアンチパターンと落とし穴

ワークスペースは便利ですが、権限境界ではありません。同一アカウント・同一バックエンドで prod と dev を持つ場合、誤った workspace select による誤 apply リスクが残ります。CI では明示的な workspace 検証や保護ブランチを運用してください。

バックエンドやプロバイダ差分をワークスペースだけで吸収しようとすると複雑化します。リージョンやアカウントが異なる場合は provider の alias と明示的な変数で制御し、限界を超えたら構成を分けます。

state の移動は慎重に。workspaces 間の移動は単純な terraform state mv ではありません。pull/push を理解して計画的に行います。

• 誤った workspace での apply を防ぐため、CI で terraform workspace show の検証を入れる
• default ワークスペースは特別。削除不可、命名変更不可
• remote_state 参照は結合度を上げるため最小化（境界越えの依存は注意）
• state の跨ぎ移動は terraform state pull/push を使い、バックアップ必須

workspaces 間で state を移す（例：検証のみ。必ずバックアップすること）

# 元: dev ワークスペース
terraform workspace select dev
terraform state pull > tfstate-dev.json

# 先: prod ワークスペース（同一構成であることを確認）
terraform workspace select prod
terraform state push tfstate-dev.json

# 注: state mv は同一 state 内のアドレス移動。workspaces 間の移動には pull/push を使う。

チーム運用：Terraform Cloud/Enterprise の使いどころ

TFC/TFE では「1 スタック × 1 環境 × 1 ワークスペース」を基本に、prod/stg/dev を個別のワークスペースへ割り当てます。Variable Set で共通値、Workspace 変数で環境固有値を管理し、RBAC とポリシーで保護します。

State ロックや並列制御はプラットフォームが担保します。Run Tasks やポリシーセット（Sentinel/OPA）で本番ガードレールを実装し、誤操作を抑止します。

• 各環境は別 Workspace（例：app-dev, app-stg, app-prod）
• RBAC と保護ブランチで本番はレビュー必須に
• Variable Set で共通化、Workspace 変数で差分化
• ポリシー（Sentinel/OPA）でコスト/タグ/リージョン制約を自動検証

Terraform Cloud backend の基本設定（名前でひも付け）

terraform {
  cloud {
    organization = "acme"
    workspaces {
      name = "app-prod"  # 環境ごとに別 Workspace を作成
    }
  }
}

# もしくは CLI の workspace と組み合わせる場合は、TFC 上も同名の Workspace を用意し、
# CI で terraform workspace select を明示して実行する。

試験対策チェックリストとコマンド暗記ポイント

Associate/Pro で頻出なのは「分離要件に対して適切なパターンを選べるか」「CLI と TFC のワークスペースの違い」「バックエンドとロックの扱い」です。以下を押さえれば得点に直結します。

コマンドや default ワークスペースの挙動（key の扱い）、state の扱い（lock、pull/push）、-var-file の運用は素直に問われます。

• CLI: terraform workspace new/select/list/show/delete
• default は削除不可。多くのバックエンドで default は key をそのまま使用
• ロック: TFC は自動、S3 は DynamoDB テーブルで実現
• -var-file による環境差分、機密は環境変数/TFC 変数で管理
• ワークスペースは権限境界ではない（強い隔離にはアカウント/プロジェクト分離）

短縮チートシート

# 新規ワークスペース
terraform workspace new stg
# 切り替え
terraform workspace select stg
# 実行（変数ファイルを明示）
terraform plan -var-file=env/stg.tfvars
terraform apply -var-file=env/stg.tfvars
# 一覧/表示
terraform workspace list
terraform workspace show

問題で確認

よくある質問