皆さま、こんにちは！
このテックブログでは、IT運用に関する内容を連載、「にこぷす通信」をお届けしています。

1. はじめに：「あ、VM消し忘れてた…」をゼロにするには

「ちょっと動作確認するために、大きめのスペックでVMを立てておこう」

「今日はもう遅いし、あとで消せばいいか……」とそのまま放置。

しかし、他の業務に追われて気づけば数日〜1週間。「あ、あの検証環境ずっと消してなかった……！」と請求アラートを見て冷や汗をかく。

インフラエンジニアやクラウド管理者なら、一度はヒヤッとした（あるいは実際にやらかしてしまった）苦い経験があるのではないでしょうか？

怖いのは大物だけじゃない。「ちりつも」で膨らむ無駄な費用

実は本当に恐ろしいのは、一度の大きなポカミスだけではありません。「1日数百円程度の小さな検証用VM」や「消し忘れた未使用のディスク・IPアドレス」といった、一見目立たないリソースの放置です。

チームメンバーそれぞれが「これくらいなら大丈夫だろう」と放置した小さなリソースが毎月・全社で積み重なると、まさに“ちりつも”でバカにならない金額の無駄コストへと化けていきます。

開発環境や検証環境の「消し忘れ」による無駄な課金問題は、クラウド運用で誰もが頭を悩ませるポイントです。

「気をつけて消す」ルールは絶対に破られる

「作ったリソースは各自責任を持って削除すること！」

どれだけ社内ルールで周知徹底しても、作業が終われば解放感でつい消し忘れてしまうもの。定期的にSlackやメールで「使っていないリソースは消してください」と呼びかける運用は促す側も、促される側も地味にストレスが溜まりますよね。

ルールや手動の運用（個人の意識）に頼った消し忘れ防止策には限界があります。

放置環境をゼロにする「Auto-destroy（自動削除機能）」

「じゃあ、時間が来たら自動で消してくれればいいのでは？」

そんな放置リソース問題をスマートに解決してくれるのが、HCP Terraformに備わっている「Auto-destroy（自動削除機能）」です！

指定した日時が来たら自動で terraform destroy を実行してくれるのはもちろん、「最後の操作から〇時間経過したら自動破棄」といった柔軟な設定も可能です。開発者が後片付けを意識しなくても、時間が来れば環境を綺麗さっぱり削除してくれます。

今回は、この便利な「Auto-destroy」の基本機能や事前通知の仕組みはもちろん、あえて削除に失敗させてみた時の泥臭い挙動検証、さらには開発環境へ自動で自動削除を仕込むガバナンスの手法まで、ガッツリ検証していきます！

2. Auto-destroyの基本設定と通知（Notifications）の仕込み

指定した時間が来たら勝手にリソースを削除してくれる「Auto-destroy」。 まずは基本的な設定手順と、実際の運用で役に立つ「通知（Notifications）」の仕込みについて解説します。

基本設定：設定はボタン数クリックで完了！

Workspace単体で設定する場合の手順は非常にシンプルです。

1. HCP Terraformで対象の Workspace を開く
2. 左メニューの Settings ➔ Destruction and Deletion を選択
3. 「Automatically destroy」 の項目にある Set up auto-destroy ボタンを押す

削除のルールは以下の2パターンから選べます。

• Destroy at specific time（日時指定）
  • プリセット（1, 2, 3, 7, 14 日後）から選ぶか、Custom で任意の日時をピンポイントで指定
  • 「今週金曜の18:00に削除」「来週の月曜朝に削除」といったイベントや検証期間が決まっている場合におすすめ
• Destroy if inactive（非アクティブ時間で指定）
  • プリセット（1, 2, 3, 7, 14 日後）のほか、Custom で 1〜9999時間（または日） という非常に柔軟な時間を設定可能
  • 最後のState更新（apply など）からの経過時間で判定

例）Destroy at specific time でCustomを選択した場合

短期集中で試したい時は「〇時間無操作で削除」、特定のイベントや検証期間が決まっている時は「日時指定」と使い分けると便利です。

---

💡 Projectで一括設定する？ Workspace個別に設定する？

Auto-destroyは「Project単位」と「Workspace単位」のどちらでも設定できます。組織のプロジェクト管理方針に合わせて、適切に使い分けるのがポイントです。

• プロジェクトを「環境別」で分けている場合（例：Project-Dev / Project-Stg / Project-Prd のように分割）
  • 開発専用の Project-Dev に対してProjectレベルでデフォルト設定を入れておきます。配下に作られる開発Workspaceすべてに自動で適用されるため、設定漏れを防ぎつつ安全に運用できます。
• プロジェクトを「システム/サービス別」で分けている場合 （例：Project-ECsite の中に dev-ws と prod-ws が同居）
  • Projectレベルで一括設定してしまうと、本番（Prod）環境まで勝手に自動削除対象になってしまい大変危険です！この場合は必ず開発用Workspaceだけピンポイントで個別設定を行いましょう。

なお、プロジェクトレベルではプロジェクトのSettingsからAuto-destroy workspaceを選択できますが、こちらは経過時間の設定のみとなっています。

🔔事前リマインドで不意打ちを防ぐ！

「知らないうちに勝手に消えていた…」という不意打ちを防ぐため、通知の設定もセットで行っておきましょう。

Workspaceの Settings ➔ Notifications からWebhook（Slackなど）やメールの通知を作成し、Notification Triggers でAuto-destroy関連のイベントにチェックを入れるだけで設定完了です。

これを仕込んでおくと、以下のタイミングで自動的に通知が飛んできます。

• 24時間前・12時間前: 「そろそろ自動削除されますよ」という事前リマインド
• 実行完了時 / エラー発生時: 「無事に削除されました」「削除に失敗しました」という結果報告

24時間前や12時間前にリマインドが届いてくれれば、「あ、まだ検証中だから削除時間を延ばさなきゃ！」と気づいて延命処理をすることも可能です。

これで準備は万全です。次の章からは、いよいよ実際の自動削除の挙動と、あえてエラーを起こしてみた泥臭い検証に入っていきます！

3. 【検証】自動削除を実行！あえて「削除失敗」を起こしてみた

設定と通知の準備が整ったので、いよいよ実際の自動削除（Auto-destroy）の挙動を検証していきます。

今回は「正常に消えるパターン」だけでなく、「消えたと思って安心していたら、裏でエラーになっていて課金が続いていた…」というハマりパターンを再現するため、あえて削除が失敗するトラップを仕掛けてみました！

---

🔹 正常系：時間が来たら裏で自動 destroy！

まずは基本の正常系です。 指定した削除日時（または最後のState更新からの経過時間）を迎えると、HCP Terraform上で自動的に Auto-destroy の Run がトリガーされます。

• 手動で画面のボタンを押さなくても、バックグラウンドで terraform destroy がスタート
• 処理が成功するとリソースが綺麗さっぱり削除され、Workspaceのステータスもクリーンな状態に
• 事前に設定した通知（Slackやメール）へ「Auto-destroy Run Succeeded（自動削除完了）」の通知が届く

「後片付けを忘れて帰宅しても、夜のうちに勝手に消えて完了報告まで届く」という、理想的な放ったらかし運用が確認できました。

💡 【実機検証の裏話】事前通知でプチ事件？24時間前のはずが「25時間前」に届いた謎

実際に設定して通知を待っていたところ、ちょっと面白い発見がありました。

24時間前のリマインドメールを待っていたのですが、なぜか予定の25時間前にメールが飛んできたのです。

「あれ、1時間ズレてる……？」と一瞬焦りましたが、どうやらタイムゾーンやサマータイムの内部計算が影響している模様。「まあ、前もって教えてくれる分にはセーフ！」ということで、事前通知の仕組み自体はしっかり機能していることが確認できました（笑）。

⏱️ 30分後設定でリトライ ➔ 今度はバッチリ時刻通り！

1日前（24h前）の通知が機能することは確認できたので、次は自動削除そのものの挙動を確かめるため、削除時間を「30分後の時刻」に再設定して待機してみることに。

すると今度は、狙った時刻ぴったりに削除が実行されました！

そして、こっちのメールはちゃんと時刻通りに届いてるんですね。。

また、Run側のステータス通知メール（Auto-destroy run succeeded） も漏れなく届いていました。

事前リマインドから実行完了の報告まで、一連の監視フローが完璧に繋がっているのが確認できて一安心です！

🔹 異常系：中身のあるストレージバケットで「削除失敗」を再現！

続いて本題のトラップ検証です。

クラウド運用でよくある「Terraformでは消せない状態」を作り出してみます。

💣 トラップの仕込み

1. Terraformで Google Cloud のストレージバケットを作成（※force_destroy = false のデフォルト状態）
2. コンソールから、そのバケットの中にテストファイルを1つアップロードしておく
3. この状態で Auto-destroy の時間を待つ！

Cloud Storage のバケットは、安全のため「中身（オブジェクト）が空でないとバケット自体を削除できない」（Cloud Consoleからは削除できます）という制約があります。この状態で自動削除が走るとどうなるでしょうか？

以下のようにバケットにファイルをアップロードした状態で自動削除を実行します。

---

🔍 実行結果：エラーで停止し、即座にSOS通知が飛んできた！

予定時刻になると自動削除が走りましたが、狙い通りGCSのAPI側からエラーが返され、処理が途中でストップしました。

HCP Terraformの画面上も Errored 表示になり、削除が不完全な状態で止まっています。

💡 ここで活きる「エラー通知」！

「消えたと思って放置していたら課金が続いていた」となると問題ですが、事前に Notifications を設定していたため、エラーが発生した直後にリソース削除失敗の通知がメールで届きました！

• Workspace Events：Auto-destroy results（左側）
• Run Events：Needs Attention（右側）

失敗したこと自体が管理者（担当者）に即時通知されるため、「消し忘れ」が「気づかない放置」に化けるのを防ぐことができます。

自動削除機能の真価は、単に「勝手に消してくれること」だけではありません。万が一リソースの依存関係や制約で失敗したとしても、「失敗したよ！」と運用者（担当者）にSOSを出してくれるガードレールが機能することこそが、運用上の最大の安心感と言えますね！

次の章では、この便利な自動削除を「開発者の善意に頼らず、システムで強制適用させるガバナンスの手法」を掘り下げていきます！

4. 手をかけずに強制する！ガバナンスと仕組み化

どれだけ便利な機能であっても、開発者に「環境を作ったら各自でAuto-destroyを設定してね！」とマニュアルでお願いしているうちは、いつか絶対に設定漏れが発生します。

運用ルールの遵守だけに頼るアプローチを脱却し、「開発者に意識させず、システム側で強制適用させる仕組み」をどう作るかが、クラウド管理者の腕の見せ所です。

ここでは、コードを使って自動的に削除ルールを仕込む具体的なガバナンス手法をご紹介します。

---

🔹 Workspaceの払い出し自体をコード化する（tfe プロバイダー）

最も確実で実用的なのが、HCP TerraformのWorkspace自体をTerraformコードで払い出す「tfe プロバイダー」を活用した運用です。

tfe プロバイダーを使うメリットは、単に「自動削除タイマー」を仕込めることだけではありません。「コスト追跡用の共通タグ」や「全環境で必須となる共通変数・ラベル」もセットで自動注入・標準化できる点にあります。

💡 実践パターン：標準Workspaceテンプレートで一元管理

私たちのプラットフォーム運用でも、開発チームから「検証環境が欲しい」とリクエストがあった際、手動で作らせるのではなく、プラットフォームチームが用意した標準払い出しコードを通してWorkspaceをプロビジョニングしています。

以下は社内のコードをもとに、分かりやすく簡略化したサンプルです。

• 共通変数（tfe_variable）: クラウドの共通リージョン設定や環境識別ラベル
• 自動削除タイマー: State更新から24時間無操作で自動削除
• 共通タグ（tag_names）: コスト分析や所有者特定用のタグ（env:dev, auto-destroy:enabled など）

# 1. Workspaceの作成（自動削除 ＆ 管理用共通タグをセット）
resource "tfe_workspace" "dev_workspace" {
  name         = "dev-app-environment"
  organization = "your-org-name"
  project_id   = tfe_project.dev_project.id

  # 最後のState更新から24時間無操作で自動削除（Auto-destroy）を強制
  auto_destroy_activity_duration = "24h"

  # コスト管理や所有者特定のための共通タグを標準で強制付与
  tag_names = ["env:dev", "managed-by:platform-team", "auto-destroy:enabled"]
}

# 2. 全環境で共通設定すべき変数（ラベル・クラウド共通設定など）を自動注入
resource "tfe_variable" "common_env" {
  key          = "ENVIRONMENT"
  value        = "development"
  category     = "terraform"
  workspace_id = tfe_workspace.dev_workspace.id
  description  = "プラットフォーム側で自動強制注入する環境ラベル"
}

このようにセットしてWorkspaceを払い出すことで、開発者が何も意識しなくても「自動削除タイマー・コスト管理タグ・共通設定」がすべて最初から組み込まれた安全な環境を手に入れることができます。

手動での設定忘れや「タグが付いていなくて誰のVMかわからない」といった野良リソース問題も、根本から一発で解決できます！

🔹 さらに固めるなら：Policy as Code（Sentinel / OPA）や No-Code Provisioning

さらに高度なガバナンスを目指す場合は、以下のようなHCP Terraformの機能を組み合わせるのも効果的です。

• Policy as Code（Sentinel / OPA）でのガードレール
  • 「Auto-destroyが設定されていないWorkspaceからの apply はポリシー違反（エラー）として弾く」というチェックルールを組織全体に適用します。万が一設定を解除されても、実行をブロックして安全を保ちます。
• No-Code Provisioning ＋ RBAC（権限管理）での標準化
  • 開発者チームに対して「あらかじめ自動削除ルールを設定した開発用プロジェクト（例: Project-Dev-Sandbox）」だけを選択・作成できるように権限（RBAC）で絞り込んでおくのがポイントです。
  • 開発者には「タイマー付きの安全なプロジェクト」しか見えない状態になるため、インフラ知識がない開発者でも設定漏れや誤操作を起こすことなく、安全にセルフサービス利用できるようになります。

💡 ガバナンスの鉄則：「お願い」ではなく「仕組み」で縛る

クラウドの運用管理において、個人の善意やマニュアル遵守だけに頼った運用は、どうしても限界が来ます（事故が防げません）。

「消し忘れないように気をつける」のではなく、「勝手に消える仕組み（コード）の中に環境を作る」。

上位のProject設定や tfe プロバイダーを活用して自動削除ルールを標準組み込みしておくことこそが、放置リソースゼロを実現する最大のポイントです！

5. まとめ

HCP Terraformの「Auto-destroy（自動削除機能）」を使えば、放置リソースの悩みをいかにスマートに解決できるかが見えてきましたね。最後に重要ポイントを整理しておきます！

• 「ルールで気をつける」のではなく「勝手に消える仕組み」にする
  • 開発者の善意やマニュアル遵守に頼る運用には限界があります。「日時指定」や「最後のState更新から◯時間無操作で削除」といった自動削除ルールをセットし、後片付けを意識しなくても環境が勝手にクリーンアップされる状態を作りましょう。
• 事前リマインドとエラー通知で「二重の安心感」
  • 事前通知（24時間前/12時間前）でまだ使う環境の延命（スケジュール変更や Refresh-only run でのタイマーリセット）が可能なほか、万が一ファイル残留などで削除が失敗しても、エラー通知が即座にSOSを出してくれるため「消したつもりが課金され続けていた」という隠れ放置リスクを防げます。
• 上位設定 ＆ コード化（tfe プロバイダー）で設定漏れを根本排除
  • Projectレベルでのセーフティネット（保険）設定をはじめ、tfe プロバイダーによる標準払い出し（自動削除タイマー ＋ 共通タグ ＋ 共通変数）、さらにはNo-Code Provisioning ＋ RBAC（権限管理）で「タイマー付きプロジェクトしか選べない状態」を作ることで、開発者に負担をかけずにガバナンスを徹底できます。

ルールでガチガチに縛るのではなく、「安全なガードレールの中で開発者が自由に・安心して検証できる環境」を作れるのが Auto-destroy の最大の強みですね！

6. 次回予告

次回はいよいよ連載最終回！「【第6回】セキュリティはCI（Checkov）で、お財布事情はSentinelで。賢い使い分けとSentinelを動かしてみた」をお届けします！

最終回では、Policy as Code（Sentinel）を用いたコストガードレールの実機検証に加えて、CheckovをはじめとするCIツールとの使い分けや設計ポイントを解説します。

さらに、全6回の締めくくりとして、これまでの検証（ドリフト検知、Auto-destroy、Sentinel）を振り返る「HCP Terraform Premium検証の総まとめ」もあわせてお届け！「結局Premiumプランは買いなのか？」「どんな組織なら元が取れるのか？」についてズバッと総括します。

💡（おまけ） ちなみに、今回の連載本編（全6回）に収まりきらなかった注目の機能（Run Tasks、Stackなど）についても、後日「番外編」としてお届けする予定です！

まずは次回、連載本編のフィナーレをどうぞお見逃しなく！

「にこぷす通信」について

「NIC × Ops（にこぷす）通信」は、隔週で皆さまに情報をお届けします。
このシリーズでは、Instana（可観測性）をはじめ、Turbonomic（リソース最適化）やTerraform（インフラ自動化）など、IT運用を劇的に変える製品をピックアップしていきます。
これからも最新の技術検証をチームで継続し、皆さまの現場ですぐに役立つ「有益な知見」を全力で共有していきます。 次回の連載もお楽しみに！