AI Coding Agent時代のcdk-nagガードレール 〜組織ルールを強制CIで守り抜く設計の挑戦〜

「AWS CDK Conference Japan 2026」での登壇資料です。
イベントURL：https://jawsug-cdk.connpass.com/event/393595/

Transcript

1. © 2026 Mizuho Bank, Ltd. AWS CDK Conference Japan 2026 AI Coding Agent 時代の cdk-nag ガードレール ～組織ルールを強制 CI で守り抜く設計の挑戦～ 2026年7月18日 情報数理工学研究所 デジタル技術開発部 0 免責事項 当レポートは情報提供のみを目的として作成されたものであり、商品 の勧誘を目的としたものではありません。本資料は、当社が信頼でき ると判断した各種データに基づき作成されておりますが、その正確性、 確実性を保証するものではありません。また、本資料に記載された内 容は予告なしに変更されることもあります。
2. © 2026 Mizuho Bank, Ltd. 自己紹介 1 私の業務と CDK の歩み ⚫ 2019：AWS CDK GA 記念 Meetup に参加後、PoC で CDK を活用 ⚫ 2021：CDK で社内プラットフォームの構築・運用を推進 ⚫ 2025：CDK 含む、AI アプリ向けゴールデンパスの企画・設計へ 発信活動 ⚫ builders.flash「AWS CDK で実装したマルチアカウント管理の仕組み」連載 ⚫ 直近 2026 年の登壇履歴 松尾 優成 上席主任研究員 日付 カンファレンス名 4/14 DevOpsDays Tokyo 2026 5/14 クラウドネイティブ会議 CloudNative Track 5/15 クラウドネイティブ会議 Platform Engineering Track 7/16 Developers Summit 2026 Summer 本講演が 今年5本目の採択！
3. はじめに 2
4. © 2026 Mizuho Bank, Ltd. はじめに 3 社内向けに、統制・閉域構成に沿った CDK アセットを配布 Enterprise GitHub Packages CDK カスタム Construct cdk-nag カスタムNagPack 配布用 Git リポジトリ 案件側 Git リポジトリ CDK App コード Publish コード変更をどう統制する？ パッケージ 参照 開発者 社内限定のプライベート環境
5. © 2026 Mizuho Bank, Ltd. はじめに 4 cdk-nag は CDK コードのセキュリティ・コンプライアンス検査ツール カスタム NagPack を作成でき、社内統制に沿った形で検査できる AWS CDK デプロイサイクル内のリソースチェック全体像 設計 ビルド (cdk synth) デプロイ (cdk deploy) リリース・運用 アサーション テスト スナップショット テスト cdk-nag Service Control Policy（SCP） Security Hub CSPM 案件固有の実装が必要 プラットフォームで統制 ※cdk-nag は実装時の単体テストでもチェック可 実装
6. © 2026 Mizuho Bank, Ltd. はじめに 5 cdk-nag のチェックで違反になった場合、どうする？ 1. 違反しないように、プロダクトコードを修正する 2. 理由を記録し、例外として違反を抑制する（今回のメインテーマ） ⚫ 理由を自由に書けるからこそ、運用次第で抜け穴にもなり得る ⚫ 例外可否は、監査で別途判定する必要がある 抑制は「違反を無視する」のではなく「例外理由を記録する」行為
7. © 2026 Mizuho Bank, Ltd. はじめに 6 AI Coding Agent が CDK コードを高速に生成・変更する時代 ⚫ ルール実装だけでは、抑制運用が抜け穴になり得る（報酬ハッキング） ⚫ どうすれば、例外運用を組織で説明できる？ ⚫ 開発速度は落とさず、統制を維持したい 前提となる仕組みの変化を紹介します ※抑制の統制設計が本発表のスコープ （ルール実装や IaC 全般のすり抜け対策は対象外）
8. cdk-nag v3 の登場 7
9. © 2026 Mizuho Bank, Ltd. cdk-nag v3 8 01 利用側 02 提供側 03 監査側 2026年6月に cdk-nag v3.0.0 がリリース！ 破壊的変更あり… 何が変わった？ 1. 利用側 NagPack の適用・例外記録（抑制）の変更 2. 提供側 検査基盤と抑制制御の変更 3. 監査側 レポート出力形式の変更 https://github.com/cdklabs/cdk-nag/releases/tag/v3.0.0
10. © 2026 Mizuho Bank, Ltd. cdk-nag v3 9 1. 利用側 （アプリ/案件リポジトリ） NagPack の適用・例外記録（抑制）の変更 NagPack の適用 違反の例外理由を記録 acknowledge で例外を記録 Aspects → Validations に変更 NagSuppressions は削除
11. © 2026 Mizuho Bank, Ltd. cdk-nag v3 10 2. 提供側 （NagPack 作成者） 検査基盤と抑制制御の変更 変更項目 v2 v3 実行モデル Aspect ベース Policy Validation Framework ベース (CDK 標準方式) ルール実装 メソッド visit(node) （CfnResource の絞り込みが必要） checkResource(node) （CfnResource の絞り込み不要） 提供側での 抑制制限 可能 （条件付き、または常時拒否） 不可 （廃止） NagPack 提供側から、抑制を禁止する手段が廃止 （例外統制はプルリクエスト上の CI など、代替手段で対応）
12. © 2026 Mizuho Bank, Ltd. cdk-nag v3 11 3. 監査側 （出力/CI連携） レポート出力形式の変更 変更項目 v2 v3 出力形式 NagReport.csv （NagReportLogger が出力） validation-report.json （CDK 標準方式） レポートの 粒度 全ルールの検査結果を出力 違反結果のみ出力 抑制情報の 記録 抑制すると自動で CloudFormation Template Metadata に出力 writeSuppressionsToCloudFormation で Template MetaData 出力有無の切替可能 （デフォルト無効） v3 レポート例
13. © 2026 Mizuho Bank, Ltd. cdk-nag v3 12 01 利用側 02 提供側 03 監査側 v3 はルール配布だけでは足りない… 違反の例外をどこで統制する？ cdk-nag v3 の変更点まとめ 1. 利用側 NagPack の適用・例外記録（抑制）の変更 Validations で適用し、acknowledge で例外理由を記録 2. 提供側 検査基盤と抑制制御の変更 Policy Validation Framework になり、提供側で抑制制御不可に 3. 監査側 レポート出力形式の変更 違反のみ出力し、CFn Template Metadata の例外出力が任意に
14. 単なるルール配布から、 例外を説明可能にする統制へ 13 ※検討中の内容であり、フィードバック歓迎！
15. © 2026 Mizuho Bank, Ltd. 単なるルール配布から、例外を説明可能にする統制へ 14 cdk-nag 違反の例外を CI で管理する ⚫ v3 ではカスタム NagPack 提供側で、違反の例外を制御する手段がない ⚫ 例外管理の監査ポリシーを設けて、組織的に CI チェックする方針がよさそう ⚫ 例外を許容するかどうかで、カスタム NagPack のルールを仕分けする ① 例外禁止 ② 条件付き許可 acknowledge による例外を認めない （例） 理由があれば例外を認める （例） • S3 バケットのパブリック公開 • SCP で禁止されている設定 S3 バケットのアクセスログ設定 →ログ格納用バケットには不要
16. © 2026 Mizuho Bank, Ltd. 単なるルール配布から、例外を説明可能にする統制へ 15 CDK リソースの CI/CD 統制例 Pull Request 開発者 Enterprise 組織強制CI (Organization Rulesets) GitHub Packages CDK ソース Git Repository 案件固有CI GitHub Actions マージ “cdk-nag 監査 (例外統制)” 起動 deploy CFn スタック Security Hub CSPM SCP 禁止操作を防止 デプロイ後 リソース監視 監査ポリシー
17. © 2026 Mizuho Bank, Ltd. 単なるルール配布から、例外を説明可能にする統制へ 16 組織強制 CI における cdk-nag の監査フロー ① 必須の NagPack が適用されているか ② NagPack の実行結果が正常終了か ③ 例外の記載（acknowledge）があるか マージ不可 マージ可能 Yes No No Yes No ④ acknowledge されたルールに例外禁止が含まれるか ⑤ 承認者が例外の理由を許可するか（条件付き許可） Yes No（承認者に確認を促す） Yes Yes No
18. © 2026 Mizuho Bank, Ltd. 単なるルール配布から、例外を説明可能にする統制へ 17 なぜ CI で例外統制する？ SCP や CSPM との役割分担は？ ⚫ SCP は絶対禁止したい操作を定義 • 実運用では全ルールを単純に機械判定できず、例外を認める場合あり • SCP は社内ルールを網羅しておらず、条件付き許可の表現が難しい ⚫ CI では、シフトレフトで社内ルール違反の検知と『例外の可否判定』ができる プルリクエスト デプロイ 運用 組織強制 CI CDK コードの静的解析 （社内ルールの例外統制を担う） 予防的統制（SCP） 機械判定で 絶対に禁止したい操作を予防 （社内ルールの一部を担う） 発見的統制（CSPM） デプロイ済リソースの 準拠/違反を常時検知 （CI を通らない変更の受け皿）
19. © 2026 Mizuho Bank, Ltd. 単なるルール配布から、例外を説明可能にする統制へ 18 今後の議論ポイント ⚫ 開発者体験を崩さずに運用が回るか ✓ 承認者の負荷が高まり、開発のボトルネックにならないか ✓ 強制 CI が、厳しすぎず・緩すぎない適度なバランスを取れるか ✓ 強制 CI をどの範囲・厳格度で適用するか （プラットフォームチームなど強権限が必要な場合でも同じ NagPack を適用してよいか） ⚫ 強制CI での追加チェック ✓ エスケープハッチ（CFn Override）など、cdk-nag のすり抜け対策 ✓ コード・シークレットスキャンなど、CDK 以外の要素も要検討
20. まとめ 19
21. © 2026 Mizuho Bank, Ltd. 20 まとめ ⚫ AI Coding Agent で cdk-nag 違反の抑制が手軽になり、抜け穴に… ⚫ 違反の例外を認めるかどうか、事前に各ルールを仕分け ⚫ 例外を CI で検出し、人（承認者）が例外の妥当性を確認 ⚫ cdk-nag v3 では破壊的変更があり、監査設計の前提が変わる点に注意 cdk-nag の役割を単なるルール配布から 例外を説明可能にする統制へ拡げる