こんにちは！クラウドインフラの世界へようこそ。
日々、TerraformやCloudFormation、あるいは手動でのポチポチ作業に疲弊していませんか？
今回は、次世代のインフラ構成管理（IaC）ツールとして世界中のエンジニアを虜にしている「Pulumi（プルミ）」を取り上げます。
特に、現場で最も冷や汗をかく瞬間の一つである「プロバイダのメジャーバージョンアップ（破壊的変更）への備え方」について、プロの知見を交えて優しく、かつ徹底的に解説していきます。
これをマスターすれば、バージョンアップの通知を見るたびに胃が痛くなる夜とはお別れできますよ。さあ、一緒にインフラ自動化の深淵を覗いてみましょう！
—
1. Pulumiってなに？なぜ今、選ばれているのか
従来のIaCツール（例えばTerraform）では、HCL（HashiCorp Configuration Language）という独自の言語を覚える必要がありました。「ここに条件分岐を入れたいのに、HCLの構文が複雑すぎて書けない……」そんなジレンマに陥ったことはありませんか？
Pulumiの最大の特徴は、「使い慣れたプログラミング言語（TypeScript, Python, Go, C#など）」でインフラを定義できる点です。
[ あなたが書くコード (TypeScriptやPythonなど) ]
↓
[ Pulumi Engine (リソースの依存関係や状態を管理) ]
↓
[ クラウドプロバイダ (AWS, GCP, Azureなど) ]
使い慣れた言語の強力なエコシステム（関数、ループ、クラス、テストフレームワーク）をそのままインフラ構築に持ち込めるため、コードの保守性と表現力が劇的に向上します。これを一度経験すると、もう元の世界には戻れなくなりますよ。
—
2. 基礎セットアップ & 「Hello World」動作確認
まずは、手元でPulumiを動かせる環境を作りましょう。今回は最もポピュラーな TypeScript を使用します。
ステップ1: ツールのインストール
macOSであればHomebrewで一撃です。
brew install pulumi
（Windowsの場合は `winget install pulumi`、Linuxの場合は公式スクリプトをご利用ください）
ステップ2: プロジェクトの初期化
適当なディレクトリを作成し、プロジェクトをセットアップします。
mkdir pulumi-hello-world
cd pulumi-hello-world
pulumi new aws-typescript
途中でAWSのリージョンなどを聞かれますが、デフォルトのままで進めて構いません。対話が終わると、カレントディレクトリに `index.ts` というファイルが生成されます。これがあなたのインフラを定義する心臓部です。
ステップ3: コードの記述（Hello World）
生成された `index.ts` を開き、S3バケットを1つ作成するだけのシンプルなコードに書き換えてみましょう。
import as pulumi from “@pulumi/pulumi”;
import as aws from “@pulumi/aws”;
// 1. セキュアなS3バケットを定義する
const bucket = new aws.s3.Bucket(“my-safe-bucket”, {
acl: “private”,
tags: {
Environment: “Development”,
ManagedBy: “Pulumi”,
},
});
// 2. バケット名をエクスポート（出力）する
export const bucketName = bucket.id;
ステップ4: デプロイの実行
以下のコマンドを叩くだけで、AWS上にリソースが構築されます。
pulumi up
画面にプレビューが表示され、「実行しますか？」と聞かれるので `yes` を選択します。数秒後、無事にS3バケットが作成され、ターミナルにバケット名が表示されたはずです。これがPulumiの基本サイクルです。簡単ですね！
—
3. 本題：プロバイダの破壊的変更（Breaking Changes）にどう立ち向かうか？
さて、ここからが今回の本題です。
インフラを運用していると、AWSやAzureなどのクラウドプロバイダのメジャーバージョンアップ（例: `@pulumi/aws` v5 から v6 への移行）に直面します。
メジャーバージョンアップには、「プロパティ名の変更」「デフォルト挙動の変更」「特定のリソースの廃止（破壊的変更）」が含まれます。何も考えずにバージョンを上げて `pulumi up` を叩くと、「既存のプロダクション環境のデータベースが意図せず削除され、作り直される」という悪夢のようなダウンタイムを引き起こす可能性があります。
これを完全に防ぐための3つの安全戦略を伝授します。
—
戦略1: スタックのバックアップ（Stateの防衛）
バージョンアップ作業の前には、必ず現在の状態（State）をエクスポートしておきましょう。PulumiのStateにはリソースの全情報が詰まっています。
現在のステータスをJSONファイルとしてローカルに退避
pulumi stack export > stack-backup-$(date +%Y%m%d).json
万が一、マイグレーション中にStateが破損しても、これがあれば一瞬で巻き戻せます。
—
戦略2: `transformations` と `alias` でリソースの「作り直し」を防ぐ
プロバイダのバージョンアップによって、リソースの内部的なURN（ユニーク名）やプロパティ構造が変わることがあります。これにより、Pulumiが「あ、古いリソースを消して、新しいリソースを新しく作らなきゃ！」と勘違いすることがあります。
これを防ぐための強力な武器が `alias`（エイリアス） です。
例えば、リソース名を変更したり、プロバイダの仕様変更でリソースのパスが変わる場合、以下のように `alias` を指定することで、Pulumiに「これは名前が変わっただけで、同じリソースだよ」と教えてあげられます。
const bucket = new aws.s3.Bucket(“my-new-bucket-name”, {
// 設定値…
}, {
// 古い名前やURNを指定し、リソースの再作成（削除＆作成）を阻止する
aliases: [
{ name: “my-safe-bucket” } // 先ほど作った古い名前
]
});
この一行があるだけで、クラウド上の実リソースを保持したまま、Pulumi上の管理定義だけを安全に移行できます。
—
戦略3: テスト環境での事前検証から本番適用までの段階的移行プロセス
本番環境（Production）でいきなりバージョンを上げるのは、目隠しをして綱渡りをするようなものです。以下のステップで段階的に移行しましょう。
1. Staging環境でのdry-run（プレビュー）
まずはステージング環境の `package.json` でプロバイダのバージョンを上げます。
npm install @pulumi/aws@latest
その後、`pulumi preview`（`up` ではなくプレビュー）を実行します。
pulumi preview
ここで、意図しない `delete` が発生していないかを血眼になって確認します。もし「〜を削除して再作成します（replace）」という表示があれば、それは破壊的変更を踏んでいます。前述の `alias` やコードの修正を行い、プレビュー上で「変更なし（または安全なプロパティ変更のみ）」になるまで調整します。
2. CI/CDパイプラインでの自動検証
GitHub ActionsなどのCI環境で、PR作成時に `pulumi preview` を自動実行させ、チーム全員で差分を目視レビューできる体制を作ります。
3. 本番環境への適用
ステージングで安全性を確認できて初めて、本番環境のバージョンアップを行います。
—
まとめ
今回は、Pulumiの基本から、プロバイダバージョンアップ時の破壊的変更に備える安全なマイグレーション戦略まで解説しました。
- Pulumiなら使い慣れた言語で安全にインフラを記述できる
- メジャーバージョンアップ前には必ず `pulumi stack export` でバックアップを取る
- 破壊的変更による意図しないリソース削除は `alias` で完全に防ぐ
- `pulumi preview` をステージング環境で徹底的に回し、差分を検証してから本番へ挑む
このプロセスを徹底すれば、どれほど巨大なインフラのバージョンアップであっても、冷や汗をかくことなく、優雅にコーヒーを飲みながらクリアできるようになります。
毎日のインフラ運用が、もっと楽しく、もっとエキサイティングになりますように。
それでは、次の現場でお会いしましょう！