Terraformでインフラストラクチャ・ドリフトが発生する原因は何ですか?

ドリフトは、ポータル、CLIコマンド、スクリプトなど、Terraformのパイプラインを経由せずにクラウドリソースへ直接加えられた変更が原因で発生します。

Terraformは、plan実行時にどのようにして構成のドリフトを検出するのですか?

Terraformは、保存されているステートファイルの情報を、プロバイダーAPIを通じて取得した実際のクラウドリソースおよびローカルの構成ファイルと比較します。

Terraformで管理しているAzureリソースを誰かが手動で変更するとどうなりますか?

次回Terraform planを実行した際に差異が検出されます。構成を更新しない限り、Terraformは宣言されたコードに合わせてリソースを元に戻そうとします。

Azure向けTerraformにおけるインフラストラクチャ・ドリフトの防止と修正

Q: Terraformのコードを更新すべきですか、それともAzureポータルでの変更を元に戻すべきですか?

手動変更が緊急のホットフィックスであり、現在では安定稼働に必要な場合は、Terraformの構成を更新してください。許可されていない変更または誤った変更であった場合は、Terraformに元に戻させてください。

By Mirko Peters · 2026-10-28

Terraformとazureでインフラストラクチャ・ドリフトが発生する仕組み、緊急時のポータルでのホットフィックスがステートファイルを壊す理由、そしてドリフトを安全に検出して修正する方法を解説します。

Automatically translated with AI from the original post. Read the English original

インフラストラクチャ・ドリフトは、現代のクラウド環境において最も一般的で危険な、気づきにくい障害の一つです。エンジニアが障害対応の際にAzureポータルで直接手動調整を行うと、その操作によってコードリポジトリとの同期が静かに崩れてしまいます。本ガイドでは、ドリフトがどのように発生するのか、それがステートファイルに与えるリスク、そして本番環境を停止させることなく差異を体系的に検出して修復する方法を解説します。

重要なポイント

インフラストラクチャ・ドリフトは、クラウドの管理コンソールで行われた手動更新が、宣言済みのTerraformコードから乖離したときに発生します。
本番環境で版管理を経由せずに直接行われた緊急のホットフィックスは、後の通常のplan実行時に障害を引き起こす要因を静かに残します。
Terraformのステートファイルは記憶の橋渡し役として機能し、記述された構成、以前のステート、実際のクラウドリソースを比較します。
ドリフトを早期に検出するには、自動化されたplan実行を定期的に行い、文書化されていない手動のポータル変更を厳格に禁止するポリシーが必要です。
ドリフトを解消するには、ライブ環境をコードに合わせて戻すか、構成を現状に合わせて更新するかを判断する必要があります。

インフラストラクチャ・ドリフトとは何か、そしてなぜ発生するのか?

どれほど規律の高いクラウドエンジニアリングチームであっても、いずれはインフラストラクチャ・ドリフトの被害を受けます。ドリフトとは、自動化パイプラインの外でクラウドリソースに加えられた、許可されていない、文書化されていない、または緊急の変更を指します。深夜のインシデントでエンジニアが呼び出される場面を想像してください。プレッシャーの中で、そのエンジニアはAzureの管理コンソールにログインし、自動スケーリングの上限を5インスタンスから10インスタンスに変更して問題を解決し、そのまま業務に戻ります。

問題は、リポジトリにあるバージョン管理された構成ファイルが今でも5と記述していることです。一方、ライブのクラウド環境は10になっています。変更が記録されず、コードも更新されていないため、意図したアーキテクチャと実際の状態との間に大きな乖離が生じます。このギャップは、まったく別の更新のために誰かが定例のTerraform planを実行するまで、数週間にわたって隠れたままになることがあります。そしてある日突然、ターミナルの出力に、Terraformがそのインスタンス数を再び5へ引き下げようとしているという警告が表示されます。

人的要因と運用上のプレッシャー

ドリフトは悪意から生じることはまれで、ほとんどの場合は運用上の緊急性から生まれます。本番環境に障害が起きると、エンジニアは手元で最も速いツールを使ってすぐに被害を食い止めようとします。Azureポータルでのクリック操作によるプロビジョニングは、素早く、目に見え、即座に反映されます。しかし、コードに記録せずにポータルで問題を修正するたびに、後で利息をつけて返済しなければならない技術的負債が積み上がります。

Terraformのステートが差異を特定する仕組み

Terraformがどのようにドリフトを検出するかを理解するには、その記憶の仕組みであるステートファイルを詳しく見る必要があります。Terraformのステートファイルは、クラウドリソースと構成ファイルを対応付ける究極の信頼できる情報源として機能します。コマンドを実行すると、Terraformは単純にファイルをクラウドへ送信するわけではありません。代わりに、3者間の比較を行います。

まず、Terraform は設定ファイルに記述された内容を読み取ります。次に、直近の正常な apply 時にステートファイルへ記録された内容を確認します。3 つ目に、プラグインを介してクラウドプロバイダーの API に問い合わせ、現在のサブスクリプション内に実際に存在するリソースを確認します。これら 3 つの情報が一致しない場合、Terraform は実環境がいつの間にか変化したことを認識します。

無視された警告の危険性

plan の実行中、Terraform は追加、更新、削除を示す詳細な出力を生成します。ドリフトが存在する場合、リソースの変更、さらには完全な置き換えが必要であることを示す警告がよく表示されます。初心者は、リソースの強制的な置き換えに関する警告を見ると慌ててしまいがちです。しかし、この警告はエラーではありません。稼働中のリソースが原形をとどめないほど変化しており、コードに合わせるには削除して再作成する必要があることを、Terraform が知らせているのです。

ドリフトを検出し、防止するためのベストプラクティス

ドリフトの防止には、組織の文化的なガードレールと、自動化された技術的な統制の両方が必要です。ドリフトの検出を手作業のチェックだけに頼っていると、本番環境の障害という痛い目に必ず遭うことになります。チームがクラウド環境を設定どおりに保つために用いている基本的な戦略は、以下のとおりです。

読み取り専用アクセスを徹底する: 人間のユーザーから本番環境への書き込み権限を取り除きます。すべてのインフラストラクチャ変更は、CI/CD パイプラインとプルリクエストのレビューを経由させてください。
自動化された plan の実行をスケジュールする: 継続的インテグレーションのパイプラインを設定し、'terraform plan' コマンドを定期的に実行します。ただし apply はしません。出力を確認し、想定外の変更がないかチェックしてください。
モノリシックなステートファイルを分割する: 大規模な環境は、より小さくモジュール化されたコンポーネントに分割します。ステートファイルが小さければ、ドリフトを切り分け、レビューし、修正しやすくなります。
リモートステートのロックを実装する: 状態ロックを備えた安全なリモートバックエンドをチームで利用し、同時実行によって状態の記録が破損するのを防ぎます。

ドリフトが発生したときの修復方法

インフラストラクチャが設定から逸脱していることがわかったら、戦略的な判断を迫られます。修復の主な方法は 2 つあります。

1 つ目は、Terraform に実環境を上書きさせる方法です。通常の 'terraform apply' を実行すると、コードに記述された状態へ Azure を強制的に戻します。これは、ドリフトが未承認の手動変更や、もう存在すべきでない一時的なデバッグ設定によって生じた場合に取るべき正しい方法です。

2 つ目は、Terraform の設定を現実に合わせて更新する方法です。インシデント対応中に行った手動のホットフィックスが、必要で、安定しており、本番環境にとって有益であったと判断できる場合は、この方法を選びます。コードを新しい状態に合わせて更新すれば、差異が解消され、今後の自動実行でも必要な設定が維持されます。

まとめ

インフラストラクチャのドリフトは、動的なクラウド環境では避けられない課題ですが、チームにとって致命的な事態になるとは限りません。Terraform のステートファイルが変更をどのように追跡するかを理解し、厳格なアクセス制御を実装し、ドリフトの検出を日常的な運用習慣として扱うことで、クラウドアーキテクチャを確実に管理できます。Infrastructure as Code、プロバイダー、ステート管理の基本的な仕組みをさらに詳しく知りたい場合は、エピソード全編を聴いて、専門家の知見をぜひ押さえ、クラウド自動化戦略のレベルアップに役立ててください。

よくある質問

Terraform でインフラストラクチャのドリフトが発生する原因は何ですか？

ドリフトは、ポータル、CLI コマンド、Terraform のパイプラインを経由しないスクリプトなどを使って、クラウドリソースを直接変更することで発生します。

plan の実行時に、Terraform はどのように設定のドリフトを検出しますか？

Terraform は、保存されているステートファイルの記録を、プロバイダー API 経由で取得した実際のクラウドリソースやローカルの設定ファイルと比較します。

Terraform で管理している Azure リソースを誰かが手動で変更した場合はどうなりますか？

次回 plan が実行されると、Terraform は不一致を検出し、設定が更新されていない限り、宣言されたコードに合わせてリソースを元に戻そうとします。

Terraform のコードを更新すべきですか、それとも Azure ポータルでの変更を元に戻すべきですか？

手動での変更が、安定稼働のために必要となった緊急のホットフィックスであった場合は、Terraform の構成を更新してください。許可されていない変更や誤って行われた変更であった場合は、Terraform に元に戻させてください。