IaC（Infrastructure as Code）ツールの主流を長年担ってきたTerraformは、2023年8月のBSL（Business Source License）ライセンス変更を境に、商用利用の制約が明確化した。2025年2月にはIBMがHashiCorpを64億ドル（約9,920億円、1ドル=155円換算）で買収し、Terraformの今後の方向性に不透明感が増している[3]。そのコミュニティフォークとして2024年1月に安定版が公開されたOpenTofu（オープンソースの完全互換Terraform代替）が、2026年5月14日にリリースした1.12.0は10年来の懸案機能を実装しTerraformとの差別化を本格化した[1]。IaC基盤の選択はインフラ全体の運用コストに直結する。Terraform継続か、OpenTofu移行かの判断軸をコスト・機能・リスクの3軸で整理する。
BSLライセンス変更とIBM買収が変えた「Terraform継続コスト」
Terraformのライセンスは2023年8月にMPL（Mozilla Public License）からBSLへ変更された[3]。BSLは「HashiCorpの商用製品と競合するサービスでの利用」を制限するもので、SaaS型IaCプラットフォームを構築・販売する企業には直接影響する。自社インフラ管理目的での利用はBSLの制限外だが、ライセンス条件の解釈リスクが残る。
2025年2月のIBM買収後、Terraformの開発ロードマップはIBMのエンタープライズ戦略に組み込まれた。無償利用範囲の将来的な変更可能性と、Enterprise版への誘導強化が懸念として浮上している。このリスクを回避するために、Gruntwork・Spacelift・env0・Scalr・Harness・Oracle Cloud Infrastructureらが支援するOpenTofuへの関心が急増している[3]。
OpenTofuの採用数字はその勢いを示す。IaCユーザーの38%がOpenTofuへの移行を評価または実施中で、12%が移行済み。ダウンロード数は累計980万件に達し、年間300%の成長を記録している[3]。Fidelityは50,000件超のstateファイル（400万件超のリソース）をTerraformからOpenTofuへ移行した実績がある。
OpenTofu 1.12の主要機能：10年来の懸案を解消
OpenTofu 1.12.0（2026年5月14日リリース）の最大の目玉は、prevent_destroyライフサイクル引数の変数化だ[1]。prevent_destroyは管理対象リソースの誤削除を防ぐ設定だが、Terraform 0.7（2016年）以来10年間、変数を使った動的設定が不可能でハードコードのみ対応だった。OpenTofu 1.12はこの制約を解消し、本番環境ではtrueに、開発環境ではfalseに切り替えるワークスペース別設定をモジュールのコード変更なしに実現できる。
| 機能 | OpenTofu 1.12 | Terraform (最新) |
|---|---|---|
prevent_destroyの変数化 | 対応 | 未対応 |
destroy = falseライフサイクル | 対応 | 未対応 |
| プロバイダーチェックサム自動記録 | zh: + h1: 両対応 | 手動ロック必要 |
| 並行プロバイダーインストール | 対応（高速化） | 順次インストール |
--json-into=FILENAME CLIオプション | 対応 | 未対応 |
destroy = falseは新たなライフサイクルオプションで、stateファイルからリソースを切り離す際にリモートリソースを削除せずに分離できる。tofu initはプロバイダーのチェックサムをzh:・h1:両ハッシュで自動記録するようになり、tofu providers lockの手動実行が不要になった。
移行判断の分岐点：コスト・機能・リスクの3軸
コスト軸：今すぐの移行コストは低い
OpenTofu 1.6はTerraform 1.5と機能互換でコード変更ゼロで移行できる[3]。1.12への直接移行も、stateファイル形式の互換性は維持されている。主なコストはCI/CDパイプラインのツール差し替え（terraformコマンドをtofuに置換）とチームへの学習支援だ。規模の大きな環境では、Fidelityの事例のように段階移行（環境単位・リポジトリ単位）が現実的だ。
機能軸：1.12で差が開いた
上記の比較表が示す通り、1.12時点でOpenTofuはTerraformにない機能を複数実装した。特にprevent_destroyの変数化は本番・開発の構成管理を大幅に簡素化する。今後もOpenTofuはOSS主導で機能追加を続ける一方、Terraformの機能ロードマップはIBMの優先度に依存する構造になった。
リスク軸：残存リスクも把握する
OpenTofuは2024年4月にHashiCorpからコード流用疑惑の警告書を受けた経緯がある（OpenTofu側は否定）[3]。法的リスクの完全払拭には至っていない。プロバイダーのエコシステムはTerraformの方が依然広く、一部のプロバイダーはTerraform専用のテスト・サポートにとどまる。移行前に使用中のプロバイダーのOpenTofu対応状況を確認する必要がある。
まとめ：意思決定のタイミングは今
OpenTofu 1.12の登場で「フォークはまだ実験的」という言い訳は使えなくなった。BSLリスクを許容しつつTerraformを継続するか、互換性が高い今のうちにOpenTofuへ移行するかの判断は、先延ばしすればするほど移行コストが上がる。自社のIaCがHashiCorp商用サービスと競合しない純粋な内部利用であれば、BSLの実害は小さい。ただしIBM買収後のロードマップ不透明感を受け入れるかどうかを、IT戦略の意思決定者が明示的に決める時期が来ている。
よくある質問（FAQ）
Q1. OpenTofuへの移行にはどれくらいのコードが変わりますか？
OpenTofu 1.6はTerraform 1.5と完全互換でコード変更ゼロで移行できます。コマンド名をterraformからtofuに替えるだけで動作します。
Q2. BSLライセンスは自社内利用でも問題になりますか？
自社インフラ管理の内部利用はBSLの制限対象外です。ただしTerraformを使ったSaaSや製品を第三者に提供する場合は制限が適用される可能性があります。
Q3. OpenTofuのプロバイダーはTerraformと同じものを使えますか？
Terraform Registryのプロバイダーは基本的にOpenTofuでも動作します。一部プロバイダーはTerraform専用のテストのみ実施しているため、移行前に対象プロバイダーの対応状況を確認することを勧めます。
