Azure Blob StorageやAzure Data Lake Storageで、小さなファイルをクール層・コールド層・アーカイブ層に保存している場合、「2026年7月1日から料金が上がるのでは」と不安に感じるかもしれません。
結論として、Microsoftは2026年6月8日、低温ストレージ層への最低課金オブジェクトサイズの導入を一時停止しました。2026年7月1日時点では、新規・既存を問わずストレージアカウントの課金方法は変更されません。
そのため、この変更だけを理由とした設定変更やデータ移行は不要です。ただし、導入自体が完全に中止されたわけではありません。今後、見直された方式とスケジュールが発表される予定です。小容量オブジェクトの保存状況やライフサイクル管理ルールは、今のうちに確認しておくとよいでしょう。(Microsoft Azure)
2026年6月8日の変更点：最低課金サイズの導入が一時停止
「Minimum billable object size for cooler storage tiers」は、低温ストレージ層に保存する小さなオブジェクトについて、実際のサイズより大きな容量を課金対象にする予定だった変更です。
当初の案内と、2026年6月8日の更新内容を比較すると次のようになります。
| 確認項目 | 当初の案内 | 2026年6月8日の更新後 |
|---|---|---|
| 最低課金オブジェクトサイズ | 128 KiBを導入予定 | 導入を一時停止 |
| 対象アクセス層 | クール、コールド、アーカイブ | 現時点では変更なし |
| 2026年7月1日 | 同日以降に作成された新規アカウントへ適用予定 | 新規・既存ともに課金方法は変更されない |
| 2027年7月1日 | すべてのストレージアカウントへ適用予定 | 見直し後のスケジュールは未発表 |
| 利用者側の作業 | コスト試算や移行検討が必要になる可能性 | 直ちに必要な設定変更や移行はない |
Microsoftは、改定した方式とスケジュールを今後のAzure Updateで案内するとしています。したがって、旧案に記載されていた2027年7月1日も、現在の確定期限として扱うべきではありません。
また、Microsoft Learnの公式ドキュメントでは、2026年6月8日に最低課金オブジェクトサイズに関する説明が削除されています。旧スケジュールを前提にした社内資料や料金試算がある場合は、内容を更新しておきましょう。(GitHub)
Minimum billable object sizeとは
Minimum billable object sizeは、日本語では「最低課金オブジェクトサイズ」と表現できます。
これは、アップロードできるファイルの最低サイズを制限する仕組みではありません。小さなファイルも従来どおり保存できますが、課金計算上は一定のサイズがあるものとして扱う仕組みです。
当初の案では、Azure Blob StorageおよびAzure Data Lake Storageのクール層・コールド層・アーカイブ層にある128 KiB未満のオブジェクトを、128 KiBとして容量課金する予定でした。128 KiBは131,072バイトです。
たとえば、旧案が導入された場合の計算は次のようになります。
| 実際のオブジェクトサイズ | 旧案での課金対象サイズ | 実サイズに対する倍率 |
|---|---|---|
| 10 KiB | 128 KiB | 12.8倍 |
| 32 KiB | 128 KiB | 4倍 |
| 64 KiB | 128 KiB | 2倍 |
| 100 KiB | 128 KiB | 1.28倍 |
| 128 KiB以上 | 実際のサイズ | 原則として増加なし |
10 KiBのオブジェクトが100万個あるケースでは、実容量は約9.54 GiBです。しかし、旧案の計算では約122.07 GiBが課金対象となります。
これはあくまで一時停止された旧案を理解するための試算であり、2026年7月1日から実際に適用される料金ではありません。当初は既存の容量課金メーターを利用し、トランザクション課金は変更しない計画でした。対象として示されていたのは、ブロックBLOBとAppend BLOBです。(GitHub)
今回の更新で影響を受けるユーザー
2026年7月1日時点では、新規・既存のストレージアカウントともに、この更新による直接的な料金変更はありません。
ただし、将来同様の仕組みが再提案された場合、次のような環境は影響を受けやすくなります。
| データの保存パターン | 将来の影響度 | 理由 |
|---|---|---|
| 数KiBのログやJSONを1件ずつ保存 | 高い | オブジェクト数が多く、最低課金サイズとの差が大きい |
| IoTデータを端末・時刻単位の小ファイルで保存 | 高い | 数百万から数億単位の小容量ファイルになりやすい |
| Azure Data Lake Storageに細かいCSVを大量保存 | 高い | パーティション内に小さなファイルが増えやすい |
| サムネイルや小さな設定ファイルを低温層へ移動 | 中程度 | 1件は小さくても、件数によって影響が増える |
| 128 KiB以上のParquetなどに集約済み | 低い | 最低課金サイズとの差が生じにくい |
| ホット層だけを利用 | 低い | 旧案ではホット層が対象外だった |
判断するときは、ストレージの総容量だけではなく、128 KiB未満のオブジェクト数と平均サイズを確認することが重要です。
同じ1 TiBのストレージでも、1 GiBのファイルが1,024個ある環境と、数KiBのファイルが数億個ある環境では、最低課金サイズが導入された場合の影響が大きく異なります。
管理者が今確認すべき項目
128 KiB未満のオブジェクト数を調べる
Azureポータルでは、ストレージアカウントの以下の画面から、アクセス層別の件数や容量を確認できます。
- 対象のストレージアカウントを開く
- 「監視」から「メトリック」を選択する
- メトリック名前空間に「Blob」を指定する
- 「Blob Count」または「Blob Capacity」を選択する
- 「Blob tier」や「Blob type」で分割する
ただし、通常の容量メトリックだけでは、128 KiB未満のオブジェクトを正確に抽出できない場合があります。
詳細を調べる場合は、Azure Storage Blob Inventoryを利用します。インベントリーレポートには、Content-Length、AccessTier、BlobTypeなどの項目を含められ、CSVまたはApache Parquet形式で日次・週次出力できます。(GitHub)
集計時には、次の2つを分けて算出すると影響を判断しやすくなります。
- 128 KiB未満のオブジェクト件数
- 各オブジェクトを128 KiBとして計算した場合の容量増分
仮想的な容量増分は、オブジェクトごとに次の式で求められます。
最大値（131072 - Content-Length, 0）Blob Inventoryにはメタデータや一部のシステムデータなどが含まれないため、レポートの合計容量を請求書の容量と完全一致させる用途には向きません。小容量オブジェクトの分布を把握するための分析データとして利用しましょう。
ライフサイクル管理ルールを確認する
Lifecycle Managementで、一定期間が経過したBLOBを自動的にクール層やコールド層へ移動している場合は、ルールの対象範囲を確認してください。
現行のライフサイクル管理ルールで利用できる主なフィルターは、次の3種類です。
- BLOBの種類
- 名前またはパスのプレフィックス
- Blob Indexタグ
オブジェクトサイズを直接指定するフィルターはありません。そのため、同じパスに大容量ファイルと小容量ファイルが混在していると、小容量ファイルだけを除外することが難しくなります。(Microsoft Learn)
今後の対策を容易にするには、保存時点で次のようにパスを分けておく方法が有効です。
/raw/small-files/
/raw/large-files/
/archive/compacted/Azure Data Lake Storage Gen2の階層型名前空間では、ライフサイクル管理のBlob Indexタグフィルターを利用できません。そのため、ADLS Gen2ではディレクトリやプレフィックスによる分類を優先すると管理しやすくなります。(Microsoft Learn)
料金見積もりと予算を修正する
2026年7月1日の最低課金サイズ導入を前提に、予算や料金予測を増額していた場合は、試算条件を見直します。
一方で、今回一時停止されたのは最低課金オブジェクトサイズの導入です。通常のAzure Blob Storage料金には、引き続き次の要素が含まれます。
- 保存容量
- 読み取り・書き込みなどのトランザクション
- 低温層からのデータ取得
- 階層間の移動
- 外向きデータ転送
- 条件に該当する場合の早期削除料金
最低課金サイズが停止されたからといって、低温層に移せば必ず安くなるわけではありません。アクセス頻度や取得量、オブジェクト数を含めて見積もる必要があります。(Microsoft Learn)
メトリックや自動化の変更予定を見直す
旧案では、Blob Capacityメトリックに次のBLOBタイプを追加する計画も示されていました。
BlockBlobSmallAzure Data Lake Storage Small
また、BlockBlobだけを明示的に抽出するダッシュボードやアラートでは、小容量オブジェクトが集計から漏れる可能性があると案内されていました。
この説明も、最低課金サイズに関する記載とともに2026年6月8日に公式ドキュメントから削除されています。現時点で、これらの新しい値を前提とした監視設定への変更は必須ではありません。(GitHub)
すでにクエリや自動化を変更している場合は、実際に取得できるメトリックディメンションを確認してから本番へ反映してください。
設定変更・更新・データ移行は必要か
今回の発表に対する対応方針は、次のように整理できます。
| 対応項目 | 現時点で必要か | 対応内容 |
|---|---|---|
| ストレージアカウントの設定変更 | 不要 | 2026年7月1日の課金変更は停止されている |
| SDKやAzure CLIの更新 | 不要 | 今回の課金変更停止だけを理由とした更新は不要 |
| クール・コールド層からの移行 | 不要 | 急いでホット層へ戻す必要はない |
| 小容量オブジェクトの棚卸し | 推奨 | 件数、平均サイズ、アクセス層を把握する |
| ライフサイクル管理の確認 | 推奨 | 小容量ファイルが自動移動していないか確認する |
| 料金予測の修正 | 必要に応じて実施 | 旧スケジュールを前提にした増額分を見直す |
| Azure Updateの監視 | 推奨 | 改定後の方式と日程を確認する |
特に避けたいのは、旧スケジュールだけを根拠に、クール層やアーカイブ層のデータを急いでホット層へ戻すことです。
低温層から高温層への移動では、読み取り操作やデータ取得の料金が発生する場合があります。保存期間によっては早期削除料金の対象にもなります。移行前には、移行コストと将来の容量コストを比較する必要があります。(Microsoft Learn)
将来の再導入に備えた対策
小さなファイルをまとめる
ログや分析データを個別に参照する必要がなければ、複数の小容量ファイルを大きなオブジェクトにまとめる方法があります。
用途に応じて、次の形式が候補になります。
- 保管・一括取得が目的：TAR、ZIP
- 分析処理が目的：Parquetなどの列指向形式
- ログ処理が目的：一定時間または一定容量ごとの集約ファイル
ファイルをまとめると、最低課金サイズへの対策だけでなく、読み取り・書き込みのトランザクション数も減らせます。Microsoftも、低温層へ移動する前に小さなファイルをまとめる方法を推奨しています。(Microsoft Learn)
一方、1件だけを頻繁に取得する用途では、まとめたファイル全体を読み込む必要が生じる可能性があります。ランダムアクセスの必要性や更新頻度を確認してから採用してください。
小容量オブジェクトをホット層に残す
小容量オブジェクトは、容量料金よりもトランザクション料金の影響が大きくなることがあります。
低温層へ移動しても容量削減額が小さく、書き込みや読み取りの単価が上がる場合は、ホット層に残した方が総額を抑えられる可能性があります。アクセス層は容量単価だけで決めず、次の合計で比較しましょう。
保存容量料金
＋書き込み料金
＋読み取り料金
＋データ取得料金
＋階層移動料金Smart Tierを選択肢として比較する
Smart Tierでは、128 KiB未満の小容量オブジェクトはSmartHot-smallとしてホット層に残ります。128 KiB以上のオブジェクトは、アクセス状況に応じてホット・クール・コールド間を自動的に移動します。
ただし、Smart Tierはアーカイブ層に対応していません。また、128 KiBを超えるオブジェクトには監視操作の料金があり、アクセス操作はホット層の料金で課金されます。
最低課金サイズ対策だけを理由に切り替えるのではなく、アクセスパターン、対象リージョン、利用ツール、料金モデルを確認したうえで判断してください。(GitHub)
よくある疑問
2026年7月1日からAzure Blob Storageの料金は上がりますか
今回の最低課金オブジェクトサイズ変更による値上げは実施されません。新規・既存のどちらのストレージアカウントも、2026年7月1日時点では課金方法が変わらないと案内されています。(Microsoft Azure)
2027年7月1日には必ず適用されますか
現時点では確定していません。
2027年7月1日は旧案のスケジュールです。Microsoftは方式と日程を見直したうえで改めて発表するとしているため、確定した移行期限として扱わない方が安全です。
Azure Data Lake Storage Gen2も対象ですか
当初の案では、Azure Blob StorageとAzure Data Lake Storageの両方が対象でした。ただし、今回の導入停止も両サービスに関係するため、2026年7月1日に最低課金サイズは適用されません。
128 KiB未満のファイルは削除した方がよいですか
削除する必要はありません。
保存義務や利用目的があるデータを、将来の課金変更だけを理由に削除するのは適切ではありません。まずは件数とサイズを集計し、集約、アクセス層の変更、保存期間の見直しが可能かを判断してください。
まとめ：移行を急がず、小容量オブジェクトの現状を把握する
2026年6月8日の更新により、Azure Blob StorageおよびAzure Data Lake Storageに対する最低課金オブジェクトサイズの導入は一時停止されました。
2026年7月1日に課金方法は変わらないため、設定変更、SDK更新、データ移行を急ぐ必要はありません。
管理者が今行うべきなのは、次の対応です。
- 旧スケジュールを前提にした料金予測を修正する
- 128 KiB未満のオブジェクト数と容量を把握する
- 小容量ファイルを低温層へ移すライフサイクル管理ルールを確認する
- 旧メトリック仕様を前提に変更した監視設定を見直す
- 改定後の方式とスケジュールが発表されるまでAzure Updateを継続的に確認する
当面は移行作業よりも、Blob Inventoryなどを使った現状把握を優先してください。小容量オブジェクトの分布が分かっていれば、将来ルールが再提案された場合も、コスト試算と対応方針をすぐに決められます。
コメント