IaCのテスト戦略 — plan確認から自動検査までどこまでやるか

IaCのテスト戦略で現場が行き詰まる原因は、手法の選択よりも「どこで自動化を止めて人が判断するか」という境界の曖昧さにあります。静的解析・plan差分・ポリシー検査・結合テストはそれぞれ検出できる問題の範囲と導入コストが異なり、組み合わせの正解は組織の規模や変更頻度によって変わります。本番環境での事故を防ぐテスト設計は、手法の網羅より役割分担の明確さと自動化の限界点の引き方にあります。各手法の使い分けと、開発速度を落とさず事故を防ぐ設計判断の考え方を整理します。

「applyして確かめる」だけでは事故る構造

変更の副作用が見えない問題

IaCを導入した初期フェーズでは「変更してapplyしてみれば分かる」という進め方が通りやすいです。環境が数台程度の小規模であれば、試行錯誤のコストも許容範囲に収まります。しかし本番環境やマルチアカウント構成に踏み込んだ途端、applyが引き起こす変更は対象リソース単体にとどまらず、依存するセキュリティグループ・IAMポリシー・ロードバランサーのリスナー設定にまで波及します。変更前の影響範囲を人の目だけで追い切れなくなるのが、事故が生じる構造的な理由です。構築を任されたある担当者がVPCのCIDR設定を1行修正した結果、依存する30以上のサブネットとルートテーブルが一斉にreplaceされ、深夜の緊急対応に発展したという話をよく聞きます。

意図しないdestroyが本番に届く経路

applyで確かめる運用でもっとも危険なのは、意図しないdestroyアクションが本番に到達するケースです。Terraformでは属性によって設定変更がin-place updateではなくdestroy → recreateとして実行されることがあり、この挙動はplan出力に明記されています。しかしpull requestに貼られたplan差分が50行を超えると、destroyの1行を読み飛ばすことは珍しくありません。CIでplan結果の自動判定を設けておらず人の目だけに頼る構成では、「見落としによる本番destroy」が定期的に発生します。レビュワーを責めるより、仕組みとして検出できていないことを問題の本質として捉える必要があります。

人手レビューだけでは防げない変更速度

チームがIaCを積極活用し始めると、1日に十数件のpull requestが飛び交うようになります。レビュワーが2〜3人しかいない体制では、各PRのplan差分を精査できる時間は実質20〜30分以下に圧縮されます。その結果、形式的なApproveが慢性化し、テスト戦略のないまま「実質applyして確かめる」運用に戻る本末転倒が起きます。人手レビューは最後の防衛線として機能しますが、その前段の自動検査レイヤーが薄い状態では、レビュワーへの負荷が集中するだけで事故のリスクは下がりません。

静的解析・plan差分・ポリシー検査の役割分担

静的解析が拾えるものと拾えないもの

tflintやcheckovといった静的解析ツールは、コードを実行せずに構文・命名規則・セキュリティ設定の違反を検出します。S3バケットのパブリックアクセス許可、セキュリティグループの0.0.0.0/0開放、暗号化設定の欠落といった「書かれていないこと・明らかに誤っていること」は高精度で拾えます。一方で、実際にplanを実行しないと判明しないリソース間の依存関係の破綻や、プロバイダーAPIが返す想定外の差分は検出範囲外です。静的解析は「書くときのガードレール」として機能しますが、「実行したらどうなるか」の判断には踏み込めません。この限界を理解した上で、plan差分との組み合わせを設計することが重要です。

plan出力を証拠として使う設計

terraform planの出力は、変更前後のリソース状態と実行アクション（create/update/replace/destroy）を明示します。この出力をCI/CDパイプラインで保存・可視化することで、コードレビュー時に「このPRはどのリソースをどう変えるか」が一目で確認できるようになります。plan出力をJSON形式で保存しておくと、後述のポリシー検査ツールがそれを読み込んで判定を行えます。さらに変更履歴の監査要件がある組織では、plan JSONをアーティファクトとして保管する設計が有効です。plan差分の「証拠化」は、レビュワーへの負荷軽減と事後の説明責任を同時に担います。

ポリシー検査でガードレールを自動化する

Open Policy Agent（OPA）やHashiCorp Sentinelは、Terraform planのJSON出力を受け取り、組織が定めたポリシーに反する変更をCIで自動的に拒否できます。「本番RDSに削除保護がなければNG」「インターネット向けSGが追加されたらNG」「指定リージョン外へのリソースデプロイはNG」といったルールを宣言的に記述でき、人の目では見落としやすい違反を機械的に検出できます。ポリシー検査はplan後・apply前のゲートとして機能するため、コードを見ただけでは判断できない実行時の変更内容まで踏み込んで判定できる点が、静的解析との本質的な違いです。

比較表: 各テスト手法のコスト・検出範囲・導入難度

手法	検出できる問題	検出できない問題	実行コスト	導入難度
静的解析（tflint / checkov）	構文エラー・命名違反・既知のセキュリティ設定漏れ	実行時の差分・依存関係の破綻	低（数秒〜数十秒）	低（設定ファイル追加のみ）
terraform plan差分確認	実際の変更アクション（create/replace/destroy）の可視化	ポリシー違反・意図外の挙動の自動判定	中（数分、APIコール発生）	低〜中（CI連携が必要）
ポリシー検査（OPA / Sentinel）	plan結果のポリシー違反・危険なアクションの自動ブロック	実際のインフラ挙動・ネットワーク疎通	低（plan JSON解析のみ）	中（ポリシー記述の学習コスト）
結合テスト（Terratest等）	デプロイ後の実挙動・エンドポイント疎通・権限確認	コスト・スケール・長時間の安定性	高（実環境構築・破棄で数十分）	高（テストコード記述・環境準備）
ドリフト検出	手動変更による設定ずれ・IaCと実態の乖離	変更前の問題・ポリシー違反	中（定期実行・plan結果比較）	低〜中（スケジューラ設定が必要）

各手法は独立した問題を検出するため、組み合わせが前提になります。ただし全部入れることが正解ではなく、チームの規模・環境数・変更頻度に応じた優先順位付けが重要です。環境数が5〜10程度であれば、静的解析とplan差分の可視化だけでも多くの事故を防げます。結合テストはリソース構築に実コストが発生するため、モジュールの変更頻度が高い箇所や本番相当の構成を確認したい場面に限定するのが、費用対効果の面で現実的な選択です。

どこまで自動検査し、どこから人がレビューするか

自動化の限界点を定義する

自動検査は「あらかじめルール化できる問題」の検出に強く、「文脈が必要な判断」には不向きです。ポリシー検査でdestroyアクションを一律ブロックする設定を入れた場合、正当な理由でリソースを削除したいときに毎回例外処理が必要になります。ルールが厳格すぎると正当な変更まで止まり、開発者がIaCの外で手動変更するようになる逆効果が生じます。「このルールを機械に委ねて良いか、それとも人が状況を見て判断すべきか」という問いで自動化の限界点を引くことが、実践的なテスト設計の出発点です。

レビューゲートの設置場所

自動検査をパスしたPRに対して、どのタイミングで人がレビューするかの設計も重要です。IaCにおいて「CIが通ったら自動マージ可」という設計は推奨されません。特に本番向けブランチへのマージは、自動検査結果をレビュワーが確認した上で承認する二段階を基本とします。ステージング環境と本番環境のapplyを分けているチームでは、ステージングへのapply結果を確認した後に本番向けapplyを承認するゲートを設けることで、人が目視確認できる機会を段階的に確保できます。

チームサイズで変わる最適点

IaCを扱うエンジニアが5名以下のチームと、20名超が並行開発する状況では、最適なテスト設計は大きく異なります。小規模チームでは全変更をレビュワーが追える前提でポリシー検査を絞り、人の判断に委ねる割合を高めにする選択が合理的です。一方、20名を超えるチームでは全変更を個人が追うことが物理的に困難になるため、ポリシー検査を厚くして機械的なNGを増やし、人のレビューは「ポリシーでは判断しきれない変更」に集中させる設計の方が長期的に運用しやすくなります。

壊す変更(destroy/replace)を事前に止める設計

replace判定をCIで検知する仕組み

plan出力のJSONにはアクションタイプが記録されており、replaceまたはdestroyアクションが含まれるリソースをスクリプトで抽出できます。CIのステップにこの抽出処理を組み込み、replaceアクション検出時にPRへ自動コメントを投稿するだけで、レビュワーへの「このPRはリソースの再作成を含む」という強調通知が実現できます。destroyアクションが含まれる場合はCIを失敗ステータスにして、追加承認なしにはマージできない設計にするチームも多いです。具体的な実装手順は各CIツールのドキュメントに委ねますが、設計の考え方として押さえておく価値があります。

destroyアクションへの承認フロー設計

本番環境でのdestroyには、通常のapply承認とは別のフローを設けることが推奨されます。destroyアクションが検出されたplan結果に対して、シニアエンジニアやSREが専用のチェックリストに沿って判断するフローを定義します。「このリソースのデータは別途バックアップ済みか」「依存サービスへの影響通知は完了しているか」「ロールバック手順は確認済みか」をチェックリスト化することで、担当者が変わっても同じ判断基準を維持できます。フローのドキュメント化がそのままオンボーディング資料にもなる点も、組織的な効果として見逃せません。

誤爆ゾーンを最小化するステート分割

Terraformのステートファイルを大きな単位でまとめて管理していると、1つのapplyが広範囲のリソースに影響を及ぼし、意図しないdestroyの影響範囲が拡大します。ステートをライフサイクル単位・チーム単位・環境単位に細かく分割することで、1回のapplyが影響できる範囲を限定できます。本番環境ではネットワーク層・計算リソース層・データ層をそれぞれ独立したステートに分割することで、データ層の誤変更がネットワーク設定を巻き込む連鎖を防げます。ステート分割はapply権限のスコープとも対応させることで、権限設計との整合が取りやすくなります。

テストを重くしすぎて開発が止まる境界

CIが遅くなるとIaCが書かれなくなる

IaCのCIパイプラインがpushのたびに15分以上かかるようになると、「IaCを書くより手動で設定した方が早い」という判断が現場で起きやすくなります。これはテスト戦略の失敗ではなく、フィードバックループの設計ミスです。結合テストで実環境を構築・破棄するステップは1回あたり10〜30分かかることが多く、全PRに対して毎回実行する設計は現実的ではありません。結合テストの実行をmainブランチへのマージ後や夜間バッチに限定し、PR段階では静的解析とplan確認にとどめる分割が、速度と品質のバランスを保つ実践的な選択です。

フィードバックループの適切な分割

IaCのテストは「高速フィードバックが必要な層」と「深いチェックが必要な層」を意図的に分けることで、全体の待機時間を最小化できます。PR時点の高速層では静的解析（数十秒）・plan差分取得（数分）・ポリシー検査（数十秒）を直列に並べ、合計で5分以内に結果が出る設計を目指します。深いチェック層では、モジュールの結合テストをmainマージ後のナイトリービルドで実行し、翌朝の確認ループに組み込みます。この二層設計により、日中の開発を止めずに深いチェックを並行して回せる体制が整います。

テスト戦略を育てる運用サイクル

IaCのテスト戦略は、一度設計したら固定ではなく、本番障害・ヒヤリハット・チームの変化に応じて継続的に更新するものです。本番でdestroyが起きたなら「なぜポリシー検査で止められなかったか」を振り返り、新しいルールを追加します。CIが遅くなったなら「どのステップが重いか」を計測して分割を見直します。このサイクルを3〜6ヶ月ごとに回す習慣をチームに根付かせることが、テスト戦略を形骸化させない核心です。「完成させるもの」ではなく「更新し続けるもの」と位置づける文化の転換が、長期的な安定運用につながります。

IaCテスト戦略チェックフレーム

以下のチェックリストをテスト設計フェーズの判断材料として活用してください。全項目を満たすことが目的ではなく、チームの規模・変更頻度・リスク許容度に応じた取捨選択が前提です。

• 静的解析の導入：構文チェック・セキュリティルール検査がCIに組み込まれており、PRごとに自動実行されているか
• plan差分の可視化：terraform planの結果がPRコメントまたはアーティファクトとして保存・確認できる状態になっているか
• destroy/replace検知：plan結果にdestroyまたはreplaceアクションが含まれる場合、自動警告またはCI失敗が発生する仕組みがあるか
• ポリシー検査の定義：組織のガードレール（暗号化必須・リージョン制限・削除保護など）がコードではなくポリシーとして定義され、plan後に自動判定されているか
• 承認フローの分離：本番環境へのapplyおよびdestroyアクションの承認は、通常のPRレビューとは異なる手順・承認者が設定されているか
• ステート分割の検討：1回のapplyが影響するリソース範囲をライフサイクル・レイヤー単位に限定するステート分割が実施されているか
• フィードバック速度の確保：PR段階のCIが5〜10分以内に完了するよう、重い結合テストは別パイプライン（夜間・マージ後）に分離されているか
• ドリフト検出の仕組み：手動変更による設定ずれを検知する定期的なplan実行の仕組みが整っているか
• テスト戦略の更新サイクル：本番障害やヒヤリハットを受けてポリシーとゲートを見直す定期的なレビューサイクルが設定されているか