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
2025/11/05
ルール Implementation follows AWS Well-Architected Framework
(AWS Well-Architected Framework に従って実装する)
解説 AWS Well-Architected Framework は、ＡＷＳでインフラを構築する際の基本となる設計原則です。
考慮すべき事項の抜け漏れ防止、あるいは関心事の深堀りなどその効用は多岐にわたります。生成ＡＩに活用させるには若干漠然としすぎていますが、それでも指摘せぬわけにいかない重要事項です。
サンプルコード 参考リンク Infrastructure
開発ガイドライン
Design
2025/11/05
ルール Prepare service monitoring and alerting mechanisms
(サービスの監視とアラート機構を準備する)
解説 サービスの安定運用には、問題の早期発見と迅速な対応が不可欠です。
CloudWatchやDatadog等を使用して監視・発報の仕組みを用意しておきます。
サンプルコード 参考リンク Infrastructure
開発ガイドライン
Design
