terraform consoleコマンドでHCL式を対話検証する方法|変数・関数・条件式のデバッグ実践手順

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Terraform > terraform consoleコマンドでHCL式を対話検証する方法|変数・関数・条件式のデバッグ実践手順
「terraform plan を実行するたびに時間がかかる。変数の展開結果をすぐに確認したい。」
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 は特に効果的


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

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" }

console では 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 計算を手作業でミスするエンジニアは多い。cidrsubnetcidrhost は 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 initterraform 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"

data source は console 起動時に AWS API を呼ばない。state に保存済みの値を参照するため、state が古い場合は 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

「Error: Function call not allowed in this context」が出る

一部の関数(file() 等)はファイルシステムアクセスが必要なため、実行ディレクトリが正しいか確認する。terraform console は .tf ファイルがあるディレクトリで実行しなければならない。

data source の値が空になる

state に data source の情報がない状態で参照すると空が返ることがある。先に terraform applyterraform 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", {...})
コードを書いて → console で式を確認 → .tf ファイルに反映 → plan という流れを習慣にすることで、plan のエラー件数と apply のやり直しを大幅に減らせる。ぜひ日常的なデバッグツールとして活用してほしい。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、terraform console を使ったデバッグ技法や HCL 設計パターンを含む実践的な Terraform 活用スキルを体系的に学べるセミナーを開催しています。
>> Terraform実践セミナーの詳細はこちら

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。