こんにちは！クラウドインフラ・SREの世界へようこそ。
日々のインフラ運用、本当にお疲れ様です。TerraformやPulumiといったIaC（Infrastructure as Code）ツールを使ってクラウドを管理していると、一度はこんな恐怖体験をしたことがないでしょうか？
「あ、このS3バケットの変数名、少し分かりにくいからリファクタリングしよう」
――軽い気持ちでコード上の名前を変更し、`pulumi up` を叩いた瞬間、画面に表示される残酷な赤文字。
『Resource X will be destroyed and recreated』
……待ってくれ！ 本番環境のデータベースや、中身が詰まったストレージバケットが消えて作り直される？ そんなダウンタイムやデータ消失を引き起こしたら、明日から会社に行けなくなってしまいますよね。
今回は、そんなインフラエンジニアの冷や汗をピタッと止める、Pulumiでの「リソース名変更でダウンタイムを出さないためのMove/Rename戦略」を、優しく、そして徹底的に解説していきます。これをマスターすれば、コードをどれだけ美しく整理整頓しても、夜パジャマのまま冷や汗をかくことはなくなりますよ。
—
1. なぜ「名前を変えただけ」でリソースが消滅するのか？
まず、Pulumi（およびTerraformなどの近代IaCツール）の裏側の仕組みを少しだけ紐解いてみましょう。
私たちがコードを書くとき、リソースには2つの名前が存在します。
1. 論理名（Logical Name / Variable Name）: プログラム上で私たちが定義する変数名（例：`const myBucket = …`）
2. 物理名（Physical Name）: クラウド上（AWS等）で実際に生成されるリソースの名前（例：`my-company-production-data-bucket-12345`）
Pulumiのステートファイル（状態管理ファイル）は、「論理名」をキーにしてクラウド上のリソースとコード上の定義を紐づけています。
そのため、コード側で論理名（変数名）を変更してしまうと、Pulumiはこう勘違いします。
> 「あれ？ 古い論理名のリソースがコードから消えたな？ じゃあ削除しなきゃ。お、同時に新しい論理名のコードが増えたな？ じゃあ新しく作らなきゃ！」
これが、名前を変えただけでリソースが再作成（Destroy & Create）されてしまうメカニズムの正体です。物理名（AWS上の名前）が同じであっても、Pulumiが「別人」と勘違いしてしまうわけですね。
—
2. 解決の切り札：Pulumiにおける2つのアプローチ
この悲劇を防ぐために、Pulumiには強力な防衛手段が2つ用意されています。状況に合わせて使い分けるのがプロの技です。
1. `aliases`（エイリアス）機能: コード側にあらかじめ「昔の名前はこれだったよ」と教えてあげる方法（最もスマートで安全）。
2. `pulumi state rename` コマンド: ステートファイルを直接書き換えて、物理的な紐づけを強制的に引っ越す方法（緊急時や大規模な整理に便利）。
それぞれの具体的な使い方を、分かりやすく見ていきましょう。
—
3. 実践！`aliases` を使った安全なリファクタリング
まずは、コード側で安全性を担保する `aliases` の使い方です。
例えば、次のようなTypeScriptのコードがあったとします。
import as aws from “@pulumi/aws”;
// 【変更前】論理名が “oldBucket”
const oldBucket = new aws.s3.Bucket(“my-app-bucket”, {
bucket: “my-super-important-production-data”,
});
この `oldBucket` という変数名を、より分かりやすい `dataBucket` にリファクタリングしたいとします。その際、以下のように `transformations` や `aliases` を設定します。
import as aws from “@pulumi/aws”;
// 【変更後】論理名が “dataBucket” になった！
const dataBucket = new aws.s3.Bucket(“dataBucket”, {
bucket: “my-super-important-production-data”,
}, {
// ここが魔法の呪文！「古い名前（論理名）」をエイリアスとして登録する
aliases: [
{ name: “oldBucket” }
],
});
ここがポイント！
`aliases` に過去の論理名（この場合はコード上のリソース名、あるいは親スタックを含めたパス）を指定することで、Pulumiにこう伝えておけます。
「ねえ、名前は変わったけど、中身はあの時のあいつと同じだから、作り直さないでステートだけ引き継いでね！」
これによって、`pulumi up` を実行した際、Pulumiはリソースを一切作り直すことなく、綺麗にステート上の名前だけをアップデートしてくれます。
—
4. 裏技：`pulumi state rename` でステートを直接外科手術する
「すでにコードを書き換えてしまって、うっかり `pulumi up` で削除が走る寸前になっている！」あるいは「もっと構造を大きく変えたので、コードにエイリアスを書き散らしたくない」という場合は、PulumiのCLIコマンドを使ったステート操作が有効です。
ターミナルを開き、以下のコマンドを叩きます（実行前には必ず `pulumi stack export > backup.json` でバックアップを取りましょう！）。
pulumi state rename <現在の論理名> <新しい論理名>
pulumi state rename urn:pulumi:dev3::my-project::aws:s3/bucket:Bucket$oldBucket urn:pulumi:dev3::my-project::aws:s3/bucket:Bucket$dataBucket
ちょっとURN（Uniform Resource Name）の記述が呪文のように見えますが、現在のステートを確認したいときは `pulumi stack –show-urns` を使うと一目で分かります。
このコマンドを実行すると、クラウド側の実体には一切触れず、Pulumiの管理台帳（ステート）の上だけで「名前の引っ越し」が完了します。外科手術のようにピンポイントで安全なリファクタリングができるため、SREとしては非常に頼りになる機能です。
—
5. 先輩からのアドバイス：安全なIaCライフルのために
インフラストラクチャをコードとして管理する（IaC）最大のメリットは、「システムを美しく、安心して進化させられること」です。しかし、ツールの挙動を誤解していると、コードの美しさと引き換えにシステムの安定性を破壊しかねません。
今回ご紹介した `aliases` やステート操作の知識を身につけておけば、もうリファクタリングを恐れる必要はありません。
「あ、ここの変数名、もっと綺麗にできるな」と思ったその瞬間に、迷わず手を加えられるエンジニアになりましょう。
これをマスターすれば、あなたの毎日のデプロイ作業やコードレビューが、劇的に楽しく、そしてスリリング（悪い意味での）のない平和なものになりますよ。
それでは、次の現場でもスマートなインフラ構築を楽しみましょう！