1. 概要
- リソース名・変数名・module名の命名規則
- ファイル・ディレクトリ名の規則
- タグ命名規則
- チームで統一するためのtflint設定
Terraformコードの可読性と保守性は命名規則の一貫性に大きく依存します。公式スタイルガイドおよびコミュニティのベストプラクティスに基づいた命名規則をまとめます。
2. リソース名の命名規則
Terraformのリソース名(ローカル識別子)にはスネークケース(snake_case)を使います。
# ✅ 良い例
resource "aws_instance" "web_server" { ... }
resource "aws_s3_bucket" "app_logs" { ... }
resource "aws_security_group" "alb_ingress" { ... }
# ❌ 悪い例
resource "aws_instance" "WebServer" { ... } # PascalCase
resource "aws_s3_bucket" "app-logs" { ... } # ケバブケース
resource "aws_security_group" "albIngress" { ... } # キャメルケース
ルール:
- スネークケース(
_区切り)を使う - リソースタイプを名前に繰り返さない(
aws_instance.instance_webではなくaws_instance.web) - 単数形を使う(
aws_subnet.publicではなくaws_subnet.publics) main/thisは単一リソースの場合に許容
3. 変数・output名の命名規則
# variables.tf
variable "environment" {
description = "環境名(dev/stg/prd)"
type = string
}
variable "instance_type" {
description = "EC2インスタンスタイプ"
type = string
default = "t3.micro"
}
variable "enable_deletion_protection" {
description = "削除保護を有効にするか"
type = bool
default = false
}
# outputs.tf
output "vpc_id" {
description = "VPC ID"
value = aws_vpc.main.id
}
output "private_subnet_ids" {
description = "プライベートサブネットIDのリスト"
value = aws_subnet.private[*].id
}
ルール:
- スネークケースを使う
- bool型は
enable_/is_/create_プレフィックスを付ける - 単位は名前に含める(例:
timeout_seconds,disk_size_gb)
4. ファイル・ディレクトリ名の規則
# ✅ 推奨されるファイル名
main.tf # メインリソース定義
variables.tf # 変数定義
outputs.tf # output定義
versions.tf # terraform/required_providersブロック
locals.tf # locals定義(ファイルが大きい場合)
data.tf # dataソース(ファイルが大きい場合)
# ディレクトリ名はケバブケースも許容
modules/
web-server/
database/
network/
environments/
dev/
stg/
prd/
5. タグ命名規則
terraform {
required_version = ">= 1.9"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "ap-northeast-1"
}
variable "environment" {
description = "環境名"
type = string
default = "dev"
}
variable "service_name" {
description = "サービス名"
type = string
default = "myapp"
}
# 共通タグをlocalsで定義して全リソースに適用
locals {
common_tags = {
Environment = var.environment
ManagedBy = "terraform"
Service = var.service_name
Owner = "infra-team"
}
}
data "aws_ami" "amazon_linux_2023" {
most_recent = true
owners = ["amazon"]
filter {
name = "name"
values = ["al2023-ami-*-x86_64"]
}
}
resource "aws_instance" "web" {
ami = data.aws_ami.amazon_linux_2023.id
instance_type = "t3.micro"
root_block_device {
volume_size = 20
volume_type = "gp3"
encrypted = true
}
# merge()でリソース固有タグと共通タグを合成
tags = merge(local.common_tags, {
Name = "${var.environment}-${var.service_name}-web"
Role = "web-server"
})
}
resource "aws_s3_bucket" "app_data" {
bucket = "${var.environment}-${var.service_name}-data"
tags = merge(local.common_tags, {
Name = "${var.environment}-${var.service_name}-data"
})
}
AWSタグ命名ルール(推奨):
Name:{environment}-{service}-{role}形式Environment:dev/stg/prdManagedBy:terraform(手動管理リソースとの区別)- PascalCase(
Name,Environment)を使う(AWSの慣習)
6. module名の規則
# ✅ 機能を表す名前
module "network" { ... }
module "compute" { ... }
module "database" { ... }
module "alb" { ... }
# ❌ 避けるべき名前
module "module1" { ... } # 意味がない
module "aws_vpc" { ... } # プロバイダーリソース名と混同
module "my_new_module" { ... } # 冗長
7. tflintで命名規則を自動チェック
# .tflint.hcl
plugin "aws" {
enabled = true
version = "0.33.0"
source = "github.com/terraform-linters/tflint-ruleset-aws"
}
rule "terraform_naming_convention" {
enabled = true
variable {
format = "snake_case"
}
output {
format = "snake_case"
}
resource {
format = "snake_case"
}
}
# CI/CDで実行
$ tflint --recursive
8. 関連記事
- terraform fmt / validate — コード整形と構文チェック — 自動整形ツール
- CI/CDパイプラインとTerraform — tflintのCI組み込み
- HCLスタイルガイド — インデント・コメントの規則
- Terraformのディレクトリ構成 ベストプラクティス
- resourceブロック — 基本構文と使い方
- variable(入力変数)— 定義・型・バリデーション
9. まとめ
- リソース名・変数名・output名はスネークケース(
snake_case) - ファイル名は
main.tf/variables.tf/outputs.tf/versions.tfが基本 - タグは
localsでcommon_tagsを定義しmerge()で合成 Nameタグは{environment}-{service}-{role}形式が標準tflintでCI上から命名規則を自動チェックできる
動作確認バージョン: Terraform >= 1.9 公式ドキュメント: https://developer.hashicorp.com/terraform/language/style