Posted on 2025-12-30 :: 3572 Words :: Tags: cdktf, terraform, infrastructure-as-code, migration, devops

CDKTF終了のお知らせ：さて、どうする？

思ったより早く終わってしまいましたね。

2025年12月10日、HashiCorpがCDKTF（Cloud Development Kit for Terraform）を完全停止しました。非推奨にしたというレベルではなく、同日中にリポジトリごとアーカイブ。猶予期間も移行計画もなく、いきなり「終了」です。

CDKTFでインフラを構築していた方、お疲れ様です。何が起きたのか、そしてここからどう脱出するか、一緒に見ていきましょう。

おさらい：CDKTFとは何だったのか

CDKTFは、HCLの代わりに普通のプログラミング言語でTerraformインフラを書けるようにしたHashiCorpの取り組みでした。コンセプトはシンプル：「YAMLは誰だって嫌いだし、HCLも制約が多い。だったらTypeScriptで書けばいいじゃん」というわけです。

// TypeScriptでのCDKTF
import { App, TerraformStack } from "cdktf";
import { AwsProvider } from "@cdktf/provider-aws";
import { Instance } from "@cdktf/provider-aws/lib/instance";

class MyStack extends TerraformStack {
  constructor(scope: Construct, name: string) {
    super(scope, name);

    new AwsProvider(this, "aws", { region: "us-west-2" });

    new Instance(this, "compute", {
      ami: "ami-123456",
      instanceType: "t3.micro",
      tags: { Name: "cdktf-instance" }
    });
  }
}

const app = new App();
new MyStack(app, "my-stack");
app.synth();

コードはTerraform JSONに「合成（synthesize）」されて、それをTerraformが実行する仕組みです。クラス、ループ、型チェック、全部使える。最高じゃないですか？

...まあ、そうでもなかったんですけどね。

実際に何が起きたのか

2025年12月10日：HashiCorpがCDKTFを非推奨に。同日：GitHubリポジトリをアーカイブ。

事前通知なし。移行期間なし。「重大なバグだけはあと1年サポートします」すらなし。ただアーカイブされただけ。リポジトリは読み取り専用になり、アップデート、バグ修正、セキュリティパッチ、すべて永久に停止です。

公式理由は？「CDKTFは十分なプロダクトマーケットフィットを達成できませんでした」

要するに：誰も使ってなかった。

正直、これは事実でしょう。2020年にリリースされたものの、CDKTFは一度も普及しませんでした。Terraformユーザーの大半はHCLに留まり、「本物のコードでインフラを書きたい」派の人たちは、もっと先行していて正直言って優れているPulumiを選んでいました。

HashiCorpは5つの言語（TypeScript、Python、Go、C#、Java）のバインディングを保守し、プロバイダーを更新し、すべてを同期させ続けていました。それも小さなユーザーベースのために。どこかで損切りしないといけなくなります。

なぜCDKTFは失敗したのか

はっきり言いましょう：CDKTFは最初から誰も求めていない中途半端な妥協案でした。

インピーダンスミスマッチ問題

Terraformは宣言的なツールです。「何が欲しいか」を書けば、Terraformが「どうやってそこに到達するか」を考える。これが価値の核心です。

CDKTFは、命令型プログラミングをこの宣言的モデルに無理やり押し込もうとしました。TypeScriptでループや条件分岐を書けるんですが、それが実行されるのはTerraformランタイムじゃなくて合成時。forループが期待通りに動かない理由をデバッグしてる人に、この仕組みを説明してみてください。

// 命令型に見えるが実際にはそうではない
const instanceCount = process.env.PRODUCTION === "true" ? 10 : 2;

for (let i = 0; i < instanceCount; i++) {
  new Instance(this, `server-${i}`, {
    ami: "ami-123456",
    instanceType: "t3.micro"
  });
}

このループ、いつ実行されるか分かりますか？Terraformが起動する前です。Terraformはどうやって状態変更を追跡するか？ぎこちなく、です。デバッグしたくなったら？TypeScriptのエラーとTerraformのエラー、両方と格闘することになります。

明確なメリットもないのに認知負荷だけ増える、という状況でした。

Pulumiがすでに勝っていた

TypeScriptやPythonで本気でインフラを書きたいなら、Pulumiが2017年からもっと良い形で実現しています。ネイティブな言語ランタイム、優れた型安全性、ちゃんと動くIDEのオートコンプリート、そして後付け感のないエコシステム。

CDKTFは、Pulumiがすでに勝っていた競争で後追いしていただけでした。Pulumiの方が同じことをもっと上手くやってるのに、なんでCDKTFを学ぶ必要があるんでしょう？

HashiCorpの本当の優先順位

HashiCorpが本気なのはHCP Terraform（クラウドプラットフォーム）です。Terraform Cloud、Enterprise機能、Sentinelを使ったポリシーアズコード。要するに、ユーザーを自分たちのエコシステムに囲い込んで離さない戦略です。

CDKTFはその戦略に合わなかった。邪魔だったんです。だから切られました。

移行オプション

暗い話はこの辺にして、本題です。本番環境でCDKTFを使ってる方、選択肢は実質3つ（あと1つは偽物）です。

オプション1：Terraform HCLに戻る

一番分かりやすい道です。CDKTFコードを普通のTerraform HCLとして書き直します。

朗報：HashiCorpは撤退する前に移行ツールを用意してくれました。これを実行しましょう：

cdktf synth --hcl

CDKTFコードから標準のTerraform HCLファイルを生成してくれます。完璧じゃないです。クリーンアップとリファクタリングは必要ですが、ゼロから書き直すよりはずっとマシな出発点になります。

移行イメージはこんな感じ：

// CDKTF
new Instance(this, "web", {
  ami: "ami-123456",
  instanceType: "t3.micro",
  tags: { Name: "web-server" }
});

# Terraform HCL（synthとクリーンアップ後）
resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

そう、生成されたHCLはリファクタリングが必要です。でも少なくともゼロスタートじゃありません。

メリット：Terraformエコシステムに残れる。HashiCorpの公式サポートあり。10万以上のコミュニティモジュールが使える。

デメリット：CDKTFで気に入ってたプログラミング言語の機能は失います。

オプション2：Pulumiに乗り換える

TypeScript/Pythonでインフラを書きたくてCDKTFを選んだなら、Pulumiが最初から選ぶべきだった正解です。

// Pulumi（TypeScript）
import * as aws from "@pulumi/aws";

const web = new aws.ec2.Instance("web", {
  ami: "ami-123456",
  instanceType: "t3.micro",
  tags: { Name: "web-server" }
});

export const publicIp = web.publicIp;

Pulumiは本物のコードみたいに感じます。実際に本物のコードだからです。本物のループ、本物の条件分岐、本物の型チェック。合成時の擬似プログラミングじゃありません。

移行の労力はHCLへの移行と同程度ですが、プログラミング言語の機能が大事なら、ずっと良いゴールに辿り着けます。

デメリット：Terraformエコシステムから完全に離脱。状態管理、ツール、価格モデル（Pulumi Cloudには階層制あり）、すべて別物です。

オプション3：AWS CDK（AWS専用の場合）

インフラが完全にAWSで、AWS CDKっぽい使い心地が理由でCDKTFを使ってたなら、HashiCorpは本物のAWS CDKへの移行を推奨しています。

AWS CDKは、TypeScript/Pythonを使うAWS独自の「Infrastructure as Code」ツールです。AWSネイティブで、サポートも充実、廃止の心配もありません。

意味があるのは以下の場合のみ：

100% AWS（GCP、Azure、その他のプロバイダーなし）
CDKTFでAWS CDK構成要素を既に使っていた
AWS専用インフラにコミットする覚悟がある

マルチクラウド構成ではほぼ無関係ですが、HashiCorpが言及してたので一応触れておきます。

オプション4：何もしない（推奨しません）

まあ...CDKTFを使い続けることもできます。コードは動きます。今は。

でも最終的に壊れるのはこんなところ：

新しいTerraformプロバイダーにCDKTFバインディングなし
既存のプロバイダーがアップデートして互換性が壊れる（修正するCDKTFアップデートはなし）
セキュリティ脆弱性がパッチされない
Node.js/Python/Goのバージョンが進んで依存関係が壊れる
クラウドプロバイダーのAPIが変わる

インフラはタイムリミット付きです。本番が午前2時に落ちるまで放置する人にはならないでください。

実際の移行方法

覚悟を決めて（HCLかPulumi）、この大まかなプランに従いましょう：

週1-2：全体を把握する

cdktf listとcdktf synthを実行して、実際に何があるか確認。スタック、リソース、依存関係を数える。複雑さについては正直に。

週3-4：小さく始める

一番シンプルなスタックを選ぶ。たぶんIAMロールか単一のS3バケットあたり。

HCLに移行する場合：そのスタックでcdktf synth --hclを実行、出力をクリーンアップして、テスト環境にデプロイ。

Pulumiに移行する場合：Pulumiで書き直す。テスト環境にデプロイ。

壊して、学ぶ。

週5-8：既存リソースをインポート

ここが退屈なパート。既存のインフラをTerraform状態（またはPulumi状態）にインポートする必要があります。

Terraformの場合：

terraform import aws_instance.web i-1234567890abcdef0
terraform plan  # "No changes"が出るはず

Pulumiの場合：

pulumi import aws:ec2/instance:Instance web i-1234567890abcdef0
pulumi preview  # 変更なしになるはず

週9-16：テスト、検証、切り替え

ステージングでテスト。もう一回テスト。メンテナンスウィンドウを予約。本番リソースをインポート。検証。CDKTF廃止。

週17-20：後片付け

CDKTFコードをアーカイブ（削除はしない）。ドキュメント更新。チームをトレーニング。CI/CDからCDKTF削除。

厄介な部分の対処法

CDKTFの動的機能をガッツリ使ってた場合、こうマッピングします：

ループ：

CDKTF：

for (let i = 0; i < 5; i++) {
  new Instance(this, `server-${i}`, { ... });
}

HCL：

resource "aws_instance" "server" {
  count = 5
  ami   = "ami-123456"
  # ...
  tags = { Name = "server-${count.index}" }
}

Pulumi（普通にループ使えばいい）：

const instances = [];
for (let i = 0; i < 5; i++) {
  instances.push(new aws.ec2.Instance(`server-${i}`, {
    ami: "ami-123456",
    instanceType: "t3.micro"
  }));
}

スタックの依存関係：

CDKTFは他のスタックを直接参照できました。HCLはリモート状態データソースを使う。Pulumiはスタック参照を使う。どっちも動きます、構文が違うだけ。

誰も聞かないけど聞くべきFAQ

Q：新規プロジェクトでCDKTF使っていい？

ダメです。正気ですか？

Q：CDKTFコード、すぐ壊れる？

すぐには壊れません。でも最終的には壊れます。来月プロバイダーが更新されるかも。来年Node.jsバージョンが変わるかも。明日AWSがAPIを変えるかも。ギャンブルしてるようなものです。

Q：コンバータツールはある？

あります。cdktf synth --hclがCDKTFコードからTerraform HCLを生成してくれます。出力はクリーンアップとリファクタが必要ですが、手動で全部書き直すよりずっとマシです。使いましょう。

Q：cdk8s（Kubernetes用CDK）は？

別プロジェクトで、まだ生きてます。CDKTFだけが終了しました。

Q：HCLとPulumi、どっち？

Terraformエコシステムに残りたくて新しい構文を学ぶのが平気ならHCL。プログラミング言語機能が本気で大事でツールを丸ごと変える覚悟があるならPulumi。どっちも良い選択です。

ここから学べること

CDKTFの終了が教えてくれる大事なこと：「好きな言語を使う」が常に正解とは限らない。

HCLが存在するのには理由があります。インフラには制約が必要だから、制約されてるんです。間違って無限ループなんて書けない。状態管理は予測可能。リソースの関係は明示的。Terraformは依存関係グラフを分析して最適化できる。

宣言的インフラツールにオブジェクト指向プログラミングを無理やり接ぎ木しようとしたら、解決するより多くの問題を生み出しました。抽象化レイヤーを追加しても、その複雑さに見合うメリットがありませんでした。

インフラにTypeScriptを使いたいなら、Pulumiを使いましょう。最初からそう設計されてます。Terraformが欲しいなら、HCLを使いましょう。両方欲しいってのが間違いでした。

今すぐやるべきこと

本番環境でCDKTFを使ってる方：

インフラを棚卸しする（どれくらいヤバい？）
移行先を決める（HCLかPulumi）
カレンダーに時間を確保する（勝手には終わりません）
重要度の低いものから移行を始める
期限を設定する（大抵の構成なら3〜6ヶ月が妥当）
実際に実行する（先延ばしにしない）

CDKTFはもうアーカイブ済みです。サポートなし、アップデートなし、パッチなし。待てば待つほど、本番が午前3時に壊れる日に近づいてます。

そういうチームにはならないでください。

参考リソース

公式情報：

分析記事とホットテイク：

env0: What the CDKTF Deprecation Means
Pulumi: CDKTF is Deprecated（露骨なバイアスあり）
The New Stack: HashiCorp Sunsets External Language Support

HCLに移行する場合：

私のTerraformチュートリアルシリーズ（ちゃんと学べるかも）
HashiCorp Learn

Pulumiに移行する場合：

お気持ち分かります。CDKTFを選んだのは、両方のいいとこ取りに見えたからですよね。TerraformエコシステムとTypeScript。2023年なら妥当な選択でした。

でもHashiCorpが終了させちゃった。今は前に進むしかありません。道を選んで、計画を立てて、実行を始めましょう。未来のあなたは、先延ばしにしなかった今のあなたに感謝するはずです。

頑張ってください。

更新日：2025-12-30

免責事項：この記事は公開情報とコミュニティの議論に基づく筆者の分析です。公式情報はCDKTFリポジトリをご確認ください。

目次