Storage Actionsの定義更新が既存割り当てへ自動反映：次回実行と停止後の処理を検証する

結論　共有定義の変更を全割り当てのリリースとして扱う

【編集上の判断】IaCやポータルでタスク定義を保存する前に、全参照先の影響をレビューしてください。対象アカウント、包含・除外プレフィックス、条件、操作、次回実行、実行ID、レポート保存先を対応付けた変更票を用意します。

【編集上の受入条件】変更前後で処理されるはずのBLOBと、対象外として保持すべきBLOBの一覧を作ります。試験環境で条件の一致と操作結果を照合し、共有先ごとのデータ所有者が結果を承認してから本番へ反映する方法を提案します。

背景と技術的要因　定義と実行のタイミングを追跡する

【確認済み事実】Azure Updatesは、定義更新の自動反映と進行中実行の停止要求を一般提供として案内しています。停止は個別割り当ての実行、またはタスクに関連する全割り当ての実行へ要求でき、非同期で処理されます。

【確認済み事実】日本語の割り当て資料では、条件・操作の更新が関連割り当てへ伝播し、定期実行は次回から更新版を使うと説明しています。すでにキューに入った実行や進行中実行は旧定義を使います。

【編集上の分析】保存後には旧定義で動く実行と新定義で動く実行が並存し得ます。調査時に現在の定義だけを見ると、処理された対象を再現しにくくなるため、変更時刻、変更前後の定義、各実行の受付・開始・終了を一組で保全します。

公表・更新日と対象リソース

【確認済み事実】Azure UpdatesのAdded to roadmapとLast modifiedはいずれも2026-11-02です。この記事では告知の登録・更新日として記録します。全リージョンへの適用完了日、一律の強制切替日、非推奨化期日は確認できずnullです。記事公開日・確認日は2026-11-07です。

【確認済み事実】タスク定義の管理対象はMicrosoft.StorageActions/storageTasks、割り当てはMicrosoft.Storage/storageAccounts/storageTaskAssignmentsです。割り当ては対象オブジェクトの範囲、実行スケジュール、レポート保存先を持ちます。根拠は割り当て資料とAzureロール資料です。

【編集上の実装確認】今回の告知で必須のREST API版やSDK最低版は確認できずnullとします。利用するTerraform/Bicep、CLI、SDKごとに、停止操作や割り当て属性を扱える版を実際のリファレンスと検証環境で確認してください。

アーキテクチャ・IaC・権限の確認事項

【編集上の設計パターン】候補定義は独立したタスクとして検証し、本番の共有定義を試験用に書き換える工程を避けます。変更単位を分ける必要があるアカウント群はタスク自体を分け、単一の共有定義を更新したまま割り当てごとに旧定義へ固定できるとは仮定しません。

【確認済み事実】割り当てのモック実行はスコープ内のBLOBを評価してレポートを生成し、データ操作を行いません。実行する操作の権限はタスクのマネージドIDに付与します。公式ロール資料はStorage Actions Blob Data Operatorを推奨しています。

【編集上の試験案】新しいモック割り当てで条件の対象を確認し、続いて少量の検証データで実操作を試します。対象が一致しても権限や保護設定で操作に失敗し得るため、削除、階層変更、タグ変更など実際に使う操作ごとに成功・拒否を確認します。

【編集上のIaC確認】planまたはwhat-ifで条件・操作の差分を確認し、全割り当てを別途列挙して次回実行と照合します。デプロイ差分に割り当ての更新が出ていなくても、定義の自動反映による処理対象をレビューします。操作追加時は各アカウントのID権限とネットワーク条件を確認し、権限変更の承認者を記録します。

運用・監視・停止・復旧の技術論点

【確認済み事実】実行レポートは割り当てで指定した対象アカウントのコンテナーへ保存され、BLOB、操作、結果、エラーコード等を確認できます。結果にはSuccess、Failed、条件不一致のN/Aがあります。根拠はタスク実行の分析資料です。

【編集上の停止手順】停止対象を個別実行と全参照先のどちらにするか決め、要求時刻と対象を記録します。停止要求の受付後も実行状態とデータの変更を追跡し、処理済み、未処理、結果不明を区別して再開範囲を決めます。停止による処理済み操作の取消しや復元は、今回の告知で保証を確認できず未確認とします。

【編集上の監視案】新定義の初回実行では、対象件数、操作成功・失敗、対象外データの保持、レポート到着を照合します。停止途中の実行についてレポートが得られない場合にも備え、実リソースとデータ所有者の確認記録を残してください。条件を元に戻した後も、キュー済み実行の定義を個別に追跡します。

【編集上の復旧試験】誤操作を想定し、利用するデータ保護方式からの復元を検証用BLOBで実測します。DR先ではタスク、割り当て、ID、通信、対象プレフィックス、次回スケジュールを照合し、再実行が二重の変更を起こさないか試験します。

【編集上の責任分界案】基盤担当が共有定義と参照先を管理し、データ所有者が対象と操作を承認し、運用担当が停止・復旧・再開の証跡を残します。委託先の変更完了には、全参照先の初回実行と通知確認を含めることを提案します。

【適用上の前提】本記事は個別環境の設計保証や法的助言を行うものではありません。実装適用にあたっては検証環境での事前テストおよび契約・業務範囲の確認が必要です。以下のチェックリストは編集上の提案です。