Share
Embed
AIに書かせたCDK、動くだけで満足してませんか?今日から始める、CDKハーネス設計!
Claude Codeなどのコーディングエージェントに「この構成図をCDKで実装して」と頼めば、それらしいコードは出てきます。
でも、grantsを使わずIAMを直書きしたり、L2があるのにL1で書いたり、動くけれど保守できないコードが量産されていませんか?
NRIでは構成図からCDKコードを生成するClaude Codeテンプレートを開発・運用しています。
本セッションではその過程で得たハーネス設計の実践知を以下のトピックでお話しします。
・構成図からいきなりコードを書かせない
・サブエージェント分割とコンテキスト管理
・AIが繰り返すCDK特有のミスの潰し方
・CDKの仕組みで品質を強制するConstruct設計
・AI生成コードのテスト戦略
AIにCDKを書かせたいがレビューコストに困っている方へ、今日から使える具体的なハーネス設計を持ち帰れるセッションです。
Shota Kawasaki
July 18, 2026
Transcript
64 slides
-
2 自己紹介 川崎 翔太 所属: 野村総合研究所 AXイノベーションセンター プラットフォームサービス開発二部 年次: 2年目
好きなサービス: AWS CDK -
4 AIを使用した検証中の開発手法イメージ AIエージェント Claude Codeなど NRIナレッジMCP AI開発プロセステンプレート MCPサーバー AIテンプレート ローカルエージェント
LLM ユーザーMCP ホスティング フロント バックエンド バッチ IaC GPT, Claude, Gemini などのLLMモデル -
5 AIエージェント Claude Codeなど NRIナレッジMCP AI開発プロセステンプレート MCPサーバー AIテンプレート ローカルエージェント LLM
ユーザーMCP ホスティング フロント バックエンド バッチ IaC GPT, Claude, Gemini などのLLMモデル ローカルのエージェントを用いて各種モデルや NRIのノウハウなどにセキュアに接続 AIを使用した検証中の開発手法イメージ -
6 AIエージェント Claude Codeなど NRIナレッジMCP AI開発プロセステンプレート MCPサーバー AIテンプレート ローカルエージェント LLM
ユーザーMCP ホスティング フロント バックエンド バッチ IaC GPT, Claude, Gemini などのLLMモデル AIを使用した検証中の開発手法イメージ 「開発プロジェクトのセット」と「コンテキスト」を 提供し安定した品質と高い生産性を実現 -
7 AIエージェント Claude Codeなど NRIナレッジMCP AI開発プロセステンプレート MCPサーバー AIテンプレート ローカルエージェント LLM
ユーザーMCP ホスティング フロント バックエンド バッチ IaC GPT, Claude, Gemini などのLLMモデル 今回は、AIテンプレートで適用している CDKのハーネス(1設計について紹介します! 1) 当発表では、「モデルを安定して動かすための実行環境や制御の仕組み」と定義する AIを使用した検証中の開発手法イメージ -
8 1 2 3 CDKのハーネス設計 CDKコード生成テンプレートの概要 まとめ 1 Sub AgentsとSkillsでコンテキスト管理する
2 構成のスケールに応じて生成ステップを分割する 3 Construct設計で共通設定を仕組み化する 4 計画段階で誤ったL1の使用を防ぐ 6 適切なテストを生成する 5 Aspectsで最終防衛線を張る 目次 -
9 1 2 3 CDKのハーネス設計 CDKコード生成テンプレートの概要 まとめ Sub AgentsとSkillsでコンテキスト管理する 構成のスケールに応じて生成ステップを分割する
Construct設計で共通設定を仕組み化する 計画段階で誤ったL1の使用を防ぐ 適切なテストを生成する Aspectsで最終防衛線を張る 目次 1 2 3 4 6 5 -
10 AIテンプレートとは AIが安定した品質のCDKを生成するための、知識や手順、 ルールをひとまとめにしたプロジェクトテンプレート IaC AIテンプレート agents: 独立したコンテキストで動くサブエージェント skills: ワークフローごとに読み込みたいナレッジやコマンド
rules:リポジトリ全体で適用すべきルール docs: AIが参照するための実行手順書 コード例: StackやConstructのコード例 継承元class: 生成するStackやConstructが継承するためのclass -
11 従来のIaC開発の課題 課題 #1 課題 #2 課題 #4 課題 #3
有識者の負荷集中 品質へのばらつき コードの標準化や 一貫性への欠如 開発速度が出ず、 プロジェクトの継続性に影響 習得・立ち上げコストが高く 導入しづらい / 調達しにくい -
12 従来のIaC開発の課題 課題 #1 課題 #2 課題 #4 課題 #3
有識者の負荷集中 品質へのばらつき コードの標準化や 一貫性への欠如 開発速度が出ず、 プロジェクトの継続性に影響 習得・立ち上げコストが高く 導入しづらい / 調達しにくい 有識者でなくても一定品 質のコードを生成可能 誰でも標準化された コードが得られる 作成・修正サイクルを短縮 人材要件のハードルを下げ 調達・育成コストを低減 IaC AIテンプレートを利用することで 有識者が多くなくても安定した品質のIaCコードを迅速に生成できる -
13 AIテンプレートを活用した開発フロー 構成図を格納するだけで、IaC生成からデプロイまでをカバー 利用されるローカルのエージェントはClaude Codeを想定 1 draw.io形式で構成図を格納 2 skillコマンドにてパラメータシート生成 3
skillコマンドにてソースコード生成 4 skillコマンドにて実環境にデプロイ 5 構成図やパラメータシートを修正し、ソースコードに反映 -
15 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 構成図からSkillでパラメータシートを作成
ECS(Fargate)だけでは、詳細なタスク定義が読み取れず ソースコード生成の段階で修正する可能性が生じる -
16 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 構成図からSkillでパラメータシートを作成
設計周りの重要な意思決定は、人間がレビューできるように工夫 -
18 ソースコードをSkillで実環境にデプロイ 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
/deploy-source-code Dev(開発)環境 Stg(ステージング)環境 Prod(本番)環境 -ENV = dev -ENV = Prod -ENV = Stg -
19 構成図の修正を検知し、ソースコードに反映 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
/update-param-sheet: 構成図の差分を検知してパラメータシートを更新 /update-source-code: パラメータシートの差分を検知して ソースコードを更新 DynamoDBを削除 -
23 1 2 3 CDKのハーネス設計 CDKコード生成テンプレートの概要 まとめ Sub AgentsとSkillsでコンテキスト管理する 構成のスケールに応じて生成ステップを分割する
Construct設計で共通設定を仕組み化する 計画段階で誤ったL1の使用を防ぐ 適切なテストを生成する Aspectsで最終防衛線を張る 目次 1 2 3 4 6 5 -
24 1 2 3 CDKのハーネス設計 CDKコード生成テンプレートの概要 まとめ Sub AgentsとSkillsでコンテキスト管理する 構成のスケールに応じて生成ステップを分割する
Construct設計で共通設定を仕組み化する 計画段階で誤ったL1の使用を防ぐ 適切なテストを生成する Aspectsで最終防衛線を張る 目次 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 1 2 3 4 6 5 -
25 Sub AgentsとSkillsでコンテキストを管理する 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース
修正 各プロセスにおいて、責務に応じたAgentとSkillに分割する 従来の課題 プロンプトやCLAUDE.mdに記載したことが無視される プロンプトの質によって生成コードがブレる このハーネスによるメリット 回答精度を上げ、同時実行を可能とする 用意されたコンテキストにより、プロンプトによって品質がブレない 生成に時間がかかる 1 -
26 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 対応プロセス
サブエージェント名 役割 パラメータシート生成 param-sheet-planner パラメータシート生成計画作成 param-sheet-generator パラメータシート生成 param-sheet-checker パラメータシート品質チェック ソースコード生成 source-code-planner ソースコード生成計画作成 source-code-generator ソースコード生成 source-code-checker ソースコード品質チェック デプロイ source-code-deployer ソースコードデプロイ ※実際のエージェントを網羅しているわけではなく、切り方の一例になります Sub AgentsとSkillsでコンテキストを管理する 1 -
27 1 2 3 CDKのハーネス設計 CDKコード生成テンプレートの概要 まとめ Sub AgentsとSkillsでコンテキスト管理する 構成のスケールに応じて生成ステップを分割する
Construct設計で共通設定を仕組み化する 計画段階で誤ったL1の使用を防ぐ 適切なテストを生成する Aspectsで最終防衛線を張る 目次 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 1 2 3 4 6 5 -
28 構成のスケールに応じて生成ステップを分割する 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
規模に応じて、パラメータシートとソースコード生成の ステップ(=エージェント呼び出し)の回数を動的に変更する 従来の課題 エージェントが扱うコンテキストが多く、エージェントの回答精度が下がる エージェントの成果物や動きが追いにくい このハーネスによるメリット 1エージェントが扱うリソース数を制限することによる回答精度の向上 各ステップでstep_summary.mdをエージェントに出力させることにより、 エージェントの思考過程が追え、中断や追加の指示が容易になる 2 -
29 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 /generate-param-sheet
パラシ作成計画エージェント 作成計画確認エージェント パラシ作成エージェント パラシ確認エージェント step-summary.mdを生成 step-summary.mdを生成 step-summary.mdを生成 構成のスケールに応じて生成ステップを分割する 2 -
step-summary.mdを生成 30 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
/generate-param-sheet 生成するファイル数に応じて分割、繰り返しする step-summary.mdを生成 step-summary.mdを生成 パラシ作成計画エージェント 作成計画確認エージェント パラシ作成エージェント パラシ確認エージェント 構成のスケールに応じて生成ステップを分割する 2 -
31 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 ネットワーク
セキュリティ ロードバランサー CDN コンピューティング データベース ストレージ+モニタリング 例えば、パラシ作成エージェントが生成するファイル数の 上限を4ファイルとしたとき、以下のステップに分割される 構成のスケールに応じて生成ステップを分割する 2 -
例えば、パラシ作成エージェントが生成するファイル数の 上限を4ファイルとしたとき、以下のステップに分割される 32 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース
修正 ネットワーク セキュリティ ロードバランサー CDN コンピューティング データベース ストレージ+モニタリング VPC周りのネットワークなど、 依存度が高いリソースから生成するように設計 構成のスケールに応じて生成ステップを分割する 2 -
33 1 2 3 CDKのハーネス設計 CDKコード生成テンプレートの概要 まとめ Sub AgentsとSkillsでコンテキスト管理する 構成のスケールに応じて生成ステップを分割する
Construct設計で共通設定を仕組み化する 計画段階で誤ったL1の使用を防ぐ 適切なテストを生成する Aspectsで最終防衛線を張る 目次 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 1 2 3 4 6 5 -
34 Construct設計で共通設定を仕組み化する 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
BaseStackやBaseConstructという基底クラスを作成し全ての StackやConstructに継承させることで共通の設定を仕組み化 従来の課題 TagやRemovalPolicyなどの共通設定を、Construct個別に書いてしまう 複数環境展開時に、Constructにfeatureフラグが量産されてしまう このハーネスによるメリット BaseStackにTagやRemovalPolicyを設定することにより、設定を強制 Environment変数をnodeのコンテキストとして格納し、 基底クラス内でアクセスする設計により、環境差分を吸収 3 -
35 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 利用パターンの詳細は下記NRIメンバーのブログ参照
Construct設計で共通設定を仕組み化する 3 -
36 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 ※BaseStackの一部抜粋
Construct設計で共通設定を仕組み化する 3 -
37 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 全Stackが継承されるBaseStack内で
Tagを付与することにより共通のTagを仕組み化 環境ごとにデフォルトのRemovalPolicyを付与 比較的新しいAPIも仕組み化することで対応 ※BaseStackの一部抜粋 Construct設計で共通設定を仕組み化する 3 -
38 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 ※BaseConstructの一部抜粋
Construct設計で共通設定を仕組み化する 3 -
39 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 Nodeのコンテキストに埋め込んだ環境変数を
全てのConstructから.appEnvで受け取れるように実装 ※BaseConstructの一部抜粋 Construct設計で共通設定を仕組み化する 3 -
40 1 2 3 CDKのハーネス設計 CDKコード生成テンプレートの概要 まとめ Sub AgentsとSkillsでコンテキスト管理する 構成のスケールに応じて生成ステップを分割する
Construct設計で共通設定を仕組み化する 計画段階で誤ったL1の使用を防ぐ 適切なテストを生成する Aspectsで最終防衛線を張る 目次 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 1 2 3 4 6 5 -
41 計画段階で誤ったL1の利用を防ぐ 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
ソースコード生成前に、Constructの利用方針を検討させ、 AIがミスしがちな不要なL1の多用を防ぐ 従来の課題 このハーネスによるメリット L1の利用理由を計画段階で明記させることで、L2が利用されやすくなる source-code-plannerなどの独自のエージェントに切り出すことができ、 MCPを用いた調査の指示やConstruct独自の指示が漏れにくくなる 型安全性やレビュー負荷の観点からAIの生成物としてはL2の方が望ましいが、 アップデート等に対応できず、L2が利用できるリソースでL1を利用してしまう 4 -
42 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 SkillでCfnから始まるL1
Constructを使用する際には、 MCPサーバーで最新情報を取得するよう指示 計画段階で誤ったL1の利用を防ぐ 4 -
43 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 比較的新しいVpcOriginも
L2を使うように計画されている 計画段階で誤ったL1の利用を防ぐ 4 -
44 1 2 3 CDKのハーネス設計 CDKコード生成テンプレートの概要 まとめ Sub AgentsとSkillsでコンテキスト管理する 構成のスケールに応じて生成ステップを分割する
Construct設計で共通設定を仕組み化する 計画段階で誤ったL1の使用を防ぐ 適切なテストを生成する Aspectsで最終防衛線を張る 目次 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 1 2 3 4 6 5 -
45 Aspectsで最終防衛線を張る 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
AIに絶対守らせたい要件を事前にAspectsで定義することで 守られていない場合デプロイ以前に落とすことができる 従来の課題 指示を無視し、AIが意図しない設定でリソースを実装してしまう このハーネスによるメリット 守らせたい要件を満たしていない場合、デプロイが起きないように強制できる AIがそのAspectsを読み込むことで、要件の意思表示となる 5 -
46 補足: Aspectsとは 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース
修正 コードの実行後、デプロイされる前に リソース全体を自動でチェック・修正する仕組み cdk deploy Construct Prepare Validate Synthesize Deploy リソース間の依存関係解決や Aspectsの適用が行われる -
47 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 RDSのsecret生成をL2
Constructに任せずに独自実装した際に デプロイをブロックできる ※一部省略しています Aspectsで最終防衛線を張る 5 -
48 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 RDSのsecret生成をL2
Constructに任せずに独自実装した際に デプロイをブロックできる AIが頻繁に起こしやすいミスを事前に対策できる Aspectsで最終防衛線を張る 5 -
49 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 RDSのsecret生成をL2
Constructに任せずに独自実装した際に デプロイをブロックできる 定義したAspectsはBaseStackに適用し 仕組みで強制する Aspectsで最終防衛線を張る 5 -
50 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 cdk-nag
(CDKのコードをチェックしてくれるツール) の 独自ルールに組み込むことも可能 1) https://docs.aws.amazon.com/cdk/v2/guide/policy-validation-synthesis.html cdk-nag v3を利用する場合、Aspectsではなく、 policy validation framework(1を利用 Aspectsで最終防衛線を張る 5 -
51 1 2 3 CDKのハーネス設計 CDKコード生成テンプレートの概要 まとめ Sub AgentsとSkillsでコンテキスト管理する 構成のスケールに応じて生成ステップを分割する
Construct設計で共通設定を仕組み化する 計画段階で誤ったL1の使用を防ぐ 適切なテストを生成する Aspectsで最終防衛線を張る 目次 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 1 2 3 4 6 5 -
52 適切なテストを生成する 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
適切な観点でテストを生成することにより、 AIによるリソースの修正や運用に耐えうるコードを書く 従来の課題 CDKのテストを書くことが難しく、テストを書く文化が浸透しない このハーネスによるメリット テストを書くことが容易となり、迅速に実装できる テストの有識者でなくても、適切な観点でテストを実装できる デプロイ優先となり、テストを実装する工数が確保できない 6 -
53 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 対応プロセス
目的 採用/非採用 スナップショット 生成されたCloudFormationテンプレー ト全体の差分を検知する。 採用 Fine-grained assertions テンプレート内の特定リソースやプロパ ティをピンポイントで検証する。 採用 バリデーション CDKコードとして不正な構成や禁止した い設定を、合成前後でチェックする。 設計ルールや入力値制約を守らせる目的。 採用 Integration 実際に近い形でスタックをデプロイ・ 実行して、複数リソースの連携やAWS上 での動作を確認する。 非採用(個人が自由にデプロイ できるdev環境を用意するため、 本テンプレートでは不要と判断) CDKには、一般的に4つテストの種類がある 適切なテストを生成する 6 -
54 ソースコード生成後に、独立したskillコマンドとして定義 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
/generate-assertion-tests /generate-snapshot-tests Fine-grained assertions + バリデーション スナップショット assertionテスト計画エージェント assertionテスト実装エージェント assertionテスト確認エージェント スナップショットテスト生成エージェント スナップショットテスト確認エージェント 適切なテストを生成する 6 -
55 ソースコード生成後に、独立したskillコマンドとして定義 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
/generate-assertion-tests /generate-snapshot-tests Fine-grained assertions + バリデーション スナップショット assertionテスト計画エージェント assertionテスト実装エージェント assertionテスト確認エージェント スナップショットテスト生成エージェント スナップショットテスト確認エージェント スナップショットは比較的単純なため plannerは不要と判断、シンプルな構成 適切なテストを生成する 6 -
56 ソースコード生成後に、独立したskillコマンドとして定義 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正
/generate-assertion-tests /generate-snapshot-tests Fine-grained assertions + バリデーション スナップショット assertionテスト計画エージェント assertionテスト実装エージェント assertionテスト確認エージェント スナップショットテスト生成エージェント スナップショットテスト確認エージェント generate-assertion-testsのplanner テスト観点が重要 適切なテストを生成する 6 -
57 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 事前にテスト観点を用意し、各Constructを検証する
テスト観点 該当する場合 for / map でリソースを動的生成している? Fine-grained(ループ検証)を書く if / props.xxx 分岐でリソースやプロパティを 切り替えている? Fine-grained(条件分岐 + Match.absent)を 書く addPropertyOverride を使っている? Fine-grained(override 確認)を書く props に対してバリデーション処理 (throw / Annotations.of)を実装している? バリデーションテストを書く ※全ての観点を網羅しているわけではなく、一例になります 適切なテストを生成する 6 -
58 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 plannerに事前に該当観点を検証させることで、
テストの品質を担保 ※解析結果は一例になります 適切なテストを生成する 6 -
59 1 2 3 CDKのハーネス設計 CDKコード生成テンプレートの概要 まとめ Sub AgentsとSkillsでコンテキスト管理する 構成のスケールに応じて生成ステップを分割する
Construct設計で共通設定を仕組み化する 計画段階で誤ったL1の使用を防ぐ 適切なテストを生成する Aspectsで最終防衛線を張る 目次 構成図を格納 パラメータシート 生成 ソースコード 生成 デプロイ リソース 修正 1 2 3 4 6 5 -
60 本日お話ししたこと 1 Sub AgentsとSkillsでコンテキスト管理する 2 構成のスケールに応じて生成ステップを分割する 3 Construct設計で共通設定を仕組み化する 4
計画段階で誤ったL1の使用を防ぐ 6 適切なテストを生成する 5 Aspectsで最終防衛線を張る