Terraform 変更を安全にレビューする — plan の読み方・CI destroy 検知・承認フロー設計

Terraform のレビューはコードレビューではない Terraform の PR レビューを「コードレビュー」と同じ感覚でやると本番が壊れる。 plan 出力に埋もれた destroy 行、resource 追加に紛れた IAM 権限の昇格、セキュアな値の漏洩。これらは「コードが綺麗か」を見る目では捕まらない。 差分を読む順序、CI で機械的に弾く仕組み、誰がどこを承認するかというフロー設計。3つが揃って初めてレビューが機能する。 なぜ Terraform 変更は普通の PR レビューでは守れないのか 理由は3つある。 plan 出力が長すぎて危険な行が埋もれる: 本番環境の terraform plan は数百行を超えることがある。+ resource ... の山の中に - aws_db_instance.main の1行が紛れ込む。レビュアーは出力を見落とす可能性が高まる。 コー

[tmatsuu]

planの結果は細かくみる癖をつけるの大事。"+" "-" だけでなく "~" の部分も注視する必要がある。が、それこそAIの方が得意かなこういうの。

[hatahata_chan]

これこそ生成AIの要約が効く案件。applyする前は必ず要約かけて思わぬ変更がないか確認している

[nguyen-oi]

tf planは嘘をつかないが人間は容易に見落とす。破壊的変更がsummaryの1行に紛れ込む恐怖よ。CIでの機械的チェックと承認フローの二重化はIaCの鉄則だな