🍀 HashiCorpは裏切ったのか？ — Terraformの歴史とOpenTofuが誕生した本当の理由

オープンソースは無料ではない。しかし、自由である。

その自由を誰かが奪おうとするとき、コミュニティはフォーク（fork）で応える。

🎯 この記事で扱うこと

TerraformがどのようにIaC（Infrastructure as Code）の標準になったのか
HashiCorpがライセンスを変更した理由とコミュニティの反応
OpenTofuが誕生した背景とCNCFに加入した理由
OpenTofu vs Terraform、現在の違いは何か
OpenTofuの未来と私たちがどのような選択をすべきか

📌 導入 — 「私たちが信じていたそのツールが突然変わった」

インフラをコードで管理するという概念、IaC（Infrastructure as Code）。この分野で長らく事実上の標準（de facto standard）であったツールが、まさにTerraformです。

AWS、Azure、GCPを問わず、クラウドインフラを.tfファイル数行で宣言すれば、あっという間に構築してくれるそのTerraform。数百万人のエンジニアが毎日使うこのツールが、2023年8月、突然ライセンスを変更しました。

反応は即座でした。コミュニティは怒り、企業は戸惑い、結局OpenTofuという新しいプロジェクトが誕生しました。わずか数ヶ月でCNCF（Cloud Native Computing Foundation）の公式プロジェクトになったのです。

この記事は、その顛末を最初から最後まで整理します。Terraformの歴史から、なぜOpenTofuが誕生しなければならなかったのか、そして今後どうなるのかまで。

🔍 Terraformの歴史 — どのようにIaCの王座に上り詰めたのか

誕生 (2014年)

Terraformは、HashiCorpが2014年に作成したオープンソースのIaCツールです。HashiCorpはVagrant、Consul、Vault、Nomadなど、インフラ関連ツールで有名な会社です。

当時の問題はこうでした。クラウドが爆発的に成長するにつれて、インフラリソースをコンソール（GUI）でクリックして作成する方法が限界に達しました。数百台のサーバー、数十のネットワーク設定を手作業で管理する？不可能です。ミスも多く、再現性もなく、共同作業も困難です。

Terraformの解決策はシンプルでありながら強力でした。

# main.tf — AWS EC2インスタンスを1つ宣言する例
provider "aws" {
  region = "ap-northeast-2"  # ソウルリージョン
}

resource "aws_instance" "web" {
  ami           = "ami-0c9c942bd7bf113a2"
  instance_type = "t3.micro"

  tags = {
    Name = "my-web-server"
  }
}

このファイル一つで、`terraform apply`の一撃でEC2インスタンスが生成されます。`terraform destroy`すればきれいに削除されます。コードなのでGitでバージョン管理もでき、チームメンバーと共有も可能です。

成長 (2015~2020年)

Terraformの核となる設計哲学は、宣言型（Declarative）方式です。「このように作ってくれ」ではなく、「最終状態はこれだ」と宣言すれば、Terraformが現在の状態と比較して必要な作業だけを自動的に行います。

また、Providerエコシステムが爆発的に成長しました。AWS、Azure、GCPはもちろん、GitHub、Datadog、Cloudflare、Kubernetesまで — 数千ものProviderがRegistryにアップロードされました。事実上、「クラウド世界のすべて」をTerraformで管理できるようになったのです。

# 複数のクラウドを同時に管理する例
provider "aws" {
  region = "ap-northeast-2"
}

provider "azurerm" {
  features {}
  subscription_id = var.azure_subscription_id
}

# AWSにS3バケット
resource "aws_s3_bucket" "backup" {
  bucket = "my-backup-bucket-2024"
}

# Azureにストレージアカウント
resource "azurerm_storage_account" "backup" {
  name                     = "mybackupstorage2024"
  resource_group_name      = var.resource_group
  location                 = "koreacentral"
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

マルチクラウド戦略を採用する企業にとって、Terraformは選択肢ではなく必須となりました。

全盛期 (2020~2023年)

2021年、HashiCorpはナスダックに上場します。企業価値は数十億ドル。TerraformはDevOps/クラウドエンジニアなら必ず知っておくべきツールとなり、関連資格（HashiCorp Certified: Terraform Associate）も登場しました。

しかし、上場企業になるということは、コミュニティよりも株主と投資家に答えなければならないという意味でもあります。そして2023年、その亀裂が露呈します。

💥 ライセンス変更 — その日の衝撃

2023年8月10日

HashiCorpは、Terraformを含む自社主要製品のライセンスを、既存のMPL 2.0（Mozilla Public License 2.0）からBSL 1.1（Business Source License 1.1）に変更すると発表しました。

なぜこれが問題なのでしょうか？違いを比較してみましょう。


項目	MPL 2.0 (既存)	BSL 1.1 (変更後)
個人利用	✅ 自由	✅ 自由
企業内部利用	✅ 自由	✅ 自由
オープンソースプロジェクト	✅ 自由	✅ 自由
HashiCorpと競合する製品/サービスの構築	✅ 可能	❌ 不可
OSI公式オープンソース認証	✅ 認証済み	❌ 未認証

核心は一つです。「HashiCorpの競合他社はTerraformを利用して商業サービスを構築できない。」

HashiCorpの論理はこうでした。「一部の企業が私たちのオープンソースで利益を上げているが、貢献はしていない。私たちも持続可能なビジネスをしなければならない。」これは間違った言葉ではありません。

しかし、コミュニティの反応は異なりました。

私たちが10年間貢献し、エコシステムを育てたのはオープンソースだったからだ。

今になってルールを変えるなら、それは裏切りではないのか？

Spacelift、Env0、ScalrのようにTerraformベースでサービスを構築していた企業は直撃を受けました。HashiCorpのTerraform Cloudと競合する構造だったからです。

🍀 OpenTofuの誕生 — コミュニティのフォーク（Fork）

OpenTF Manifesto (2023年8月)

ライセンス変更発表直後、コミュニティは迅速に動きました。数十の企業と数千人の開発者がOpenTF Manifestoに署名しました。要点はシンプルでした。

HashiCorpにMPL 2.0に戻るよう要請する
戻らない場合、我々が直接真のオープンソースTerraformフォークを作成する

署名に参加した企業だけでも、Gruntwork、Spacelift、Env0、Terragruntの開発元など、有力な企業ばかりでした。HashiCorpは応じませんでした。

OpenTofu誕生 (2023年9月)

そうしてOpenTofuが誕生しました。Terraformの最後のMPL 2.0バージョン（1.5.x）をベースにした公式フォークです。

名前の由来が面白いです。🍀 クローバーの絵文字を活用したマスコット、そしてTofu（豆腐）。豆腐はどんな料理にも合い、形を自由に替えられ、オープンソースのように誰でも作ることができます。オープンソース哲学を料理で表現したセンスのあるネーミングです。

OpenTofu 초기 참여 기업/프로젝트:
- Gruntwork (Terragrunt 개발사)
- Spacelift
- Env0
- Scalr
- Digger
- Terramate
- ... 수십 개 기업

CNCF加入 (2023年9月)

OpenTofuは驚くべき速さでCNCF（Cloud Native Computing Foundation）Sandboxプロジェクトに加入しました。発表後わずか数週間での出来事です。

☁️ CNCFとは何か、なぜOpenTofuがそこに入ったのか

CNCF紹介

CNCFはLinux Foundation傘下の非営利団体です。Kubernetes、Prometheus、Envoy、Argo CD、Helmなど、クラウドネイティブエコシステムの核となるプロジェクトを抱える場所です。簡単に言えば、「クラウドネイティブ世界の公式ホーム」です。

CNCFプロジェクトになることの意味：

🔒 中立性の保証: 特定企業の利害関係から独立
💰 財政支援: インフラ、マーケティング、法務支援
🏛️ ガバナンス: 透明な意思決定構造
🌍 コミュニティ: グローバルな貢献者ネットワーク

OpenTofuがCNCFを選択した理由

OpenTofuの最大の危険は、「もう一つのHashiCorp」になることでした。最初はオープンソースで始まったが、後で商業的利害関係でライセンスを変更する、ということが繰り返される可能性があるからです。

CNCFへの加入は、この危険を構造的に遮断します。

いかなる単一企業もOpenTofuを「所有」することはできません
ライセンス変更はコミュニティ全体の合意なしには不可能です
MPL 2.0ライセンスは永久に維持されます

KubernetesがGoogleからCNCFに移管されたように、OpenTofuも同じ道を歩むのです。

🔄 OpenTofu vs Terraform — 現在どれくらい違うのか

初期にはほとんど同じでした。TerraformコードをそのままOpenTofuで使うことができました。しかし、時間が経つにつれて違いが生じています。

現在（2024〜2025年）の主な違い

機能 Terraform OpenTofu


ライセンス	BSL 1.1 (非オープンソース)	MPL 2.0 (オープンソース)
State暗号化	❌ 未サポート	✅ ネイティブサポート
Provider関数	制限的	拡張サポート
開発透明性	HashiCorp主導	コミュニティ主導
GitHub Stars増加傾向	鈍化	急上昇

特にStateファイル暗号化はOpenTofuのキラー機能です。TerraformのStateファイルは機密情報（パスワード、APIキーなど）が平文で保存される場合があり、セキュリティ上の懸念がありましたが、OpenTofuはこれをネイティブでサポートします。

# OpenTofu — State暗号化設定の例
terraform {
  # OpenTofuでは'terraform'ブロックをそのまま使用
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      method = method.aes_gcm.my_method
    }
  }
}

移行はどれくらい簡単か？

既存のTerraformユーザーであれば、ほとんどの場合、これだけで済みます。

# macOS (Homebrew)
brew install opentofu

# 既存のTerraformコマンドをtofuに置き換え
terraform init    →  tofu init
terraform plan    →  tofu plan
terraform apply   →  tofu apply
terraform destroy →  tofu destroy

# .tfファイルは修正なしでそのまま使用可能（ほとんどの場合）

.tfファイル内部のコードは、ほとんど修正する必要がありません。HCL文法自体が同じだからです。

⚠️ 注意事項 — OpenTofu導入時のチェックリスト

1. Provider互換性の確認 ほとんどのProviderは互換性がありますが、一部のエンタープライズ専用ProviderはHashiCorp Terraformにのみ最適化されている場合があります。導入前に必ず確認してください。

2. Terraform Cloud/Enterpriseを使用中の場合 HashiCorpのマネージドサービス（Terraform Cloud、Terraform Enterprise）との連携は、当然ながらTerraform専用です。OpenTofuに移行する場合、Spacelift、Env0、Scalr、Atlantisなどの代替案を検討する必要があります。

3. Stateファイル管理 既存のTerraform StateファイルはOpenTofuでそのまま読み取ることができます。しかし、OpenTofuのState暗号化機能を有効にすると、Terraformに戻ることが難しくなる場合があります。

4. チーム内でのバージョン統一 TerraformとOpenTofuをチーム内で混用すると混乱が生じます。移行時にはチーム全体が同時に移行することを推奨します。

🔭 OpenTofuの未来 — 楽観的である理由

HashiCorpのIBM買収 (2024年)

2024年、IBMがHashiCorpを約64億ドルで買収しました。このニュースは、OpenTofuコミュニティにとってむしろ好材料となりました。大企業の買収後、オープンソースポリシーがより制限的に変わる事例を数多く見てきたからです。OpenTofuへの移行を検討していた企業が、決断を下すきっかけとなりました。

急速な成長

GitHub Star数: 数万件突破（急速に増加中）
貢献者数: 数百人のグローバル開発者
企業スポンサー: 数十の主要テクノロジー企業
CNCF Incubating段階への昇格

コミュニティ主導の強み

OpenTofuは、Terraformが解決していなかった機能を迅速に追加しています。コミュニティから長年要望があったにもかかわらず、HashiCorpが優先順位をつけなかった機能です。State暗号化はその代表的な例です。

それでもTerraformを使うべき場合

OpenTofuは素晴らしいですが、まだTerraformを選択すべき状況もあります。

HashiCorpの公式エンタープライズサポートが必要な場合
Terraform Cloudと深く連携したワークフローを使用している場合
組織の規定上、CNCFプロジェクト以外の特定のベンダー公式サポートが必要な場合

✅ まとめ — オープンソースの自由はフォークで守られる


時期	出来事
2014年	HashiCorp、TerraformをMPL 2.0でオープンソースとしてリリース
2021年	HashiCorpナスダック上場
2023年8月	Terraform、ライセンスをBSL 1.1に変更すると発表
2023年8月	OpenTF Manifesto発表、数千人が署名
2023年9月	OpenTofu正式発足、CNCF Sandboxに加入
2024年	IBM、HashiCorp買収完了
2024〜2025年	OpenTofu、CNCF Incubatingに昇格し、独自機能を追加

Terraformは確かに偉大なツールであり、今もそうです。しかし、オープンソースの力は特定の企業ではなく、コミュニティにあることをOpenTofuは改めて証明しました。

次のステップとして推奨される学習方向：

OpenTofu公式ドキュメント: opentofu.org
CNCFプロジェクトエコシステムの理解
Terragrunt、AtlantisなどOpenTofuベースのワークフローツール
State暗号化の実践

IaCを初めて始める方には、今すぐOpenTofuから始めることをお勧めします。📦