AWSへの爆速デプロイだけじゃない。cdkdのコマンドをまとめて試す

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バケットで管理しています。

あとは cdk を cdkd に置き換えるだけで、CDKのコードには手を入れずに使用できるので、これまでと同じようにCDKによる開発ができるわけです。

後藤さんご本人も、紹介記事で「AWS CDK CLIを置き換えるものではなく、補完するもの」と書いています。
開発中はcdkdで素早くデプロイして、本番は本家のCDK CLIに任せるのがよさそうです。

普段づかいのコマンド（synth / deploy / diff / destroy）

普段使うコマンドは、本家のCDK CLIとほぼ同じなので戸惑いません。

デプロイ途中で失敗した場合は、本家のCDK CLIと同様に作成・変更したリソースをロールバックする仕組みを持っています。
ただし、CloudFormationのロールバックと完全に同一の挙動・保証であるとは限らない点はご注意を。

--no-rollback を付ければ、ロールバックせず途中の状態を残せます。あとから戻したくなったときのために cdkd rollback もあります。

DynamoDB、Lambda、API Gatewayだけの小さなスタックで試したところ、初回デプロイは29.22秒で完了しました。

リソースの依存関係を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まで、ローカルで動かせます。

ローカル実行でエラーになりがちなのが、他のリソースを参照している環境変数です。

たとえば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）

どちらのフラグも付けないと、警告が出るだけで、その環境変数は渡りません。
さきほどの構成をcdkdでデプロイして、フラグなしで試したらこうなりました。

--from-state を足すと、tableName に実際のテーブル名が入ります。

start-api は、どのパスがどのLambdaにつながるかをCDKアプリから読み取って、そのままローカルにHTTPサーバーを立てます。

つまり、デプロイは cdk deploy のままで、ローカル実行のためだけにcdkdを入れることもできます。
local start-cloudfront は、CloudFront FunctionsとS3オリジンだけならDockerも要らず、ルーティング関数の修正を数秒で確認できます。

ずれを見つけて直す（cdkd drift）

CloudFormationのドリフト検出は、テンプレートに書いたプロパティだけを見ます。
cdkdはこれと違って、デプロイした時点のAWS側の状態を記録しておき、今の状態と突き合わせるので、テンプレートに書いていない設定をコンソールで変えたときも差分として出ます。

--dry-run を付ければ、stateやAWSリソースを変更せずに、実行予定の解決内容を確認できます。

消す、片付ける（destroy / orphan / gc）

destroy はAWSのリソースとstateの記録を両方削除し、orphan はstateの記録だけを消してAWSのリソースは残します。

削除保護をまとめて外す（--remove-protection）

検証環境あるあるですが、RDSやDynamoDBに削除保護が付いていると、destroyはAWSのエラーで止まります。
保護されたリソースだけ残して他が消えるのではなく、そこで失敗します。コンソールで保護を外してから、もう一度destroyし直すことになります。

削除する直前に削除保護を外してから消すので、CDKコードを直して再デプロイする手間が要りません。
結構危険なオプションなので、確認プロンプトのデフォルトが Y/n から y/N に変わるという細かい配慮がされています。
他にも --skip-final-snapshot があります。CDKのRDSのL2コンストラクトはデフォルトが SNAPSHOT なので、検証環境ならこれでdestroyが数分速くなります。

溜まったアセットを片付ける（cdkd gc）

cdkd bootstrap が作ったアセット用のS3バケットとECRリポジトリは、cdkd destroy では空になりません。
これを消すコマンドが cdkd gc です。

デプロイ中のスタックが1つでもあるとgcは中断するので、実行はデプロイのない時間帯を選びます。

CDKアプリなしでstateを見る（cdkd state）

ここまでのコマンドは、手元にCDKのソースがあるのが前提でしたが、cdkd state 系だけは例外で、S3のstateバケットだけを見ます。
ソースが手元にないときや、synthに時間をかけたくないときに使えます。

CloudFormationと行ったり来たり（import / export）

すでに cdk deploy で構築済みのスタックであっても、CloudFormationの管理下から外しAWSのリソースには影響を与えずに、cdkdの管理下に移すことができます。
これには cdkd import を使います。

元のCloudFormationスタックから論理IDと物理IDの対応を読み取って、全リソースをcdkdのstateに取り込みます。
そのうえで全リソースに Retain を入れて、元のスタックを削除します。これで cdkd deploy が使えるようになります。

そしてまた、CloudFormationの管理下に戻したくなったとしましょう。

ここで cdk deploy を実行しても戻りません。なぜなら元のスタックはもう消えていて、CloudFormationは新しいスタックとしてゼロから作ろうとするからです。そこで cdkd export を使います。

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 の登壇資料