はじめに
こんにちは！2025 Japan AWS Jr. Champion の、株式会社Relic 所属エンジニア、エイミ/amixedcolor です！(𝕏はこちら)
今回、AWS CDK Conference Japan 2025 に参加しています！一人の参加者として 全力で参加 し、その内容を 記事を読んだみなさんにもお届け できるように、この記事で大体わかる を意識して記事を執筆していきます！
セッションはメイントラックを中心に、セカンドトラックの「CDK Vibe Coding Fes‼️」などの体験・内容をお届けします！
リレーについて
この記事は「2025 Japan AWS Jr. Champions 夏のQiitaリレー 」の8日目の記事です。
過去の投稿（リンク集）はこちらからご覧ください！
入場
ご挨拶して名札をいただきつつ、お水もいただきました！ありがたい 
それなりに早めに入れたので、最前中央席が空いてました！わくわく！
オープニング（運営より）
運営の方からいろいろなアナウンスがありました！会場から湧き上がる拍手！いよいよ始まるぞ…！！
キーノート（運営より）
CDK Conferenceの参加者は年々増えているらしいです。
そしてCDK6周年！なんとGitHub上でAWS CDKは620回もリリースされたとのこと！
AWS CDKはなぜ生まれたのか？
AWSには非常に多くのサービスがあります。
統合化や抽象化が必要で、コンピュータサイエンスの歴史でも同様に、抽象化が行われてきました。
AWSはそういったサービスの1つとして、Amplifyがあったり、SAMがあったりします。
それと同様にAWSは AWS Cloud Development Kit を提供しており、それがCDKです。
「抽象化」という言葉でこれまでの歴史やCDKを認識したことはありませんでした。たしかに、今までどんどん抽象化され、低級言語は高級言語に、人間のコーディングはAIのコーディングになっていると思います。
アーキテクチャをプログラミングできるようにしたものがCDKであり、リリース当初は「ゲームチェンジャー」と呼ばれていました。
たしかに、自分は入社時点から自社でもCDKを採用しており意識していませんでしたが、誕生当時のインパクトが大きいものであったのは、想像に難くありません。
では、なぜCDKは生まれたのか？
過去、Amazon Echo Dotのアーキテクチャを変更する必要がありました。
全世界に展開する必要性や、各モジュールを独立して開発したいという要望がありました。
以前まででは AWS CloudFormation でそういった要望が実現されてきましたが、Yamlなど以上の表現力が必要とされていました。
モデル化する能力には限りがあり、宣言型では表現しきれませんでした。
改めて、AWSで提供されているサービスが内部の課題をもとに開発されてきたことを感じます。
「Invent and Simplify」の考え方に基づき、既存のCloudFormationを抽象化することが考案されました。
まず初めに生まれたのがConstructsです。複数のLevelがあり、一貫した定義を行えます。
また、プログラミング言語の採用によって学習コストの低減も行われました。それらをJava Modulesにし、共有することで開発者の体験を高めたのがCDKです。
いろいろな言語へのサポートも考慮し、JSIIを開発することでTypeScriptで書いたコードを複数の言語で扱えるようにしました。
抽象化したものをいろんな具体的な状況で使えるようにする！とても素敵ですね。CDKのことがますます好きになりました！
AI Agent時代のソフトウェア開発を支える AWS Cloud Development Kit (CDK)（高野さんより）
CDKはIaCツールの1つです。
ソフトウェアのコードは今までずっと、人間が書いていました。
しかし現在、AIがコードを書く機会が増えています。これまでのコード支援のレベルを振り返りましょう。
- ドットによるコード補完
- インラインでのコード補完
- AI Agentによる自律的な探索、コード修正、テスト
コード支援は古くからあり、特にここ数年で大きく進化した（コード補完・自律コーディング）と感じます。
なお、現時点ではまだ人間による指示が必要ということには注意が必要です。
今後、どうすればAIが自律的にコーディングできるかなど、AIを中心に考えることが必要です。
AIが期待した結果を返してくれない課題は多いですが、AIにエンジニアの意図を伝える、AI駆動開発のスキルを身につける必要があります。
自分にとってもまさに重要な課題の1つです。まだAI駆動開発のスキルは不足していて、実現したいことを 100% AIだけで実現できる力量を備えられていません。
しかしそれは難しいので、AIが自律的に情報を取得できるように、コンテキストの差をコードで埋める考え方があります。
「Everything as Code」です。
あらゆるものをコードで管理することで変更を追跡可能にし、再現性と一貫性を目的とします。
AI駆動開発スキルと Everything as Code が紐づくのは自分にとって発見でした！たしかに、使いこなしきれないスキルだけでなく、AIにそもそも指示が甘くてもコンテキストが伝わるようにするのは、「AI駆動開発スキル」の補助になりますね。
全てをコードで管理する中心的な役割としてIaCがありますが、その中でもCDKを紹介します。
CDKによって、以下を可能にします。
まさしく理想的な状態だと感じます。弊社でも徐々に対応を進めていますが、改めて重要性を認識しました！
また、AWS CDKでフィードバックループを加速することができます。
- 静的解析（型チェック・Linter・セキュリティ診断）
- CDKの組み込みバリデーション
- テストデプロイやレビューでも、意図に沿ったAPI実装がサポート
人間の曖昧な操作よりも明文化されたコードが有用なことを改めて感じます。
ただし、AIの活用可能性は状況によって現時点でも異なります。
そのために、「あなた自身の体験や考えをシェア」しましょう！
交流会で意識したいことが1つ見つかりましたね！もちろん他の機会でもそうですが、AIをどこでどう使うのか、どういった状況だったのか、CDKとどう絡められるか、話してみようと思います。
CDK Vibe Coding Fes!!（運営(Vibe Coder)より）
きたぞ！自分は Claude Code で参戦します。
「最高にイケてるアーキテクチャ」を作っていきます。
ルールは以下でした。
- initなど一部は手動でも良い
- アーキテクチャ図も作成する
- Draw.ioやmermaidなど
サンプルも共有いただきました。
よーいどん！取り決めはほぼなし！創造性が問われますね。
実装
※全部書いていて長いので、大体でいい！という人は目次から次へ飛んでください！
何をしたかをつらつらと書いていきます。
- GitHubリポジトリ作成
git clonenpm install aws-cdknpx cdk --versionmkdir cdkcd cdknpx cdk init app --language typescript- Claude Code 起動（以降はClaude Code内）
/init 日本語で
CDKによって、最高にイケてるAWSアーキテクチャを作成したいです。最高にイケてるとはどう定義できるか熟考し、複数の筋のいい案を提案してください。
↓↓
最高にイケてるAWSアーキテクチャの提案: │
│ │
│ 1. フルサーバーレス・イベントドリブンアーキテクチャ │
│ - API Gateway + Lambda + DynamoDB │
│ - EventBridge, Step Functions │
│ - 完全サーバーレスで運用負荷ゼロ │
│ 2. マイクロサービス・コンテナアーキテクチャ │
│ - ECS/EKS + App Mesh │
│ - 言語非依存、細かいリソース制御 │
│ 3. エッジ最適化グローバルアーキテクチャ │
│ - CloudFront + Lambda@Edge │
│ - 世界中で低レイテンシ │
│ 4. AI/ML駆動型インテリジェントアーキテクチャ │
│ - SageMaker + Bedrock │
│ - AIによる自動最適化 │
│ 5. ハイブリッド・モダンレガシー統合 │
│ - Outposts + Direct Connect │
│ - オンプレミスとのシームレス統合 │
│ │
│ 選択した方向性に基づいて、CDKで実装を開始します。
↓↓
フルサーバーレス・イベントドリブンアーキテクチャをベースに、ありきたりではない一捻りを加えた案を複数出していただけますか？
↓↓
│ フルサーバーレス・イベントドリブンアーキテクチャの独創的な案: │
│ │
│ 1. 時間旅行型 - イベントソーシングで任意時点の状態を再現 │
│ 2. 自己進化型 - MLで自動最適化するシステム │
│ 3. 量子インスパイア - 複数パスを同時実行し最速採用 │
│ 4. ブロックチェーン型 - 分散合意形成で信頼性向上 │
│ 5. 生物模倣型 - 免疫システムのような自己修復 │
│ 6. パラレルユニバース - 複数実装の自然淘汰 │
│ 7. メタバース連携 - 3D空間でインフラ可視化 │
│ │
│ 選択した案に基づいて、CDKで革新的なサーバーレスアーキテクチャを実装します。 │
↓↓
「量子インスパイア - 複数パスを同時実行し最速採用」を中心に、さらに「アーキテクチャ図に起こした時に洗練されていてイケていてインパクトのある」ものになるための提案をしてください。
↓↓
│ 量子インスパイア型サーバーレスアーキテクチャの実装計画： │
│ │
│ 1. Core Quantum Components │
│ - Quantum Gate API Gateway (確率的ルーティング) │
│ - Superposition Step Functions (並列実行エンジン) │
│ - Entanglement EventBridge (状態相関システム) │
│ 2. Visual Architecture │
│ - 六角形ハニカム構造のLambda群 │
│ - 多次元レイヤー設計 │
│ - フラクタル型自動スケーリング │
│ 3. CDK Implementation │
│ - カスタムコンストラクトで量子ゲートを抽象化 │
│ - Step Functionsで並列実行パターン実装 │
│ - CloudWatch Dashboardで量子状態可視化 │
│ │
│ アーキテクチャ図として美しく、技術的にも革新的なシステムを構築します。 │
↓↓
その提案は技術的に何が優れていますか？量子的な模倣がただの模倣ではなく、真に有用で価値のあるものになるように熟考し、理由を添えて提案してください。
↓↓
⎿ 量子インスパイアアーキテクチャの実装計画：
技術的価値を実現する実装
1. Hedged Requests System
- 複数パス同時実行でP99レイテンシを大幅改善
- Step Functions + Parallel State実装
2. Probabilistic Routing
- Multi-Armed Banditによる動的最適化
- API Gateway + Lambda@Edgeで実装
3. State Entanglement
- EventBridge + DynamoDB Streamsで状態一貫性
- CRDTアルゴリズムの実装
4. Quantum Annealing Optimization
- 探索と収束の自動バランス
- CloudWatchメトリクスによる適応制御
測定可能な成果：
- レイテンシ: 300ms → 100ms (P99)
- 可用性: 99.9% → 99.99%
- コスト: 30%削減
CDKで段階的に実装し、各コンポーネントの価値を実証します。
↓↓
承認！と思ったらエラー 
API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.9.content.2: `thinking` or
`redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the
original response."}}
↓↓
今までの議論をたどり、特に最後の意見に比重を置き、包括的に最高にイケてるアーキテクチャをCDKで実現する計画を立ててください。
↓↓
⎿ 量子インスパイアアーキテクチャのCDK実装計画:
4週間の段階的実装
Week 1: 基盤構築
- プロジェクト構造整備
- Core Constructs (QuantumGate, SuperpositionEngine, EntanglementBus)
Week 2: 量子的機能
- Hedged Requests System (レイテンシ50%改善)
- Multi-Armed Bandit Router (動的最適化)
- State Entanglement (一貫性保証)
Week 3: 高度な最適化
- Quantum Annealing Optimizer
- Speculative Execution
- Chaos Engineering
Week 4: 可視化
- Quantum Dashboard (3D可視化)
- Hexagonal Service Map
期待される成果
- P99レイテンシ: 300ms → 100ms
- 可用性: 99.9% → 99.99%
- コスト: 30%削減
段階的に実装し、各フェーズで価値を実証します。
↓↓
承認！今回は無事に動いたので、以降はしばらく眺めます。
↓↓
・・・
↓↓
このアーキテクチャにより、従来のサーバーレスシステムと比較して：
- レイテンシ50%改善
- 可用性99.99%達成
- コスト30%削減
- 開発速度3倍向上
量子物理学からインスピレーションを得た、真に革新的なクラウドアーキテクチャです。
↓↓
今のcdkコードのアーキテクチャを、これまでの議論も含めて解析し、draw.ioのアーキテクチャ図に落とし込んでください。
↓↓
〜〜〜（図のコードベタ書き）
アーキテクチャ図の説明
視覚的特徴
1. 量子レイヤー構造: 4層の明確な分離
2. 六角形ハニカム: Lambda関数群の量子的配置
3. 量子フロー: 色分けされた実行パス
4. 物理学的注釈: 各層の量子原理説明
色彩設計
- Edge Layer: 深い青 (宇宙色)
- Superposition Layer: 明るい青 (重ね合わせ状態)
- Entanglement Layer: 紫 (量子もつれ)
- Measurement Layer: 緑 (観測・結果)
量子的要素
1. 不確定性原理: 確率的ルーティング
2. 重ね合わせ: 並列実行パターン
3. 量子もつれ: イベント相関システム
4. 観測効果: モニタリングによる最適化
この図をdraw.ioにインポートすれば、技術的な正確性と視覚的インパクトを両立した革新的なアーキテクチャ図が完成します。
↓↓
図を作成できるコードファイルをワークスペースのルートに作成してください。
↓↓
図ができたのでWebで開いてみたところエラー
ファイル読み込みエラー
図面ファイルではありません。 (error on line 140 at column 89: xmlParseEntityRef: no name)
これをそのまま入力として渡しました。
↓↓
無事図が読み込めましたが、あまりにAWSの一般的な図と異なってしまったので修正してもらいます。（インパクトとかを指示したのでおそらくこうなってしまいやすかったです。）
改めてplanモードにて。
正常に表示されましたが、いわゆるAWSのアーキテクチャ図とはデザインが大きく異なるので、一般的にどのようなデザインで行われるのか熟考して調査し、修正してください。
↓↓
⎿ AWS標準準拠のアーキテクチャ図修正計画:
現状の問題
- 宇宙テーマ（濃紺背景）で非標準的
- 独自の六角形デザイン
- 量子物理学的装飾が過度
- AWS公式ガイドラインから逸脱
修正方針
1. 標準AWS準拠デザイン
- 白背景に変更
- AWS公式アイコンセット使用
- 左→右のデータフロー
- VPC/Subnet境界の明確化
2. 色彩設計の標準化
- AWSオレンジ (#FF9900) をプライマリに
- サービス別標準色（Compute:オレンジ、Data:ブルー等）
- クリーンなグレーの接続線
3. 量子概念の整理
- メイン図: 標準的なAWSアーキテクチャ
- 右側注釈: 量子アルゴリズムの説明
- フロー説明: 技術的価値の文字説明
4. 構造の再設計
- 4層構造 → 標準的なTier構造
- VPC境界ボックスの追加
- グリッドベースの整列
技術的価値を保持しつつ、AWS標準に準拠した専門的なアーキテクチャ図に修正します。
一旦良さそうなので承認！
↓↓
出来たものはだいぶ良くなったけどちょっと惜しい！
改めてplanモードで進める。
惜しいです、矢印は水平または垂直で直角に折り曲がるもののみにし、AWSの公式のアイコンを使用してください。
↓↓
⎿ AWS標準準拠の最終修正計画:
現在の問題
1. 接続線: 曲線を使用（curved=1）
2. アイコン: 汎用四角形、AWS公式アイコン未使用
3. レイアウト: 直交配置が不完全
修正内容
1. 接続線の標準化
- orthogonalEdgeStyle使用
- 水平・垂直・直角のみ
- curved=1を全削除
- strokeColor=#232F3E（標準グレー）
2. AWS公式アイコンの適用
- shape=mxgraph.aws4.* 指定
- Lambda: mxgraph.aws4.lambda_function
- API Gateway: mxgraph.aws4.api_gateway
- CloudFront: mxgraph.aws4.cloudfront
- DynamoDB: mxgraph.aws4.dynamodb
- EventBridge: mxgraph.aws4.eventbridge_custom_bus
- CloudWatch: mxgraph.aws4.cloudwatch_2
- X-Ray: mxgraph.aws4.xray
3. レイアウト最適化
- グリッドベース配置
- Tier構造の明確化
- 直交接続パターン
完全にAWS標準準拠のプロフェッショナルなアーキテクチャ図に修正します。
↓↓
かなり理想的になってきました！仕上げに日本語にしましょう。
図に関するplanがこれまで2回ともLGTMだったので、今回は直接依頼します。
素晴らしいです。最後に、説明は日本語にし、（リソース名は英語の正式表記ままであることに注意し、）仕上げとして何が必要か熟考の上実装してください。
↓↓
かなり惜しいです！重なりを調整してもらいましょう。
仕上げで失敗すると手戻りになるので、改めてplanモードで臨みます。
文字や図形の重なりが、矢印の上の説明だけは良いのですが、他の重なりは視認性を低くするので、どこで影響があるのか検討し調整してもらえますか？
↓↓
⎿ 🎨 アーキテクチャ図 視認性改善計画
主要調整項目
1. レイアウト最適化
- キャンバスサイズを拡張 (1600x1000 → 1800x1200)
- 左側の凡例・説明ボックスを再配置して重なりを解消
- 右側の情報ボックス群の間隔を調整
2. アイコン配置の改善
- Lambda関数群の間隔を拡大 (現在80px間隔 → 120px間隔)
- DynamoDB群の垂直間隔を調整
- Security Groupの位置を微調整
3. テキストボックスの配置調整
- 凡例を左下に移動 (y=280 → y=350)
- セキュリティ考慮事項との間隔確保
- 右側情報ボックスの垂直間隔を20px拡大
4. フロー説明の最適化
- 重要なフローラベルのフォントサイズ調整
- 矢印上のテキスト位置を微調整
- 長いラベルを短縮または改行
5. 視認性向上
- 背景色のコントラスト調整
- 重要要素のハイライト強化
- テキストの可読性向上
期待効果
- すべての要素が重なりなく表示
- テキストの可読性が向上
- プロフェッショナルな見た目を維持
- AWS標準に準拠したレイアウト
この調整により、図面の視認性が大幅に改善され、技術的な内容が明確に伝わるようになります。
ある程度問題なさそうなので承認！
↓↓
許容範囲くらいのものができました！
最後に、できた画像をリポジトリに含めつつ、README.mdを書いてもらいましょう。
@quantum-architecture.png に図をpngエクスポートしたので、この図をトップに含めた、本リポジトリのcdkアーキテクチャの簡潔でわかりやすい説明をREADME.mdとして作成してください。
↓↓
最終的な成果リポジトリがこちらです！
あとは入賞したか結果を待つのみ…！果たしてどうなる！？
地獄絵図！CDKプロジェクトを手動更新して生まれた大量のプロパティ差分を解消する方法（@akikii__さんより）
タイトルからして地獄絵図すぎる…！！
新しいチームに入ったら
「AWS CDKでリソース定義してるよ！」＆「リソースは手動で変更してるよ！」
怖すぎる 手動で変更しない原則は、状況によっては守られなくなってしまうことがありますよね…。
いっそのこと新しい環境作っちゃえば？→「今動いているものを使いなさい！」
再構築は往々にして承認が降りないことが多いですよね。（良し悪しの話は別とします）
検出できない差分がある
テンプレートとスタックはdiffがとれ、リソースとスタックはdriftがとれるけど、そもそもCDKで定義していないプロパティなどは対象外でドリフトもわからない！
そうだったのか！と初知りでした。確かに言われてみれば、そもそも管理下にない（存在すらわからない）ようにならざるを得ず、そのままでは差分もわからないですね。
Stackへのインポートは全てのプロパティを指定する必要がある
管理下に置くことは可能だが、全てのプロパティを指定するのは大変
そもそもインポートで解決できることを初めて知りました。こういった状況にも対応できるのはさすがですね！
状況によっては少し後からCDK管理に含める、という使い方ができそうです。
全て指定するのは大変ですよね…。自分も不要リソースの自動整理で、手動整理が大変だから作ったことを思い出します。
解決方法（独自命名の4ステップ）
ステップが整理されていてわかりやすいですね！こういったことも抽象化の1つで、「手続の抽象化」だと思いました。この後説明されるMigrateフェーズによって、手動で全てプロパティを指定する手間が省けるようです。
Removeフェーズ
- 依存度の深いリソースから置き換えを検討する
- 対象リソースに削除保護をかける
- スタックから対象のリソースを除外する（Refactorフェーズで使うのでコメントアウトでok）
- リソースを削除する
依存度を考慮するのはポイントだと思いました。いわゆる手戻りを防ぐことにも繋がり、スタック間の場合はDependencyを指定するのにも使えそうです。
Migrateフェーズ
- IaCジェネレータで全体をスキャン（Full Scan）する（IaCジェネレータ：CloudFormationの機能）
cdk migrateでCDKプロジェクトを作成（importと異なり、明示的な指定が不要）- 対象のリソースをcdkプロジェクトに取り込む（失敗時のトラブルシューティングは資料末尾を参照）
明示的な指定が不要なのは大きいですね！！IaCジェネレータ、覚えておこう。
Refactorフェーズ
- スナップショットテストを作成・更新する
- L1→L2 Constructにリファクタリング
- リソースの参照関係、シークレットを置き換える
- スナップショットテストを更新する
後述ではこの部分がAI代替できそうとのことでした。
Importフェーズ
cdk importでスタックにリソースを取り込むcdk driftでスタックとリソースに差分がないか検証する- 差分を解消して終了
この時出た差分が一体どれほど大きかった/多かったのかは少し気になりますね。
L1→L2はスナップショットテストでガードしているので生成AIに任せてもOK！
ただしスナップショットテスト自体を更新されないように
ガードを用意して適切にAIを使うと、さらに簡便に対応できそうですね。
この発表のおかげで地獄絵図がそんなに地獄じゃなく感じられました。もう怖くない！
Stageを活用したマルチステージ運用の最短経路（@kotukotuganbadさんより）
ステージのポテンシャルを解放！
気になる！
ステージとはスタックをまとめてグループ化するもの
なるほど、スタックより大きな括りなんですね。
開発環境へのデプロイフロー
環境別にパラメータを変えたデプロイができる
ステージとデプロイ先環境が異なる時のブロックも実現
自社でも別の方法で環境ごとのパラメータ変更、デプロイ先ミスがないようなチェックを2重にいれていますが、改めて同じ結果を実現する方法は複数あることを感じました。
aspectsを使うと全てのリソースに設定を適用できる
そんな便利な機能もあったんですね！アスペクト、覚えておこう。
ステージとアスペクト、新たな知見を得ました！
CDKで挑むIdentity Centerの運用改善（いけのがみさん）
背景として、AWSログイン管理に Identity Center を利用していた
設定はマネコンからぽちぽち
アカウント数は組織内外で50弱程度
管理できている保証がない課題があり、CDKを採用した
日本語の情報発信が多いことがCDK導入根拠の1つ
「管理できている保証がない」というのは手動で作成していると起きやすい課題だなと感じました。
設計ポイント
- CDKの適用範囲：適用メリットが大きい（リソース数が多い）ところにのみ適用
- スタック構成：必要ないならわけない
費用対効果が最大になるように設計されていたようです。自分で何か行うときも注意していることですが、「必要」なことをやっていきたいですね！
既存環境への適用として
cdk importを活用
SSMパラメータを活用して管理負荷を低減
ここでも cdk import が登場、どこかで使ってみたいところです。
よかったこと
- CDK導入によって今の状態が把握しやすくなった
- 複雑性を抑えながらループ処理を実現
- 運用が安定化
状況把握としての観点もCDK（IaC）で実現できることは学びですね！
課題・考慮点
- 管理アカウントにデプロイが必要
- グループスタックをコードから消しても実体が消えない
- そもそも恒久的なアクセス権の付与で良いのか？
課題は残るものの、まず一歩Everything as Codeに踏み出したような発表でした。聞けてよかった！
The Niche of CDK - Grant オブジェクトって何者？（@hassaku_63さんより）
なんで10分で応募しなかったんだろう、、
登壇応募あるあるの1つですね（笑）5分に収めるのはボリューミーな内容とのことでした。
結論
内部的に型があるんですね…！！初知り、責務の分解をはじめとし、本当にCDKはよくできていますね、、（n回目）
grantメソッドは使いやすいインターフェース
宣言的なコーディングできていいですね！
grantオブジェクトとは、grantメソッドの返り値
返り値取れるんですね…！
意識したら嬉しい（かもしれない）ケース
- cdkコントリビューター
- カスタムconstructを開発する人がgrantメソッドを自作する場合
たしかに！使うケースは限られていますが、使う機会はないわけではありませんね。
テストメソッドでgrantオブジェクトをアサーションすることにも使える
こちらはさらに使える機会が多そう！権限付与が成功したか？のユニットテストに使えるのか、知見。これは聞いていなければ思いつかなかった気がする。
驚くことが多いセッションでした！新しくGrantオブジェクトについて学び、応用が効く場面は多くはなさそうですが、必要に応じて使えることを思いだせればと思います！
ご注文の差分はこちらですか？ - AWS CDKのいろいろな差分検出と安全なデプロイ（@konokenj）
IaCツールは宣言的に状態の差分を自動的に埋めてくれる
差分を正しく理解することで、さまざまな状況に対処できる
cdk diff くらいしか使ったことがなく、違いを説明できません…！これは学びが多そう
スナップショットテストの仕組み
- ユーザーがテストコードを書いて、テストを実装・実行
- ユーザーが意図した変更なら、スナップショットテストを更新
- プルリクエストを送り、スナップショットの差分をレビューする
差分をコードだけじゃなく結果でもレビューできるんですね！
※この説明はAWSの仕様のを示すものではありません
前提、CloudFormation による状態管理
- ユーザーがテンプレートをデプロイ
- CloudFormation がスタックを作成して、テンプレートを保存
- CloudFormation が現在の状態を確認して、変更を「変更セット」で計画
- CloudFormation がリソースを操作
- CloudFormation がリソースの状態（State）を記録する
cdk diff --no-change-set
- テンプレートの新旧比較
- 速いが精度が低い
cdk diff
- 動的参照も含めて、変更セットを計算することで差分を検出
cdk diff --no-change-setより高精度
ここで、自分が cdk diff で行われていることが正しくは cdk diff --no-change-set だったことに気づきました。社内にも共有したい！
CloudFormation の外で状態を変更すると？
- 状態はstateで記録しているが、追跡はしていない
- ドリフトがある状態でデプロイした時の動作は未定義動作
cdk drift
- ドリフト検出を行ってくれる
- ドリフトの解消方法は「AWS CDK 開発を成功に導くトラブルシューディングガイド」を参照
前の発表でもありましたが、drift検出はマネコンからしかできないと思い込んでいました…。今後はこれも積極的に使っていこうと思います！
ご注文の差分は？
どう使い分けるのか、どれくらいカバーできるのかが一目瞭然です！とてもわかりやすい！
CDKにおける差分を確認する4つの方法の内容とその違いについて学びました。この学びをもとに、今後は状況によって適切に使い分けることを検討できそうです！
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ（@_watanyさんより）
完！
湧き上がる拍手！ありがとうございました！！（まだ終わりません）
コーディングエージェントでは自動承認が実装されつつある
うまく使うと安全に放置できるのでいいですね！
直接 CloudFormation をかかせればいいのか？
この話、「01のバイナリ実行可能ファイル書かせればいいのでは？」と少し似ている気がします。
真ん中の AWS CDK は "過剰なレイヤー" ？
いいえ、CDKが解決した課題はそのまま活かした方がいい
同感です！CDKに則るからこそAIは安全で有用に活用できると思います。
AIエージェントは基本人間より速い
しかし、結局人間が間に入るとボトルネック
ボトルネックは人間である
たしかに…。いろいろなところでこの話もよく聞きます。
ではCDKのループの中で人間はどうすればいい？
人間時代→AI時代
- Reading：あった方がいい→あった方がいい
- Writing：あった方がいい→なくてもいい
- Testing：あった方がいい→無いとマズい
テストがないと「正しさ」がわからない（根拠は聞けば出てくるが）
この辺こそ、TDDで書いた方がいいと言われる所以の1つでもありそうです。自動テストが無いと、正解を担保できないですし、テストコードという「宣言的」な定義こそがアプリケーションを形作ると思います。
しかし、AIは報酬ハッキングをするし、テスト自体を書き換えることがある。
注意すべきポイントですね！
テストにおけるCDKとCFnの対応を見たら、両方あるにはある
- CFnのUnitTestsは自明なイコール
- CDKではスナップショットで、バージョン更新やリファクタリングに活きる
- バリデーションも含められる
- CDKではL2をテストすると自明なイコールでは無いのでテストのモチベを保ちやすい
エージェント時代だからこそ、テストを柔軟に書けるIaC
「できる」ことと「適切である」ということは異なりますね。CDKの利点が際立って見えます。
エージェント時代だからこそ、テスト！
AWSのリソースは多く、CFnに起こすと何百行に及ぶ
するとレビューは非常に困難になる
→エージェントの生産性が上がってもレビュアーの負荷は高いまま
これは想像するだけでも大変厳しそうですね…。
CDKは可読性が高く、リソースの関係性を表す記法が充実している
エージェント時代だからこそ、人間の読みやすさの価値が上がる
今はまだ読むことが多いからこそ、読みやすさは大事な価値ですね。
AgentでCDKを書くコツ
- ガードレール（そもそもLLMは否定系に弱い）
- MCP（AWSが公式に用意しているものもある）
- ルール（状況のコンテキストをルールとして用意）
- プロンプト（簡潔・明瞭・定量的に書く）
関係ないことを書かない
最近執筆中の同人誌でも書きましたが、チェーホフの銃の誤謬ですね。AIは入力に引っ張られてしまう…。
"フルコード" の時代
先の発表でもあった Everything as Code にも通づる話ですね！
改めていくつかの認識が補強されつつ、詳細についての学びがあるセッションでした！
AWS CDK単体テスト実装を効率化するライブラリをリリースしました（@HorieTakehiroさんより）
従来のアサーションテストでは
aws-cdk-lib/assertionsモジュールを使うが、型やスキーマが提供されないので、ドキュメントを都度参照したりする必要がある
たしかにこの手間はミスにも時間の浪費にもつながってしまいますね。
aws-cdk-utulでアサーションでも型やスキーマを提供
助かる！！特に人間がコーディングする時には有用そうですね。
テストをする時に困るポイントを解決する方法を1つ覚えることができました。
CDK引数設計道場100本ノック（@nixiemintonさんより）
L2以上のConstructやCustom Constructでどんな型にすると良いのか？
- {{L1}}：{{ほか}}
- boolean：boolean
- データサイズのnumber：Size
- 期間のnumber：Duration
- パターンが決まったstring：enum
- パターンが決まっているが頻繁にパターン数が増えるstring：enum-like class
- 未定義のインスタンスタイプを
ofメソッドで使えるようにする- attributeのstring：コンストラクトのinterface
- アカウント/リージョンのstring：コンストラクトのinterface
- 全てのコンストラクトは
.envを経由することでアカウント/リージョンを取得可能- 失効日時のunixtime：Expiration
- パスワードのstring：SecretValue
- タイムゾーンのstring：TimeZone
- サブネットIDのstring：IVpcとSubnetSelectionを2引数で
- その他のstring：string
「100本ノック」のタイトルの通り、多くの型の対応を知れました！特に Custom Construct をつくるとき、これを自分で参照し直して設計したいですね。
例外的にstringが好ましいケース
無理にstringにはしない、という解釈ができそうです。
応用編
- 複数引数をまとめたオブジェクト：同じオブジェクト or 個別引数定義
- デザインガイドでは後者だが、レビュー時は前者が推奨されやすい
- 密接に関連した複数引数：L1踏襲 or 独自クラス定義
意見が分かれているようですが、まずは簡単な踏襲をすると良さそうです！
まとめ
- まずはstringをなるべく避けよう！
- typoを防げる
- numberもSizeやDurationを使えるケースが多い
結局は状況次第
- 使い勝手とカスタマイズ性は表裏一体
- ベストな定義よりベターな定義
自分でConstructを作る機会は稀ですが、人為的ミスを防ぐといった考え方は他の設計でも応用できそうです。何か書かせる時、何かの型にできないのか、特にTypeScriptでの開発で活きそうです！
Git Syncを超える！OSSで実現するCDK Pull型デプロイ（@t_kikucさんより）
既存のCDKデプロイでは、どの方法でも、継続的に差分検出する方法がない
そこで、PipeCDを使うのはどうか？
PipeCDのエージェントをAWS側に置き（app runnerで可能）、継続的にgitを監視してデプロイする
Pull型は必須ではないが、作り込みを避けつつ、 "Git == CFnスタック" を実現したい時に有用
PipeCDで行われていることは代替可能ですが、作り込みたくない時、OSSらしく「それを使えば簡便に実現できる！」ように使えそうです！
AWS CDKの仕組み（@365_step_tech）
CDKはCDK CLIとCDK Appに分けられるが、やれることは実は結構多い
この図をパッと見て、よくわからないな…となってしまいました。この図を理解できるようになりたい！
cdk deployを掘り下げる（トップレベルはCLIの実施内容）
- CLIからコマンドが走る
- config読み込み
- 各種設定ファイルとコマンドライン引数から context などを取得
- synthesize（合成）
- 子プロセスとしてCDK Appを実行
- Constructフェーズ
- CDKコードからコンストラクトツリーを作成する
- App
- Stack
- Construct
- 内包されている各コンストラクト
- さらに上記がL2ならL1
- アスペクトやバリデーションを適用
- contextの中に欲しい情報が足りなければ、manifest.jsonに書き込むだけ
- SDKはまだ呼び出さない
- ファイルアセットのバンドルをする（typescript→javascript）
- Dockerイメージなど、イメージアセットのビルドは走らない
- Prepareフェーズ
- ツリー完成後、ツリーのルートから順にアスペクト有無のチェック・実行
- リソース間の依存の追加（CFnのDependsOn）
- スタック間の依存関係の解決
- クロススタック/リージョン・ネストスタック参照
- ネストスタック処理
- （CDKv1時は、コンストラクトのprepareメソッドを実行するフェーズだった）
- Validateフェーズ
- バリデーション内容をvalidateメソッドに定義
- Synthesizeフェーズ
- ツリーからCloudFormationテンプレートを生成
- クラウドアセンブリ（CDKアプリの合成結果）をcdk.outに出力
- CloudFormationテンプレート
- アセットファイル
- その他
- （3つのマニアック情報）
- SDK実行、再合成
- 不足するコンテキストを取得し、cdk.context.jsonに書き込み
- 不足があれば再合成
（ここまでは、cdk synthまでで行われる。逆に、これより先はcdk synthでは行われない）- イメージビルド
- イメージアセットのビルドを行う
- アセットアップロード
- CloudFormationデプロイ
非常に詳細かつ明瞭な解説をいただいたおかげで、最初の図がどんなものか理解できました！全体のフローはもちろん、1つ1つに出てきた用語も学びであり、前の発表でも出てきたアスペクトやバリデーション、新しく cdk synth の具体的な内容についても理解が進みました。
（CDKテストでの違いを紹介）
（今までの説明をさらったまとめ）
（自作OSSツールを紹介）
これらは書ききれませんでしたが、興味のある方はぜひ公開された資料などをご確認ください！
クロージング・撮影等（運営より）
アンケートがありました。とっても大事、即記入しました！
そしてVibe Coding Fesの入賞者発表！
-
@hayatinさん - なんと私
@amixedcolor！ -
@mob_engineerさん -
@Tesla_yoonさん
ありがたいことに入賞ということでシャツLサイズをいただけました、ありがとうございます！
評価いただけたのは「量子インスパイア」といういかにもな部分で、狙って奇をてらった甲斐がありました！
そして集合写真も撮りました！相変わらず最後尾におります。
おわりに
このあとは懇親会に参加します。AIについても、CDKについても、いろいろな話ができるのが楽しみです！
ここまでお読みいただきありがとうございました！全力で参加した内容・体験を少しでもお届けできていたら嬉しいです。
エイミでした。それでは、またこんど！