AWS CDK「読めるけど書けない」を脱却するファーストステップ

2026/3/18（水）開催の「JAWS-UG名古屋03月会 全員LT登壇会 ちょいAudience, いっぱいBuilders.」における私の発表「AWS CDK「読めるけど書けない」を脱却するファーストステップ」の発表資料です。

https://jawsug-nagoya.connpass.com/event/385547/
#jawsug #jawsug_nagoya

Transcript

1. AWS CDK「読めるけど書けない」を脱 却するファーストステップ 2026.03.18 JAWS-UG名古屋03月会 全員LT登壇会 ちょいAudience, いっぱいBuilders. KDDIアジャイル開発センター 名古屋オフィス 鈴木 正樹
2. 1 KDDI Agile Development Center Corporation 自己紹介 ◼ 氏名：鈴木 正樹 ◼ 所属：KDDIアジャイル開発センター（KAG） 名古屋オフィス ◼ 役割：クラウドアーキテクト ＆ バックエンドエンジニア サーバーレス＆IaCが大好き。好きなサービスはAWS LambdaとAWS CDK 主にJAWS-UG 名古屋＆JAWS-UG CDK支部で活動 ◼ 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 アジェンダ • はじめに：なぜ読めるのに書けないのか • ステップ1：CDKの「基本」を知る • ステップ2：手を動かす • まとめ
5. 4 KDDI Agile Development Center Corporation 本日の資料について • ターゲット： ◦ 「（生成AIの普及で）AWS CDKのコードが読めるけど書けない！」という人 • ゴール： ◦ ちょっとだけでもAWSのコードが書けるようになる ◦ とりあえずサーバーレスの最小構成（API GW-Lambda-S3）がCDKで書けるようになる ※ 時間の関係で、割愛している項目もあります（Assets, L1/L3コンストラクタの詳細など） ※ この資料は、下記URLで公開済みです ◦ この資料です
6. 5 KDDI Agile Development Center Corporation 参考資料 • AWS CDKとは（AWS公式サイト） ◦ https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/home.html • AWS CDK公式リファレンス（めちゃくちゃ見ることになるので、ブクマ推奨） ◦ https://docs.aws.amazon.com/cdk/api/v2/docs/aws-construct-library.html
7. 6 KDDI Agile Development Center Corporation はじめに：なぜ読めるのに書けないのか
8. 7 KDDI Agile Development Center Corporation 「読めるけど書けない」の正体 ※ 結局「書いてない」ことが原因 • 生成AIの普及で「手を動かす機会」（写経・調査など）が減った ◦ 生成AIが（それなりに動く）コードを生成するため、自分で手を動かす機会がゼロに ◦ アプリのコードならともかく、インフラコードとなるとなおさら • CDKの基本を理解する機会がない ◦ 生成AIがいい感じにやってくれるので、CDKの基本を知らなくても何とかなってしまう ◦ App/Stack/Construct/propsなどの理解が不十分のため、いざ自分が書く際に訳が分からない状態に • つまり「書けるようになる」ために必要な最初のステップは、以下2つ ◦ CDKの「基本」を知る ◦ その上で「手を動かす」
9. 8 KDDI Agile Development Center Corporation ステップ1：CDKの「基本」を知る
10. 9 KDDI Agile Development Center Corporation CDKの基本 ※ とりあえず以下4つ（特に「アプリ」以外の3つ）をなんとなく理解すればOK（最初から全部知る必要はない） ※1：1アプリに複数スタックを設定可能。ただしAWS公式では1アプリ1スタック（シングルスタック）を推奨 2 スタック インフラの「入れ物」で、全AWSリソース定義（コンストラクタ）はここに入る。 アプリは1つ以上のStackで構成される（※1）。CloudFormationの「スタック」に該当 3 コンストラクタ S3, Lambdaなど個々のAWSリソース定義の事で、CDKにおける最重要要素。 通常「CDKのコードを書く」≒「コンストラクタを書く」ということ L1～L3の3レイヤーがあるが、最初はL2だけ意識すればOK。 4 props コンストラクタで引数として渡す、各種AWSリソースの設定（インターフェース） 1 アプリ（App） アプリで使う全スタックの入れ物 ※これはそこまで意識する必要はない（初期化時に自動作成される）
11. 10 KDDI Agile Development Center Corporation ステップ2：手を動かす
12. 11 KDDI Agile Development Center Corporation ステップ2：手を動かす ※ コンストラクタを書いて「リソースが作成された！」ことを体験する • CDKの基本を理解したら、次は「CDKコードを書く！」 ◦ …とはいえ最初は「何を書いたらいいか分からない」と思うので、まずは下記のサーバーレスWeb APIの作成を 目標にするとよい • ポイントは「書く構成はシンプルに」という点（いきなり複雑なことをやろうとしない） Amazon API Gateway Amazon Simple Storage Service (Amazon S3) AWS Lambda
13. 12 KDDI Agile Development Center Corporation 最初の1歩：まず1つリソースを作る ※ とりあえず1つコンストラクタを書いて「リソースが作成される」ことを体験する • まず最初に「リソースを1個作る！」を目標にする ◦ 作るリソースは1つだけにする（いきなり何個も作らない） • S3バケットのコンストラクタだけを書いて、デプロイする（以下ソース参照） ◦ S3バケットはprops不要で「new Bucket(this, “MyBucket”);」だけで作成可能 ◦ 「CDKでコンストラクタを書けば、そのリソースがAWS上に作られる」ことを体験する import * as cdk from 'aws-cdk-lib'; import { aws_s3 } from 'aws-cdk-lib’; // スタック定義は初めから書かれている class MyStack extends cdk.Stack { constructor(scope: cdk.App) { super(scope, 'MyStack’); // この1文だけ書けばOK new aws_s3.Bucket(this, 'MyBucket'); } }
14. 13 KDDI Agile Development Center Corporation そのあと：作るリソースを徐々に増やす＆トリガを作成してみる ※ 1つリソースを作ったら、そこから作るリソースを徐々に増やしていく • 次にLambdaを作り、一度デプロイした後にpropsで以下を設定する ◦ 値を変更し、それがマネジメントコンソールに反映されることを確認する（「timeout」など） ◦ 他リソース（例：S3バケット）のプロパティを埋め込む（例：「environment」にbucketNameを設定する） • API Gatewayを作成し、Lambdaトリガを設定する（「LambdaIntegration」クラス） ◦ これは最初は少し敷居が高いので、既存ソースのコピペやAIにコード生成させてもOK ◦ ただし、その場合も「それで終わり」ではなく、そのコードについて「自分で調べる」事が大事 • 大切なのは「最初は小さく書いて、そこから守備範囲を広げていく」事 ◦ いきなり最初からあれこれやろうとしない
15. 14 KDDI Agile Development Center Corporation まとめ
16. 15 KDDI Agile Development Center Corporation まとめ ※ CDKは難しくない。書いてないだけ • 「読めるけど書けない」原因はAI依存による実践不足 • まずは「CDKの基本」を知る（何事においても「基本」が大事） ◦ とりあえず最初はスタック/コンストラクタ/propsをなんとなく理解すればOK ◦ コンストラクタはCDKの最重要要素 ◦ CDKのコードを書く ≒ コンストラクタを定義する（※1） • まず小さく書いて、そこから徐々に理解を広げていく ◦ いきなり一気にいろいろ書くと、エラーが出た際に訳が分からなくなる ◦ まずは小さく書いて「動かす」ことを優先し、そこから徐々に理解を広げていくことが大事 ※1：もちろん、それが全てではない
17. 16 KDDI Agile Development Center Corporation 参考：「書ける」ようになる3つの習慣 ※ CDKに限らず、どんなコードでも共通だと思います • コードを「一行ずつ消して再現」する ◦ 既存のコードやAIが生成したコードを読んだ後で、消してゼロから書き直す ◦ 「写経」ではなく「再現」するのがポイント • まず自分で公式リファレンスを調べる ◦ 何かあったら、まず AWS CDK公式リファレンス を自分で調べる ◦ AIに聞くのはそのあと • 小さくcommitして差分を学ぶ ◦ リソースを1つ追加したらコードをcommitする ◦ 「git diff」コマンドを実施し、既存の状態との変化（=追加したコードがどう影響するのか）を学ぶ
18. Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る