OpenTofuとは？Terraformとのライセンス・機能差と移行判断を実装視点で解説

OpenTofuは、Terraformと同じHCL構文でクラウドやオンプレの構成をコード化する、オープンソースのInfrastructure as Codeツールです。2023年にHashiCorpがTerraformのライセンスを変更したことを機に生まれ、いまはLinux Foundationの下で開発が続いています。「Terraformと何が違うのか」「乗り換える意味があるのか」で判断が止まる技術選定者は多いはずです。本記事は、MPL 2.0とBUSLというライセンス差が実務に効く場面、状態暗号化やprovider for_eachといったOpenTofu独自の機能、tofu initで置き換える移行の実際とバージョン境界、そしてOpenTofuへ移るべき組織とTerraformを据え置くべき組織の条件までを、実装の解像度で整理します。IaCそのものの仕組みはIaCとはInfrastructure as Codeの仕組みと導入判断で扱っており、本記事はTerraformとの比較と移行判断に絞ります。

まとめ：OpenTofuの要点とTerraformから乗り換えるか据え置くかの判断軸

先に結論を置きます。OpenTofuは、Terraformのフォーク（分岐）として作られた、CLI互換のオープンソース版IaCです。書き方はTerraformとほぼ同じで、コマンドが tofu に変わり、ライセンスがMPL 2.0のまま保たれています。2023年8月にHashiCorpがTerraformをBUSL（Business Source License）へ切り替えたことが、この分岐の出発点でした。

両者の差は二層あります。ひとつはライセンスで、OpenTofuはOSI承認のオープンソース、TerraformはBUSLの source-available です。もうひとつは機能で、OpenTofuは状態・プラン暗号化やproviderブロックの for_each など、Terraformにない独自機能を先に実装してきました。逆にTerraformはStacksやephemeralリソースで独自の道を進み、フォーク時点の互換は保ちつつ両者は少しずつ離れています。

判断の軸は明確です。BUSLのライセンス条項が自社の使い方に触れる、あるいは純粋なオープンソースを社内標準にしたい組織は、OpenTofuへの移行が見合います。Terraform 1.5.x相当からの移行なら tofu init への置き換えで概ね済みます。一方、HCP TerraformのようなHashiCorpのmanagedサービスや、Stacksなどフォーク後のTerraform新機能に依存している組織は、無理に動かす理由がありません。まず「BUSLが自社の運用に実害を及ぼすか」を先に問うのが、乗り換えを判断する順序です。

OpenTofuの定義とTerraformのライセンス変更から分岐した経緯

OpenTofuを理解する近道は、それが生まれた理由——Terraformのライセンス変更——から入ることです。技術的な出自はTerraformそのものなので、まず「なぜ分ける必要があったのか」を押さえます。

OpenTofuがTerraform互換のOSS版IaCとして生まれた背景

2023年8月、HashiCorpはTerraformのライセンスを、それまでのMPL 2.0からBUSL 1.1へ変更しました。ソースコードは読めるものの、HashiCorpが競合とみなすサービスへの利用を制限する形です。これに反発したコミュニティとベンダーが、変更直前のMPL 2.0版Terraformを起点にフォークを立ち上げ、OpenTF、続いてOpenTofuと名を変えて開発を継続しました。最初の正式版（1.6.0系）は2024年初頭に公開され、以後は独自にバージョンを重ねています。名前は豆腐（tofu）にかけたもので、CLIコマンドも tofu です。出発点がTerraformのコードそのものであるため、HCLの書き方も基本的な workflow も引き継いでいます。

MPL 2.0とBUSL 1.1のライセンス差が実務にもたらす制約

ライセンスの違いは、抽象的な思想の話ではなく、使う組織ごとに実害の有無が分かれる実務上の論点です。OpenTofuのMPL 2.0はOSIが承認したオープンソースで、商用利用・改変・再配布に制限がありません。TerraformのBUSL 1.1は source-available で、コードの閲覧や自社利用は認めつつ、HashiCorpが競合と判断するサービスの提供を追加許諾条項で制限します（条項どおりなら公開から4年後にApache 2.0へ転換）。

実害が出るのは、Terraformをラップ・拡張して製品化するベンダー側です。managed CI/CD、ドリフト検知、ポリシー適用などをTerraform上で商用提供する場合、BUSLの条項に抵触しうる。逆に、自社のクラウド基盤に terraform apply するだけの一般的な利用者にとって、BUSLの直接的な制約はほとんどありません。ここを取り違えると、実害のないところで乗り換えコストだけを払う判断になります。

Linux Foundation下のガバナンスと独自レジストリの位置づけ

OpenTofuは単独ベンダーの製品ではなく、Linux Foundation傘下でTechnical Steering Committeeが運営します。Spacelift・env0・Scalr・Gruntworkといった複数のIaCベンダーがバッキングに名を連ね、特定企業の一存で方針が変わりにくい構造です。プロバイダやモジュールの配布も、HashiCorpのTerraform Registryとは別に registry.opentofu.org を独自運用しています。これは単なる別置きではなく、Terraform Registryの利用規約変更に左右されずにエコシステムを保つための分離です。ガバナンスとレジストリを自前で持つことが、フォークが一過性で終わらず継続する土台になっています。

OpenTofuとTerraformの機能差とOpenTofuが先行する独自機能

ライセンスだけなら「同じものの権利違い」で済みますが、OpenTofuはフォーク後に独自機能を積んでおり、いまや中身も分岐しています。実装者が気にすべき差分を具体で押さえます。

状態・プラン暗号化などOpenTofuが独自に先行実装した機能

OpenTofuの独自機能で最も引き合いに出されるのが、状態（state）とプランの暗号化です。1.7系で導入され、tfstateに含まれるパスワードやトークン、秘密鍵といった機微情報を、保存時点で暗号化できます。Terraformには状態ファイルをネイティブに暗号化する仕組みがなく、これはOpenTofu固有の解決策です。設定は encryption ブロックで鍵プロバイダを指定する形で、PBKDF2・AWS KMS・GCP KMS・OpenBaoに対応し、暗号方式はAES-GCMを使います。状態ファイルをバックエンドに置く運用で、保存時の秘匿を標準機能として担保できる点が実務での差になります。

早期評価・provider定義関数・-excludeなどの機能差分

暗号化以外にも、OpenTofuが先に取り込んだ機能があります。バックエンド設定やモジュールソースで変数を早い段階で評価する early evaluation（1.8系）は、環境ごとにバックエンドを切り替える構成を書きやすくします。ターゲット指定では、除外側から絞る -exclude フラグ（1.9系）が加わりました。プロバイダ構成では、provider ブロックに for_each を書いて動的にインスタンスを増やす書き方（1.9系）に対応し、マルチリージョン・マルチアカウントの記述が簡潔になります。テスト機能では override_resource などのモックも使えます。なお provider定義関数（provider-defined functions）は、2024年の1.8系でTerraformとOpenTofuの双方がほぼ同時期に導入しており、これはOpenTofu独自ではありません。差分を語るときは「暗号化・early評価・provider for_each」がOpenTofu側の代表格だと押さえておくと整理しやすくなります。

TerraformがStacksやephemeralで広げた差と互換の境界

分岐は一方向ではありません。Terraformもフォーク後に独自機能を進め、複数の構成をまとめて扱うStacksや、値を状態に残さず一時的に扱う ephemeral resources/values などを追加しました。これらはOpenTofuには無いか、実装方針が異なります。つまり互換が保たれているのは「フォーク時点（Terraform 1.5.x相当）まで」で、それ以降に両者が足した機能は相互に使えないと考えるのが安全です。HCLの基礎とプロバイダの大半は共通するため日常の記述は移せますが、フォーク後の新機能に依存したコードは、そのままでは行き来できません。この境界を意識せずに移行すると、特定の新機能で詰まります。

TerraformからOpenTofuへ移行する手順と互換性の境界

OpenTofuはドロップイン置き換えを掲げますが、実際の移行は「どのTerraformバージョンから来るか」で難易度が変わります。手順と落とし穴を分けて見ます。

tofu initでTerraformを置き換える移行作業の実際

Terraform 1.5.x相当からの移行は、比較的直行です。おおまかな流れは次のとおりです。

1. OpenTofuのCLI（tofu）をインストールし、既存の .tf ファイルはそのまま置く
2. 既存の状態ファイルを退避（バックアップ）し、tofu init でプロバイダとバックエンドを初期化する
3. tofu plan で差分ゼロ（no changes）になることを確認し、想定外の差分が出ないか点検する
4. CI/CDのコマンドやDockerイメージを terraform から tofu へ切り替える

状態ファイルの形式はフォーク時点で互換なので、多くの構成は tofu plan が「変更なし」を返します。ここで差分が出る場合、フォーク後のTerraform機能やプロバイダのバージョン差が原因になりがちです。いきなり全環境を切り替えず、開発環境で plan の一致を確かめてから本番へ広げるのが、事故を避ける進め方になります。

移行前に確認する状態ファイル・プロバイダ・CI/CDの依存関係

移行の可否は、コードそのものより周辺の依存で決まります。確認すべきは次の点です。

• 状態ファイル：どのTerraformバージョンで書かれたか。フォーク後の新バージョンで書いた状態は非互換の可能性がある
• プロバイダ／モジュールの入手元：Terraform Registry前提のものが registry.opentofu.org で揃うか
• フォーク後のTerraform独自機能：Stacksやephemeralに依存していないか（依存があるとそのままは移せない）
• CI/CD・ラッパー：Atlantis等のツールやHCP Terraformの managed 機能に組み込まれていないか

とりわけHCP Terraform（旧Terraform Cloud）の managed な状態管理やワークスペースに乗っている場合、CLIを差し替えるだけでは移行が完結しません。HCP Terraformの位置づけはHCP Terraformの機能と料金の解説で整理しており、OpenTofuはこの managed 商用サービスに対する「セルフホストのOSS」という別の選択肢にあたります。依存の棚卸しを飛ばして移行に着手すると、状態やCI/CDの一点で止まります。

OpenTofuを採用すべき組織とTerraformを据え置くべき組織の条件

ここは立場を明確にします。OpenTofuは有力ですが、すべての組織が乗り換えるべきものではありません。移行が見合う条件と、Terraformのままがよい条件を分けて示します。

OpenTofuへの移行が見合うライセンス・OSS・機能の要件

次の条件が当てはまるほど、OpenTofuへの移行が見合います。

• IaCツールを組み込んだサービスを外部提供しており、BUSLの追加許諾条項が事業に触れうる
• 社内標準やコンプライアンス上、OSI承認のオープンソースであることが要件になっている
• 状態暗号化やprovider for_eachなど、OpenTofu側の独自機能が具体的な課題を解く
• ベンダーロックインを避け、Linux Foundationの中立ガバナンスを重視する

移行元がTerraform 1.5.x相当で、HCP Terraformの managed 機能に深く依存していなければ、置き換えのコストは小さく収まります。逆に言えば、ライセンス上の懸念か独自機能への具体的な必要が無いのに、思想だけで動かすのは労力に見合いません。判断の起点は「BUSLが自社の使い方に実害を及ぼすか」「OpenTofu独自機能が解く課題が実在するか」の二点です。クラウド基盤の構築やIaCの移行そのものを外部の手で進めたい場合は、AWS・Google Cloud・Azureのインフラ構築で、ツール選定から状態設計・CI/CD整備まで対応しています。

TerraformやHCP Terraformを据え置くべき見送り条件

逆に、次の場合は無理にOpenTofuへ動かすべきではありません。

第一に、HCP Terraformの managed な状態管理・ワークスペース・ポリシー機能に業務が組み上がっている組織です。CLIの差し替えでは済まず、移行はプラットフォーム全体の作り直しに近くなります。第二に、Stacksやephemeralリソースといったフォーク後のTerraform独自機能を前提にコードを書いている場合です。OpenTofuには対応が無いか方針が異なり、そのままは移せません。第三に、自社インフラに terraform apply するだけで、BUSLの追加許諾条項が事業に一切触れない一般的な利用者です。この立場ではライセンス上の実害が無く、移行コストだけが残ります。まずBUSLが自社の運用に実害を与えるかを確かめ、実害と独自機能の必要が揃って初めて移行を検討する。この順序が、流行に流された切り替えを避けます。

OpenTofuの機能差・移行・採用判断についてのよくある質問

検討段階でよく挙がる質問をまとめます。Terraformとの比較と移行判断に絞って答えます。

OpenTofuとTerraformはどちらを選ぶべきですか？

ライセンスと独自機能で選び分けます。IaCツールを組み込んだサービスを外部提供している、あるいはOSI承認のオープンソースを要件にする組織はOpenTofuが向きます。一方、HCP Terraformの managed 機能やStacksなどフォーク後のTerraform独自機能に依存している組織は、Terraformのままが妥当です。自社インフラに適用するだけでBUSLの条項に触れないなら、どちらでも実務差は小さく、無理に乗り換える理由はありません。

既存のTerraformからOpenTofuへ移行するのは大変ですか？

移行元のバージョン次第です。Terraform 1.5.x相当からなら、CLIを tofu へ入れ替え、状態を退避してから tofu init と tofu plan で差分ゼロを確認する流れで概ね移れます。状態ファイルの形式がフォーク時点で互換なためです。ただしフォーク後のTerraform新機能やHCP Terraformの managed 機能に依存していると、そのままでは移せません。開発環境で plan の一致を確かめてから本番へ広げるのが安全です。

OpenTofuは無料で商用利用しても問題ありませんか？

問題ありません。OpenTofuはMPL 2.0で提供される、OSI承認のオープンソースです。商用利用・改変・再配布に制限がなく、これはTerraformが2023年8月より前に採用していたライセンスと同じ位置づけです。IaCツールを組み込んだサービスを外部提供する場合でも、TerraformのBUSLのような競合利用の制限を受けずに済みます。

OpenTofuとTerraformで.tfファイルはそのまま使えますか？

フォーク時点（Terraform 1.5.x相当）までのHCLは、基本的にそのまま使えます。OpenTofuはTerraformのコードを起点にしており、HCL構文とプロバイダの大半を共有するためです。ただしフォーク後にTerraformが足したStacksやephemeralリソース、あるいはOpenTofu独自の状態暗号化やprovider for_eachといった各々の新機能は互換ではありません。共通部分は移せる、双方の新機能は行き来できない、と線を引くのが実務的です。

OpenTofuとHCP Terraformは何が違うのですか？

比べる層が異なります。OpenTofuはCLIツール（Terraform本体に相当するOSS版）で、HCP Terraformは状態管理・ワークスペース・ポリシー適用などをクラウドで提供するHashiCorpの managed サービスです。OpenTofuを使いつつ状態管理は別のバックエンドやセルフホスト基盤で賄う、という組み合わせになります。HCP Terraformの機能や料金はHCP Terraformとは（旧Terraform Cloud）の解説で整理しています。

関連記事

• IaCとは？Infrastructure as Codeの仕組み・メリットと導入判断：OpenTofu/Terraformの上位概念。IaCそのものの仕組みと導入判断はこちら
• HCP Terraformとは？旧Terraform Cloudの機能・料金とHCPでの位置づけ：OpenTofu（OSS版）に対するmanaged商用サービス。状態管理をクラウドで賄う選択肢