CDK Deployのための ”反響定位”

JAWS-UG CDK支部 #25 〜AI時代のCDK、みんなどう書いてる？〜 でお話しした内容です。
https://jawsug-cdk.connpass.com/event/386514/

Transcript

1. CDK Deployのための ”反響定位”
2. ⾳で世界を"視る"少年 > クラスメイトでいたずら好きの少年が、ベンをからかおうと、 ⾯⽩半分にその顔を殴った。するとベンは、いつものように⾆打ち を始めた。「⾆を鳴らしながら、彼を追いかけました。そして彼を 捕まえて、⼀発お⾒舞いしてやったんです。」 > (中略) ベンは失われた視⼒を補うべく、ある特異な能⼒を⾝に 付けた。それは継続的に⾆打ちをし、⼝から発する⾳のエコー （反響⾳）によって、まるで世界を視るように物体の外形や距離を 掴むというものである。 2 音で世界を"視る"少年 米 http://x51.org/x/06/07/1944.php
3. 反響定位(エコーロケーション) - 反響定位：発した⾳や超⾳波の反響 によって物体の距離‧⽅向‧⼤きさ などを知ること 、その能⼒ - 動物：コウモリ、イルカ - 厳密な空間把握とは異なる - 視覚障害者に対する反響定位 トレーニングを推進する国際的な 団体も存在する 3 【研究成果】コウモリが超音波から把握する空間が実空 間と異なることを発見 https://www.hiroshima-u.ac.jp/news/69707
4. About Me 渡邉 洋平(watany) • 所属：NTTテクノクロス株式会社 • AWS Ambassadors(2024〜) • JAWS-UG東京(AWSコミュニティ) 運営 • 寄稿：CodeZine ◦ 仕様駆動開発の原稿を近⽇公開予定 4 書籍は2026年5月2日（土）発売 https://www.sbcr.jp/product/4815636593/
5. 今⽇のテーマ - AIを前提とするAWS CDKの書き⽅について - エージェントのための反響定位について 5 JAWS-UG CDK支部 #25 〜AI時代のCDK、みんなどう書いてる？〜 https://jawsug-cdk.connpass.com/event/386514/
7. Context Engineering https://blog.langchain.com/context-engineering-for-agents/ 7 2026年4⽉時点で「AIで書く」とはエージェントの話
8. 暗黙知の体系化 2025年からAIエージェントユーザの経験的なベストプラクティス から体系⽴てられた知識たち - プロンプトエンジニアリング - コンテキストエンジニアリング - ハーネスエンジニアリング 8
9. プロンプトエンジニアリング 9
10. 「頭が⾚い⿂を⾷べる猫」には5通りの解釈がある 1. 頭が⾚い、⿂を⾷べる猫 2. 頭が⾚い⿂を、⾷べる猫 3. 頭が、⾚い⿂を⾷べる、猫 4. 頭が、⾚い⿂を⾷べる猫 5. 頭が、⾚い、⿂を⾷べる猫 10 頭が赤い魚を食べる猫 https://blog.sigakusya.com/2021/01/14/%E9%A0%AD%E3%81%8C%E8%B5%A4%E3%81%84%E9%AD%9A%E3 %82%92%E9%A3%9F%E3%81%B9%E3%82%8B%E7%8C%AB/
11. プロンプトエンジニアリング LLMを最⼤限活躍させるための指⽰のテクニック - 明瞭/明確/過不⾜のないプロンプト - 「頭が⾚い⿂を⾷べる猫」と書かない - プロンプトの「型」 - 例⽰すると精度が上がる(Few-shot prompting) - 出⼒形式を固定すると安定する（Structured output） - 段階的に推論させると精度が上がる(CoT/Reasoning) 11
12. コンテキストエンジニアリング 12
13. 「LLMという関数」の⼊⼒においてプロンプトはほんの⼀部 12-Factor Agents -3. Own your context window https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-03-own-your-context-window.md 13 Prompt → Context
14. 14 コンテキストを書く / 選ぶ / 縮める / 分ける ための技術 Context Engineering https://blog.langchain.com/context-engineering-for-agents/
15. 今⽇のテーマの現時点への回答 - Q.「AI時代のCDKをどう書いているか」 - A. 「コンテキストを与えながらエージェントに書かせている」 - 「ただしここがゴールだとは思っていない」 15 JAWS-UG CDK支部 #25 〜AI時代のCDK、みんなどう書いてる？〜 https://jawsug-cdk.connpass.com/event/386514/
16. 今の書き⽅よりも 先の話をしましょう 16
17. ハーネスエンジニアリング 17
18. > TLDR: Agent = Model + Harness. 18 AIエージェントをハーネス(⾺具)と呼ぶ⼈たち The Anatomy of an Agent Harness https://blog.langchain.com/the-anatomy-of-an-agent-harness/ > (下線は筆者による)All models are run with OpenHands agent framework (Wang et al., 2024b),1 which provides a stable and strong agent harness for both web browsing and coding. TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks https://arxiv.org/html/2412.14161v2
19. 19 Anthropicの定義：LLMを⻑時間駆動させるための⾺具 LLMはセッション毎に記憶が無くなる(ステートレス) - 2025/11：バトンの受け渡し - Setupスクリプト、進捗ファイル、git履歴、⾃動テスト - 2026/03：”GAN”型の評価者エージェントの追加 - ⽣成 Agentと評価Agentからなるマルチエージェント構成 - 2026/04：モデルの⾃主性を尊重する - 不要な補助ロジック‧ツール‧制御...を外す - セキュリティ境界への決定論的⼿段は設定する Effective harnesses for long-running agents https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents Harness design for long-running application development https://www.anthropic.com/engineering/harness-design-long-running-apps Harnessing Claude’s intelligence https://claude.com/blog/harnessing-claudes-intelligence
20. 20 OpenAIの定義：⼈間を介在させないエンジニアリング - ナレッジベース(doc/)と⽬次(AGENT.md) - カスタムリンターと構造テスト - 技術的負債の返済 - 拡⼤したエントロピーへのガベージコレクション — > ⽣成されたコードは、必ずしも⼈間のスタイルの好みに合致 するとは限りませんが、それでも構いません。 出⼒結果が正しく、保守可能であり、将来の実⾏エージェントが 読み取れる限り、基準を満たしています。 ハーネスエンジニアリング：エージェントファーストの世界における Codex の活用 https://openai.com/ja-JP/index/harness-engineering/
21. ”ハーネス”というバズワードを読み解く ハーネスは2層に分けられる - (内部)ハーネス - Modelの外側 - “Agent マイナス Model” - 外部ハーネス - 内部ハーネスの外側 - ハーネスにハーネスを 巻くのは変だが 置いておく 21
22. ”ハーネス”というバズワードを読み解く ハーネスのスコープは⼤きく2つに分けられる - 内部ハーネス - LangchainやAnthropicが語るハーネスエンジニアリング - AIエージェントにおけるLLMモデル「以外」の実装 - ≒ エージェントの作り⼿側が考慮するハーネス - 外部ハーネス - OpenAIやMitchell Hashimotoが語るハーネスエンジニアリング - AIエージェントが同じミスをしないように、解決策を設計 (Mitchell Hashimoto) - ≒ エージェントの使い⼿側が考慮するハーネス 22
23. 以降のハーネスエンジニアリングは外部ハーネスを指す ハーネスのスコープは⼤きく2つに分けられる - 内部ハーネス - LangchainやAnthropicが語るハーネスエンジニアリング - AIエージェントにおけるLLMモデル「以外」の実装 - ≒ エージェントの作り⼿側が考慮するハーネス - 外部ハーネス - OpenAIやMitchell Hashimotoが語るハーネスエンジニアリング - AIエージェントが同じミスをしないように、解決策を設計 (Mitchell Hashimoto) - ≒ エージェントの使い⼿側が考慮するハーネス 23
24. 24 ハーネスエンジニアリングの構成要素
25. ハーネスエンジニアリングは 2種類のプロセスに分けられる - feedforward(Guide)： - ⽣成するために必要な情報 - feedback(Sensors) ： - ⽣成物の評価に必要な情報 25 feedforward/feedback
26. 再掲：暗黙知の体系化 2025年からAIエージェントユーザの経験的なベストプラクティス から体系⽴てられた知識たち - プロンプトエンジニアリング - 適切な指⽰を与える - コンテキストエンジニアリング - 適切な指⽰と⽂脈を与える - ハーネスエンジニアリング - 適切な指⽰と⽂脈を与える環境を整備する 26
27. つまり、ハーネスエンジニアリングとは - 必要な情報(feedforward)を元に⽣成し - 必要な情報(feedback)を元に評価ループを回す ハーネスエンジニアリングを取り⼊れると - 必要なフィードバックを与えるほど、現在の品質が「視える」 - 視えた課題は⾃律的に直るので、レビュー負荷が減る - レビューというボトルネックを解消するほど、開発が速くなる 27 ハーネスエンジニアリングに必要な反響定位
28. 反響定位についての前提は揃った 28
29. CDK Deployのための反響定位について 29
31. - Productionでfeedbackを受けるのはあり得ない - ”多分動くと思うからリリースしようぜ” 31 feedbackをどこで⾏うか CI/CD on AWS https://docs.aws.amazon.com/ja_jp/whitepapers/latest/cicd_for_5g_networks_on_aws/cicd-on-aws.html
32. - Stagingでfeedbackを受けるのは妥当ではある - デプロイ ：15分/回 → 4回/時 32 feedbackをどこで⾏うか CI/CD on AWS https://docs.aws.amazon.com/ja_jp/whitepapers/latest/cicd_for_5g_networks_on_aws/cicd-on-aws.html
33. - ローカルでfeedbackを受けるとイテレーションを増やせる - ⾃動テスト：数分/回 → 10回以上/時 33 feedbackをどこで⾏うか CI/CD on AWS https://docs.aws.amazon.com/ja_jp/whitepapers/latest/cicd_for_5g_networks_on_aws/cicd-on-aws.html
34. - ⾃動テスト10分だと、イテレーションは 6回/時 - 10分→5分に短縮すると、エージェント側で2倍速くなる - 10分→2分に短縮すると、エージェント側で5倍速くなる - ローカルほど速く、外部へ通信すると遅くなる - npm run ci 5分/回 → 12回/時 - npm run deploy 15分/回 → 4回/時 - デプロイ効率を⾼めるには”左側”でfeedbackを増やす必要がある - エージェントループのためのシフトレフト 34 feedbackは早く返したい
35. 35 AWS CDK(Deploy)のライフサイクル CDK Aspectsを利用してベストプラクティスに従ったインフラストラクチャを構築する https://aws.amazon.com/jp/blogs/news/align-with-best-practices-while-creating-infrastructure -using-cdk-aspects/
36. AWS CDKのデプロイまでの7段階 (★は図にない部分) 1. Construct 2. Prepare 3. Validate 4. Synthesize 5. Difference(★) 6. Publish(★) 7. Deploy 36 AWS CDK(Deploy)のライフサイクル CDK Aspectsを利用してベストプラクティスに従ったインフラストラクチャを構築する https://aws.amazon.com/jp/blogs/news/align-with-best-practices-while-creating-infrastructure -using-cdk-aspects/
37. - 特有のTree構造でコーディング - App(エントリーポイント) - Stack(CFn Stack) - Construct (抽象化されたAWSリソース) - 注意：Tokenの処理は対応不可 - Token：Construct記述時に 未確定な値のプレースホルダー 37 feedback - 1. Construct AWS CDK とは https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/home.html
38. - フィードバック：CDKにおける主要なUnit Test - Snapshot - Fine-grained assertions - Validation 38 feedback - 1. Construct
39. - CDKで⽣成されるテンプレートの差分を検出するテスト 39 Unit Test - Snapshot AWS CDK における単体テストの使い所を学ぶ https://aws.amazon.com/jp/builders-flash/202411/learn-cdk-unit-test
40. - CDKで⽣成されるテンプレートの構成要素への単体テスト 40 Unit Test - Fine-grained assertions AWS CDK における単体テストの使い所を学ぶ https://aws.amazon.com/jp/builders-flash/202411/learn-cdk-unit-test
41. - CDKで⽣成されるテンプレートの値の妥当性をテスト 41 Unit Test - Validation AWS CDK における単体テストの使い所を学ぶ https://aws.amazon.com/jp/builders-flash/202411/learn-cdk-unit-test
42. - フィードバック：複数resourceに 跨る共通ルールを設定 - 設定箇所は「CDK Aspects」 >CDK Aspects は、特定のスコープ 内のすべての construct に対して 共通の操作を適⽤する⽅法です。 >CDK Aspect は Preparation フェーズで関係してきます。 この Preparation フェーズでは、 construct の最終的な状態を設定 するための最後の変更ラウンドが 実⾏されます。 42 feedback - 2. Prepare CDK Aspectsを利用してベストプラクティスに従ったインフラストラクチャを構築する https://aws.amazon.com/jp/blogs/news/align-with-best-practices-while-creating-infrastructure -using-cdk-aspects/
43. - CDK Deploy前にAspectsでバリデーションする例 43 feedback - 2. Prepare CDK Aspectsを利用してベストプラクティスに従ったインフラストラクチャを構築する https://aws.amazon.com/jp/blogs/news/align-with-best-practices-while-creating-infrastruc ture-using-cdk-aspects/
44. - cdk-nag(静的解析ツール)をAspectsで実⾏する例 44 feedback - 2. Prepare AWS Cloud Development Kit と cdk-nag でアプリケーションのセキュリティとコンプライアンスを管理する https://aws.amazon.com/jp/blogs/news/manage-application-security-and-compliance-with-the-aws-cloud-develop ment-kit-and-cdk-nag/
45. - フィードバック：遅延解決される値へのバリデーション。 - 例：解決済みのTokenの値など - Aspectsのタイミングで拾えない値を対象とする - 静的な値：Aspects、動的な値：Validation - Stack や Constructの内部にあるNode クラスのメソッド 「addValidation」で実施など 45 feedback - 3. Validate
46. 46 Appendix. NodeクラスとaddValidationの概要 CDKでValidationする本当の方法 https://speakerdeck.com/gotok365/cdk-validation
47. - cdk synth時にValidationを発動させる例 47 feedback - 3. Validate AWS CDK における単体テストの使い所を学ぶ https://aws.amazon.com/jp/builders-flash/202411/learn-cdk-unit-test
48. - Synthesize(合成)コマンドでのトランスパイル - CDK → Cloud Assembly(CFn + Asset + Metadata) - cdk synthでの固有の概念 - cdk.out: Cloud Assemblyの格納先ディレクトリ - cdk.context.json: 合成時に取得した値のキャッシュ - フィードバック - 合成が成功したか？ - 合成前後のCloud Assembly差分 - 合成後の資材へのテンプレート検査 48 feedback - 4. Synthesize
49. - 環境ごとのcdk synthコマンドの実⾏は、時間がかかるだけでなく 合成結果がバラバラになり、静的なフィードバックが得づらい。 - 引⽤：AWS CDK のデプロイベストプラクティス - > また、dev / stg / prod などの環境ごとに cdk deploy コマン ドを実⾏する場合、環境ごとに cdk synth コマンドも実⾏さ れることになります。つまり、環境ごとに合成処理が⾛ること になります。 49 Appendix. Synthesize once, deploy many
50. 50 feedback - 5. Difference ご注文の差分はこちらですか？ 〜 AWS CDK のいろいろな差分検出と安全なデプロイ https://speakerdeck.com/konokenj/cdk-snapshot-diff-drift?slide=4
51. - CDKで⽣成されるテンプレートの差分を検出するテスト 51 Difference - Snapshot(再掲) AWS CDK における単体テストの使い所を学ぶ https://aws.amazon.com/jp/builders-flash/202411/learn-cdk-unit-test
52. - リソース差分の計算 - CloudFormation 変更セット機能 - Snapshotとの違い：動的参照を加味した差分検出 - SSM Paramater Store / Secrets Managerでの値解決 - CFn記法(!Ref, !GetAtt) - Tips - 「--fail」: 差分が出たら exit code 1 52 Difference - cdk diff ご注文の差分はこちらですか？ 〜 AWS CDK のいろいろな差分検出と安全なデプロイ https://speakerdeck.com/konokenj/cdk-snapshot-diff-drift?slide=4
53. - リソースと環境差分の計算 - CloudFormation (ドリフト検出機能) - cdk diffとの違い：IaCの状態と実環境の差分検出 - 差分によってはデプロイ影響があるので解消が必須 - エージェントに依頼し、IaCの状態と実態を適合させる。 53 Difference - cdk drift AWS CDK における単体テストの使い所を学ぶ https://aws.amazon.com/jp/builders-flash/202411/learn-cdk-unit-test
54. - ファイルやイメージなどのAssetを 事前アップロード(Publish) - AssetのbuildとAWS リソースDeployの責務を分離 - フィードバック：Assetの不備 (⾮IaC部分)の検知 - Assetの概要図 - 引⽤：もっとじっくり AWS CDK のコンセプト 第6回 アセッ ト 54 feedback - 6. Publish
55. - Publishはcdk publish-assetsで実施。 - npx cdk publish-assets --unstable=publish-assets --app cdk.out - 4/1にマージされたばかりのβ版なのでフラグが必要 - --unstable=publish-assets 55 feedback - 6. Publish
56. - フィードバック - デプロイ失敗：できるだけ詳細なエラーメッセージ - ホットスワップ：Assetだけの⾼速デプロイによる迅速な結果 - Appendix. - Agent Plugins for AWS(エージェント⽤のプラグイン)に 「deploy-on-aws」は存在するが、feedforward⽤途 - Deploy on AWS Plugin - AWSへのアプリケーション導⼊を、推奨アーキテクチャの 提案、コスト試算、IaCによるデプロイ、検証済みアーキ テクチャ図の作成まで⼀貫してサポートします。(筆者訳) 56 feedback - 7. Deploy
57. - `--hotswap` - AWS SDK によって直接更新 ≒ ⾼速feedback - Hotswapの対象リソース(下 + Agentcore) 57 feedback - 7. Deploy - dev cdk deploy https://docs.aws.amazon.com/cdk/v2/guide/ref-cli-cmd-deploy.html
58. - `--no-rollback` - デプロイ失敗時のロールバックを停⽌‧失敗状態の保持 - ＝失敗した環境をfeedbackとして扱う - 停⽌したロールバックは「 cdk rollback」で再実⾏ 58 feedback - 7. Deploy - dev
59. - `--progress events` - 完全なCloudFormation Eventを出⼒ - 失敗時の「CREATE_FAILED時の論理 ID」「主原因は何か」 - 注意) コンテキストが増える点に注意 59 feedback - 7. Deploy - prod
60. - `--progress events` - 完全なCloudFormation Eventを出⼒ - 失敗時の「CREATE_FAILED時の論理 ID」「主原因は何か」 - 注意) コンテキストが増える点に注意 60 feedback - 7. Deploy - prod
61. - エージェントへのレビューをどの密度にする場合でも今後は ハーネスエンジニアリングが必須になっていく - 紹介した7段階のフィードバック例をSkills化などして使う - ※間に合わなかったため後⽇掲載 or 発表 - 新しいことを始める訳ではなく、コミュニティでの実践を以下に 明⽂化していくかを考える - フィードバックを与えるツールを作るのもいい - lecs：Kubernetesの「Kind」のECS版 61 まとめ