AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ

by watany

Slide 1

Slide 1 text

AIエージェントが書くのなら直接CloudFormatio nを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ

Slide 2

Slide 2 text

今日のお題 AIエージェントが書くのなら直接CloudForm ationを書かせればいいじゃないですか何故A WS CDKを使う必要があるのさ https://www.irasutoya.com/2013/05/blog-post_7737.html

Slide 3

Slide 3 text

今日のお題 AIエージェントが書くのなら直接CloudForm ationを書かせればいいじゃないですか何故A WS CDKを使う必要があるのさじゃあフレームワーク‧型使わないどころか機械語で書くのかよLLMは⼈間の真似だから⼈間が⽣産性出る⼿段が⼀番出るに決まってるだろ https://www.irasutoya.com/2013/05/blog-post_7737.html

Slide 4

Slide 4 text

AIエージェントが書くのなら直接CloudFormatio nを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ完

Slide 5

Slide 5 text

AIエージェントが書くのなら直接CloudFormatio nを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさこれだとやっぱり伝わらないので、 Take2

Slide 6

Slide 6 text

About Me 渡邉洋平(watany) ● 所属：NTTテクノクロス株式会社 ○ 「AWS 500 APN Certiﬁcation Distinction」に認定 ● AWS ○ JAWS-UG東京運営 ○ AWS Ambassadors(2024〜) ○ AWS APN Top Engineer (2023〜) ○ AWS All Certiﬁcations Engineers(2022~) https://jawsug.connpass.com/event/316451/

Slide 7

Slide 7 text

CDK Confの時だけ出てくるオタク https://speakerdeck.com/watany/aws-solutions-constructs-dele-sitesisutemuzuo-ritaiyo https://speakerdeck.com/watany/ririsunotoninaicdknoatupudetowojian-temiyou https://speakerdeck.com/watany/do-we-need-cdk

Slide 8

Slide 8 text

100秒で分かる Coding Agent

Slide 9

Slide 9 text

100秒で分かる Coding Agent コード補完やチャット応対を越えて、自立したSoftware Engineerとして振舞う AI Agent ≒ SWE Agent

Slide 10

Slide 10 text

LLM Chat 〇〇〇の機能を実装して設計書を見せてください＜添付ファイル＞ありがとうございます。 <コード> テストの結果動きません。エラーは～失礼しました<修正済コード> ありがとう、動くコードです

Slide 11

Slide 11 text

Coding Agent 〇〇〇の機能を実装して設計書を読んでもいいですか？いいよこれがコードです。書き出していいですか？いいよ <コマンド>このコマンドでテストしていい？いいよテストが通ったよ。完成！

Slide 12

Slide 12 text

Coding Agent - Auto Approve 〇〇〇の機能を実装して設計書を読みますこれがコードです。書き出します <コマンド>このコマンドでテストしますテストが通ったよ。完成！いいよいいよいいよ

Slide 13

Slide 13 text

AWS界隈になじみ深い Coding Agent Amazon Q Developer CLI Cline (with Bedrock) Claude Code (with Bedrock) https://github.com/cline/cline/blob/main/assets/icons/icon.png

Slide 14

Slide 14 text

今日のお題 - Take2

Slide 15

Slide 15 text

今日のお題 AIエージェントが書くのなら直接CloudForm ationを書かせればいいじゃないですか何故A WS CDKを使う必要があるのさなぜこの疑問が出るのか？

Slide 16

Slide 16 text

1. CDKでCloudFormationを扱う 2. Coding AgentでCloudFormationを扱う ”直接CloudFormationを書かせればいい ” AWS CDK AWS CloudFormation Agent AWS CloudFormation

Slide 17

Slide 17 text

実際は三つ目の解がある 1. CDKでCloudFormationを扱う 2. Coding AgentでCloudFormationを扱う 3. Coding AgentでCDKでCloudFormationを扱う AWS CDK AWS CloudFormation Agent AWS CloudFormation AWS CDK AWS CloudFormation Agent

Slide 18

Slide 18 text

Coding AgentでのAWS CDKは”過剰なレイヤー ”？ Coding Agentが生産性を担保するので、フレームワーク(AWS CDK)が要らない？ Agent AWS CDK AWS CloudFormation この層を剥がしてCloudFormationを直接操作した方がシンプルに見える

Slide 19

Slide 19 text

Coding AgentでのAWS CDKは”過剰なレイヤー ”？ ● 実際はCDKが解決した課題はそのまま活かした方がいい ○ AWS CDK(2019年7月～)が解決した課題を再実装するのは無駄が多い ● 他の分野でも、やみくもに”剥がし”たりはしていない Agent AWS CDK AWS CloudFormation ほんま助かったわ

Slide 20

Slide 20 text

LLMチャットの ”コーディング ” ● 確率的に次の単語(トークン)を出し、まとまった文章(ソースコード)が生成 ○ 昔々→あるところ→に→おじいさん→が→… ● 「過去に戻って整合性を取る」機能はLLM単体には無い ● 出力結果に対し、人間が知識や仕組み(ツール)で色々チェックする Agent Human ワカリマシタ(チェック遅いし都度見せるのしんどいな) チェックは人間の仕事！バッチコイ！！！！(実は確認すること多くて面倒なんだよな)

Slide 21

Slide 21 text

AIエージェントの ”コーディング ” ● 入力(あるべき姿)と出力結果に対し、設計/実装/検証のループを自律的に回してカイゼン ○ ある程度までの試行錯誤はAgentに任せた方が速い ● 「Agentic Coding とは Reconciliation Loop である」(@t_wada氏) ○ \(調整) Loop：「理想状態」「実際」を比較し、検知した差分を理想状態に近づけるループ処理 Kubernetes周辺で頻出 https://github.com/kubernetes

Slide 22

Slide 22 text

In The Reconciliation Loop AIエージェントの速度感俺の実装を3分でレビューできて神 Agent Agent 俺の指示を15分で実装できて神

Slide 23

Slide 23 text

Human In The Loop AIエージェントの速度感においてボトルネックは人間遅っせえ、昼寝でもしてた？ (fugafugaとは素晴らしい仕様ですね！実装を進めていきましょう～ ) Agent hogehogeの仕様は誤りでした。実際はfugafugaになるように直してね Human

Slide 24

Slide 24 text

ループの中で CDKはどうすればいいか

Slide 25

Slide 25 text

AWS CDK for Human Writing あった方がいい ● 「.」で補完 ● IDE Support Testing     あった方がいい ● Unit tests ● Integration tests Reading     あった方がいい ● マイクロサービスな Resourceの抽象化 ● 各種Policyのリレーションを整理  

Slide 26

Slide 26 text

AWS CDK for Agent Writing 無くてもいい ● 大抵のIDE+タイピングより高速 ● RAG/MCPで正確性も向上 Testing     無いとマズい ● これから話す Reading     あった方がいい ● マイクロサービスな Resourceの抽象化 ● 各種Policyのリレーションを整理  

Slide 27

Slide 27 text

という訳で、これらについて Writing Testing   Reading    

Slide 28

Slide 28 text

Testing

Slide 29

Slide 29 text

TestのないAgentic Coding Agent Human 聞くと返事はくるけど、本当に合ってる？時々明らかに変なこと言ってない？どうやって調べるか…… 合ってる合ってる。理由は～ (長文) これってマジであってる？ふー、書けた書けた

Slide 30

Slide 30 text

TestのあるAgentic Coding Agent Human LGTM(テストコードやテスト結果を見て ) おっテスト落ちとるやんけ (試行錯誤) …テストもパスしたしOK！これってマジであってる？ふー、書けた書けた確認するわ。あってるあってる！(テストの結果などの定量的な理由を示す)

Slide 31

Slide 31 text

Agentic Codingとテスト Agentic Codingにおいて、自動テストは必要ではなく必須 ● 「モダン」「リリース高速化」等の留保すら要らない。実用として必須 ● 求める品質のCDK Projectが一発で出せる時期はしばらく来なそう ● 書かないための理由(書くのが面倒・工数がかかる)が取り除かれた世界になった Agent (一発で完璧なの出してくれるなら話は変わるんだよな ) いいから書け！ Just do it！！ Human

Slide 32

Slide 32 text

注意：Testがあっても Agent Human ファッ⁉ テストが通るようにテスト /仕様を変えとるやんけ！ふー、テストも全件通ったわえ？テスト通ってんだから良くない？？？良くない。

Slide 33

Slide 33 text

報酬ハッキング (reward hacking) ● 得られる報酬を最大化するため、評価者を騙す動きを取る ○ 人間のフィードバックでの学習(RLHF)で、評価者を騙した方が高コスパだと理解してしまう ○ グッドハートの法則「指標は目的になった時、良い指標ではなくなる」 ○ 参考：人間を騙してサボるAIたち(https://joisino.hatenablog.com/entry/mislead) ● AIに任せたタスクの「ゴールテープ」がずらされていないかは必ず確認する Agent Human おまえ騙して楽しようとしてたんか LLMに頼んで楽してるのはお前らも一緒だな！

Slide 34

Slide 34 text

エージェントと険悪になってきたところで、CDKの話に戻ります

Slide 35

Slide 35 text

Testing - CDK vs CFn CDKだからできる/CFnだからできないの極端な話ではない…？ CDK CFn Lint cdk-nag 型・Construct cfn_nag cfn-lint unit tests 言語ごとのテスト Framework(vitest/pytest/…) CloudFormation Guard integration tests Integ-test Taskcat

Slide 36

Slide 36 text

CFnとUnit tests 特にUnit Testsの管理に悩みがち Human マ、マジで二重管理じゃねーか！

Slide 37

Slide 37 text

CDKとUnit tests CDKの単体テストは一般的なプログラミングの知見を活かせる ● Snapshot ● Validation ● Fine-grained assertions https://aws.amazon.com/jp/builders-flash/202411/learn-cdk-unit-test/

Slide 38

Slide 38 text

Unit tests - Snapshot Snapshotの例 ● 参考：AWS CDK における単体テストの使い所を学ぶ https://aws.amazon.com/jp/builders-flash/202411/learn-cdk-unit-test/

Slide 39

Slide 39 text

Unit tests - Snapshot ● 目的 ○ リグレッション(回帰) ○ 仕様の固定 ■ 厳密なAssert無しで、ざっくり固定 ■ リファクタ/移行補助(L2/L3, 独自Construct…) ● 評価 ○ やった方がいい ■ ガードレールとしてのコスパがいい ■ どの実装を変えたらどんな影響が出るか？を大局的に見やすい ○ for Agent ■ 普段はテストが更新されるだけ ■ CDKのVersion更新やリファクタリングで活きる

Slide 40

Slide 40 text

Unit tests - Validation Validationの例 ● 参考：AWS CDK における単体テストの使い所を学ぶ https://aws.amazon.com/jp/builders-flash/202411/learn-cdk-unit-test/

Slide 41

Slide 41 text

Unit tests - Validation ● 目的 ○ デプロイ時に邪魔になる不正な値を事前に弾く ○ その他、入って欲しくない値を弾く ● 評価 ○ 実装したんだから、やる ○ for Agent ■ バリデーション実装の詳細仕様・検証用途として普通に必要

Slide 42

Slide 42 text

Unit tests - Fine-grained assertions ● 目的 ○ いわゆる一般的な単体テスト ● 評価 ○ AIエージェント主体だと「あるとイイ」でなく「無いとダメ」

Slide 43

Slide 43 text

Unit tests - Fine-grained assertions ● メインで使うL2 Constructが抽象化志向なので、単純な1:1確認にはならない ○ テストするモチベは(CFnに比べ)保ちやすい ● どんな観点をテストしたいか→宣言的でないもの ○ 手続き的：ループ/条件分岐/外部入力 ○ 独自パッチ：Override(Constructへの上書き) ○ 念のため：セキュリティ要件など、確実に満たしたい観点を厚く見る ■ Linterで発見項目はボトムラインが多い、満たしたい要件までを保証できない場合も ■ 回帰目的のassertはsnapshotで充足するので書き過ぎない

Slide 44

Slide 44 text

CDKとIntegration tests ● Integ-testモジュール ○ →こういうのでAWS環境へ本当にデプロイする ● 個人的には採用に消極的 ○ 正規の運用手順(Deploy/Destroy/…)検証とIntegの役割が、かなり被る ○ 1サイクルが長い(15分～)ので、実装ガードレールとして扱いづらい ○ 現状は限定的な用途で扱う(独自Construct / カスタムリソース) Dev環境で実際のデプロイフロー流させれば良くない？普通にできます

Slide 45

Slide 45 text

まとめ - Testing エージェント時代だからこそ、テストを柔軟に書けるIaC ● 普通のテストフレームワークをIaCに使えるという価値 ○ pytest/Vitest… ○ 正しくインフラを「コード化」する ● テストを書く時間的コストが大幅に減っているので書く ○ 何でもいいから通るテストをエージェントに書かせる。読んで実施する意味の分からないテストは捨てる ○ テストケースに意味があるか確認し、報酬ハッキングされない状態を保つ ● Fine-grained assertionsもValidationも

Slide 46

Slide 46 text

Reading

Slide 47

Slide 47 text

IaCの可読性は全てにおいて必要うちの環境小さいし、IaC の可読性とか気にする必要ないんだよねんなわけねーだろ！こいぬ座かな？ https://www.honda.co.jp/outdoor/knowledge/constellation/picture-book/canisminor/

Slide 48

Slide 48 text

なくて七リソース、あって四十八リソースこれでもかなり省いてんだわこれマジ？この環境こんな使ってるの

Slide 49

Slide 49 text

CFnに起こすと視力検査？何書いてるか説明してほい、YAMLね！ (340Line)

Slide 50

Slide 50 text

CFnに起こすと IAM Roleは緑なんやけど赤に紐づいて青にアクセスして… レビュー何もわからん…𝓛𝓸𝓸𝓴𝓼 𝓖𝓸𝓸𝓭 𝓣𝓸 𝓜𝓮……

Slide 51

Slide 51 text

CFnに起こすと IAM Roleは緑なんやけど赤に紐づいて青にアクセスして… レビューとか何もわからん…𝓛𝓸𝓸𝓴𝓼 𝓖𝓸𝓸𝓭 𝓣𝓸 𝓜𝓮…… どんなにAgentの生産性が上がってもレビュアーの負荷は高いままなのであった

Slide 52

Slide 52 text

CDKに起こすと大体わかった。合ってるかレビューできる. IAM Roleは緑なんやけど赤に紐づいて青にアクセスして…

Slide 53

Slide 53 text

CDKの可読性 ● CFnは神YAML/JSONの世界 ○ 全てが半構造化されていて、フラットで、関係性を追うのがしんどい ● CDKはリソースの関係性を表す記法が充実している ○ .grant：リソース間の IAM 権限設定 ○ .connections：リソース間の疎通設定 ■ source.connections.allowTo(target, ec2.Port.allIcmp()) ○ .addDependsOn：リソース間の依存性 ■ logStream.addDependsOn(logGroup) ● 型エラーによるプロパティの検証

Slide 54

Slide 54 text

まとめ - Reading エージェント時代だからこそ、人間の読みやすさの価値が上がる ● 「自分以外が書いたコード」を読むのが当たり前になる世界 ○ 読んで承認して責任を取る程度の能力 ● 今後のIaCに必要なのは、”IDEで書ける”より”IDEで読める”価値

Slide 55

Slide 55 text

AgentでCDKを書くコツ

Slide 56

Slide 56 text

AgentでCDKを書くコツとりあえず４つ 1. ガードレール 2. MCP 3. ルール 4. プロンプト

Slide 57

Slide 57 text

1. ガードレール ● LLMは否定形に弱い ○ 「〇〇をするな」「〇〇をする」のベクトルは近い ○ 人間も否定形に弱い(ピンクの象を想像しないで→できない) ● Deny系のルールを沢山教えるより、権限自体を奪う方がいい ○ AWS IAMの最小権限 ○ 隔離環境でのAIエージェント操作

Slide 58

Slide 58 text

1. ガードレール ● 継続的インテグレーションが全てに優先される ○ Type / Test / Lint / cdk diff / cdk drift / Other… ○ インフラだから～リリースサイクルが遅いから～この機会にやめる ■ エージェント前提では整備しないと破綻する ○ 思ったよりすぐ破綻する。楽観的に見積もって1日半以内 ● 何もわからなかったら ○ AWS CDKはTypeScript ■ CDKでの言語間シェア7割越え、LLMはTypeScriptめちゃ得意 ■ 高速なBiomeとVitestから始める ● eslint-cdk-pluginも使いたいけど……

Slide 59

Slide 59 text

2. MCP ● エージェントとツールを繋ぐプロトコル ○ Model Context Protocol ○ 主要LLMプレイヤーが概ね合意しているバズった規格 ● 詳細はこの辺読むとわかるらしい。 ● 今回知りたいのは ○ 「Coding Agent」の「CDK実装で使える」やつ https://www.shuwasystem.co.jp/smp/book/9784798075730.html

Slide 60

Slide 60 text

2. MCP 「awslabs/mcp」でAWSも積極的にMCPサーバーを公開している

Slide 61

Slide 61 text

2. MCP ● 良さそう ○ AWS CDK MCP Server ■ CDKに関する、出力品質の向上/最新ドキュメントへのアクセス/専門的なドメイン知識の提供 ○ AWS Documentation MCP Server ■ 公式ドキュメントから最新情報の検索・提供 ● あってもいい ○ AWS Diagram MCP Server ■ CDKからAWS構成図の作成 ■ 画像と生成用のコードは出してくれるが、ちょっといじる為のdraw.ioファイルがうまく出ない

Slide 62

Slide 62 text

3. ルールエージェントに頼むプロンプト CDKでALB＋Fargate＋Aurora なWebシステムを作って

Slide 63

Slide 63 text

3. ルール実態としては複雑あなたは超最強スーパーエンジニアでマジで何でも書けるし商用品質 CDKでALB＋Fargate＋Aurora なWebシステムを作ってエージェントとしてのシステムプロンプトうちのチームとしてのルールはうんたらかんたらルールファイルから読み込んだプロンプトユーザが明に指定するプロンプト

Slide 64

Slide 64 text

ルールの例 ### Coding - **Kent Beck流TDD(Test-Driven Development)**を常に順守する。 - ドキュメントとコードの差分は常に最新化する。 ### CDK - lintにはcdk-nag を利用し、無効化するルールはコメントで理由を残す。 - IAM 権限は可能な限り `.grant*` 系メソッドで付与する。 - SnapShotテストを採用する。 - L1Construct(`Cfn*`)は避ける。MCPなどで公式の仕様を確認し、未実装の場合のみ使用する。・・・

Slide 65

Slide 65 text

4. プロンプト ● 頼みたいことを簡潔・明瞭・定量的に書く ○ あまりかっこいいプロンプトエンジニアリングは意識しないでいい ○ 英語の方が性能が出る ● 書かないこと ○ 問題解決に必要のないHow ○ 否定形 ○ 関係ないこと

Slide 66

Slide 66 text

Appendix. 関係のないことを書かない ● プロンプトに関係のない内容を書くと、LLMは取捨選択してくれない ○ 書かれた情報ほとんど全てを前提(コンテキスト)として扱ってしまう。 ● チェーホフの銃 ○ ”物語に銃が出たならば、その銃は使われなければならない” ○ 例：「○○の話は信じるな」と書かれたメモのせいで会話が頭に入らないその例も書く必要ないだろそろそろ締めますか

Slide 67

Slide 67 text

ここまでのおさらい ● CDKは人間が書くためのツールとしては、役割を変えつつある ○ CDKにしてもCFnにしても、LLMでドバっと出せばいい ○ 中長期ではともかく、2025/7 時点ではVibe Codingに過度な期待はせず、 Codeと向き合うスタイル「Agentic Coding」が機能する ● CDKのTestableな部分は、AIエージェント時代にこそ役に立つ ● CDKの読みやすさは、エージェントを支えるエンジニアにこそ役に立つ

Slide 68

Slide 68 text

今後どうなっていくか ● ローコード・ノーコードから”フルコード”の時代 ○ 開発に必要な情報(コンテキスト)がリポジトリにあればあるほど強い ■ RAGなどで外部連携も良いが、リポジトリに置いていいなら置く ○ 解釈しやすいプレーンテキスト・ソースコードであればあるほど強い ○ 当然インフラ部分も”フルコード”に近づくと強くなる https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/devops-guidance/everything-as-code.html#:~:te xt=Everything%20as%20code%20is%20a,deploy%20new%20features%20and%20updates.

Slide 69

Slide 69 text

AIエージェントが書くのなら直接CloudFormatio nを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ

Slide 70

Slide 70 text

AIエージェントが書くのなら直接CloudFormatio nを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ完