Terraform の CI/CD: plan/apply の自動化を堅牢に設計する

本稿は、Terraform の plan/apply を CI/CD に組み込み、変更の可視化と安全なデプロイを両立するための実務指針をまとめたものです。

変更計画の固定化、状態のロック、承認ゲート、バージョン固定といった試験で問われやすい要点を、現場で使える形に落とし込んで解説します。

前提とゴール

目的は、Terraform の plan 結果を人が確認できる形で固定し、その同一の計画だけを本番に適用するパイプラインを作ることです。これにより、レビュー後にコードや外部状態が変化しても、適用内容がすり替わらないことを保証します。

想定読者は、クラウドの権限分離やリモートバックエンド運用の基本を理解している中〜上級者です。Terraform のバージョン管理、プロバイダのロックファイル、リモートバックエンドでのロックは、以降の内容の基盤となります。

• Terraform/Provider のバージョンは固定する（.terraform.lock.hcl を VCS にコミット）
• 状態ファイルはリモート管理し、ロックを有効化する（例: S3 + DynamoDB, azurerm, gcs）
• CI は plan を生成・保存、CD は承認後にその plan を apply する

パイプライン設計の原則

plan と apply は必ず別フェーズに分離し、apply は保存済み plan ファイルをそのまま適用します。apply フェーズで plan をやり直さない設計が重要です。

CI 実行環境と CD 実行環境で Terraform とプロバイダのバージョンを合わせます。plan ファイルは Terraform/プロバイダのバージョンや OS に依存するため、同一バージョン前提で運用します。

• 不変性: plan をバイナリ出力（-out）し、その同一ファイルだけを適用する
• 再現性: Terraform/Provider バージョン固定とロックファイルのコミット
• 安全性: -input=false、サービスプリンシパルは最小権限、状態はリモート + ロック
• 可観測性: -detailed-exitcode で変更有無を機械判定、plan をアーティファクト化
• 承認: 人的レビューの後段に apply を配置、環境ごとに権限・並列性を制御

plan/apply 分離の基本パイプライン

参照実装: 最小の CI/CD ステージング

以下は、1) 変更の静的検査、2) 初期化、3) 検証、4) 計画の保存、5) 手動承認、6) 計画の適用、の順に進む最小構成の例です。CI/CD 製品に依存しないよう、シェル手順で表します。

バックエンド設定や可変値（機密情報）は CI のシークレットストアや環境変数から注入し、-input=false で対話を禁止します。

• plan は plan.bin として保存し、ハッシュ化して改ざん検出を行う
• apply は plan.bin を直接指定（terraform apply plan.bin）し、plan を再生成しない
• -detailed-exitcode により、差分がなければ apply ステージをスキップ

CI/CD 参照スクリプト（疑似例）

# CI: 計画の生成
set -euo pipefail

# 1) フォーマットと静的検査
terraform fmt -check -recursive
terraform init \
  -input=false

# 2) バリデーション
terraform validate -no-color

# 3) ワークスペース/環境の選択
# export TF_WORKSPACE=staging
# terraform workspace select "$TF_WORKSPACE" || terraform workspace new "$TF_WORKSPACE"

# 4) 変更計画の作成（詳細終了コードで差分検出）
set +e
terraform plan \
  -out=plan.bin \
  -lock=true \
  -input=false \
  -no-color \
  -detailed-exitcode
rc=$?
set -e

if [ "$rc" -eq 0 ]; then
  echo "差分なし。apply は不要"; exit 0
elif [ "$rc" -eq 2 ]; then
  echo "差分あり。plan.bin を保存して承認待ちへ";
  sha256sum plan.bin > plan.bin.sha256
  # ここで CI のアーティファクトに plan.bin とハッシュを保存
else
  echo "plan 失敗"; exit $rc
fi

# --- 手動承認ゲート（人のレビュー）---

# CD: plan の適用（同一バージョンの Terraform/Provider 前提）
sha256sum -c plan.bin.sha256
terraform init -input=false
terraform apply -input=false -auto-approve plan.bin

環境分離と承認フロー

環境の分離は、ディレクトリ分割（env ディレクトリ単位で状態分離）、ワークスペース（1 つの構成で複数状態）、もしくはリポジトリ分割のいずれかで行います。いずれの場合も状態は物理的に分かれ、apply の並列実行が干渉しないようロックが働く設計が必要です。

レビューと承認は plan の可視化を中心に据えます。レビュー対象は HCL の差分だけでなく、plan のリソース追加・変更・削除の要約です。承認後の apply は、承認時に生成された plan.bin を適用します（apply の直前に plan を再実行しない）。

• ディレクトリ分割: envs/prod, envs/stg などで最も直感的。状態も明確に分割
• ワークスペース: 同一構成でテナント/環境を切り替える運用に適合
• 承認ゲート: 人手承認、RBAC、変更理由の記録、plan アーティファクトのハッシュ検証

状態管理・ロック・並行制御

リモートバックエンドは、状態の一元管理とロックを提供します。S3 + DynamoDB ロック、azurerm、gcs など主要バックエンドはロック機構を備えています。-lock はデフォルトで true ですが、CI/CD では明示しておくと意図が伝わります。

並行制御は二重で行います。第一にバックエンドのロック、第二に CI/CD のキューイング（同一環境の apply を逐次化）です。これにより、並走 apply による状態破損を防ぎます。別環境・別状態間の並列は許容しやすくなります。

• バックエンドは変更しない限り terraform init -migrate-state を不要にする設計にする
• 他状態の出力参照は data "terraform_remote_state" を用い、明示的に依存関係を表現
• ロールバックは Git の revert + 新規 plan/apply の手順で扱う（状態の直接編集は避ける）

運用パターン比較と試験対策ポイント

Terraform の自動化は、大別すると DIY な汎用 CI/CD、Terraform Cloud/Enterprise の VCS 連携、API 駆動の実行に分かれます。選定は、状態管理・ポリシー・承認 UX・コストなどで比較します。

試験観点では、plan の固定化と apply の分離、リモート状態とロック、バージョン固定、最小権限、-detailed-exitcode の意味、そしてポリシー適用（Sentinel など）の位置付けが頻出です。

• plan は人が確認、apply は機械が忠実に実行
• 同一 plan の適用により「レビューしたもの」と「適用されたもの」を一致させる
• Sentinel/OPA などのポリシーは plan 段階または適用前ゲートで評価

問題で確認

よくある質問