HCP Terraform No Code Moduleのバージョン指定を考えてみる

HCP Terraform No Code Moduleのバージョン指定を考えてみる

Clock Icon2025.06.11

No Code Moduleは、利用者がTerraformコードを書かずにTerraformでリソースをデプロイできる機能です。

この特性から、通常のTerraformと同じようにバージョン指定をすると不便なことがあります。

今回は、No Code ModuleのTerraform・Providerバージョン制約のおすすめ設定方法を紹介します。

結論

メジャーバージョン マイナーバージョン パッチバージョン 設定例
Terraform 固定 最新 最新 >= 1.12.0
Provider 固定 固定 最新 ~> 5.99.0

tfファイルにすると以下のような形です。

terraform.tf
terraform {
  required_version = ">= 1.12.0"
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.99.0"
    }
  }
}

No Code Moduleの特徴

No Code Moduleには、以下の特徴があります。

  • 再利用可能なモジュール
  • ルートモジュール(呼び出し元のコードは存在しない)

通常のモジュールだと、ルートモジュールから呼び出して使います。

しかし、No Code Moduleでは呼び出し元のコードが存在せず、ルートモジュール的な役割もあると思います。

ここで、公式ドキュメントをみてみましょう。

Reusable modules should constrain only their minimum allowed versions of Terraform and providers, such as >= 0.12.0. This helps avoid known incompatibilities, while allowing the user of the module flexibility to upgrade to newer versions of Terraform without altering the module.
Root modules should use a ~> constraint to set both a lower and upper bound on versions for each provider they depend on.

Version Constraints - Configuration Language | Terraform | HashiCorp Developer

以下のように解釈しました。

  • 再利用可能なモジュール: >=を使用。最小バージョンを制約。
  • ルートモジュール: ~>を使用。バージョンの下限と上限を設定。

No Code Moduleはどちらの特徴も持ちます。どちらに従うべきか迷います。

TerraformバージョンとProviderバージョンで分けて考えてみます。

Terraformバージョン: Terraformバージョン制約によるRunの失敗回避

No Code Moduleを利用して作成されるWorkspaceは、その時点の最新のTerraformバージョンが指定されます。(2025/6時点)

この動作は、No Code Moduleのtfファイルにrequired_versionの設定が含まれていても関係ありません。

以下のように設定していても、その時点で1.12.0が最新だと1.12.0がWorkspaceに設定されます。

terraform.tf
terraform {
  required_version = "~> 1.10.0"
}

このままRunが行われると~> 1.10.0の制約では、1.10.3は許容しますが1.12.0は許容できません。

そのためエラーになり、Runが失敗します。

Workspace作成後にWorkspaceのTerraformバージョンは変更可能です。

今回であれば、1.10.0に設定してRunを再実行すればエラーは解消されます。

No Code Moduleのコンセプトとして、Terraformを分からない人でもTerraform経由でリソースを作成できることがあると思います。

そういったユーザーは、Workspaceのバージョン変更もハードルが高いように思います。単純に手間でもあります。

上記からTerraformバージョンはメジャーバージョン固定・マイナーバージョン・パッチバージョン最新(例: >= 1.10.0)をおすすめします。

Providerバージョン: 意図しない変更を防ぐ

Providerバージョンに関しては、required_providers.versionに従ってバージョンが設定されます。

バージョン指定可能・安定性を確保するために、パッチバージョンだけ最新化(例: ~> 5.99.0)することをおすすめします。

マイナーバージョンを最新にした場合(例: >= 5.99.0)も考えてみます。

ユーザーが作成した時点の最新のマイナーバージョンが適用されます。

作成タイミングによっては、5.100.0 5.99.0 5.101.0のように同じ No Code ModuleでもProviderバージョンが異なることになります。

マイナーバージョンは基本的には後方互換性があります。

しかし、Providerによってはマイナーバージョン内にBREAKING_CHANGEが含まれていることもあり、特定バージョンでは既存のコードで動かなくなることもありえます。

マイナーバージョンのアップデートのタイミングはコントロールできたほうが運用しやすいです。(マイナーバージョン固定)

おわりに

No Code Moduleは、ModuleとついているのでModuleと同じようにバージョン制約を考えたくなります。

しかし、呼び出し元のコードが無くルートモジュール的な面もあります。

作成されるWorkspaceのTerraformバージョンがモジュールのコード内で指定可能になったら、Terraform・Providerどちらもパッチバージョンで指定するのが良さそうです。

今後のアップデートに期待ですね。

以上、AWS事業本部の佐藤(@chari7311)でした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.