2025/11/03
ルール Minimize the use of locals blocks. If used, define them in locals.tf.
(localsブロックの使用を最小限にする。使用する場合はlocals.tfに定義する)
解説 AWSの推奨に従っています。
使用する際はlocals.tfに集約することで、ローカル変数の定義場所を一元化し可読性を維持します。
サンプルコード # locals.tf
locals {
# 複数の変数を組み合わせた共通タグ
common_tags = {
Environment = var .environment
Project = var .project
}
# 計算が必要な値
common_prefix = "${var.environment}-${var.project}-"
}
参考リンク Infrastructure
開発ガイドライン
Coding Standards
2025/11/03
ルール Fixed values may be coded directly in resource definitions. (e.g., t4g.micro)
(固定値はリソース定義に直接記述してよい(例:t4g.micro))
解説 生成AIはむやみやたらとvariablesを使いたがる傾向があります。そこで明示的にそれを抑制しています。
サンプルコード resource "aws_instance" "web" {
ami = data .aws_ami .ubuntu .id
instance_type = "t4g.micro" # 固定値を直接記述
tags = {
Name = "web-server"
}
}
Infrastructure
開発ガイドライン
Coding Standards
2025/11/03
ルール Minimize the use of data blocks. If used, place them immediately above the resource block that references them.
(dataブロックの使用を最小限にする。使用する場合は、参照するリソースブロックの直前に配置する)
解説 dataブロックは便利なのですが、AWS APIへの問い合わせが行われるため、多用するとTerraformの実行が遅くなります。
そのため使わなくてもよい場面ではDataブロックではなくvariablesを利用します。
ただし禁止ではないため、使用することもあります。その場合はなるべく読みやすいよう参照するリソースの直前に配置します。
サンプルコード # 使用するリソースの直前にdataブロックを配置
data "aws_ami" "ubuntu" {
most_recent = true
owners = ["099720109477" ] # Canonical
filter {
name = "name"
values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*" ]
}
}
resource "aws_instance" "web" {
ami = data .aws_ami .ubuntu .id
instance_type = "t3.micro"
}
参考リンク Infrastructure
開発ガイドライン
Coding Standards
2025/11/03
ルール Do not add comments describing what is already clear from the code.
(コードから明らかな内容を説明するコメントを追加しない)
解説 コードを見れば分かる内容を繰り返すコメントは害のほうが大きいため禁止しています。
サンプルコード # 良い例
resource "aws_s3_bucket_lifecycle_configuration" "logs" {
bucket = aws_s3_bucket .logs .id
rule {
id = "delete_old_logs"
status = "Enabled"
# 監査要件により90日間保持
expiration {
days = 90
}
}
}
# 悪い例(参考)
# resource "aws_s3_bucket" "logs" { # <- S3バケットを作成
# bucket = "${var.environment}-${var.project}-logs" # <- バケット名を設定
# }
Infrastructure
開発ガイドライン
Coding Standards
2025/11/03
ルール *Keep comments in .tf files to a minimum. Avoid adding header blocks or documentation-level specifications in comments.
(*.tfファイルのコメントを最小限に保つ。ヘッダーブロックの追加禁止。またドキュメントに記載すべき仕様も書いてはならない)
解説 生成AIはしばしば大量のコメントやヘッダーブロックをコード内に埋め込もうとします。しかし過剰なコメントは可読性を落とし、コメントの保守の手間を増やし、トークン効率を悪化させます。そのため禁止しています。
サンプルコード # 良い例: 最小限のコメント、自己文書化されたコード
variable "instance_type" {
type = string
description = "EC2インスタンスタイプ。本番環境ではt3.mediumを推奨"
}
resource "aws_instance" "web" {
ami = data .aws_ami .ubuntu .id
instance_type = var .instance_type
# セキュリティ要件により、IMDSv2を強制
metadata_options {
http_endpoint = "enabled"
http_tokens = "required"
}
}
Infrastructure
開発ガイドライン
Coding Standards
2025/11/03
ルール Avoid abbreviations, use full names (e.g., cg → coding_guidelines). However, abbreviations used as proper nouns (e.g., RDS, id) may be used.
(略語を避け、完全な名前を使用する(例: cg → coding_guidelines)。ただし、固有名詞として使用される略語(例: RDS, id)は使用可能)
解説 独自の略語は外部の人員や将来の担当者が意図を理解しにくくなるため極力利用を控えます。
ただし、RDSやidのような固有名詞に近いものは利用してかまいません。
サンプルコード # 完全な名前を使用。ただしidのように半ば固有名詞として使われているものは可
variable "security_group_id" {
type = string
description = "Security Group ID"
}
# このような略し方はNG
variable "sg_id" {
type = string
description = "Security Group ID"
}
Infrastructure
開発ガイドライン
Coding Standards
2025/11/03
ルール Implementation should consider the AWS Well-Architected Framework, though strict compliance is not required.
(実装はAWS Well-Architected Frameworkを考慮する。ただし厳格な準拠は要求しない)
解説 AWS Well-Architected Frameworkは大変優れた設計原則であり、何をおいてもこの考え方が設計の基本となります。
ただしその方針を具体化したルールの中には準拠が難しいものも含まれるため、参考に止めればよいとしています。
Infrastructure
開発ガイドライン
Coding Standards
2025/11/03
ルール Use MiB/GiB for storage units, and MB/GB (decimal units) for others.
(ストレージ単位にはMiB/GiBを使用し、その他にはMB/GBを使用する)
解説 ストレージ容量(ディスク/ボリューム/スナップショット等)はバイナリ単位を使用します。それ以外のメトリクス(ネットワーク転送量、帯域など)は10進数の単位を使用します。単位の微妙な違いによる勘違いを防止します。
サンプルコード # ストレージには2進数(GiB/MiB)を使用
variable "ebs_volume_size_gib" {
type = number
description = "EBS volume size in GiB"
}
# それ以外は10進単位を使用
variable "cw_alarm_network_out_threshold_mb" {
type = number
description = "CloudWatch Alarm threshold for NetworkOut in MB"
}
参考リンク Infrastructure
開発ガイドライン
Coding Standards
2025/11/03
ルール Include units in numerical variable names (e.g., size_gb, ram_size_gb).
(数値変数名には単位を含める)
解説 単位を変数名に含めることで、単位の取り違えによるバグを防止します。
AWS推奨の設定方法です。
サンプルコード variable "bandwidth_limit_mb" {
type = number
description = "Bandwidth limit in MB per second"
}
参考リンク Infrastructure
開発ガイドライン
Coding Standards
2025/11/03
ルール Multiple resources within a module should be named according to their role (e.g., primary, read_replica).
(モジュール内の複数リソースは役割に応じて命名する)
解説 モジュール内に同じタイプのリソースが複数存在する場合は、primary や read_replica のようにそのリソースの役割を示す名称をつけます。
なお単一リソースの場合は mainとします。
サンプルコード # modules/database/main.tf
# データベースの役割に応じて命名
resource "aws_db_instance" "primary" {
identifier = "${var.environment}-${var.project}-primary"
engine = "postgres"
instance_class = "db.t3.medium"
}
resource "aws_db_instance" "read_replica" {
identifier = "${var.environment}-${var.project}-replica"
replicate_source_db = aws_db_instance .primary .id
instance_class = "db.t3.small"
}
参考リンク Infrastructure
開発ガイドライン
Coding Standards