2023年8月10日にHashiCorpがTerraformを含む主要製品のライセンスをMPL 2.0からBUSLへ変更して以降、IaC市場は「機能競争」だけでなく「統治モデル競争」の局面に入った。2025年6月23日時点でOpenTofuはGitHub Releasesだけで980万ダウンロードに到達し、同プロジェクトは2025年10月にFidelityの大規模移行事例を公開している。さらにHashiCorpは2025年2月27日にIBM傘下入りを完了し、TerraformはIBMのソフトウェア事業内で進化する体制へ移行した。

本稿は2026年3月5日時点の一次情報に基づき、TerraformとOpenTofuをPlatform Engineering視点で比較する。論点は、(1) state/planの暗号化設計、(2) provider/module互換性、(3)移行工数、(4)統治・調達リスクである。

市場分断の現在地: BSL転換から2年で何が固定化したか

まず時系列を固定すると、判断の前提が明確になる。

  • 2023年8月10日: HashiCorpが将来リリースをBUSL化すると発表。
  • 2024年1月10日: OpenTofuがLinux Foundation配下でGA公開。
  • 2025年2月27日: HashiCorpがIBM買収完了を公表。
  • 2025年6月23日: OpenTofu 1.10.0で「GitHub Releasesのみで980万DL」と発表。
  • 2025年10月6日: OpenTofuがFidelityの移行事例（2,000超アプリ、50,000超state、400万超リソース）を公開。

この2年間で重要なのは、TerraformとOpenTofuが単なる「同一製品の別名」ではなく、意思決定軸が分かれたことである。Terraformは商用提供体制・企業製品との統合を強みとし、OpenTofuはLinux Foundation統治とオープンな意思決定を強みとする。調達・法務・セキュリティ審査を含むエンタープライズ導入では、この差が技術差と同等以上に効く。

機能差分の実態: state暗号化と互換性

機能比較で誤解されやすいのは「どちらが暗号化できるか」である。正確には、両者とも暗号化は可能だが、実装位置が異なる。

  • OpenTofu: CLI/言語側でstate/plan暗号化を定義可能。`encryption`ブロックや`TF_ENCRYPTION`でクライアント側暗号化を構成できる。
  • Terraform: バックエンドやHCP Terraform機能に依存。HCP TerraformではHYOK（2025年7月31日GA）で顧客管理鍵を使えるが、Premium前提の機能である。

この差は、マルチバックエンド環境での「運用一貫性」に影響する。OpenTofuはコードで暗号化方針を表現しやすく、Terraformは実行基盤側の設計に委ねる比率が高い。

互換性については、OpenTofu公式が「drop-in replacement」を掲げ、2026年3月時点のトップページでは3,900+ providers、23,600+ modulesを提示している。したがって多くのワークロードで互換性は高いが、完全同一ではない。Terraform側で先行した新機能（例: ephemeral/write-only関連）やprovider側の要件更新は、時期によって差分が出る。実務上は「互換性は高いが、ゼロ検証で本番切替は不可」という扱いが妥当である。

移行工数はどこで増えるか: 2-4週間レンジの現実

CLI置換（`terraform`→`tofu`）だけを見れば短時間で済む。しかしFidelity事例が示した通り、難所は周辺システムである。具体的にはCI/CD、ガバナンス、モジュールカタログ、アーティファクト管理、内部サポート導線である。

公開ガイドと事例から逆算すると、エンタープライズの標準的な移行は以下の4段階に分解できる。

  • 週1: 対象棚卸し、stateバックアップ、PoC（本番同等パイプラインで検証）
  • 週2: 中核共有パイプライン更新、主要モジュール互換テスト
  • 週3: 先行チーム移行、ガバナンス・監査証跡の確認
  • 週4: 既定CLI切替、旧系バージョン縮退運用

このため、本稿では「平均2-4週間」を、単一プロダクト全社移行の完了日数ではなく、Platform Teamが最初の本番移行波を成立させるまでのレンジとして定義する。コード互換だけを評価すると過小見積りになりやすい。

2026年の選択基準: Platform Engineeringの意思決定フレーム

最終判断は、機能優劣より「組織制約との整合」で決まる。実務では次の4観点で判定するとブレが小さい。

  • 統治・法務: OSS統治とライセンス確実性を優先するならOpenTofuが有利。IBM統合ロードマップと商用サポート一体性を重視するならTerraformが有利。
  • セキュリティ実装: 暗号化をコードでポータブルに表現したいならOpenTofu、HCP Terraform中心に集約運用するならTerraformでも充足可能。
  • 移行リスク: 共有パイプラインと標準モジュールが整っている組織ほどOpenTofu移行は短期化する。個別最適運用が強い組織は移行期間が延びる。
  • 調達・ベンダー戦略: 単一ベンダー最適化か、Foundation主導の中立性かを先に決めると、技術選定の迷いが減る。

結論として、2026年時点での現実解は二者択一ではない。短期はTerraform継続で事業優先、並行してOpenTofu互換性を保つ「デュアルラン戦略」が最も再現性が高い。逆に、法務・統治要件が厳格な組織は、OpenTofu標準化を先行させる方が将来の再移行コストを抑えやすい。

FAQ

TerraformとOpenTofuは2026年時点で完全互換と言えるか？

完全互換とは言い切れない。大半の既存コードは高い互換性を持つ一方、機能追加タイミングやprovider要件更新で差分が生じる。移行時は必ず`init/plan/apply`を本番同等環境で検証すべきである。

state暗号化だけを理由にOpenTofuへ移行すべきか？

暗号化機能は有力な差分だが、単独理由では不十分である。監査要件、運用基盤、鍵管理方式、既存HCP利用状況まで含めて総合判断する必要がある。

「移行2-4週間」は全社移行完了を意味するのか？

意味しない。本稿の2-4週間は、Platform Teamが最初の移行波を本番で成立させるまでの目安である。全社完了は組織規模と依存関係でさらに長期化する。

IBM買収後のTerraformはリスクが高いのか？

リスクの性質が変わったと捉えるべきである。製品消滅リスクより、戦略優先順位や契約・価格体系の変化を継続監視する運用リスク管理が重要になる。

参考文献