Transforming CDK Contribution into Issue-Driven Development

Transcript

1. AWS CDK Conference Japan 2026 presented by JAWS-UG CDK Contribution Skill をトランスフォームしたら Issue 駆動で CDK 開発できるのか 2026年7月18日 ます（@hayatin）
2. © TDI Co., Ltd. 2 プロフィール 早川 将史 会社 所属 ロール 業務 ます（@hayatin） はやかわ まさふみ 好きなCDKコンストラクト： NodejsFunction ：TDI 株式会社 ：デジタルイノベーション技術部 ：テックリード ：全社の技術支援、営業支援、 最新技術の検証・適用
3. © TDI Co., Ltd. 3 きっかけは、AWS Hero 後藤さんの X ポスト 1 後藤さんのポストで Skill を知る 2 AWS 松田さんの紹介記事で深掘り https://zenn.dev/aws_japan/articles/cdk-contribution-skill 「CDKに限らず、ソフトウェア開発へのAI適用のプラクティスが 詰まっている」 これ、普段の CDK 開発 にも使えるのでは？
4. © TDI Co., Ltd. 4 10 Agent が 5 フェーズを流れ、2 つの承認ゲートで人が判断 GitHub Issue 分析 Issue Analyst 1 設計 Solution Architect 2 承認ゲート ①（実装前） 人が承認 実装 Build Engineer ＋ Implementation Specialist 3 検証 並列 4 Test Engineer QA Specialist Documentation レビュー 並列 5 Security Regression Review Report 承認ゲート ②（PR前） 人が最終承認 レビュー可能な PR
5. © TDI Co., Ltd. 5 各 Agent は Agent SOP で定義されている Agent SOP ＝ Agent 1 体分のワークフロー定義 Role Identity（役割定義） 何者で、何を担当するかを宣言 Input Requirements（入力要件） 処理開始前に読むべき成果物 Procedure（手順） ステップバイステップの実行指示 Output Deliverable（成果物） 出力すべきファイルとフォーマット Success Criteria（成功基準） 完了条件のチェックリスト Markdown × 自然言語で記述 コードではなく文章。誰でも読めて、直せる MUST / SHOULD / MAY RFC 2119 のキーワードで手順の優先度を明示 一貫した品質 × カスタマイズ 10 体を同じ品質で動かせ、直したい所は自然言語で 書き換えるだけ
6. © TDI Co., Ltd. 6 読み解く → 残す / 変える / 足す ＝ 残す 汎用ワークフロー 5 フェーズ + 承認ゲート 破壊的変更の分析 セキュリティチェックリスト Go / No-Go 判定 Review Report Generator → 100% そのまま流用 ⇔ 変える aws-cdk 固有 → 自分の CDK 向け 対象リポジトリの前提 yarn+lerna → npm+cdk synth integ-runner → Jest+cdk diff JSII / upstream sync は削除 ＋ 足す CDK 品質チェック（3 層） 自動 eslint-plugin-awscdk 自動 cdk-nag 手動 手動レビュー（SOP） ＋ cdk diff で既存への影響確認
7. © TDI Co., Ltd. 7 同じ Issue で、どれだけ変わる？
8. © TDI Co., Ltd. 8 試した Issue はこんな感じ
9. © TDI Co., Ltd. 9 スキルありはテストの観点が違った 観点 スキルなし（丸投げ） スキルあり Jest テスト 14（存在確認が中心） 24（SSL/TLS/OAC も検証） cdk-nag 未解決 13 件 0 件（全て承認） eslint（awscdk） 7 件 0 件 IAM5（ワイルドカード） 放置（根拠なし） 根拠付きで承認 監査証跡 なし 01〜05.md + GO/NO-GO 差は 件数 ではなく 観点 と 説明責任
10. © TDI Co., Ltd. 10 スキルなし・ありでのコードの差 スキルなし const role = new iam.Role(this, 'LambdaRole', { assumedBy: new ServicePrincipal( 'lambda.amazonaws.com'), managedPolicies: [ Basic... ], }); bucket.grantReadWrite(role); table.grantReadWriteData(role); → IAM4 / IAM5 の指摘はそのまま スキルあり bucket.grantReadWrite(handler); table.grantReadWriteData(handler); acknowledge(defaultPolicy, 'AwsSolutions-IAM5[s3:PutObject*]', 'Wildcards by CDK grant, scoped to specific bucket / table ARNs.'); → 抑制ごとに "理由" を明記 抑制するかどうかではなく、なぜ 抑制したか？
11. © TDI Co., Ltd. 11 スキルが残したドキュメント 05-review.md （セルフレビュー）から抜粋 01〜05 の Markdown を出力 分析・設計・実装・検証・レビューの各フェーズが成果物を残す なぜ？まで残る nag 抑制の根拠・残リスク・GO/NO-GO 判定が言語化される 読むだけで理解が深まる 確認しながら進めるので、設計意図もアーキテクチャも追える
12. © TDI Co., Ltd. 12 正直、向き不向き はあります ✓ 向いている ✓ Issue 単位でスコープが切れる開発 （機能追加・リファクタ・PoC） ✓ 品質・セキュリティの観点を担保したい （cdk-nag / eslint / レビュー） ✓ レビュー前提で判断の証跡を残したい ✓ 学習目的 × 向かない × 要件がまだ固まっていない探索フェーズ （ゲート・SOP が重い） × ごく小さな変更 （フルワークフローは大げさ） × アーキテクチャの意思決定そのもの （人が主役） × レビュー工数・最終責任を負う人がいない （全自動ではない）
13. © TDI Co., Ltd. 13 Issue 駆動で CDK 開発できるのか？ → できた しかも、「できた」 だけじゃない。 01 スキルなしより、明確に 品質の高いコード を生成できた 02 各フェーズのドキュメントを確認しながら進められ、開発体験が良い 03 ドキュメントを読むと、アーキテクチャの理解も深まる 04 スキルだから、「もっとこうしたい」 を簡単に手に入れられる AI に任せて終わり、ではなく 判断しながら育てる CDK 開発へ GitHub リポジトリの URL