【入門編】Pulumi vs Terraform vs CDK for Terraform (CDKTF)：どれを選ぶべき？徹底比較 – インフラ構成管理（IaC）活用バイブル

こんにちは！インフラストラクチャーの世界へようこそ。
クラウドのインフラをコードで管理する「IaC（Infrastructure as Code）」、毎日本当によく頑張って書いていますよね。

「TerraformのHCL（HashiCorp Configuration Language）に慣れたけど、条件分岐や複雑なループを書くときに無理やり感が出てしんどい……」
「AWS CDKみたいに使い慣れたTypeScriptでインフラを書きたいけど、マルチクラウドや他のプロバイダーも使いたい……」
「最近よく耳にする『Pulumi』って、実際のところどうなの？」

そんなモヤモヤを抱えていませんか？

今回は、現代のIaC界隈で激しい覇権争いを繰り広げる「Pulumi」「Terraform」「CDK for Terraform (CDKTF)」の3大巨頭を、現場のリアルな視点から徹底比較します。

これをマスターすれば、あなたのプロジェクトにどのツールを導入すべきかが明確になり、毎日のインフラ構築・運用作業が劇的に楽になりますよ。さあ、一緒に深淵を覗いてみましょう！

—

1. 各ツールの特徴とアーキテクチャの違い

まずは、それぞれのツールが「どうやって動いているのか」という裏側の仕組み（アーキテクチャ）を紐解きます。ここを理解すると、ツールの得意・不得意が手に取るように分かります。

【Terraform】
[HCLコード] —> (Terraform CLI) —> [APIリクエスト] —> [クラウド]
└─(State管理)─┘

【CDK for Terraform (CDKTF)】
[TS/Pythonコード] —> (cdktf synth) —> [HCLに変換] —> [Terraform CLI] —> [クラウド]
└─(State管理)─┘

【Pulumi】
[TS/Go/Python等] —> (Pulumi Engine) —> [言語ランタイム] —> [APIリクエスト] —> [クラウド]
└─(Pulumi Service or S3/GCS等でState管理)─┘

Terraform：王道の静的宣言型

  • 言語: HCL（独自の独自ドメイン言語）
  • 仕組み: 書いた宣言通りの状態になるように、Terraform CLIがクラウドのAPIを直接叩きます。
  • 特徴: 安定感抜群。インフラの「あるべき姿」をそのまま書くため、誰が書いても同じようなコードになりやすいのが最大の強みです。ただし、HCL自体の表現力には限界があり、複雑な処理をしようとすると途端にコードが汚くなります。

CDK for Terraform (CDKTF)：TypeScript等でTerraformを操る欲張り設計

  • 言語: TypeScript, Python, C#, Java, Go
  • 仕組み: 使い慣れた一般プログラミング言語でコードを書くと、一度「TerraformのHCLコード」にトランスパイル（変換）され、その後の実行はTerraformのエンジンに委ねられます。
  • 特徴: 「Terraformの堅牢なプロバイダーエコシステム」と「一般プログラミング言語の表現力」の良いとこ取りをした設計です。ただし、裏でHCLを挟む分、エラーメッセージが少し難解になることがあります。

Pulumi：真のプログラミング言語によるクラウドネイティブIaC

  • 言語: TypeScript/JavaScript, Python, Go, C#, Java, YAML
  • 仕組み: HCLのような中間言語を挟みません。TypeScriptやGoなどのプログラムを実行すると、Pulumiエンジンが直接クラウドAPIをコールします。
  • 特徴: プログラミング言語のすべての機能（ループ、条件分岐、関数、外部ライブラリのインポートなど）がそのまま使えます。「もし本番環境ならインスタンスサイズを大きく、ステージングなら小さく」といったロジックを、if文でスマートに書けます。

—

2. 学習コスト、エコシステム、ドキュメントの充実度の比較

新しいツールを導入する際、最も気になるのが「学習コスト」と「情報の見つけやすさ」ですよね。

| 評価項目 | Terraform | CDKTF | Pulumi |
| :— | :— | :— | :— |
| 学習コスト | 低〜中（HCLの習得が必要） | 中〜高（言語＋Terraformの知識） | 中（使い慣れた言語なら低い） |
| エコシステム | 圧倒的（最大・最強） | Terraformのものがそのまま使える | 高い（Terraformのプロバイダーを自動変換して取り込み） |
| ドキュメント | 豊富だが、古い情報も混在 | まだ発展途上（情報が少ない） | 非常によく整備されている |

  • Terraformのエコシステムは依然として最強です。ググれば大抵のバグやユースケースの解決策が見つかります。
  • Pulumiのドキュメントの美しさは特筆ものです。例えばAWSのS3バケットを作るコードを探すとき、公式ドキュメントで「TypeScript」タブを選ぶと、そのままコピペして動くきれいなコードが出てきます。この体験は一度味わうと病みつきになります。

—

3. 開発言語の柔軟性とマルチクラウド対応の評価

モダンな開発チームでは、「フロントエンドもバックエンドもインフラも、すべてTypeScriptで書きたい！」という要望がよく挙がります。

  • 言語の柔軟性:
  • PulumiとCDKTFの圧勝です。普段使っている言語（TypeScriptやPythonなど）でインフラを書けるため、チーム内のコードレビューのハードルが劇的に下がります。インフラエンジニアだけでなく、アプリエンジニアも気軽に参加できます。
  • マルチクラウド対応:
  • TerraformとPulumiは、AWS、GCP、Azureはもちろん、Kubernetes、Cloudflare、Datadogなど、あらゆるプロバイダーを同時に操作する「マルチクラウド構成」に非常に強いです。
  • CDKTFもTerraformの資産を使えるためマルチクラウド対応ですが、設定の複雑さが増す傾向があります。

—

4. プロジェクトの要件に応じた最適なツールの選び方

ここまで読んで、「じゃあうちはどれを選べばいいの？」と思っているはずです。先輩エンジニアとして、明確な指針を授けましょう。

1. Terraformを選ぶべきケース

  • チームにHCLの知見がある、またはインフラ専任チームがいて標準化したい。
  • トラブルシューティングの容易さ（ネット上の情報の多さ）を最優先したい。

2. CDKTFを選ぶべきケース

  • すでにTerraformの巨大なStateや既存コード資産があり、それを活かしつつTypeScript等で書き換えたい。

3. Pulumiを選ぶべきケース

  • アプリケーション開発者も巻き込んで、TypeScriptやPythonなどの同一言語でモダンに開発したい。
  • 複雑な条件分岐や、外部API（GitHubやSlackなど）と連携した動的なインフラ構築を行いたい。

—

実践：Pulumiで「Hello World」を動かしてみよう！

百聞は一見にしかず。今回は、最も未来を感じられる「Pulumi（言語はTypeScript）」を使って、AWS上にS3バケットを作成するHelloWorldを実際に体験してみましょう！

これをサクッと動かせば、Pulumiの気持ちよさが一瞬で理解できます。

ステップ1: ツールのインストール

まずは手元の環境にPulumi CLIと、AWS CLI（認証設定済みであること）をインストールします。

macOSの場合 (Homebrew)
brew install pulumi

バージョン確認
pulumi version

ステップ2: プロジェクトの初期化

適当なディレクトリを作成し、Pulumiプロジェクトを対話形式で初期化します。

mkdir pulumi-hello-world
cd pulumi-hello-world

プロジェクトの新規作成
pulumi new aws-typescript

途中でいくつか質問されます（プロジェクト名、スタック名、AWSのリージョンなど）。基本はEnterキーでデフォルトのままでOKです（リージョンだけ `ap-northeast-1` など好みのものを選んでください）。

これだけで、綺麗に整理されたTypeScriptのプロジェクトが生成されます。

ステップ3: インフラコードの記述（index.ts）

生成された `index.ts` を開き、以下のように書き換えてみてください。
プログラミング言語の恩恵を受けながら、非常に直感的にインフラを定義できます。

import as pulumi from “@pulumi/pulumi”;
import as aws from “@pulumi/aws”;

// 1. 組織名や環境名を取得（スタック名を利用）
const stack = pulumi.getStack();

// 2. S3バケットのリソースを定義
// まさに「オブジェクト指向のコード」としてインフラを定義します
const bucket = new aws.s3.Bucket(`my-cool-bucket-${stack}`, {
bucket: `my-unique-bucket-name-2023-${stack}`, // ※一意な名前に変更してください
forceDestroy: true, // デモ用なのでバケット内が空でなくても削除できるようにする
});

// 3. バケットのタグを設定
const bucketTag = new aws.s3.BucketTagging(`bucket-tag-${stack}`, {
bucket: bucket.id,
tagSet: [
{
key: “Environment”,
value: stack,
},
{
key: “ManagedBy”,
value: “Pulumi”,
},
],
});

// 4. 外部に出力する値（Outputs）を定義
// これにより、デプロイ完了後にバケット名がコンソールに表示されます
export const bucketName = bucket.id;
export const bucketArn = bucket.arn;

ステップ4: デプロイ（実行）と動作確認

さあ、魔法の呪文を唱えましょう。以下のコマンドを実行します。

pulumi up

実行すると、Pulumiがコードを解析し、AWS上で何が作成されるのかの「プレビュー（差分）」を美しくカラー表示してくれます。
確認画面で `yes` を選択すると、瞬時にAWS上にS3バケットが構築されます！

View Live: https://app.pulumi.com/… (ブラウザで状態を確認することも可能)

Type: aws:s3:Bucket
Name: my-cool-bucket-dev

  • Status: created (3s)

Outputs:
bucketArn : “arn:aws:s3:::my-unique-bucket-name-2023-dev”
bucketName: “my-unique-bucket-name-2023-dev”

Resources:
+ 2 created

Duration: 6s

たった6秒で、安全にインフラが構築できました。
不要になったら、以下のコマンドですべて綺麗に削除（クリーンアップ）できます。

pulumi destroy

—

まとめ

いかがでしたでしょうか？
今回は「Pulumi vs Terraform vs CDKTF」というテーマで、それぞれのアーキテクチャの本質から具体的なコードの感触までを解説しました。

  • 安定のTerraform
  • 堅実なCDKTF
  • 自由とスピードのPulumi

どのツールにも、それぞれの美学とユースケースがあります。しかし、もしあなたが「使い慣れたプログラミング言語のパワーで、もっと直感的かつスピーディにインフラをコード化したい」と感じているなら、Pulumiを試してみる価値は間違いなくあります。

これを機に、ぜひあなたの開発環境にも新しいIaCの風を吹かせてみてください。毎日のインフラ作業が、きっともっと楽しく、エキサイティングになりますよ！

スポンサーリンク
タイトルとURLをコピーしました