Terraform Console徹底活用: 式の評価とデバッグ

terraform consoleは、その場でHCL式を評価できる対話的REPLです。plan/applyの前に式の正当性や型変換、ループ処理の結果を確認でき、検証の反復速度を大きく上げます。

本稿ではAssociate/Pro試験で狙われやすい式評価の基礎から、locals/variables/状態参照のデバッグ、エラーの読み解き方まで、実務でそのまま使える手順をまとめます。

terraform consoleの基礎と立ち上げ

terraform consoleは現在の作業ディレクトリの設定と状態を読み込み、HCL式を逐次評価します。状態が存在すればリソース属性やモジュール出力も参照できます。

利用前にterraform initを実行し、バックエンドやプロバイダを解決しておくのが安全です。リモートバックエンドが構成されていれば、認証情報が有効な前提でその状態に対しても評価できます。終了はexitまたはCtrl-Dです。

• 主な用途: 型変換の確認、for式の動作検証、正規表現や条件式のテスト、状態にあるIDの収集/整形
• 状態参照: 直近の状態からresourceやmoduleの属性/出力を参照（未適用の属性は未確定で評価できない場合あり）
• 変数: var.<name>、localsはlocal.<name>、ワークスペースはterraform.workspaceで参照
• 安全策: try()やcan()で未定義・型不一致に備える

式評価の流れ（概念）

入力式  -->  パーサ(HCL)  -->  評価器
                              |  \-- 関数呼び出し
                              |  \-- 変数/locals参照
                              |  \-- 状態参照(resource/module)
                              V
                           結果/エラー

起動と基本評価例

# 変数はTF_VAR_*やtfvarsから解決される。状態は作業ディレクトリに紐づく
$ TF_VAR_env=dev terraform console
> terraform.workspace
"default"
> var.env
"dev"
> tostring(1 + 2)
"3"
> can(regex("^app-", "app-web"))
true
> coalesce(null, "fallback")
"fallback"
> exit

式と型の評価パターン

Terraformの基本型はstring、number、bool、コレクション（list/tuple、map/object）、nullです。consoleでは関数で明示的に型を整えるとエラーが減ります。

未知値（未適用で確定していない属性）やnullを含む式は、そのままでは評価エラーになることがあります。can()で評価可否を先に確認し、try()やcoalesce*でフォールバックを用意するとデバッグが進みます。

• 明示変換: tostring/tonumber/tobool/tolist/toset/tomap
• 安全評価: can(expr)で安全性チェック、try(a, b, c)で代替値を順に評価
• null扱い: coalesce(x, y)、coalescelist(xs, ys)で非null/非空を選択
• コレクション: keys(map)、values(map)、length(col)、merge(map...)

型と安全評価の実例

terraform console
> toset(["a", "b", "a"])  # 重複排除
set([
  "a",
  "b",
])
> tomap({ a = 1, b = 2 })
{
  "a" = 1
  "b" = 2
}
> can(var.unknown)
false
> try(var.missing, "ok")
"ok"
> coalescelist([], [1,2])
[
  1,
  2,
]
> tonumber("08")
8

変数・locals・状態のデバッグ

consoleは現在の設定ファイルのlocalsやvariablesを解決します。locals参照はlocal.<name>です。tfvarsや環境変数（TF_VAR_*）を用意すると、本番に近い入力で式を試せます。

状態が存在する場合、resourceアドレス（例: aws_instance.web.id）やmodule出力（module.app.url）も評価できます。未適用で状態にない属性は評価できないため、try()で防御しつつ代替ロジックを検証します。

• locals参照: local.tags、local.common
• 変数確認: var.region、lookup(var.tags, "env", "dev")
• 状態参照: aws_instance.web.private_ip、module.db.endpoint
• ワークスペース: terraform.workspaceで環境切替ロジックの分岐確認

設定とconsoleの往復で検証する

# locals.tf（一例）
locals {
  tags = merge({ app = "sample" }, { env = var.env })
}

# variables.tf
variable "env" { type = string, default = "dev" }

# consoleで評価
$ terraform console
> local.tags
{
  "app" = "sample"
  "env" = "dev"
}
# 状態にある場合のみ参照可能（無いとエラー）
> try(aws_instance.web.private_ip, "no-ip")
"no-ip"
> can(module.app.url)
false

コレクション操作とfor式の検証

for式や条件付き内包表記は、リソース引数に入れる前にconsoleで完成形を作って確認するのが近道です。map/objectのキー・値の変換、flattenやdistinctの活用で実務の整形要件にも対応できます。

正規表現、分岐、ソートなども組み合わせ、目的のスキーマに落ちるまで反復します。

• 内包表記: [for x in xs : ... if cond]、{ for k, v in m : ... }
• 整形: flatten、compact、distinct、sort、reverse
• 文字列処理: regex/regexall/replace/format
• JSON/YAML: jsonencode/jsondecode、yamldecode（必要に応じて）

for式と整形の例

terraform console
> xs = [{name="a", port=80}, {name="b", port=443}]
> [for x in xs : format("%s:%d", x.name, x.port)]
[
  "a:80",
  "b:443",
]
> m = { web = {subnets=["s-1","s-2"]}, api = {subnets=["s-3"]} }
> flatten([for k, v in m : v.subnets])
[
  "s-1",
  "s-2",
  "s-3",
]
> addrs = ["10.0.0.1", "10.0.0.1", "10.0.0.5"]
> sort(distinct(addrs))
[
  "10.0.0.1",
  "10.0.0.5",
]

典型エラーとトラブルシュート

consoleでのエラーは本番の計画/適用でも発生しうるため、原因を正確に分類します。未定義（unknown/未適用）、型不一致、キー欠落、ファイル/パス不備が主要因です。

can()/try()で隔離し、個々のサブ式を小さく分割して評価すると根本原因に早くたどり着けます。

• Unknown/未適用: 状態にない属性は参照不可。try(aws_x.y, null)で保護
• 型不一致: tolist/tomapで揃える。特にnull混在に注意
• キー欠落: lookup(map, key, default)で既定値を用意
• パス/ファイル: abspath/pathexpand/fileexistsで事前確認

エラーの切り分け例

terraform console
# 未定義参照
> aws_instance.web.id
╷
│ Error: Invalid reference
│   on <console-input> line 1:
│ (resource not found in state)
╵
# can/tryで防御
> can(aws_instance.web.id)
false
> try(aws_instance.web.id, "no-id")
"no-id"
# 型不一致の修正
> merge({a=1}, {b=null})
{
  "a" = 1
  "b" = null
}
> tomap(merge({a=1}, {b=null}))  # map型を明示
{
  "a" = 1
  "b" = null
}
# ファイル存在確認
> fileexists("./vars/dev.tfvars")
true

試験対策と実務Tips

Associate/Proでは、consoleでの式検証、型の暗黙/明示変換、for式と条件、unknown値の扱い、workspace分岐などが頻出です。設問は挙動の正確さ（どこまで参照できるか）と、安全なガード（try/can/coalesce）の適用を問う傾向があります。

実務では、plan前にconsoleで式を固める、状態起点のデータ整形を一度consoleで原型を作る、tfvarsとTF_VAR_*で本番相当の入力を用意して動作確認するのが有効です。

• locals参照はlocal.<name>で、localsではない点を確認
• workspace分岐: terraform.workspace == "prod" ? ... : ...
• mapの安全参照: lookup(m, "key", default) と try(m.key, default) の使い分け
• 正規表現の罠: regexは単一マッチ、regexallはリストで返る

小ワザ集（抜粋）

# 別状態ファイルを評価（ローカルにダウンロード済みの例）
$ terraform console -state=./terraform.tfstate
> module.app.endpoint
"https://app.example.com"

# workspace分岐の動作確認
$ TF_VAR_env=prod terraform console
> terraform.workspace
"default"
> var.env
"prod"
> var.env == "prod" ? "hoge" : "fuga"
"hoge"

# ファイル入力の検証
> jsondecode(file("./overrides.json"))
{
  "image" = "1.2.3"
}

問題で確認

よくある質問