TerraformユーザーのためのPulumi実践ガイド：HCLから汎用言語へのパラダイムシフト

2026-01-20 2026-01-20

Infrastructure as Code (IaC) のデファクトスタンダードといえば、間違いなく Terraform です。多くのエンジニアがHCL (HashiCorp Configuration Language) の宣言的な記述に慣れ親しんでいることでしょう。

しかし近年、Pulumi が急速に注目を集めています。「なぜ今さら新しいツールなのか？」「HCLで十分ではないか？」

本記事では、Terraformの知識を持つエンジニアを対象に、Pulumiが解決しようとしている課題と、Terraformとの実践的な違いについて解説します。

1. 最大の違い：DSL vs 汎用プログラミング言語

TerraformとPulumiの最も根本的な違いは、「独自言語（DSL）」か「汎用言語（GPL）」かです。

Terraform (HCL) の場合

HCLは「設定」を記述するために特化した言語です。シンプルで読みやすい反面、複雑なロジックを組もうとすると途端に可読性が下がります。

count や for_each の独特な挙動
三項演算子のネスト地獄
独自の組み込み関数（cidrsubnetなど）の学習コスト

Pulumi (Python/TypeScript etc.) の場合

Pulumiは、Python, TypeScript, Goなどの標準的な言語を使用します。これは、「インフラ定義に、ソフトウェア開発の全パワーを使える」ことを意味します。

具体例：条件分岐とループ

「本番環境以外かつ、特定のフラグが立っている場合のみリソースを複数作成する」といったロジックを比較してみましょう。

Terraform (HCL):

resource "aws_s3_bucket" "example" {
  # countと三項演算子を駆使する必要がある
  count = var.env != "prod" && var.enable_feature ? length(var.names) : 0
  bucket = var.names[count.index]
}

Pulumi (Python):

if env != "prod" and enable_feature:
    for name in names:
        aws.s3.Bucket(f"bucket-{name}")

Terraformユーザーであれば、Pulumiのコードがいかに「直感的」で、脳内のロジックをそのまま記述できているか分かるはずです。

2. State管理：Backendの概念は同じ

Terraformユーザーが最も気にするのが .tfstate の管理でしょう。Pulumiも概念は全く同じです。

Terraform: S3やGCS、Terraform CloudをBackendとして設定。
Pulumi: デフォルトは「Pulumi Service (SaaS)」ですが、ログイン不要でS3やGCSをBackendに指定可能です。

# AWS S3をState置き場として使う場合
pulumi login s3://my-pulumi-state-bucket

このように、Terraformでいう「Remote Backend」を自前で管理する運用も完全にサポートされています。

3. モジュール化と抽象化のレベル

Terraformでは module ブロックを使って再利用性を高めますが、変数の受け渡し（variable と output）の定義が冗長になりがちです。

Pulumiにおいて、モジュールは単なる「関数」や「クラス」です。

TerraformのModule

module "network" {
  source = "./modules/vpc"
  cidr   = "10.0.0.0/16"
}

これを使うために、./modules/vpc/variables.tf などをしっかり定義する必要があります。

Pulumiのコンポーネント

Pythonであれば、単にクラスを定義するだけです。型ヒント（Type Hinting）も効くため、エディタの補完が強力に支援してくれます。

# クラスとして定義しておけば...
class MyVpc:
    def __init__(self, cidr):
        # VPC作成ロジック
        pass

# 使う時はただのインスタンス化
vpc = MyVpc("10.0.0.0/16")

パッケージマネージャー（pipやnpm）を通じて社内ライブラリとして配布するのも、Terraform Registryを構築するより遥かに容易です。

4. プロバイダーの信頼性（実はTerraformを使っている？）

「新しいツールだと、AWSやGCPの最新機能への対応が遅いのでは？」という懸念があります。

実は、Pulumiの主要なプロバイダー（AWS, Azure, GCPなど）は、Terraform Providerをラップする形（Terraform Bridge）で実装されています。 つまり、Terraformでできることは、原理的にPulumiでもほぼ同時にできるようになります。Terraformのエコシステムの恩恵をそのまま受けているのがPulumiの強みです。

5. デメリット：Terraformの方が優れている点

公平を期すために、Pulumiの課題点も挙げます。

環境構築の複雑さ
- Terraformはバイナリ1つで動きますが、Pulumiは「言語のランタイム（PythonやNode.js）」と「パッケージ管理（pipやnpm）」が必要です。node_modules の管理などの "プログラミング固有の悩み" がインフラに持ち込まれます。
自由すぎるがゆえの可読性低下
- プログラミング言語なのでどんな書き方もできてしまいます。チーム内でコード規約を設けないと、スパゲッティコード化したインフラが生まれるリスクがあります。Terraformの制約は、逆に「誰が書いても似たコードになる」というメリットでもあります。

結論：どちらを選ぶべきか？

Terraformを使い続けるべきケース

インフラ構成がシンプルで静的である。
チームメンバーがプログラミング言語（Python/TSなど）に詳しくない。
ステートレスで宣言的な記述を徹底したい。

Pulumiを検討すべきケース

条件分岐やループなどの複雑なロジックが必要な構成である。
アプリ開発チームがインフラも担当する（言語を統一したい）。
動的なパラメータ（外部APIを叩いてその結果で台数を決める等）に基づいてインフラを作りたい。

最後に

Terraformに慣れたエンジニアにとって、Pulumiへの移行障壁は「言語」だけです。しかし、一度その「プログラミング言語でインフラを操作する全能感」を味わうと、HCLの制約に戻るのが少し窮屈に感じるかもしれません。

まずは、小さなプロジェクトや個人の検証環境から import pulumi してみてはいかがでしょうか。