Terraform を書いていると、変数の値がどう展開されるか、関数が期待通り動くかをその場で確認したい場面が頻繁にある。apply を繰り返すのはリスクがあり、plan でさえ AWS API を呼ぶため数十秒かかることも多い。
この記事では、
terraform console コマンドを使って HCL 式を対話的に評価・検証する方法を解説する。変数の参照・組み込み関数のテスト・条件式・for 式のデバッグまで、実際のコマンド出力例を交えて説明する。動作確認環境: Terraform 1.7.5 / Rocky Linux 9.3
この記事のポイント
・terraform console でHCL式をplan不要で対話確認できる
・var.変数名・local値・data sourceも console で参照可能
・cidrsubnet・jsonencode・formatlist等の関数をその場で試せる
・for式・条件式のデバッグに console は特に効果的
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
terraform consoleとは何か
terraform console は、Terraform に組み込まれた対話型 REPL(Read-Eval-Print Loop)コマンドだ。HCL の式を入力するとその場で評価結果が返ってくる。通常の terraform ワークフローでは、コードを書いて → plan → apply と進む。しかし「この変数がどんな値になるか」「この関数の戻り値は何か」を確認したいだけのために plan を実行するのは効率が悪い。console はその問題を解決するデバッグツールだ。
console の特徴をまとめると次のとおり。
・HCL 式をその場で評価できる:変数・関数・条件式・for 式すべて対応
・state を参照できる:terraform.tfstate が存在する場合、var や data source の値も参照可能
・AWS API は呼ばない:plan と異なり、クラウドへの通信なしで式評価のみ行う(data source は一部例外)
・破壊的操作はできない:console はあくまで読み取り・評価専用。リソースへの変更は一切しない
terraform consoleの基本的な使い方
1. 起動と終了
terraform console は、.tf ファイルが置いてあるディレクトリで起動する。# terraform console を起動する $ cd /path/to/terraform-project $ terraform console >
> が表示されたら入力待ち状態だ。終了するには exit または Ctrl+D を入力する。> exit $
2. 変数(var)を参照する
variables.tf に次のように変数が定義されている場合を例にとる。# variables.tf variable "region" { default = "ap-northeast-1" } variable "instance_type" { default = "t3.micro" }
var.変数名 で値を参照できる。> var.region "ap-northeast-1" > var.instance_type "t3.micro"
terraform.tfvars または -var-file で値を渡してから console を起動すれば参照できる。# tfvars を明示して起動する場合 $ terraform console -var-file=dev.tfvars > var.env "dev"
3. ローカル値(local)を評価する
locals ブロックで定義した値も console で確認できる。特に複雑な式や文字列連結を使った local 値は、console で展開結果を先に確認してから .tf ファイルに書くと安全だ。# main.tf locals { name_prefix = "${var.env}-${var.project}" tags = { Environment = var.env ManagedBy = "Terraform" } }
> local.name_prefix "dev-myapp" > local.tags { "Environment" = "dev" "ManagedBy" = "Terraform" }
組み込み関数を対話的に確認する
terraform console が最も力を発揮するのが、組み込み関数のデバッグだ。ドキュメントを読んでも引数の順序や戻り値の型が分かりにくい関数も、console で試しながら確認できる。1. 文字列・数値系関数
よく使う文字列・数値系の関数を console で確認する例を示す。# 文字列操作 > upper("ap-northeast-1") "AP-NORTHEAST-1" > replace("my-bucket-dev", "dev", "prod") "my-bucket-prod" > substr("terraform-console", 0, 9) "terraform" > split("-", "ap-northeast-1") tolist([ "ap", "northeast", "1", ]) # 数値操作 > max(10, 50, 30) 50 > length(["a", "b", "c"]) 3
2. ネットワーク系関数(cidrsubnet・cidrhost)
VPC やサブネットの CIDR 計算を手作業でミスするエンジニアは多い。cidrsubnet と cidrhost は console で確かめてから .tf ファイルに書くべき関数だ。# cidrsubnet(prefix, newbits, netnum) # 10.0.0.0/16 を /24 に分割したとき、インデックス 0 のサブネット > cidrsubnet("10.0.0.0/16", 8, 0) "10.0.0.0/24" # インデックス 1 のサブネット > cidrsubnet("10.0.0.0/16", 8, 1) "10.0.1.0/24" # インデックス 2 のサブネット(ap-northeast-1c 用など) > cidrsubnet("10.0.0.0/16", 8, 2) "10.0.2.0/24" # cidrhost でサブネット内の特定ホストのIPを計算 > cidrhost("10.0.1.0/24", 10) "10.0.1.10"
newbits の値を間違えると意図しない CIDR になる。plan の前に console で確認する習慣を付けると、サブネット設計のミスを事前に防げる。3. エンコード系関数(jsonencode・yamldecode)
IAM ポリシーや ECS タスク定義など、JSON を HCL 内で扱う場面でjsonencode は必須だ。> jsonencode({ Version = "2012-10-17" Statement = [ { Effect = "Allow" Action = "s3:GetObject" Resource = "arn:aws:s3:::my-bucket/*" } ] }) "{\"Statement\":[{\"Action\":\"s3:GetObject\",\"Effect\":\"Allow\",\"Resource\":\"arn:aws:s3:::my-bucket/*\"}],\"Version\":\"2012-10-17\"}"
templatefile 関数も console で変数展開結果を確認できる。テンプレートファイルが正しく展開されるかを apply 前に検証するのに使う。# user_data.sh.tpl が存在する場合 > templatefile("user_data.sh.tpl", { region = var.region bucket = "my-config-bucket" }) "#!/bin/bash\naws s3 cp s3://my-config-bucket/setup.sh /tmp/setup.sh --region ap-northeast-1\nbash /tmp/setup.sh\n"
実務デバッグパターン
1. 条件式(三項演算子)の動作確認
Terraform の条件式は条件 ? 真の値 : 偽の値 の形式だ。複雑な条件を組み合わせた場合、console で評価結果を事前に確認しておくと安全だ。# 変数 env が "prod" かどうかで instance_type を切り替える条件式 > var.env == "prod" ? "t3.large" : "t3.micro" "t3.micro" # 複合条件:env が prod かつ region が東京の場合 > (var.env == "prod" && var.region == "ap-northeast-1") ? "m5.xlarge" : "t3.micro" "t3.micro" # null チェック > var.custom_ami != null ? var.custom_ami : "ami-0d3a0b0e1b8f1e3b1" "ami-0d3a0b0e1b8f1e3b1"
2. for式とリスト操作の検証
for 式は強力だが、構文ミスや意図しない型変換でエラーになりやすい。console でリスト・マップ操作の結果を確認してから .tf ファイルに書くのが安全な進め方だ。# リストをマップに変換(for 式) > {for s in ["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"] : s => true} { "ap-northeast-1a" = true "ap-northeast-1c" = true "ap-northeast-1d" = true } # リスト要素をフィルタリング > [for s in ["web", "app", "db"] : s if s != "db"] [ "web", "app", ] # マップのキーだけを取り出す > keys({a = 1, b = 2, c = 3}) [ "a", "b", "c", ] # リストの各要素を大文字に変換 > [for s in ["web", "app"] : upper(s)] [ "WEB", "APP", ]
3. data sourceの参照確認(state が必要)
terraform init と terraform refresh(または terraform plan -refresh-only)実行後であれば、console から data source の値も参照できる。# main.tf に data "aws_vpc" "main" {} が定義済みで state にある場合 > data.aws_vpc.main.id "vpc-0a1b2c3d4e5f67890" > data.aws_vpc.main.cidr_block "10.0.0.0/16"
terraform refresh で更新してから console を使うこと。トラブルシュート・エラー対処
【注意】console で確認できた値でも、state が古い場合は本番環境と食い違うことがある。重要な変更は必ずterraform plan で最終確認してから apply すること。console はあくまで「式の評価を確認するツール」であり、本番確認の代わりにはならない。「Error: Reference to undeclared input variable」が出る
変数にデフォルト値がなく、.tfvars や -var オプションで値が渡されていない場合に発生する。
-var-file オプションを付けて console を起動する。# 対処: var-file を指定して起動 $ terraform console -var-file=dev.tfvars
一部の関数(
file() 等)はファイルシステムアクセスが必要なため、実行ディレクトリが正しいか確認する。terraform console は .tf ファイルがあるディレクトリで実行しなければならない。data source の値が空になる
state に data source の情報がない状態で参照すると空が返ることがある。先に
terraform apply か terraform plan -refresh-only を実行して state を最新にしてから console で確認する。マルチライン入力を途中でやめたい
{ や [ を入力してマルチラインモードに入った後、入力を中断したい場合は Ctrl+C を押す。そのままプロンプトに戻る。本記事のまとめ
terraform console は plan や apply を繰り返さずに HCL 式を検証できる、日常的に使えるデバッグツールだ。特に次の場面で効果が高い。| 使う場面 | 確認コマンド例 |
|---|---|
| 変数の展開確認 | var.region |
| ローカル値の評価 | local.name_prefix |
| CIDR 計算の検証 | cidrsubnet("10.0.0.0/16", 8, 1) |
| JSON エンコードの確認 | jsonencode({...}) |
| 条件式の動作確認 | var.env == "prod" ? "t3.large" : "t3.micro" |
| for 式・リスト操作の検証 | [for s in [...] : upper(s)] |
| テンプレート展開確認 | templatefile("file.tpl", {...}) |
>> Terraform実践セミナーの詳細はこちら
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:Terraformのdata sourceで既存AWSリソースを参照する方法|aws_ami・aws_vpc・aws_subnetsのfilter設計
- この記事の属するカテゴリ:Terraformへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます