背景

クラウドインフラ／DevOps／プラットフォームエンジニアリングの潮流の中で、インフラをコードで管理する「Infrastructure as Code（IaC）」の重要性はますます高まっています。
本記事では、主要なIaCツールである Terraform、Pulumi、Crossplane を比較し、「どの場面でどれを選ぶべきか」を整理します。

この記事を読むことで、以下が理解できることを期待しています：

3大ツールの特徴を整理し、得意／不得意領域を把握できる
自己のチーム・環境に即したツール選定の視点を得られる
“選定時に押さえておきたいポイント”が理解できる

各ツールの概要と特徴

Terraform

概要：HashiCorp 社が開発した IaC ツール。宣言的にインフラ（クラウド／オンプレ／サービス）を記述し、状態（state）を管理して構築・変更を実現します。
言語：HCL (HashiCorp Configuration Language) または JSON。
強み：
- 圧倒的なプロバイダ（provider）エコシステムを持つ（AWS, Azure, GCP, 各種 SaaS など多数）
- マルチクラウド対応／既存インフラ移行の選択肢として実績がある
- 宣言型構成のため、比較的学習コストが抑えられる（特にインフラ寄りのエンジニアには馴染みやすい）
弱み・注意点：
- 動的ロジック（ループや条件分岐、プログラム的生成）を扱う際には限界・工夫が必要
- “継続的リコンシリエーション（状態の自動修復）”という観点では Kubernetes ネイティブな仕組みほどではない
- 2023年8月、HashiCorpはTerraformを含むすべての製品を「Business Source License（BSL）」へ移行することを発表しました（公式発表）。
  このライセンスでは、商業的な利用の判定が「本番使用（production use）」という用語で定義されており、
  「この用語の定義が明確でないために正確な基準がどこにあるかはライセンサー側しか判断できない構造になっている」
  という指摘があります（出典：shujisado.com）。
  筆者の所属する組織でもこの部分が議論となり、
  「ライセンサー側しか判断できないリスクがあるのであれば使うのをやめておこう」
  という結論に至り、結果的に一時的に AWS CloudFormation の利用へ切り替える判断をしました。

Pulumi

概要：Pulumi Corporation が開発・提供している IaC ツール。一般的なプログラミング言語（TypeScript／Python／Go／C#など）を用いてインフラをコード化できます。
言語：上述のように多言語対応。
強み：
- ソフトウェア開発者としてのスキルセット（IDE, テスト, パッケージ管理など）を活かしやすい
- ループ・条件・関数といったプログラミング構造を活用でき、抽象化や再利用がしやすい
- アプリケーションコードと同じ言語の延長でインフラコードを書くという体験が好きなチームには親和性が高い
弱み・注意点：
- プログラミングできる分、構造が複雑化しやすく、明確なパターン設計やガバナンスが必要
- Terraform に比べるとプロバイダ数・コミュニティの成熟度はまだ発展途上の部分もある

Crossplane

概要：Kubernetes ネイティブな制御ループ（コントローラ／CRD）を活用して、クラウドリソースを Kubernetes のリソースとして扱えるようにする IaC／プラットフォームエンジニアリング向けツール。
言語／構成：YAML（Kubernetes Manifest）＋CRD 定義。K8s を前提とした環境設計が必要です。
強み：
- Kubernetes クラスターをすでに運用している／運用予定の組織には、開発者向け “セルフサービス” プラットフォーム構築に強い
- 継続的リコンシリエーション（“望ましい状態”を Kubernetes が常に監視・修復）というモデルが組み込みやすい
- インフラとアプリケーションの境界が曖昧になる “Platform Engineering” の設計にマッチする
弱み・注意点：
- Kubernetes の運用・理解が前提となるため、純粋なインフラチームのみ・K8s未導入環境には導入ハードルが高い
- ツールそのものの導入設計／CRD設計／運用ガバナンス設計という“次のレベル”の工程がある

ツール選定：どんな場面で使い分けるべきか

ツール	適したシーン	補足ポイント
Terraform	マルチクラウド環境／既存インフラの IaC 化／CI／CD で標準化したい場合	状態管理／チーム分割／モジュール設計を早めに整備することが鍵。
Pulumi	アプリ開発チームとインフラチームが近く、プログラマブルなインフラ設計を取り入れたい場合	“言語”を扱える分ガバナンスや可読性・保守性をきちんと考える必要があります。
Crossplane	既に Kubernetes を中心基盤とし、開発者にセルフサービスでインフラを提供したい場合	運用・設計のハードルが高めなので “K8s前提” でなければ導入検討を慎重に。

ライセンス変更とその影響（Terraform のケース）

この経験から、ツール選定時には「機能・導入容易性・チーム体制」だけでなく、
ライセンス・コミュニティ・開発ロードマップ・ベンダーロックインといった要素も評価軸に含めるべきではと思います。

比較まとめ（機能・運用観点）

観点	Terraform	Pulumi	Crossplane
コード記述方式	HCL／宣言型	プログラミング言語（TS／Python／Go等）／プログラマブル	Kubernetes CRD／YAML＋コントローラ型
マルチクラウド対応	高い	高い	対応ありだが Kubernetes 前提
学習コスト	中	中〜高	高
運用モデル	plan/apply 実行型	同様に実行型	継続的リコンシリエーション
開発者体験	安定的	柔軟で動的	自動化・セルフサービス志向
適用フェーズ	基盤構築	アプリ／動的インフラ	Platform Engineering
注意点	ライセンス	設計複雑性	導入難度

コードスニペット比較

Terraform

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_s3_bucket" "example" {
  bucket = "my-unique-bucket-name"
  acl    = "private"
}

Pulumi (TypeScript)

import * as aws from "@pulumi/aws";

const bucket = new aws.s3.Bucket("example", {
  bucket: "my-unique-bucket-name",
  acl: "private",
});

Crossplane (YAML)

apiVersion: s3.aws.crossplane.io/v1alpha3
kind: Bucket
metadata:
  name: example
spec:
  forProvider:
    bucketName: my-unique-bucket-name
    acl: private
  providerConfigRef:
    name: aws-provider

まとめ

Terraform／Pulumi／Crossplane はそれぞれ異なる思想で設計されており、「万能ツール」は存在しません。
Terraform のライセンス変更を契機に、IaCツールを選定する際は技術面だけでなく、ライセンスや将来のリスクも重要な要素であることが浮き彫りになりました。
結果として、チームのスキルセットや運用モデル、ライセンスポリシーに応じて適切なツールを選ぶことが不可欠です。
今後は「Terraform で基盤構築」「Pulumi でアプリ寄りリソース」「Crossplane でセルフサービスレイヤーを実現」するような、Polyglot IaC 戦略が現実的な選択肢になるでしょう。

タグ候補：Terraform Pulumi Crossplane IaC PlatformEngineering