Terraformの-targetで行う部分適用の使いどころと注意点（Associate対策）

Terraformの-targetは特定のリソースやモジュールだけを計画・適用するためのオプションです。便利に見えますが、公式ドキュメントでも日常的利用は非推奨と明言されており、依存関係の取り扱いを誤ると状態の不整合を生む原因になります。

本記事では、-targetの挙動を依存グラフとStateの観点から解説し、現場でどうしても必要な場面に限定して安全側に使うための手順と、より推奨される代替手段をまとめます。Associate試験の出題傾向も踏まえて要点を押さえます。

-targetの基本と公式スタンス

-targetは、アドレス指定したオブジェクト（リソースやモジュール）に関わる部分だけを計画・適用の対象に絞り込みます。対象の依存元（必要な前提）は自動で含めますが、対象に依存する後続は含めません。

HashiCorpの公式ドキュメントでは、-targetは復旧や回避のための例外的な用途に限ることが推奨されています。日常運用で多用すると、依存関係外の更新が置き去りになり、次回フル適用時に意図しない差分が出るリスクがあります。

適用方法はplanにもapplyにも指定できますが、まずplanで差分を確認し、レビュー後に適用するのが安全です。保存した計画ファイルを使う場合、その計画は対象のみに限定された内容になります。

• 使う局面: 失敗する一部リソースの切り分け、外部制約（Quota/配布ウィンドウ）回避、長時間リソースの先行作成など
• 避ける局面: 定常的な段階的デプロイの代替、依存が複雑な変更、広範なスキーマ変更直後
• アドレス例: aws_instance.web[0], module.app, module.db.aws_security_group.sg

基本的な実行例

terraform plan -target=module.app -target=aws_instance.web[0]
terraform apply -target=module.app
# 計画を保存してから適用
terraform plan -target=aws_security_group.web -out=plan.tfplan
terraform apply plan.tfplan

依存グラフと部分適用の挙動を正しく理解する

Terraformは依存グラフに基づいて実行順序を決めます。-targetを指定すると、指定オブジェクトとその依存元だけをグラフから抽出して処理します。依存先（ターゲットに依存する側）は除外されるため、連鎖的な更新は行われません。

そのため、ターゲットのアップデートが依存先の入力に影響する設計の場合、依存先は未更新のまま残ります。これが次回のフル適用で大きな差分や再作成（create-before-destroy等）を誘発する温床になります。

• 依存元は自動的に含まれる（例: DBのパスワードを参照するアプリの-SGをターゲットにすると、パスワードを吐き出すリソースは含まれる場合がある）
• 依存先は含まれない（例: VPCをターゲットにしても、そのVPCにぶら下がるサブネットやルートは対象外）
• データソースは参照時に評価されるが、計画対象外のリソース出力は更新されないことに注意

ターゲット指定時の依存グラフの切り出し

A (vpc)
 \
  B (subnet) --> D (instance)
 /
C (sg)

-target=B の場合:
  含まれる: B と Bが依存する A（必要なら）
  含まれない: Bに依存する D、C（Bが参照しないなら）

依存関係の例（HCL）

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "app" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_instance" "web" {
  subnet_id = aws_subnet.app.id
  # ...
}

# -target=aws_subnet.app は VPC を含むが、aws_instance.web は処理されない

Stateと差分管理の落とし穴

部分適用を繰り返すと、Stateは最新でも、未対象のリソースがクラウド側と乖離している可能性が高まります。次のフルplanで大量の差分が出て、計画レビューが困難になるケースが典型です。

count/for_eachで配列やマップを扱う場合、一部だけ更新するとインデックスの再配置やKey追加が次回フル適用で予期せぬ置換を招くことがあります。ライフサイクルのcreate_before_destroyやignore_changesの設定との相互作用にも注意が必要です。

Outputsやモジュールの出力は、ターゲット外だと古い値のまま参照されることがあります。依存が間接的でも、フル適用で整合させる前提で運用してください。

• 部分適用後は必ずフルplanで差分チェック
• 破壊的変更の温床になりやすいのは: ネットワーク層、IAMポリシーの依存、ストレージのライフサイクル
• 長期的な部分適用の積み重ねは避ける（短期間の回避策にとどめる）

差分の見え方の比較

# 部分適用
terraform plan -target=module.db
terraform apply -target=module.db

# 直後にフルplanで整合性確認
terraform plan  # ここでappやnetworkに差分が出ないか確認

# count/for_eachの変更が絡むときは特に注意
# 例: for_eachの元データに要素追加後、部分適用で一部だけ作成 → フル適用時に再配置が発生することがある

現場での限定的ユースケースと安全な運用手順

公式が想定するのは、トラブル切り分けや外部制約を回避するための一時的措置です。たとえば、特定のリソースでプロバイダのAPI制限に当たって全体が進まない場合、そのリソースを除外して他を先に進める、あるいは逆に必要最小限だけ先に作る、といった用途です。

安全に使うためには、対象の明確化、差分の十分なレビュー、適用後のフルplanチェック、短期間でのフル適用による整合性回復、のサイクルを徹底します。

• 手順のひな形: 1) 影響範囲を図解して対象と依存元を確認 2) terraform plan -target=... を複数回指定して差分を精査 3) 必要に応じて段階的に適用（小さく刻む） 4) 直後に terraform plan（フル）で不整合を確認 5) 合意が取れたら短期間でフル適用して収束させる
• 実運用上のヒント: ターゲットには具体的なリソースアドレスを使い、ワイルドカード的な広い指定は避ける
• 長時間作成のリソース（例: RDS、GKE）の先行作成に使う場合でも、後続の依存更新を放置しない

複数ターゲットの指定と段階的適用

# 依存順にターゲットを刻む（例）
terraform plan  -target=aws_vpc.main -target=aws_subnet.app
terraform apply -target=aws_vpc.main -target=aws_subnet.app

# 先行作成後にアプリ層
terraform plan  -target=module.app
terraform apply -target=module.app

# 必ず最後にフルplan
terraform plan

代替手段とベストプラクティス

多くのケースで、-targetより安全な手段があります。特定オブジェクトの置換には -replace、状態のみ最新化したいなら -refresh-only、構成を分割してBlast Radiusを小さくするならスタック分割（ワークスペースやレポ分割）を検討します。

また、構成変更時はmovedブロックでリネームを明示し、ignore_changesで一時的なドリフトを許容するなど、計画を安定させる手当ても有効です。部分適用を使った後は、短期間で必ずフル適用して収束させる、という運用ルールを決めておくと事故が減ります。

• 特定リソースの再作成: terraform apply -replace=aws_instance.web[0]
• 最新状態の取得のみ: terraform plan -refresh-only → 問題なければ terraform apply -refresh-only
• Blast Radius低減: ステート分割・ワークスペース活用・モジュール境界の見直し

代替手段の具体例

# 置換が目的なら -replace を優先
terraform plan  -replace=aws_instance.web[0]
terraform apply -replace=aws_instance.web[0]

# 状態だけ最新化して影響を見たい場合
terraform plan  -refresh-only
terraform apply -refresh-only

# リソース名の変更や移動は moved ブロックで明示
moved {
  from = aws_security_group.old
  to   = aws_security_group.new
}

Associate試験の観点で押さえる要点

出題では、-targetの性質（例外的な利用、依存元のみ含まれる、依存先は含まれない）とリスク認識が問われやすいです。日常的な運用として推奨されるかどうか、代替手段の選択も判断ポイントになります。

また、アドレス指定の粒度（リソース、モジュール、インスタンスインデックス）、計画ファイルに反映される範囲、適用後のフルplanの重要性など、現場での運用手順と結び付けて覚えておくと選択肢で迷いにくくなります。

• ターゲットは例外的に使う。定常運用の第一選択肢ではない
• 依存グラフ: 依存元は含む、依存先は含まない
• 代替: 置換は -replace、状態同期は -refresh-only、構成分割でBlast Radius低減
• 部分適用後は必ずフルplanで整合確認
• アドレス指定は正確に（module.foo, aws_xxx.res[0] など）

試験で混同しやすいコマンド例の整理

# 部分適用（例外的）
terraform plan  -target=module.app
terraform apply -target=module.app

# 置換（推奨される明示的な再作成）
terraform apply -replace=aws_db_instance.main

# 状態のみ反映
terraform plan  -refresh-only

問題で確認

よくある質問