2026 年 5 月 30 日、Zenn に CDKをやめてTerraformに移行しようか迷っている話 vol.1 が公開され、SNS とエンジニアコミュニティで大きな議論になりました。記事の論点は、AWS CDK / CloudFormation で構築した資産が大きくなるほど、CDK 固有のクセ（synth コスト・ドリフト・チーム間の TypeScript 習熟差・スタック分割の難しさ）が運用負債化しているという、現場の率直な悩みです。同時期、OpenTofu 1.12 / Pulumi / cdktf / Atlantis / Spacelift などの周辺ツールが成熟し、マルチクラウド前提の中堅企業では「CDK を一部残しつつ Terraform/OpenTofu を中核に据える」という現実解が広がりつつあります。
受託で中堅企業の クラウド基盤 / SRE / プラットフォームチームを支える立場では、これは 「CDK か Terraform か」の二択論争ではなく、「どの資産をどの IaC に寄せるか」を判断する標準化フェーズに入ったことを意味します。これまで OpenTofu 1.12 Terraform 移行受託（GH Media） で扱った ライセンス対応 + ガバナンス、AWS Interconnect マルチクラウド受託（GH Media） で扱った マルチクラウド前提のネットワーク設計、AWS DevOps Agent マルチクラウド AIOps（GH Media） で扱った 横断運用と接続して、「IaC 標準化移行」を 受託パッケージとして整理します。
なぜ「CDK→Terraform 判断が分水嶺」なのか
| 観点 | CDK 単独運用（〜2025 のデフォルト） | Terraform / OpenTofu 標準化（2026 標準） |
|---|---|---|
| 対象クラウド | AWS 中心 | AWS + GCP + Azure + SaaS |
| 記述言語 | TS / Python（開発者向け） | HCL（インフラ向け宣言型） |
| 状態管理 | CloudFormation スタック | tfstate（S3 / GCS / Tofu Cloud） |
| ドリフト検知 | 弱い（手動 diff） | terraform plan で常時検出 |
| モジュール再利用 | Construct（言語縛り） | Registry（チーム横断） |
| CI/CD 連携 | CDK Pipelines | Atlantis / Spacelift / GitHub Actions |
| ベンダーロック | 高い | 低い（マルチクラウド可） |
| 学習コスト | TS 習熟 + CFn 知識 | HCL のみ |
| 失敗時のロールバック | CFn 自動 | state ロック + 手動 plan |
つまり Terraform/OpenTofu 標準化は 「CDK を捨てる」話ではなく、「マルチクラウド × チーム横断 × 監査要件」に耐える IaC 基盤への構造転換です。
受託案件で活きる 3 つの構造変化
構造 1: 「単一クラウド前提」から「規模の壁」へ
CDK は AWS 単一 / 開発者中心の小〜中規模では極めて優秀です。しかし スタック数が 50 を超え、チームが 5 つ以上に増えると、synth 時間 / 依存関係 / クロスアカウント設定が運用コストとして跳ね上がります。受託では スタック数 × チーム数 × 月次変更回数を軸にした 「規模の壁」診断を行い、閾値を超えた領域だけ Terraform に寄せるハイブリッド設計を提供します。これは OpenTofu 1.12 Terraform 移行受託（GH Media） で扱った ガバナンス設計の 規模軸版です。
構造 2: 「AWS 専用」から「マルチクラウド可搬性」へ
中堅企業の多くは AWS をメインに据えつつ、GCP（データ基盤）/ Azure（Microsoft 365 連携）/ Cloudflare（CDN）を併用しています。CDK では GCP/Azure リソースを記述できず、結局 Terraform を併用することになります。受託では 共通モジュール（VPC / IAM / 監査ログ / シークレット管理）を Terraform に統一し、AWS 固有の高度構成（Step Functions / Lambda 内製ライブラリ）だけ CDK に残す設計を提供します。これは AWS Interconnect マルチクラウド受託（GH Media） で扱った マルチクラウド接続の IaC 版です。
構造 3: 「開発者専用」から「チーム横断の IaC 可搬性」へ
CDK は アプリ開発者が書く IaC として親和性が高い反面、インフラ専任 / SRE / セキュリティチームが触りにくいという声が増えています。Terraform/OpenTofu + HCL は 役割横断の共通言語として機能し、Atlantis / Spacelift による PR ベースのレビューフローが監査要件にも適合します。受託では チームトポロジーに合わせた IaC レイヤリング（プラットフォーム / プロダクト / アプリ）を設計します。これは AWS DevOps Agent マルチクラウド AIOps（GH Media） で扱った 横断運用の 記述言語版です。
受託で提供する「IaC 標準化移行」5 フェーズ
フェーズ 1: 現状診断（2〜3 週間）
- CDK / CFn / Terraform / Pulumi の資産棚卸し
- スタック数 × チーム数 × 月次変更回数の計測
- ドリフト / synth 時間 / 失敗履歴のデータ収集
- マルチクラウド利用状況の棚卸し
- 監査要件（ISO 27001 / SOC2 / PCI DSS）整理
- リスク + ROI マトリクス
フェーズ 2: 設計（2〜3 週間）
- 「残す CDK」/「移行する Terraform」/「新規 OpenTofu」の振り分け
- state 分割設計（環境 / チーム / ライフサイクル別）
- 共通モジュール設計（VPC / IAM / 監査ログ）
- CI/CD パイプライン（Atlantis / Spacelift / GitHub Actions）
- ドリフト検知 + 通知設計
- ロールバック / DR 設計
フェーズ 3: 構築（4〜6 週間）
- Terraform/OpenTofu 共通モジュール実装
- state バックエンド（S3 + DynamoDB / Tofu Cloud）
- Atlantis / Spacelift セットアップ
- TFLint / Checkov / tfsec のポリシー設定
- cdktf による CDK → HCL 段階移行ブリッジ
- import 自動化スクリプト
フェーズ 4: パイロット移行（3〜4 週間）
- 非クリティカル環境（dev / staging）で先行移行
- ドリフト検知 + 切り戻し演習
- チーム別オンボーディング研修
- KPI 計測（plan 時間 / レビュー時間 / 失敗率）
- フィードバックループ
フェーズ 5: 月次運用レビュー（継続）
- 移行進捗 / 残 CDK 資産の棚卸し
- モジュールバージョン管理
- ドリフト / インシデント原因分析
- 新リソース対応（プロバイダ更新）
- 半期ごとの標準化ガイド更新
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| IaC コア | Terraform / OpenTofu | Pulumi |
| CDK 連携 | cdktf（HCL 出力） | aws-cdk-lib（残す領域用） |
| state バックエンド | S3 + DynamoDB / Tofu Cloud | GCS / Terraform Cloud |
| CI/CD | Atlantis / Spacelift | GitHub Actions + tfaction |
| 静的解析 | TFLint / Checkov / tfsec | Trivy / Snyk IaC |
| ポリシー | OPA / Sentinel | Conftest |
| ドリフト検知 | driftctl / Spacelift Drift | cron + plan |
| シークレット | AWS Secrets Manager / Vault | SOPS + KMS |
| モジュール管理 | Private Registry / GitHub | Spacelift Modules |
| 監査ログ | CloudTrail + OpenTelemetry | Datadog Audit |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| CDK 資産が 50 スタック超で運用負債化 | CDK 10 スタック以下で安定稼働 |
| AWS 以外（GCP / Azure / SaaS）を併用 | AWS 単一クラウド前提 |
| SRE / セキュリティチームが IaC に参加 | 開発者単独で IaC を完結 |
| ISO 27001 / SOC2 / PCI DSS 監査対応 | 監査対象外 |
| 月次のドリフト / 構成事故が頻発 | ドリフトゼロで安定 |
| マルチアカウント / マルチリージョン展開 | 単一アカウント / 単一リージョン |
小規模 CDK プロジェクトは むしろ残す判断が合理的です。受託では **「全部 Terraform に揃える」ではなく、「規模と境界に応じてハイブリッドに残す」**設計を行います。
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 移行対象範囲 | 残す CDK / 移行する Terraform の境界 | 境界変更時の追加費用 |
| state 管理責任 | バックエンド運用 / ロック / 暗号化 | 鍵管理の所在 |
| 失敗時の補償 | import 失敗 / drift 起因事故の責任分界 | 訴訟 / クレーム想定 |
| 監査ログ保持 | tfstate 履歴 + CI/CD ログの保管期間 | 法令要件 |
| 退場時引き渡し | モジュール / state / Runbook / 教育 | 自社運用継続性 |
| OSS ライセンス | OpenTofu / Atlantis の利用条件 | BSL → MPL 変化への追従 |
価格モデル — IaC 標準化移行パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 / PoC | 180 万円〜（5 週間） | 資産棚卸し + 振り分け設計 | レポート + 移行設計書 |
| Lite | 60 万円〜 / 月 | スタック 20〜50 | 月次レビュー + モジュール保守 |
| Standard | 140 万円〜 / 月 | スタック 50〜200 | + Atlantis / Spacelift 運用 |
| Enterprise | 320 万円〜 / 月 | スタック 200 超 / 多拠点 | + 専任 SRE + 月次ワークショップ |
| 初期構築 | 500 万円〜（一括） | モジュール + CI/CD + state 基盤 | 全プラン共通 |
顧客側 ROI 試算（スタック 120 / SRE+開発 40 名想定）
| 項目 | 既存（CDK 単独で運用負債化） | IaC 標準化移行後 | 差分 |
|---|---|---|---|
| plan / synth 時間（1 変更あたり） | 18 分 | 6 分 | -12 分 / 件 |
| ドリフト起因事故（月） | 3 件 | 0.5 件 | -2.5 件 |
| マルチクラウド展開リードタイム | 8 週間 | 3 週間 | -5 週間 |
| 新規メンバーオンボーディング | 6 週間 | 2 週間 | -4 週間 |
| IaC 関連工数（月） | 480 時間 | 280 時間 | -200 時間 |
| 年間効果 | — | — | 約 3,840 万円相当 + マルチクラウド展開速度 2.5 倍 |
時給 8,000 円換算で 年間 1,920 万円の工数削減 + 新規展開速度向上による機会創出。Standard プラン（年額 1,680 万円）でも 12 ヶ月以内で回収可能です。
ハマりやすい 5 つの落とし穴
落とし穴 1: state 分割を「環境別だけ」で済ませる
dev / staging / prod だけで分けると、チームが増えたとき競合が頻発します。環境 × チーム × ライフサイクルの 3 軸で分割し、Atlantis / Spacelift で PR 単位のロックを組み合わせます。
落とし穴 2: ドリフトを放置して「import 地獄」に陥る
CDK 時代に マネジメントコンソールで手動修正した資産は、Terraform 移行時に大量の import が必要になります。移行前にドリフトをゼロ化し、driftctl で常時検知する体制を作ります。
落とし穴 3: モジュール設計を共通化しすぎる
「DRY」を追求して 超汎用モジュールを作ると、変更影響範囲が読めなくなる結果になります。プラットフォーム層（共通）/ プロダクト層（チーム別）の 2 階層に留め、3 階層以上は禁止にします。
落とし穴 4: CDK を全部捨ててしまう
Step Functions / 内製 Construct ライブラリなど、CDK の表現力が活きる領域を Terraform に書き直すと 逆に負債化します。境界を明確に文書化し、残す CDK 資産を意図的に保護します。
落とし穴 5: ポリシー as Code を後回しにする
Checkov / tfsec / OPA を 移行後に追加すると、既存モジュールが大量に違反検出されて運用が止まります。移行と同時にポリシーを段階導入し、重大度別に違反許容期間を設けます。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜3 | 資産棚卸し + 規模の壁診断 + 振り分け設計 |
| Week 4〜5 | state 分割設計 + 共通モジュール設計 + CI/CD 設計 |
| Week 6〜11 | モジュール実装 + Atlantis/Spacelift 構築 + cdktf ブリッジ |
| Week 12〜13 | dev / staging パイロット移行 + オンボーディング研修 |
| Week 13 | prod 移行開始 + ドリフト検知運用 |
| Week 13 | 月次レビュー初回 + ROI ダッシュボード |
まとめ — 「CDK か Terraform か」から「規模と境界で標準化」へ進化する IaC 運用
Zenn の議論が示した CDK 運用負債は、「CDK が悪い」のではなく「規模と境界の判断を後回しにした結果」です。受託で中堅企業のクラウド基盤を支える立場では、規模の壁 + マルチクラウド + チーム横断を軸に、残す CDK と移行する Terraform/OpenTofu を意図的に振り分ける 「IaC 標準化移行」が新しい主力サービスです。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で本パッケージを提供しています。「CDK 資産が膨らんで運用が回らない」「マルチクラウド展開のために IaC を統一したい」「監査要件で IaC ガバナンスを整えたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
