プロポーザル

本発表では CI 環境での実行や、クロスアカウントでのデプロイメントのシナリオをカバーする CDK 標準の仕組みを解説します。

本発表で想定している主な状況は、GitHub Actions のような CI ツールでデプロイを行う場合や、Organizations の統制側で複数のメンバーアカウントに共通の仕組みを展開する場合です。自前でデプロイ用に強い権限 (e.g. Administrator) を持つ IAM Role を構成していませんか？

実際のところ、cdk deploy の実行主体となるクレデンシャルに必要な権限はほとんどありません。CDK の使い方を覚えたばかりのユーザーにとってキャッチアップの意識が後回しになりやすいであろうデプロイ権限構成の問題について、より安全な権限構成を「仕組みを理解して」使えるようになっていただくことを、この発表のゴールとしています。

SIの案件でCDKを採用しようとしたけども見送った話をしたいです。
具体的には以下の下記の流れで話をしようと思っています。
1.本LTで定義するJTCなSIプロセスとは
　WF開発、開発及び運用保守の体制など
2.CDKを採用しようと思った理由
　SIerの強みとCDKの強みを掛け合わせたら強いのでは？
3.CDKの採用が難しい理由n選
理由１:作ったソースコードは誰のもの？
　お客様の環境へお客様の資材(CDKのコード)をデプロイすることの難しさ
理由２：体制上の難しさ
　開発体制を整備することの難しさ、保守運用の問題など
理由３：周囲の理解がどこまで得られるのか？
　上記理由を押し切ってまでも採用するメリットがあるのか？
理由４：そもそもCDKの理念に沿っている？
　SI個別の案件で見た場合にCDK必要なのか？
４. 私が想う、SIerでのCDKの使い方について
　まとめと今後の展望

CDK のニッチなトリビアを提供する LT をします。本発表では、多くの CDK ユーザーが暗黙的に使っているであろう「Grant オブジェクト」について解説します。

IAM Role などに権限を追加するのに大変便利な grant 系メソッドですが、その戻り値にあたる Grant オブジェクトのことを意識する機会は少ないと思います。
基本的に一般の CDK ユーザーが意識する必要性はそう多くありませんが、CDK の内部実装に手を入れたり、組織横断で配布する共通モジュールとして特定の権限付与パターンを抽象化するのに、知っていると役に立つ...かも、しれません。

grant メソッドの戻り値でなんとなく存在は知っていたけど、結局何者？私たちが使う機会はあるの？と、気になっていた CDK ユーザーの疑問にお答えします。

CDKプロジェクトが成長すると、「ユーザー認証ロジックがLambda関数に直書き」「DynamoDB操作がビジネスロジックと混在」「インフラ変更でドメインロジックも影響を受ける」など
ビジネスロジックとインフラコードが密結合し、テストが困難になり、新メンバーの理解が進まない問題が発生する可能性があります。
monorepo構成で、CDK・Lambda・ドメインロジックをパッケージ単位で分離、Clean Architecture原則をCDKに適用し、
@app/coreでAWS依存ゼロのドメインモデル設計、リポジトリパターンでDynamoDB抽象化、Lambda関数での依存性注入によるレイヤー分離を実装方法を考えます。
Before/Afterコード比較で具体的実装を解説し、ビジネスロジック変更がインフラに影響しない、テスト容易性が向上した持続可能なCDK開発パターンをお伝えします。

フロントエンド・バックエンド・インフラが分離されたプロジェクトでは、API仕様変更時の型不整合、スキーマ定義の重複管理、デプロイ時の仕様ズレなどが発生します。
CDKを独立管理すると「Zodスキーマを定義してもフロントエンドは手動型定義」「API Gatewayスキーマも手動で重複定義」「OpenAPI生成が動作しない」など悩みがつきません。
CDKをmonorepoに組み込み、@app/coreのZod-OpenAPIスキーマを唯一の真実の源として、フロントエンド型定義自動生成、CDK API Gatewayスキーマ自動生成、OpenAPI仕様書自動出力する設計を実装について考えます。
Zodスキーマ変更がフロントエンド・CDK・ドキュメントに反映される型安全な開発体験を実現した具体的手法と、ライブラリバージョン問題の解決策をお伝えします。

AWS CDK開発では、コンストラクトの選定・責務分離・セキュリティ構成といった設計判断が重要ですが、その意図は暗黙知になりがちです。
本セッションでは、AWS-Documentation-MCP-Serverを活用して設計ドキュメントをAIが理解可能な形式で管理し、Amazon Q Developer CLIと連携することで、CLIからの自然言語クエリを通じて設計意図に基づくCDK判断支援を行う仕組みを考察します。
「このLambdaにVPCが必要か？」「S3バケットは暗号化対象か？」「スタックの責務はこれで妥当か？」といった設計判断を、設計ドキュメントを元にAIがリアルタイムに補完。
実際のコマンド実行例、自然言語プロンプトとCDKコードへの影響、設計ドキュメントのMCP記述例、失敗パターンとその改善策をもとに、CDK開発における“AIアーキテクト”との協働の実践知をお伝えします。

CDK Stage を「パイプライン都合でスタックを束ねるだけ」と見なしてはいないでしょうか。本 LT ではparameter.tsに各環境（dev / stg / prd）の アカウント・リージョンと専用パラメータを集中管理し、Stage 経由で共通スタックへ安全に受け渡す設計手法を解説します。

• ディレクトリ構成 (lib/stack, lib/stage, parameter.ts)
• ガードレール envによる誤デプロイ防止
• パラメータ注入 Stage→Stack間で型付きconfigを渡す実装
  など、環境間コード重複と手動ミスを同時に解消する具体策を提示します。

2023年にRubyエンジニアとしてキャリアをスタートした私は「プログラミング言語でインフラを扱う」 AWS CDKに軸足を移し、約1年半にわたり開発に携わってきました。社内で「CDKといえば自分」という認知を得て、CDK関連のタスクや相談を任せてもらえるようになるなど、スキルアップと実績形成の機会が大きく増えました。その結果、AWS Community Buildersに選出されるなど多くの恩恵を得ています。

本セッションでは、まずCDKの概要に触れたうえで

• 希少スキルとしての市場価値
• アプリ開発経験 × TypeScriptで得られる学習相乗効果
• コーディング力を保ちながらインフラ知識を伸ばすメリット
  などCDKがキャリア構築に有意義な点をお伝えします。 CDKに興味を持っている方の最初の一歩を応援できるようなセッションにしたいと思います。

実案件でECS on Fargate + Ruby on Rails を構築した際 「アプリ開発担当にも扱える シンプルな自動デプロイ を提供したい」と考え、 単一の CDK Pipelines でアプリとインフラを丸ごとデプロイする構成を採用しました。
しかし実運用ではビルド時間の肥大化などの課題に直面し、 最終的にパイプラインを インフラ／アプリの 2 レーン に分割し次のように解決しました。

• インフラ　GitHubActions→OIDC認証→S3→CDK Pipelines
• アプリ GitHubActions→ECR→EventBridgeでタスク定義だけを更新

本セッションでは

• CDK Pipelines
• OIDC認証構築
• DockerImageAsset
• ECR ベースの軽量アプリパイプライン実装例
  について実装コードを交えて解説します。

AWS CDKに興味はあるけど、何から手を付ければいいかわからない…そんな方のための「最初の一歩」を徹底解説します。公式ドキュメントやサンプルの使い方、開発を効率化するツール、生成AIの活用法まで、これから AWS CDK を使い始めるあなたに必要な情報をお伝えします。セッション後には「これなら自分も始められる！」という自信が持てる内容です。

CDKプロジェクトを手動で更新しちゃった…この積み重ねで地獄になってませんか？
残念ながら、CDKやCloudFormationでは、プロパティの差分を簡単に解消できる方法は提供されてません

• ドリフト検出でも見つからない差分…
• 設定されているプロパティを上書きしてしまう恐怖…

あなたはどうやって立ち向かいますか？

本セッションでは、次の観点を持って課題解決に挑みます

• 安全性を重視
• 初めからL2 Construrtで書いたかのようなソースコード

CDKやCloudFormationの盛りだくさんな機能も扱います！

• cdk diff
• cdk drift
• cdk migrate
• cdk import
• IaCジェネレーター
• スナップショットテスト

せっかくCDKで管理しているのに手動で変更しているプロジェクトを撲滅しましょう！

「CDKToolkit スタックを誤って削除しちゃった」「複数のスタックでリソースを参照している時にデッドロックしちゃった」といった、AWS CDK をご利用いただく上であるあるのエラーとその回避法を紹介します。
今回は、特にはまりがちなクロスリージョン参照 (crossRegionReferences) に焦点を当てて紹介します。

CDKのCI/CDパイプラインやCloudFormationのGit Sync機能に満足しきれないあなたへ！CDKデプロイの新しい形を一つお見せします。

私がメンテナとして開発に携わるPull型デプロイのOSS「PipeCD」で、まもなくCDKもデプロイ可能になります。

このセッションでは、以下の内容をお伝えします。
・Pull型の嬉しさ（セキュリティ、運用性など）
・CDK x PipeCDのデプロイフロー
・あなたはPull型を選ぶべきか？

CDK界やCI/CDに悩む方に新しい視点をお届けできれば幸いです。

AWS MCP Serversの中には、「AWS CDK MCP Server」や「Cost Analysis MCP Server」、「AWS Serverless MCP Server」、「AWS Documentation MCP Server」とCDK開発をサポートするMCPがたくさんあります。

しかしながら、「なんとなくMCPを使っているものの、それぞれのMCPがどのような処理をしているのかは、よく知らない」という方も多いのではないでしょうか。
そこで本セッションでは、それぞれのMCPの挙動をソースコードから確認しながら、各MCPがどのような機能を提供してくれているのか紹介したいと思います。

先日開催されたWeb3のグローバルハッカソンにて分散型決済・ストレージ機能を提供するMCPサーバーを自作しました。
その自作MCPサーバーをAWS Lambda上で動かす方法とGitHub Copilot Agent Modeから呼び出す方法を紹介します！！
AWSリソースの管理にはもちろんCDKを使います！！

ソースコードやデモも交えながら実装のポイントを解説していく予定です！

これであなたも自作したMCPサーバーをいつでもリモートMCPサーバーとして公開できます！！

【参考技術ブログ】
Zenn - x402 と Walrus の MCP を作ってみた！AI Agent 時代の分散型決済・ストレージ統合ガイド 🚀
https://zenn.dev/mashharuki/articles/x402_walrus_mcp

リソースをいい感じの単位にまとめて扱いたい！だけどCDKのスタックを分けるのは少し大げさ……そんな時に活躍するのが自作のコンストラクタです。
DB周りのリソースをひとまとめにした自作DBコンストラクタ、アプリ周りのリソースをひとまとめにした自作アプリコンストラクタのように、うまく区切っていくとCDKコードの可読性も向上します。しかしこの際に考えなくてはいけないのは、コンストラクタ間での値の受け渡しです。セキュリティグループのIDやIAM権限を与えるための対象リソースのARNなど、細かすぎる値をやり取りするようになってしまうのは、せっかくいい感じのグループ化・抽象化を自作コンストラクタで行ったのが台無しです。
このセッションでは、コンストラクタ間での値の参照パターンと、それらをナイスにリファクタできるCDK組み込みの便利インターフェースを紹介します。

「とあるIaCツールで構築したAWSリソースをCDKで管理したいけど、どうやってやればいいの…？」「CloudFormationや手動で構築したリソースをCDKに移行したいけど、なんか難しそうで踏み出せない…」そんな悩みはありませんか？

本セッションでは、とあるIaCツールで構築していたリソースを「cdk migrate」を使用してCDKに移行した私の経験を通して、
cdk migrateの気をつけるべき点や、CDK移行時の開発フローの考え方や工夫など、「無理なく着実に、移行するTips」をお伝えします。

あなたのCDK移行を「無理しない、頑張りすぎずにやりきる」ためのヒントをお伝えできれば幸いです。

後輩「先輩、このcdk initで出来るtsconfig.jsonとかってなんですか？」
先輩「ああ、あれね。うーん…なんかCDKを良い感じに動かすのにいるやつだよ！」

こんな返答していませんか？私はするかもしれません。
毎度疑問になるたび調べるけど、毎回忘れていく。あるいは見逃している。そんな知識をここで改めて一緒に身につけませんか？

本セッションでは、CDKの初期セットアップコマンドであるcdk initを実行した時にできる以下のファイルや、synth時に生成されるファイルと設定されるパラメータを深堀りしていきます。これでいつ聞かれても大丈夫になりましょう！

• tsconfig.json
• .npmignore
• package.json
• jest.config.js
• cdk.json ..and more

AWS CDK Toolkit LibraryがGAになり、CLIを使わずともNode.jsなどから直接クラウドアセンブリ作成やデプロイといったAWS CDKの機能が使えるようになり、インテグレーションテストの導入も容易になりました。

しかしAWS CDK Toolkit Libraryでも今まで同様、テストの機能は含まれていないため外部ライブラリを使うしかなく、特に単体テストは相変わらずCLIを使うしかありません。

ただ、どうせなら単体テストもAWS CDK Toolkit Libraryソースで完結させたいと思いませんか？

そこでこのトークでは、AWS CDK Toolkit Libraryのテストに対する考え方の紹介や単体テストもAWS CDK Toolkit Libraryで完結させる方法、およびその際のメリットデメリット・ユースケースなどを紹介したいと思います。

２０２５年には日本語対応やAmazon Q Developer for GitHubのプレビュー版の発表など、何かと話題になるAmazonQですが、AWS CDKを利用した開発を進めるうえではどのような活用方法があるのでしょうか？
コーディング支援やエラー対応支援、レビュー、テストの支援など各シーンでのAmazonQの活用方法を探ります。