プロポーザル

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

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

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

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

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

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

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

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

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

先日開催された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

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

データベースの運用は、バージョンアップデートなどさまざまなことを考慮する必要があり、多くの開発チームにとって頭の痛い課題です。
また障害やDisaster Recovery 時の復旧など、緊急事態にも対応が必要となるため、事前に備えておくことが重要です。

本セッションでは、AWS CDK を使用して Amazon RDS を運用していくための tips をご紹介します。

AWS Step Functions はサーバーレスにワークフローを組めるサービスで、2024年の re:Invent 直前に JSONata と変数のサポートで大きく使い勝手が進化して以前よりも遥かに簡単に構築できるようになりました。

そんな JSONata と変数機能が AWS CDK の L2 でサポートされた 2025 年 3 月頃に、VSCode の拡張機能である AWS Toolkit でも Step Functions のサポートが強化されました。これによりマネジメントコンソールで構築するかのように VSCode 内で Step Functions を編集できるようになりました。

さて、これらはぶっちゃけどちらを使うべきなのか？また、具体的にどう使い分けるべきなのか？といった観点を JSONata サポートを実装した本人が包み隠さずお話します。

AWS CDK は TypeScript などのプログラミング言語で AWS リソースを構築できる革新的なツールであるものの、CDK を使用した開発を行う際には AWS に関する知識のみではなく、TypeScript や CDK のセオリー・ベストプラクティスやアンチパターンの理解が求められる場面があります。

しかし、CDK エコシステムにおいては、セオリー違反のコードに対する自動検知システムが十分に整備されていません。
そのため、こうした問題に対し多くの開発現場では、経験豊富なエンジニアによるコードレビューなどに依存してコードの品質や安全性を担保しているのが現状ではないでしょうか。

本セッションでは、そのような問題と向き合う方法のひとつとして、TypeScript の型システムや静的解析ツールを使用して、CDK のセオリー・ベストプラクティスを自動適用する方法について紹介します。

みなさんはIdentity Centerの設定をどのように管理されていますか？
私はあるプロジェクトで、当初はマネジメントコンソールやCLIを使って運用していましたが、利用範囲が広がるにつれ、「今どういう設定になっているのか？」がだんだん見えづらくなっていきました。
このままでは運用がつらくなると感じ、CDKによるコード管理にチャレンジしてみました。
今回は、CDKへの移行やその後の運用を通じて得られた気づきや工夫について、ぜひ共有させていただきたいと思います。

CDKプロジェクトを運用していると、こんな経験ありませんか？
・「いつの間にかCDKバージョンが古くなっている」
・「CDKが自動作成するLambdaのランタイムが古いまま」
この発表では、これらの依存関係管理を自動化するアプローチを紹介します。

【Renovate活用術】
依存関係の自動更新設定から、安全な自動マージまでの実践的な運用方法を解説します。

【Vitest導入】
頻繁なテスト実行で気になるJestの実行速度を、Vitestへの移行で改善する手法も紹介します。

これらの組み合わせにより「手離れの良いCDKプロジェクト」の構築が可能になります。
実際の設定例を交えながら、明日から始められる持続可能なCDK運用のノウハウをお伝えします。