公開2025.02.13更新2026.09.27 自動化

Pulumiとは？読み方・対応言語・Terraformとの違い・料金を実例で解説

Q: Pulumi.yamlとは何ですか？

プロジェクトのメタ情報（名前・使用言語・ランタイム）を定義する設定ファイルです。環境ごとの設定値は Pulumi. .yaml に分離して管理します。

Pulumiとは？読み方・対応言語・Terraformとの違い・料金を実例で解説

Pulumi（プルミ）は、TypeScriptやPython、Goといった普段づかいのプログラミング言語でクラウドインフラを定義・管理するInfrastructure as Code（IaC）ツールです。TerraformのようにコードでAWSやAzureを構築できますが、独自の設定言語ではなく汎用言語を使えるため、ループや条件分岐、関数、クラスをそのままインフラ定義に持ち込めます。この記事では、Pulumiの読み方と開発元、対応言語、インストールからpulumi upまでの使い方、Terraformとの決定的な違い（記述言語とライセンス）、そして意外と情報が少ないPulumi Cloudの料金までを、一次情報にもとづいて整理します。

まとめ：Pulumiの要点

正体：汎用プログラミング言語（TypeScript／JavaScript／Python／Go／C#／Java／YAML）でクラウドを構築するIaCツール。読みは「プルミ」。
開発元：Pulumi Corporation（2017年設立、元Microsoftのジョー・ダフィー氏とエリック・ルダー氏が創業、米シアトル本社）。CLIとSDKはApache License 2.0のオープンソース。
Terraformとの違い：記述が独自言語HCLではなく汎用言語である点と、ライセンスがApache 2.0（Terraformは2023年8月からBSL 1.1のソース提供型）である点が核心。
料金：個人利用のPulumi Cloudは無料。Team Editionは月150,000クレジット（約200リソース分）まで無料で、超過分は2,000クレジットあたり1ドル。
対応範囲：AWS・Azure・Google Cloud・Kubernetesなどを1つのコードベースで横断管理できる。

Pulumiとは何か：汎用言語で書くInfrastructure as Code

Pulumiは、書きたい「望ましい状態（desired state）」をコードで宣言し、その差分だけをクラウドに適用するIaCツールです。実行の流れはシンプルで、Pulumi CLIが手元のプログラムを実行してリソースのモデルを組み立て、クラウドプロバイダーのAPIを呼び出して作成・変更・削除を反映します。設定ファイルを書く従来型ツールと違い、インフラ定義そのものを普段のアプリケーション開発と同じ言語・同じエディタ・同じテスト手法で扱えるのが出発点です。

読み方と開発元（Pulumi Corporation）

「Pulumi」は日本語では「プルミ」と読まれることが多い名称です。開発元のPulumi Corporationは2017年に設立され、創業者はいずれも元Microsoftのジョー・ダフィー（Joe Duffy、現CEO）とエリック・ルダー（Eric Rudder）で、本社は米ワシントン州シアトルにあります。ダフィー氏はMicrosoftで言語・コンパイラ分野の開発を率いた経歴を持ち、「開発者がインフラを言語で書く」という発想はその出自と直結しています。中核のPulumi CLIとリソースプロバイダーはApache License 2.0で公開されており、この「オープンソースであること」自体が後述するTerraformとの差別化点になっています。

宣言的IaCとしての位置づけとCloudFormationとの違い

Pulumiはコードで手続きを書けますが、内部モデルは「最終的にどうあってほしいか」を宣言する方式です。つまり命令的に書けるが結果は宣言的、という二面性を持ちます。AWS専用のAWS CloudFormationがJSON／YAMLテンプレートでAWS内に閉じるのに対し、PulumiはAWS・Azure・Google Cloudを同じ言語・同じ抽象で横断できる点が構造的に異なります。マルチクラウドや、アプリとインフラを同じリポジトリ・同じ言語でそろえたいチームで効きます。

Pulumiが対応するプログラミング言語と選び方

Pulumiは独自DSLを覚える必要がなく、既存のプログラミング言語をそのまま使えます。2026年時点でTypeScript／JavaScript、Python、Go、C#（.NET）、Java、そして宣言的に書きたい人向けのYAMLに対応し、いずれの言語でも全プロバイダーの機能を等しく利用できます。どれを選ぶかは、チームの既存スキルと連携したいコード資産で決めるのが実務的です。

言語	特徴	向くケース
TypeScript／JavaScript	型安全・エコシステム最大	Web開発チーム、大規模で型を効かせたい
Python	構文が平易	データ／ML基盤、スクリプト運用が多い
Go	単一バイナリ・高速	既存GoツールやKubernetes周辺と統合
C#（.NET）	企業システム親和	.NET資産のあるエンタープライズ
Java	JVM資産と統合	既存JavaバックエンドとIaCをそろえたい
YAML	宣言的・ランタイム不要	ロジック不要な単純構成、HCLからの移行

迷う場合は、インフラを触るメンバーが日常的に書いている言語を選ぶのが失敗しにくい判断です。YAML対応は「汎用言語は要らないが宣言的にマルチクラウドを書きたい」層の受け皿になっています。

Pulumiのインストールと最初のプロジェクト作成

各OSでのインストール手順

PulumiはWindows・macOS・Linuxに対応し、パッケージマネージャか公式スクリプトで導入できます。加えて、使う言語のランタイム（Node.js／Python／Goなど）と、対象クラウドの認証情報（例：aws configureで設定したAWS認証情報）を先に用意しておきます。

# macOS（Homebrew）
brew install pulumi/tap/pulumi

# Windows（winget もしくは Chocolatey）
winget install Pulumi.Pulumi
choco install pulumi

# Linux（公式スクリプト）
curl -fsSL https://get.pulumi.com | sh

pulumi new から pulumi up までの基本コマンド

インストール後は、State（後述）の保存先を決めるログインから始めます。pulumi loginでPulumi Cloudに接続するか、pulumi login --localで手元に保存します。次にpulumi newでテンプレートから雛形を作成します。

# State保存先にログイン（--local でローカル保存も可）
pulumi login

# AWS × TypeScript の雛形を作成
pulumi new aws-typescript

生成されたindex.tsにリソースを宣言します。例えばS3バケットを1つ作るだけなら次のように書きます。

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

// aws provider v6以降は BucketV2 を使う
const bucket = new aws.s3.BucketV2("my-bucket");

export const bucketName = bucket.id;

あとは主要コマンドを使い分けてインフラを操作します。実運用ではpulumi previewで差分を確認してからpulumi upで適用する流れが基本です。

コマンド	役割
pulumi preview	適用予定の変更（作成／更新／削除）を事前確認
pulumi up	コードの内容をクラウドに適用
pulumi destroy	Stackが管理するリソースを削除
pulumi refresh	実クラウドの状態をStateに取り込み直す

この一連の操作はGitHub ActionsによるCI/CDに組み込み、Pull Requestでpulumi preview、マージでpulumi upと自動化するのが定番です。

プロジェクト構成とStack・State管理

Pulumi.yamlとStackの役割

Pulumiプロジェクトの中心はPulumi.yamlで、プロジェクト名・使用言語・ランタイムなどのメタ情報を持ちます。ここに置く「Stack」は、開発・ステージング・本番といった環境ごとの設定単位です。環境差分はPulumi.<stack>.yamlに分離し、pulumi config setで値を、pulumi config set --secretで暗号化した機密値を管理します。1つのコードベースに対してdevとprodのStackを持たせれば、同じ定義で環境ごとの構成を安全に切り替えられます。

Stateのバックエンド（Pulumi Cloud／セルフマネージド）

Pulumiは管理下リソースの現状を「State」として保持します。既定の保存先はPulumi Cloudで、State保存・同時実行時のロック・変更履歴を無料で担います。自前で管理したい場合は--localのローカル保存や、AWS S3・Azure Blob・Google Cloud Storageをバックエンドに指定できます。State更新時のロックが標準で効くため、チームでの同時pulumi upによる競合を防ぎやすいのは実務上の利点です。

Pulumi Cloudの料金体系

公式ドキュメントに散らばっていて分かりにくいのがPulumi Cloudの料金です。課金はクレジット制で、1クレジット＝1リソースを1時間管理する単位（0.0005ドル）として計算されます。個人利用は無料、チーム利用にも無料枠があるため、小規模なら費用をかけずに始められます。

プラン	対象	無料枠	超過時
Individual	個人	State管理・更新回数とも無料	―
Team	チーム	月150,000クレジット（約200リソース）	2,000クレジットあたり1ドル
Enterprise / Business Critical	大規模組織	要問い合わせ（SSO・RBAC等）	個別見積

目安として、常時管理するリソースが200個以下のチームなら無料枠に収まります。クレジット単価や無料枠は改定されることがあるため、本番のコスト試算前に公式の料金ページで最新値を確認してください。なお、State管理自体はセルフマネージドにすればPulumi Cloudなしでも無料で運用できます。

PulumiとTerraformの違い：どちらを選ぶべきか

PulumiとTerraformは同じIaCカテゴリですが、思想が異なります。差が最も出るのは「記述言語」と「ライセンス」の2点です。

観点	Pulumi	Terraform
記述言語	汎用言語＋YAML	HCL（独自の設定言語）
ライセンス	Apache 2.0（オープンソース）	BSL 1.1（2023年8月〜／ソース提供型）
State管理	Pulumi Cloudが標準・ロック内蔵	tfstateをS3等かHCPで自前管理
エコシステム	成長中	成熟・モジュールとプロバイダーが豊富
学習コスト	プログラマは低い	インフラ専任にはHCLが平易

2023年8月にHashiCorpがTerraformのライセンスをオープンソースのMPL 2.0から商用制限のあるBSL 1.1へ変更したことは、選定に直接影響します。ソースコードの改変はできても、HashiCorpの商用製品と競合する用途には使えないためです。これを受けてLinux Foundation主導のフォーク「OpenTofu」（MPL 2.0）が生まれ、Terraform 1.5.x互換のオープンソース代替として使えます。

判断の目安ははっきりしています。既存アプリと同じ言語でループや条件分岐を多用したい、アプリとインフラのコードをそろえたいならPulumiが向きます。逆に、HCLの資産や豊富な公式モジュールを前提に宣言だけで足りるならTerraform、オープンソースに強くこだわるならOpenTofuが選択肢です。よくある失敗は、汎用言語の自由度に任せてインフラコードへ手続き的なロジックを詰め込みすぎ、レビュー不能な複雑コードにしてしまうケースです。Pulumiでもリソース定義は宣言的に保ち、動的処理は最小限にとどめるのが安全です。State管理を深掘りしたい場合はHCP Terraform（旧Terraform Cloud）の解説や、Terraformの最新アップデートもあわせて比較してください。

PulumiのAI機能とエコシステム（Pulumi AI・Neo・ESC）

Pulumiは、2025年にエージェント型のNeoを投入するなど、コード生成から運用までをAIとサービスで固めています。用途に応じて次の3つを押さえておけば十分です。

Pulumi AI：自然言語で「〜な構成が欲しい」と伝えると、対応言語のPulumiプログラムを生成する。雛形づくりや学習の入口に向く。
Pulumi Neo：2025年9月に公開プレビューが始まったエージェント型のプラットフォームエンジニア。Pulumi CLIから直接呼び出せるほか、GitHubのPull Requestで@neoに調査や修正を依頼したり、Slackで@neoに相談したりできる。ドリフト検知・依存更新・ポリシーチェックを定期実行し、結果をPull Requestとして提出する運用が可能。
Pulumi ESC：環境・シークレット・設定を一元管理するサービス。AWS Secrets Manager、Azure Key Vault、HashiCorp Vault、1Passwordなどと連携し、バージョン管理された環境定義として扱える。

加えて、Pulumi MCP ServerはClaude CodeやCursor、GitHub CopilotといったエディタのAIアシスタントと連携し、リソース情報の参照やコード生成を支援します。ただしAIが生成したインフラコードはそのまま本番へ流さず、必ずpulumi previewで差分を確認してから適用するのが鉄則です。Kubernetesのマニフェスト生成なども依頼できますが、この場合も適用前に必ずpulumi previewで差分を確認します。