2025/11/05
ルール Do not define provider blocks within shared modules (provider configuration should be done only once in root module)
（サブモジュール内で provider ブロックを定義しない。provider の設定はルートモジュールで一度だけ行う）
解説 プロバイダの設定はルートモジュールで一元管理します。サブモジュール内に provider ブロックを含めると混乱のもととなるため禁止します。
サンプルコード # ルートモジュール: ./production/providers.tf
provider "aws" {
region = "ap-northeast-1"
default_tags {
tags = {
Environment = "production"
Service = "my-service"
}
}
}
# 共有モジュール: ./modules/networking/main.tf
# providerブロックは定義しない
resource "aws_vpc" "main" {
cidr_block = var .vpc_cidr
}
参考リンク Infrastructure
開発ガイドライン
Provider Configuration
2025/11/05
ルール Environment names are production, staging, development, and experimental
（環境名はproduction、staging、development、experimentalとする）
解説 productionは本番環境、stagingは本番環境と同等の構成で最終検証を行う環境、developmentは開発者が日常的に使用する開発環境、experimentalは新技術の検証や実験的な機能を試すための環境です。
表記ゆれがないよう明確に指定します。prd, prod, product, productionと同じ用途で微妙に異なる文字列が使われることは、美観を損なうだけでなく、リソースをまとめて管理したい際の妨げとなります。
サンプルコード # ディレクトリ構造での使用例
# terraform/
# production/
# staging/
# development/
# experimental/
# リソース命名での使用例
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
tags = {
Name = "${var.environment}-${var.project}-vpc"
Environment = var .environment # production, staging, development, experimental のいずれか
}
}
Infrastructure
開発ガイドライン
Project Information
2025/11/05
ルール Keep module hierarchy to 1-2 levels and maintain flat inheritance
（モジュール階層を1〜2段階に保ち、フラットな継承を維持する）
解説 サブモジュールから別のサブモジュールを呼び出す構造は極力避けます。避けられない場合でも１度までとします。
コピペしたDRYではないベタ書きが増えるわけですが、Terraform用コードは結局それがバランスがいいようです。
サンプルコード # フラットなモジュール階層
# main.tf（ルートモジュール）
module "networking" {
source = "./modules/networking"
vpc_cidr = var .vpc_cidr
availability_zones = var .availability_zones
public_subnet_cidrs = var .public_subnet_cidrs
private_subnet_cidrs = var .private_subnet_cidrs
}
module "application" {
source = "./modules/application"
vpc_id = module .networking .vpc_id
private_subnet_ids = module .networking .private_subnet_ids
app_port = var .app_port
}
# modules/networking/ と modules/application/ は
# さらに他のモジュールを呼ばず、直接リソースを定義
参考リンク Infrastructure
開発ガイドライン
Module Design
2025/11/05
ルール Always expose reference values for resources within modules through outputs to make dependencies explicit
（モジュール内リソースの参照値は必ずoutputで公開し、依存関係を明示する）
解説 あるモジュール内で作成されたリソースの値を他のモジュールやリソースで使用する際は、outputブロックを通じて利用させます。
言い方を変えると、dataブロックやARNのハードコーディングを用いるコーディングは、保守性を落とすため避けるべきです。
サンプルコード # outputで参照値を明示的に公開
# modules/networking/outputs.tf
output "vpc_id" {
description = "The ID of the VPC"
value = aws_vpc .main .id
}
参考リンク Infrastructure
開発ガイドライン
Module Design
2025/11/05
ルール Do not create modules that only wrap a single resource; define resources directly in the caller when needed
（単一リソースを包むだけのモジュールは作らない。必要な場合は呼び出し元で直接リソースを定義する）
解説 特定の設定をまとめただけのリソースブロックをモジュールにしないようにします。
粒度が小さすぎるモジュールは保守性をかえって悪化させます。
サンプルコード 参考リンク Infrastructure
開発ガイドライン
Module Design
2025/11/05
ルール Group related resources logically and encapsulate by functional units like network foundation and data layer
（関連リソースを論理的にまとめ、ネットワーク基盤やデータ層のような機能単位でカプセル化する）
解説 モジュールは用途に沿ったリソースをまとめられるように勤めます。variableブロックを用いた外部への依存およびoutputブロックを用いた外部への情報提供は少ないに越したことはありません。
サンプルコード # ネットワーク基盤を機能単位でまとめたモジュール
# modules/networking/main.tf
resource "aws_vpc" "main" {
}
resource "aws_subnet" "public" {
}
resource "aws_internet_gateway" "main" {
}
resource "aws_route_table" "public" {
}
参考リンク Infrastructure
開発ガイドライン
Module Design
2025/11/05
ルール Infrastructure directory structure: infrastructure/
scripts/
terraform/
development/
production/
modules/
<module_name>/
（インフラストラクチャのディレクトリ構造を定めておく）
解説 ディレクトリ構造はあらかじめ定めておきます。露骨な言い方をすると、生成AIにディレクトリ構造を決めさせてはいけません。
生成AIはランダムな結果を返すものですから、なんのルールもないと、法則も設計もないディレクトリ構造を作成します。ランダムなので法則がなく、したがって理解しようもないディレクトリ構造は、運用を困難にします。
サンプルコード infrastructure/
scripts/
deploy.sh
terraform/
development/
main.tf
variables.tf
outputs.tf
terraform.tfvars.json
production/
main.tf
variables.tf
outputs.tf
terraform.tfvars.json
modules/
networking/
main.tf
variables.tf
outputs.tf
database/
main.tf
variables.tf
outputs.tf
compute/
main.tf
variables.tf
outputs.tf
参考リンク 備考 infrastructure/
scripts/
terraform/
development/
production/
modules/
<module_name>/
Infrastructure
開発ガイドライン
Directory Structure
2025/11/05
ルール Never open repositories containing sensitive information in LLM-integrated editors
（機密情報を含むリポジトリをLLM統合エディタで開かない）
解説 LLMを統合したエディタは、開いたファイル内容がクラウドサービスへ送信される可能性があります。うっかり機密情報を外部に流してしまわないよう、機密情報を含むリポジトリはLLM統合エディタでは開かないようにします。
暗号化していれば別ですが、その場合は復号するための鍵がLLM統合エディタの手の届かないようにします。もちろん復号した後の平文のテキストがLLM統合エディタから開ける状態もNGです。
サンプルコード Infrastructure
開発ガイドライン
Development Environment
2025/11/05
ルール Always log important resources and operations
(重要なリソースと操作は常にログを取る)
解説 トレーサビリティの確保にも、トラブルシューティングにも、ログは必要不可欠です。
なくても動くからとおろそかにせず、重要なリソースのログは必ず残します。代表例はCloudTrailです。
ただしプロジェクトの性格上重要ではないものはオミットして差し支えありません。
サンプルコード Infrastructure
開発ガイドライン
Design
2025/11/05
ルール Priorities are: 1) Security and Reliability, 2) Operational Excellence and Performance Efficiency, 3) Cost Optimization, considering balance among the three
(優先順位は 1) セキュリティと信頼性、2) 運用上の優秀性とパフォーマンス効率、3) コスト最適化とし、3つのバランスを考慮する)
解説 システムは何をおいても動き続けなければなりません。そのためセキュリティと信頼性を最重視しています。
次に、システムは運営費が続かなくなって止まることも防がねばなりません。運用上の優秀性とパフォーマンス効率も無視するわけにいきません。
最後にコスト最適化ですが、これはセキュリティや信頼性と比較すれば優先順位は下がります。
ただしこれらはバランスを考慮しなければなりません。いくらセキュリティが大事だからと言っても、金額換算すれば10ドル程度のメリットのために、1000ドルもかかるような対策を打つべきではありません。
サンプルコード Infrastructure
開発ガイドライン
Design
