Terraform ignore_changesでドリフトを賢く扱う：設計と試験対策

Terraform は「構成（HCL）」「状態（state）」「実インフラ（remote）」の差分から計画を導きます。ignore_changes はこの差分評価を一部抑制し、外部変更を受け入れるための安全弁です。

ただし乱用はドリフトの見落としを招きます。本稿では公式の挙動に沿って、使いどころ／使わないほうがよい場面、代替手段との比較、試験での落とし穴を短く実用的にまとめます。

ignore_changesの基礎：何を、いつ、どう“無視”するのか

lifecycle.ignore_changes は、指定した属性に関する差分を計画から除外します。対象属性が外部で変更されても、Terraform はそれを元に戻そうとせず、次回の refresh で状態だけは最新の実インフラ値へ更新します。

重要な前提は作成時と作成後で挙動が異なることです。初回作成時は設定値（もしくはプロバイダー既定値）が使われ、ignore_changes は適用後の更新段階から効き始めます。以降、設定ファイル側でその属性を変更しても、計画は発生しません。

置換（force new）が必要な別の変更が発生した場合は、リソースが再作成され、その際は ignore_changes の対象でも構成ファイル上の値（あるいは既定値）が新しいリソースに適用されます。

• 対象はリソースの属性のみ（データソースやモジュール直下には適用不可）
• map（例: tags）を指定すると、その属性全体の差分が無視される（個別キー単位の指定は一般に不可）
• 状態は refresh で実インフラ値に更新されるが、計画は発生しないため“静かに”ドリフトを受け入れる
• 試験観点：module ブロックには lifecycle を書けない、初回作成には ignore_changes は効かない

最小例：特定属性の差分を抑制する

resource "aws_instance" "web" {
  ami           = var.ami
  instance_type = var.instance_type
  tags = {
    Name   = "web"
    Owner  = var.owner
  }
  lifecycle {
    ignore_changes = [tags]  # 外部システムがタグを追記しても計画に出さない
  }
}

挙動の詳細：作成時／更新時／ドリフト時の時系列

Terraform の計画は「構成 → 状態 ←→ 実インフラ」を同期させる過程で生まれます。ignore_changes は、対象属性の差分が見えても“計画に載せない”フィルターとして作用します。以下の流れを押さえましょう。

1) 初回 apply では設定値で作成。2) 運用中に外部で対象属性が変更される。3) 次回 plan 時に refresh で状態は外部値へ更新されるが、対象属性に関する差分は計画に現れない。4) 別属性の変更で置換がかかった場合、新規作成時は設定値（または既定値）が用いられる。

• ドリフトは“見える（state には反映される）が、直さない（plan は沈黙する）”
• 置換時は ignore_changes でも設定値が再び効く点に注意
• 計画に出ない＝監査が難しくなる。外部での変更を別経路で可視化しておく

差分評価における ignore_changes の位置付け

   [Configuration]
          |
          v
       diff calc  ---->  [Filter: ignore_changes on attributes]
          |                           |
          |                           v
   [Current State]  <---- refresh ---- [Remote]
          |
          v
        [Plan]  (ignored attributes: no-op)

挙動の確認：plan は静か、state は変わる

# 外部で tags に変更があっても
terraform plan
# => No changes. (ignore_changes 対象のため計画なし)

# 状態は refresh で外部値へ更新される
terraform plan -refresh-only
terraform apply -refresh-only  # 状態のみ更新、リソース変更なし

使いどころとアンチパターン

ignore_changes は“共存”が必要な箇所に限定して使います。タグ／ラベルの自動付与、外部コントローラが触るフィールド、プロバイダーが都度計算する値などが典型です。一方、セキュリティやネットワーク制御など、Terraform による一貫管理が求められる領域での使用は避けるべきです。

試験では、どの属性が“外部で上書きされうる”か、また“完全管理すべきか”の見極めが問われます。

• 向いている: 企業共通タグの自動付与、CI/CD が埋めるバージョン識別子、外部監視ツールが追記するメタデータ
• 避ける: セキュリティグループ/ファイアウォールルール、IAM ポリシー、暗号鍵や秘匿値、ルーティング、コストに直結するサイズ系パラメータ
• map 全体の無視は強力だが粗い。必要最小限の属性に留める
• module 側に閉じ込める設計（モジュール内部でのみ ignore_changes を使用）でスコープを限定

部分的に管理したい map の例（タグ/ラベル）

resource "google_compute_instance" "app" {
  name         = "app-1"
  machine_type = "e2-medium"
  # ... 他の必須属性 ...
  labels = {
    owner = var.owner
    role  = "app"
  }
  lifecycle {
    ignore_changes = [labels] # 外部の自動ラベリングと競合しない
  }
}

代替アプローチとの比較：いつ ignore_changes を選ぶか

ドリフトを“受け入れる”“検知だけする”“是正する” のいずれを狙うかで手段は変わります。試験では目的と作用範囲の違いを問われます。以下の表で使い分けを整理します。

• refresh-only は“状態を最新化するだけ”。実インフラは触らない
• import は“既存の外部資産を管理下へ”。ignore_changes で一部だけ受け入れる設計も可
• taint/-replace は“意図的に置換”。ドリフト是正や既知不良の解消に使う

CLI 例：状態だけ更新／置換を強制

# 状態のみ最新化（実インフラ不変）
terraform plan -refresh-only
terraform apply -refresh-only

# 置換を強制（ドリフトを包括的に是正）
terraform plan -replace=aws_instance.web
terraform apply -replace=aws_instance.web

実務パターン：最小限スコープでの適用とテスト

ignore_changes は“局所化”が肝心です。モジュール内部だけで使い、外部公開する変数でコントロールしないと、呼び出し側でドリフトが不可視になります。また、CI では refresh-only を併用して、状態がどの程度外部で変化しているかを定期的に把握します。

初回作成時にだけ値を流し込み、その後は外部任せにするケースでは、apply 後に外部が上書きするまでの時間差を考慮して、計画の安定性をテストします。

• モジュール内でのみ使用し、使用理由をコメントで明記
• map 全体ではなく、まずは対象リソースを分割する設計も検討（タグ専用リソースなどがある場合）
• CI に plan -refresh-only を組み込み、状態変化の可視化レポートを残す

モジュール内の最小化例（AWS: ELB が追記する属性を許容）

resource "aws_lb_target_group" "api" {
  name     = "api-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = var.vpc_id

  # ヘルスチェックの一部は ALB 側で調整されうる
  health_check {
    path = "/healthz"
  }

  lifecycle {
    ignore_changes = [health_check] # 外部調整を許容（必要最小限に）
  }
}

運用と試験での落とし穴チェックリスト

ドリフト受け入れは監査の難易度を上げます。誰が・いつ・何を変えたかは Terraform 以外の仕組み（クラウド監査ログ等）で補完してください。試験では、どのレイヤで制御すべきかの“境界線”を問う設問が多いです。

また、ignore_changes は万能ではありません。プロバイダーが内部で常に再計算する読取専用属性については、そもそも計画に出ないため指定不要です。

• module 直下に lifecycle は書けない（リソースブロック内のみ）
• 初回作成には効かない。適用後の更新から有効
• 置換が発生した場合、新リソースには構成値（または既定値）が再適用される
• 監査要件が厳しい場合は refresh-only レポートやクラウド監査ログと併用

状態の確認と差分の健全性チェック

# 状態の単体確認
terraform state show aws_instance.web

# 設定変更が他属性に波及していないかを確認
terraform plan -detailed-exitcode
# exit code 0: 変更なし / 2: 変更あり（ignore_changes 以外の差分に注意）

問題で確認

よくある質問