CDK for Terraform（CDKTF）とは？提供終了後の移行判断を解説

CDK for Terraform（CDKTF）は、TypeScriptやPythonといった汎用プログラミング言語でインフラを記述し、Terraformが読める構成ファイルへ変換する仕組みです。ただし2026年8月時点で、この製品はすでに提供が終了しています。HashiCorpは2025年12月10日付でCDKTFを非推奨とし、GitHubのリポジトリも同日アーカイブされました。この記事では、CDKTFがどうやってTerraformと接続していたのかという仕組みの側面と、いま手元に残っているCDKTFのコードをどう畳むかという実務判断の両方を扱います。三者比較の相手はAWS CDKとPulumiです。

まとめ：新規採用は見送り、既存資産は撤退期限つきで扱う

結論は2つです。新規プロジェクトでCDKTFを選ぶ理由は、2026年8月時点で残っていません。保守が止まったツールにインフラ定義という長寿命の資産を預ける形になるためです。

すでにCDKTFで組んだ環境がある場合は、即日の作り直しまでは不要とみます。CDKTFの生成物はTerraformが解釈できるJSON構成ファイルであり、Terraform本体が動く限り既存環境の管理そのものは継続できるからです。ただし期限は切ってください。プロバイダーの新バージョンやTerraformの新機能に追随できない時点が必ず来ます。

移行先は、標準のHCLへ戻す・AWS CDKへ寄せる・Pulumiへ移す、の3案に整理できます。マルチクラウドでTerraformプロバイダーの資産を残したいならHCL、対象がAWSに閉じているならAWS CDK、プログラミング言語での記述をどうしても続けたいならPulumiです。判断の分岐点と工数の目安は後半で具体的に示します。

CDKTFがTerraform JSONを生成する仕組みとjsii由来の制約

まず仕組みから押さえます。ここを誤解したまま移行計画を立てると、工数見積もりが大きくずれます。

cdktf synthが出力するcdk.tf.jsonの中身とHCLとの差

CDKTFの解説では「コードからHCLを生成する」と書かれることがありますが、公式のアーキテクチャ文書が示す実際の生成物はHCLではありません。cdktf synthが出力するのは、Terraformが受け付けるJSON構成ファイル（cdk.tf.json）です。TerraformはHCLとJSONの両方の構文を解釈できるため、この方式で成立していました。

この差は移行時に効いてきます。生成されたJSONは人間が読み書きする前提の成果物ではないため、リソース名やブロックの並びが機械的で、コメントも残りません。「synth結果をそのままHCLに変換すれば移行完了」という見通しは、実際には成り立ちにくいということです。

実行フローは、コードを書き、cdktf synthで構成ファイルへ変換し、cdktf diffやcdktf deployで適用する流れでした。差分の読み方そのものはTerraformのterraform planの差分の読み方とinit・apply・destroyの安全手順と同じ考え方が通用します。

jsiiによる5言語対応とTypeScript以外での型情報の欠落

CDKTFが5言語に対応できたのは、AWS CDKと同じjsiiというポリグロット基盤を使っていたためです。TypeScriptで書かれた単一のコードベースから、Python・Java・C#・Goの各言語向けライブラリを生成する仕組みになっています。

裏返すと、一次言語はTypeScriptでした。型情報や補完の効き方、エラーメッセージの分かりやすさは、TypeScript以外の言語では一段落ちます。Pythonで書いていたチームがランタイムエラーの原因を追う際、スタックトレースがjsiiの層をまたいで読みにくくなる、という詰まり方が起こりえます。移行判断の際は、この「一次言語かどうか」の差を工数に織り込んでください。

プロバイダーバインディング自動生成の待ち時間と依存関係の膨張

CDKTFはTerraformプロバイダーやモジュールのスキーマを読み取り、型付きのコードバインディングを自動生成します。Terraformが対応しているリソースはおおむね扱えた、という広さはここから来ています。

代償は初期化時間と依存関係の量でした。AWSプロバイダーのように定義数が多いプロバイダーでは、バインディング生成に相当の時間がかかります。CIで毎回生成し直す構成にすると、パイプラインの待ち時間がそのまま伸びます。生成物をコミットする運用に切り替えるチームが多かったのは、この事情によるものです。

2025年12月10日のアーカイブで確定した保守停止の影響範囲

次に、提供終了が実務に何をもたらすかを切り分けます。「使えなくなった」という言い方は正確ではありません。

アーカイブ後に止まるバグ修正とセキュリティ更新の具体的な範囲

HashiCorp Developerの告知は「CDK for Terraformは2025年12月10日をもって非推奨であり、HashiCorpはサポートも保守も行わない」と明記しています。GitHubのリポジトリには「2025年12月10日にオーナーによってアーカイブされました。現在は読み取り専用です」という表示が出ています。

止まるのは、バグ修正・セキュリティパッチ・新しいTerraform版やプロバイダー仕様への追随です。コードは公開されたまま残り、npmなどに公開済みのパッケージも消えるわけではありません。つまり、いま動いているCDKTF環境が明日壊れることはないが、外側の周辺環境が変わったときに直す人がいない状態、と理解するのが正確です。

v0.21系で凍結された依存とTerraform新版への追随不能

公式のリリースページは、2026年8月時点でv0.21系をlatestとして表示しています。1.0に到達しないまま開発が終わった、という点は判断材料になります。

実務で先に効くのは、CDKTFが内部で参照するTerraform CLIやプロバイダー側の変更です。プロバイダーのメジャーバージョンが上がって引数の構造が変わった場合、バインディング生成側が新仕様を正しく扱えなくなる可能性があります。そのときに修正を投げるべき上流がもう存在しません。Terraform本体の新機能を使いたいなら、CDKTFの層を外す以外の選択肢はなくなります。

稼働中の既存プロジェクトが動き続ける期間と壊れ始める具体的な引き金

「いつまで持つか」を年数で言い切ることはできません。代わりに、壊れ始める引き金を具体的に挙げます。

• プロバイダーのメジャーバージョンアップで、既存バインディングが生成できなくなる
• Node.jsのサポート終了で、CDKTF CLIが動く実行環境をCIで用意できなくなる
• 依存パッケージに脆弱性が見つかり、上流で修正されないまま監査に引っかかる
• 新規メンバーが入り、保守されていないツールの学習コストを払う判断ができなくなる

優先度としては、実務でまず来るのが2番目の実行環境の問題です。プロバイダーはバージョンを固定して逃げられますが、CIランナーのイメージ更新は自社都合だけでは止められません。棚卸しの起点はここに置いてください。

CDKTF・AWS CDK・Pulumiの提供状況と言語対応の比較表

移行先を決める前に、三者が何を土台にしているのかを揃えて見ます。表面的な「プログラミング言語でインフラを書ける」という共通点の下で、実行基盤がまったく違います。

CDKTF・AWS CDK・Pulumiの実行基盤と状態管理の差

表で最も効くのは「実行基盤」の行です。CDKTFはTerraformの上に乗る薄い層でしたが、AWS CDKはCloudFormation、Pulumiは独自エンジンと、下回りがそれぞれ別物です。移行とは記述言語の乗り換えではなく、状態管理の乗り換えである、と捉えたほうが見積もりを外しません。IaC全体の考え方はIaCとはInfrastructure as Codeの仕組みと導入判断で整理しています。

AWS CDKがAWS専用にとどまる理由とマルチクラウドの限界

AWS CDKはCloudFormationテンプレートを生成し、CloudFormationが実際のリソースを作ります。この構造上、対象はAWSのリソースが中心です。CloudFormationのカスタムリソースを噛ませれば他社サービスも扱えますが、常用する設計ではありません。

したがって、CDKTFでAWS以外のプロバイダー（DatadogやGitHub、Cloudflareなど）も管理していたなら、AWS CDKへの一括移行は成立しません。CloudFormation側の制約、たとえばスタックあたりのリソース数上限やロールバック挙動の違いも引き継ぐことになります。仕組みの詳細はAWS CDKの仕組みとCloudFormation・Terraformとの違いを参照してください。

Pulumiが有償SaaS前提となる料金構造と自前運用の選択肢

Pulumiは、記述言語の自由度という点でCDKTFに最も近い移行先です。ただし状態管理の既定がPulumi Cloudというホスト型サービスで、規模が大きくなると課金が発生します。セルフマネージドのバックエンドを選べばオブジェクトストレージ上で状態を持てますが、その場合はロックやチーム機能の一部を自前で組む前提になります。

もう一点、Pulumiは独自エンジンでクラウドAPIを直接呼ぶ仕組みです。tfstateからPulumiの状態への移行は、リソースを作り直さずに取り込むインポート作業が主戦場になります。読み方・言語・料金の詳細はPulumiの読み方と言語・Terraformとの違い・料金にまとめています。

稼働中のCDKTF資産で選べる移行先3案と工数の見積もり手順

ここからは実務です。どの案でも、最初にやることは共通しています。現行のCDKTFプロジェクトでcdktf synthを実行し、生成されたJSONに含まれるリソースを数えてください。この件数が全案の工数のベースになります。

案1：cdktf synth出力をHCLへ書き戻す手作業の工数

最も素直な案です。JSON構成ファイルはTerraformがそのまま解釈できるため、いったんJSONを正とした状態でTerraform CLIだけで運用を継続し、そのうえで人間が読めるHCLへ書き直していきます。tfstateはそのまま引き継げるので、リソースの再作成は発生しません。

工数の当て方は、リソース種別数に比例させるのが実感に近いやり方です。同じ種別のリソースが100個あっても書き方は1通りなので、件数より種別数が効きます。書き直しの際は、CDKTF側でループやクラスとして表現していた部分を、moduleやfor_eachへ置き換える設計判断が必要です。分割の粒度はTerraform moduleの分割粒度とoutput設計の考え方をそのまま当てられます。

この案の注意点は1つです。書き戻したHCLと既存tfstateの対応が崩れると、planに削除と作成が並んで出ます。移行中はplanの差分がゼロであることを毎回確認してから進めてください。

案2：AWS CDKへ寄せる条件とCloudFormation差の吸収

対象リソースがAWSに閉じており、かつアプリケーション側でも既にAWS CDKを使っているなら、こちらに寄せる意味があります。言語と構成の型（Construct）がそろい、リポジトリの構成も一本化できます。

ただし実行基盤がCloudFormationに変わるため、tfstateは捨てることになります。既存リソースを壊さずに移すには、CloudFormationのリソースインポートで1つずつ取り込む必要があり、ここが最大の工数です。インポートに対応していないリソース種別があれば、その部分だけTerraformに残すハイブリッド構成になります。管理境界が2つに割れるので、AWS以外のプロバイダーを1つでも使っているなら案2は選びません。

案3：Pulumiへ移す場合の状態管理の移設手順と費用の増分

プログラミング言語での記述を続けたい、という要件が最優先なら案3です。手順は、Pulumiプロジェクトを新規作成し、既存リソースをインポートして状態に取り込み、生成されたコードを整えていく流れになります。

費用面は事前に確認してください。Pulumi Cloudを使う場合、管理リソース数に応じた課金となるため、リソースが数千規模になると年間コストが無視できません。セルフマネージド構成にすればその費用は避けられますが、状態ファイルの保護とロックの設計を自前で持つことになります。判断は「言語での記述をどれだけ手放したくないか」の一点で行い、そこが弱い要件なら案1に落としたほうが総コストは下がります。

移行を急がない場合の凍結運用とリスクを受け入れる線引きの条件

4つ目の選択肢として、当面は凍結して動かし続ける運用があります。これを選んでよいのは、次の条件をすべて満たす場合です。対象環境が今後大きく変わらないこと、プロバイダーのバージョンを固定できること、CI実行環境を自社で固定できること、そして撤退期限を決めてあること。

期限を決めていない凍結は、単なる先送りです。実務では「次の大きな構成変更が必要になった時点」を期限に設定するのが運用しやすいやり方になります。凍結中はプロバイダーとCDKTFのバージョンをロックファイルで固定し、状態ファイルの扱いはtfstateの構造とS3バックエンド・移動削除の安全手順に沿って通常のTerraform運用と同じ水準を保ってください。

新規プロジェクトでCDKTFを見送る判断条件と例外的に残す場面

ここで判断を言い切ります。玉虫色の結論は、この主題では読者の役に立ちません。

新規開発でCDKTFを選ばない具体的な理由とHCL標準へ戻す判断

2026年8月時点で新規にCDKTFを採用するのは、見送りが正解です。理由は保守停止そのものよりも、インフラ定義の寿命にあります。アプリケーションコードは書き換えが前提ですが、インフラ定義は5年、10年と残ります。その資産を、修正の投げ先がないツールの上に置く判断は割に合いません。

「HCLの学習コストを避けたい」という当初の動機は、いま満たすなら別の手段を取ります。HCL自体の記述量が問題ならmoduleでの共通化が先ですし、ライセンス面の懸念が動機ならOpenTofuとTerraformのライセンス・機能差と移行判断という別の選択肢があります。言語の好みでツールを選ぶより、チームが5年後も直せる状態を優先してください。

例外的にCDKTFを残してよい2つの条件と撤退期限の具体的な切り方

例外は2つだけ認めます。1つは、寿命が明確に短い環境です。1年以内に廃止が決まっている検証環境やキャンペーン用基盤なら、既存のCDKTFコードを流用するほうが速い場面はあります。もう1つは、既存の大規模なCDKTF資産に対する小さな追加変更です。1リソース追加のために移行を先行させる必要はありません。

いずれの場合も、期限を数値で書き残してください。運用ドキュメントに「この構成は2027年◯月までに撤退」と1行入れるだけで、判断の再検討が起きます。逆に、恒久運用する基幹システムのインフラをCDKTFで新規に書き始めることは、条件を問わず推奨しません。

受託開発でCDKTF案件を引き継ぐ際の見積もりと合意すべき事項

他社が構築したCDKTF環境を引き継ぐ場面では、着手前に3点を合意しておくと後の紛糾を避けられます。生成されたJSONと実環境の差分がゼロであること、tfstateの所在とバックアップ体制、そして移行までの暫定期間の責任範囲です。

特に1点目は最初に実測してください。CDKTF経由の管理が長く放置されていた環境では、コンソールでの手作業変更が入っていて差分が出るケースも想定範囲です。この確認を飛ばすと、移行作業中に意図しない変更が適用される事故の原因です。一創ではAWS・Google Cloud・Azureのインフラ構築として、既存IaC資産の棚卸しから移行、移行後の運用体制づくりまで対応しています。CDKTFで組まれた環境の引き継ぎや、HCLへの書き戻し設計もご相談いただけます。

よくある質問

CDK for Terraformの提供終了と移行について、実装者から実際に挙がる質問をまとめます。

CDK for TerraformとTerraform CDKは同じものですか？

同じものです。正式名称はCloud Development Kit for Terraformで、略称としてCDKTF、通称としてTerraform CDKやterraform cdkという呼び方が混在しています。検索する際はどの表記でも同じ製品にたどり着きます。なお、AWSが提供するAWS CDKとは別製品です。両者はjsiiという共通の基盤技術を使っているため構文が似ていますが、開発元も実行基盤も異なります。

CDKTFはいつ、なぜ提供終了になったのですか？

HashiCorpが2025年12月10日付で非推奨とし、同日にGitHubリポジトリをアーカイブしました。公式には、期待した規模での定着に至らず、Terraform本体とそのエコシステムへ投資を集中させる判断だと説明されています。バージョンはv0.21系が最後の系列で、1.0に到達しないまま開発が終了しました。コード自体は読み取り専用で公開が続いています。

CDKTFで作った環境は今すぐ作り直す必要がありますか？

即時の作り直しは不要です。CDKTFの生成物はTerraformが解釈できるJSON構成ファイルであり、tfstateも通常のTerraformと同じ形式のため、Terraform CLIだけで既存環境の管理を続けられます。まずcdktf synthで構成ファイルを生成し、それをリポジトリに保存してTerraform CLI運用へ切り替えるのが、最も安全な初手になります。そのうえで撤退期限を決め、HCLへの書き戻しを計画的に進めてください。

CDKTFはHCLを生成するのではないのですか？

HCLではありません。公式のアーキテクチャ文書によれば、生成されるのはTerraformが受け付けるJSON構文の構成ファイルです。TerraformはHCLとJSONの両方を解釈できるため、この方式が成立していました。移行の際、synth結果をそのまま人間が読むHCLとして流用できると考えると見積もりを外します。JSONは機械生成前提の成果物で、コメントも残らないためです。

移行先はHCL・AWS CDK・Pulumiのどれを選ぶべきですか？

管理対象がAWS以外のプロバイダーを含むなら、標準のHCLへ戻す案が第一候補です。tfstateをそのまま引き継げるため、リソースの再作成が発生しません。対象がAWSに閉じており、既にAWS CDKを社内で使っているならAWS CDKへの統合に意味があります。プログラミング言語での記述をどうしても続けたい場合のみPulumiを検討してください。後者2案は状態管理の移設を伴うため、工数はHCL案より大きくなります。

関連記事

• IaCとは？Infrastructure as Codeの仕組み・メリットと導入判断を解説：CDKTFが乗っていたIaCという考え方そのものを、導入判断の観点から整理しています。
• AWS CDK（cdk）とは？仕組み・使い方とCloudFormation・Terraformとの違い：移行先候補の案2について、CloudFormationとの関係と使い方を詳しく扱っています。
• Pulumiとは？読み方・言語・Terraformとの違い・料金を解説：移行先候補の案3について、料金体系と状態管理の実装を確認できます。
• Terraform stateとは？tfstateの構造とS3バックエンド・移動削除の安全手順：移行中に触ることになる状態ファイルの安全な扱い方をまとめています。
• HCP Terraformとは？旧Terraform Cloudの料金・機能とHCPでの位置づけ：HCLへ戻した後のチーム運用基盤として検討できる選択肢です。