目次
AIが数十秒で書いたコードを、数分かけてデプロイしている
こんにちは！AWS CDKが大好きな早川です！
最近はコーディングエージェントがいい感じのCDKコードを書いてくれるようになり、本当にちょっとした構成ではほとんどCDKコードを書かなくなりました。
しかし、コードは簡単に早く書けたとしても、cdk deploy で数分待たされるのはこれまで通りです。
この問題を解決してくれるのが、AWS Heroの後藤さん（go-to-k）のOSS、cdkd（CDK Direct） です。cdk deploy を cdkd deploy に置き換えるだけで、既存コードのままデプロイが速くなるCLIで、なんと最大15倍のデプロイスピード！
私も参加したAWS CDK Conference Japan 2026でも紹介されていて、ずっと気になっていました。
READMEを読むと、多くのコマンドが用意されていることがわかりました。今回はcdkdのコマンドを、使いどころとあわせて紹介していきたいと思います！
※ 2026年8月時点のmainブランチ（v0.284系）が元ネタです。ドキュメントにもある通り、本番での利用は非推奨とされています。
cdkdコトハジメ
cdk deploy は、
- CDKのコードからCloudFormationテンプレートを出力
- それをCloudFormationに渡してデプロイしてもらう
という構成ですが、cdkdは後半のデプロイの部分を変更しています。
デプロイはCloudFormation経由ではなく、AWS SDKとCloud Control APIを直接呼ぶようになっています。
だから速いんですね！
なので、これまでCloudFormationが持っていたスタックの状態はcdkdがS3バケットで管理しています。
|
1 2 |
npm i -g @go-to-k/cdkd cdkd bootstrap # cdk bootstrap の代わりでアカウントごとに1回する。スタック状態を保持するS3バケット（など）を作る |
あとは cdk を cdkd に置き換えるだけで、CDKのコードには手を入れずに使用できるので、これまでと同じようにCDKによる開発ができるわけです。
|
1 2 |
cdkd deploy # cdk deploy の代わり cdkd destroy # cdk destroy の代わり |
後藤さんご本人も、紹介記事で「AWS CDK CLIを置き換えるものではなく、補完するもの」と書いています。
開発中はcdkdで素早くデプロイして、本番は本家のCDK CLIに任せるのがよさそうです。
普段づかいのコマンド（synth / deploy / diff / destroy）
普段使うコマンドは、本家のCDK CLIとほぼ同じなので戸惑いません。
|
1 2 3 4 5 6 7 |
cdkd synth cdkd deploy # スタックが1つなら自動で選ばれる cdkd deploy MyStack cdkd deploy --all cdkd deploy --dry-run # 変更せずプランだけ cdkd diff MyStack --fail # 差分があれば終了コード1 cdkd destroy MyStack |
デプロイ途中で失敗した場合は、本家のCDK CLIと同様に作成・変更したリソースをロールバックする仕組みを持っています。
ただし、CloudFormationのロールバックと完全に同一の挙動・保証であるとは限らない点はご注意を。
--no-rollback を付ければ、ロールバックせず途中の状態を残せます。あとから戻したくなったときのために cdkd rollback もあります。
DynamoDB、Lambda、API Gatewayだけの小さなスタックで試したところ、初回デプロイは29.22秒で完了しました。
|
1 2 3 4 5 6 |
Deploying 16 resource(s) (DAG: 7 levels, max parallel: 10) [1/16] ✓ ApiF70053CD (AWS::ApiGateway::RestApi) created [2/16] ✓ HandlerServiceRoleFCDC14AE (AWS::IAM::Role) created IAM propagation delay for ApiAccountA18C9B29 (attempt 1/3), retrying in 10s... ... Duration: 29.22s |
リソースの依存関係を7レベルの有向非巡回グラフ（DAG）に展開して、最大10並列で実行しています。
IAMの伝播が間に合わないときも、そこで失敗させずにリトライしていました。
どこまで待機するかを選ぶ（--no-wait / --full-wait）
cdk deploy が遅いのは、リソースの作成をAWSに依頼したあと、CloudFormationが「使える状態になった」と確認できるまで待機しているからです。
cdkdは、同じデプロイの中の何かがその状態を必要とするときと、待機することで失敗を検知できるときだけ待機します。
たとえばCloudFrontディストリビューションは、作成後、エッジへの伝播に3〜15分かかります。
ただ同じデプロイの中でその完了を必要とするものがないので、デフォルトは CreateDistribution が受け付けられた時点で次へ進みます。
この判断を変更するのが、次の2つのオプションです。
| オプション | 効く対象 | 挙動 |
|---|---|---|
--no-wait |
RDS、ElastiCache、NAT Gateway、EC2インスタンス、ELBv2ロードバランサー、Lambda MicroVM Image | デフォルトは待機するが、作成APIが返った時点で次へ進む |
--full-wait |
ECSサービス、CloudFrontディストリビューション | デフォルトは待機しないが、ECSはタスクが安定するまで、CloudFrontは配信が行き渡るまで待機する |
なお --no-wait はdeploy専用です。
destroyで使えないのは、削除中のNAT GatewayがENIを掴んだままになり、他のリソースの削除が DependencyViolation で落ちるからだとREADMEに書いてありました。
デプロイせずに動かす（cdkd local）
cdkd local はざっくり言えばsam localのようなもので、Lambda、API Gateway、ECS、ALB、CloudFrontからBedrock AgentCore Runtimeまで、ローカルで動かせます。
|
1 2 |
cdkd local invoke MyStack/Handler cdkd local start-api MyStack/MyApi --watch |
ローカル実行でエラーになりがちなのが、他のリソースを参照している環境変数です。
たとえばLambdaからDynamoDBのテーブルを読む構成なら、CDKではテーブル名を TABLE_NAME という環境変数で渡します。
ただ、そのテーブル名が決まるのはデプロイのときです。
CDKが出力するテンプレートには「あとで実際の名前を入れる」という目印（Ref）しか書かれていないので、ローカルで動かすだけではこれを解決できません。
そこでcdkdは、環境変数やシークレット、イメージURIに埋まった Ref や Fn::ImportValue を、デプロイ済みのスタックの実際の値に置き換えてくれます。
どちらのフラグを使うかは、そのスタックをcdkでデプロイしたのかcdkdでデプロイしたのかで使い分けます。
| スタックのデプロイ方法 | 使うフラグ | 値の取得元 |
|---|---|---|
cdk deploy（CloudFormation管理） |
--from-cfn-stack |
CloudFormationスタック |
cdkd deploy（cdkd管理） |
--from-state |
cdkdのstate（S3） |
|
1 |
cdkd local start-api MyStack/MyApi --from-cfn-stack |
どちらのフラグも付けないと、警告が出るだけで、その環境変数は渡りません。
さきほどの構成をcdkdでデプロイして、フラグなしで試したらこうなりました。
|
1 2 3 4 |
Environment variable TABLE_NAME contains a CloudFormation intrinsic and was dropped. Override it with --env-vars ..., or pass --from-state / --from-cfn-stack to recover deployed values. {"message":"hello from cdkd","tableName":null,"stage":"dev"} |
--from-state を足すと、tableName に実際のテーブル名が入ります。
|
1 |
{"message":"hello from cdkd","tableName":"CdkdDemoApi-Items5C12978B","stage":"dev"} |
start-api は、どのパスがどのLambdaにつながるかをCDKアプリから読み取って、そのままローカルにHTTPサーバーを立てます。
|
1 2 3 4 |
ApiF70053CD (REST API v1) (http://127.0.0.1:39073) Discovered routes: ANY / -> Handler886CB40B (REST v1, stage 'prod') ANY /{proxy+} -> Handler886CB40B (REST v1, stage 'prod') |
つまり、デプロイは cdk deploy のままで、ローカル実行のためだけにcdkdを入れることもできます。
local start-cloudfront は、CloudFront FunctionsとS3オリジンだけならDockerも要らず、ルーティング関数の修正を数秒で確認できます。
ずれを見つけて直す（cdkd drift）
CloudFormationのドリフト検出は、テンプレートに書いたプロパティだけを見ます。
cdkdはこれと違って、デプロイした時点のAWS側の状態を記録しておき、今の状態と突き合わせるので、テンプレートに書いていない設定をコンソールで変えたときも差分として出ます。
|
1 2 3 4 |
cdkd drift MyStack # 差分があれば終了コード1 cdkd drift MyStack --accept --yes # state ← AWS（コンソールの変更を正とする） cdkd drift MyStack --revert --yes # AWS ← state（コンソールの変更を取り消す） cdkd drift MyStack --json # CIから読める形で出す |
--dry-run を付ければ、stateやAWSリソースを変更せずに、実行予定の解決内容を確認できます。
消す、片付ける（destroy / orphan / gc）
destroy はAWSのリソースとstateの記録を両方削除し、orphan はstateの記録だけを消してAWSのリソースは残します。
|
1 2 |
cdkd destroy MyStack cdkd orphan MyStack/MyBucket # リソース1つだけstateから外す |
削除保護をまとめて外す（--remove-protection）
検証環境あるあるですが、RDSやDynamoDBに削除保護が付いていると、destroyはAWSのエラーで止まります。
保護されたリソースだけ残して他が消えるのではなく、そこで失敗します。コンソールで保護を外してから、もう一度destroyし直すことになります。
|
1 |
cdkd destroy MyStack --remove-protection |
削除する直前に削除保護を外してから消すので、CDKコードを直して再デプロイする手間が要りません。
結構危険なオプションなので、確認プロンプトのデフォルトが Y/n から y/N に変わるという細かい配慮がされています。
他にも --skip-final-snapshot があります。CDKのRDSのL2コンストラクトはデフォルトが SNAPSHOT なので、検証環境ならこれでdestroyが数分速くなります。
溜まったアセットを片付ける（cdkd gc）
cdkd bootstrap が作ったアセット用のS3バケットとECRリポジトリは、cdkd destroy では空になりません。
これを消すコマンドが cdkd gc です。
|
1 2 |
cdkd gc --older-than 30d --dry-run # 30日より古い未参照アセットを、消さずに一覧 cdkd gc --older-than 30d # 実際に消す |
デプロイ中のスタックが1つでもあるとgcは中断するので、実行はデプロイのない時間帯を選びます。
CDKアプリなしでstateを見る（cdkd state）
ここまでのコマンドは、手元にCDKのソースがあるのが前提でしたが、cdkd state 系だけは例外で、S3のstateバケットだけを見ます。
ソースが手元にないときや、synthに時間をかけたくないときに使えます。
|
1 2 3 4 5 6 7 |
cdkd state info # バケット名、リージョン、スキーマバージョン cdkd state list # スタックとリージョンの一覧 cdkd state list --tree # ネストスタックの親子ツリー cdkd state show MyStack # stateの中身 cdkd state resources MyStack # 論理ID、型、物理ID cdkd state destroy MyStack # CDKアプリなしでリソースごと削除 cdkd state orphan MyStack # stateの記録だけ削除 |
CloudFormationと行ったり来たり（import / export）
すでに cdk deploy で構築済みのスタックであっても、CloudFormationの管理下から外しAWSのリソースには影響を与えずに、cdkdの管理下に移すことができます。
これには cdkd import を使います。
|
1 |
cdkd import MyStack --migrate-from-cloudformation --yes |
元のCloudFormationスタックから論理IDと物理IDの対応を読み取って、全リソースをcdkdのstateに取り込みます。
そのうえで全リソースに Retain を入れて、元のスタックを削除します。これで cdkd deploy が使えるようになります。
そしてまた、CloudFormationの管理下に戻したくなったとしましょう。
ここで cdk deploy を実行しても戻りません。なぜなら元のスタックはもう消えていて、CloudFormationは新しいスタックとしてゼロから作ろうとするからです。そこで cdkd export を使います。
|
1 2 |
cdkd export MyStack --dry-run # 何が起きるかだけ確認 cdkd export MyStack |
ChangeSetType=IMPORT の変更セットを使って、既存のリソースをそのままCloudFormationの管理下に戻します。
成功するとcdkd側のstateは削除され、再度 cdk deploy で運用できるようになります。
cdkdを使う際の注意点
| 注意点 | 内容 |
|---|---|
| 本番利用は非推奨 | ドキュメントに開発とテスト向けだと明記されています。 |
| IAM権限 | cdkdを実行するIAMユーザーまたはIAMロールには、対象AWSサービスを直接操作する権限が必要です。継続利用する場合は、対象リソース・リージョン・操作を絞った最小権限を設計してください。 |
| 未対応のリソース | SDK ProviderまたはCloud Control APIで対応していないAWSリソースはデプロイできません。といっても元がCDKのソースなので実質ないのかも・・・ |
まとめ
AIによって高速にCDKコードを書けるようになった時代に、さっそうと現れた高速デプロイツール「cdkd」。
cdkdのコマンドを1つ1つ調べていくと、速いだけのツールではありませんでした。
本記事で紹介したコマンドは以下の通りです。
| やりたいこと | コマンド |
|---|---|
| デプロイを速くする | cdkd deploy（--no-wait / --full-wait で待機する範囲を変更） |
| 差分だけ先に見る | cdkd diff --fail / cdkd deploy --dry-run |
| デプロイせずローカルで動かす | cdkd local invoke / start-api（--from-cfn-stack / --from-state） |
| ドリフトを見つけて直す | cdkd drift（--accept / --revert） |
| 削除保護が付いていても消す | cdkd destroy --remove-protection |
| 溜まったアセットを消す | cdkd gc |
| ソースがなくても状態を見る | cdkd state list / show / resources |
| CloudFormationと行き来する | cdkd import --migrate-from-cloudformation / cdkd export |
CDKにおける開発を熟知している作者ならではのツールと言えるでしょう。
今後、対応リソースや運用面がどう広がるかにも目が離せません！
参考
| 参照先 | 内容 |
|---|---|
| cdkdのGitHubリポジトリ | cdkdのリポジトリ。READMEが非常に参考になりました |
| 既存の AWS CDK コードのまま、最大 15 倍速くデプロイできる『cdkd』を作った | 作者ご本人による紹介記事 |
| AWS CDK を「作」ってみた 〜フルスクラッチで見えた CDK の裏側〜 | AWS CDK Conference Japan 2026 の登壇資料 |
執筆者プロフィール
- TDI デジタルイノベーション技術部
-
昔も今も新しいものが大好き！
インフラからアプリまで縦横無尽にトータルサポートや新技術の探求を行っています。
週末はときどきキャンプ場に出没します。
2024-2026 Japan AWS All Certifications Engineer
2026 Japan AWS Top Engineer
