【実務・中級編】TerraformにおけるJSON/YAMLファイルからのデータ駆動型インフラ構築：templatefileとyamldecodeの極意 – インフラ構成管理（IaC）活用バイブル

Terraformで「枯れたコード」を書くな。データ駆動型インフラ構築の極意

多くのエンジニアがTerraformで犯す最大の罪、それは「リソース定義の中に環境固有の値を直書きすること」だ。

「`prod`と`staging`で似たようなリソースを作るから」とコピペを繰り返し、`count`や`for_each`の条件分岐でコードがスパゲッティ化しているのを見て、私はいつも思う。「それ、データとロジックを分離すれば一瞬で解決するぞ」と。

今日は、Terraformにおける「データ駆動型設計」の深淵に触れ、あなたのチームのデプロイ速度を次の次元へ引き上げるための「武器」を授ける。

—

IaCの目的は「宣言」することだ。しかし、環境が増えるたびにコード自体を書き換えていては、それは「宣言」ではなく「手動の流し込み」に過ぎない。

データ駆動型設計（Data-Driven Design）を採用すると、以下のメリットが得られる。

ロジックの不変性: Terraformコード（ロジック）は一度書けば変更不要。環境追加はYAMLを足すだけ。
認知負荷の低減: リソースの増減はYAMLのリストを操作するだけで済み、HCLの複雑な構文に頭を悩ませる必要がない。
バリデーションの集中化: `yamldecode`で読み込んだ直後に`precondition`等でバリデーションをかければ、デプロイ前の事故を確実に防げる。

—

複雑な階層構造はJSONよりYAMLの方が圧倒的に可読性が高い。

vars/production.yaml
vpc_config:
cidr: “10.0.0.0/16”
subnets:

cidr: “10.0.1.0/24”

cidr: “10.0.2.0/24”

locals {
# ファイルを読み込み、構造化データとして展開
config = yamldecode(file(“${path.module}/vars/${terraform.workspace}.yaml”))
}

resource “aws_subnet” “main” {
for_each = { for s in local.config.vpc_config.subnets : s.name => s }

vpc_id = aws_vpc.main.id
cidr_block = each.value.cidr
availability_zone = “${var.region}a”
tags = { Name = each.value.name }
}

極意: `templatefile`は「動的な設定ファイル（例：UserdataやNginx設定）」を生成する際に使い、`yamldecode`は「リソースの構成管理」のために使う。この境界を曖昧にしてはいけない。

—

`tflint`: 絶対必須。静的解析なしでデプロイするのは目隠しで高速道路を走るようなものだ。
`tfsec` / `trivy`: セキュリティの「門番」。CIパイプラインの初期段階で必ず通すこと。
VS Code拡張機能: 公式の `HashiCorp Terraform` 以外に、`YAML` (Red Hat製) を入れ、必ずスキーマ定義をリンクさせよ。補完精度が劇的に変わる。

`Shift + Alt + F`: Terraformの自動フォーマット。これを設定で「保存時に実行」にしていないなら、今すぐ設定ファイル（`settings.json`）を書き換えろ。

“[terraform]”: {
“editor.formatOnSave”: true
}

—

YAMLファイルをただ置くだけでは、誰かがキーを打ち間違えた瞬間にTerraformが爆発する。`json-schema`を書き、VS CodeのYAML拡張機能に読み込ませろ。エディタがリアルタイムで「そのキーは存在しません」と警告してくれるようになる。

`resource` ブロックの中に複雑な `ternary operator`（三項演算子）を書くのは素人のやることだ。

locals {
# 複雑なロジックはここで計算し、リソース定義をクリーンに保つ
is_prod = terraform.workspace == “prod”
instance_type = local.is_prod ? “m5.large” : “t3.micro”
}

`terraform.tfvars` は禁止: 環境ごとの値は必ず `vars/.yaml` に分離すること。
モジュールの標準化: チーム内では `module` を自作せず、社内標準のリポジトリをタグ指定（`ref=v1.2.0`）で呼び出すこと。バージョン管理のないモジュールは「技術的負債」の塊だ。

—

インフラコードは「一度動いて終わり」ではない。半年後の君や、明日のチームメンバーがそのコードを見たとき、「この設定値はどこから来ているのか？」と一瞬で理解できるか。それがプロの仕事だ。

YAMLに情報を逃がし、HCLを純粋なロジックとして磨き上げる。この分離こそが、大規模なクラウド環境を安定して運用し続ける唯一の道である。

さあ、今すぐ不要なコピペを削除し、データ駆動型の設計へ移行せよ。君のインフラは、もっと美しくなれるはずだ。