Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.
Avatar for Makky12 Makky12
April 15, 2026

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

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

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

#jawsug_cdk

Avatar for Makky12

Makky12

April 15, 2026

More Decks by Makky12

Other Decks in Technology

Transcript

  1. 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/
  2. 3 KDDI Agile Development Center Corporation アジェンダ • はじめに:最近よく耳にする言葉 •

    生成AIでCDKコーディングを行う際の課題 • 課題に対する「CDKとの向き合い方」 • まとめ&参考資料 ※ ゴールとして「生成AIを使用しながらCDKを理解し、コードに責任を持てるようになる向き合 い方を理解する」事を標榜しています ※ この資料は、下記URLで公開済みです ◦ この資料です
  3. 6 KDDI Agile Development Center Corporation CDKも、生成AIに書いてもらう時代に • 生成AIの普及により、CDKも生成AIで書くように ◦

    特にインフラ周り(IaC)はその傾向が強いかも(Terraform含め) • 結果、自分でコードを書く機会が減り「読めるけど書けない」という人が増えた ◦ 「コードはなんとなく分かるが、自分で書いたりコードレビューはできない」という理解度 • ただ個人的には「書かなきゃ覚わらなくないか?」と思っていた ◦ 個人的にCDK(というよりインフラコード)を書くのが好き、というのもあると思うけど
  4. 7 KDDI Agile Development Center Corporation 業務でAIエージェントを構築 ※ みのるんさんに壁打ちしてもらいました •

    そんな折、私も業務でAIエージェントを構築することに ◦ Atlassian Cloud運用サポートチームの業務を支援するAIエージェントの作成
  5. 8 KDDI Agile Development Center Corporation 実際に生成AIによるCDKコーディングを実施 ※ 実際にCDKを生成AI(Claude Code)でコーディング

    • 下図がAIエージェントのインフラ環境(※) ◦ 下図のインフラ環境をClaude Codeを使ってCDKでコーディング ※ Amplify Gen2を使っていますが、諸事情で「backend.ts」は未使用(自分で個別定義したスタックを利用)
  6. 9 KDDI Agile Development Center Corporation 生成AIでCDKコーディングした感想 ※ 便利だけど、課題も色々ある…というのが率直な感想 •

    確かに「自分でコードを書かなくなる」理由は納得 ◦ CDKに詳しくなくでも、生成AIが「それなりに動きそう」なCDKコードを瞬時に作成してくれる ◦ 同様に、テスト環境&テストコードも瞬時に作成してくれる(個人的に、この恩恵が大きいと感じた) ◦ 結果、CDKコーディングの工数が大幅に短縮(=スピードアップ) • ただその一方で、問題もいろいろ見えてきた ◦ 詳細は次のセクションで説明
  7. 11 KDDI Agile Development Center Corporation 問題その1:100%正しいCDKコードを生成するわけではない ※ 性能はだいぶ良くなったが、まだまだハルシネーションは発生する •

    まだ完全なCDKコードを生成するとは限らない(ハルシネーションはある) ◦ 実際、先述のAIエージェント構築時も「GHEを使用しているのに、Amplifyでブランチデプロイ方式前提のコー ドを書く」などの現象があった(AmplifyのブランチデプロイはGHE未対応) ◦ むしろ問題は、AIセキュリティリスクにもある「人間はAIが出力した内容を正しいと誤解しがち」であること • 特に、あまりCDKに詳しくない状態であればあるほど • 「30点くらいのアウトプットには素早くたどり着ける」(「AI駆動開発入門」より) ◦ 逆に言うと「最初に出力するコードは30点くらい」という事も十分ありえる、という事 • インフラ系はアプリ系と比べ「後でサクッと直してデプロイ」が困難なケースもある ◦ リソースによっては、再デプロイにサービス停止を要するケースもある(一部削除→再生成を行うリソース) ◦ アプリコードと違い「該当部分のみサクッと修正して再デプロイ」とはいかない場合も
  8. 12 KDDI Agile Development Center Corporation 問題その2:「理解」フェーズが飛ばされる ※ AIがコードを生成することで、今まであった「理解する」というフェーズがなくなる傾向がある •

    「理解」というフェーズが飛ばされ、CDKに対する理解度が不十分なままになる ◦ 「指示」→「出力」→「デプロイ」という流れで「理解」フェーズがない状態が続くと「よく分からないけど動 いているからヨシ!」という状況が発生しかねない(いわゆる「居眠り運転」状態) ◦ 結果、もしAIが出力したCDKコードに問題があっても、それに気づけない ◦ それが積み重なることで、どんどんCDKのコード品質が低下する(最悪「時すでに遅し」という事も…) • 人間がコードレビューができない ◦ 上記を防ぐためにも人間のレビューは必要だが、そもそもレビューできるだけの理解度がない状態に陥る ◦ 「最初に出力するコードは30点くらい」という事自体を判断できない • プロダクトに対する責務の問題 ◦ プロダクト(コード)に責任を負うのは「人間」だが、理解度が十分でないとそれを全うできない
  9. 14 KDDI Agile Development Center Corporation 「理解」フェーズの重要性を認識する ※ コード生成時の「理解」の度合いが下がる分「理解」フェーズの重要性を意図的に上げる必要がある •

    「レビュー」における「理解」の重要性を認識し、意図的に時間を割く ◦ レビュー工程を単なる「レビュー」ではなく、自分自身の「CDKを理解するフェーズ」でもあると認識し、意図 的に時間を割く(不明点を調べたり、AIに確認するなどして理解を深める) ◦ 先に一度、AIにコードレビューさせることは問題ない(むしろ推奨) • 目的は「理解」であり「問題を見つける」ことではない(=CDKコードの品質が高いに越したことはない) • AI開発の概念・フレームワークにおける「レビュー」工程でCDKの理解を深める ◦ 「Mob Construction」(AI-DLC) ◦ 各成果物の「レビュー」工程(仕様駆動開発:Spec Driven Development) • 生成AIを使うと軽視されがちだが、この「理解」が重要であるという認識を持つ ◦ この「理解」の工程こそがCDKコードの品質担保に重要
  10. 15 KDDI Agile Development Center Corporation 重要なのは(チーム・組織などへの)成果を出すこと ※ つい「時短」にとらわれがちだが、それは本来の目的ではない…という事を理解する •

    「コード生成における時短」が本来の目的ではない ◦ 生成AIを使うと「コード生成の時短」ばかり注目されがちだが、それは生成AIを使う本来の目的ではない ◦ 目的は「チーム・組織が負うべき責務(運用保守・品質保証なども含め)全体への成果を(より効率的に)出す こと」である • そのために「理解」にも十分な時間を割くことが必要(「コード生成」にとらわれない) ◦ 「コード生成」はあくまで「工程の一つ」である ◦ 例え「理解」フェーズに時間を割いても、長い目で見ればそれが一番効率的で時短になる(ここを誤解しがち) ◦ 「理解」を省くと、後々運用・品質などの点で大きな影響が発生しかねない • ただしケースバイケースであり、臨機応変に対応する ◦ PoCなど短期的&スポット的なものは「とりあえず早く作る」ことも重要(Vibe Coding等)
  11. 17 KDDI Agile Development Center Corporation まとめ ※ 本セッションのまとめ •

    生成AIによるコーディングは便利だが「理解」フェーズが省略されがち ◦ 「コーディングの早さ」ばかりに目が行き「理解」フェーズが軽視されがち ◦ 「理解」を省略すると、のちのち運用・品質などにおいて問題が発生するケースがある • 「理解」に意図的に時間を割く ◦ 「まだ生成AIの出力は100%ではない」ことを認識し、自分でも「理解」を深めておく必要がある ◦ あくまでもプロダクト(コード)に対する責任を負うのは「人間」である • 目的は「チーム・組織への成果を効率的に出すこと」であることを理解する ◦ 重要なのは「チーム・組織が負うべき責務全体への成果を出すこと」であり、「コード生成」は果たすべき責務 の工程の一つに過ぎない ◦ 「理解」に時間を割くことは一見時間がかかるように見えるが、長い目で見ればそれが一番効率的で時短になる
  12. 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もあるが、これらは現 在非推奨となっているので注意
  13. 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