Terraformのplan・applyエラーを調査・解決する方法｜TF_LOG・Stateロック・ドリフトを実践的に切り分ける

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ Terraform ＞ Terraformのplan・applyエラーを調査・解決する方法｜TF_LOG・Stateロック・ドリフトを実践的に切り分ける

「terraform applyを実行したらエラーで止まった。でも何が原因か分からない」
Terraformを本番運用し始めると、こうした状況に必ず一度は直面します。エラーメッセージは英語で長く、どの行が本当の原因なのか見つけにくい。CI/CDに組み込んでいれば、パイプラインが突然止まって復旧に時間がかかることもあります。

この記事では、Terraformのplan・applyエラーを体系的に調査・解決するための実践手順を解説します。デバッグログ（TF_LOG）の活用、DynamoDBのStateロック解除、ドリフト検出とリカバリ（terraform plan -refresh-only の使い方と解消アプローチ）、よくあるエラーパターンの切り分けまで、実際のコマンド出力を交えて説明します。

この記事のポイント

・TF_LOG=DEBUG 設定だけでAPIレベルのエラー原因を特定できる
・DynamoDB Stateロック詰まりはforce-unlockコマンドで安全に解除できる
・terraform plan -refresh-only でドリフトを診断し、インフラは変更しない
・ドリフト解消は「コード修正・インフラ修正・terraform import」の3択で判断する
・CI/CDに -detailed-exitcode を組み込めばドリフトをexit codeで自動判定できる

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

Terraformのplan・applyエラーを3種類に分類する

Terraformのエラーは大きく3種類に分類できます。この分類を最初に把握しておくと、調査の手順が明確になります。

・クラウドプロバイダーのAPIエラー：権限不足（AccessDenied）、リソース上限超過、リージョン指定ミスなど。AWSとTerraformの通信段階で起きる問題です
・tfstate整合性エラー：ローカルのtfstateと実際のAWSリソースの状態が食い違っている（ドリフト）場合や、Stateロックが残っている場合です
・HCLコードの構文・依存エラー：変数の未定義、リソース間の循環依存、プロバイダーバージョンの不整合など、コード自体に問題がある場合です

エラーメッセージの先頭にある Error: の直後の文言を見て、どの種類かを判断するのが最初のステップです。

調査の優先順位は「APIエラー → tfstate整合性 → HCLコード」の順です。APIエラーから始めると、権限やネットワークの問題が素早く解消できます。

TF_LOGでデバッグログを有効にしてエラーを追う

Terraformには組み込みのデバッグログ機能があります。TF_LOG 環境変数を設定するだけで、APIリクエスト・レスポンスの詳細をすべてコンソールに出力できます。

1. TF_LOGの設定方法（ログレベル別の使い分け）

TF_LOG は以下の5段階で設定できます。

・ERROR：致命的なエラーのみ（デフォルトの挙動に近い）
・WARN：警告を追加表示
・INFO：Terraformの動作フローを確認するのに適する
・DEBUG：APIリクエスト/レスポンスを確認できる。権限エラーの調査に最も使う
・TRACE：内部処理の全ログ（量が多いため、限定した場面で使う）

権限エラーや予期しないAPI動作の調査には DEBUG が適切です。

# TF_LOG を設定して terraform plan を実行する export TF_LOG=DEBUG terraform plan

2. TF_LOG_PATHでログをファイルに保存する

デバッグログはコンソールに大量に出力されるため、ファイルに書き出して後から解析するのが実用的です。

# ログをファイルに書き出す export TF_LOG=DEBUG export TF_LOG_PATH=/tmp/terraform-debug.log terraform plan # エラー行だけを抽出して原因を絞り込む grep -i 'error\|access denied\|unauthorized' /tmp/terraform-debug.log

3. APIエラーと権限問題をログで読む

以下は、IAM権限不足のリソース作成時に実際に出力されたデバッグログの抜粋です（アカウントID・リソース名はマスク済み）。

2026-06-15T14:23:07.441+0900 [DEBUG] provider.terraform-provider-aws_v5.xx: Response body: {"Code":"AccessDenied","Message":"User: arn:aws:iam::XXXXXXXXXXXX:user/terraform-ci is not authorized to perform: ec2:CreateSubnet on resource: arn:aws:ec2:ap-northeast-1::subnet/*"} 2026-06-15T14:23:07.441+0900 [ERROR] provider: Plugin called logger after being closed: logger: error="dial tcp: lookup provider.registry.terraform.io: no such host"

このログから「terraform-ci というIAMユーザーが ec2:CreateSubnet 権限を持っていない」と即座に特定できます。TF_LOGなしの通常エラー出力では「AccessDenied」の一行しか表示されず、どのリソース・どのアクションで失敗したか見えません。

調査後は必ず unset TF_LOG でログ出力を無効にしてください。大量のデバッグログがCI/CDのログに残り続けると、本番の機密情報（API応答）が記録されるリスクがあります。

Stateロックが解除されない時の対処

S3バックエンド＋DynamoDB State Lockingを使用している環境では、terraform apply が途中でプロセス強制終了した場合や、ネットワーク切断が発生した場合に、ロックが残ったままになることがあります。

1. Stateロック詰まりのエラーを確認する

ロックが残っている場合、次の terraform plan や terraform apply を実行すると以下のエラーが出ます。

$ terraform apply Acquiring state lock. This may take a few moments... ╷ │ Error: Error acquiring the state lock │ │ Error message: ConditionalCheckFailedException: The conditional request failed │ Lock Info: │ ID: a8f3c2d1-xxxx-xxxx-xxxx-7b9e43f1a2c4 │ Path: s3://my-tfstate-bucket/env/prod/terraform.tfstate │ Operation: OperationTypePlan │ Who: terraform@ci-runner-02 │ Version: 1.7.5 │ Created: 2026-06-15 03:17:42.831 +0000 UTC │ Info: ╵

エラー内の ID: フィールドが、DynamoDBに残っているロックIDです。このIDを使って手動でロックを解除します。

2. force-unlockコマンドで安全に解除する

# 上記エラーのLock IDを指定して解除する terraform force-unlock a8f3c2d1-xxxx-xxxx-xxxx-7b9e43f1a2c4 # 確認プロンプトが出る。本当にロックされていないか確認してから yes を入力 Do you really want to force-unlock? Terraform will remove the lock on the remote state. This will allow local Terraform commands to modify this state, even though it may still be in use. Only 'yes' will be accepted to confirm. Enter a value: yes Terraform state has been successfully unlocked!

重要な注意点：force-unlock は、他のエンジニアがまさに terraform apply を実行中の場合に使うと、同時実行による状態破損が起きます。「誰も実行していない」ことをチームに確認してから実行してください。CI/CD環境では、パイプラインジョブが終了していることをCI管理画面で確認します。

3. ロックを残さないCI/CDの設計パターン

CI/CDでTerraformを実行する場合、パイプラインのタイムアウトとプロセスキルによってロックが残りやすい構造になっています。以下の設計でリスクを下げられます。

・タイムアウトを長めに設定する：大規模インフラ変更では30分を超えることがある。CI側のジョブタイムアウトをTerraformの想定実行時間より長くする
・ロック取得後の強制終了を防ぐ：シグナルトラップ（trap）でプロセス終了時に terraform force-unlock を自動実行するスクリプトを用意する（ただし実行中の場合を除く）
・DynamoDB TTLを設定する：DynamoDBのロックテーブルにTTL（例:24時間）を設定しておけば、異常終了したロックが自動削除されてオペレーターが気づかないまま放置される事態を防げる

これら3つの設計を事前に組み込んでおくことで、CI/CDパイプラインのロック詰まりによる作業停止リスクを大幅に下げられます。

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、Terraformのエラー調査・Stateロック設計・チーム運用のスキルをハンズオン形式で習得できるセミナーを開催しています。
Terraformマニュアルを無料で受け取る＞＞

ドリフト検出と修正（コンソール手動変更の影響を確認する）

「先週のterraform planではNo changesだったのに、今日実行したら差分が大量に出た」
これはドリフトと呼ばれる状態です。AWSコンソールや他のツールがTerraform管理外でリソースを変更すると、tfstateと実際のリソースの状態が食い違います。

ドリフトが起きる原因は主に3パターンです。

・手動変更：緊急対応でセキュリティグループのルールをAWSコンソールから追加した、インスタンスタイプをCLIで変更したなどが典型例です
・外部自動化：同じAWSアカウントでAutoScaling・Lambda・別のCloudFormationや別のTerraformワークスペースなど、別のツールがリソースを変更したケースです
・AWSサービス側の更新：マネージドサービスが自動でパラメータを追加・変更した、廃止予定の属性が自動更新されたなど、Terraform側では変更していないのにplanに差分が出る現象として現れます

ドリフトが起きた状態で通常の terraform plan を実行すると、「コードとStateの差分」と「Stateと実インフラのドリフト」が混在した計画が表示されます。これが「意図しない変更がplanに出てくる」原因です。ドリフトを正確に把握しないまま terraform apply を実行すると、手動で適切に設定したパラメータが上書きされる危険があります。

terraform plan -refresh-only（Terraform 0.15.4以降）はこの問題を切り分けるためのコマンドです。通常の terraform plan や terraform plan -refresh=false との違いを整理しておきます。

コマンド	リフレッシュ	変更計画の生成	用途
`terraform plan`	実施	生成する（コードとのdiff）	通常のapply前確認
`terraform plan -refresh-only`	実施	stateのみ更新する計画	ドリフト検知・診断
`terraform plan -refresh=false`	スキップ	生成する（stateとのdiff）	リフレッシュを省略して高速化（非推奨）

1. terraform plan -refresh-onlyで現状差分を把握する

terraform plan -refresh-only は、リソースの変更や追加を提案せず、「現在のAWSリソースの状態をtfstateに反映するとどうなるか」だけを表示します。実際のインフラは一切変更しない、診断専用のコマンドです。

例として、TerraformでEC2インスタンスの Environment タグを管理しているとします。コンソールから production から staging に手動変更した場合、次のように差分が表示されます。

$ terraform plan -refresh-only aws_instance.web: Refreshing state... [id=i-0a1b2c3d4e5f67890] Note: Objects have changed outside of Terraform Terraform detected the following changes made outside of Terraform since the last "terraform apply" which may have affected this plan: # aws_instance.web has changed ~ resource "aws_instance" "web" { id = "i-0a1b2c3d4e5f67890" ~ tags = { "Name" = "web-server" ~ "Environment" = "production" -> "staging" } # (28 unchanged attributes hidden) } This is a refresh-only plan, so Terraform will not take any actions to undo these. If you were expecting these changes then you can apply this plan to update the Terraform state to match. Plan: 0 to add, 0 to change, 0 to destroy.

出力のポイントを読み解きます。

・「Terraform detected the following changes made outside of Terraform」：「Terraform管理外で加えられた変更が検出された」という意味です。これがドリフトの宣言文です
・「~」記号が付いたリソース：stateに記録されている値と実際のインフラの値に差異があります。複数のリソースがドリフトしている場合はすべて列挙されます
・「Plan: 0 to add, 0 to change, 0 to destroy.」：-refresh-only なので、インフラへの変更は0件です。stateの更新計画のみが生成されています

ドリフトがない場合は「No changes. Your infrastructure matches the configuration.」が返ります。この場合はtfstateと実インフラが一致しており、ドリフトは発生していません。

セキュリティグループの変更など、対象が複数ある場合はどのリソースにドリフトが発生しているか一覧化できます。

# aws_security_group.web_sg のドリフト例 $ terraform plan -refresh-only # aws_security_group.web_sg will be updated in-place ~ resource "aws_security_group" "web_sg" { ~ description = "managed by Terraform" -> "Temp change for test" id = "sg-0a1b2c3d4e5f67890" # (5 unchanged attributes hidden) } Plan: 0 to add, 0 to change, 0 to destroy.

CI/CDパイプラインでドリフトの有無を自動判定する場合は -detailed-exitcode を使います。終了コードで条件分岐することで、ドリフトの有無をスクリプトから自動判定できます。


# exit code: 0=差分なし, 1=エラー, 2=ドリフトあり
terraform plan -refresh-only -detailed-exitcode
EXITCODE=0
if [  -eq 2 ]; then
  echo "ドリフトを検出しました。調査してください。"
  exit 1
elif [  -eq 1 ]; then
  echo "terraform planがエラーで失敗しました。"
  exit 1
fi
echo "ドリフトなし。環境はクリーンです。"

2. terraform apply -refresh-only でStateを更新する

「手動変更は意図的なものだったので、TerraformコードはあとでStateに合わせて修正したい——そのためにStateだけ先に更新したい」というケースがあります。その場合は terraform apply -refresh-only を実行します。

$ terraform apply -refresh-only aws_instance.web: Refreshing state... [id=i-0a1b2c3d4e5f67890] # （plan出力） Do you want to update the Terraform state? Terraform will update its state file to match the detected changes above. This is not an apply - your infrastructure will not be modified. Enter a value: yes Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

「This is not an apply - your infrastructure will not be modified.」というメッセージに注目してください。apply -refresh-only は実インフラを一切変更しません。Stateファイルだけを更新します。

StateがAWSの実態に合わせて更新されたら、次にコード（.tf）を修正します。これでState・コード・実インフラの3者が一致し、ドリフトが完全に解消されます。

3. 旧コマンド terraform refresh との違い（非推奨の理由）

Terraform 0.15.4以前には terraform refresh という独立したコマンドがありました。現在は非推奨（deprecated）です。

なぜ非推奨になったのでしょうか。terraform refresh は確認なしにStateを即座に書き換えます。「どのような差分をStateに書き込むのか」を事前に確認する手段がないまま実行してしまうリスクがありました。

terraform plan -refresh-only と terraform apply -refresh-only の2ステップに分けたことで、必ず差分を確認してからStateを更新するワークフローが強制されるようになっています。

コマンド	動作	確認ステップ	推奨状況
`terraform refresh`	Stateを即時更新	なし（危険）	非推奨
`terraform plan -refresh-only`	ドリフトを表示するだけ	あり（目視）	推奨
`terraform apply -refresh-only`	確認後にStateを更新	あり（yes/no）	推奨

4. ドリフトを解消する3つのアプローチ

ドリフトが判明したら、状況に応じて3つのアプローチのどれかを選びます。「手動変更が意図したものかどうか」という業務的な判断がポイントです。

アプローチ1：コードを現状に合わせる（意図した変更だった場合）

手動変更が「正しい変更」だった場合は、Terraformコードをその変更内容に合わせて更新します。例えばセキュリティグループに追加したルールが正規の変更だったなら、HCLに ingress ブロックを追加してコードを実態に合わせます。コードを更新後に terraform apply -refresh-only でStateを同期し、その後 terraform plan で差分がないことを確認して完了です。

アプローチ2：インフラをTerraform定義に戻す（誤操作・不正変更の場合）

手動変更が「誤った変更」だった場合は、通常の terraform apply を実行してTerraformのコード定義でインフラを上書きします。applyと同時にStateも更新されるため、apply後に terraform plan で差分がなければ完了です。

アプローチ3：特定属性のドリフトを許容する（AWSが自動変更する属性の場合）

AutoScalingやマネージドサービスなど、AWSが自動でリソースを変更する環境では、特定の属性のドリフトを「許容」する設計が有効です。lifecycle ブロックの ignore_changes に対象属性を指定することで、Terraformがその属性の差分を検出しなくなります。


# コンソール変更の description を Terraform が変更しないよう ignore_changes で吸収する
resource "aws_security_group" "web_sg" {
  name        = "web-sg"
  description = "managed by Terraform"

  lifecycle {
    ignore_changes = [description]
  }
}

ignore_changes を広げすぎると本物のドリフトも無視することになります。対象属性は最小限に限定してください。

手動作成したリソースをTerraform管理下に取り込む場合（terraform import）

Terraform管理外で新規に作成したリソース全体をTerraform管理下に取り込む必要がある場合は terraform import を使います。Terraform 1.5以降では import ブロックをHCLに書いてplanの一部として実行できます。


# import.tf（Terraform 1.5以降の宣言型import）
import {
  to = aws_s3_bucket.manual_bucket
  id = "my-existing-bucket-name"
}

resource "aws_s3_bucket" "manual_bucket" {
  bucket = "my-existing-bucket-name"
}

# importを含むplanで差分確認 $ terraform plan Plan: 1 to import, 0 to add, 0 to change, 0 to destroy. # 問題なければapply $ terraform apply Apply complete! Resources: 1 imported, 0 added, 0 changed, 0 destroyed.

import後は terraform plan を実行して差分がないことを確認します。差分が残っている場合は、コードに書いた属性値がAWSの実際の値と一致していないサインです。

どのアプローチを採るか、インフラの「真実の情報源（Single Source of Truth）」をどこに置くかをチーム全体で明確にすることが、ドリフト管理の鉄則です。

5. CI/CDでドリフトを定期検出する

本番環境でドリフトを早期発見するには、CI/CDに plan -refresh-only を組み込む設計が有効です。GitHub Actionsの例を示します。

# .github/workflows/drift-detect.yml name: Drift Detection on: schedule: - cron: '0 9 * * 1-5' # 平日9時に毎日実行（UTC 0:00 = JST 9:00） jobs: drift-check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Terraform uses: hashicorp/setup-terraform@v3 with: terraform_version: "1.9.x" - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ secrets.AWS_ROLE_ARN }} aws-region: ap-northeast-1 - name: Terraform Init run: terraform init - name: Drift Detection id: drift run: | terraform plan -refresh-only -detailed-exitcode -out=refresh.tfplan echo "exit_code=$?" continue-on-error: true - name: Notify on drift if: steps.drift.outputs.exit_code == '2' run: | echo "::warning::本番環境でTerraformドリフトを検出しました。手動で確認・解消してください。" exit 1

-detailed-exitcode オプションを付けると、差分がある場合の終了コードが 2 になります（変更なしは 0、エラーは 1）。終了コードで条件分岐することで、ドリフトの有無を自動判定できます。

設計上の重要な注意点を3つ挙げます。

・自動解消はしない：ドリフトの自動 apply は危険です。原因を人間が確認してから対応を決めるフローが鉄則です。CIは「検知して通知」に留め、解消は必ず手動で行います
・環境ごとにジョブを分ける：dev・staging・prod でワークスペースを分けている場合は、環境ごとに個別のジョブを設定します。prod は頻度を上げる（例：6時間ごと）などのチューニングも検討してください
・IAM権限の最小化：ドリフト検知用のIAMロールには読み取り系の権限で十分な場面がほとんどです。CI用クレデンシャルは最小権限の原則で必要なAPIアクションだけに絞ります

このワークフローを平日の始業前に回しておけば、前日のコンソール手動変更を翌朝に検出できます。ドリフトは放置すると複合して原因特定が難しくなるため、定期的な自動検出の仕組みを設けることが本番運用の鉄則です。

よくあるplanエラーのパターンと解決策

1. 「Error: Cycle detected」依存関係の循環

リソースAがリソースBを参照し、リソースBもリソースAを参照するような循環依存が発生すると、このエラーが出ます。

│ Error: Cycle: aws_security_group.app_sg, aws_security_group.db_sg

解決策：aws_security_group_rule リソースを使ってセキュリティグループルールを分離することで循環を解消できます。aws_security_group 内の ingress / egress ブロックを削除し、別リソースとして定義します。

2. 「Error: Provider configuration not present」

バックエンド設定が見つからない場合や、terraform init が完了していない状態で plan を実行した場合に発生します。

│ Error: Provider configuration not present │ │ To work with aws_instance.web its original provider configuration at │ provider["registry.terraform.io/hashicorp/aws"] is required, but it has been │ removed. This occurs when a provider configuration is removed while objects │ created by that provider still exist in the state.

解決策：terraform init を再実行します。CI/CD環境ではプロバイダープラグインがキャッシュされていない場合に頻発します。-reconfigure フラグを付けて強制的に再初期化することで解消できます。

# バックエンド設定を含めて再初期化する terraform init -reconfigure

3. 「Error: creating resource already exists」リソース重複エラー

Terraformの管理外で手動作成されたリソースと同じ名前のリソースをTerraformで作ろうとした時に発生します。

│ Error: creating S3 Bucket (my-app-config-bucket): BucketAlreadyExists: │ The requested bucket name is not available. │ status code: 409, request id: XXXXXXXXXXXX

解決策：既存リソースをTerraform管理下に取り込む (terraform import) か、コード側のリソース名を変更して別名で作成します。Terraform 1.5以降では import ブロックをHCLに書いてplanの一部として実行できます。

4. plan -refresh-only でAPIエラーが出る

-refresh-only は管理している全リソースに対してAPIコールを行うため、IAMロールの権限不足やレートリミットが原因になることがあります。エラーメッセージ中の AccessDenied または ThrottlingException を確認してください。権限不足の場合は、Terraformの実行ロールに対象リソースの Describe / List 系権限を追加します。

5. apply -refresh-only 実行後もplanがドリフトを示し続ける

terraform apply -refresh-only でStateを更新した後も、terraform plan で差分が表示される場合があります。これはドリフトとは別の問題で、コードとStateの差分が残っているケースです。

対処手順：terraform plan の出力を精読し、コードに書かれているが実際のインフラに存在しないリソースがないか確認します。terraform state list で管理対象の一覧を確認し、意図せず削除されたリソースがないか調べます。コードが正しければ terraform apply で実際のインフラをコードに合わせます。

# 管理対象のリソース一覧確認 $ terraform state list # 特定リソースの現在のstate確認 $ terraform state show aws_security_group.web_sg

applyが途中で止まった時のリカバリ手順

terraform apply が途中でCTRL+Cや強制終了で止まった場合、Terraformは「途中まで適用した状態」をtfstateに書き込んでいます。この状態からの回復は次の手順で行います。

1. 現在のtfstateを確認する

# 現在 Terraform が管理しているリソースの一覧を表示する terraform state list # S3バックエンドの場合、現在のtfstateをローカルにダウンロードしてバックアップ terraform state pull > /tmp/tfstate-backup-20260708-100711.json

2. Stateロックを確認・解除してから再実行する

applyが強制終了した場合、Stateロックが残っている可能性があります。前述の force-unlock でロックを解除してから、terraform apply を再実行してください。

Terraformは「tfstateにすでに存在するリソース」はスキップして「まだ適用されていないリソース」だけを処理します。途中から再開できる仕組みになっているため、通常は再実行で問題なく完了します。

3. 一部のリソースが壊れた状態になっていた場合

まれに、applyが途中で止まったことで「半壊」したリソースが残る場合があります（RDSのクラスター作成中に止まった等）。この場合は以下の手順を取ります。

・terraform state list で問題のリソースを特定する
・AWSコンソールで当該リソースの実際の状態を確認する
・リソースが中途半端に作成されている場合、AWSコンソールで手動削除してから terraform state rm でtfstateから除外する
・その後 terraform apply で再作成する

本記事のまとめ

Terraformのplan・applyエラー調査で使うコマンドと手順をまとめます。

問題のパターン	使うコマンド・設定
エラーの原因が分からない	`export TF_LOG=DEBUG`
ログが多すぎてファイルに保存したい	`export TF_LOG_PATH=/tmp/terraform-debug.log`
Stateロックが残っている	`terraform force-unlock <LOCK_ID>`
コンソール変更との差分を確認したい	`terraform plan -refresh-only`
CIでドリフト有無をexit codeで自動判定したい	`terraform plan -refresh-only -detailed-exitcode`
ドリフトをStateに反映してコードを後から修正したい	`terraform apply -refresh-only`
applyが途中で止まってしまった	force-unlock後に`terraform apply`を再実行
planで循環依存エラーが出た	`aws_security_group_rule`でルールを分離
initが未完了またはキャッシュが壊れた	`terraform init -reconfigure`
手動作成リソースをTerraform管理に取り込む	`terraform import`（または importブロック）
planを高速化してドリフト検出を省略したい	`terraform plan -refresh=false`

Terraformのエラー調査で最も重要なのは「分類から始める」ことです。APIエラーならTF_LOG、Stateならforce-unlockまたはplan -refresh-only、HCLコードなら構文チェックと依存関係の整理という3ルートに分けるだけで、原因特定の時間が大幅に短縮できます。

ドリフトに関しては plan -refresh-only → 原因判断 → 適切なアプローチ（コード修正・インフラ修正・import）という流れを習慣化し、CI/CDで定期検出する仕組みを設けることが、IaCの冪等性を本番で守り続けるための実践的な設計です。

関連記事もあわせてご覧ください。
・Terraformのtfstate管理とS3バックエンド設定｜チーム運用で壊さないための基礎
・Terraformのstate操作コマンド実践ガイド｜state list・state mv・state rmで既存インフラを安全に管理する方法
・Terraformのlifecycleブロックで本番リソースを誤削除から守る方法

TerraformのIaC設計知識をLinuxマスターの無料マニュアルで体系的に学べます。plan・applyのトラブルシュート・state設計・module化まで、現役エンジニアが現場の実践知識をまとめています。
Terraformマニュアルを無料で受け取る＞＞

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

Linux無料マニュアル（図解60P）名前とメールで30秒登録

この記事を書いた人

宮崎智広（みやざきともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

次のページへ：Terraformのdynamic blockでHCL設定を動的に生成する方法｜繰り返し設定の簡潔化と実務パターン
前のページへ：Terraformのstate操作コマンド実践ガイド｜state list・state mv・state rmで既存インフラを安全に管理する方法
この記事の属するカテゴリ：Terraformへ戻る