★★ 中級

08. PR レビューの進め方（IaC 観点）

IaC の PR レビューは 本番に触る最後の人間ゲート。「ロジックが正しいか」だけでなく 「これを apply したら何が消えるか」 までを見ます。レビュー観点とチェックリストを整理。

この章の目次

IaC レビューのマインドセット
Plan を最初に読む
レッドフラッグ集
レビューチェックリスト
作る側のチェック
議論の進め方

IaC レビューのマインドセット

アプリコードのレビューは「動くか」「読めるか」が中心。IaC は 「動く」よりも「壊さない」 を優先します。理由:

本番 RDS を再作成 = 数時間のダウンタイム + データ損失
SG を間違えて 0.0.0.0/0 開放 = 直ちに脆弱性
IAM ポリシーの権限拡大 = 攻撃面の拡大
state を直接編集 = 後続の plan が壊れる

Plan を最初に読む

CI が PR コメントに terraform plan 結果を貼っているはず（05 章）。コードよりも先に plan を読む。

Plan: 3 to add, 2 to change, 1 to destroy.

注目するキーワード:

キーワード	意味	レビュー時の判断
`+ create`	新規作成	意図したリソースか
`~ update in-place`	属性変更（無停止）	たいてい OK。属性確認
`-/+ destroy and then create`	強制再作成	要警戒。停止と引き換えに何を変えているか
`- destroy`	削除	最警戒。データ消失の可能性
`(forces replacement)`	再作成の理由	その属性の意味を知っているか確認

レッドフラッグ集

これらが PR に含まれていたら必ず議論:

セキュリティ

0.0.0.0/0 の SG ingress（22 や 3306 などの管理ポートで特に）
"Action": "*" や "Resource": "*" の IAM ポリシー
S3 の block_public_acls = false や restrict_public_buckets = false
publicly_accessible = true（RDS）
encrypted = false または KMS なし
パスワードや API キーがハードコード（"AKIA..."、password = "..."）

コスト

NAT Gateway 追加（月 $35+）
RDS Multi-AZ ON（料金 2 倍）
大型インスタンス（r5.4xlarge 等）
EBS gp2 → gp3 への変換漏れ
ログの retention_in_days なし（無期限保持で課金が膨らむ）
用途不明な Provisioned 容量（DynamoDB / RDS IOPS など）

破壊的変更

resource の name 変更（state 上は別物扱い → destroy + create になる）
count から for_each への移行（moved ブロック必須）
state にあるリソースから resource ブロックを削除（destroy される）
prevent_destroy の解除
module の source 変更（バージョン上げで内部リソースが再作成）

運用

lifecycle.ignore_changes の追加（手動変更との分離が増えるたびに技術的負債）
depends_on の追加（暗黙の依存で済まないか）
terraform_data や provisioner の利用
再デプロイで再現できない手順がコメントに書いてある

レビューチェックリスト

コピペ用 PR コメント:

## レビュー結果

- [ ] CI の plan を確認した
- [ ] destroy / forces replacement が無い、または許容範囲
- [ ] セキュリティ: SG / IAM / 暗号化に懸念なし
- [ ] コスト: 想定外の課金リソースなし
- [ ] 命名規約・タグ規約に従っている
- [ ] terraform fmt / validate / tflint パス
- [ ] ドキュメント (README) 更新（必要なら）
- [ ] 変更を applied する apply 順序を確認した（envs/dev → stg → prd）

作る側のチェック

レビュアーの負担を減らすため、PR を出す前に作者がやること:

terraform fmt -recursive
terraform validate
terraform plan をローカルで確認、特に destroy の有無
tflint / trivy をローカルで通す（pre-commit）
PR 説明に 「なぜ必要か」「どう影響するか」 を書く（コードに書けない情報）
大きな変更は分割してまとめずに小さく出す

PR テンプレート例

# .github/pull_request_template.md

## 概要
<!-- このPRで何を変えるか -->

## 動機 / 背景
<!-- なぜ必要か -->

## 変更内容
- [ ] リソースの追加: ...
- [ ] リソースの変更: ...
- [ ] リソースの削除: ...

## terraform plan サマリ
<!-- Plan: X to add, Y to change, Z to destroy. -->

## 影響範囲
- 環境: dev / stg / prd
- 想定ダウンタイム: なし / 数分
- ロールバック手順: ...

## レビュー時に見てほしいポイント
<!-- 自信がない箇所、議論したい箇所 -->

議論の進め方

「ブロッカー」「サジェスト」「質問」を分ける — レビュアーは "blocking:" "nit:" "q:" 等のプレフィックスを付ける
議論が長くなったら同期コミュニケーション（Slack ハドル等）に切り替える
巨大 PR は 「分割を提案」 も立派なフィードバック
本番に触る PR は 2 名以上のレビュー を Branch ruleset で必須化（07 章）