AWS CDK vs Terraform 2026年版 ― 現場での使い分け基準と、AIに書かせるならどちらか

このブログでは、DifyをApp Runnerに載せる記事も、ECSのオブザーバビリティ連載の3本も、インフラはTerraformで書いてきました。AWSしか使っていない構成なのに、なぜAWS CDKではないのか。自分でもきちんと言葉にしておきたかったので、2026年10月時点の公式情報で両者を比べ直しました。

どちらが優れているかを決める記事ではありません。「このプロジェクトならこちら」と判断するための軸を並べ、最後に、AIエージェントにIaCを書かせるならどちらが扱いやすいかという観点を足します。この1年で、比較の前提になる出来事がいくつも起きているので、まずそこから整理します。

2025〜2026年に何が変わったか

数年前の比較記事を読んで判断しようとしている人は、少なくとも次の変化を織り込んでください。日付はすべて公式の発表やリリースノートで確認したものです。

中でも影響が大きいのはCDKTFの終了です。「Terraformのエコシステムは使いたいが、HCLではなくTypeScriptで書きたい」というチームの受け皿がなくなりました。公式の案内では、cdktf synth --hcl でHCLを書き出してTerraformに移るか、AWS CDKへ移るかが挙げられています。2026年のこの比較は、事実上「AWS CDK（＝CloudFormation）か、Terraform／OpenTofuか」の二択になっています。

思想の違い：コードを「実行」するか、宣言を「比較」するか

図：CDKとTerraformの処理の流れ

AWS CDKは、TypeScriptやPythonで書いたプログラムを cdk synth で実行し、その結果としてCloudFormationのテンプレートを出力します。実際にAWSへ変更を加えるのはCloudFormationです。かなり雑に言うと、CDKは「CloudFormationのテンプレートを生成するプログラムを書く道具」です。

Terraformは、HCLで「こうなっていてほしい」という状態を宣言します。terraform plan が宣言と、前回の結果を記録したstateファイルと、実際のリソースを比べ、差分を埋めるためのAPI呼び出しをproviderが行います。

この違いは、運用でいくつかの差になって表れます。

• 状態を誰が持つか: CDKはCloudFormationのスタックとしてAWS側が持つ。Terraformはstateファイルを自分で管理する（S3に置くのが一般的で、Terraform 1.11からはDynamoDBなしでS3だけでロックできる）
• 失敗したとき: CloudFormationは既定で変更前に自動ロールバックする。Terraformは途中まで作られたリソースがそのまま残り、次の plan で続きから直す
• 扱える範囲: CDKはCloudFormationが対応しているAWSリソース（とカスタムリソース）。Terraformはproviderがあれば、Datadog、GitHub、Cloudflareなども同じ書き方で扱える

2つ目の差は、私も実際に経験しています。Dify on App Runnerの記事に書いた「ハマりポイント❾」がそれで、ECRにコンテナイメージをpushする前に terraform apply を流したところ、App RunnerのサービスがCREATE_FAILEDのまま残り、再デプロイもできなくなりました。結局 -target で該当リソースだけdestroyし、イメージをpushしてから作り直しています。CloudFormationなら失敗時点でスタックごと巻き戻されるので、同じ状況でも後始末の手間は違ったはずです。どちらが良いというより、「失敗したらどの状態で止まるか」が違う、と理解しておくのが大事です。

比較表：10の軸で見る

表にすると差が小さく見える軸もありますが、実際に効いてくるのは「状態管理」「差分の確認」「AWS以外の管理」の3つだと考えています。

CDKが向くケース

• AWSしか使わず、アプリ開発者がインフラも書くチーム: アプリと同じTypeScriptで書け、同じエディタの補完と型チェックが効く
• Lambda中心のサーバーレス構成: Lambda関数、API Gateway、DynamoDB、権限を、L2コンストラクトで数行ずつ書ける。IAMポリシーを table.grantReadData(fn) のように書けるのは、手書きのポリシーより間違いが少ない
• stateファイルの管理を持ちたくない: バックエンドの設計、ロック、state内の秘密情報の扱いをAWSに任せられる
• 失敗時に自動で元に戻ってほしい: 本番の変更で中途半端な状態が残るのを避けたい場合

注意点もあります。CDKのコードが短く書けるのは、裏でたくさんのリソースが生成されているからです。L3コンストラクト1行で、セキュリティグループやIAMロールを含む十数個のリソースができることもあります。「コードは読めたが、何が作られるかは cdk diff を見るまで分からない」という状態は、レビューする側の負担になります。

Terraformが向くケース

• AWS以外も一緒に管理したい: 監視SaaS、DNS、GitHubのリポジトリ設定などを、同じ plan と apply の流れで扱える
• インフラ専任チームが plan の差分をレビューする文化がある: 変更がリソースと属性の単位で出るので、レビューする人が見るべき場所がはっきりしている
• マルチクラウド、または将来その可能性がある
• 既存のリソースを後からコード化したい: import ブロックに加え、1.14の terraform query で既存リソースを探して取り込み用の設定まで生成できる（対応リソースは順次拡大中）

このブログでTerraformを選んできた一番の理由は、1つ目です。Datadog編では、ECSの構成と一緒に、Datadogのモニター9個とSLO 2個、AWS連携の設定までTerraformで書いています。インフラの変更と監視の変更が同じプルリクエストに並ぶので、「サービスを足したのに監視を足し忘れた」がレビューで見つかります。CDKでは、ここまでを1つのツールで扱うのは難しいと思います。

一方で、同じ記事では「DatadogのAPIキーをTerraformの変数に平文で渡すと、stateに平文で残る」という注意も書きました。stateを自分で持つというのは、そこに入る秘密情報の管理も自分の責任になる、ということです。Terraform 1.10のephemeral resources、1.11のwrite-only属性で、秘密情報をstateに残さずに渡す方法がそろってきたので、新しく書くならこちらを使うのが安全です。

TerraformとOpenTofu、どちらにするか

ライセンスを気にする場合や、IBMの方針に左右されたくない場合はOpenTofuがあります。2026年9月末にOpenTofu 1.13、10月初めにTerraform 1.16.5が出ていて、ephemeral／write-onlyやS3のネイティブロックなど、主な機能はほぼ同時期にそろっています。社内で使う分にはBUSLで困ることはまずないので、私は「HCP Terraformを使うならTerraform、使わずにOSSで固めたいならOpenTofu」くらいの基準で十分だと考えています。

AIエージェントにIaCを書かせるなら

ここからは、比較記事ではあまり扱われない観点です。IaCをAIエージェントに書かせる場面は、すでに珍しくありません。私のClaude Codeの環境にも、HashiCorpのTerraform MCPサーバーを入れてあります。道具がそろってきたところで、どちらのツールのほうが事故を起こしにくいかを考えます。

レビューするのは「コード」ではなく「差分」

AIが書いたIaCで一番怖いのは、書かれたコードが正しいかどうかより、実行したら何が起きるかを人が把握しないまま適用されることです。だから、人がレビューする対象は、コードではなく、適用前の差分であるべきです。

この点で、Terraformの plan は扱いやすい出力です。変更されるリソースと属性が、追加・変更・削除・作り直しの区別つきで並びます。特に「作り直し（replace）」が表示されるので、データベースが作り直されるような危険な変更に気づけます。

CDKでも同じことはできます。ただし、レビューするのはTypeScriptのコードではなく、cdk diff の出力か、change setです。AIが書いたCDKのコードは、短く、読みやすく、それらしく見えます。その「読めてしまう」感じが、生成されるリソースの確認を省かせる方向に働きやすい、というのが私の懸念です。2025年11月からは、change setが実リソースのドリフトも考慮するようになったので、本番ではchange setを作って中身を確認してから実行する流れにしておくと安心です。

表現力が高いことは、AIにとって必ずしも利点ではない

CDKはプログラミング言語なので、synthの時に環境変数を読んだり、外部APIを呼んだりする処理も書けてしまいます。AIは、頼んでいない便利な処理を書き足すことがあります。HCLは書ける範囲がもともと狭いので、AIの出力が想定外の方向に広がりにくい。これは、人間が書く場合には制約でしかありませんが、AIに書かせる場合には安全側に働きます。

公式のMCPサーバーと、その使い方

道具は両陣営ともそろってきました。

• Terraform MCP Server（HashiCorp、2026年6月GA）: レジストリからproviderやモジュールの情報を引ける。HCP Terraformのワークスペースを操作するツールは既定で無効になっていて、READMEでも出力を必ずレビューするよう求めている
• AWS IaC MCP Server（AWS、2025年11月公開）: CDKとCloudFormation向け。ローカルで動き、cfn-lintやcfn-guardによる検証、CloudTrailを使ったデプロイ失敗の調査など、読み取り専用の支援が中心

2026年4月には、AWSが以前公開していたCDK用、CloudFormation用、Terraform用のMCPサーバーが削除されています。古い記事の手順でMCPサーバーを入れようとしている場合は、上の2つに置き換えてください。

AWSは2026年7月に、AIコーディングエージェントを統制するための考え方を公開しています。IaCに関係するのは次の点です。

• デプロイ前にIaCのスキャンを行う（CloudFormation、Terraform、CDKのどれでも）
• エージェントには、開発者本人とは別の、最小権限の専用クレデンシャルを渡す
• ツール呼び出しをすべて自動承認にしない。影響の大きい変更には人の承認を挟む

実務に落とすなら、エージェントに許すのは terraform plan や cdk diff、change setの作成までにして、apply や deploy は人が差分を見てから実行する、という線引きが現実的です。CloudFormationのExpress modeはロールバックが既定で無効なので、エージェントの作業で本番に使わせないほうがよいでしょう。

結論：AIに書かせるならどちらか

差分の読みやすさと、書ける範囲の狭さという2点で、私はTerraformのほうがAIに書かせやすいと考えています。ただし、CDKでも「レビューはchange setで行う」と決めておけば、同じ水準の安全性は作れます。ツールの選択より、エージェントに何を許すかの線引きのほうが、事故の起きにくさに効きます。エージェントの権限設計そのものは、ガードレール設計の記事に詳しく書いています。

判断の順番

迷ったときは、次の順に考えると、たいていどちらかに決まります。

1. AWS以外のサービスもコードで管理したいか。はい、ならTerraform（またはOpenTofu）
2. インフラを書くのはアプリ開発者か、インフラ専任か。アプリ開発者が中心で、AWSだけならCDKが書きやすい
3. stateファイルを管理する体制があるか。持ちたくないならCDK
4. すでにある資産と、チームが読み慣れている差分はどちらか。レビューする人が慣れている形式を優先する
5. CDKTFを使っていたか。使っていたなら、HCLに書き出してTerraformへ移るか、AWS CDKへ移るかを早めに決める

おわりに

このブログでTerraformを使ってきたのは、AWSと監視SaaSを同じ流れで管理したかったからで、CDKが劣っているからではありません。AWSだけで完結し、アプリ開発者がインフラも書くチームなら、私もCDKを勧めます。

2026年に変わったのは、どちらのツールも「AIが書き、人が差分を見て承認する」という使い方を前提にし始めたことです。どちらを選ぶ場合でも、人が何を見て承認するのかを、最初に決めておいてください。

※本記事のバージョン・機能・料金は2026年10月時点の公開情報に基づいています。Terraform 1.17とTerraform Policy、cdk refactor は執筆時点で正式版ではないため扱っていません。

参考

• Terraform Releases（GitHub）
• CDK for Terraform（Sunset Notice）
• New Terraform and Packer features at HashiConf 2025
• HCP Terraform enhanced free tier
• Terraform MCP Server is now generally available
• Terraform AWS Provider v6.0.0
• OpenTofu - CNCF
• AWS CloudFormation 2025 Year in Review
• CloudFormation drift-aware change sets
• CloudFormation / CDK Express mode
• cdk drift - AWS CDK Developer Guide
• Introducing the AWS Infrastructure as Code MCP Server
• A control framework for AI coding agents - AWS Security Blog