Terraform モジュール出力を使いこなす: Associate 向け outputs の実務パターン

Terraform の outputs は、モジュール間で値を受け渡しし、実行後に必要な情報を表示するための公式メカニズムです。Associate レベルでも、宣言方法、参照方法、sensitive の挙動、評価順序の制御あたりが頻出です。

この記事では、実務で壊れにくい outputs 設計と、試験で問われやすい観点をまとめます。バージョン依存の挙動に触れる場合は、現行の安定仕様に限って扱います。

outputs の基本と試験で問われるポイント

output ブロックはモジュール内で計算した値を外に公開します。親モジュールは module.<子>.output_name で参照できます。ルートモジュールの outputs は terraform apply 後に表示され、terraform output コマンドで再表示できます。

output には value（必須）、description（任意）、sensitive（任意）、そして必要に応じて depends_on（評価順序の明示）が指定できます。値は型推論され、複合型（オブジェクトやマップ）も返せます。

• 基本: 子モジュールで output を宣言し、親は module.child.name で参照
• CLI: terraform output、terraform output -json、terraform output -raw
• sensitive=true は画面表示をマスクするが、state には保持されるためバックエンドの保護が必須
• depends_on により出力評価の順序を明示できる（後述）

最小構成の output（子と親）

# 子モジュール: modules/network/outputs.tf
output "vpc_id" {
  value       = aws_vpc.main.id
  description = "作成した VPC の ID"
}

# 親モジュール: main.tf
module "network" {
  source = "./modules/network"
}

output "network_vpc_id" {
  value = module.network.vpc_id
}

モジュール間のデータフローを設計する

複数モジュールを配線する際は、子の outputs を親が受け取り、必要に応じて親でも再出力します。ワークスペース間で値を渡す場合は terraform_remote_state データソースを用いますが、疎結合に留め、契約（スキーマ）を安定させることが重要です。

出力値は apply 完了後に確定します。plan 時点で unknown の値は依存の連鎖により親でも unknown になり得ます。unknown を前提にしても壊れないよう、条件分岐や null 合体などで防御的に設計します。

• 同一構成内の配線: 親 → 子: 入力 variables、子 → 親: outputs
• ワークスペース間連携: data.terraform_remote_state で outputs を読む（権限と暗号化を前提に）
• 契約の安定性: 型・キー名・意味を固定し、破壊的変更は避ける

親モジュールと子モジュールの出力の流れ

親で子の出力を再出力／remote_state で他ワークスペースの出力を参照

# 親で子の出力を参照し、再出力
module "web" { source = "./modules/web" }
module "svc" {
  source = "./modules/service"
  a_id   = module.web.a_id
}

output "alb_dns" {
  value = module.web.alb_dns
}

output "service_url" {
  value = module.svc.service_url
}

# 他ワークスペースの出力を読む（Terraform Cloud/Enterprise の例）
data "terraform_remote_state" "network" {
  backend = "remote"
  config = {
    organization = "acme"
    workspaces = { name = "network-prod" }
  }
}

# 取得した出力の活用例
module "app" {
  source = "./modules/app"
  vpc_id = data.terraform_remote_state.network.outputs.vpc_id
}

型と集合操作で安定した outputs を作る

出力の型を安定させると、親側の参照が壊れにくくなります。特に for_each で複数作成した子モジュールの値を集約する場合、マップやリストの並び順・キーを明確にします。

順序が未定義な集合は sort() や toset()/tolist() で明示化し、オブジェクトは tomap() でキーを固定します。将来のスキーマ拡張を見越し、オブジェクト出力には description で契約を記述しておくと運用が楽です。

• for_each で作成した複数モジュールの出力集約は map かソート済み list で返す
• 並び順が重要な場合は sort()、ユニーク集合は toset()
• オブジェクトはキーの互換性を意識して拡張（新規キーは追加、既存キーは変更しない）

for_each した子モジュールの出力を安定化して返す例

# 子モジュール群（仮）
module "subnet" {
  source = "./modules/subnet"
  for_each = {
    a = { az = "ap-northeast-1a" }
    c = { az = "ap-northeast-1c" }
  }
  az = each.value.az
}

# 並びに依存しない map で返す
output "subnet_ids_by_key" {
  value       = { for k, m in module.subnet : k => m.id }
  description = "キーごとのサブネットID（a/c などの論理名をキーにする）"
}

# 順序が必要ならソートして list で返す
output "subnet_ids_sorted" {
  value       = sort([for k, m in module.subnet : m.id])
  description = "安定ソート済みのサブネットID一覧"
}

# オブジェクトで契約を明示
output "network_contract" {
  value = {
    vpc_id      = module.network.vpc_id
    subnet_ids  = sort([for k, m in module.subnet : m.id])
    region      = var.region
  }
  description = "上位に公開するネットワーク契約（将来はキー追加で拡張）"
}

セキュアな出力: sensitive と state の扱い

sensitive=true を設定すると、CLI 出力や UI 表示で値が伏せられます。ただし Terraform の状態（state）には実値が保持されるため、バックエンドの暗号化、RBAC、最小権限が必須です。機密値は可能な限り出力しない設計が第一で、やむを得ず出力する場合も可視範囲を最小化します。

sensitive は式に伝播します。機密値を含む計算結果は自動的に sensitive になり、必要な場面のみ nonsensitive() で解除します（表示やログへの漏えいに注意）。CLI では terraform output で機密出力は既定で表示されません。自動処理が必要な場合は -json や -raw を安全な実行環境からのみ用います。

• 原則: パスワードやシークレットは outputs に載せない
• 例外時: sensitive=true とバックエンド保護、取得パスの監査を徹底
• nonsensitive() の使用は最小限にし、ログ出力などの副作用を禁止

sensitive と nonsensitive の使い分け

# 子モジュールで機密値を返す必要があるケース
output "db_password" {
  value     = random_password.db.result
  sensitive = true
  description = "DB パスワード（表示はマスク）"
}

# 親で一部だけを再出力（原則は避ける）
output "db_connection_info" {
  value = {
    endpoint = module.db.endpoint
    username = var.db_user
    // パスワードは出さない or どうしても必要なら sensitive=true にする
  }
}

# 機密を含むが公開したい一部の値のみを非機密として再計算
output "public_url" {
  value = nonsensitive(module.web.public_url)
  description = "公開URL（機密を含まない）"
}

depends_on と出力の評価順序を制御する

通常、output の依存関係は value の式から自動解決されます。まれに、副作用的な前提を満たしてから出力を評価したい場合（例: 補助モジュールの完了シグナルを待つ）、output に depends_on を追加して順序を明示できます。

depends_on はリソース作成順を直接変えるためではなく、出力の評価が特定の完了を待つことを保証する用途で使います。

• value で参照しないが、完了を待ちたい対象を depends_on に追加
• apply 出力のタイミングを制御し、チェーン先の自動処理を安定化

出力評価を明示的に遅延させる例

# app と db の完了を待ってから true を出力
output "bootstrap_complete" {
  value      = true
  depends_on = [module.app, module.db]
  description = "主要モジュールの適用完了シグナル"
}

# 別例: シークレットの発行完了を待ってからエンドポイントを表示
output "service_endpoint_ready" {
  value      = module.svc.endpoint
  depends_on = [aws_secretsmanager_secret_version.api_token]
}

リファクタリングと互換性の守り方

出力名の変更や型の変更は親モジュールを破壊します。モジュールの公開インターフェースと考え、命名・型・意味を安定させます。非推奨化は、旧出力をしばらく残し description に Deprecation を明記するのが無難です。

破壊的変更が不可避な場合は新しいメジャーバージョンのタグを切り、CHANGELOG とサンプルの更新、モジュール利用側のマイグレーション手順を提供します。

• 出力名・型は互換性を最優先（変更は最後の手段）
• Deprecated 出力を一定期間併存させ、移行先を明示
• 契約テスト: terraform validate / terraform plan -json をCIで回して破壊検出

非推奨出力を併存させる例

# 旧: base_url は非推奨、新: service_url を使用
output "base_url" {
  value       = module.web.public_url
  description = "[DEPRECATED] 代わりに service_url を使用してください"
}

output "service_url" {
  value       = module.web.public_url
  description = "サービスの公開URL（正式名称）"
}

問題で確認

よくある質問