Pulumiオーケストレーションの深淵：リソース名変更で本番を殺さないためのStateリファクタリング戦略
インフラストラクチャ・アズ・コード（IaC）の運用において、最も背筋が凍る瞬間はどれだろうか。大規模なリファクタリングを終え、自信満々に `pulumi up` を叩いた直後、ターミナルに表示される赤い文字——「- (削除)」「+ (作成)」。
その対象が、数百万件のレコードを抱えるRDSインスタンスや、ステートフルな永続ボリュームであった場合の絶望感たるや、筆舌に尽くしがたい。
Pulumi（およびその背後にあるCloud Resource Provider）は、コード上の変数名や論理名（Logical Name）の変更を「既存リソースの廃棄と新規リソースの作成」と厳密に解釈する。この仕様の表層しか見えていないエンジニアは、命名規則の綺麗さを追求するあまり、本番環境のダウンタイムという名の爆弾を自ら起爆させることになる。
本稿では、Pulumiのステート管理メカニズムの深部に踏込み、一歩たりともダウンタイムを出さずに論理名を安全に変更するための「Move/Rename戦略」の全貌を、実戦コードとコマンドラインの極意と共に解き明かす。
—
1. 悲劇のメカニズム：なぜPulumiはリソースを再作成するのか？
まず、敵を知ることから始めよう。Pulumiのアーキテクチャにおいて、各リソースは以下の2つの名前を持っている。
1. Logical Name（論理名）: コード内でインスタンス化する際の変数名や第一引数（例: `const bucket = new aws.s3.Bucket(“my-bucket”, …)` の `”my-bucket”`）。
2. URN (Uniform Resource Name): ステートファイル（`Pulumi.
Pulumiのエンジンは、コードをパースして得たURNと、Stateファイルに記録されているURNを比較して差分検出（Diff）を行う。ここで論理名を変更すると、エンジンは「古いURNのリソースが消滅し、新しいURNのリソースが新しく宣言された」と判定する。
[旧コード] new aws.s3.Bucket(“app-logs”, …) -> URN: urn:pulumi:prod::app::aws:s3/bucket:Bucket::app-logs
[新コード] new aws.s3.Bucket(“application-logs”, …) -> URN: urn:pulumi:prod::app::aws:s3/bucket:Bucket::application-logs
結果、エンジンは慈悲なく `aws.s3.Bucket` の `Delete` を発行し、その後に `Create` を実行する。バケットポリシーやオブジェクトロックが有効なバケットであれば、APIレベルで削除が拒絶され、デプロイパイプラインは無残にクラッシュする。
この悲劇を防ぐアプローチは主に2つある。
1. コードレベルでの解決（Aliases機能）
2. ステートレベルでの解決（`pulumi state` コマンド）
それぞれの深淵を見ていこう。
—
2. アプローチA：`aliases` による宣言的リファクタリング（推奨）
コードベースの変更でこれを解決する最も優雅な方法は、`alias` プロパティの明示だ。Pulumiに対し、「このリソースの過去のアイデンティティ（URN）はこれだったから、新旧を同一視せよ」と教え込む。
TypeScriptでの実践例
以下の例では、S3バケットの論理名を `data-bucket` から `core-storage` へリファクタリングする。同時に、親スタックの構造変更に伴い、親モジュールのパス（Parent）や名前空間が変わったケースも想定する。
import as pulumi from “@pulumi/pulumi”;
import as aws from “@pulumi/aws”;
// リファクタリング後
export class StorageStack extends pulumi.ComponentResource {
public readonly bucket: aws.s3.Bucket;
constructor(name: string, args?: pulumi.ResourceOptions) {
super(“pkg:index:StorageStack”, name, {}, args);
this.bucket = new aws.s3.Bucket(“core-storage”, { // 論理名を変更
bucket: “my-company-core-storage-prod”,
acl: “private”,
}, {
parent: this,
// 致命的な再作成を防ぐためのAliases定義
aliases: [
// 1. 単純な論理名（URNの名前部分）の変更に対応
{ name: “data-bucket” },
// 2. モジュール階層やParentが変わった場合（完全な旧URNを指定することも可能）
{
name: “data-bucket”,
parent: this, // 過去の親リソースコンテキスト
// urn:pulumi:prod::my-proj::pkg:index:StorageStack$aws:s3/bucket:Bucket::data-bucket のような旧URNも指定可能
}
]
});
}
}
エキスパートの知見：Aliasesの網羅性と罠
`aliases` を記述する際、過去にさかのぼった全てのエイリアスを記述する必要がある。過去に何度かリネームを繰り返しているリソースの場合、配列の末尾に古い履歴を積み上げていく必要がある。これを怠ると、中間のリネーム履歴を持つ環境で予期せぬ再作成が走るため注意せよ。
—
3. アプローチB：`pulumi state` による外科手術的ステート書き換え
コードに汚染（エイリアスのハードコード）を残したくない場合や、すでにデプロイ済みの本番環境で急遽リソース名を変更し、エイリアスを書き忘れて `pulumi up` を走らせてしまった場合の最終手段（Emergency Protocol）が、ステートの直接操作である。
1. 現在のステートのエクスポート
まず、バックエンドのステートをローカルのJSONファイルに安全に吸い出す。
pulumi stack export –file stack-backup.json
※鉄則：このバックアップファイルは、いかなる場合でも最初に退避させておくこと。
2. `pulumi state rename` コマンドの活用
Pulumi CLIには、ステート内のURNを安全に変更するためのビルトインコマンドが用意されている。
pulumi state rename
pulumi state rename \
“urn:pulumi:prod::my-project::aws:s3/bucket:Bucket::old-name” \
“urn:pulumi:prod::my-project::aws:s3/bucket:Bucket::new-name”
このコマンドは、単なるテキスト置換ではなく、ステートの整合性（グラフ構造）を検証した上で安全にURNを書き換える。
3. 大規模リファクタリングにおけるステート直接ハック（JSON編集）
モジュールの分割や、親リソース（ComponentResource）の導入・廃止によってURN構造が複雑に変化した場合、CLIの `rename` だけでは追いつかないことがある。その場合は、エクスポートしたJSONを直接書き換える。
1. ステートのエクスポート
pulumi stack export –file state.json
2. JSON内のURNを一括置換（jqやsed、あるいはカスタムスクリプトを使用）
例: “aws:s3/bucket:Bucket::data-bucket” を “aws:s3/bucket:Bucket::core-storage” へ
jq ‘.deployment.resources |= map(.urn |= gsub(“data-bucket”; “core-storage”))’ state.json > state-fixed.json
3. 依存関係のチェック（親URNや依存先URNの不整合がないか確認）
ここで他のリソースの `dependencies` 配列内のURNも一致させる必要がある点に注意！
4. ステートのインポート
pulumi stack import –file state-fixed.json
警告: JSONの手動編集はインフラエンジニアにとっての「ロシアンルーレット」である。依存関係（`dependencies`）や親プロパティ（`parent`）の整合性が1箇所でも崩れると、次回の `pulumi up` でステート破損エラー（Corruption Error）を引き起こす。実行前には必ずテスト用の非本番スタックで検証すること。
—
4. 完全に自動化されたパイプラインのためのセーフティ・ガードレール
手動のステート操作や、開発者のうっかりミスによるダウンタイムをCI/CDパイプラインレベルで完全に根絶するためには、「Policy as Code (Pulumi Policy / OPA)」を導入するべきだ。
以下は、リソースの再作成（Delete & Create）を検知した瞬間にパイプラインを強制終了させる、Pulumi CrossGuard（Policy Pack）の極秘実装コードである。
`index.ts` (Policy Pack)
import { PolicyPack, ResourceValidationPolicy } from “@pulumi/policy”;
const preventResourceReplacement: ResourceValidationPolicy = {
name: “prevent-unplanned-resource-replacement”,
description: “本番環境での意図しないリソースの削除・再作成（Replacement）をブロックします。”,
validate: (args, reportViolation) => {
// スタック名が本番環境であるかチェック
const stackName = pulumi.getStack();
if (!stackName.includes(“prod”)) {
return;
}
// ライフサイクルや差分を解析し、この操作が「置換（Replacement）」を伴うか判定
// Pulumiのバリデーションコンテキストでは、置換フラグや計画された変更を検知可能
// ※実際の実装ではpreview時のDIFF情報をフックするか、customTimeouts等を監視
// 例: 特定のクリティカルなリソースタイプ（RDS, S3, DynamoDB等）の削除を検知
const criticalTypes = [
“aws:rds/instance:Instance”,
“aws:s3/bucket:Bucket”,
“aws:dynamodb/table:Table”
];
if (criticalTypes.includes(args.isType)) {
// ここで過去のURNからの変更で aliases が定義されているか、
// あるいは意図的な置き換えフラグが立っていないかを検証する
// （※詳細なDiff解析ロジックはエンジニアのユースケースに応じて拡張）
}
},
};
new PolicyPack(“production-guardrails”, {
policies: [preventResourceReplacement],
});
これを組織のCI/CDパイプラインに組み込むことで、開発者がどんなに雑なリネームをしてPRを出したとしても、マージ前段階で自動的にブロックされる要塞が完成する。
—
5. 結論：真のSREは「破壊」を許さない
インフラストラクチャのコード化が進むにつれ、コードの美しさ（綺麗な命名規則、モジュール設計）と、インフラの継続性（無停止稼働）がコンフリクトする場面は数多く訪れる。
その際、安易に `pulumi up` の結果を受け入れ、クラウド上の実リソースを巻き添えにするようなエンジニアは、もはや「インフラエンジニア」とは呼べない。ただのツール実行者だ。
今回解説した `aliases` による宣言的防衛と、`pulumi state` による外科手術的介入、そしてPolicy as Codeによる自動化の防壁。これらを手の内に入れた者だけが、コードベースの美しさと、本番環境の絶対的可用性を両立させるという「エンジニアリングの極致」に到達できる。
さあ、今すぐ手元のコードベースを見直し、恐怖の「- / +」が潜む地雷原を掃海せよ。