OpenTofuとは｜Terraformとの違い・ライセンスと選定基準

OpenTofuとは｜Terraformから分岐したIaCツール

OpenTofuは、Terraform 1.5.x系のコードベースから分岐したIaCツールです。設定ファイルの書き方（HCL）もstateの考え方も引き継いでいるため、Terraformを触ったことがあれば、ツール名とコマンド名が変わったくらいの感覚で扱えます。

違いが出るのは、ライセンス・意思決定の仕組み・分岐後に追加された機能の3つです。

OpenTofuの定義とコマンド名

OpenTofuの実行バイナリは tofu です。terraform init にあたる操作は tofu init になります。Terraform向けに書かれた多くの .tf ファイルはそのまま読み込め、tfstateについても高い互換性があります。

ライセンスはMozilla Public License 2.0（MPL 2.0）。分岐前のTerraformと同じライセンスを引き継いでいます。プロジェクトはOpenTofu公式サイトで公開されており、Linux Foundation配下の"a Series of LF Projects, LLC"として運営されています。

ここが実務上いちばん効く点です。単一ベンダーの主導ではなく、Linux Foundation配下のプロジェクトとして運営されているという事実そのものが、採用理由として挙がりやすい。設立時の考え方はOpenTofu Manifestoにまとまっています。

BUSL移行からLinux Foundation参加までの時系列

経緯を押さえておくと、案件先で「なぜうちはTerraformのままなのか」を聞かれたときに説明しやすくなります。

IBMによる買収完了はIBMのニュースリリースで公表されています。買収後もTerraformのBUSL体制自体は続いており、「買収されたからライセンスが元に戻った」わけではありません。ここは誤解されやすいところです。

ミニFAQ：OpenTofuとTerraformの関係

Q. OpenTofuはTerraformの後継ですか？

いいえ。後継ではなく並行して存在する別プロジェクトです。分岐点は共通ですが、以降はそれぞれ独立してリリースを重ねています。

Q. 名前が「OpenTF」と書かれている資料を見かけました。

発足直後の一時期の名称です。2023年9月にLinux Foundation傘下へ入るタイミングでOpenTofuに改名されました。古い日本語記事では旧名のまま書かれていることがあります。

TerraformとOpenTofuの違いを5つの軸で比較

結論から言うと、日常のコードの書き方はほぼ同じで、差が出るのはライセンス・ガバナンス・分岐後の機能・レジストリ・商用サポートの5点です。条件次第では「差が実務に効かない」ケースもあります。以下の比較表は、選定会議でそのまま使えるように整理したものです。

ライセンスとガバナンスの違い

Terraformは1.6.0以降、BUSL 1.1で配布されています。BUSLはOSI承認のオープンソースライセンスではなく、ソースは公開されているが利用範囲に制限がある「ソースアベイラブル」に分類されるものです。ライセンスの類型そのものの整理は、OSSライセンスとは｜GPL・MIT・Apacheの違いと商用利用の注意点にまとめてあります。

一方のOpenTofuはMPL 2.0。商用利用・改変・再配布の扱いは分岐前のTerraformと同じ条件です。

ガバナンス面では、OpenTofuがLinux Foundation配下という点が効きます。ライセンス方針の決定が単一ベンダーに帰属しない構造であること自体が、採用側の評価軸として挙げられます。将来の方針変更が起きないことを保証するものではありませんが、意思決定の主体が違うという事実は選定理由になります。

設定言語・stateの互換性

分岐元が同じなので、HCLの文法もプロバイダの指定方法も共通です。既存のtfstateもそのまま読み込めます。

ただし、互換性は「分岐時点のもの」であって、将来にわたって完全一致が保証されるわけではありません。双方が独自機能を追加していけば、片方でしか動かない書き方は増えていきます。移行時に差分が出やすいのはこの部分です。

OpenTofu側で先行して入った機能

OpenTofuは分岐後、Terraformのオープンソース版にはない機能を継続的に追加しています。執筆時点（2026年9月）で公式のリリースノートから確認できる主なものは次のとおりです。

実務で効きやすいのはstate暗号化とOCIレジストリ対応です。tfstateには接続情報や生成されたシークレットが含まれることがあり、保存時の暗号化を本体側で持てるのは運用設計上わかりやすい。閉域環境でプロバイダ配布に困っていた現場では、OCIレジストリ対応が選定理由になることもあります。

バージョンごとの詳細はOpenTofu v1.12.0のリリースノートやGitHubのリリース一覧で確認できます。バージョン番号を前提に技術選定する場合は、公式の最新情報を必ず自分で当たってください。この種の記事は数か月で古くなります。

なお、サポート期限もバージョンごとに設定されています。1.11以降はセキュリティサポート期間をGo言語のリリースサイクルに合わせる方針が示されており、各版のEOLはendoflife.dateのOpenTofuページで一覧できます。

Terraform側の商用サービスと機能

Terraformには、ベンダーが提供する運用基盤（HCP Terraform等）とセットで使える強みがあります。リモート実行、ポリシー適用、チーム権限管理といった周辺機能を、調達済みの契約の中で完結させたい組織にとっては、これが決定打になります。

IBM傘下に入ったことで、既存のIBM製品との調達・サポート窓口をまとめられる点を評価する企業もあります。仕様やサポート範囲はTerraform公式ドキュメントで確認してください。

レジストリとプロバイダ入手経路の違い

プロバイダとモジュールの取得元は、それぞれ別のレジストリに向きます。AWS・Google Cloud・Azureといった主要プロバイダはどちらからも入手できますが、マイナーなサードパーティ製プロバイダは片方にしか登録されていないことがあります。

移行検討時は、使っているプロバイダを required_providers から洗い出し、移行先のレジストリに揃っているかを先に確認するのが安全です。ここを飛ばすと、init の段階で止まります。

ライセンス変更で実際に影響を受けるのは誰か

最初に短答を置きます。自社（または顧客企業）のインフラを構築・運用する目的でTerraformを使う範囲であれば、HashiCorpのFAQ上は無料利用の範囲として整理されています。 フォークの話題性に比べて、実際にライセンスが制約として効いてくる立場は限られます。

ただし以下はBUSLの一般的な整理であり、個別の事業モデルが「競合サービス」に当たるかどうかの最終判断は法務部門や弁護士に確認してください。ライセンス解釈は提供形態・契約実態によって変わります。

自社インフラの構築・運用は引き続き無料で使える

BUSLは、ライセンサーと競合するサービスとして製品を提供する行為に制限をかける形式のライセンスです。制限の対象と条件はライセンス本文と提供元の解釈で定まるため、ここでの整理は概要にとどまります。その前提で言えば、社内のインフラをTerraformで管理する、顧客の環境を構築するといった使い方は、これまでどおり無料の範囲として案内されています。

商用契約が必要になる条件や「競合サービス」の考え方は、HashiCorpのライセンスFAQに項目立てで公開されています。判断に迷う構成なら、まずこのFAQの該当項目を確認するのが早い。

BUSLが論点になる典型パターン

制限に触れる可能性が出てくるのは、次のような立場のときです。

• Terraformをエンジンとして組み込んだIaC実行基盤を、SaaSとして外部に販売する

• Terraformの実行をマネージドサービスとして顧客にホスティング提供する

• Terraformの機能を再実装・再配布する形の製品を出す

CI/CDパイプラインからTerraformを実行する、社内向けのセルフサービス基盤を作る、といったケースは通常ここに含まれません。おおまかには「サービスとして外部に売っているか」が分かれ目になりますが、境界の判定は提供形態によって変わるため、上記に近い構成を検討しているなら法務確認を挟んでください。

フリーランス・受託開発の立場での考え方

受託でクライアントの環境をTerraformで構築する働き方は、通常は制限の対象として想定されている使い方ではありません。心配なのはむしろ参画先がどちらの方針を採っているかを把握しないまま入ることでしょう。

現場によっては、法務レビューの結果としてOpenTofuへ統一している、あるいは逆にベンダーサポート込みでTerraformを継続している、といった判断が済んでいます。その背景を知らずに「こちらのほうが新しいので移行しませんか」と提案すると、すでに終わった議論を蒸し返すことになりかねません。

ミニFAQ：ライセンスの扱い

Q. すでにTerraform 1.5.7で運用しています。このまま使い続けても問題ありませんか？

ライセンス上は、1.5.7はMPL 2.0で配布された版なのでその条件のまま利用できます。ただし古い版に留まる選択は、セキュリティ修正や新しいプロバイダへの追随という別の問題を抱えます。据え置くなら、依存プロバイダのサポート状況とアップデート計画をセットで確認してください。

Q. 案件でTerraformを使うとき、クライアントにライセンス確認は必要ですか？

クライアント側の事業モデルがBUSLの制限に触れる可能性があるなら、契約前に法務確認の有無を聞いておくと安全です。通常の受託開発では、参画時に「どちらを使うか」を確認できていれば足ります。

OpenTofuとTerraformの選定基準

判断軸は3つに絞れます。ライセンスの確実性を最優先するか、商用サポートを重視するか、独自機能が必要か。この順で当てはめると、多くのケースは迷わず決まります。

OpenTofuを選ぶ判断材料になる条件

• 製品にIaCエンジンを組み込む、あるいはIaC実行を外部提供する事業モデルである

• 法務レビューで、単一ベンダーによるライセンス再変更のリスクを継続的に許容できないと判断された

• state暗号化やOCIレジストリ配布を、追加の製品を入れずに本体機能で賄いたい

• OSSであることが調達要件・社内ポリシーに明記されている

Terraformを続けるのが妥当な条件

• ベンダー提供のマネージド基盤や有償サポートを前提に運用設計している

• IBMとの既存契約に統合したい調達事情がある

• チームの習熟・社内ドキュメント・CIテンプレートがTerraform前提で厚く積み上がっている

• 使っているサードパーティ製プロバイダが移行先レジストリに揃っていない

実務で判断を左右しやすいのは、後ろの2項目です。技術的な優劣より、積み上がった運用資産の移し替えコストのほうが選定に効くという整理になります。

4問で判断するフローチャート

上から順に答えていけば結論が出ます。これがこの記事の中心です。

設問4まで来て「どちらでも可」になる現場は珍しくありません。その場合は急いで動く理由がないので、次のリプレイス時期まで据え置くのが現実的な判断になります。

TerraformからOpenTofuへ移行する手順と工数の目安

移行の基本は、stateを壊さないことと、planの差分がゼロであることを確認してから進めることの2点です。設定言語もstateも互換なので、多くの構成では書き換え作業そのものはほとんど発生しません。

移行の5ステップ

1. stateとコードをバックアップする。 リモートbackendを使っている場合もstateのスナップショットを取得しておく

2. OpenTofuをインストールする。 CIランナー側にも同じ版を入れる

3. tofu init を実行する。 プロバイダの取得先が移行先レジストリに切り替わるため、required_providers の解決がここで確認できる

4. tofu plan を実行し、差分がゼロであることを確認する。 ここで差分が出るなら、原因を潰すまで先に進まない

5. 影響の小さい環境（開発用など）から小さな変更を1件適用し、挙動を確認する

手順の詳細はOpenTofu公式の移行ガイドに記載があります。複数の構成が terraform_remote_state で相互参照している場合は、参照の向きを整理する追加作業が必要になるため、公式ガイドの該当セクションを先に読んでおいてください。

規模別の所要時間の目安

以下は、移行作業の工程（バックアップ・init・全stateでのplan確認・CI修正）を構成規模から逆算した机上の目安です。実測値の集計ではなく、プロバイダの不足やCI構成の複雑さ、承認プロセスの有無で大きく変動します。自分の環境で1つのstateを試したときの所要時間を基準に、state数で掛け直すほうが精度が出ます。

実作業より、planの差分ゼロを全stateで確認する工程に時間がかかります。 state数が増えるほど確認の回数が線形に増えるためです。中規模以上なら、この確認をスクリプト化しておくと後が楽になります。

移行しない・据え置くという選択

現行のTerraformで運用が回っていて、BUSLの制限にも触れないなら、いま動かないことも正当な選択です。フォークが登場したこと自体は移行の理由になりません。

据え置く場合にやっておきたいのは、判断の記録です。「なぜ移行しないのか」「どういう条件になったら再検討するのか」をドキュメントに1ページ残しておくと、次に誰かが同じ議論を始めたときのコストを減らせます。

案件現場での扱いと参画前の確認ポイント

先に実務的な話をすると、案件の要件欄に書かれたツール名を、そのまま現場の実体だと思わないほうが安全です。募集要件は「Terraform」「IaC（Terraform等）」のように広く通じる語で書かれることが多く、OpenTofuを採用している現場でも要件欄の表記はTerraformのまま、という組み合わせが起こりえます。要件欄は求職者に伝わる語が優先されるため、ツール名の表記だけでは実体を判断できないと考えておくのが安全です。

したがって、表記の読み解きより参画前の確認のほうが効きます。次の3点は面談段階でも押さえられます。

どちらを使っているか見分ける3つの手がかり

リポジトリにアクセスできる状態なら、次の3点を見ればすぐ判別できます。

• CI設定ファイル：実行されているコマンドが terraform か tofu か

• バージョン管理ファイル：.terraform-version や .tool-versions に書かれたツール名

• ロックファイルの中身：.terraform.lock.hcl に記録されたプロバイダの取得元ホスト

面談段階で聞くなら、「IaCはTerraformとOpenTofuのどちらで運用されていますか」と直球で聞いて問題ありません。答えに詰まる現場なら、そこも含めて状況が把握できます。

スキル評価・単価への影響

評価されるのは、ツール名そのものよりIaCの設計・運用経験です。state分割の方針、モジュール設計、ドリフト検知の運用、レビュー体制といった部分は、TerraformでもOpenTofuでも共通して問われます。

逆に言えば、片方の経験しかないことが決定的な不利になる場面は限られます。コマンド名が違うだけで、求められる思考は同じだからです。

インフラ領域の単価水準を体系的に把握したいなら、SREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安と【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？が参考になります。自分の経験でどのくらいの単価を狙えるかを確かめたい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。

IaCの周辺領域まで広げるなら、構成管理はAnsibleとは？構成管理の仕組み・Terraformとの違い・案件単価をフリーランス視点で解説、デプロイ運用はArgoCDとは｜GitOpsの仕組み・Kubernetes運用と案件動向、役割の広がりはプラットフォームエンジニアとは｜仕事内容・年収・SRE/DevOpsとの違いが対応します。インフラ案件そのものを見たい場合はインフラエンジニアの案件一覧から探せます。

よくある失敗と対策

差分ゼロを確認せずにapplyしてしまう

いちばん事故が大きいパターンです。plan結果を見ずにapplyすると、プロバイダ版の差異によってリソースの再作成が走ることがあります。

対策はシンプルで、移行直後の初回applyは必ずplanの出力を人の目で確認してから実行する。CIで自動applyしている環境では、移行期間中だけ手動承認を挟む運用に切り替えるのが安全です。

旧バージョンのTerraformに留まり続ける

ライセンスを理由に1.5.7へ固定したまま、何年も更新しない状態は避けたいところです。MPL 2.0で使える最後の版に留まることと、安全に運用できることは別の話です。

古い版のまま運用すると、セキュリティ修正の提供が止まっているだけでなく、新しいプロバイダ版が要求する最低バージョンを満たせなくなることがあります。据え置くなら、依存プロバイダの対応状況を定期的に確認し、いつまで維持できるかの見通しを持っておいてください。

OpenTofu独自機能を使って戻れなくなる

早期変数評価やstate暗号化を使い始めると、その設定はTerraform側では解釈できません。検証段階では便利に感じても、あとから「やっぱりTerraformに戻す」となったときに書き換えが発生します。

移行を評価している期間は、独自機能の利用を意図的に止めておくのが無難です。本格採用を決めてから使い始めれば、戻れなくなる範囲をコントロールできます。

導入判断チェックリスト

検討会議の前に、この10項目を埋めておくと議論が早く終わります。

• [ ] 自社／顧客の事業モデルがBUSLの「競合サービス」に該当しうるかを法務に確認した

• [ ] 現在使用しているTerraformのバージョンと、そのライセンス区分を把握している

• [ ] required_providers に書かれたプロバイダをすべて洗い出した

• [ ] そのプロバイダが移行先レジストリに揃っているかを確認した

• [ ] stateの数と、それぞれのbackend種別を一覧化した

• [ ] terraform_remote_state による構成間の相互参照があるかを確認した

• [ ] CI/CDでIaCを実行している箇所をすべて洗い出した

• [ ] 移行後の初回applyをどう承認するか、運用ルールを決めた

• [ ] 移行しない場合の再検討条件（時期・きっかけ）を文書化した

• [ ] チーム内の習熟コスト（コマンド名の変更・ドキュメント更新）を見積もった

まとめ

OpenTofuとは、Terraformから分岐したオープンソースのIaCツールで、ライセンスとガバナンスを重視する現場の選択肢になります。 ただし自社インフラを管理するだけの使い方なら、Terraformを使い続けても支障はありません。移行の検討が必要になるのは、IaCの実行そのものを外部提供する立場か、OSSであることが調達要件に入っている場合です。

• OpenTofuはBUSL移行を受けて2023年に立ち上がり、現在はLinux Foundation配下でMPL 2.0のまま開発が続いている

• BUSLが制限をかけるのは競合サービスとしての提供。社内利用・受託でのインフラ構築はFAQ上は無料の範囲として整理されている（個別判断は法務確認）

• 設定言語とstateは互換。移行の要点は「バックアップ→init→planで差分ゼロ確認」の徹底にある

• 選定は技術的優劣より、商用サポートの要否・プロバイダの揃い方・積み上がった運用資産で決まる

• 案件の要件欄の表記と現場の実体はずれることがある。参画前にコマンド名とCI設定を確認しておけば齟齬を避けられる

• 急ぐ理由がないなら据え置きも正当な判断。再検討の条件だけ書き残しておく

次のアクションとしては、手元の構成の required_providers を洗い出し、移行先レジストリに揃っているかを確認するところから始めるのが具体的です。ここで詰まるかどうかで、移行の難易度がおおよそ見えます。

参照した一次情報は次のとおりです。

• OpenTofu公式サイト

• OpenTofu Manifesto

• OpenTofu 移行ガイド

• OpenTofu v1.12.0 リリースノート

• OpenTofu GitHub リリース一覧

• endoflife.date: OpenTofu

• HashiCorp ライセンスFAQ

• Terraform公式ドキュメント

• IBM、HashiCorpの買収完了を発表