IaC

Terraform state てらふぉーむすてーと

Terraformインフラ管理ステートファイルtfstateIaCHashiCorp

Terraform stateについて教えて

簡単に言うとこんな感じ！

Terraformが「今どんなインフラを作ったか」を覚えておくための”メモ帳”だよ！これがないと次に何を変えればいいか分からなくなっちゃうんだ。設計図（コード）と現実のサーバーをつなぐ大切な記録ファイルってこと！

Terraform stateとは

Terraform state（テラフォームステート） とは、Terraformがインフラの現在の状態を記録・管理するためのデータファイル（terraform.tfstate）のことです。Terraformはコードに書かれた「あるべき姿」と、このステートファイルに記録された「今の姿」を比較することで、「何を追加・変更・削除すべきか」を判断します。

たとえば、AWSにEC2インスタンスを1台作るコードを書いて terraform apply を実行すると、作成されたインスタンスのID・IPアドレス・タグなどの詳細情報がステートファイルに書き込まれます。次回 apply を実行したとき、Terraformはこのステートと最新のコードを照合し、差分だけを適用します。ステートがなければ「すでに作ったかどうか」すら判断できないため、重複作成や削除漏れが発生してしまいます。

ステートファイルはデフォルトではローカルの terraform.tfstate というJSONファイルに保存されますが、チームで使う場合はAWS S3やTerraform Cloudなどのリモートバックエンドに保存して共有するのが一般的です。このステートの管理こそが、Terraformを実運用する上で最も重要なポイントの一つです。

Terraform stateの構造と役割

Terraformの動作はステートを中心に回っています。コード・ステート・実際のインフラの三者関係を理解すると全体像が見えやすくなります。

ステートファイルの主な中身

項目	内容	例
`version`	ステートファイルの形式バージョン	`4`
`terraform_version`	使用したTerraformのバージョン	`1.7.5`
`resources`	管理しているリソースの一覧	EC2・RDS・VPCなど
`instances`	各リソースの詳細属性	インスタンスID・ARNなど
`dependencies`	リソース間の依存関係	セキュリティグループ → EC2 など

ステートに関する主要コマンド

terraform state list          # 管理中リソースの一覧表示
terraform state show <名前>   # 特定リソースの詳細表示
terraform state mv <旧> <新>  # リソース名の変更（コード側変更に追随）
terraform state rm <名前>     # ステートからリソースを除外（実物は消さない）
terraform import <名前> <ID>  # 既存リソースをステートに取り込む

ローカルバックエンド vs リモートバックエンド

個人開発ならローカルでもよいですが、チーム開発ではリモートバックエンドが必須です。

比較項目	ローカルバックエンド	リモートバックエンド
保存場所	ローカルの `terraform.tfstate`	S3・GCS・Terraform Cloud など
チーム共有	❌ できない	✅ できる
同時実行制御（ロック）	❌ なし	✅ あり（DynamoDB など）
暗号化	❌ 平文保存	✅ 暗号化可能
向いているシーン	個人・学習用	本番・チーム開発

リモートバックエンドの代表的な設定例（AWS S3 + DynamoDB）：

terraform {
  backend "s3" {
    bucket         = "my-tfstate-bucket"
    key            = "prod/terraform.tfstate"
    region         = "ap-northeast-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"  # 同時実行ロック用
  }
}

⚠️ ステートファイルの取り扱い注意点

Git管理しない：パスワードやAPIキーが平文で含まれる場合があり、.gitignore に必ず追加する
手動編集しない：JSONを直接書き換えると整合性が崩れる。変更は terraform state コマンド経由で行う
バックアップ必須：S3のバージョニングを有効にするなど、誤削除に備える

歴史と背景

2014年 — HashiCorpがTerraform v0.1をリリース。当初からステートファイルの概念を導入し、宣言的インフラ管理の基盤とした
2016年 — リモートバックエンドの仕組みが整備され、S3・GCSなどへのステート保存が容易になる
2017年 — terraform import コマンドが安定化し、既存インフラをTerraform管理に移行しやすくなった
2019年 — Terraform Cloudがリモートステート管理のマネージドサービスとして一般提供開始
2021年 — Terraform v1.0リリース。ステートファイルの互換性維持が正式に約束される
2023年 — HashiCorpがライセンスをBSL（Business Source License）に変更。コミュニティフォークとして OpenTofu が誕生するが、ステートの仕様・形式は互換を維持

ステートのよくあるトラブルと対処法

ステートロック（State Lock）とは

チームで同時に terraform apply を実行すると、ステートファイルが壊れる危険があります。これを防ぐのがステートロックで、一人が操作中は他の人がapplyできないよう排他制御をかけます。

Error: Error acquiring the state lock
  Lock Info:
    ID: a1b2c3d4-...
    Operation: OperationTypeApply
    Who: user@example.com

このエラーが出たら、前の操作が正常終了していない可能性があります。terraform force-unlock <ロックID> で解除できますが、本当に誰も操作していないことを確認してから実行しましょう。

ステートドリフト（State Drift）とは

コンソールや他のツールでインフラを変更すると、ステートと実態がズレます（これをドリフトと呼びます）。terraform plan で差分が出るので定期的に確認を。terraform refresh（または plan -refresh-only）でステートを実態に合わせて更新できます。

状態	コード	ステート	実インフラ	対処
正常	✅ 定義あり	✅ 記録あり	✅ 存在	—
ドリフト	✅ 定義あり	✅ 記録あり（古い）	⚠️ 変更済み	`terraform refresh`
孤立リソース	❌ 定義なし	❌ 記録なし	✅ 存在	`terraform import`
ゴーストリソース	❌ 定義なし	✅ 記録あり	❌ 存在しない	`terraform state rm`