CDKでさまざまなエージェントを構築してみた

AWS CDKを使って気づいたことなどをお話しした資料となります。（内容浅め）

Transcript

1. CDK でさまざまなエージェントを 構築してみた 2026.04.15 / JAWS-UG 東京支部 / 蔵品絢介
2. 自己紹介 プロフィール ニックネーム：くらっち ピーディーシー株式会社 システム開発部 アプリケーションエンジニア JAWS-UG 東京支部 運営 ↓ お猿さんアイコンが目印！ X アカウントはこちら！↑ 業務内容 社内業務用 Web アプリ開発（Ruby on Rails ） 生成 AI R&D （主に Amazon Bedrock AgentCore ） デジタルサイネージソリューション プロダクトのQA 業務 好きなAWS サービス Amazon Bedrock AgentCore CDK 歴は3 ヶ月くらい 2
3. 今日話すこと 01 私が CDK を使って試みていること 02 AI エージェント構築と CDK は相性が良い 03 AgentCore × Strands × CDK の開発体験が 劇的に変わった気がする 04 Durable Functions は「会話履歴保持の有無」で 決めれば良さそう 今回お話する内容は、CDK を使った完成品ではなく、発展途上のものについてお話します。 3
4. 私が CDK を使って試みていること
5. 私が CDK を使って試みていること 01 リリース前作業の自動化 RDS Snapshot 取得 + ElasticBeanstalk 設定保存 を自動化 02 ガイドラインサイト 更新ニュース配信 S3 の変更を検知して Slack に自動通知 AI エージェント 03 Backlog Webhook 開発サポートエージェント コメントを起点に 自動調査・レポート生成 AI エージェント Elastic Beanstalk RDS/EC2/LoadBalancer などのWeb アプリに必要なリソースを一元管理できるサービス ガイドライン 弊社システム開発部のルールやガイドラインが定義された静的Web サイト 5
6. ① リリース前作業の自動化
7. 前提 弊社では、本番リリース作業を決まった曜日の21 時に以下の流れで行なっています。 1. RDS のDB スナップショット取得 2. Elastic Beanstalk 環境の設定の保存（ Saved configurations ） 3. 手順2 で保存した設定を用いて環境を起動 i. 設定値に問題がないことをダブルチェックで確認 ii. アプリケーションバージョンを指定してソースコードをデプロイ 4. データ投入スクリプトなどの手動実行 5. URL ドメインのスワップ 6. リリース後動作確認 今回は、1,2 の手順を21 時に自動で取得する仕組みを構築 7
8. ① リリース前作業の自動化 そこまで時間はかからないけど、省略できるのであれば省略したかった... ！ RDS スナップショット取得 リリース開始時に毎回行うスナップショッ ト取得を EventBridge+Lambda で自動 化。リリース作業時間を短縮し、命名ミス などを防ぐ。 ElasticBeanstalk 設定の保存 リリース前の EB 設定保存も EventBridge+Lambda で自動化。 リリース作業を開始する時には、上記に処理が実行されている状態になるので、 時間の短縮に繋がる 「毎回やるルーティン作業」は自動化して、凡ミスを減らす 8
9. ② ガイドラインサイト更新ニュース配信
10. 前提 弊社のシステム開発部には、 「開発部ハンドブック」と呼ばれる、 以下のルールやガイドラインが記載されているWeb サイトが存在しています。 プロダクト開発体制のフロー 試験仕様書の作成方法 データ投入スクリプトを実行する際のルール 生成AI ツールの使用に関するポリシー SNS 投稿に関するルール etc... かなり大事なことが書かれているのですが、開発部メンバーが自立的に読む習慣がない 更新があった場合に通知が来れば目を通す機会を増やせるのでは？？ 10
11. ② ガイドラインサイト更新ニュース配信 対策 定期的に更新分をチェックして通知をする 11
12. ③ Backlog Webhook 開発サポートエージェント
13. ③ Backlog Webhook 開発サポートエージェント Backlog コメントを起点に 2 種類のタスクの自動化 を試している 質問応答エージェント コメントに対して、Backlog の プロジェクト / 課題 / Wiki / ドキュメント を自動調査して回答 品質レポート生成エージェント 開発品質改善のためのレポートを Backlog データから自動生成 特に品質レポート生成エージェントは人間の手でデータを集めてレポートを作成するのは大変。 13
14. ③ Backlog Webhook アーキテクチャ アーキテクチャはこんな感じです。Webhook あるある構成。 Backlog 上のデータ調査は、Strands Agents の AgentSkills を活用しています Claude Code で使ってるSkills を流用しただけ... ！ 14
15. ③ Backlog Webhook タイムアウト対策 Backlog Webhook のシビアな制約 Backlog Webhook は応答タイムアウトが非常に短く、エージェントの処理を待てない。 解決策: 非同期分離 1. Lambda ① → 即座に HTTP 200 を返す 2. 同時に SQS にキューを送信 3. SQS が Lambda ② を非同期で起動 4. Lambda ② が AgentCore を呼び出し結果をコメント Slack やTeams などのチャットツールで実装する場合も、 タイムアウト対策としてHTTP 200 を返さないとダメになることがありました。 15
16. AI エージェント構築と CDK は相性が良い
17. Bedrock AgentCore Runtime へデプロイする時の流れ CDK も使わず、agentcore CLI も使わないでデプロイする場合、以下のような流れでデプロイすること になります。 1. ローカルでエージェントを構築する 2. ECR にDocker イメージをプッシュ 3. ECR のイメージID を指定してBedrock AgentCore Runtime へデプロイする なんとなく agentcore launch コマンドを実行してやってると、気づかないかも？ cdk gc コマンドで不要なイメージを削除できる 公式ドキュメントには まだ開発中 との記載がありますが、 --unstable=gc をつければ有効になります 17
18. agentcore CLI → CDK へ agentcore CLI とは agentcore launch コマンド一発で AgentCore にエージェントをデプロイできる ツール 手軽に始めることができる Bedrock AgentCore 以外のリソースは別で管 理しておく必要がある CDK で一括管理へ移行 AWS リソース全てを1 つのリポジトリで一括管 理できる デプロイ手順が cdk deploy だけに統一され る 「どのリソースに変更が加わったのか」も cdk diff コマンドで確認できる 18
19. AgentCore × Strands × CDK の 開発体験が劇的に変わった
20. コンソールぽちぽちより速い マネコンより速く検証できる AWS マネコンでぽちぽちするより、コードで書いた方が早い。 素早くリソースを作成・変更・削除して検証サイクルを回せる。 cdk destroy コマンドで検証用で作ったリソースを全て削除できるので、 削除忘れによる余計なコストがかかりづらくなる！ 20
21. テンプレ化できてしまうのでより早く コードはほぼテンプレ化できる 各リソースの記述はパターンが決まっており、一度書けば流用できる。 コードを書く際に詰まることがほぼない。 IAM ロール・ポリシーはいまだに詰まる... 一度作成したCDK リソースはSkill 化しておくと便利です。 . |- .claude |- skills |- cdk-sample-skill |- SKILL.md ・・・ ここにCDKリポジトリの場所を記載していく 21
22. セキュリティの考慮がちょっと楽になった 環境変数にアクセスキーや認証情報を配置することはセキュリティにOUT... Secrets Manager に認証情報は格納するようにしておく コード内に認証情報は書かない コードに含めない = 各リソースの環境変数などに設定されることはない cdk.json は .gitignore に設定しておくことで、 リモートリポジトリに認証情報をプッシュすることも少なくなる 22
23. CDK xxx コマンドたちが便利 以下のコマンドの存在は嬉しい！ cdk destroy : リソースの削除 cdk gc : 不要になったリソースの削除（ECR やS3 ） cdk docs : Claude Code のSkills に仕込んでます （AWS IaC MCP Server とどっちがいいんだろう？と実験中） 今度有効的に使いたいコマンド cdk migrate : デプロイ済のリソースをCDK プロジェクトに落とし込むことができる 最近UI バグ多めの ElasticBeanstalk から乗り換えもあり... ？ 23
24. おまけ: Lambda Durable Functions
25. Durable Functions とは 処理後にユーザの応答を待機できるモード 許可待ち・確認待ちなどのワークフローに有効 状態を保持したまま最大 1 年 待機可能 1 回の実行自体は 15 分制限 があるため、長時間の処理は分割が必要。 通常モードとの違い 通常 Durable 待機 なし 最大1 年 状態保持 なし あり 25
26. 今回のケースでの判断と今後 今回 Durable Functions を使わなかったケース ガイドライン更新通知 定期チェック → 自動通知のフロー。 ユーザの応答待機が不要なため、通常モードで十分。 26
27. 今回のケースでの判断と今後 今後 Durable Functions を適用したいケース 質問応答エージェント 各開発メンバーごとに会話履歴を持たせ、待機状態にしておくのが良い場合は、 Durable Functions を使うように改修していきたい 品質レポート生成 生成されたレポートに対して、承認・修正依頼などの操作を開発メンバーが行う場合は、 Durable Functions を使うように改修していきたい 27
28. まとめ CDK でAI エージェント周辺リソースを一括管理できる Lambda / SQS / IAM / CloudWatch などをコードで統一管理。 cdk deploy 一発でデプロイ完結。 コードで書いた方がコンソールより速い マネコンのぽちぽちより検証サイクルが速い。 各リソースの記述はテンプレ化できるので詰まらない。 Durable Functions は「ユーザ応答待機が必要か」で判断 自動処理フローなら不要。承認・却下などの人間の介在が必要なケースで活用を検討する。 28
29. 今後 既存の Elastic Beanstalk / Lambda などの環境管理もCDK でできたら楽だよなぁ Lambda 増えがちなので、まとめて管理したい コーディングエージェントとの相性も抜群に良いので、よりCDK 化したい 29
30. 以上です！