OpenTofu 2026 - Terraformフォークの成熟と本番採用

OpenTofuとは何か

OpenTofu(オープントーフ)は、HashiCorpがTerraformのライセンスをMozilla Public License v2.0からBusiness Source License(BSL)に変更したことを受け、2023年8月にフォークされたオープンソースのInfrastructure as Code(IaC)ツールです。Gruntwork・Spacelift・Harness・Env0・Scalrなど主要IaCベンダーが結集し、Linux Foundationの支援を受けてCNCFプロジェクトとなりました。

2026年4月時点でGitHubスター数1万9800、コントリビューター企業50社超(OpenTofu公式サイト)を達成し、企業での本番採用が加速しています。Terraform BSLの制約から逃れつつ、既存の.tfファイルをそのまま使えるため、移行障壁が低いことが特徴です。

OpenTofu 2026の主要機能

1. State file暗号化(State Encryption)

OpenTofu 1.7で実装された最大の差別化要素がState暗号化です。Terraformでは、S3バケットが漏洩すると機密情報(データベースパスワード、APIキー)が平文で露出するリスクがありました。

# terraform.tofu(OpenTofu設定ファイル)
terraform {
  encryption {
    key_provider "aws_kms" "main" {
      kms_key_id = "arn:aws:kms:us-east-1:123456789012:key/abc-def"
      region     = "us-east-1"
    }

    method "aes_gcm" "state_encryption" {
      keys = key_provider.aws_kms.main
    }

    state {
      method = method.aes_gcm.state_encryption
    }

    plan {
      method = method.aes_gcm.state_encryption
    }
  }
}

この設定により、State fileがS3に保存される際にAES-GCM暗号化され、KMSキーなしでは復号不可能になります。Terraform公式ではこの機能が未実装のため、OpenTofu独自の優位性です。

2. Early Variable Evaluation

OpenTofu 1.8で導入された機能で、変数を評価してからbackend設定に渡せるようになりました。従来のTerraformでは、backendブロックで変数が使えず、環境ごとに設定ファイルを複製する必要がありました。

# variables.tofu
variable "environment" {
  type = string
}

variable "region" {
  type = string
}

# backend.tofu(OpenTofu 1.8以降)
terraform {
  backend "s3" {
    bucket = "mycompany-tfstate-${var.environment}" # 変数が使える!
    key    = "infrastructure/terraform.tfstate"
    region = var.region
  }
}

これにより、dev・staging・prodで単一の設定ファイルを使い回せ、DRY原則が徹底されます。

3. Provider互換性とRegistry

OpenTofuはTerraform Registry(registry.terraform.io)のProvider互換を保ちつつ、独自のOpenTofu Registryも運営しています。

# OpenTofu RegistryのProvider利用例
terraform {
  required_providers {
    aws = {
      source  = "opentofu/aws" # OpenTofu Registry
      version = "~> 5.0"
    }
  }
}

2026年4月時点で、AWS・GCP・Azure・Kubernetesなど3900超のProviderが移植済みです(OpenTofu公式発表)。

4. モジュール互換性

Terraform Moduleの99%以上がそのまま動作します(OpenTofu互換性レポート、2026年3月)。

# Terraform Module Registryのモジュールを利用
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"

  name = "my-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]
}

既存のTerraform Moduleエコシステムをそのまま活用でき、学習コストがゼロです。

Terraformからの移行手順

1. バージョン確認

OpenTofu 1.7以降はTerraform v1.5.x・v1.6.xのState fileを読み込み可能ですが、一度OpenTofuでapplyすると、Terraformで読めなくなる可能性があります。

# Terraformバージョン確認
terraform version
# Terraform v1.6.0

# OpenTofuインストール(Homebrew)
brew install opentofu

# バージョン確認
tofu version
# OpenTofu v1.9.0

2. State fileバックアップ

# State fileをローカルにダウンロード
terraform state pull > terraform.tfstate.backup

# S3バケットから直接バックアップ
aws s3 cp s3://my-bucket/terraform.tfstate ./backup/

3. 初回実行とPlan確認

# OpenTofuで初期化
tofu init

# Planでdiffがないことを確認
tofu plan
# No changes. Your infrastructure matches the configuration.

初回tofu planで差分が出ないことを確認すれば、移行成功です。

4. CI/CDパイプライン更新

# GitHub Actions例
name: OpenTofu Apply
on:
  push:
    branches: [main]
jobs:
  tofu:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup OpenTofu
        uses: opentofu/setup-opentofu@v1
        with:
          tofu_version: 1.9.0
      - name: Tofu Init
        run: tofu init
      - name: Tofu Plan
        run: tofu plan -out=plan.tfplan
      - name: Tofu Apply
        run: tofu apply plan.tfplan

AWS・GCP・Azure対応状況

AWS Provider

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws" # Terraform Registryも利用可能
      version = "~> 5.40"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

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

  tags = {
    Name = "OpenTofu-managed"
  }
}

AWS Provider v5.40以降はOpenTofu 1.8で完全動作確認済みです(AWS公式ドキュメント、2026年2月)。

GCP Provider

provider "google" {
  project = "my-gcp-project"
  region  = "us-central1"
}

resource "google_compute_instance" "vm" {
  name         = "opentofu-vm"
  machine_type = "e2-micro"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = "default"
  }
}

Google Cloud Provider v5.x系はOpenTofu 1.7以降で公式サポートされています。

Azure Provider

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "rg" {
  name     = "opentofu-resources"
  location = "East US"
}

resource "azurerm_virtual_network" "vnet" {
  name                = "opentofu-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

AzureRM Provider v3.x系は問題なく動作し、v4.x系も2026年Q2対応予定です(OpenTofu Roadmap)。

Pulumi・AWS CDKとの比較

PulumiはTypeScriptで柔軟な条件分岐が書ける一方、State管理が複雑です。AWS CDKはAWS専用で、マルチクラウド戦略には不向きです。

GitOpsとの統合

Atlantisによる自動化

# atlantis.yaml
version: 3
projects:
  - name: production
    dir: environments/prod
    workflow: custom
    autoplan:
      when_modified: ["*.tofu", "*.tfvars"]
workflows:
  custom:
    plan:
      steps:
        - run: tofu init
        - run: tofu plan -out=plan.tfplan
    apply:
      steps:
        - run: tofu apply plan.tfplan

GitOpsパターンでは、Pull Request作成時にtofu planが自動実行され、承認後にapplyされる運用が一般的です。

Terragrunt対応

# terragrunt.hcl
terraform {
  source = "git::https://github.com/myorg/infrastructure.git//modules/vpc"
}

inputs = {
  vpc_cidr = "10.0.0.0/16"
  environment = "prod"
}

TerragruntはOpenTofu 1.8以降で公式対応し、DRYなモジュール管理が可能です。

実践的なユースケース

ケース1: Kubernetes基盤構築

# EKSクラスター作成
module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "opentofu-eks"
  cluster_version = "1.33"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    main = {
      min_size     = 2
      max_size     = 10
      desired_size = 3

      instance_types = ["t3.medium"]
    }
  }
}

Kubernetes 1.33クラスターをOpenTofuで管理し、ノードグループのスケーリングを自動化できます。

ケース2: マルチリージョンDR構成

# primary region
module "primary" {
  source = "./modules/infrastructure"

  region      = "us-east-1"
  environment = "prod"
}

# DR region
module "dr" {
  source = "./modules/infrastructure"

  region      = "us-west-2"
  environment = "prod-dr"
}

# Route53でフェイルオーバー
resource "aws_route53_record" "failover_primary" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "app.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  alias {
    name                   = module.primary.alb_dns_name
    zone_id                = module.primary.alb_zone_id
    evaluate_target_health = true
  }

  set_identifier = "primary"
}

ケース3: State暗号化によるコンプライアンス対応

# PCI-DSS準拠のState暗号化設定
terraform {
  encryption {
    key_provider "vault" "pci" {
      address   = "https://vault.example.com"
      token     = var.vault_token
      key_name  = "terraform-state-key"
      namespace = "compliance"
    }

    method "aes_gcm" "pci_encryption" {
      keys = key_provider.vault.pci
    }

    state {
      method   = method.aes_gcm.pci_encryption
      enforced = true # 暗号化を強制
    }
  }

  backend "s3" {
    bucket = "pci-compliant-tfstate"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
  }
}

トラブルシューティング

State file互換性問題

# エラー例
Error: state snapshot was created by OpenTofu v1.8.0, which is newer than current v1.7.0

# 解決策: OpenTofuをアップグレード
brew upgrade opentofu

Provider互換性

# 一部のProviderがOpenTofu非対応の場合
terraform {
  required_providers {
    custom = {
      source  = "custom/provider"
      version = "1.0.0"
    }
  }
}

# Terraform Registryからミラーリング
provider_installation {
  filesystem_mirror {
    path    = "/usr/local/share/terraform/providers"
    include = ["custom/*"]
  }
}

Platform Engineeringとの統合

Platform Engineeringの文脈では、OpenTofuを内部開発者ポータル(IDP)と統合する事例が増えています。

# Backstage Software Templateとの統合
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: opentofu-infrastructure
spec:
  steps:
    - id: tofu-apply
      name: Apply Infrastructure
      action: opentofu:apply
      input:
        workspace: ${{ parameters.environment }}
        vars:
          app_name: ${{ parameters.appName }}

よくある質問

OpenTofuはTerraformの完全互換ですか?
Terraform v1.5.x・v1.6.xとは99%互換ですが、v1.7以降はHashiCorp独自機能が追加されており、一部互換性がありません。逆に、OpenTofu独自機能(State暗号化・Early Evaluation)はTerraformで使えません。

本番環境での実績はありますか?
2026年4月時点で、Gruntwork・Spacelift・Scalrなど主要IaCベンダーが本番採用しています。AWS・GCP・Azureでの動作実績も十分あり、金融・医療業界での採用事例も報告されています。

TerraformとOpenTofuは並行利用できますか?
技術的には可能ですが、State fileの互換性に注意が必要です。一度OpenTofu 1.7+でapplyしたStateは、Terraform v1.6以前で読めない場合があります。完全移行を推奨します。

まとめ

OpenTofu 2026は、Terraformのオープンソース版として成熟し、本番採用が加速しています。以下のポイントを再確認します。

• CNCF傘下で50社超がコントリビュートする信頼性
• State暗号化でセキュリティ強化、コンプライアンス対応が容易
• 3900 Provider・23600 ModuleでTerraformエコシステム継承
• HashiCorp BSLの制約なく商用利用可能

Terraform v1.6以前からの移行は技術的リスクが低く、ライセンスリスクを回避できます。新規プロジェクトではOpenTofuを第一候補として検討する価値があります。

参考リソース

• OpenTofu公式サイト - ドキュメント・移行ガイド
• OpenTofu State Encryption - State暗号化の設定詳細
• OpenTofu vs Terraform 2026 - 移行判断の指針
• OpenTofu Registry - Provider・Module検索