こんにちは、ストレージ運用で「これ消して大丈夫かな...」が毎回ちょっと怖いアーキテクトのやまぱん！です 😅
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！
TL;DR
- Azure Storage Actions は、Azure Blob Storage / Azure Data Lake Storage に対するデータ管理操作を、ノーコード寄りに自動化できるフルマネージドサービスです
- 2026/05 に Mock run が GA になり、本番スコープ全体を non-destructive に検証 できるようになりました
- Condition preview が 5,000 blob までのスポット確認なのに対して、Mock run は assignment scope 全体を非同期で評価し、CSV と summary JSON を出してくれます
- ただし 無料ではありません。Task execution instance と objects scanned は課金されます
- さらに、1 つの storage account では mock / real を含めて同時実行は 1 本だけ、完了済み Mock run の再実行もできません
先に結論
Mock run は、Azure Storage Actions を本番投入する前に 1 回止まれる確認手段として使いどころがはっきりしています。
特に、delete、immutability、legal hold、tier 変更、tag 変更みたいに、あとから「やっぱ違った」がつらい操作では先に挟みたくなります。
ただし、dry run = 無料 ではありません。
preview の延長として考えるとズレるので、そこは先に押さえておきたいです。
Azure Storage Actions って何だっけ？
Azure Storage Actions は、Azure Blob Storage / Azure Data Lake Storage 向けの大規模データ管理を自動化するフルマネージド サービスです。
- Azure Storage Actions とは - Microsoft Learn
たとえば、こんなことをコードなしで定義して自動実行できます。
- 「90 日以上アクセスがない blob を cool tier に移動する」
- 「特定の prefix 配下の blob に一括でタグを付ける」
- 「条件に一致した blob を delete する」
Azure Functions や自前スクリプトを都度作らなくても、
- どの blob を対象にするか
- どんな条件なら処理するか
- 何の操作をするか
を組み合わせて、storage task として定義できます。
登場する要素は 3 つです。
| 要素 | 役割 |
|---|---|
| Conditions | どの blob を対象にするかを決める条件 |
| Operations | 対象 blob に対して何をするか |
| Assignments | どの storage account に、いつ、どの範囲で実行するか |
Blob lifecycle management だけでは書きにくい条件付き処理を、task と assignment に分けて持てるのが Azure Storage Actions の面白いところです。
今回の Mock run で何が変わったの？
2026/05 に Azure Updates で、Azure Storage Actions の Mock run が General Availability として案内されました。
Mock run は、storage task assignment を実際に走らせる前に、対象 blob を全部スキャンして条件評価だけ先にやる機能です。
- 条件に一致した blob はどれか
- どの操作が走る想定か
- 何件ぐらい影響を受けそうか
を、データを変更せずに 確認できます。
Storage 系の自動化では、実行そのものより「どこまで巻き込むか」の方が怖い。
assignment 単位で対象全体を先に見られるので、削除や tier 変更を流す前の確認に使いやすいです。
Condition preview と何が違うの？
| 観点 | Condition preview | Mock run |
|---|---|---|
| 対象範囲 | 最大 5,000 blob のサンプル確認 | Assignment scope 全体 |
| 実行モデル | その場で即時確認 | 非同期で実行 |
| 操作内容の表示 | なし | あり |
| レポート出力 | なし | CSV / summary JSON あり |
| 課金 | なし | 一部あり |
| 向いている場面 | 条件式の書き始め | 本番前の最終確認 |
私の理解では、Condition preview は設計中の目視確認、Mock run は本番前のゲートです。
「まず少量サンプルで条件の向きを見て、最後に Mock run で全体確認」が自然な順番です。
どういう操作で特に効きそう？
個人的には、戻しづらい操作ほど価値が高いです。
- delete
- immutability policy
- legal hold
- tier 変更
- blob index tag や metadata の更新
たとえば「90 日超えのログだけ cool tier に落とすつもりだったのに、prefix の切り方が甘くて別データも巻き込む」みたいな事故は避けたいですよね。
Mock run があると、そこで一度止まれます。
ざっくり使い方
Portal では、storage task assignment を作るときに Run type = Mock run を選ぶ形です。
今回は Japan East で、実際に最小 lab を起こしながら画面を追いました。
作成時に使った主な名前は次のとおりです（環境固有情報はスクリーンショット上でマスクしています）。
- storage account:
stmockrun260525a - storage task:
stmocktask260525a - assignment:
stmockassign260525a - report container:
stmockreports
大きな流れは次のとおりです。
- 先に storage task 側で条件と操作を定義しておく
- Assignments から対象 storage account を選ぶ
- managed identity に必要なロールを付ける
- 必要なら prefix filter で対象を絞る
- Run type で Mock run を選ぶ
- Report export container を指定して assignment を作成する
- assignment を enable して実行する
Marketplace で Storage task - Azure Storage Actions を引くと、Portal からそのまま作成に入れます。
条件画面では、ビジュアルビルダーで IF 条件と THEN 操作を組み立てられます。
今回のラボでは「BLOB 名に sample.txt を含む」→「BLOB タグを設定」というシンプルな条件を入れました。
review 画面まで進めると、task 名、条件、assignment、Mock run 指定、report container までまとめて確認できます。
作成 を押すと、storage task と assignment が同じテンプレートでまとめてデプロイされます。
デプロイ中は読み込み画面が表示され、完了するとそのままリソースページに遷移します。
デプロイが終わると、storage task の概要ページからメトリクスや状態を追えるようになります。
割り当て一覧では、Run type が モック になっていること、状態と最後の実行時刻がそのまま見えます。
今回のラボでは Mock run が完了し、状態が 完了済み になっていました。右ペインの「実行タスク」から結果の詳細にも飛べます。
レポートでどこを見るの？
Mock run が終わると、CSV と summary JSON が出ます。
実行結果は、左メニューの「タスクの実行」から確認できます。
今回のラボでは、テスト用に 11 個の blob（うち条件に一致する名前は 3 個）を入れて Mock run を回しました。
上部カードに「対象オブジェクトの総数: 11」、run の行に「完了済み / 試行 カウント: 3 / 11」が出ていて、ここだけで影響範囲がわかります。
run の行の右端「モック実行の表示」をクリックすると、「モックの要約」タブに遷移します。
ここに オブジェクトが一覧表示されました: 11、条件を満たすオブジェクト: 3、モックされた操作: 3 のカードが並びます。
report container には summary JSON と CSV も出力されます。
出力された summary JSON がこちらです。
{
"completionTime": "2026-05-25T20:53:01",
"fileSchema": [
"Container", "Blob", "Snapshot", "VersionId",
"Operation", "Result", "Error description",
"Error code", "Matched condition block"
],
"objectsListed": 11,
"objectsToBeProcessed": 3,
"operationsToBeInvoked": 3,
"status": "succeeded"
}
見ておきたいのは次のあたりです。括弧内は Portal の「モックの要約」タブでの表示名です。
-
objectsListed（Portal: オブジェクトが一覧表示されました）
スキャンした blob の総数 -
objectsToBeProcessed（Portal: 条件を満たすオブジェクト）
条件に一致して、実際なら操作対象になっていた件数 -
operationsToBeInvoked（Portal: モックされた操作）
実行される想定だった操作の数 -
status
mock run の成否 - CSV の
Operation
どの操作が想定されていたか - CSV の
Matched condition block
どの条件分岐に当たったか
この Matched condition block が見えるのは地味に便利です。
IF / ELSE のどちらに落ちたか追いやすいので、条件式のズレを直しやすくなります。
実際の CSV はこんな感じです（今回のラボの出力から抜粋）。
Container,Blob,Operation,Result,Matched condition block
testblobs,data/sample.txt,(Mock) SetBlobTags,Success,IF
testblobs,data/backup-sample.txt,(Mock) SetBlobTags,Success,IF
testblobs,archives/old-sample.txt,(Mock) SetBlobTags,Success,IF
testblobs,logs/app-log-20260101.txt,,N/A,No conditions were met
testblobs,data/report-2026Q1.csv,,N/A,No conditions were met
sample.txt を含む 3 件が IF に当たり (Mock) SetBlobTags の対象、残りは No conditions were met で素通り。
どの blob がどの条件分岐に落ちたかが 1 行ずつ見えるので、prefix の切り方ミスや条件式の抜け漏れを拾いやすいです。
注意点
課金の仕組み
Azure Storage Actions の課金は 3 つのメーター で構成されています。
| メーター | 単位 | Mock run で課金？ |
|---|---|---|
| Task execution instance | 1 回の実行あたり | される |
| Objects targeted | スキャン・評価した blob 100 万件あたり | される |
| Operations performed | 実行した操作 100 万件あたり | されない（常に $0） |
Mock run では blob の変更操作をしないので Operations performed だけ $0 になります。
ただし、スキャン中に Blob Storage API（List / GetProperties 等）を呼ぶので、そのトランザクション費用は通常どおりかかります。
つまり、real run と比べれば安いけれど、Condition preview（無料）の代わりに使うと想定外のコストが積みます。
blob 数が多いほど Objects targeted メーターが効いてくるので、prefix filter で対象を絞るのが大事です。
公式の料金詳細はこちらです。
- Azure Storage Actions の価格
- Azure Storage Actions のコスト管理 - Microsoft Learn
その他の制限
-
Storage account ごとの同時実行は 1 本
別の real run や mock run が動いていると queue されます -
完了済み Mock run は再実行できません
もう一度やるなら assignment の新規作成か複製が必要です - network 制限がある storage account では、Allow trusted Microsoft services が必要です
特に一番大事なのは、non-destructive だけど no-cost ではないことだと思います。
「とりあえず毎回全部回しておこう」ではなく、Condition preview と役割分担しながら使う方がよさそうです。
本番投入までの流れ
Mock run の良いところは、結果を見たあとに Run once や Recurring へ切り替えられることです。
- 条件を作る
- Condition preview でざっくり確認する
- Mock run で本番スコープ全体を確認する
- 問題なければ real run へ切り替える
この流れなら、条件の向きを見る段階と、本番前に全体を見る段階を分けられます。
確認用の assignment を捨てずにそのまま real run へ寄せられるので、手戻りも少なくて済みます。
まとめ
Azure Storage Actions は、Blob / Data Lake の大量データ管理を task と assignment で分けて扱えるサービスです。
今回の Mock run GA で、実行前に一度止まって確認する手段が加わりました。
特に、
- 影響範囲を full-scale で見たい
- irreversible な操作をいきなり流したくない
- CSV で監査っぽく残したい
という場面では、私は Mock run を先に挟みたくなります。
無料の軽い preview を期待するとズレるので、条件を詰める段階は Condition preview、実行前だけ Mock run と分けて使うのが合いそうです。
ぜひ試してみてください～！
参考
- Generally Available: Mock runs for Azure Storage Actions - Validate before you execute
- Azure Storage Actions とは - Microsoft Learn
- Storage task assignment の Mock runs - Microsoft Learn
- Mock runs for storage task assignments - Microsoft Learn
- Create a mock run - Microsoft Learn
- Storage task の既知の制限 - Microsoft Learn
- Azure Storage Actions のコスト管理 - Microsoft Learn