terraform destroyを安全に使いこなす: 全削除とターゲット指定の実務パターン

terraform destroyは状態を基に依存関係グラフを解体し、管理対象リソースを削除します。便利な一方で、誤用すれば重大な停止につながります。本稿は「安全な削除」と「ターゲット指定の適切な使い方」を、試験と実務の両面で最短で理解できるよう整理しました。

前半で安全確認フローと-targetの注意点、後半でガードレール設定、ワークスペース、失敗時の対処を扱います。記法や挙動はTerraform公式ドキュメントの安定機能に準拠しています。

まず押さえる: destroyの流れと安全確認フロー

terraform destroyは「計画→確認→適用」の3段階を踏みます。計画段階では現在の状態と設定から削除順序を決め、プロバイダに対する削除リクエストの並びを算出します。確認段階では対話プロンプトか-auto-approveの有無で進行が決まります。適用段階で依存関係に沿って削除が実行されます。

安全の基本は、削除前の計画の可視化、ステートのバックアップ、ロックの確認です。加えて、実際に削除される範囲を最小化し、必要に応じてターゲット指定で順序を分割します。

必ず事前に計画を作る: terraform plan -destroy（計画のみ。インフラは変化しない）
ステートをバックアップ: terraform state pull > state-backup.json
リモートバックエンドはロックが既定で有効。-lock=false は原則使わない
データソースはdestroyの対象外。管理対象(resource)のみが削除対象
モジュール配下のアドレス指定は module.name.resource.type[索引] 形式を厳密に

依存関係グラフと削除順序（例）

安全な事前確認とバックアップの定石

terraform workspace show
terraform state pull > state-backup-$(date +%Y%m%d%H%M%S).json
terraform plan -destroy -out=tfplan
terraform show tfplan

-targetの正しい使い方と落とし穴

-targetは計画の探索範囲を限定する高度なオプションです。緊急回避や段階的削除などの例外用途に限るのが公式推奨です。依存元（そのリソースに依存する上位）は計画に含まれず、孤立や一時的な障害を招く恐れがあります。

複数の-targetは併用できます。module経由のリソースやcount/for_each付きのリソースは正確なアドレス指定が必須です。誤って state rm で消すとクラウド側の実体が残り、ドリフトを増やします。

使う前に plan -destroy -target=... で影響範囲を必ず確認
依存元は自動で含まれない。上位から順に段階的に壊す計画を
一時的な運用のみ。恒常的な部分適用の代替にしない
アドレスは module.app.aws_iam_role.this や aws_subnet.public[0] のように正確に
誤った場合は import で取り戻し、再計画してから実施

段階的削除の例（影響を最小化）

# まず関連の高い上位リソースから切り離す
terraform plan -destroy -target=aws_api_gateway_rest_api.main -out=tfplan1
terraform destroy -target=aws_api_gateway_rest_api.main -auto-approve

# 次に実行系を削除
terraform plan -destroy -target=aws_lambda_function.fn -out=tfplan2
terraform destroy -target=aws_lambda_function.fn -auto-approve

# 最後に基盤権限など
terraform destroy -target=aws_iam_role.app -auto-approve

全削除・部分削除・ステート操作の比較

削除アプローチには特性があります。Associate試験では、どの手段がインフラを実際に削除するのか、どの手段が状態のみを変更するのかを識別できることが重要です。

運用ではまず正攻法（全削除の計画→適用）、やむを得ない場合のみターゲット指定、ドリフト解消や重複管理の排除にはimport/state操作を慎重に、という順序が安全です。

試験ポイント: state rm はクラウド実体を削除しない
ターゲット指定は例外的対応で、恒常的な部分運用には不適
手順の前にplanで可視化、後に差分確認

手段	作用範囲	主な利点	リスク/注意
terraform destroy	管理対象すべて	依存関係に沿った安全な順序で一括削除	誤環境での実行リスク。必ずworkspaceとplanを確認
terraform destroy -target=addr	指定アドレス＋必要な依存先	影響を局所化、順序を段階化できる	依存元は含まれず孤立化の恐れ。恒常運用は非推奨
terraform state rm addr	Terraformの状態のみ	誤登録や重複管理の解消に有効	クラウド実体は残る。ドリフトの原因に
クラウドコンソール手動削除	対象リソースのみ（外部操作）	緊急停止や強制力が必要な時に即応	状態がズレる。後でimport/refreshが必要

典型的な全削除の流れ

terraform workspace select staging
terraform plan -destroy -var-file=staging.tfvars -out=tfplan
terraform show tfplan
terraform destroy -auto-approve -var-file=staging.tfvars

ガードレール設計: prevent_destroy と削除安全性の担保

ライフサイクルのprevent_destroyは、該当リソースの削除を計画段階でブロックします。誤操作から要保護リソース（KMSキー、共有VPC、状態保存用S3など）を守る最後の砦になります。-targetや-auto-approveでも回避できません。解除はコードを変更して再計画が必要です。

create_before_destroyでリプレース時のダウンタイムを抑制できます。削除そのものの安全性ではなく、置換の可用性を高めるオプションとして使います。併せてクラウド側の削除保護（例: S3バケットの削除保護、RDS削除保護、IAMポリシー）も有効です。

prevent_destroy: 不可逆なコアリソースに必須
create_before_destroy: 置換時の先行作成で切替を安全に
プロバイダ固有のforce_destroy等は副作用に留意して最終手段として使用
権限設計でdestroyの実行者を限定（最小権限）

保護の基本パターン（例: 重要バケットの保護）

resource "aws_s3_bucket" "state" {
  bucket = "org-terraform-state"
  lifecycle {
    prevent_destroy = true
  }
}

# 置換時の可用性重視の例
resource "aws_lb" "app" {
  # ...
  lifecycle {
    create_before_destroy = true
  }
}

ワークスペース/環境ごとの運用で誤爆を防ぐ

ワークスペースは状態を環境ごとに分離します。destroy前に必ず現在のワークスペースを確認し、環境専用の変数ファイルで設定差分を明示します。バックエンドがリモートの場合、ロックが既定で有効となり並行実行を防ぎます。

CI/CDでは -auto-approve の常用は避け、承認ゲートを入れるのが基本です。API制限や依存関係の都合で時間がかかる場合、-lock-timeout で待機時間を調整します。

実行前に terraform workspace show で環境確認
環境変数・tfvarsで差分を明示、コミット管理でレビュー
リモートバックエンド＋ロックで並行破壊を防止
承認付きパイプラインで -auto-approve の誤用を抑制

ワークスペースと変数の組み合わせ

terraform workspace list
terraform workspace select prod
terraform plan -destroy -var-file=env/prod.tfvars -lock-timeout=5m -out=tfplan
terraform destroy -var-file=env/prod.tfvars

失敗時の対処: 依存、ドリフト、レート制限

依存関係エラーは、上位リソースが残っている、循環参照、プロバイダ制限などが原因です。依存元を先に壊す計画に分解するか、手動で安全に切断してから再実行します。-targetはこの段階的破壊でのみ最小限に使います。

ドリフト（状態と実体の乖離）は、外部変更や過去のstate操作が原因です。まずplanで差分を可視化し、必要ならimportで整合を取り戻してからdestroyします。APIレート制限に当たる場合は -parallelism を下げてリトライ間隔を確保します。

依存元の明示: depends_on と実体の関連（例: アタッチメント）を確認
ドリフトは import で回復してからdestroyが安全
-parallelism を抑えてプロバイダのレート制限を回避
state rm は物理削除ではない。最終手段として慎重に

よくある復旧コマンド

# 依存リソースを先に対象化して段階的に削除
terraform destroy -target=aws_route_table_association.app

# ドリフト解消してから削除
terraform import aws_iam_role.app my-role-arn
terraform plan -destroy

# レート制限の緩和
terraform destroy -parallelism=2

問題で確認

Associate

問題 1

開発環境で、API Gatewayは残したまま特定のLambda関数のみを安全に削除したい。最も適切な手順はどれか。

A. まず terraform plan -destroy -target=aws_lambda_function.fn で計画を確認し、その後 terraform destroy -target=aws_lambda_function.fn を実行する
B. terraform state rm aws_lambda_function.fn を実行してから何もしない
C. AWSコンソールでLambdaを削除し、Terraformの状態は放置する
D. terraform destroy を実行して全て削除し、必要なものは作り直す

正解: A

部分削除は例外的に-targetを用いる。まず plan -destroy -target で影響範囲を可視化し、問題ないことを確認してから targeted destroy を行う。state rm は物理削除にならず、コンソール手動削除はドリフトを招く。全削除は要件を満たさない。

よくある質問

-targetは依存関係をどの範囲まで含みますか？

指定リソースの作成に必要な依存先は計画に含まれる可能性がありますが、依存元（上位でそのリソースに依存しているもの）は含まれません。そのため部分削除では依存元が一時的に壊れる設計でないかを確認する必要があります。

terraform plan -destroy と terraform destroy の違いは？

plan -destroy は削除計画の作成のみで、インフラに変更は加えません。destroy は確認後に実際の削除を適用します。安全な運用では常に plan -destroy → レビュー → destroy の順に進めます。

lifecycle.prevent_destroy で失敗した場合に回避できますか？

回避できません。prevent_destroy は計画段階でブロックするため、-auto-approve や -target でも越えられません。削除が必要な場合はコードから一時的に設定を外し、レビューの上で再計画・適用します。

この記事で学んだ内容を問題で確認しましょう

16,000問以上の問題で実力チェック

無料で問題を解いてみる

この記事の著者

NicheeLab編集部

データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。