terraform state rmで“壊さず外す”——実インフラを管理対象から安全に除外する手順と試験対策

terraform state rmは、リソースをステートから削除してTerraformの管理対象から外すコマンドです。実インフラは削除されませんが、次回のplan/apply挙動には強い影響が出ます。

本稿では、安全な実務手順、典型シナリオ、アドレス指定のコツ、destroy/state mv/moved/importとの違いを押さえ、Terraform公式ドキュメントの前提に沿って解説します。

state rmの正体と使いどころ

terraform state rmは、現在のTerraformステートから指定のリソースインスタンスを削除します。実インフラは破壊されません。結果としてTerraformはそのリソースを「未管理」と見なし、同じアドレスの定義がHCLに残っていれば次回planで“新規作成”として扱います。

主な使いどころは、(1) 既存リソースをTerraform管理から外して手動運用へ移したい、(2) 手動で削除済みのリソースに対するステートのゴミを掃除したい、(3) モジュール再編や命名変更の前段として一時的に外す、などです。命名変更や場所の移動が目的なら、state mvやmovedブロックの方が安全で再現性が高い点に注意します。

• 削除されるのは“ステート上の追跡情報”のみ。クラウド側の実体は残る
• HCL定義が残っていると、次のplan/applyで再作成を試みる（重複作成のリスク）
• アドレスはterraform state listで確認。for_eachキーやインデックスは厳密に指定
• 命名変更・移動は原則movedブロック（Terraform 1.1+）かterraform state mvを優先

基本操作のひな型

terraform state list
# => 管理対象のアドレスを確認

terraform state show aws_s3_bucket.logs
# => 状態詳細を確認

terraform state rm aws_s3_bucket.logs
# => ステートから除外（バケット自体は残る）

安全に“管理対象から外す”ための手順

state rmは強力です。安全に適用するには、事前のバックアップ、影響評価、HCL側の整合性調整が不可欠です。特に、HCL定義が残ったままstate rmすると、次のplanで“作成差分”が出てしまうため、意図しない複製作成につながります。

実務での推奨シーケンスは以下です。バックエンドがロックをサポートしている場合（例: S3+DynamoDBロック、Terraform Cloud/Enterprise）ではロックが自動で効きますが、併走applyを避ける運用を徹底してください。

• 1) ステートのバックアップを取得（terraform state pull > tfstate.bak）
• 2) 対象アドレスを特定（terraform state list / show）
• 3) HCLから当該リソース定義を削除 or 恒久的に外す方針を明確化
• 4) plan -refresh-only で現状同期を確認（apply -refresh-onlyは慎重に）
• 5) terraform state rm で除外
• 6) 通常のterraform planで差分が期待どおり（差分なし/最小）か検証

手順の実行例（Bash）

# 1) ステートのバックアップ
terraform state pull > tfstate-$(date +%F-%H%M%S).bak

# 2) 対象アドレスの特定
terraform state list | grep aws_s3_bucket
terraform state show aws_s3_bucket.logs

# 3) HCLから当該resourceをコメントアウト/削除（VCSでコミット）

# 4) 現状同期（必要に応じて）
terraform plan -refresh-only

# 5) ステートから外す
terraform state rm aws_s3_bucket.logs

# 6) 意図した差分か確認
terraform plan

現場の典型シナリオと対応パターン

手動削除の後始末: 実インフラを手動で削除済みなら、HCLからも該当resourceを削除し、最後にstate rmでステートの残骸を掃除します。HCLを残したままrmすると再作成が走るため目的と矛盾します。

一部リソースのみ手動運用へ移行: HCL定義を削除または条件分岐（count=0等）で作成対象外にしたうえでstate rmします。将来のapplyで再作成が起きないことを確認します。

モジュール再編/命名変更: 原則movedブロックかstate mvを使い、rmは使わない。やむを得ず外す場合は再インポートの計画を立てます。

• moduleやfor_eachのアドレスはterraform state listで都度確認
• workspaceごとにステートは別。rmは現在workspaceにのみ影響
• プロバイダ側の上限（例: 同名作成不可）に注意。重複作成エラーの温床
• 再度管理したくなったらterraform importかmoved/state mvを検討

for_each/モジュール配下の精密アドレス指定

# for_eachキーはクオートが必要
terraform state rm 'aws_subnet.public["public-1a"]'

# モジュール配下の特定インスタンス
terraform state rm 'module.network.aws_subnet.public["public-1a"]'

# 現在のworkspaceを確認
terraform workspace show

落とし穴と副作用を図で理解する

state rmの直後、HCLに同じリソース定義が残っているとTerraformは「ステートに無い=未作成」と判断します。planでは“作成”が提案され、applyで重複作成や命名衝突エラーが発生し得ます。

依存関係は基本的にHCLから再構築されるため、rmで依存の解決が壊れることは稀ですが、出力値や参照元に実体が無いとエラーや未知値拡散の原因になります。

• rmは不可逆に近い操作。バックアップ必須
• 出力や他リソースが参照している場合、planが大きく揺れる
• 遠隔バックエンドではロックの効かない手動編集は禁止（state push/pullでの直編集は非推奨）
• 再管理はterraform importで再アタッチか、moved/state mvで移行

state rm後の世界（概念フロー）

意図せず再作成になる例

# HCLにresource "aws_s3_bucket" "logs"が残ったまま
terraform state rm aws_s3_bucket.logs
terraform plan
# => + create aws_s3_bucket.logs （重複作成/命名衝突の可能性）

アドレス指定と“移動”の正解：state mv / moved / import

アドレスはresource.type.name[インデックス or キー]、モジュール配下はmodule.path.resource...の形式です。誤指定は意図せぬ除外につながるため、必ずterraform state list/showで確認します。

命名変更やモジュール移動が目的の場合、Terraform 1.1以降はmovedブロックによる宣言的な状態移行が推奨です。計画時に旧→新アドレスへステートが自動移行され、再現性が高く、rmのような孤児化を避けられます。

• 移動: movedブロック（推奨・宣言的） or terraform state mv（命令的）
• 外す: terraform state rm（実体は残し、管理だけ外す）
• 再アタッチ: terraform import（既存実体→ステートに取り込み）

movedブロック／state mv／importの書式例

# moved（HCL、Terraform 1.1+）
moved {
  from = aws_s3_bucket.logs
  to   = module.logging.aws_s3_bucket.logs
}

# state mv（CLI）
terraform state mv aws_s3_bucket.logs module.logging.aws_s3_bucket.logs

# 既存を再アタッチ（import）
terraform import aws_s3_bucket.logs my-logs-bucket-name

試験対策：似たコマンドの比較と出題ポイント

Pro試験では「壊さず外す」「名前変更は何を使う」「既存の再アタッチ」の選択肢鑑別が頻出です。state rmは“管理対象から外すだけ”で、destroyは“実体破壊”、state mv/movedは“状態の移動”、importは“既存の取り込み”です。

refresh系はapply -refresh-onlyが現在の推奨。-targetは最小化のための緊急避難であり、恒常運用の推奨ではありません。

• state rmは実体に触らない。HCLが残っていれば再作成に注意
• 命名変更/配置換えはmoved（またはstate mv）を選ぶ
• 既存の採番資産はimportで再アタッチ
• refresh-onlyは状態同期。構成差分は作らない

試験で問われやすいワンライナー

# "壊さず外す":
terraform state rm module.db.aws_db_instance.main

# "名前を変える/場所を変える":
terraform state mv aws_iam_role.app module.iam.aws_iam_role.app
# or HCLのmovedブロックで宣言的に

# "既存を取り込む":
terraform import aws_eip.web eipalloc-1234567890abcdef0

問題で確認

よくある質問