Terraform variable validationで入力値を堅牢にする: 入力値の検証ルールをAssociate/Pro視点で整理

variable validationは、型制約では表しきれないビジネスルールをTerraform言語で宣言的に検査する機能です。エラーメッセージを明示でき、モジュールの再利用性と安全性を高めます。

Associateでは基本構文・評価タイミング、Proではコレクション/条件付き/unknownの扱いが頻出。実務でもmoduleの入口で落とせる設計が保守コストを下げます。

variable validationの基本と評価タイミング

variableブロック内のvalidationは、conditionがtrueであることを要求し、falseの場合にerror_messageの内容で失敗させます。conditionはTerraform言語の式で、var.<name>を参照します。

評価タイミングは「その変数の最終値が既知になった時点」。通常はplan時に既知で評価され、結果が偽ならplan自体がエラーで停止します。値がunknown（例: data source依存）で条件結果が不定な場合は、明確にfalseと判定できない限り適用時まで猶予されます。

• 宣言的・副作用なし: 外部コマンド実行やリソース参照は不可
• 型制約と併用が前提: typeで粗く、validationで細かく
• エラーメッセージは利用者向けに具体的に（期待値と例を含める）
• 入力ソース（-var, tfvars, 環境変数, Cloud/Enterpriseの変数）を問わず同一に適用

評価パイプライン（概念図）

最小構成の例

variable "image_id" {
  type = string

  validation {
    condition     = can(regex("^ami-[0-9a-f]+

      

        
        NicheeLab を読み込み中…
      
    
  quot;, var.image_id))
    error_message = "image_id は 'ami-' で始まる有効なAMI IDを指定してください。例: ami-0123abcd";
  }
}

文法とベストプラクティス

validationブロックはcondition（必須）とerror_message（必須）から構成されます。conditionは純粋式であり、関数・演算子・for式を使って書けます。エラーメッセージは利用者が即修正できる粒度で短く具体的に。

正規表現や数値範囲など失敗しやすい判定はcan()でガードし、不正形式でregexがエラーになるのを防ぎます。重い計算や大きなコレクション走査は最小限に保ち、読みやすく維持しやすい表現を心がけます。

• まずtypeで大枠を絞り、validationでビジネスルールを追加
• regexはcan()で保護: can(regex(pattern, s))
• 複合条件は論理積/含意（AならB）で短く: (env != "prod" || count >= 3)
• メッセージは期待形・制約範囲・例を含める

エラーメッセージ設計の観点

よくあるガードの書き方

variable "account_id" {
  type = string
  validation {
    condition     = can(regex("^[0-9]{12}

      

        
        NicheeLab を読み込み中…
      
    
  quot;, var.account_id))
    error_message = "account_id は12桁の数字で指定してください。";
  }
}

variable "port" {
  type = number
  validation {
    condition     = var.port >= 1 && var.port <= 65535
    error_message = "port は1〜65535の範囲で指定してください。";
  }
}

文字列・数値の代表的な検証パターン

シンプルなパターンは可読性を重視します。接頭辞検査はstartswith、厳密な形式はregex、レンジは単純な比較で表現します。

regexはメンテナンス性を損ねやすいので、必要十分に留め、代替があればなるべくstartswithやlengthで置き換えます。

• 接頭辞: startswith(var.id, "ami-")
• 範囲: var.replicas >= 2 && var.replicas <= 10
• 最小長: length(var.name) >= 3
• 列挙: contains(["dev","stg","prod"], var.env)

パターン選択の目安

サンプル: ポートとAMI

variable "port" {
  type = number
  validation {
    condition     = var.port >= 1 && var.port <= 65535
    error_message = "port は1〜65535です。";
  }
}

variable "ami" {
  type = string
  validation {
    condition     = can(regex("^ami-[0-9a-f]+

      

        
        NicheeLab を読み込み中…
      
    
  quot;, var.ami))
    error_message = "ami は 'ami-'で始まる有効なIDを指定してください。";
  }
}

コレクション/複合型の検証

listやmap/objectではfor式とalltrue/anytrueで各要素をまとめて検査します。重複禁止はdistinctで実現できます。

タグやキーの長さ・文字種制約などは読みやすい単位に分解して条件式を構成すると保守しやすくなります。

• 全要素の接頭辞検査: alltrue([for s in var.subnets : startswith(s, "subnet-")])
• 重複禁止: length(distinct(var.names)) == length(var.names)
• 許容セット: alltrue([for e in var.envs : contains(["dev","stg","prod"], e)])
• mapのキー/値長さ: alltrue([for k, v in var.tags : length(k) <= 128 && length(v) <= 256])

for式で要素を検査する流れ

サンプル: サブネットIDとタグ

variable "subnets" {
  type = list(string)
  validation {
    condition     = length(var.subnets) > 0 && alltrue([for s in var.subnets : startswith(s, "subnet-")])
    error_message = "subnets は1件以上、各要素は 'subnet-'で始まるIDで指定してください。";
  }
}

variable "tags" {
  type = map(string)
  validation {
    condition     = alltrue([for k, v in var.tags : length(k) <= 128 && length(v) <= 256])
    error_message = "tags のキーは128文字以内、値は256文字以内で指定してください。";
  }
}

variable "names" {
  type = list(string)
  validation {
    condition     = length(distinct(var.names)) == length(var.names)
    error_message = "names は重複のない値で指定してください。";
  }
}

条件付き検証と未知値(unknown)の扱い

条件付き検証は「含意」で表現すると読みやすくなります。例えばprodのときだけ強い制約を課すなら、env != "prod" || 厳格条件 の形にします。

unknown値（計画時に未確定の値）が関係する場合、Terraformは条件が明確にfalseと断定できない限りエラーにしません。regexなど不正形式で式自体が評価エラーになる恐れがある箇所はcan()で包んで安全に。

• 含意の定石: (条件Aでなければ許可) または (条件Aなら制約B)
• unknownを誤って評価エラーにしない: can()で防御
• 外部リソース属性やデータソース値に依存させない（そもそも参照不可）

unknownの評価イメージ

prodのときだけ強い制約をかける

variable "env" {
  type = string
  validation {
    condition     = contains(["dev","stg","prod"], var.env)
    error_message = "env は dev/stg/prod のいずれかです。";
  }
}

variable "az_count" {
  type = number
  validation {
    condition     = var.env != "prod" || var.az_count >= 2
    error_message = "env=prod の場合、az_count は2以上である必要があります。";
  }
}

試験対策: 出題ポイントとアンチパターン

試験では、type制約とvalidationの役割差、precondition/postconditionとの違い、評価タイミング、unknownの扱いが問われがちです。validationは入力値に対する静的な検査であり、リソース属性やデータソース結果を参照できません。

アンチパターンは、複雑な正規表現で可読性を損なう、外部状態に依存させる、エラーメッセージが抽象的すぎる、など。まず型で絞り、シンプルな関数で十分な安全性を確保しましょう。

• validationはvariableブロック内。resourceの状態検査はprecondition/postconditionを使う
• resource属性やdataの参照は不可（variableスコープ外）
• 複数条件は読みやすく分割。can()で評価エラーを未然に防ぐ
• メッセージは修正指針を含める（期待値・範囲・例）

Do/Don'tメモ

[OK] typeで大枠 → validationで細則
[OK] envに応じた含意で条件分岐
[NG] resource属性やdataをvalidationで参照
[NG] 複雑すぎるregexで可読性を損なう

アンチパターン修正例

# 悪い例（resource属性参照は不可）
# variable "size" {
#   validation {
#     condition     = var.size <= aws_instance.example.cpu_core_count  # 参照不可
#     error_message = "...";
#   }
# }

# 良い例: 入力間の関係をvalidationで、リソース状態はpreconditionで
variable "size" {
  type = number
  validation {
    condition     = var.size >= 1 && var.size <= 64
    error_message = "size は1〜64で指定してください。";
  }
}

# （参考）resource側での状態検査はprecondition/postconditionを使用
# resource "aws_instance" "example" {
#   # ...
#   lifecycle {
#     precondition {
#       condition     = self.cpu_core_count >= var.size
#       error_message = "インスタンスタイプが size を満たしていません。";
#     }
#   }
# }

問題で確認

よくある質問