Terraform Output 徹底ガイド: 実行結果の取得と共有（Associate対策と実務）

Terraformのoutputは、構築したリソースの重要な識別子やエンドポイントを外部へ渡す“インターフェース”です。設計を誤ると、値が取れない・漏えいする・パイプラインが壊れるといった事故につながります。

本記事は、outputの定義からCLIでの安全な取得、モジュール間や別スタックへの共有、CI/CDへの受け渡しまでを、Associate試験で問われやすい観点で整理します。

Outputの基本: 役割・定義・注意点

outputはルートモジュール（または子モジュール）が外部へ公開する値です。適用（apply）後に状態ファイル（state）へ保存され、CLIや他のコードから参照できます。plan段階では値が未確定（known after apply）になり得る点に注意します。

sensitive = true を付けると、CLIの標準表示では値がマスクされます。ただしstateに値自体は保存されるため、stateの保護（バックエンドのアクセス制御、暗号化）が前提です。

• 定義場所: ルートや子モジュールの outputs.tf 等に記述
• 主要属性: value（必須）, description（任意）, sensitive（任意）
• 依存関係: value で参照したリソースやモジュールに自動的に依存
• planでは「known after apply」になり得る（apply後に取得が基本）

最小の outputs.tf（機密値を含む例）

output "bucket_name" {
  description = "アプリの成果物を格納するS3バケット名"
  value       = aws_s3_bucket.app_bucket.id
}

output "db_password" {
  description = "DBユーザーの初期パスワード（表示はマスク）"
  value       = random_password.db.result
  sensitive   = true
}

CLIでの取得: terraform output の使い分け

terraform output は適用後の出力値を一覧または個別に取得します。人間が読む場合はそのまま、機械可読にしたい場合は -json、純粋な文字列として取り出したい場合は -raw を使い分けます。

sensitive な出力は通常表示でマスクされます。-json は値を含むJSON（sensitiveフラグ付き）を返すため、自動化では扱いやすい一方で、ログ流出に注意が必要です。-raw は文字列専用で、敏感な出力には使えない（マスクやエラーになる）ことがあります。

• terraform output 出力の一覧（機密はマスク）
• terraform output name 個別の値（機密はマスク）
• terraform output -json 機械可読なJSON（機密値も含むが sensitive: true が付く）
• terraform output -raw name 文字列出力をそのまま（非機密の文字列向け）

Outputの流れ（定義→状態→取得・共有）

代表的な取得コマンド集

# 一覧（機密はマスク）
terraform output

# 個別取得（機密はマスク）
terraform output bucket_name

# 機械可読（機密値も含まれる。ログ取り扱い注意）
terraform output -json | jq '.bucket_name.value'

# 文字列だけをそのまま（非機密の文字列向け）
terraform output -raw bucket_name

# state全体をJSONでパース（outputs以外も加工したいとき）
terraform show -json | jq '.values.outputs'

モジュールの出力と親子連携の設計

子モジュールのoutputは、親モジュールから module.<name>.<output_name> で参照できます。親で再公開（ラップ）して外部インターフェースを安定化させると、内部の実装変更に強くなります。

まとめて返したい場合はオブジェクトやマップをvalueに使うと、取扱いがシンプルになります（出力に明示的な型宣言はありませんが、値としてオブジェクトを渡せます）。

• 子→親→外部の順にインターフェースを設計する
• 値はapply後に確定するため、上位の依存もapply順序に注意
• 名前の衝突や肥大化を避け、意味のある最小限の出力に保つ

子モジュールの出力を親で再公開する例

# child/outputs.tf
output "vpc" {
  description = "VPCの主要属性"
  value = {
    id     = aws_vpc.main.id
    cidr   = aws_vpc.main.cidr_block
    rt_ids = [for r in aws_route_table.this : r.id]
  }
}

# root/main.tf
module "network" {
  source = "./child"
  # ...
}

# root/outputs.tf
output "vpc_id" {
  value       = module.network.vpc.id
  description = "アプリが利用するVPC ID"
}

別スタックへの共有: terraform_remote_state の使い所と注意

別のステートにあるoutputを参照したい場合、data "terraform_remote_state" を使えます。たとえばネットワーク層のVPC IDをアプリ層が読み取る、という分離構成に適します。

ただしスタック間の暗黙的な依存が生まれるため、適用順序の管理（CIでネットワーク→アプリの順に実行）や、参照先ステートへのアクセス権限設定が必須です。強い結合が問題になる場合は、単一リポジトリのルート/子モジュール構成も検討してください。

• backend と config を正しく指定（S3, AzureRM, GCS など）
• 読み取り専用。参照先のstate更新は即時に反映されない場合がある点に留意
• 並列applyでの競合を避けるため、パイプラインで実行順を制御

terraform_remote_state で別ステートの出力を参照

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "tfstate-shared-bucket"
    key    = "envs/prod/network/terraform.tfstate"
    region = "ap-northeast-1"
  }
}

# 参照例（VPC IDを使う）
resource "aws_subnet" "app" {
  vpc_id            = data.terraform_remote_state.network.outputs.vpc_id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a"
}

CI/CDへの受け渡し: JSON出力と安全な共有パターン

自動化では terraform output -json を使い、必要なキーだけを抽出してアーティファクトや環境変数に渡します。ログへの機密値混入を避けるため、マスキング機能や権限の分離を行います。

outputをリソースの入力に直接戻すことはできないため（outputは外部公開用）、ファイル生成はCLIで行うのがシンプルです。-raw が使えない場合は -json と jq で代替します。

• 最小限のキーのみをエクスポートする（必要十分の原則）
• 機密値はセキュアなシークレットストア（Vault等）を優先
• stateバックエンドのアクセス制御・暗号化・バージョニングを有効化

CIのステップ例（JSON→.env/ファイル出力）

# 1) JSONへ保存
terraform output -json > outputs.json

# 2) 必要な値だけ抽出して .env へ（機密はマスク/スキップ推奨）
VPC_ID=$(jq -r '.vpc_id.value' outputs.json)
echo "VPC_ID=$VPC_ID" >> app.env

# 3) 別形式への変換（例：システム設定用）
jq '{service_url: .service_endpoint.value, bucket: .bucket_name.value}' outputs.json > runtime_config.json

Associate試験で狙われるポイントと落とし穴

outputはapply後に取得するのが基本。planでは unknown になり得ます。sensitive=true はCLI出力のマスクであり、stateの暗号化ではありません。-json は機密値も含むため、ログ出力に注意が必要です。

別スタック参照は data.terraform_remote_state が使えますが、推奨はモジュール化による明示的な依存管理です。-raw は文字列専用で、複合型には使えません。

• apply後に terraform output で取得（planでは不十分）
• sensitive は表示を抑制するだけ。state保護が本丸
• -json は自動化向け。-raw は非機密の文字列向け
• 別ステート参照は権限・順序・結合度に注意

known after apply のイメージ

# planの表示例（概念的）
# + output "bucket_name" {
#     value = (known after apply)
#   }
# -> apply後に terraform output で確定値を取得

問題で確認

よくある質問