CDKでPRごとに使い捨て環境立てたら便利すぎました

使い捨ての検証環境、作ってますか？

弊社で運用中のプロダクトで、プルリクエストごとに検証環境を構築できるようにしたところ、以下の悩みを一挙に解決できました：

・ステージングにマージする前に、実際のAWS環境で動作確認したい
・ローカル環境ではリソースの干渉で、ワークツリーごとにローカル起動できない
・リモートコーディングエージェントに書かせたPRなので、自分で動作確認しづらい

本セッションでは、この仕組みをCDKで構築した際のハマりどころやコツを共有します。あなたが明日同じことをする時に、確実に役立つはず！

この夏はブランチの数だけ環境を複製しまくって、IaCの本領を発揮しよう！

Transcript

1. 2026/7/18 #cdkconf2026 CDKでPRごとに使い捨て環境⽴てたら 便利すぎました Masashi Tomooka @tmokmss
2. 2026/7/18 #cdkconf2026 友岡 雅志 Masashi Tomooka Software Engineer @AOI Inc. X/GitHub ID: tmokmss AWS (Prototyping Engineer) からスタートアップへ 最近は何でも屋をやっています CDK Conferenceの登壇は2年ぶり3回⽬？（いつもありがとうございます！） ⾃⼰紹介 2
3. 2026/7/18 #cdkconf2026 本⽇の主張: PRごとのプレビュー環境は良いですよ！ プレビュー環境のモチベーション： • ローカル環境ではAWSの挙動を完全に再現できない → 問題の⾒落とし発⽣ • Pull Request (PR)レビューする際、レビュワーとしてはコードだけでなく挙動まで 確認したいが、⾃分のローカル環境で起動するのは⾯倒くさい ◦ 特にコーディングエージェントがポコポコPR⽴てる状況で顕著 ◦ Devin PRの動作確認するためにわざわざPC起動したくない ◦ ワークツリーで並列作業時、ツリーごとのローカル環境はリソース競合が発⽣ 3 PR ごとのプレビュー環境をAWSへデプロイすれ 解決
4. 2026/7/18 #cdkconf2026 Staging環境スタック (定常環境, 共用スタック) 実装例: PRが開いたらdeploy、閉じたらdelete 4 RDS Aurora SQS Queue Lambda (api) AWS CDK API Gateway CloudFront S3 Bucket (frontend) Lambda (job) PR環境スタック (ephemeral) SQS Queue Lambda (api) API Gateway CloudFront S3 Bucket (frontend) Lambda (job) < PRの数だけ増えるよ GitHub Actions 使⽤済みのスタックを削除 スタックを⾃動作成‧更新 < こっちは常駐の環境 ⼀般的な3層サーバーレス構成でPRプレビューするなら、こうなる
5. 2026/7/18 #cdkconf2026 推しポイント • 便利。PRが⽴って数分後にはAWS環境で動作確認できる • インフラの変更もプレビュー可能 （PRスタックに載っている範囲は） • AI時代のボトルネックは⼈間のレビュー → それを円滑にする • とにかく便利。 5
6. 2026/7/18 #cdkconf2026 FAQ: デプロイ遅くて困らないですか？ • デプロイは数分程度に収まるよう設計する （それ以上かかると⽂句が出がち） • 作成時間のかかるリソースは定常環境と共⽤し、環境ごとの作成を不要に ◦ VPCやRDSなど • プレビューで検証できる範囲を合意することが⼤事 ◦ RDS共⽤だとDBスキーマの変更のプレビューはできないが許容するなど • そもそも：AIの出⼒するコードは⼗分正確なので、PRごとに必要なイテレー ション回数は従来より減っている ◦ 多少デプロイ遅くても気にならない（領域にはよる） 6
7. 2026/7/18 #cdkconf2026 他にもデプロイ⾼速化のために有効なアイデア • プレビュー環境専⽤にAWSアーキテクチャを変える ◦ 本番：ALB + ECS → プレビュー: APIGW + Lambda など （LWA） • コミットごとの変更されたファイルによりデプロイ⽅法を変える ◦ フロントエンドだけであれば、CDKをスキップし直接 s3 sync (hotswap? ) • リソース間の依存関係を断ち切って並列化 （例: CloudFront Ref -> カスタムドメイン） ◦ CFnコンソールのタイムライン表⽰は、最適化ポイントを考えるのに便利 7 これがボトルネック ここ 削ってもあまり意味がない
8. 2026/7/18 #cdkconf2026 FAQ: CDK特有のはまりどころは？ • 暗黙の依存: 意図しないスタック間依存が露呈。参照を意識して要回避 ◦ 例: 共⽤RDSのSecurity Group(SG) へのアクセス許可がプレビュー環境のLambdaごとに必要 ◦ 対策例：全プレビューLambdaが同じSGを共有し、RDS SGへの変更を回避する、など • Exportの消失: PRスタックが0個になると、共⽤スタックのExportが消える ◦ 対策例：PRスタックはダミーを常に1つsynthする / 共⽤スタックから明⽰的にexportする 上記含め細かい問題は諸々あったが、AIが解決できる程度でした ちなみに：弊社ではTerraformでも同様の構成を取っているが、どちらが楽というわけでもな い。結局はデプロイ⾼速化のためのアーキテクチャ要件整理が勝負な印象 8
9. 2026/7/18 #cdkconf2026 その他FAQ: • Q: コストは？ ◦ A: アーキテクチャ次第。サーバーレスならプレビュー構成による追加コストはニア ゼロ。デプロイも早いし、現代ではサーバーレスが必須だね (過⾔) • Q: CDK Expressモードは使える？ ◦ A: 試した限りは使えなかった。IAMポリシーの伝播を待たないようで？、カスタム リソースが失敗することがあり⾒送り（完全な原因究明は未完了）。そもそも今は CloudFront作成がボトルネックなので、単純な⾼速化は難しそう。 • Q: PRから⾃動でAWSにデプロイできる構成だと、セキュリティの懸念は？ ◦ A: プレビュー環境は本番環境とAWSアカウントを隔離。これによりIAM権限上は完全に 本番環境と分離しており、blast radiusを抑制する。 9
10. 2026/7/18 #cdkconf2026 おまけ：1発構築プロンプト Fableさんお願いします！☺ 10 開始地点となるものは これで作れるはずです 🫡 https://gist.github.com/tmokmss/6 5228a04b5936489b72bd3f6a92d816 2 +⼿直しを経て…
11. 2026/7/18 #cdkconf2026 弊社もエンジニア募集しています！ 使えるものは全部使って前に進み、 最短で価値を届ける⼈と働きたい！ まずは話だけでも歓迎です！ https://aoiinc.co.jp/recruit ※もちろん会社HPもCDKでデプロイ 11
12. 2026/7/18 #cdkconf2026 まとめ • PRごとにプレビュー環境をデプロイするのは、とてもおすすめ。 特にPR⽣成頻度が上がったコーディングエージェント時代には必須 • CDKでも難なく実装できる • 構築⽤プロンプトもお試しください 12 ⽂字だけのスライドがあったので、チャッピーに 飾り付けしてもらいました笑 CDK (day?) のかわうそ、パンケーキくんです