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連続 の場合は即時中断し、旧フローへ戻す、といった基準を明文化しておくと現場判断がぶれません。

Terraform を導入していても、運用が進むほど「実環境がいつの間にかコードとズレる」問題にぶつかります。いわゆるドリフトです。最初は小さな差分でも、放置すると本番変更時に予期せぬ差分が混ざり、障害やリリース遅延の原因になります。

本記事では、Terraform ドリフト検知を単なる terraform plan 実行で終わらせず、継続運用できる仕組みとして実装するための具体策をまとめます。対象は AWS を例にしますが、考え方は他クラウドでも共通です。

1. ドリフト検知で最初に決めるべきこと

多くのチームが失敗するのは、実装前に運用設計を決めないことです。まず以下を決めます。

1. どの環境をいつ検知するか（prod は毎日、stg は平日など）
2. 検知結果をどこに通知するか（Slack/Discord/Issue）
3. 誰がいつまでに対応するか（当番制、SLA）
4. 「意図した手動変更」をどう扱うか（例外ラベル、期限付き）

ここを決めずに CI だけ作ると、通知がノイズ化して無視されます。ドリフト検知は技術課題より運用課題です。

2. リポジトリ構成と state 分離

最小限、次のような構成を推奨します。

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

infra/
  modules/
    vpc/
    ecs/
    rds/
  envs/
    prod/
      main.tf
      backend.hcl
      variables.tf
    stg/
      main.tf
      backend.hcl
.github/
  workflows/
    terraform-drift.yml

環境ごとに backend と state を分けることが重要です。ドリフト検知ジョブが state を誤って参照すると、存在しない差分が出ます。S3 backend + DynamoDB lock を使う場合は、bucket/key/region/table の整合性を必ず固定化します。

3. CI での検知フロー（GitHub Actions）

以下は、毎朝実行してドリフトを検知する最小構成です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

name: terraform-drift

on:
  schedule:
    - cron: "0 22 * * *" # JST 07:00
  workflow_dispatch:

jobs:
  drift-prod:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: infra/envs/prod
    permissions:
      id-token: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.9.8

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-terraform-readonly
          aws-region: ap-northeast-1

      - name: Init
        run: terraform init -backend-config=backend.hcl

      - name: Drift check
        run: terraform plan -detailed-exitcode -out=tfplan

-detailed-exitcode は実務で必須です。終了コードの意味は以下です。

• 0: 差分なし
• 1: エラー
• 2: 差分あり（ドリフト含む）

これを使えば、差分ありと失敗を明確に分けられます。

4. 終了コードを正しく扱う

Actions で単純に terraform plan を実行すると、終了コード 2 が failure 扱いになるため、実際には「検知成功」なのに赤く見えます。以下のように分岐して扱います。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

set +e
terraform plan -detailed-exitcode -out=tfplan
code=$?
set -e

if [ "$code" -eq 0 ]; then
  echo "DRIFT=false" >> $GITHUB_ENV
elif [ "$code" -eq 2 ]; then
  echo "DRIFT=true" >> $GITHUB_ENV
else
  echo "Terraform plan failed"
  exit 1
fi

この実装にすると、ジョブ自体は成功させたまま「ドリフト有無」を後段に渡せます。

5. 通知設計：差分サマリを人間が読める形にする

ドリフト検知で最も大事なのは、通知が読みやすいことです。plan 全文を貼ると誰も読みません。次の 3 つだけ通知します。

1. どの環境で
2. 何が（resource type + name）
3. どう変わるか（create/update/delete）

例: terraform show -json tfplan を jq で要約

1
2
3
4
5

terraform show -json tfplan > plan.json
jq -r '
  .resource_changes[] |
  "- \(.type).\(.name): \(.change.actions | join(","))"
' plan.json | head -n 50 > summary.txt

通知文は長すぎると切れるため、冒頭 50 件だけに制限し、全文は artifacts に添付する運用が実践的です。

6. 誤検知を減らす具体策

ドリフト検知の信頼性を下げる典型例は次です。

• timestamp 的な値を管理対象にしている
• provider バージョン差で毎回微差分が出る
• autoscaling 系設定が外部コントローラで更新される

対策として、lifecycle { ignore_changes = [...] } を乱用せず、変化が許容される属性だけを限定的に無視します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

resource "aws_ecs_service" "app" {
  name            = "app"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.app.arn

  lifecycle {
    ignore_changes = [
      desired_count
    ]
  }
}

ignore_changes は便利ですが、広げすぎると本当に危険なドリフトを見逃します。四半期ごとに見直しを入れてください。

7. 復旧フロー：検知後に迷わない手順

ドリフトを検知したら、毎回議論しないように Runbook 化します。

ステップA: 変更の意図確認

• 直近の障害対応や緊急作業がなかったか
• コンソール手動変更のチケットがあるか

ステップB: 差分分類

• 許容（意図あり）
• 要コード反映（意図あり、IaC未反映）
• 要即時修正（意図なし）

ステップC: 実行方針

• IaC 正とする場合: コード更新 → PR → apply
• 実環境正としない場合: 手動変更を戻す、または Terraform apply で整合

このフローを当番が 30 分以内に回せるようにすると、検知の価値が跳ね上がります。

8. IAM 最小権限の実例

ドリフト検知専用ロールは read-only を原則にします。plan だけなら多くのサービスで読み取り権限で足ります。apply 権限を同じロールに入れると、漏えい時のリスクが大きくなります。

• github-terraform-readonly: drift check 用
• github-terraform-apply: manual approval 後に限定実行

この分離は監査対応でも説明しやすく、セキュリティレビューで通りやすいです。

9. 週次レポートで改善を回す

検知を入れたら終わりではありません。週次で次を見ます。

• ドリフト検知件数
• うち誤検知件数
• MTTR（検知から解消まで）
• 原因カテゴリ（手動運用、自動スケール、設定ミス）

誤検知率が 30% を超えるなら通知設計か ignore ポリシーが過剰です。逆に検知ゼロが長すぎる場合は、ジョブ自体が死んでいる可能性もあります。

10. 導入チェックリスト

最後に、導入時のチェックリストを置いておきます。

• env ごとに backend/state 分離済み
• terraform plan -detailed-exitcode を採用
• 終了コード 2 を正常系として処理
• 通知は summary + artifacts の二段構成
• read-only ロールで drift check を実行
• 復旧 Runbook を 1 ページ化
• 週次で誤検知率と MTTR をレビュー

Terraform ドリフト検知は、単なる監視ではなく「IaC の信頼性を維持する運用基盤」です。最初から完璧を狙うより、通知品質と対応フローを小さく回して改善する方が、結果的に強い運用になります。

11. すぐ使える運用コマンド（当番向け）

最後に、当番が迷わず実行できる最小コマンドをまとめます。どれも「まず状況把握」を優先する順序です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 1) 直近のドリフトジョブ確認（GitHub CLI）
gh run list --workflow terraform-drift.yml --limit 5

# 2) 失敗/差分あり実行のログ確認
gh run view <run-id> --log

# 3) 対象環境で再現確認（ローカル）
cd infra/envs/prod
terraform init -backend-config=backend.hcl
terraform plan -detailed-exitcode

# 4) 差分要約を作成
terraform plan -out=tfplan
terraform show -json tfplan | jq -r '.resource_changes[] | "- \(.type).\(.name): \(.change.actions | join(","))"'

この 4 ステップを運用手順書の先頭に置くだけで、一次対応の速度と品質が安定します。特に「誰が見ても同じ順序で確認できる」状態を作ることが、夜間障害時の認知負荷を大きく下げます。