Terraform Cloud の No-Code Modules で実現するセルフサービス配布（Pro向け実務パターン）

No-Code Modules は、Terraform Cloud/Enterprise の Private Registry から、UIベースでワークスペースを生成・実行できる配布形態です。利用者はHCLを触らずに変数を入力するだけでプロビジョニングでき、提供者はバージョン管理・入力検証・ポリシーでガードレールを維持できます。

本稿では、モジュールのNo-code ready化、Private Registryでのセルフサービス配布、権限・ポリシー設計、運用パターンまでを実務視点で整理します。Pro試験での頻出観点（Private Registry、Sentinelポリシー、Variable Sets、Run Tasks、RBAC）も意識した内容です。

No-Code Modules の概要とメンタルモデル

No-Code Modules は、Private Registry に公開されたモジュールを「No-code ready」としてマークし、利用者がUIからワークスペースを生成して実行する仕組みです。利用者はHCLを直接編集せず、モジュール作者が公開した入力（variables）だけをUIで指定します。ワークスペースはモジュールのソース・バージョンを参照し、Plan→Policy Check→Apply の標準パイプラインで実行されます。

利点は、利用者の習熟度に依存せずに安全なセルフサービスを広げられる点です。提供者は型定義・validation・デフォルト値・必須/任意の見極め・出力定義・Sentinel/Run Tasks・Variable Setsでガードレールを掛け、安定した配布面を整備します。

• 提供者はモジュールに入力仕様と検証を埋め込み、Private Registryへバージョン付きで公開
• 利用者はUIからワークスペースを作成し、公開変数だけを入力して実行
• Policy Check（Sentinel）はPlan後、Apply前に評価
• 更新は「モジュールの新バージョン公開」→「利用ワークスペースでバージョン切替」という二段階

No-Code Modules によるセルフサービス配布の流れ

モジュール側の入力定義（variables.tf）でNo-code readyを意識する例

variable "name" {
  type        = string
  description = "リソースの識別子。組織内で一意となるプレフィックスを推奨"
  validation {
    condition     = can(regex("^[a-z][a-z0-9-]{2,20}

      

        
        NicheeLab を読み込み中…
      
    
  quot;, var.name))
    error_message = "name は英小文字開始、英数字とハイフンのみ、3〜21文字で指定してください。"
  }
}

variable "tags" {
  type        = map(string)
  description = "共通メタデータ（コストセンター等）"
  default     = {}
}

variable "environment" {
  type        = string
  description = "環境識別子"
  default     = "dev"
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "environment は dev / staging / prod のいずれかを指定してください。"
  }
}

モジュールのNo-code ready化：入力・検証・出力・バージョニング

No-Code Modules での体験品質は、モジュールの入力設計に直結します。必須入力は最小限に抑え、その他は妥当なデフォルト値・型・validationで安全域を広げます。sensitive変数やprovider認証はVariable Setsに委譲し、利用者が秘匿値を個別に持たない構成が実運用で安定します。

出力（outputs）は後続の参照（例: 接続情報、ID、エンドポイント）を想定して名前と説明を明確にします。READMEとexamplesはPrivate RegistryのUIに表示されるため、利用者がUIだけで完結できる説明を用意します。モジュールのバージョンはセマンティックバージョニングを心掛け、破壊的変更はmajorで示すと、利用側の計画的なアップグレードに寄与します。

• variables: type/nullable/sensitive/validation を明示
• outputs: 利用者が次に何を参照すべきかを説明に含める
• README: 入力表、出力表、前提条件（Variable Sets/権限）をUIで読める形で記述
• バージョニング: 破壊的変更はmajor、後方互換はminor/patch

出力定義（outputs.tf）の例

output "vpc_id" {
  description = "作成されたVPCのID"
  value       = aws_vpc.this.id
}

output "subnet_ids" {
  description = "作成サブネットのID一覧"
  value       = aws_subnet.this[*].id
}

output "endpoint" {
  description = "サービスのエンドポイント（例: ALB DNS名）"
  value       = try(aws_lb.this.dns_name, null)
}

Private Registry配布と権限設計：セルフサービスの踏み台を作る

Private Registryにモジュールを公開し、No-code readyを有効化すると、利用者はカタログからワークスペースを作成できます。実務では、ワークスペース作成権限、プロジェクト単位のRBAC、Variable Setsの割当、ポリシーセットの適用を事前に仕込むことで、セルフサービスの“踏み台”を整えます。

Variable Setsにはクラウド認証情報や共通タグ、地域などの組織既定値を格納します。ポリシーセットは組織もしくはプロジェクト・タグ単位で適用し、コスト上限・リージョン制限・命名規則などを強制または助言レベルで運用します。

• プロジェクトでワークスペース作成権限を限定しつつ、Registryは広く閲覧可にしてセルフサービス促進
• Variable Setsで認証情報・共通変数を一括適用（環境毎のセットを用意）
• Policy Set（Sentinel）はorg/project/tag単位で紐付け、強制/ソフト/アドバイザリを使い分け
• Run Tasksでセキュリティ検査やコスト検査をPlan/Apply前に連携

Terraform（TFE provider）で踏み台を自動化する例

terraform {
  required_providers {
    tfe = {
      source  = "hashicorp/tfe"
      version = ">= 0.51"
    }
  }
}

provider "tfe" {}

resource "tfe_project" "app" {
  name = "app-svc"
}

resource "tfe_variable_set" "env_dev" {
  name         = "env-dev-common"
  organization = var.organization
  description  = "dev環境の共通変数（認証・タグ等）"
}

resource "tfe_variable" "cc" {
  key             = "cost_center"
  value           = "CC-1001"
  category        = "terraform"
  variable_set_id = tfe_variable_set.env_dev.id
}

resource "tfe_workspace" "nc_wsp" {
  name         = "app-svc-dev-001"
  organization = var.organization
  project_id   = tfe_project.app.id
  tag_names    = ["no-code", "dev"]
  execution_mode = "remote"
  assessments_enabled = true

  no_code { # No-Code Modules由来のワークスペース設定用ブロック（提供環境で利用可能な場合）
  }
}

resource "tfe_workspace_variable_set" "attach" {
  workspace_id   = tfe_workspace.nc_wsp.id
  variable_set_id = tfe_variable_set.env_dev.id
}

resource "tfe_policy_set" "guardrails" {
  name         = "org-guardrails"
  organization = var.organization
  kind         = "sentinel"
  # policyのVCS連携等は省略(安定機能)
}

resource "tfe_policy_set_attachment" "attach_project" {
  policy_set_id = tfe_policy_set.guardrails.id
  project_id    = tfe_project.app.id
}

variable "organization" { type = string }

ポリシーとガードレール：Sentinel/Run Tasks/変数セットの使い所

Terraform Cloud/Enterpriseでは、Plan完了後、Apply前にPolicy Checkステップが実行されます。Sentinelで強制（hard-mandatory）/ソフト（soft-mandatory）/アドバイザリ（advisory）を使い分け、No-Code Modulesの適用可否や勧告を制御します。Run Tasksは外部スキャナやコストツールをPlan/Apply前に呼び出し、品質を担保します。

変数設計はガードレールの第一歩です。入力の型・バリデーション・既定値で逸脱を最小化し、Variable Setsで認証や共通タグ・リージョンを固定化します。Policyで例外承認のフローを用意すれば、セルフサービスの速度と統制の両立が可能です。

• Policy CheckはPlan後/Apply前。評価に通らないとApply不可（強制時）
• advisoryは警告を出すがApply可能、softは承認次第で許可、hardはブロック
• Run TasksはPlan/Applyの任意ポイントで外部チェックを挿入
• 変数のvalidationとSentinelを併用し、UI入力ミスと設計逸脱を二重で抑止

シンプルなSentinelポリシー例（特定リージョンのみ許可）

# Sentinel policy: aws_region_only.sentinel
import "tfplan/v2" as tfplan

allowed = ["ap-northeast-1", "ap-northeast-2"]

main = rule {
  all tfplan.module_paths as path {
    all tfplan.resources[path] else {} as rtype, rname, r {
      all r.applied as change {
        not ("region" in change) or (change.region in allowed)
      }
    }
  }
}

# 評価はPlan後、Apply前に行われる（Terraform Cloud/Enterpriseの標準動作）

実装パターン：ネットワーク基盤、アカウント初期化、DBプロビジョニング

よくあるセルフサービスは、ネットワーク基盤（VPC/サブネット/ルーティング）、アカウント初期化（IAMロール/監査/タグ）、マネージドDB（サイズ・バックアップ・接続情報出力）です。No-Code Modulesでは、これらを用途別に小さく分割し、組織既定のタグ・命名規則・リージョンを固定することで、安全に横展開できます。

各モジュールは共通インターフェース（name、environment、tags、regionなど）を揃え、出力をつなぎやすくします。バージョン固定とリリースノートを徹底し、破壊的変更の周知とロールアウト計画を運用手順に組み込みます。

• ネットワーク基盤: CIDR重複をvalidationで抑止、リージョン固定はVariable Setsで
• アカウント初期化: 監査ロール/ログバケット等を必須化し、出力はARN/IDを明示
• DB: サイズ・暗号化・自動バックアップを変数で露出しつつ、最小値をvalidationで担保
• 共通: outputsで接続情報を明示し、他ワークスペースへ引き継ぎやすくする

モジュールの内部（例）: VPCを作るmain.tf（抜粋）

resource "aws_vpc" "this" {
  cidr_block           = var.cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = merge(var.tags, {
    Name        = "${var.name}-vpc"
    Environment = var.environment
  })
}

resource "aws_subnet" "this" {
  for_each          = var.subnets
  vpc_id            = aws_vpc.this.id
  cidr_block        = each.value
  map_public_ip_on_launch = false
  tags = merge(var.tags, { Name = "${var.name}-${each.key}" })
}

variable "cidr" { type = string }
variable "subnets" { type = map(string) }

運用と試験対策：更新、ロールバック、よくある落とし穴

更新は「モジュールの新バージョンをPrivate Registryに公開」→「各ワークスペースでバージョンを切替」の順序です。No-Code Modulesの利用者はHCLを触らないため、提供者は破壊的変更を避け、migrationガイドをREADMEに含めます。万一のロールバックは、ワークスペースで旧バージョンを再選択し再実行します。

Pro試験観点では、Private Registry、No-Code Modules、Policy Checkの評価タイミング、Variable Sets、Run Tasks、RBAC（プロジェクト・チーム）を正しく関連付けて説明できることが重要です。特に、Policy CheckがPlanの後・Applyの前に評価される点、Variable Setsは複数ワークスペースへ横断適用できる点は頻出です。

• 破壊的変更はmajorで明示。利用側の手順書とセットで公開
• ロールバックはワークスペース側のモジュールバージョンを戻すだけでよい設計にする
• Policy Setの強制度（advisory/soft/hard）と適用単位（org/project/tag）を整理
• Variable Setsで認証を配布し、利用者に秘匿値を入力させない

推奨のterraformブロック（互換性と再現性の明示）

terraform {
  required_version = ">= 1.4.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
}

provider "aws" {
  region = var.region
}

variable "region" {
  type        = string
  description = "Variable Setsで組織既定を配布することを推奨"
}

問題で確認

よくある質問