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"
}
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"
}
Use snake_case for resource names in terraform code (e.g., web_server).
（Terraformコードのリソース名はスネークケースを使用する）
Terraformのリソース名には通常スネークケースが用いられます。
AWS公式のベストプラクティスでもスネークケースの使用が推奨されています。
# リソース名にスネークケースを使用
resource "aws_instance" "web_server" {
instance_type = "t3.micro"
ami = var.ami_id
}
Do not use plural forms in resource names.
（リソース名に複数形を使用しない）
特にこだわる所ではないため、素直にAWSの推奨に従っています。
なぜこのようになっているかは存じませんが、リソースによって複数形だったり単数形だったりするよりは、片方だけに統一されているほうが好ましいと考えます。
# 良い例: 単数形を使用
resource "aws_instance" "web_server" {
count = 3
instance_type = "t3.micro"
ami = var.ami_id
}
Do not include the resource type name in the resource name (e.g., avoid aws_instance.ec2_instance).
（リソース名にリソースタイプ名を含めない）
二つの理由により、リソース名にリソースタイプ名を含めるべきではありません。
悪い例としてはaws_instance.ec2_instance のような命名が該当します。
AWS公式のベストプラクティスでもこの命名規則が推奨されています。
# 良い例: リソースタイプを重複させない
resource "aws_instance" "web_server" {
instance_type = "t3.micro"
ami = var.ami_id
}
resource "aws_security_group" "api" {
name = "${var.environment}-${var.project}-api"
vpc_id = aws_vpc.main.id
}
A single resource within a module should be named main (e.g., resource "aws_vpc" "main").
（モジュール内の単一リソースは main と命名する）
モジュール内に特定のリソースタイプが一つしかない場合はリソース名を main とします。
採用の理由は「それがAWS推奨の手法だから」ですが、モジュール内の主要なリソース、またはそのリソースのための補助的な宣言であることが理解しやすいため従っておけばよいと考えます。
# modules/vpc/main.tf
# VPCリソースが一つだけの場合は main と命名
resource "aws_vpc" "main" {
cidr_block = var.cidr_block
enable_dns_hostnames = true
enable_dns_support = true
}
Name boolean variables affirmatively (e.g., enable_external_access).
（真偽値変数は肯定形で命名する）
コードの可読性を向上させるため、変数は肯定形で記載します。
否定形を使用した二重否定（e.g., disable_logging = false) は読みづらいため避けます。
variable "enable_external_access" {
type = bool
description = "Enable external access to the resource"
}
Name AWS resource names (Name tags) in the format [environment]-[project]([-additional_info_if_any]) (e.g., production-practitioner-api). In HCL, use variables like ${var.environment}-${var.project}-api. ‘api’ is just an example, so be sure to replace it appropriately.
（AWSリソース名（Nameタグ）は[環境名]-[プロジェクト名][-追加情報]の形式で命名する）
これはプロジェクト独自の命名規則です。
環境名を先頭に配置することですぐにどの環境のリソースかわかるようにし、環境の取り違えを防止します。
またどのリソース名でも同一の命名規則を徹底することで、スクリプトなどを使った一括処理を行いやすくします。
resource "aws_instance" "api" {
ami = "ami-12345678"
instance_type = "t3.micro"
tags = {
Name = "${var.environment}-${var.project}-api"
}
}
Do not include provider or terraform in submodules.
（サブモジュールにproviderやterraformブロックを含めない）
プロバイダー設定はルートモジュールで一括管理します。そのためサブモジュールでproviderやterraformブロックを利用してはいけません。
Terraformの公式ベストプラクティスでも推奨されている設計原則です。
# production/providers.tf（ルートモジュールで定義）
terraform {
required_version = ">= 1.5.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "ap-northeast-1"
}
github/spec-kitが公開されました。AI駆動開発の本命であろう仕様駆動開発の標準化に貢献するであろうこのプロジェクトにはとても注目しています。
かつて私も仕様書を元にAIに作成させる方法を自著の同人誌で提案したことがあります。やはり有利なのです。
まず大前提として、生成AIに作業をさせるためにはプロンプトが必要です。そのプロンプトは明確かつ必要十分の情報を保有していることが望ましいです。
そして開発プロジェクトにおいて「明確かつ必要十分の情報を保有している」プロンプトすなわちテキストとは、つまるところ仕様書です。仕様書とは設計やコーディングに必要な情報を明確かつ必要十分に記載したテキストなのですから。――常に実現できているとは限りませんが、目指してはいます。
である以上、
「いっそプロンプトとして仕様書を渡してしまえばいい」
という発想に至るのは自然な帰結でしょう。
AIに渡すプロンプトを毎回作るのは大変ですし、再現性も低いという問題があります。これはバイブコーディングの泣き所でもあります。ですが仕様書を渡すスタイルなら何度でも書き終えた仕様書を渡せば済むわけです。再利用も簡単、追跡性もばっちりです。
さて、前述の技術同人ではIaCを仕様駆動開発（と言う名前ではありませんでしたが）で実用にたるレベルで実行することができていました。これには下記の要因があります。
ところがこの成功体験をもとにGoプロジェクトで仕様駆動開発を実践しようとすると問題が生じました。上の条件の逆で、コードの規模が大きく複雑、取りうるアーキテクチャ・ライブラリ・ツールの数も多く、またチーム開発を想定する必要があったのです。これは必要なプロンプト（＝ドキュメント）の量を増やし、開発体制の整備にかかる時間をIaCだけのケースよりはるかに大きなものとし、しかもチーム内教育への考慮まで要求されることとなりました。
これらの課題を地力で頑張って乗り切ることは、不可能ではないまでも多大な時間を要し、かつそこまでしても普及させられると思えず、ありていに言ってあまり割に合わない作業になりそうに思えました。
そのような状況で登場したのがKiroや今回のSpec Kit等、大手が提示するツールやプロジェクトです。まだ実験的な性格も強いようですが、おそらく開発体制の充実度合いや運用保守の強固さなどから、このタイプの提示する仕様駆動開発の採用が堅い選択になるのではないかと考えられます。
個別に最適化したほうがプロジェクトにフィットさせられるのでしょうが、現実的には、多くのプロジェクトでは人の入れ替わりや開発リソースの限界などの要因によってそう簡単ではありません。技術的な理想ではなくとも、運用や教育などの面まで含めた総合的判断においては、既存のソリューションを利用するほうがベストとなるケースが多いことでしょう。
かなり前置きが長くなりましたが、このようなわけで、独自開発ではなく既存プロジェクトに乗る方向で仕様駆動開発を試していきます。spec-kitです。