Terraform Workspaces の使い分け: CLI と Cloud の違いを実務と試験目線で整理

Terraform の “workspace” は同名異義語。CLI では同一コンフィグに対する複数の状態管理、Cloud/Enterprise では実行単位としての独立ワークスペースです。

環境分離や権限設計で選択を誤ると、State 衝突や権限漏れにつながります。この記事では、両者の正しい使い分けを図・比較表・コマンド例で手早く確認します。

用語の整理: CLI と Cloud の “workspace” は別物

CLI の workspace は、同一ディレクトリにある同一 Terraform コンフィグに対して、状態ファイルを切り替える仕組みです。言い換えると、コンフィグは一つ、state が複数です。ローカルまたはバックエンド上で state 名が分かれます。

Terraform Cloud/Enterprise（以下 TFC/E）の workspace は、VCS 連携・変数スコープ・実行履歴・ロール/権限・ポリシー適用などを内包する“実行ユニット”です。各ワークスペースは通常、独立した state と実行パイプラインを持ちます。

• CLI: 同一コンフィグに対する state の切替。環境差分を小規模に扱うときに有効。
• TFC/E: 組織・チーム運用を前提としたフルマネージドな実行単位。VCS トリガーやキューイング、権限と密接。

CLI の workspace 基本操作（ローカル/任意バックエンド共通）

terraform workspace list
terraform workspace new dev
terraform workspace select dev
terraform plan -var-file=vars/dev.tfvars
terraform apply

CLI Workspaces: 使いどころと避けたい誤用

CLI workspace は、ステートを切り替えつつ同一コンフィグを適用したい場面に適しています。例えば軽量な環境分離（dev, test, qa など）が挙動差の少ない構成で成り立つ場合です。

一方で、変数・プロバイダ設定・モジュール構成が大きく異なる環境を CLI workspace だけで吸収するのは危険です。誤ったワークスペースで apply する人的ミスや、複雑化した条件分岐により可読性が落ち、レビュー漏れの温床になります。

• 向いている: 小規模の環境違い、同一リージョン内での名前空間分離、PoC。
• 避けたい: 大規模な環境差分、強い権限制御が必要な本番、リージョン/アカウント跨ぎ。

CLI workspace と backend の state 命名（例: S3 backend）

terraform {
  backend "s3" {
    bucket = "example-tfstate"
    key    = "projectA/terraform.tfstate"   # 実際は workspace 名で分岐されることに注意
    region = "ap-northeast-1"
  }
}
# ワークスペース名をキーに含めるには、backend の機能や規約で設計（例: key に workspace を埋め込む命名規約）

Terraform Cloud/Enterprise Workspaces: 実行とガバナンスの単位

TFC/E の workspace は、VCS ブランチとの連携、変数・機密値のスコープ、プラン・適用キュー、ロール/ポリシー、State 共有・出力の参照（run tasks/DRY 設計）など、実行管理に必要な機能を一式で提供します。

ワークスペース間連携は、変数の共有や出力の参照機能（例: remote state data ソース、TFC/E の統合機能）を用いて安全に行います。手作業で state ファイルを行き来させるような運用は避けます。

• VCS 連携: プッシュで plan、承認で apply といったレビュー導線を統一可能。
• RBAC/Policy: チームごとの権限とガードレールを workspace 単位で適用。

TFC/E への接続例（cloud ブロック、変数は TFC/E 側で管理）

terraform {
  cloud {
    organization = "your-org"
    workspaces {
      name = "projectA-prod"
    }
  }
}
# remote backend でも可。資格試験では、TFC/E workspace が state・実行・権限の単位である点を押さえる。

違いの核心: 変数・実行・ロック・権限（比較表）

日々の運用で効いてくる違いを整理します。特に試験では、CLI と TFC/E の“workspace”の役割混同が頻出です。

以下の表は、設計判断と試験対策の両面で押さえておくべき要点です。

• 試験では“CLI workspace は複数コンフィグを束ねない”が定番出題。
• 実務では“権限・監査が必要なら TFC/E workspace で分離”が基本線。

CLI と TFC/E の workspace と state の関係

実行の違い（CLI は手動、TFC/E はキュー＋承認）

# CLI: 手動で実行
terraform plan
terraform apply

# TFC/E: VCS 連携（例）
# - main ブランチに PR -> Plan 作成
# - 承認者が Apply を承認 -> 実行
# API/手動トリガーも可（詳細は TFC/E の Run キュー挙動に依存）

環境分離戦略: ディレクトリ、CLI workspace、TFC/E workspace の選び方

大きな違いは“何で分けるか”です。差分が大きければディレクトリやリポジトリで分け、権限や監査要件が強ければ TFC/E workspace で分けます。差分が小さく、同一コンフィグで回せるなら CLI workspace で軽量に切り替えます。

リソース命名やバックエンドキーに workspace 名を組み込む命名規約を用意し、誤適用防止のための pre-commit、plan の可視化、approval フローを合わせて設計します。

• 大差分（Region/Account/Provider 設定が大きく異なる）: ディレクトリやモノレポ内で分離、または別リポジトリ。
• 中差分（同一構成だが権限/監査が必要）: TFC/E workspace を環境ごとに分割。
• 小差分（タグやサイズ程度の違い）: CLI workspace と tfvars で切替。

命名規約例（workspace 名を反映）

locals {
  ws = terraform.workspace
}

resource "aws_s3_bucket" "app" {
  bucket = "app-${local.ws}"
  tags = {
    env = local.ws
  }
}
# 注意: terraform.workspace は CLI/TFC/E 双方で有効だが、命名衝突や容量制限を考慮すること

試験対策と運用の落とし穴チェック

Associate/Pro では、“CLI workspace は state 切替の仕組みであり、環境の完全分離や RBAC を担わない”が頻出です。また、“TFC/E workspace は実行・変数・権限の単位で、VCS 連携やキューイングを持つ”点も要暗記です。

実務では、同じ言葉でも意味が異なるため運用フローが混ざりやすいことに注意。CLI と TFC/E を併用する場合も、責任分界（誰が、どこで、どう適用・承認するか）を明示しておきます。

• 誤適用対策: workspace 名の明示、リソース名への埋込、保護ブランチ＋レビュー必須化。
• State 衝突回避: ロック対応 backend と TFC/E のキューを活用。

よく使う確認コマンド

# 現在のワークスペース確認（CLI）
terraform workspace show

# 変数の優先度確認（計画時の -var-file と環境変数）
terraform plan -var-file=vars/prod.tfvars

# TFC/E: 実行は UI/API が中心（CLI は cloud ブロック経由で送信）

問題で確認

よくある質問