開発ツール15分で読める

Terraform vs OpenTofu——IaCの分裂、どちらを選ぶべきか

開発ツールオープンソースクラウド
加木谷 直俊ソース記事を見る

2023年8月、HashiCorpがTerraformのライセンスをMPL 2.0からBSL（Business Source License）1.1に変更したことで、Infrastructure as Code（IaC）の世界に激震が走った。この決定を受けて誕生したフォーク「OpenTofu」は、Linux Foundation傘下で急速に成長し、2026年現在ではOpenTofu 2.0のリリースを控えるまでに至っている。さらに2024年にはIBMがHashiCorpを**64億ドル（約9,600億円）**で買収し、Terraformの方向性にも大きな変化が生じている。

本記事では、TerraformとOpenTofuの現状を徹底比較し、チームや組織がどちらを選ぶべきかの判断材料を提供する。

ライセンス分裂の経緯

以下の図は、TerraformからOpenTofuへの分裂の流れと、それぞれの特徴を示しています。

Terraform vs OpenTofuの分裂経緯。2014年のOSS公開から2023年のBSL転換、OpenTofuフォークまでの流れ

BSL転換の背景

HashiCorpがBSLに転換した最大の理由は、サードパーティベンダーがTerraformのコードをそのまま使って競合製品を提供していたことだ。具体的にはenv0、Spacelift、Scalrなどが、Terraform Cloudと直接競合するマネージドサービスを展開していた。HashiCorpのArmon Dadgar CEOは「オープンソースの持続可能性を守るため」と説明したが、コミュニティの反発は大きかった。

BSL 1.1の要点は以下のとおりだ。

  • Terraformのコードを自社プロダクトの管理・運用には自由に利用可能
  • ただし「Terraformと競合する製品・サービス」の提供に使用することは禁止
  • 4年経過後、コードはMPL 2.0としてリリースされる

OpenTofu誕生

BSL転換からわずか1カ月後の2023年9月、Gruntwork、Spacelift、env0、Harness、Scalrなど主要なTerraformエコシステム企業が結集し、OpenTofu（当初はOpenTF）をフォーク。Linux Foundation傘下のプロジェクトとして正式にスタートした。初期のマニフェストには140社以上、700名以上の個人が署名している。

IBM による HashiCorp 買収

2024年4月、IBMはHashiCorpを**64億ドル（約9,600億円）**で買収すると発表し、同年末に完了した。これにより以下の変化が生じた。

  • Terraform は IBM のマルチクラウド戦略の一部に組み込まれる
  • HashiCorp Cloud Platform（HCP）は IBM Cloud との統合が進む
  • Vault、Consul、Nomad を含むHashiCorp製品群が IBM のエンタープライズポートフォリオに追加
  • ライセンスに関してはBSLを維持する方針が明示された

Terraform vs OpenTofu 機能比較

項目TerraformOpenTofu
ライセンスBSL 1.1MPL 2.0（完全OSS）
最新バージョン1.10.x1.9.x / 2.0 beta
State暗号化なし（Enterprise のみ）v1.7+ で標準搭載
変数/プロバイダーの Early Evaluation非対応v1.8+ で対応
Registryregistry.terraform.ioregistry.opentofu.org
プロバイダー互換性公式（全プロバイダー）Terraform プロバイダーと互換
マネージドサービスTerraform Cloud / EnterpriseSpacelift, env0, Scalr 等
サポート体制HashiCorp / IBM 公式コミュニティ + スポンサー企業
ガバナンスHashiCorp / IBM が管理Linux Foundation
料金OSS無料 / Cloud $20+/月完全無料

OpenTofu 2.0 の注目機能

OpenTofu 2.0（2026年前半リリース予定）では、Terraformとの差別化がさらに進む。

  1. ネイティブテスト機能の強化: tofu test コマンドでインフラコードのユニットテスト・統合テストを標準サポート
  2. State暗号化のAWS KMS / GCP KMS対応: クラウドプロバイダーのキーマネジメントサービスと直接統合
  3. モジュールのバージョニング改善: セマンティックバージョニングの厳密な適用とロックファイルの改善
  4. for_each の動的プロバイダー対応: プロバイダー設定自体を動的に生成可能に
  5. パフォーマンス改善: 大規模State（10,000リソース以上）のplan/apply速度が最大40%向上

移行ガイド：Terraform → OpenTofu

以下の図は、TerraformからOpenTofuへの移行を検討する際の判断フローを示しています。

移行判断フローチャート。Terraform Cloud利用有無やBSLライセンスリスクに応じた選択肢

基本的な移行手順

TerraformからOpenTofuへの移行は、現時点では比較的スムーズに行える。HCL構文とStateファイルの互換性が高いためだ。

# 1. OpenTofu のインストール
brew install opentofu

# 2. 既存プロジェクトで初期化（.terraform ディレクトリを再作成）
tofu init

# 3. plan で差分がないことを確認
tofu plan

# 4. 問題なければ以降は tofu コマンドを使用
tofu apply

移行時の注意点

  • Stateファイルの互換性: 現時点ではTerraform 1.5.x までのStateファイルと完全互換。1.6以降は一部非互換の可能性あり
  • プロバイダーのRegistry: registry.terraform.io から registry.opentofu.org にミラーリングされているが、企業独自のプライベートプロバイダーは手動設定が必要
  • CI/CDパイプライン: GitHub ActionsやGitLab CI用のOpenTofuアクション/テンプレートが公式提供されている
  • Terraform Cloud/Enterprise: 移行先としてSpacelift、env0、Scalr等のOpenTofu対応プラットフォームを検討

移行に向かないケース

以下の場合はTerraform継続が合理的だ。

  • Terraform Cloud/Enterpriseに深く依存: Sentinel Policy、Run Tasks、Private Registryなどを多用している場合
  • HashiCorp製品スイート統合: Vault、Consul、Nomadとの連携がTerraform Cloudで管理されている場合
  • エンタープライズサポートが必須: IBMによる24/7サポートが契約上必要な場合

クラウドプロバイダーの対応状況

主要クラウドプロバイダーの公式スタンスは以下のとおりだ。

プロバイダーTerraform 対応OpenTofu 対応備考
AWS公式サポート公式にはニュートラルAWS Provider は両方で動作
Google Cloud公式サポート公式にはニュートラルGCP Provider は両方で動作
Azure公式サポート公式にはニュートラルAzureRM Provider は両方で動作
Oracle Cloud公式サポートコミュニティサポートOCI Provider は両方で動作

実質的にすべてのメジャープロバイダーのTerraformプロバイダーはOpenTofuでもそのまま動作する。これはプロバイダーがGoのプラグインとしてTerraform Plugin SDKで実装されており、このSDK自体はMPL 2.0ライセンスのままであるためだ。

エコシステムとツール比較

IaCマネジメントプラットフォーム

ツールTerraform対応OpenTofu対応特徴
Terraform Cloud○×HashiCorp公式。IBM買収後も継続
Spacelift○○OpenTofuの主要スポンサー
env0○○コスト管理機能が強み
Scalr○○マルチテナント対応
Atlantis○○OSS。GitHub/GitLab PR連携

周辺ツール

  • Terragrunt: OpenTofuを正式サポート。terragrunt.hcl の terraform ブロックを opentofu ブロックに変更可能
  • Infracost: OpenTofuのplanファイルからコスト見積もり可能
  • Checkov / tfsec: HCL構文のセキュリティスキャンは両方で動作
  • Docker: 公式Docker ImageはTerraform・OpenTofu両方提供

コミュニティと開発体制

Terraform（HashiCorp / IBM）

  • GitHub Stars: 約43,000
  • コントリビューター: HashiCorp社員が中心（外部コントリビュートは限定的）
  • リリース頻度: 約2〜3カ月ごとのマイナーリリース
  • 意思決定: IBM/HashiCorp の製品ロードマップに依存

OpenTofu（Linux Foundation）

  • GitHub Stars: 約24,000（フォーク以降急成長）
  • コントリビューター: 150社以上からの貢献
  • リリース頻度: 約1〜2カ月ごとのマイナーリリース
  • 意思決定: RFC プロセスによるオープンガバナンス
  • スポンサー: Spacelift、env0、Gruntwork、Harness 等

注目すべきは、OpenTofuのコントリビューション速度がTerraformを上回りつつある点だ。State暗号化やEarly Variable Evaluationなど、OpenTofu発の機能がTerraformにはない独自の価値を提供し始めている。

日本ではどうなるか

日本市場におけるTerraform vs OpenTofuの動向は、以下のポイントに注目すべきだ。

エンタープライズ市場

日本の大企業では、IBMとの既存関係がTerraform選択に大きく影響する。IBMのエンタープライズ営業力は日本市場で強く、HashiCorp製品を含むパッケージ提案が増えている。金融・製造業を中心に、SIerを通じたTerraform Enterprise導入が引き続き主流と見られる。

スタートアップ・テック企業

一方、日本のスタートアップやテック企業ではOpenTofuへの移行が加速している。特にコスト意識の高いスタートアップにとって、完全OSSであることとベンダーロックインの回避は大きな魅力だ。メルカリ、LINE、サイバーエージェントなどのメガベンチャーがOpenTofu採用を検討・実施しているという報告もある。

コミュニティ

日本のTerraformユーザーコミュニティ「HashiCorp User Group Japan」は引き続き活発だが、OpenTofuの日本語ドキュメントやコミュニティも徐々に形成されつつある。CloudNative Days TokyoやPlatform Engineering Meetupなどのイベントでも、OpenTofuのセッションが増加傾向にある。

SIer・MSPへの影響

BSLライセンスの「競合禁止」条項は、日本のSIerやMSP（マネージドサービスプロバイダー）にとってグレーゾーンとなりうる。Terraformの運用・管理をサービスとして提供しているSIerは、法務確認を含めたライセンスリスク評価が必要だ。この不確実性がOpenTofuへの移行を後押しする要因にもなっている。

まとめ：どちらを選ぶべきか

TerraformとOpenTofuの選択は、組織の状況によって異なる。以下のアクションステップを参考にしてほしい。

  1. ライセンスリスクの評価: BSL 1.1が自社のユースケースに影響するか法務部門と確認する。特にIaCの運用・管理をサービスとして外部提供している場合は要注意
  2. Terraform Cloud/Enterpriseの依存度チェック: Sentinel、Run Tasks、Private Registryなどの利用状況を棚卸しし、移行コストを見積もる
  3. OpenTofuの検証: 新規プロジェクトでOpenTofuを試用し、既存のHCLコードとの互換性を確認する。tofu init && tofu plan だけでも初期検証は可能
  4. ハイブリッド運用の検討: 既存プロジェクトはTerraform、新規プロジェクトはOpenTofuという段階的な移行戦略も有効
  5. コミュニティへの参加: OpenTofu Slack、GitHub Discussions、日本のPlatform Engineeringコミュニティに参加し、最新情報と移行事例をキャッチアップする

IaCツールの選択は、単なる技術的判断ではなくライセンス・ガバナンス・エコシステムを含む戦略的判断だ。2026年はOpenTofu 2.0のリリースとIBMによるTerraformの再定義が重なり、この分野の大きな転換点となるだろう。

この記事をシェア

XはてブLinkedIn

「開発ツール」カテゴリの記事

「開発ツール」の記事をもっと見る

関連記事

新着記事