■ 1. コーディングエージェント時代のIaCレビューの課題
- 従来のIaC開発:
- 人間が少量ずつコードを書くため、暗号化設定や保持期間、タグ付けの確認もレビューで吸収できた
- 生成速度とレビュー速度の乖離:
- Codexなどのコーディングエージェントにより、IaCの作成速度が上がった
- 人間のレビュー速度や設計判断の速度は同じ割合では上がらない
- 従来どおりのレビューを続けると、レビュー待ちの増加や見落としのリスクが生じやすい
- AIレビューの限界:
- 生成コードを別のAIにレビューさせる方法もある
- ただし、ログ保持期間や暗号化の有無など答えが明確な項目まで毎回LLMに判断させる必要はない
- 組織のルールに従うべき項目は、機械的に評価できる形にする方が一貫性と再現性を確保しやすい
- Guardrailの自動化:
- 重要なのは、AIがコードを書くことだけではない
- AIや人間が毎回判断しなくてよい項目をGuardrailとして自動化することも重要
- 実装手段として、AWSがOSSで公開するCloudFormation GuardをCodexの作業中に使う
- 検証時点:
- 2026年9月3日時点で、CloudFormation Guard 3.2.1を使って確認した内容
■ 2. 結論
- レビュー粒度の見直し:
- エージェントが生成したIaCを、すべて人間や別のAIが同じ粒度でレビューする必要はない
- 機械的に判断できる項目をPolicy as Codeで検証すれば、人間は要件、構成、コストなどの設計判断に集中できる
- 想定フロー:
- エージェントがIaCを生成し、Policy as Codeツールでチェックする
- NGならエージェントが修正して再検証し、OKなら人間が設計判断を中心にレビューする
- 仕組みの要点:
- 最初から正しいコードを書かせることだけを目指さない
- 間違いをすぐ検出し、修正と再検証を繰り返せる仕組みを用意する
- ルール化できる項目とできない項目:
- 暗号化、保持期間、必須タグなどは明示したルールで決定論的に検証できる
- リソースの必要性や、可用性とコストのバランスは単純なルールでは決められない
- Policy as Codeの目的はレビューをなくすことではなく、人間がレビューすべき項目を減らすこと
■ 3. CloudFormation GuardとPolicy as Code
- CloudFormation Guard:
- JSONやYAMLのデータを、Guard DSLで書いたルールに照らして評価するOSSのPolicy as Codeツール
- CloudFormation以外の構造化データも検証できる
- Policy as Code:
- 組織やシステムのルールを、機械的に評価できるコードとして管理する考え方
- 例として「監査ログは365日保持する」という設計標準をGitで管理する
- 変更履歴を残せ、ルール自体もレビューやテストの対象にできる
- cfn-lintやCheckovとの違い:
- IaCの自動チェックツールは、それぞれ確認する目的が異なる
- CloudWatch LogsのRetentionInDaysに90を指定することは、CloudFormationの仕様上は有効
- セキュリティ上も必ずしも誤りではないが、「監査ログは365日保持」という組織ルールには違反し得る
- Guardを選んだ理由:
- 組織固有の設計標準をシンプルに記述できる
- コード化したルールで、コーディングエージェントやCIから同じ基準で繰り返し検証できる
- 実際の開発では各ツールを排他的に選ばず、目的に応じて組み合わせる
■ 4. CloudFormation Guardによる検証の実践
- 検証シナリオ:
- CloudWatch Logsの保持期間を、ApplicationログとAuditログで分ける
- Applicationログは90日、Auditログは365日とする
- 同じリソースタイプでも、用途によって正しい値が異なるケース
- インストール:
- Linuxではinstall-guard.shをcurlで取得して実行し、PATHに~/.guard/binを追加する
- テンプレートの準備:
- 用途ごとにLogGroupを作り、LogTypeタグとRetentionInDaysを設定する
- Guardルールの構成:
- まずテンプレート内のAWS::Logs::LogGroupを抽出する
- LogTypeタグで用途別のコレクションに分け、それぞれに異なる保持期間を適用する
- LogTypeタグ未設定への対策:
- 用途別ルールだけでは、タグのないLogGroupがどのコレクションにも入らず検証がSKIPになる
- そのため、許可したLogTypeタグの存在を確認するルールも定義する
- カスタムメッセージ:
- 違反時のメッセージを<<と>>の間に記述する
- 値の誤りだけでなく、RetentionInDays自体がない場合も用途別ルールはFAILになる
- Codexが修正内容を判断しやすいよう、メッセージに期待値を明記する
- validateコマンドの結果:
- 準拠したテンプレートでは終了コード0で終了する
- 違反を検出すると終了コードが0以外になるため、CIの品質ゲートに使える
- 違反の検出:
- 監査ログの保持期間を90日に変え、--show-summary allで再検証する
- 違反ルール名、メッセージ、プロパティパス、実際の値90、比較値365が出力される
- CloudFormationとして有効な値でも、組織ポリシー違反として検出できる
■ 5. Guardルール自体のテスト
- validateとtestの違い:
- cfn-guard validateは、テンプレートがルールに準拠しているかを検証する
- cfn-guard testは、ルールが意図どおりに判定するかを確認する
- テストデータの書き方:
- inputに検証用の入力データ、expectationsに期待する判定結果を記述する
- 準拠するケースと、監査ログの保持期間が短すぎるケースを用意する
- テスト結果の読み方:
- 期待どおりの判定になったルールはPASS Rulesに表示される
- Expected = FAILはテスト失敗ではなく、ルールがFAILと判定することを期待するという意味
- 期待と実際の判定が一致しないルールはFAIL Rulesに表示される
- テストの効果:
- 正常な入力と違反する入力の両方をテストしておく
- 設計標準の変更でルールを直した際、既存の判定を壊していないか確認できる
■ 6. CodexとCloudFormation Guardの連携
- AGENTS.mdへの組み込み:
- AGENTS.mdは、コーディングエージェントに作業ルールや手順を伝える設定ドキュメント
- CloudFormation変更時は、作業完了前にcfn-lintとcfn-guard validateを実行するよう記載する
- GuardがFAILした場合は、出力を見て修正し、PASSするまで再実行させる
- 動作確認:
- 監査用LogGroupのRetentionInDaysが誤って90になったテンプレートをCodexに修正させる
- 最初の検証で違反が検出され、終了コード19で終了する
- Codexは出力から修正内容を判断し、該当値だけを90から365に変更する
- 再検証で対象ルールがPASSになり、終了コード0になる
- 連携の効果:
- 自然言語の指示だけでは、見落としや解釈の違いが起こり得る
- Guardが違反箇所と期待値を具体的に返すため、その場で修正と再検証のループを回せる
- 同じルールは、ローカルや他のコーディングエージェント、CIでも再利用できる
■ 7. 実運用でのCI・デプロイ時の検証
- エージェント側の検証だけに頼らない:
- Codexがコマンドを実行し忘れる可能性がある
- 人が直接テンプレートを変更することもある
- CIでの品質ゲート:
- Pull Requestの作成時や更新時に、CIで同じルールを実行する
- マージ前の品質ゲートとして機能させる
- デプロイ時の強制:
- 強いガバナンスが必要なら、AWS::CloudFormation::GuardHookも選択肢になる
- プロビジョニング前にGuardルールを評価できる
- Failure ModeはWARNまたはFAILを設定でき、FAILなら違反時にプロビジョニングを失敗させる
■ 8. Guardに向くレビュー・向かないレビュー
- Guardに向いている項目:
- 暗号化の有無や暗号化方式
- ログやバックアップの保持期間
- 必須タグ
- Public Accessの禁止
- 許可するインスタンスタイプ
- Security Groupの禁止ポート
- 人間やAIのレビューが必要な項目:
- そもそもそのリソースが必要か
- 要件に対して構成が適切か
- 可用性とコストのトレードオフ
- 障害復旧方針が業務要件に合っているか
- ポリシー自体が妥当か
- ルール化の効果:
- ルール化できる項目を増やすほど、人間は背景やトレードオフを含む判断に時間を使える
- ルール化しすぎの弊害:
- 細かい条件まで対象にすると、個別要件に合わせた条件分岐が増えて管理が複雑になる
- まずは保持期間や必須タグなど、判断基準が明確で繰り返し確認する項目から始める
■ 9. まとめ
- 二段階での検出:
- GuardをCodexの作業中とCIの両方で実行する
- ポリシー違反を、生成直後とマージ前の二段階で検出できる
- Policy as Codeの目的:
- 人間のレビューをなくすことではない
- 人間が判断すべきレビューに時間を使えるようにすること