この記事の結論
容量を抑えるために自動削除は有効な手段ですが、先に消してよい条件が必要です。利用目的、保存期間、例外を整理し、対象が正しいと確認できてから自動化します。
保存する理由と期限の起点を決める
作成日から何日なのか、最終更新日から何日なのかで対象は変わります。業務上の必要期間、契約上の保持条件、調査中の保存などを担当部門と確認します。単に古いという理由だけで消さず、保管責任者と削除判断の根拠を残します。個別の法定保存期間は本記事では判断しません。
階層変更と削除を別ルールとして考える
Azure Blobのライフサイクル管理には階層変更や削除のルールがあります。使われなくなったデータを低頻度向けへ移すことと、復元できない状態まで消すことは影響が違います。現在の版、古い版、スナップショットをそれぞれどう扱うかを設計します。
対象を小さく絞って検証する
名前の接頭辞やタグなどの条件を確認し、意図しないデータが含まれていないか一覧で照合します。Azureのフィルターは対象を含める条件として扱われるため、除外したつもりのデータに作用しないか注意します。最初は専用の検証領域や小さな対象で挙動を確かめます。
停止と例外の扱いを先に決める
ルールの変更や停止が直ちに全ての処理へ反映されるとは限りません。異常を見つけたときの停止手順と連絡先を用意します。削除保護が有効なら削除後も保持期間中の容量が残る場合があり、想定どおりに費用が減るかも確認します。例外データを別の管理対象へ分ける判断も必要です。
| 項目 | 決める内容 | 検証 |
|---|---|---|
| 対象 | コンテナー・接頭辞・タグ | 予定対象の一覧と照合 |
| 時間 | 作成・更新・アクセスの起点 | 境界日のサンプルで確認 |
| 例外 | 調査中・業務継続に必要なデータ | 誤って対象に入らないこと |
導入・見直しのチェックリスト
- 消してよい根拠と期限の起点を決めたか
- 現在版・履歴・例外を分けたか
- 対象と停止時の挙動を検証したか
参考資料と確認範囲
- Microsoft：Blobライフサイクル管理 — 条件・フィルター・処理の実行と削除保護との関係。