terraform applyの本質: 変更の適用と承認フローを安全に設計する

terraform applyは最終的にインフラへ変更を適用するコマンドです。試験ではplanとの関係、承認の入れ方、ロックや並列度などの安全装置がよく問われます。

本稿は、CLI単体とTerraform Cloud/Enterpriseの両方で、変更の確認・承認・適用をどう設計するかを、手順と判断基準に落として解説します。

terraform applyの基本動作と試験で問われやすいポイント

terraform applyは計画と適用を実行します。対話モードでは差分プランを表示し、承認プロンプトにYesで続行します。-auto-approveを付けると承認なしで適用しますが、本番では推奨されません。

安全に承認を挟むには、terraform plan -outでバイナリの計画ファイルを作り、人手レビュー後にterraform apply planfileで適用します。計画ファイルは同一の作業ディレクトリと依存関係（プロバイダ版や変数）を前提とし、長距離・長期間の持ち運びには向きません。

デフォルトで状態はリフレッシュされます（-refresh=falseで抑制可能）。ロックは対応バックエンドで有効化され、-lockと-lock-timeoutで制御できます。並列度は-parallelismで設定します。

• planの終了コード: 0（変更なし）、2（変更あり）、1（エラー）。applyは成功で0、失敗で非0。
• terraform apply -refresh-onlyとplan -refresh-onlyでドリフト検知・状態更新のみを実行可能。
• -input=falseで非対話実行（CI）。変数は-var、-var-file、環境変数や.tfvarsで注入。
• terraform destroyは破壊専用コマンド。apply -destroyも同義だがdestroyの方が意図が明確。

CLIで実現する人手承認フロー（保存プラン駆動）

最小構成の承認フローは、保存プランをアーティファクトにして人手承認を挟む方法が堅実です。レビューはplanのテキスト出力、適用は保存プランで再現性を担保します。

ポイントは、レビュー対象（人が読むテキストのplan出力）と適用対象（機械が読むplanファイル）を分離すること、適用時に状態ロックを有効にすること、作業ツリーやプロバイダ版が一致していることをCIで検証することです。

• 保存プランの生成: terraform plan -out=plan.tfplan -var-file=... -lock-timeout=... -input=false
• レビュー: planテキスト出力をPRに貼る（terraform show -no-color plan.tfplan で整形可能）
• 承認後の適用: terraform apply plan.tfplan（-lockと-lock-timeoutを併用）
• ガード: mainブランチのみapply、タグ付けでリリース、-auto-approveは非使用

CLI保存プランを用いた承認フロー

Terraform Cloud/Enterpriseでの承認フロー設計

Terraform Cloud/Enterprise（TFC/E）はリモート実行と組織的な承認・ポリシーを提供します。VCS連携では、プルリク作成時にスペキュレイティブプラン（適用しない試算）を自動生成し、mainブランチへのマージで本番ワークスペースの計画が走ります。ワークスペース設定でApplyを手動承認にすれば、人のクリックが入るまで適用されません。

SentinelポリシーやRun Tasksでガードレールを実装できます。ハードマンダトリは違反時に実行停止、ソフトマンダトリは警告のうえ手動継続が可能です。コスト見積もり、監査ログ、機密値の保護も併せて利用できます。

• スペキュレイティブプラン: PRでの安全な差分確認（適用なし）
• 手動承認: ワークスペースでApplyに承認ステップを要求
• ポリシー: Sentinel/OPA相当のRun Tasksで組織標準を強制
• 状態・ロック: TFC/Eが一元管理し、競合を防止

競合と安全性: ロック、並列度、再実行の勘所

状態ロックは同時実行による破壊的な競合を防ぎます。S3バックエンドではDynamoDBテーブルを併用してロックを実現します。ConsulやTFC/Eはロックをネイティブ提供します。apply時は-lock=true（既定）で、競合時は-lock-timeoutで待機時間を延ばせます。

並列度は-parallelismで制御します。デフォルトは10前後（環境により既定値あり）。依存の少ない大量リソースを作るときは上げ、レートリミットの厳しいAPIでは下げます。

再実行時は冪等性を前提としつつ、プロバイダの差分判定や外部変更（ドリフト）を考慮します。ドリフトが疑わしいときはplan -refresh-onlyやapply -refresh-onlyでまず状態を実態に合わせるのが無難です。

• S3バックエンドでのロック: DynamoDBテーブルにハッシュキーを設定し有効化
• -lock-timeout=5m などで競合待機を調整
• -parallelism=1 で順次実行（レート制限対策）
• プロバイダ版は固定し、CIでterraform init -lockfile=readonlyを使い差分を検出

よくある落とし穴とトラブルシュート

保存プランの適用失敗: 計画生成後にプロバイダ版や設定、変数が変わると適用に失敗します。同じ作業ディレクトリ・同じ依存で短時間にhandoffする運用に限定しましょう。

-auto-approveの誤用: CIで誤って本番に即時反映しないよう、環境ごとにジョブを分離し、適用ステップには必ず手動承認を入れます。

-targetの乱用: 局所適用は依存グラフの一貫性を壊しがちです。緊急避難以外では使わず、根本原因を修正して全体計画を適用します。

• CIではterraform fmt -check、terraform validate、terraform planの順で早期失敗
• API制限エラーは-parallelism低下とリトライポリシーで緩和
• 状態ロック解除が必要な時は慎重に。強制解除は最終手段

実務テンプレート（安全な適用スクリプト例）

最小限の安全装置を備えたスクリプト例です。保存プランを生成・保存し、レビュー可能なテキストを出力、承認後に同一プランを適用します。S3+DynamoDB等のバックエンドを前提にしています。

環境ごとに変数ファイルとバックエンド設定を分け、適用先はブランチやタグで明示します。

• 非対話実行のため-input=falseを明示
• 失敗時は即時終了、exit codeをCIに伝搬
• 適用時は保存プランを必ず消費し、plan無しの直接applyを禁止

保存プラン駆動の承認・適用テンプレート（bash）

# 初期化（ロックファイルを尊重）
terraform init -lockfile=readonly || exit 1

# 変数と並列度、ロック待機を調整
ENV=prod
TFVARS=env/${ENV}.tfvars
PLAN_OUT=.artifacts/${ENV}.tfplan
mkdir -p .artifacts

# 計画を生成（保存プラン）
terraform plan \
  -var-file="${TFVARS}" \
  -out="${PLAN_OUT}" \
  -lock=true -lock-timeout=5m \
  -parallelism=5 \
  -input=false || exit 1

# レビュー用にテキスト化（PRに添付）
terraform show -no-color "${PLAN_OUT}" > .artifacts/${ENV}.plan.txt || exit 1

# --- ここで人手承認を実施（CIのManualジョブなど） ---

# 承認後に同一プランを適用
terraform apply -input=false -lock=true -lock-timeout=5m "${PLAN_OUT}" || exit 1

echo "Apply finished for ${ENV}"

問題で確認

よくある質問