Terraform 運用 #7 OpenTofu とライセンス — BSL 転換、IBM による買収、選択基準

インフラ Terraform IaC OpenTofu
読了 6分

トラックの最終回はコードではなく、ツールそのものの話です。基礎 #1で「OpenTofu というフォークがあり、選択基準は最後に扱います」と先送りにした約束の回でもあります。いま Terraform を学ぶ人の前には、事実上 2 本の道があります。その分かれ道がなぜ生まれたのか、実際に何が分かれたのか、そしてどう選ぶのかを整理して、トラックを締めくくります。

何が起きたのか — 2023 年からの年表 #

  • 2023-08: HashiCorp が Terraform のライセンスをオープンソース(MPL 2.0)から BSL(Business Source License)に転換しました。突然の転換にコミュニティが反発し、数週間で最後のオープンソースバージョン(1.5)からフォークした OpenTofu が立ち上がりました。
  • 2024: OpenTofu が Linux Foundation 傘下で 1.6 を皮切りに独自リリースを重ね、Terraform との機能分岐が始まりました。
  • 2025-02: IBM による HashiCorp の買収が完了しました(64 億ドル)。Terraform は IBM 製品群の一部になりました。
  • 2025-04: OpenTofu が CNCF(Cloud Native Computing Foundation)に採択され、Kubernetes と同じ財団のプロジェクトになりました。
  • 2026 年現在: 調査によって差はありますが、OpenTofu の採用率は 10% 台前半で、Terraform が依然として多数派です。ただし、新規の評価候補に OpenTofu を挙げるチームの割合は、それよりずっと高く出ています。

BSL が実際に禁止していること #

ライセンス論争は過熱しやすいので、事実関係を絞っておきます。BSL 下の Terraform はソースが公開されており、無料で使え、商用サービスのインフラ管理に使うのも自由です。禁止されているのは、Terraform と競合する商品に Terraform を組み込んで提供することです。つまり #6で見た実行プラットフォームのような事業を行う会社が直接の影響範囲で、インフラを管理する大半のエンドユーザーにとって、法的な実質の変化はありません。それでもフォークが起きた理由は、ライセンスの条文より信頼の問題でした。一度変わったライセンスはまた変わり得ますし、エコシステムを構成していたツール企業の足場が揺らぎ、IBM による買収は「単一企業の決定に左右されるツール」という懸念を再確認させました。OpenTofu が財団(Linux Foundation、その後 CNCF)所属であることを前面に打ち出す理由はここにあります。

何が分かれたのか #

フォーク初期は 2 つのツールは事実上同じでしたが、リリースを重ねるうちに分岐が実体化しました。

  • 文法とコア: 依然として大部分は互換です。このトラックで学んだ HCL、state、モジュール、ワークフローの概念は、どちらにもそのまま通用します。プロバイダーとモジュールのエコシステムも大部分は共有です(OpenTofu は独自のレジストリを運営しています)。
  • OpenTofu 固有: 代表的なのは state 暗号化(state ファイルそのものを暗号化して保存)のように、コミュニティの要望が大きかった機能を先に入れる動きです。
  • Terraform 固有: 実践 #6で使った ephemeral・write-only 系のように、最新の言語機能が Terraform に先に載る場合があり、HCP Terraform や Sentinel といった商用エコシステムは Terraform 専用です。

実務的な含意は明確で、概念の学習は共通の資産、特定の新機能に依存するコードから移植性が壊れます。このトラックの内容では、write-only 引数が代表的な確認ポイントです。

選択基準 #

  • すでに Terraform を使っているチーム: 強制的に移行すべき理由はありません。BSL はエンドユーザーに実質的な制約を課さず、切り替えコストは実在します。ただし、新機能への依存を増やすほど後から戻りにくくなる点は、認識したうえで判断します。
  • これから始めるチーム: 財団のガバナンスとライセンスの安定性を重視するなら OpenTofu、HCP Terraform のエコシステムや Sentinel、最新の言語機能を使うなら Terraform です。求人市場の表記はまだ Terraform が多数ですが、概念が共通なので、履歴書の観点での差は大きくありません。
  • 実行プラットフォームやツールを作る組織: BSL の直接の影響範囲なので、法務レビューなしに Terraform を組み込んではいけません。この場合は OpenTofu がデフォルトです。

移行そのものは、分岐点(1.5/1.6)付近のバージョンであれば state をそのまま読めるため順調に進むことが多く、バージョンが離れるほど、まず機能の使用有無の監査が先になります。公式の移行ガイドがバージョンの組み合わせごとの確認項目を提供しているので、実行前に最新のガイドを確認することを前提にしてください。

トラックを終えて #

基礎 9 本で文法と原理を、実践 10 本で myapp インフラ全体を、運用 7 本でチームのワークフローとガバナンスを扱いました。26 本を貫くテーマを 1 つだけ挙げるなら、インフラに関する判断をレビュー可能な記録にすることです。plan を読む習慣(基礎 #2)から始まり、安全装置(基礎 #7)、シークレット(実践 #6)、CI の関門(#1)、ポリシー(#4)まで、すべてその変奏でした。学習を資格として仕上げたいなら、HashiCorp の Terraform Associate が標準です。2026 年 1 月から試験が 003 から 004 に改定されたので、受験時点の現行コードを確認して準備してください。このトラックの基礎・実践の内容が、試験範囲の大部分をカバーします。

まとめ #

今回扱った内容です。

  • 2023 年の BSL 転換 → OpenTofu フォーク → 2025 年の IBM による買収完了と CNCF 採択が、現在の勢力図に至る年表です
  • BSL が禁止しているのは競合商品への組み込みで、インフラを管理する大半のエンドユーザーには実質的な制約がありません。フォークの原動力は条文よりガバナンスへの信頼でした
  • 文法と概念は依然として大部分が共通で、state 暗号化(OpenTofu)、ephemeral・write-only(Terraform)のように新機能から分かれていきます
  • 既存チームは現状維持がデフォルト、新規チームはガバナンス対エコシステムで選択、ツールを作る組織は OpenTofu がデフォルトです
  • Associate 資格は 2026 年 1 月から 004 が現行です。トラックの基礎・実践が試験範囲の大部分をカバーします

Terraform トラック 26 本はここで完結です。インフラコードの次のステップとしては、このトラックの CI 部分を拡張する GitHub Actions の自動化、そして Kubernetes トラックとの組み合わせが自然な隣接分野です。どちらに進むにしても、このトラックのコードがそのまま出発点になります。

X