Pulumiは「インフラをコードで書く」のではなく「インフラを言語で書く」
Terraformが独自DSL（HCL）であるのに対し、PulumiはTypeScript/Python/Go/C#などの汎用言語でリソースを記述できます。条件分岐・ループ・ユニットテストが通常のコードと同じ書き方でできるため、複雑な構成を扱うチームでは可読性が大幅に向上します。一方で、言語の自由度が高い分、規約を決めないと「人によって書き方が違う」問題が起きやすいのが現実です。
Pulumi導入を検討すべき5つのシグナル
- 同じTerraformコードを「環境ごとに微妙に書き分けている」状態が長く続いている
- HCLでは表現しづらい動的なリソース生成（ループ・条件・外部API参照）が増えてきた
- インフラチームと開発チームの言語スタックを揃えたい（TypeScript統一など）
- ユニットテスト・スナップショットテストでインフラ変更の安全性を担保したい
- Kubernetes・複数クラウドの抽象化を1つのフレームワークで扱いたい
Terraformとの使い分け表（実務目安）
Terraform向き: 単純な構成・運用チームの技術スタックが多様・OSSモジュール資産を活用したい。
Pulumi向き: 動的構成が多い・TypeScript/Pythonでテスト駆動したい・複数クラウドを統一抽象化したい。
両方併用するケースも増えており、Terraformで土台を作りPulumiで上位レイヤを書く構成も実用的です。
状態管理（State）の選択肢
Pulumiの状態はデフォルトでPulumi Cloud（SaaS）に保存されますが、S3/Azure Blob/GCS等のセルフホスト先も選べます。商用での実務目安:
- 5人以下のチーム → Pulumi Cloud（無料枠で十分）
- 金融・公共系で外部SaaSが使えない → S3バックエンドでロックはDynamoDB
- マルチテナント運用 → スタック分離＋OrganizationでRBAC設計
CI/CD連携の基本パターン
GitHub Actionsからpulumi preview→PRコメント、pulumi up→マージ後、という流れが標準。OIDC連携でクレデンシャルを排除すると安全性が一気に上がります。大規模化したらPulumi Deployment（マネージドCI/CD）に移行する選択肢もあります。
実務で詰まりやすい3つの落とし穴
- 非同期Output型の扱い:
pulumi.Outputは値が確定するまでthen的に扱う必要があり、文字列結合で頻発する。pulumi.interpolateを使うのが定石 - テスト用モック:
@pulumi/pulumi/runtimeのmockを正しく差し込まないと「クラウドを実際に叩いてしまう」事故が起きる - シークレット管理:
pulumi config set --secretで暗号化するが、ログ出力時に意図せず復号値が漏れることがある。pulumi.secret()でラップする
学習ロードマップ（30日プラン）
- 1週目: TypeScriptでAWS S3バケットを1つ立てる→destroyまで往復
- 2週目: VPC・サブネット・EC2をComponentResourceでモジュール化
- 3週目: ユニットテスト（jest+pulumi/runtime mock）を書く
- 4週目: GitHub Actionsで preview→up を自動化、Pulumi Cloudのスタック分離を実装
関連リンク
Terraform上級の実装パターンは Terraform上級活用、CI/CDの基本は Jenkinsモダン化、IaCの選択肢比較は IaCツール選び方 を参照してください。インフラエンジニアのキャリア設計は インフラエンジニアのキャリア もどうぞ。