OpenTofu徹底解説:Terraformのフォーク、移行、そして切り替えるべきか

今日Terraformモジュールを開くと、3年前には存在しなかった疑問に直面します。このコードを実行するバイナリは terraform、それとも tofuか。IBMは HashiCorp買収 を2025年2月27日に64億ドルで完了し、OpenTofuは CNCF Sandboxプロジェクト 2025年4月23日になり、両ツール間の移行経路は正式に文書化されている。この決断はもはや仮定の話ではない。

本稿はインフラ運用の視点から書かれており、マネージドTerraformプラットフォームの視点からではない。目的は、実際の移行コストをライセンスとガバナンスをめぐる雑音から切り分けることだ。つまり、移行中に何が壊れるか、正当なガバナンス上の懸念、そしてTerraformにとどまるのが正しい選択であるケースについて、率直に語ることができる。

本稿では4つのテーマを扱う。2026年時点でのOpenTofuとは何か、Terraformにはない機能、実際の移行の様子、そしてよくある意思決定パターンへの明確な推奨だ。

短いバージョン

• OpenTofuはTerraformのオープンソースフォークであり、MPL 2.0ライセンスの下、Linux Foundationがホストし、2025年4月23日以降はCNCF Sandboxプロジェクトとなっている。2023年8月にHashiCorpがTerraformをBusiness Source Licenseに移行した後、Terraform 1.5.xからフォークした。
• 2026年7月26日時点で、現在のメンテナンスリリースは v1.12.5。GitHubリポジトリのスター数は29,000を超えており、 OpenTofu公式サイト は3,900以上のプロバイダーと23,600以上のモジュールを掲載している。
• OpenTofu独自、またはOpenTofuが先行し、Terraformが現状同等には対応していない機能を備えている。クライアント側でのstateとplanの暗号化、provider for_eachの、早期変数評価、 enabled メタ引数、そして動的な prevent_destroy。Ephemeral resourcesはOpenTofu独自の機能ではない。Terraformは1.10以降これをサポートしている。
• ローカルまたはS3のstateを使う小規模なTerraform 1.5.xプロジェクトであれば、順調な移行は短く元に戻せるものになり得る。CI/CDの参照、HCP固有のワークフロー、依存関係ロックの変更が作業量を膨らませる部分だ。
• 2026年に新規でIaCプロジェクトを始めるならOpenTofuから始めるとよい。既存のTerraform環境については、BSLが実害をもたらすとき、OpenTofuにはあってTerraformにはない機能が必要なとき、あるいはIBM主導のロードマップが実質的な懸念となるときに切り替えるとよい。それ以外では費用対効果は薄い。

2026年におけるOpenTofuとは

OpenTofuはTerraformのオープンソースフォークであり、Linux Foundationがホストし、2025年4月23日にCNCFのSandboxプロジェクトとして受け入れられ、Mozilla Public License 2.0の下でライセンスされている。バイナリ名は tofu。設定言語はHCLであり、Terraformが使うものと同じHCLだ。ほとんどの単純〜中規模のプロジェクトでは、既存のTerraformコードベースはそのままOpenTofu上で動作する。

このフォークは2023年8月、HashiCorpがTerraformをMPL 2.0から Business Source License 1.1 2023年8月10日への移行を機に始まった。BSLはOSI承認ライセンスではなくソースアベイラブルであり、「HashiCorpの商用製品と競合する」本番利用を制限する。5日以内にOpenTF宣言が公開され、フォークが発表された。Linux Foundationの発表により、2023年9月20日にOpenTofuが正式に紹介された。

Linux Foundationの発表 は、Harness、Gruntwork、Spacelift、env0、Scalr、Digger、Terrateam、Massdriver、Terramateを創設支援企業として挙げ、少なくとも18名のエンジニアが最低5年間フルタイムで関与すると表明した。OpenTofuは最後のMPL 2.0系であるTerraform 1.5.xからフォークした。

現在のプロジェクトの状況: v1.12.5が現行のメンテナンスリリースであり、公式サイトには3,900以上のプロバイダーと23,600以上のモジュールが掲載されている。採用の兆しはもはや抗議フォークとしての勢いだけにとどまらない。 Fidelityの移行事例 は、5万件を超えるstateファイルと400万件のリソースにまたがるプログラムを紹介している。

関連する事業背景として、IBMは2025年2月27日に64億ドルでHashiCorpの買収を完了した。Terraformのロードマップは、いまやはるかに大きなエンタープライズベンダーの内部で決められることになる。これは利用者にとって自動的に良いとも悪いとも言えないが、2026年にチームが行う判断材料の一部になっている。

OpenTofuとTerraformの違い

フォーク以降、両プロジェクトは異なる機能の道を歩んできた。以下の表はその要約であり、続く説明では各違いが実務者にとって何を意味するかを解説する。

クライアント側の state暗号化 (v1.7.0、2024年4月30日)。 OpenTofuはPBKDF2、AWS KMS、GCP KMS、またはOpenBaoを使い、ツール内でstateとplanファイルを暗号化できる。Terraformは通常、保存時の暗号化を選択したバックエンドに委ねており、ローカルのstateは平文のままとなる。OpenTofuのクライアント側暗号化は、復号鍵が一緒に流出しない限り、盗まれたstateオブジェクトやキャッシュされたplanを保護できる。ただしTLS、バックエンドのアクセス制御、シークレット管理の規律の代わりにはならない。

設定はおおよそ次のようになる:

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.tofu_state_passphrase
    }
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.passphrase
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

プロバイダー for_each (v1.9)。 リソースをイテレートするのと同じ感覚でprovider設定をイテレートできる。マルチリージョンやマルチアカウント構成では、これにより長年続いた回避策の類が不要になる。リージョンごとにエイリアス付きproviderを手作業で書く必要はもうなく、マップから単一のブロックで制御できる。

早期変数評価(v1.8)。 変数はこれまで制限されていた箇所、たとえばbackendやmodule sourceの引数でも参照できるようになった。これは、1つのルートモジュールが少数の変数だけが異なる複数の環境を扱う場合に便利だ。

Ephemeralリソースと enabled メタ引数(v1.11.0、2025年12月9日)。 OpenTofu 1.11ではEphemeralリソースと enabled メタ引数を追加した。Ephemeralリソースは単一のplan/applyサイクルの中でのみ存在し、stateには保持されない。これは短命な認証情報に有用だ。これらはOpenTofu独自の機能ではなく、Terraformは1.10で導入し、1.11でwrite-only引数を追加した。ここでOpenTofu固有の機能となるのが enabledであり、条件付きの count を使った複雑な処理を避けられる。

動的 prevent_destroy (v1.12)。 Terraformの prevent_destroy 設定はリテラル値しか受け付けない。OpenTofu 1.12ではこれを計算式で指定できるため、1つのモジュールでstagingは削除可能なままにしつつ、productionは保護できる。

ライセンスの行は、機能としては表面化しない構造的な違いだ。MPL 2.0はOSI承認済みで、ファイル単位のコピーレフトである。TerraformのBSL 1.1ライセンスはソースアベイラブルで、追加の利用制限を含み、各ライセンス対象の作品が公開されてから4年後にMPL 2.0へと切り替わる。ほとんどのチームにとって実務上の影響は小さいが、HashiCorpの商用製品に近いものを構築するベンダーにとっては、これがフォークが存在する理由そのものだ。

移行:実際に壊れるもの

公式移行ガイド は意図的に短く、元に戻せる内容になっている。stateとコードをバックアップし、OpenTofuをインストールし、 tofu initを実行し、 tofu planと比較し、小さな変更をテストする。難しいのはコマンドそのものではない。周辺のCI/CD参照、HCP固有のワークフロー、依存関係ロックの変更、そしてフォーク採用に伴う組織的なレビューだ。

順調なケース

HCP Terraformを使っておらず、パイプライン内に大量の terraform参照を持たないプロジェクトであれば、移行は単純だ。

# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak

# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Re-initialize against the OpenTofu registry.
tofu init -upgrade

# Verify parity with what Terraform was doing.
tofu plan

tofu plan はTerraformが作成したplanと一致するはずだ。予期しない差分がある場合は、適用前にproviderのバージョン、backendの設定、Terraform 1.5.x以降で追加された機能を確認すること。

何かを実行する前に、2つの細かな注意点がある。第一に、OpenTofuは本ガイドが扱うケースにおいてTerraform形式のHCLと大部分で設定互換性があるが、Terraform 1.5.x以降に追加された機能については互換性の確認がなお必要だ。第二に、 tofu init -upgrade は .terraform.lock.hcl、providerのsourceアドレスやchecksumエントリを含めて更新することがある。このメタデータはインフラのdriftとは別に確認すること。

本当のボトルネック

3つの要因が、単純なCLI移行をより広範なプラットフォームプロジェクトへと変えうる。いずれもバグではない。

HCP Terraformのワークスペース。 OpenTofuには cloudおよびremote統合機能 互換性のあるremoteサービス向けの統合が含まれており、ローカル実行やstateストレージのシナリオにおけるHCP Terraformにも対応する。より難しいのは、HCP固有のremote実行とプラットフォーム機能だ。Sentinel、run trigger、動的認証情報、Stacks、そしてOpenTofuが完全にはテストまたはサポートできないサービス動作などである。これらが重要な場合は、まず1つのワークスペースで試験導入するとよい。HCPから離れる場合は、stateを移行し、これらのプラットフォーム制御を再構築すること。

プロのヒント: HCP Terraformから離れることは、環境がHCP固有のワークフローに依存している場合、最大の隠れたコストになりうる。判断する前に、 terraform state pull > state.json を実行し、サイズとリソース数を確認しよう。200リソースの1ワークスペースと、run triggerやpolicy setを備えた50ワークスペース規模のフリートとでは、まったく別のプロジェクトになる。後者はツールの入れ替えではなく、プラットフォームエンジニアリングとしての移行になる。

向けにハードコードされたCI/CDパイプライン terraform. への参照はすべて、 terraform plan, terraform apply、バイナリパス、Dockerイメージ、そしてGitHub ActionsやGitLab CIのステップは見直しが必要になる。GitHub Actionsの場合、置き換えはおおよそ次のようになる:

# Before
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.5.7

- run: terraform init
- run: terraform plan

# After
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v2
  with:
    tofu_version: 1.12.5

- run: tofu init
- run: tofu plan

これは単純なケース、つまり1つのワークフロー、1つのリポジトリの場合だ。共有のcomposite action、複数のパイプライン、再利用可能なワークフローライブラリを持つモノレポでは、見直すべき範囲がずっと広くなる。作業自体は機械的だが、CLIの置き換えそのものより時間がかかることがある。

依存関係ロックファイルのレビュー。 tofu init は .terraform.lock.hclを更新することがあり、providerのsourceアドレスやchecksumエントリも含まれる。OpenTofu 1.12ではさらに、すべてのプラットフォーム向けの完全な h1: checksumセットを追加できる。この差分はインフラのdriftではなく、別途レビューしてコミットすべき依存関係のメタデータとして扱うこと。

プロのヒント: ロックファイルの差分は最初のコミットでは雑然と見えるかもしれない。 tofu init -upgrade クリーンなブランチ上で、ロックファイルだけを「review OpenTofu lock-file changes」のような明確なメッセージでコミットし、その上に機能開発の作業をリベースしてください。依存関係のメタデータを機能PRに混在させると、両方の変更のレビューが難しくなります。

ステークホルダーの抵抗。 「今はフォークを使っている」という事実は、組織によって受け止め方が異なる。誠実な反論としては、OpenTofuは本ガイドが扱うケースにおいてTerraform形式のHCLと大部分で設定互換性を保っているため、通常この切り替えは元に戻せるということだ。もしOpenTofuが明日消えたとしても、多くのチームはTerraformを再インストールし、ロックファイルを見直した上で、同じ .tf .tfファイルを使い続けられるだろう。まずはフォーク後に追加された機能を検証すること。この注意点のほうが、完全な互換性を約束するよりも信頼できる。

移行が本当に難しくなるとき

この順調な道筋が、すべてのTerraform環境に当てはまるわけではない。

以下の場合、移行は明らかに難しくなる:

• stateが大規模で(数千件のリソース、数十のワークスペース)、HCP Terraform上にある場合。
• コードベースがHCP専用機能に深く依存している場合、たとえばワークスペースに組み込まれたSentinelポリシー、run trigger、HCP管理の動的provider認証情報などだ。Terraform StacksはHCP専用でOpenTofuに相当機能がなく、本稿の対象外である。
• 企業の監査やコンプライアンスフレームワークが「Terraform」を正式なIaCツールとして指定している場合、技術的な問題に加えて調達や文書管理上の問題も生じる。
• 大規模なモジュールライブラリには、Terraform固有のレジストリの挙動に基づいて解決された内部バージョン制約がある場合。

すべてのチームが移行すべきというわけではない。費用対効果が意味を持つのは、BSLの制限が実際にユースケースへ影響している場合、特定のOpenTofu機能が具体的な課題を解決する場合、あるいはIBM主導のロードマップが組織にとって現実的な懸念である場合に限られる。これらのどれにも当てはまらないなら、Terraformにとどまるのも十分に理にかなった選択だ。

切り替えるべきか?

ここに唯一絶対の正解はない。あるチームの意思決定ツリーを描くと、4つのよくあるパターンが現れ、正しい選択はどのパターンに当てはまるかによって変わる。

新規IaC導入(グリーンフィールド)。 OpenTofuから始めよう。ライセンスはMPL 2.0で、ガバナンスはLinux FoundationとCNCFの下にあり、プロジェクトは活発なリリースペースを維持している。その差別化要因には、クライアント側のstate暗号化、provider for_each, enabled、そして動的な prevent_destroyが含まれる。BSLに起因する摩擦を考慮する必要もない。これが本稿の中で最も強い推奨事項だ。

既存のTerraformユーザー、小〜中規模プロジェクトの場合。 3つの引き金のいずれかが当てはまるなら切り替えを検討する。1つ目は、BSLの「HashiCorpと競合する」という除外条項に触れる可能性のある製品を販売している、または販売する可能性がある場合だ。法的な整理はMPL 2.0のほうが明快だ。2つ目は、クライアント側のstate暗号化、provider for_each, enabled、動的な prevent_destroy を必要としている、あるいはTerraformの回避策を維持する価値がもはやない場合だ。3つ目は、単一ベンダーのロードマップより複数関係者によるガバナンスを好む場合だ。どれにも当てはまらず、Terraformが問題なく動いているなら、そのまま使い続けるとよい。移行は多くの環境で元に戻せるが、無料ではない。

HCP Terraformを重度に利用している場合。 これはバックエンドの移行ではなく、プラットフォームに関する意思決定として扱うべきだ。OpenTofuは互換性のあるremoteバックエンドを使えるが、HCP固有のremote実行、Sentinel、run trigger、動的認証情報、Stacksについては、機能ごとに個別の評価が依然として必要になる。これらの制御が重要であれば、まずパイロット導入から始めるとよい。ライセンス、コスト、ガバナンスの理由でHCPから離れるのであれば、この作業をプラットフォーム移行として計画すること。

PulumiやほかのHCL以外の選択肢を検討している場合。 HCLと既存のワークフローの大部分を維持したいなら、OpenTofuが最も近い選択肢だ。Pulumiはより幅広いプラットフォームおよび言語の選択肢であり、TypeScript、Python、Go、.NETなどでクラウドAPIを操作する。そちらへの移行には変換や書き換えが伴うことがあるため、TerraformからOpenTofuへの単純なバイナリの切り替えとは別に評価すべきだ。

もう一つ、直接触れておくべき点がある。OpenTofuが部分的にはSaaSベンダーのヘッジであるという、正当な批判だ。BSL変更に関するHacker Newsのスレッドでは、プロジェクトの創設メンバーが、自らのライセンス柔軟性という動機を持つ商用Terraformプラットフォームであるという懸念が浮上した。私はこの懸念を真剣に受け止めている。その緩和策となっているのが、ガバナンス構造、Linux Foundationによるホスティング、CNCF Sandbox、そしてすべてのファイルに適用されるMPL 2.0であり、これらは将来の再ライセンス化を、単一ベンダーによる再ライセンス化よりもはるかに困難にしている。不可能にするわけではない。しかし、それを実質的な歯止めとなるほどコストの高いものにしている。

簡潔な結論。 2026年に新たなIaCの取り組みを始めるなら、OpenTofuから着手するとよい。そのライセンス、ガバナンス、活発な開発、そして機能セットは、有力な既定の選択肢となる。既存のTerraform環境については、上記の3つの引き金のいずれかが当てはまるときに切り替えを検討し、それ以外では費用対効果は薄く、そのまま使い続けても問題ない。

ツールの選択が固まったら、次の実務的な問いはOpenTofuをどこで実行するかだ。この判断は、シークレットの扱い、コスト、再現性、そしてチームが実行環境をどれだけ制御できるかに影響する。

自分でOpenTofuを実行する

OpenTofuはCLIバイナリだ。どこで実行するかによって、コスト、セキュリティ、そして何ができるかが大きく左右される。配置先として妥当な場所はおおよそ3つある。

ノートPCまたは開発マシン。 単発のplan実行やプロトタイピング、小規模な個人プロジェクトには適している。remote state、ロック機構、レビュー体制がすでに徹底されていない限り、共有の本番ワークフローには不向きなデフォルトだ。チームは通常、最後に誰かのノートPCで tofu apply.

マネージドCIランナー(GitHub Actions、GitLab CIなど)。 一般的な選択肢だ。 opentofu/setup-opentofu アクションは hashicorp/setup-terraformhashicorp/setup-terraformの直接の代替品だ。これはほとんどのチームやプロジェクトでうまく機能する。トレードオフとしては、シークレットがサードパーティのCIサービスを経由すること、大きなstate操作では無料枠の分数が尽きることがあること、そしてランナー環境がephemeralであること(通常は利点だが、時に制約にもなる)が挙げられる。詳しくは GitHub vs GitLab を参照してほしい。ホスト型CIの選択肢についてまだ迷っているなら参考になるはずだ。また Best CI/CD Tools より広い選択肢については

VPS上のセルフホストランナー。 マネージドCIのトレードオフが機能しなくなったとき、たとえばシークレットをサードパーティサービスの外に置く必要がある、CIの利用時間が高額になる、あるいは永続的なproviderキャッシュが欲しい場合に有用だ。セットアップは単純で、Linux VPS、OpenTofuバイナリ、GitHub ActionsまたはGitLab Runnerのエージェント、そしてジョブ分離用のDockerがあればよい。詳しくは Install Docker on VPS この部分が初めてであれば参考にしてほしい。小規模チーム向けランナーなら、4GB RAM、2 vCPU、60GB NVMeが妥当な出発点であり、より大きなplanや高い並行性に合わせてCPU、メモリ、ストレージをスケールさせるとよい。

ランナーのシークレットをより厳密に管理したい、永続的なproviderキャッシュが欲しい、あるいはCIコストを予測可能にしたいチームにとっては、VPS上のセルフホストランナーが理にかなう選択肢になる。その構成では、root権限、高速なNVMeストレージ、容易なリサイズ、そして大きなplan操作に十分なCPU/RAMを優先するとよい。

Cloudzy Linux VPS のインスタンスは、root権限、NVMeストレージ、柔軟なサイジングを備えたこのセルフホストランナーのパターンに適しており、小さく始めてOpenTofuのワークロードの増加に合わせてランナーをスケールさせていくことができる。

よくある質問

OpenTofuはTerraformと同じものか?

厳密には違う。OpenTofuはTerraform 1.5.xのフォークとして始まり、Terraform形式のHCLと大部分で設定互換性を保っている。同じ .tf ファイル、provider、そして plan/apply ワークフローが多くのプロジェクトで使える。両者はライセンスと、フォーク後に追加された機能の点で異なる。OpenTofuにはクライアント側のstate暗号化、provider for_each, enabled、そして動的な prevent_destroyを備え、Terraformには独自のフォーク後の機能があり、その一つがephemeralリソースだ。

OpenTofuはすべてのTerraformプロバイダーに対応しているか?

AWS、GCP、Azure、Kubernetes、Helmといった主要providerであれば、概ね対応している。 OpenTofu Registry は2026年7月時点で3,900以上のプロバイダーを報告している。 tofu init は .terraform.lock.hcl tofu initは.terraform.lock.hclのメタデータを更新することがある。ニッチな、特定ベンダー向け、あるいは新しく公開されたproviderについては、切り替え前に対応状況とバージョンサポートを直接確認すること。

OpenTofu自体がいつか再ライセンス化される可能性はあるか?

将来の再ライセンス化はTerraformのときより難しいが、不可能ではない。OpenTofuはMPL 2.0であり、Linux Foundationがホストし、2025年4月23日以降はCNCF Sandboxプロジェクトである。ガバナンスは複数関係者によるもので、ライセンスはOSI承認済みだ。単一の創設メンバーによる一方的な再ライセンス化は、財団の憲章にも、削除または書き直しが必要になる既存のMPL 2.0の貢献にも抵触することになる。この懸念は正当であり、構造的な障壁は現実のものだ。

IBMによるHashiCorp買収はTerraformの将来にとって何を意味するか?

IBMは2025年2月27日に64億ドルでHashiCorpの買収を完了した。Terraformのロードマップは、いまや大手エンタープライズベンダーの内部に位置づけられている。買収そのものは、将来のライセンスや製品の方向性を証明するものではない。所有権の変化を予測材料として扱うのではなく、最新のリリースノート、ライセンスに関する指針、HCP製品の変更点を確認すべきだ。

OpenTofuは2026年時点で本番運用可能か?

はい。v1.12.5が現行のメンテナンスリリースであり、プロジェクトはCNCF Sandboxに参加しており、Fidelityは5万件を超えるstateファイルと400万件のリソースにまたがるIaC環境での本番導入について報告している。本番運用可能であることは機能が同一であることを意味しない。Terraform Stacksのような、HCP専用の機能に依存しているチームは、依然として別途互換性の判断が必要になる。