こんにちは！クラウドインフラ・SREの世界へようこそ。
日々、AWSやGCP、Azureなどのクラウド環境をコードで管理（IaC：Infrastructure as Code）していると、こんな恐怖に襲われたことはありませんか？
- 「うっかり `pulumi destroy` を叩いてしまい、本番データベースが消えかけた…」
- 「KubernetesのコントローラーやAWSの自動タグ付け機能が勝手にリソースを書き換えるせいで、`pulumi up` するたびに差分（diff）が出てイライラする…」
IaCは魔法の杖のようにインフラを自動化してくれますが、扱い方を一歩間違えると、「たった1行のコマンドミスで会社が傾く大惨事」を引き起こす諸刃の剣です。
今回は、そんな絶望からあなたを守り、毎日のデプロイを心穏やかなものにしてくれるPulumiの最強の盾「Resource Options（`protect` と `ignoreChanges`）」について、現場の生きた知見を交えて優しく徹底解説します。
これをマスターすれば、うっかりミスや外部からの勝手な変更におびえる日々から解放されますよ！
—
1. 意図しないリソース削除や変更が起きる原因と怖さ
まずは、「なぜインフラは壊れてしまうのか」そのメカニズムをサクッと整理しておきましょう。
IaCツール（PulumiやTerraformなど）は基本的に、「コードの状態（Desired State）」と「実際のクラウド上の状態（Actual State）」を常に一致させようと動きます。非常に優秀な反面、以下のようなシーンで牙を剥きます。
1. コードからのうっかり削除: チームメンバーがリソース定義をコードから消し、それに気づかずにレビューしてマージしてしまった。
2. コマンドの暴発: ステージング環境のつもりでターミナルのタブを間違え、本番環境で `pulumi destroy` を実行してしまった。
3. 外部ツールによるドリフト（Drift）: AWSのAuto ScalingやKubernetes、あるいは別の管理ツールが勝手につけたタグや設定を、Pulumiが「コードと違う！直さなきゃ！」と勘違いして上書きしてしまう。
こうした「ヒューマンエラー」や「システム間の競合」を防ぐために、Pulumiにはリソースごとに個別設定できるResource Optionsという強力な防御機構が備わっています。
—
2. Pulumiの基本セットアップとHelloWorld
「まだPulumiに触ったことがないよ」という方のために、サクッと環境を整えて、今回の主役を試す準備をしましょう。
インストール
MacであればHomebrewで一発です。
brew install pulumi
プロジェクトの初期化
適当なディレクトリを作って、TypeScriptでプロジェクトを初期化してみましょう（PythonやGoでも考え方は同じです）。
mkdir pulumi-guard-demo && cd pulumi-guard-demo
pulumi new aws-typescript –dir . –yes
これだけで、`index.ts`（メインのコード）を含む雛形が生成されます。
それでは、本題である2つの鉄壁の防御策を見ていきましょう。
—
3. `protect` オプションによる重要リソースの削除ガード実装
最初に紹介するのは、最も恐ろしい「リソースの誤削除」を防ぐ `protect: true` です。
本番用のRDSデータベースやS3バケットなど、「これだけは絶対に消えてはいけないリソース」にこのオプションを付与します。
コード例：S3バケットを絶対に消させない
`index.ts` を以下のように書き換えてみてください。
import as pulumi from “@pulumi/pulumi”;
import as aws from “@pulumi/aws”;
// 絶対に削除してはならない重要なお財布データを保存するバケット
const secureBucket = new aws.s3.Bucket(“critical-finance-bucket”, {
bucket: “my-super-important-finance-data-2026”,
}, {
// 🔑 ここがキモ！削除ガードを有効化
protect: true,
});
export const bucketName = secureBucket.id;
実際にどうなるか試してみる
1. `pulumi up` でバケットを作成します。
2. その後、コードからこのリソースの記述をまるごと削除するか、`pulumi destroy` を実行してみてください。
通常ならここでリソースが消滅しますが、`protect: true` が設定されていると、Pulumiは次のようなエラーを吐いて処理を強制停止します。
> error: preview failed: resource urn:pulumi:dev::… is protected and cannot be deleted
「おっと、危ない！」とここで気づくことができます。
もし本当にこのリソースを削除したい場合は、一度コード側で `protect: false` に書き換えて `pulumi up` で保護を解除してからでないと消せない仕様になっています。この「ワンクッション」が、あなたのキャリアと会社の信頼を守ってくれるのです。
—
4. `ignoreChanges` を使った外部自動変更の検知・無視設定
続いて紹介するのは、実務で一番遭遇率が高い「外部ツールや手動変更による差分（ドリフト）のノイズ」を華麗にスルーする `ignoreChanges` です。
例えば、AWSのECSタスク定義やLambda関数などは、CI/CDパイプライン（GitHub Actionsなど）や別のデプロイツールによって、イメージタグ（`image` の中身など）が勝手に書き換えられることがよくあります。
この時、Pulumiのコード側が古いイメージタグを知っていると、`pulumi up` するたびに「最新のイメージを古いものに戻そうとする」という大迷惑な上書きが発生してしまいます。
コード例：タグの勝手な変更を無視する
import as pulumi from “@pulumi/pulumi”;
import as aws from “@pulumi/aws”;
const appServer = new aws.ec2.Instance(“app-server”, {
ami: “ami-0c55b159cbfafe1f0”,
instanceType: “t3.micro”,
tags: {
Environment: “Production”,
// 誰かがAWSコンソールから手動で変えるかもしれないオーナー情報
Owner: “sre-team”,
},
}, {
// 🔑 外部で変更されるプロパティをPulumiの監視対象外にする
ignoreChanges: [“tags.Owner”],
});
これで、AWSコンソール上から誰かが `Owner` タグを勝手に `oss-team` に書き換えても、Pulumiは「お、好きにやってるね、ここは俺は口出ししないよ」と無視してくれます。
CI/CDでデプロイメントツールが動的に書き換えるプロパティ（Dockerイメージのハッシュ値など）を指定するのにも必須のテクニックです。
—
5. 実務でよくあるトラブルを防ぐためのベストプラクティス集
最後に、現場のSREたちが実践している、Resource Optionsを運用するための知見をいくつかシェアします。
1. ライフサイクル管理の原則として最初から `protect` を入れる
- 本番環境のデータベース、KMSキー、永続ボリューム（EBSなど）は、「作った瞬間から `protect: true` をデフォルトにする」くらいの気構えでいきましょう。ポリシー・アズ・コード（Pulumi CrossGuardなど）を使って、特定のタグを持つリソースには自動で `protect` を強制する仕組みを作るのもおすすめです。
2. `ignoreChanges` は「逃げ道」ではなく「共存の技術」
- 何でもかんでも `ignoreChanges` で無視していると、IaCのメリットである「コードを見ればインフラの全てが分かる」という状態が崩壊します。外部ツールと連携せざるを得ないピンポイントなプロパティ（イメージタグやオートスケーリングの現在値など）に絞って使いましょう。
—
まとめ
今回は、PulumiのResource Optionsである `protect` と `ignoreChanges` について解説しました。
- `protect: true` で、うっかりミスや誤操作によるリソースの消滅を物理的にブロックする。
- `ignoreChanges` で、外部システムや手動変更による無駄な差分（ノイズ）をシャットアウトする。
この2つを適切にコードに組み込むだけで、あなたの管理するクラウドインフラの堅牢性は跳ね上がります。明日からのデプロイが、少しでも安心して行えるようになれば幸いです。
それでは、素晴らしいインフラライフを！