OpenTofuとTerraformを比較する｜BSLライセンス変更後の移行判断・HCL互換性・機能差分の実践ガイド

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ Terraform ＞ OpenTofuとTerraformを比較する｜BSLライセンス変更後の移行判断・HCL互換性・機能差分の実践ガイド

「Terraform を本番環境で使っているが、HashiCorp のライセンス変更後に何が変わったのかを把握していない」「OpenTofu という選択肢があると聞いたが、移行すべきかの判断基準がわからない」——これはセミナーでよく受ける相談です。

2023 年 8 月、HashiCorp は Terraform のライセンスを MPL-2.0（Mozilla Public License）から BSL（Business Source License）に切り替えました。競合他社が Terraform をマネージドサービスとして再配布することを制限する変更で、Linux Foundation はこの動きに対抗して Terraform 1.5 コードをフォークし、OpenTofu を立ち上げました。2024 年 1 月に v1.6 が正式リリースされ、2026 年 8 月現在は v1.8 系が安定版として稼働しています。

この記事では、OpenTofu と Terraform を HCL コードレベルで比較し、移行手順と選択の判断基準を解説します。動作確認環境: Rocky Linux 9.4 / OpenTofu 1.8.0 / AWS プロバイダー v5.60.0 で動作確認済みです。

この記事のポイント

・OpenTofu は Terraform 1.5 のオープンソースフォーク・CLI は tofu コマンドで置き換わる
・HCL 構文・プロバイダー・state ファイルはほぼ完全に互換で既存コードの変更は不要
・移行は tofu init → tofu plan の 2 ステップで動作確認できる
・Terraform Cloud 非依存なら移行コストは低く・判断は「社内ポリシー」「将来リスク」で決まる

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

なぜ OpenTofu が誕生したのか——BSL ライセンス変更の背景

HashiCorp の BSL 変更が影響するのは「Terraform を使ってマネージドサービスを提供する企業」です。自社インフラの管理に Terraform を使う一般企業は現行の BSL でも制限されません。それでも業界が敏感に反応した理由は、「将来的に制限が強化されるかもしれない」というリスク感と、「オープンソースの原則が守られるべき」というコミュニティの価値観です。

OpenTofu の主なスポンサーは Spacelift・env0・Harness・Gruntwork（Terragrunt 開発元）など、Terraform エコシステムに深く関わる企業群です。Linux Foundation の傘下で運営されるため、特定企業によるライセンス変更リスクを構造的に回避しています。コードは GitHub で完全に公開されており（github.com/opentofu/opentofu）、誰でも参照・貢献できます。

重要な経緯として、OpenTofu は Terraform 1.5（BSL 変更直前の最後の MPL バージョン）をフォーク元としているため、1.5 時点での全機能を継承しています。以降は独自にバージョンを進め、Terraform にない機能を追加しながら発展しています。

OpenTofu と Terraform の互換性・機能差分（2026 年 8 月時点）

1. HCL 構文の互換性

.tf ファイルの構文は Terraform 1.5 と完全に互換しています。resource・variable・module・data・output・locals・provider ブロックの書き方は変わりません。以下のコードは OpenTofu でそのまま動作します。


# main.tf — 既存の Terraform コードはそのまま OpenTofu で動作する
terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

2. プロバイダーの互換性

OpenTofu は Terraform Registry（registry.terraform.io）のプロバイダーをそのまま利用できます。AWS・Azure・GCP・Kubernetes・datadog などの主要プロバイダーはすべて動作します。プロバイダーの取得元は provider_installation 設定で変更可能ですが、デフォルトで Terraform Registry から取得するため .tf ファイルの修正は不要です。

3. state ファイルの互換性

terraform.tfstate の JSON フォーマットは OpenTofu と Terraform で共通です。S3 バックエンドや Azure Blob・GCS などのリモートバックエンドに保存された state は、そのまま tofu コマンドで読み書きできます。state の変換作業は一切不要です。

4. 機能差分の比較（2026 年 8 月時点）

機能・項目	OpenTofu	Terraform
HCL 構文	完全互換（1.5 ベース）	継続更新中
state 暗号化（ネイティブ）	あり（v1.7 以降）	なし（KMS 等で代替）
provider-defined functions	あり（v1.6.3 以降）	あり（v1.8 以降）
ephemeral values（秘密値の非永続化）	なし（開発中）	あり（v1.10 以降）
Terraform Cloud / Enterprise 連携	なし（HCP Terraform 非対応）	ネイティブ対応
ライセンス	MPL-2.0（OSS）	BSL 1.1
CLI コマンド名	tofu	terraform

OpenTofu の最大の独自機能が「state 暗号化」です。v1.7 以降、state ファイルを AES-GCM または PBKDF2 で暗号化する機能を HCL で宣言的に設定できます。Terraform では KMS や HashiCorp Vault を組み合わせるしかなかった要件に、OpenTofu はネイティブに対応しています。

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、OpenTofu・Terraform のツール選定から設計・CI/CD 連携まで、ハンズオン形式で習得できるセミナーを開催しています。
＞＞ Terraform実践セミナーの詳細はこちら

移行前の確認事項——互換性に影響する設定の見直し

1. required_version の確認

既存コードに `required_version = "= 1.5"` のように完全一致で指定している場合は注意が必要です。OpenTofu はバージョン番号を独自に進めているため、`= 1.5` という制約は OpenTofu 1.8 では満たされません。


# NG: 完全一致指定は OpenTofu 1.x で動作しない
required_version = "= 1.5.0"

# OK: 以上指定にする（OpenTofu 1.8 でも通過する）
required_version = ">= 1.5"

# または: 両方を許容する範囲指定
required_version = ">= 1.5, < 2.0"

`>=` による範囲指定に変更するだけで、Terraform・OpenTofu いずれでも動作するコードになります。実際に私が管理している検証サーバーの設定では、この 1 行の修正だけで移行前後の tofu plan 結果が完全に一致しました。

2. Terraform Cloud バックエンドの確認

backend ブロックに `cloud` または `remote` を使って Terraform Cloud（HCP Terraform）に接続している場合、OpenTofu はこのバックエンドに対応していません。Terraform Cloud を利用中の場合は移行が困難です。S3・Azure Blob・GCS などのセルフホスト型バックエンドであれば問題ありません。


# OpenTofu 非対応: Terraform Cloud バックエンド
terraform {
  cloud {
    organization = "myorg"
    workspaces {
      name = "production"
    }
  }
}

# OpenTofu 対応: S3 バックエンド（こちらはそのまま使える）
terraform {
  backend "s3" {
    bucket = "my-tfstate-bucket"
    key    = "prod/terraform.tfstate"
    region = "ap-northeast-1"
  }
}

OpenTofu への移行手順（Rocky Linux 9.4 での実機手順）

1. OpenTofu のインストール

Rocky Linux / RHEL 系では公式の RPM リポジトリを登録してインストールします。


# GPG キーのインポート
sudo rpm --import https://get.opentofu.org/opentofu.gpg

# リポジトリファイルの配置
sudo curl -Lo /etc/yum.repos.d/opentofu.repo   https://packages.opentofu.org/opentofu/tofu/config_file/opentofu.repo

# インストール
sudo dnf install -y opentofu

# バージョン確認
tofu version
# OpenTofu v1.8.0
# on linux_amd64

Ubuntu / Debian 系の場合は `apt` リポジトリが提供されています。公式ドキュメント（opentofu.org/docs/intro/install）にディストリビューション別の手順が掲載されています。

2. tofu init で既存プロジェクトを初期化

既存の Terraform プロジェクトのディレクトリで `tofu init` を実行します。`terraform init` の実行結果と同じ動作をします。

$ cd /home/operator/infra/production $ tofu init Initializing the backend... Initializing provider plugins... - Finding hashicorp/aws versions matching "~> 5.0"... - Installing hashicorp/aws v5.60.0... - Installed hashicorp/aws v5.60.0 (signed, key ID ...) OpenTofu has been successfully initialized! You may now begin working with OpenTofu. Try running "tofu plan" to see any changes that are required for your infrastructure.

3. tofu plan で差分を確認する

`tofu plan` の出力フォーマットも `terraform plan` と同一です。No changes と表示されれば、既存の state と HCL コードが一致しており、インフラへの影響なく移行が完了しています。

$ tofu plan OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: No changes. Your infrastructure matches the configuration. OpenTofu has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

「No changes」が表示されれば移行完了です。以降は `terraform` の代わりに `tofu` コマンドを使うだけです。スクリプトや CI 設定の `terraform` コマンドを `tofu` に置換する対応が残作業として発生します。

移行時のトラブルシューティング

「Failed to query available provider packages」エラー
プロバイダーの取得先が見つからない場合に発生します。`.terraformrc` または `.tofurc` に provider_installation 設定が残っている場合に起こります。設定ファイルの内容を確認し、不要な provider_installation ブロックを削除してください。

「The argument "required_version" does not match」エラー
先述の通り、完全一致の `required_version = "= 1.x.x"` 指定が原因です。`>= 1.5` のような範囲指定に変更することで解消します。

「This configuration requires Terraform vX.X.X or later」警告
required_version が OpenTofu のバージョン以上を要求している場合の警告です。`>= 1.5, < 2.0` のような上限付き指定に変更するか、required_version を削除することで対応できます。

Lock ファイルの不一致
`.terraform.lock.hcl` がある状態で `tofu init` を実行すると、ハッシュ値の検証に失敗することがあります。この場合は `tofu init -upgrade` を実行してロックファイルを再生成してください。

どちらを選ぶべきか——判断チェックリスト

OpenTofu を選ぶ場合：
・OSS ライセンスへのコミットメントが組織方針として明確
・Terraform Cloud / HCP Terraform を使っていない
・state 暗号化をネイティブに実現したい
・Terragrunt を使っている（Terragrunt は OpenTofu に正式対応済み）
・将来の BSL 制限強化リスクを組織として避けたい

Terraform を維持する場合：
・Terraform Cloud / HCP Terraform の機能（Remote Runs・Sentinel Policy・Private Registry）に依存している
・HashiCorp サポート契約が必要な業種・規制要件がある
・最新の Terraform 機能（ephemeral values など）を即時利用したい
・現行の CI/CD パイプラインが安定しており移行リスクを取りたくない

現時点では「どちらかを強制する技術的理由はほぼない」というのが正直な評価です。HCL の 98% 以上は互換しており、tofu コマンドへの置換コストは低い。自社ポリシーと将来リスクの判断が主軸になります。

本記事のまとめ

確認項目	OpenTofu での扱い
HCL 構文	完全互換・変更不要
プロバイダー（hashicorp/aws 等）	そのまま利用可能
state ファイル	互換・変換不要
required_version	完全一致指定は要修正・範囲指定に変更
Terraform Cloud バックエンド	非対応・S3 等に切り替えが必要
移行の CLI 操作	tofu init → tofu plan の 2 ステップ
state 暗号化（ネイティブ）	OpenTofu 独自機能（v1.7 以降）

OpenTofu は「Terraform と入れ替えられるオープンソースの代替」として十分に成熟しています。Terraform Cloud に依存していないチームであれば、tofu コマンドへの置換という最小コストで移行できます。一方で、Terraform Cloud・Enterprise を活用している組織には現時点で移行の実用性がありません。「自社のビジネスリスクと OSS ポリシー」を軸に判断することをおすすめします。

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、OpenTofu への移行判断から Terraform の実践設計・CI/CD 連携まで、ハンズオン形式で習得できるセミナーを開催しています。
＞＞ Terraform実践セミナーの詳細はこちら

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。