Terraformのライセンス変更以降、OpenTofuへ移行したいという相談は確実に増えています。とはいえ現場の本音は「理屈は分かるが、stateが壊れたら終わる」「本番を止めずに移行できるのか不安」です。

結論から言うと、移行は十分可能です。ただし「CLIを置き換えるだけ」で済むケースは限定的で、実際は providerバージョン整合・state lock・CI/CD・運用Runbook までまとめて整える必要があります。

本記事では、既にTerraformを本番運用しているチーム向けに、OpenTofuへ段階移行する実践手順をまとめます。

1. 移行方針を先に決める

最初に決めるべきは「一気に切り替えるか」「ワークスペース単位で段階移行するか」です。実務では次の方針が安全です。

1. 低リスク環境（dev/sandbox）から先行
2. 本番は最終フェーズで移行
3. 旧TerraformとOpenTofuを一定期間並行運用
4. ロールバック手順を文書化してから実施

この順序を守るだけで、移行事故の大半を避けられます。

2. 互換性の棚卸し（最重要）

まずは現状のIaC資産を棚卸しします。

• Terraformバージョン（例: 1.5.x / 1.6.x）
• 使用provider（AWS/Azure/GCP/Kubernetes等）
• backend（S3 + DynamoDB lock、Terraform Cloud、GCSなど）
• moduleの参照方式（registry / git / local）
• CI実行環境（GitHub Actions, GitLab CI, Jenkins）

2.1 依存を固定化してから移行する

.terraform.lock.hcl を必ずコミットし、providerを固定します。移行時にproviderまで同時更新すると、差分原因の切り分けが困難になります。

1
2
3
4
5
6
7
8
9

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.40"
    }
  }
}

移行フェーズでは「ツール差分」と「provider差分」を分離してください。

3. ローカル検証の基本手順

OpenTofuを導入したら、既存プロジェクトで次を実行します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 現状確認
terraform version

# OpenTofu側確認
tofu version

# 初期化（既存backendを利用）
tofu init -upgrade=false

# 差分確認
 tofu plan -out=tfplan

plan が完全一致しない場合、いきなり適用してはいけません。主な原因は以下です。

• providerの暗黙更新
• data sourceの評価タイミング差
• 標準関数・型変換の微差
• module内部のversion制約

差分は「構文差分」より「実行時評価差分」で出ることが多い点に注意してください。

4. Stateを守る設計（壊したら復旧が重い）

IaC移行の本質的リスクはstateです。ここを守るために、以下を移行前チェックリストに組み込みます。

• state backendのバックアップ取得
• lock機構が有効か確認（DynamoDB等）
• apply 権限を移行担当者に限定
• 並列実行ジョブを停止（同時apply禁止）

4.1 S3 backendの例

1
2
3
4
5
6
7
8
9

terraform {
  backend "s3" {
    bucket         = "prod-iac-state"
    key            = "network/prod.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

OpenTofuでもこのbackend構成は継続利用できます。重要なのは「誰がいつlockするか」を運用で統制することです。

5. CI/CDをOpenTofu対応に置換

CLI切替はローカルだけでは不十分です。実運用ではCIがapply主体です。

5.1 GitHub Actions移行例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

name: iac-plan
on:
  pull_request:
    paths:
      - "infra/**"

jobs:
  plan:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: infra
    steps:
      - uses: actions/checkout@v4
      - uses: opentofu/setup-opentofu@v1
        with:
          tofu_version: 1.8.5
      - run: tofu init -input=false
      - run: tofu validate
      - run: tofu plan -input=false -no-color

ポイントは、tofu_version を固定し、突然のツール更新を防ぐことです。

5.2 Planの品質ゲート

• tofu fmt -check
• tofu validate
• tflint
• checkov や tfsec によるセキュリティ検査

この4点をPRゲート化すると、移行直後の品質低下を防げます。

6. 段階移行の実践フロー

本番で安全に移行するなら、次の順番が現実的です。

1. dev workspaceをOpenTofuに切替
2. 1週間運用し、差分・事故を記録
3. stg workspaceを切替
4. 本番はメンテウィンドウで切替
5. 切替後48時間は変更凍結（緊急以外apply禁止）

移行で一番危険なのは「切替当日に通常の機能変更を混ぜる」ことです。必ず分離してください。

7. よくある障害と対策

7.1 plan 差分が毎回揺れる

原因:

• data sourceに非決定的値（timestamp等）が混在
• providerバージョン不統一

対策:

• 変動値をlocalsに隔離
• provider lockを全環境で統一

7.2 import済み資源が再作成扱いになる

原因:

• module path変更
• resource address変更（count→for_each）

対策:

• moved ブロックを使い論理移動を明示
• 必要時のみ state mv を計画的に実施

7.3 lock解放漏れでapplyが詰まる

原因:

• CI異常終了
• 手動中断

対策:

• lock timeoutを定義
• 強制unlock手順をRunbook化
• Slack通知でlock継続を可視化

8. 運用Runbookに必ず入れる項目

• OpenTofuバージョン更新手順
• backend障害時の復旧手順
• lock競合時の対応フロー
• 監査ログ（誰がいつapplyしたか）
• ロールバック条件（差分件数・重大リスク判定）

「ツール移行成功」は、CLIが動くことではなく、運用が回ることです。

9. 具体的な移行チェックリスト

• .terraform.lock.hcl を全リポジトリで固定
• OpenTofu版CIテンプレート作成
• dev/stg/prodの順に移行計画作成
• stateバックアップの自動化
• lock競合監視の通知導入
• apply実行権限を限定
• 切替後の変更凍結ルールを明文化

まとめ

TerraformからOpenTofuへの移行は、単純なCLI置換ではなく IaC運用基盤の再整備 です。

• 差分原因を分離して検証する
• state保護を最優先に設計する
• CIとRunbookをセットで更新する
• 段階移行でリスクを局所化する

この4点を守れば、既存システムを止めずに移行できます。まずはdev環境で「同一plan再現性」を検証し、そこから本番へ広げるのが最短かつ安全です。

付録: 切替当日の実行チェック（時系列）

移行当日は、作業手順よりも「順番管理」が事故防止に効きます。以下は実務で使える時系列テンプレートです。

• T-30分: 変更凍結を全チームへ告知、未マージPRを棚卸し
• T-20分: tofu version と lockfile整合性確認、CI変数最終確認
• T-10分: backend到達確認、stateバックアップ取得
• T+0分: dev→stg→prodの順で tofu plan 実行（差分をレビュー）
• T+15分: 許容差分のみ tofu apply 実行、結果を監査ログへ転記
• T+30分: 主要監視（APIエラー率、レイテンシ、コスト）を15分監視

さらに、切替時に最も有効なのは「中止判断ライン」を先に決めることです。例えば、plan差分件数が想定の2倍以上 や apply失敗が2連続 の場合は即時中断し、旧フローへ戻す、といった基準を明文化しておくと現場判断がぶれません。