手動で作ったAWSを無停止でコード化：Terraform import ブロックを活用した安全な既存リソース移行手順

「急に『手動で作った既存のAWS環境を、Terraformでコード管理して』と無茶振りをされて、冷や汗をかいていませんか？」

従来の terraform import コマンドは、State（管理台帳）だけが更新されて手元のコードは手動コピペで再現するという、実務では恐怖を伴う泥臭い作業でした。「失敗して本番環境を壊したらどうしよう……」と生きた心地がしない方も多いはずです。

現在のTerraform（v1.5以降）には、安全で既存リソースを取り込める「 import ブロック」と「コード自動生成機能」が備わっています。

実際に手動のAWSリソースを安全にTerraform化し、実験後の後片付けまでを検証したステップをお伝えします。

読めば、本番環境を1ミリも傷つけることなく、スマートにIaC化を完了させるノウハウがすべて手に入りますよ！

1. なぜ従来の terraform import コマンドは実務で辛かったのか？
2. 【実践】WSL2環境から手動作成したS3バケットをインポートする手順
3. 【注意】plan実行時の「Warning: Config generation is experimental」の真相
4. 【検証完了】terraform apply の実行とStateの確認
5. 【超重要】実験用リソースを削除（destroy）する際の正しい順番と仕組み
6. まとめ：まとめ：IaCを「安全に導入・撤退」できるスキルを強みにしよう
6. まとめ：インフラを「ライフサイクル」として安全に回しきるために

1. なぜ従来の terraform import コマンドは実務で辛かったのか？

State（管理台帳）しか更新されない（コードは手動コピペ）

従来のコマンドを実行しても、同期されるのはTerraformの管理台帳である「Stateファイル」だけでした。つまり、手元の `.tf` ファイル（設定コード）は、実際のAWSのパラメーターを見ながら自分で一からタイポなしでコピペ再現しなければならなかったのです。少しでもコードとStateに差分があると、次回の `plan` でリソースが意図せず「破壊・再作成（Replacement）」されそうになり、毎回冷や汗をかくことになります。

本番環境の「State破壊」という恐怖

実務のインフラ運用において、Stateファイルの直接編集や、手動でのインポート作業は極めてリスクが高い行為です。コマンドの引数を1文字間違えたり、既存のStateを誤って上書き・破損させてしまったりすれば、インフラの管理台帳が実態と完全に乖離し、本番環境のシステム運用そのものが大混乱に陥る恐怖（State破壊）と常に隣り合わせでした。

2. 【実践】WSL2環境から手動作成したS3バケットをインポートする手順

ステップ1：AWSコンソールで検証用のS3バケットを手動作成

ステップ2：WSL2側の main.tf に import ブロックを記述

import {
  to = aws_s3_bucket.test
  id = "import-test-2026"
}

ステップ3：自動生成コマンドを実行する

terraform plan -generate-config-out=s3.tf

出力されたS3の中身、一瞬でバケットが作成されました。感動！！

# __generated__ by Terraform
# Please review these resources and move them into your main configuration files.

# __generated__ by Terraform from "import-test-2026"
resource "aws_s3_bucket" "test" {
  bucket              = "import-test-2026"
  bucket_namespace    = "global"
  bucket_prefix       = null
  force_destroy       = false
  object_lock_enabled = false
  region              = "ap-northeast-1"
  tags                = {}
  tags_all            = {}
}

3. 【注意】plan実行時の「Warning: Config generation is experimental」の真相

plan時に以下ドキッとする警告が出ます。
これはexperimental(実験機能)なのでwaningを出している。正式な機能ではないよーと伝えたいだけなので、機能としては問題はない

Plan: 1 to import, 0 to add, 0 to change, 0 to destroy.
╷
│ Warning: Config generation is experimental
│
│ Generating configuration during import is currently experimental, and the generated configuration format may       
│ change in future versions.
╵

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

4. 【検証完了】terraform apply の実行とStateの確認

terraform applyを実行すると問題なく完了、そしてstateファイルもできていました。

$ terraform apply
aws_s3_bucket.test: Preparing import... [id=import-test-2026]
aws_s3_bucket.test: Refreshing state... [id=import-test-2026]

Terraform will perform the following actions:
--中略--
Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_s3_bucket.test: Importing... [id=import-test-2026]
aws_s3_bucket.test: Import complete [id=import-test-2026]

Apply complete! Resources: 1 imported, 0 added, 0 changed, 0 destroyed.

5. 【超重要】実験用リソースを削除（destroy）する際の正しい順番と仕組み

検証が無事に成功し、不要になったS3バケットなどのリソースを後片付けする際、実行する「順番」を間違えるとAWS上にリソースが取り残されて課金が続く罠があります。

必ず以下の順番を守ってクリーンアップを行ってください。

◯ 正しい順番：コード（.tf）を残した状態で terraform destroy ➔ 成功後にコードファイルを物理削除
✕ 間違った順番：不要になったからと、先に手元の設定ファイル（.tf）を削除してから terraform destroy

なぜコードを先に消してはいけないのか？（State管理のロジック）

Terraformがリソースを削除・管理する裏側では、以下のようなロジックが動いています。

terraform destroy コマンドが叩かれる。
Terraformは、まず手元の「設定ファイル（.tf）」の記述を読み込み、何が管理対象であるかを認識する。
次に、その対象が「State（管理台帳）」にどう記録されているかを突き合わせ、実際のAWSリソースへ削除命令を送る。

もし、先に手元の設定ファイル（.tf）をゴミ箱に捨ててしまうと、Terraformは「おや、コード上には消すべきリソースの定義が何もありませんね」と判断し、No changes（変更なし）として処理を終了してしまいます。

結果として、State（台帳）からはリソースが消えた（あるいは最初から追えない）状態になるにもかかわらず、AWS上には実リソース（S3バケット等）が手動作成された時のようにそのまま残り続け、課金が発生し続けるという最悪の不整合が発生します。

「インポートしたリソースを安全に消すには、コードがある状態で destroy を叩き、AWSから消えたのを見届けてから、最後にファイルを消す」。このライフサイクルの基本原則を、実務でも必ず徹底しましょう。

6. まとめ：まとめ：IaCを「安全に導入・撤退」できるスキルを強みにしよう

6. まとめ：インフラを「ライフサイクル」として安全に回しきるために

今回は、Terraform v1.5以降の強力な新機能である import ブロックを使い、手動で作られたAWSリソースを無停止で安全にコード化する手順を解説しました。

TerraformをはじめとするIaC（Infrastructure as Code）の導入において、私たちはどうしても「新しくインフラを構築する（apply）」ことばかりに目を奪われがちです。しかし、実務における運用の本質は、以下の3つのフェーズをいかに安全に、かつ泥臭いエラーを出さずに回せるかにあります。

構築：クリーンな環境への自動デプロイ
取り込み：過去に手動で作られた「遺産（レガシーリソース）」の安全なインポート
撤退（破棄）：不要になったリソースの、 Stateを不整合にさせない確実なクリーンアップ（destroy）

今回の検証を通して、私たちの使い慣れた WSL2（Windows Subsystem for Linux 2）環境から、AWSへの認証、最新の import ブロックによる自動生成、そしてWarningへの適切な対処から安全な撤退までの一連のライフサイクルが、完全にノーリスクで回せる手順が確立できました。

この「安全に導入し、安全に撤退できる手順」さえ手元にあれば、実務で急に既存環境の移行を任されたとしても、もう怯える必要はありません。ぜひ今回の最小構成での実験データをベースに、実務のインフラ自動化・効率化へ一歩踏み出してみてください！