Terraformの事故の多くは、コードではなくstate(状態ファイル)の扱いから生まれます。stateとは何か、なぜ機微情報を含むのか、remote backendとlockでどう守るのかを、チーム運用の勘所として整理します。
Terraformを本格的に運用し始めると、必ず突き当たるのがstate(状態ファイル)の扱いです。コードのレビューはできても、stateの設計とロックの運用が曖昧なまま複数人・複数パイプラインで回すと、いつか必ず事故が起きます。この記事では、HashiCorp公式の定義を土台に、SIer・エンタープライズの実務でつまずきやすいポイントを順に整理します。
01stateとは何か — 実世界と構成の「対応表」
HashiCorp公式は、stateの役割を「実世界のリソースを構成にマッピングし、メタデータを追跡し、大規模インフラのパフォーマンスを改善する」と定義しています(State | Terraform)。つまりstateは、あなたが書いた.tfのリソースアドレス(aws_instance.webなど)と、クラウド上に実在するリソースID(i-0abc...)を結びつける対応表です。
Terraformがplanで差分を計算できるのは、この対応表があるからです。stateがなければ、Terraformは「このコードに対応する実物がどれか」を知る手段を失います。裏を返せば、stateが壊れる・食い違うと、Terraformは既存リソースを認識できず、作り直そうとしたり削除しようとしたりします。stateはコードと同格、あるいはそれ以上に守るべき資産だと考えてください。
02なぜstateは機微情報を含むのか
stateはJSONであり、リソースの属性値をそのまま保持します。ここに落とし穴があります。公式も明言している通り、ローカルで開発するとTerraformはstateを平文ファイルに保存し、構成で定義したシークレット値もそこに含まれます(Manage sensitive data | Terraform)。
具体的には、初期DBパスワード、生成されたAPIトークン、TLS秘密鍵、IAMアクセスキーなどが、リソースの属性としてstateに書き込まれます。variableやoutputにsensitive = trueを付けても、それはCLI出力やUIでのマスキングにすぎず、state内には値が残ります。stateファイルは「機微情報の塊」だと前提を置くのが安全です。
- state自体を機微情報として扱い、Gitワークフローから除外する(公式推奨)。
- 値をそもそもstateに残したくない場合は、実行時のみ利用され state/plan に書き込まれない ephemeral values の活用を公式で要確認。
- 保管時暗号化はバックエンド依存。どの方式で暗号化されるかを必ず確認する。
03ローカルstateの危険 — なぜ本番で使ってはいけないか
デフォルトのローカルstate(terraform.tfstate)は、学習や単独検証には便利ですが、チーム運用では致命的です。理由は3つに整理できます。
- 共有できない：手元にしかないため、他メンバーやCIパイプラインが最新stateを参照できません。
- ロックがない：2人が同時に
applyすると、stateの上書き競合でファイルが壊れます。 - 漏洩・消失リスク：平文の機微情報がノートPCやリポジトリに残り、誤ってコミットする事故が起きます。公式も、state locking と安全なアクセス制御を持たない保存先を避けるよう明確に警告しています。
「とりあえずローカルで始めて後で移す」は、移行時にstateマイグレーションという別の作業を生みます。最初からremote backendを前提に設計するのが、結局は最短です。
04remote backend — S3 + ロックの定番構成
remote backendは、stateをリモートに保存し、必要なときだけメモリ上に展開する仕組みです。AWSでの定番はS3バックエンドです。stateをS3に置き、暗号化とロックを組み合わせます(Backend Type: s3 | Terraform)。
ここで押さえるべき最新の重要ポイントがあります。従来はロック用にDynamoDBテーブル(dynamodb_table)を併用する構成が定番でしたが、公式ドキュメントは「DynamoDBベースのロックは非推奨(deprecated)であり、将来のマイナーバージョンで削除される」と明記しています。代わりに、S3のネイティブロック機能であるuse_lockfile = trueが推奨されています。これはS3上に<key>.tflockというロックファイルを作る方式です。
use_lockfileとdynamodb_tableは移行目的で同時併記できます(公式)。いきなり切り替えるのではなく、両方有効な期間を設けて安全に移行してください。バージョン依存のため、採用可否は公式で要確認です。暗号化はencrypt = trueでサーバサイド暗号化を有効化し、鍵管理を厳密にしたい場合はkms_key_idでKMS鍵を指定します。エンタープライズでは、stateバケットへのアクセスを最小権限で絞ることが監査上ほぼ必須です。IAMの実運用についてはマルチアカウント統制の観点も合わせて設計してください。
05state lock — 同時実行から守る最後の砦
state lockは、誰かがapplyしている間、別の実行がstateを触れないようにする仕組みです。これがないと、2つのapplyが同じstateを読み書きし、対応表が半分書き換わった壊れたstateが生まれます。壊れたstateからの復旧は、実務で最も神経を使う作業のひとつです。
特にCI/CD化した環境では、人間の手動applyとパイプラインの自動applyが競合しやすくなります。ロックは「行儀の良い運用ルール」ではなく、機械的に競合を防ぐガードレールです。前述のuse_lockfile(S3ネイティブロック)を有効化し、ロック取得失敗時にジョブが安全に失敗する設計にしておきます。CI/CDでの実行順序やゲートの設計は、IaCのCI/CDパイプライン設計と合わせて考えると全体像が掴めます。
force-unlockは限られた担当者だけが、状況を確認したうえで実行する運用にしてください。安易な強制解除は、実行中のapplyと衝突して事態を悪化させます。06workspaceとstateの分割 — blast radiusを制御する
Terraformには複数のstateを扱う仕組みとしてworkspaceがあります。同一構成コードに対して、開発・検証・本番といった別々のstateを持てます。ただし、workspaceだけで環境分離を完結させるのは、エンタープライズでは推奨しにくい場面が多いです。理由は権限分離とblast radius(影響範囲)にあります。
より重要なのは、stateをどう分割するかという設計です。単一の巨大stateにすべてのリソースを詰め込むと、次の問題が起きます。
- blast radiusが大きい：小さな変更のapplyでも、巨大なstate全体を対象にするため、事故時の影響範囲とロック競合が広がります。
- planが遅い：リソース数に比例して差分計算が重くなります。
- 権限を絞れない：ネットワーク担当とアプリ担当が同じstateを共有すると、最小権限の原則を実装しにくくなります。
実務では、ライフサイクルと責任境界でstateを分けるのが定石です。例えば「ネットワーク基盤」「共有サービス」「各アプリケーション」といった単位で分割し、変更頻度と影響範囲を揃えます。分割した各stateは、後述のterraform_remote_stateデータソースなどで疎に参照します。
07import / move — 既存資産と構成変更に追従する
stateを扱う実務では、コードとstateの対応をあとから直す操作が避けられません。代表的なのがimportとmoveです。
- import：Terraform管理外で作られた既存リソースを、stateに取り込んでコードの管理下に置きます。既存環境をIaC化する移行プロジェクトでは必須の操作です。
- move：リソースのアドレスを変更した際に、実物を壊さずstate上の対応だけを付け替えます。
terraform state mvはコマンドでの操作、movedブロックはコードで宣言する方法です。
公式は、movedブロックを使うと、Terraformはfromで指定した既存オブジェクトをtoの名前へリネームしたうえでplanを作るため、リソースを破棄せずに済むと説明しています(moved block reference | Terraform)。リファクタリング時に「リネームしただけのつもりが、destroy → create の破壊的変更になる」事故を防ぐのがmoveの役割です。
state mvは手元操作で履歴が残りにくいのが難点です。チーム運用では、可能な限りmovedブロックのようにコードとして残る方法を選び、変更の意図をレビュー可能にしてください。stateへの手作業は、レビューされない変更として事故の温床になります。08チーム運用の勘所 — ルールを仕組みに落とす
ここまでの要素を、SIer・エンタープライズのチーム運用として束ねると、次の原則に集約されます。
- stateは機微情報として扱う：暗号化・最小権限・監査ログを前提に、アクセスできる人を絞る。
- 手作業applyを段階的に減らす：CI/CD経由に寄せ、ロックと承認ゲートで直列化する。
- stateは責任境界で分割する：blast radiusを小さく保ち、担当ごとに権限を分離する。
- stateへの直接操作は例外扱い：
force-unlockやコマンドでのstate mvは担当と手順を定め、記録を残す。 - コードとstateのズレ(drift)を検知する：定期的な
planで乖離を早期に把握する。
これらは一度に完璧を目指すものではありません。既存環境の制約に合わせて、リスクの高い箇所から順に「仕組み」に落としていくのが現実的です。私たちEMWは、こうしたstate設計とパイプライン整備を、既存の運用を尊重しながら一緒に組み立てています。過去の導入事例も合わせてご覧ください。
—まとめ
Terraformのstateは、実世界と構成をつなぐ対応表であり、機微情報を含む守るべき資産です。ローカルstateを避け、S3などのremote backendに置き、ロック(現在はS3ネイティブのuse_lockfileが推奨、DynamoDBロックは非推奨)で同時実行を防ぐ。そのうえで、責任境界でstateを分割してblast radiusを制御し、import/moveは可能な限りコードとして残す。この4点を仕組みに落とせば、Terraform運用の事故は大きく減らせます。バージョンや価格に依存する挙動は、必ず公式ドキュメントで最新情報を確認してください。