Terraform Cloud Run Triggersで実現するワークスペース間の依存自動化

複数のワークスペースでネットワーク→プラットフォーム→アプリのように層を分けたとき、上流の変更に気づいて確実に下流を再計画・適用させるのがRun Triggersです。手動運用や外部CIに頼らず、Terraform Cloud内で依存を自動化できます。

ただしRun Triggersは「実行を並べるための仕組み」であり、値の受け渡しは行いません。値はremote stateで参照し、トリガーは実行の起動に専念させるのが基本設計です。

Run Triggersの全体像とユースケース

Run Triggersは、あるワークスペースの実行が適用まで成功したとき、同一組織内の別ワークスペースに自動でRunをキューイングする仕組みです。VCSのコミットやUI操作に依存せず、上流→下流の依存をTerraform Cloudの中で完結できます。

上流から下流へは一対多のファンアウト、複数上流から1つの下流へのファンインも可能です。サイクル（循環依存）は作成時に拒否されます。Run Triggers自体は値を運びません。出力はdata.terraform_remote_stateで参照します。実行モードがlocalのワークスペースにはトリガーしても実行されないため、remote実行が前提です。スペキュレイティブプラン（PRプラン）や計画のみの実行はトリガー対象外です。

• 同一Organization内でのみ利用可能
• 上流の適用成功時に下流を自動キューイング
• データの受け渡しは行わない（remote stateを併用）
• ファンアウト/ファンイン可、循環は不可
• 下流はremote実行必須、local実行は非対応
• スペキュレイティブプランや失敗は発火しない

ワークスペース間の依存連鎖（例）

もっとも小さなtfe_run_triggerの例（Aの成功でBを起動）

provider "tfe" {}

# 既存ワークスペースIDをデータ参照する例（名称->ID解決）
data "tfe_workspace" "a" {
  name         = "network-a"
  organization = var.org
}

data "tfe_workspace" "b" {
  name         = "platform-b"
  organization = var.org
}

resource "tfe_run_trigger" "a_to_b" {
  workspace_id  = data.tfe_workspace.b.id       # 下流
  sourceable_id = data.tfe_workspace.a.id       # 上流
}

出力の受け渡しはremote state、実行の連鎖はRun Triggers

設計の基本は役割分担です。出力（vpc_idやsubnet_idsなど）はremote stateで参照し、Run Triggersは下流のRunを自動で並べるだけに使います。これにより、ヒューマンエラーや手動実行忘れを排しつつ、コード上の依存は明示的に維持できます。

remote backendを使う場合、同一OrganizationであればTerraform Cloudのトークン注入により追加設定なくstateへアクセスできます。機密出力は機密のまま扱われるため、出力設計時に最小限の露出を心がけてください。

• remote stateでのみ値を共有し、変数の直渡しや外部CI経由の環境変数注入は避ける
• 下流はremote stateの参照に失敗しても安全に失敗できるよう、バリデーションを設ける
• Run Triggersは自動起動の一貫性確保に集中させる
• outputsは必要最小限・命名一貫性・型を明示（map/list/number/string）

data.terraform_remote_stateで上流の出力を参照

terraform {
  backend "remote" {
    organization = var.org
    workspaces {
      name = "app-c"
    }
  }
}

data "terraform_remote_state" "network" {
  backend = "remote"
  config = {
    organization = var.org
    workspaces = { name = "network-a" }
  }
}

data "terraform_remote_state" "platform" {
  backend = "remote"
  config = {
    organization = var.org
    workspaces = { name = "platform-b" }
  }
}

module "app" {
  source  = "./modules/app"
  vpc_id  = data.terraform_remote_state.network.outputs.vpc_id
  subnet_ids = data.terraform_remote_state.platform.outputs.subnet_ids
}

設定方法（UI / API / Terraform Provider）と比較

Run Triggersの作成は、Terraform CloudのUI、TFC/TFE API、またはTerraform Provider(tfe)でコード化の3択です。チームで再現性を重視するならtfeプロバイダでtfe_run_triggerリソースを使うのが確実です。UI操作は手早い検証向け、APIは既存の自動化と統合したい場合に有効です。

作成・変更には対象ワークスペースで少なくともMaintainer相当の権限が必要です。下流ワークスペース側にRun Triggerが紐づくため、下流の管理権限を確認してください。

• UI: Workspace → Settings → Run Triggersで上流/下流を関連付け
• API: /workspaces/:id/run-triggersエンドポイントでCRUD
• IaC: tfe_run_triggerで宣言的に管理（推奨）

TerraformでRun Triggersをコード化（UIと同等の設定）

provider "tfe" {}

variable "org" {}

resource "tfe_workspace" "a" {
  name         = "network-a"
  organization = var.org
  execution_mode = "remote"
}

resource "tfe_workspace" "b" {
  name         = "platform-b"
  organization = var.org
  execution_mode = "remote"
}

resource "tfe_run_trigger" "a_to_b" {
  workspace_id  = tfe_workspace.b.id   # 下流
  sourceable_id = tfe_workspace.a.id   # 上流
}

実行ライフサイクルと失敗時の挙動

上流ワークスペースで計画→（必要に応じて承認）→適用が成功すると、下流ワークスペースにRunがキューイングされます。下流でAuto applyを無効にしていれば、計画後に承認待ちとなります。ポリシー（Sentinel/Run Tasks）違反やプラン失敗時は次段に進みません。

複数の上流から1つの下流にトリガーする場合、下流はワークスペースのキュー制御に従い直列で実行されます。並列化はできませんが、冪等な計画を前提にすれば問題になりません。循環依存は作成段階でブロックされます。

• 発火タイミング: 上流の適用が成功したときのみ
• 計画のみ・失敗・取り消しは発火しない
• 下流のAuto apply設定により手動承認の要否が変わる
• ファンイン時は下流で順次実行（同時実行は不可）
• UIのRun詳細でReason=run_triggerを確認可能

下流の自動適用を制御する例（環境ごとの差異）

resource "tfe_workspace" "app_dev" {
  name           = "app-dev"
  organization   = var.org
  execution_mode = "remote"
  auto_apply     = true   # 開発環境は自動適用
}

resource "tfe_workspace" "app_prod" {
  name           = "app-prod"
  organization   = var.org
  execution_mode = "remote"
  auto_apply     = false  # 本番は承認必須
}

セキュリティ、権限、組織境界の注意点

Run Triggersは同一Organization内に限定されます。作成・変更には対象ワークスペースの管理権限（通常はMaintainer以上）が必要です。組織をまたいだ依存は設計段階で分割し、外部連携（通知や承認）など別の統制を検討してください。

remote stateでの値共有は強力ですが、過剰露出に注意します。出力は最小限、可能ならば集約モジュールでラップし、下流からは必要なキーだけを参照します。機密出力は下流でのログや外部通知に出さないよう配慮します。

• 同一Organization内のみでトリガー可能（クロス組織は不可）
• 作成権限: 対象ワークスペースのMaintainer/Admin相当
• remote stateは組織トークンにより安全に参照（必要最小限のoutputs）
• Variable Setsで資格情報を横展開し、出力で渡さない
• 下流はexecution_mode=remoteが必須（localは非対応）

共通資格情報をVariable Setで配布（出力で渡さない）

resource "tfe_variable_set" "shared_creds" {
  name         = "shared-creds"
  organization = var.org
  description  = "Shared provider credentials for all envs"
}

resource "tfe_variable" "aws_access_key" {
  key             = "AWS_ACCESS_KEY_ID"
  value           = var.aws_access_key_id
  sensitive       = true
  category        = "env"
  variable_set_id = tfe_variable_set.shared_creds.id
}

resource "tfe_workspace_variable_set" "attach" {
  variable_set_id = tfe_variable_set.shared_creds.id
  workspace_id    = data.tfe_workspace.app.id
}

試験対策の要点（Pro向け）

Run Triggersは「実行の自動連鎖」、remote stateは「値の参照」という役割分担をまず押さえること。Run Triggersは同一Organization内のみ、上流の適用成功で下流Runをキュー、データは渡さない、下流はremote実行必須。このあたりが頻出ポイントです。

UI/Provider/APIのいずれでも設定できるが、再現性の観点ではtfe_run_triggerが模範解答。下流のAuto applyやポリシーの有無、マルチ上流での直列実行も絡めて設計意図を語れると加点を狙えます。

• Run Triggersは値を渡さない → outputsはremote stateで参照
• 同一Organization内のみ、循環は不可、ファンアウト/ファンインは可
• 発火は上流の適用成功時のみ（計画のみは不可）
• 下流のAuto apply設定とポリシーチェックの関係を説明できること
• IaCでの設定はtfe_run_triggerが第一候補

remote backend定義（試験で見かける最小例）

terraform {
  backend "remote" {
    organization = var.org
    workspaces {
      name = "platform-b"
    }
  }
}

# outputsは上流ワークスペース側で明示的に公開しておく
output "subnet_ids" {
  value = module.network.subnet_ids
  sensitive = false
}

問題で確認

よくある質問