AIエージェントを構築して感じた、AI時代のCDKとの向き合い方

2026/04/15（水）に開催された「JAWS-UG CDK支部 #25 〜AI時代のCDK、みんなどう書いてる？〜」における私の発表「AIエージェントを構築して感じた、AI時代のCDKとの向き合い方 」の発表資料になります。

https://jawsug-cdk.connpass.com/event/386514/

#jawsug_cdk

Transcript

1. AIエージェントを構築して感じた、AI 時代のCDKとの向き合い方 2026.04.15 JAWS-UG CDK支部 #25 〜AI時代のCDK、みんなどう書 いてる？〜 KDDIアジャイル開発センター 名古屋オフィス 鈴木 正樹
2. 1 KDDI Agile Development Center Corporation 自己紹介 ◼ 氏名：鈴木 正樹 ◼ 所属：KDDIアジャイル開発センター（KAG） 名古屋オフィス ◼ 役割：クラウドアーキテクト ＆ バックエンドエンジニア サーバーレス＆IaCが大好き。好きなサービスはAWS LambdaとAWS CDK 主にJAWS-UG CDK支部 & JAWS-UG 名古屋で活動 ◼ Certification： ◼ AWS Solution Architect Associate（2023） ◼ AWS Community Builder(serverless)（2023～） ◼ Scrum Inc. 認定スクラムマスター（2025～） ◼ : @makky12（SUZUKI Masaki@クラウドエンジニア） ◼ Blog：https://makky12.hatenablog.com/
3. 採用募集中！ エンジニア・デザイナー
4. 3 KDDI Agile Development Center Corporation アジェンダ • はじめに：最近よく耳にする言葉 • 生成AIでCDKコーディングを行う際の課題 • 課題に対する「CDKとの向き合い方」 • まとめ＆参考資料 ※ ゴールとして「生成AIを使用しながらCDKを理解し、コードに責任を持てるようになる向き合 い方を理解する」事を標榜しています ※ この資料は、下記URLで公開済みです ◦ この資料です
5. 4 KDDI Agile Development Center Corporation はじめに：最近よく耳にする言葉
6. 5 KDDI Agile Development Center Corporation 最近よく耳にする言葉 ※ あくまで一例です CDK、読めるけど書けない
7. 6 KDDI Agile Development Center Corporation CDKも、生成AIに書いてもらう時代に • 生成AIの普及により、CDKも生成AIで書くように ◦ 特にインフラ周り（IaC）はその傾向が強いかも（Terraform含め） • 結果、自分でコードを書く機会が減り「読めるけど書けない」という人が増えた ◦ 「コードはなんとなく分かるが、自分で書いたりコードレビューはできない」という理解度 • ただ個人的には「書かなきゃ覚わらなくないか？」と思っていた ◦ 個人的にCDK（というよりインフラコード）を書くのが好き、というのもあると思うけど
8. 7 KDDI Agile Development Center Corporation 業務でAIエージェントを構築 ※ みのるんさんに壁打ちしてもらいました • そんな折、私も業務でAIエージェントを構築することに ◦ Atlassian Cloud運用サポートチームの業務を支援するAIエージェントの作成
9. 8 KDDI Agile Development Center Corporation 実際に生成AIによるCDKコーディングを実施 ※ 実際にCDKを生成AI（Claude Code）でコーディング • 下図がAIエージェントのインフラ環境（※） ◦ 下図のインフラ環境をClaude Codeを使ってCDKでコーディング ※ Amplify Gen2を使っていますが、諸事情で「backend.ts」は未使用（自分で個別定義したスタックを利用）
10. 9 KDDI Agile Development Center Corporation 生成AIでCDKコーディングした感想 ※ 便利だけど、課題も色々ある…というのが率直な感想 • 確かに「自分でコードを書かなくなる」理由は納得 ◦ CDKに詳しくなくでも、生成AIが「それなりに動きそう」なCDKコードを瞬時に作成してくれる ◦ 同様に、テスト環境＆テストコードも瞬時に作成してくれる（個人的に、この恩恵が大きいと感じた） ◦ 結果、CDKコーディングの工数が大幅に短縮（=スピードアップ） • ただその一方で、問題もいろいろ見えてきた ◦ 詳細は次のセクションで説明
11. 10 KDDI Agile Development Center Corporation 生成AIでCDKコーディングを行う際の問題
12. 11 KDDI Agile Development Center Corporation 問題その1：100%正しいCDKコードを生成するわけではない ※ 性能はだいぶ良くなったが、まだまだハルシネーションは発生する • まだ完全なCDKコードを生成するとは限らない（ハルシネーションはある） ◦ 実際、先述のAIエージェント構築時も「GHEを使用しているのに、Amplifyでブランチデプロイ方式前提のコー ドを書く」などの現象があった（AmplifyのブランチデプロイはGHE未対応） ◦ むしろ問題は、AIセキュリティリスクにもある「人間はAIが出力した内容を正しいと誤解しがち」であること • 特に、あまりCDKに詳しくない状態であればあるほど • 「30点くらいのアウトプットには素早くたどり着ける」（「AI駆動開発入門」より） ◦ 逆に言うと「最初に出力するコードは30点くらい」という事も十分ありえる、という事 • インフラ系はアプリ系と比べ「後でサクッと直してデプロイ」が困難なケースもある ◦ リソースによっては、再デプロイにサービス停止を要するケースもある（一部削除→再生成を行うリソース） ◦ アプリコードと違い「該当部分のみサクッと修正して再デプロイ」とはいかない場合も
13. 12 KDDI Agile Development Center Corporation 問題その2：「理解」フェーズが飛ばされる ※ AIがコードを生成することで、今まであった「理解する」というフェーズがなくなる傾向がある • 「理解」というフェーズが飛ばされ、CDKに対する理解度が不十分なままになる ◦ 「指示」→「出力」→「デプロイ」という流れで「理解」フェーズがない状態が続くと「よく分からないけど動 いているからヨシ！」という状況が発生しかねない（いわゆる「居眠り運転」状態） ◦ 結果、もしAIが出力したCDKコードに問題があっても、それに気づけない ◦ それが積み重なることで、どんどんCDKのコード品質が低下する（最悪「時すでに遅し」という事も…） • 人間がコードレビューができない ◦ 上記を防ぐためにも人間のレビューは必要だが、そもそもレビューできるだけの理解度がない状態に陥る ◦ 「最初に出力するコードは30点くらい」という事自体を判断できない • プロダクトに対する責務の問題 ◦ プロダクト（コード）に責任を負うのは「人間」だが、理解度が十分でないとそれを全うできない
14. 13 KDDI Agile Development Center Corporation 問題に対する「CDKとの向き合い方」
15. 14 KDDI Agile Development Center Corporation 「理解」フェーズの重要性を認識する ※ コード生成時の「理解」の度合いが下がる分「理解」フェーズの重要性を意図的に上げる必要がある • 「レビュー」における「理解」の重要性を認識し、意図的に時間を割く ◦ レビュー工程を単なる「レビュー」ではなく、自分自身の「CDKを理解するフェーズ」でもあると認識し、意図 的に時間を割く（不明点を調べたり、AIに確認するなどして理解を深める） ◦ 先に一度、AIにコードレビューさせることは問題ない（むしろ推奨） • 目的は「理解」であり「問題を見つける」ことではない（=CDKコードの品質が高いに越したことはない） • AI開発の概念・フレームワークにおける「レビュー」工程でCDKの理解を深める ◦ 「Mob Construction」（AI-DLC） ◦ 各成果物の「レビュー」工程（仕様駆動開発：Spec Driven Development） • 生成AIを使うと軽視されがちだが、この「理解」が重要であるという認識を持つ ◦ この「理解」の工程こそがCDKコードの品質担保に重要
16. 15 KDDI Agile Development Center Corporation 重要なのは（チーム・組織などへの）成果を出すこと ※ つい「時短」にとらわれがちだが、それは本来の目的ではない…という事を理解する • 「コード生成における時短」が本来の目的ではない ◦ 生成AIを使うと「コード生成の時短」ばかり注目されがちだが、それは生成AIを使う本来の目的ではない ◦ 目的は「チーム・組織が負うべき責務（運用保守・品質保証なども含め）全体への成果を（より効率的に）出す こと」である • そのために「理解」にも十分な時間を割くことが必要（「コード生成」にとらわれない） ◦ 「コード生成」はあくまで「工程の一つ」である ◦ 例え「理解」フェーズに時間を割いても、長い目で見ればそれが一番効率的で時短になる（ここを誤解しがち） ◦ 「理解」を省くと、後々運用・品質などの点で大きな影響が発生しかねない • ただしケースバイケースであり、臨機応変に対応する ◦ PoCなど短期的&スポット的なものは「とりあえず早く作る」ことも重要（Vibe Coding等）
17. 16 KDDI Agile Development Center Corporation まとめ
18. 17 KDDI Agile Development Center Corporation まとめ ※ 本セッションのまとめ • 生成AIによるコーディングは便利だが「理解」フェーズが省略されがち ◦ 「コーディングの早さ」ばかりに目が行き「理解」フェーズが軽視されがち ◦ 「理解」を省略すると、のちのち運用・品質などにおいて問題が発生するケースがある • 「理解」に意図的に時間を割く ◦ 「まだ生成AIの出力は100%ではない」ことを認識し、自分でも「理解」を深めておく必要がある ◦ あくまでもプロダクト（コード）に対する責任を負うのは「人間」である • 目的は「チーム・組織への成果を効率的に出すこと」であることを理解する ◦ 重要なのは「チーム・組織が負うべき責務全体への成果を出すこと」であり、「コード生成」は果たすべき責務 の工程の一つに過ぎない ◦ 「理解」に時間を割くことは一見時間がかかるように見えるが、長い目で見ればそれが一番効率的で時短になる
19. 18 KDDI Agile Development Center Corporation 参考資料
20. 19 KDDI Agile Development Center Corporation CDKのAIコーディングに役立つMCP Server ※ 生成AIにCDKコードを書いてもらう際に有用なMCP Server（いずれもAWS公式） • AWS Documentation MCP Server ◦ AWSドキュメントへのアクセス・コンテンツ検索・推奨事項の取得のためのツールを提供 ◦ 参考：https://awslabs.github.io/mcp/servers/aws-documentation-mcp-server • AWS IaC MCP Server ◦ CDKやCloudFormationなど、AWSでのIaCに関する各種情報取得のためのツールを提供 ◦ 参考： https://awslabs.github.io/mcp/servers/aws-iac-mcp-server ◦ 「AWS CDK MCP Server」「AWS CloudFormation MCP Server」というMCP Serverもあるが、これらは現 在非推奨となっているので注意
21. 20 KDDI Agile Development Center Corporation 「CDKを書けるようにする」ための第一歩 ※「読めるけど書けない」を脱却したい！という方へのファーストステップ • 3/18（水）開催の JAWS-UG名古屋 にて「AWS CDK『読めるけど書けない』を脱却する ファーストステップ」というLTをさせていただきました • お時間があれば、一度こちらをご参照頂ければお役に立てるかもしれません。 URL：https://speakerdeck.com/smt7174/aws-cdk-du-merukedoshu-kenai-wotuo-que-suruhuasutosutetupu
22. Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る