Azure Blob Storage / Azure Data Lake Storageで、小さなファイルを大量にCool、Cold、Archive層へ置いているチームは、2026年以降の請求ルール変更を早めに確認すべきです。ポイントはシンプルで、128KiB未満のオブジェクトでも、対象層では128KiB分として容量課金されるようになります。ログ、IoTデータ、監査証跡、画像サムネイル、JSON、Parquetの小片、アプリの細かなバックアップなどを大量に保管している環境では、見かけの保存容量より請求対象容量が大きくなる可能性があります。
この変更で重要なのは、「Azure Blob Storageの単価が一律に上がる」という話ではない点です。影響を受けるのは、主にCool、Cold、Archive層にある128KiB未満の小さなオブジェクトを大量に持つストレージアカウントです。FinOpsチームはコスト予測と配賦ロジックを見直し、ストレージ管理者は小さなオブジェクトの集約、Smart Tierの活用、ライフサイクル管理ポリシーの再設計を検討する必要があります。
Azure Blob Storage / Data Lake Storageの最小課金オブジェクトサイズ変更とは
MicrosoftはAzure Blob StorageおよびAzure Data Lake Storage向けに、Cool、Cold、Archiveアクセス層で128KiBの最小課金オブジェクトサイズを導入します。対象層に保存された128KiB未満のオブジェクトは、実サイズではなく128KiBのオブジェクトとして容量課金されます。課金は既存の容量課金メーターで行われ、トランザクション課金の扱いは変更されないと説明されています。(Microsoft Learn)
導入時期は段階的です。
| 時期 | 対象 | 実務上の意味 |
|---|---|---|
| 2026年7月1日 | 同日以降に作成された新しいストレージアカウント | 新規プロジェクト、移行先アカウント、新設データレイクで即座に設計見直しが必要 |
| 2027年7月1日 | すべてのストレージアカウント | 既存環境も含め、全社的な影響調査と予算反映が必要 |
どちらの段階に該当するかは、ストレージアカウントの作成時刻で判断されます。Hot層については、引き続き最小課金オブジェクトサイズはありません。(Microsoft Learn)
影響が大きいのは「小さいオブジェクトが多い」環境
今回の変更は、保存容量が大きい環境よりも、オブジェクト数が多く、平均サイズが小さい環境で効きやすい変更です。
たとえば、1個あたり10KiBのJSONファイルを1億個、Cool層に保存しているケースを考えます。実データ量は単純計算で約953GiBですが、各オブジェクトが128KiBとして扱われると、請求対象容量は約11.9TiB相当になります。実際の請求額はリージョン、冗長性、契約、通貨、予約容量などによって変わりますが、「実容量だけを見て安い層に置く」という判断は危険になります。
| オブジェクトの平均サイズ | オブジェクト数 | 実データ量の目安 | 128KiB課金後の容量目安 | 影響度 |
|---|---|---|---|---|
| 4KiB | 1,000万 | 約38GiB | 約1.19TiB | 非常に大きい |
| 16KiB | 1,000万 | 約153GiB | 約1.19TiB | 大きい |
| 64KiB | 1,000万 | 約610GiB | 約1.19TiB | 中程度 |
| 128KiB以上 | 1,000万 | 実サイズに依存 | 実サイズに近い | 小さい |
この表で見るべきなのは、合計容量ではなく平均オブジェクトサイズです。オブジェクトサイズが128KiBに近づくほど影響は小さくなり、数KiBから数十KiBのデータを大量に置いているほど影響が大きくなります。
まず確認すべき対象データ
FinOpsチームやストレージ管理者は、全ストレージアカウントを一律に見直すのではなく、影響が出やすいワークロードから優先順位を付けるべきです。
| データ種別 | 影響を受けやすい理由 | 見直しポイント |
|---|---|---|
| アプリケーションログ | 1ファイルが数KiB〜数十KiBになりやすい | 日次・時間単位で圧縮してまとめられないか |
| IoT/センサーデータ | デバイス単位・イベント単位で小さなファイルが増えやすい | 取り込み時にバッチ化できるか |
| 監査ログ・証跡 | 長期保管目的でArchive層に移しやすい | 検索用インデックスと本体データを分けられるか |
| サムネイル・小画像 | 1オブジェクトが128KiB未満になりやすい | Hot層維持、集約、別サービス利用を比較する |
| Data Lakeの細分化ファイル | パーティション設計によって小ファイルが大量発生する | 小さすぎるパーティションを統合する |
| バックアップのメタデータ | 本体よりメタ情報のオブジェクト数が増えやすい | メタデータの保存形式を再設計する |
特にAzure Data Lake Storage Gen2を使って分析基盤を構築している場合、日付、テナント、リージョン、デバイス、アプリIDなどで細かくパーティションを切りすぎると、小さなファイルが大量に発生します。クエリ性能のために分割したはずが、ストレージ課金では不利になることがあります。
コスト影響を試算する基本式
今回の変更による影響は、難しい料金モデルを使わなくても概算できます。まず、対象層にある128KiB未満のオブジェクトをサイズ帯別に集計します。
概算式は次の通りです。
追加請求対象容量 ≒ Σ（128KiB − 実オブジェクトサイズ） × 対象オブジェクト数たとえば、平均20KiBのオブジェクトが5,000万個ある場合は次のように考えます。
1オブジェクトあたりの差分 = 128KiB − 20KiB = 108KiB
追加請求対象容量 = 108KiB × 50,000,000
≒ 約5.03TiBこの追加請求対象容量に、該当するアクセス層、リージョン、冗長性の容量単価を掛けると、月額影響額の目安が出せます。Azure Blob Storageの料金は、保存容量、操作回数、データ転送、冗長性などで変わるため、最終的な金額は公式の料金ページやPricing Calculatorで確認する必要があります。(Microsoft Azure)
FinOpsで見るべき3つの数字
影響試算では、次の3つを分けて見ると判断しやすくなります。
| 指標 | 意味 | 判断に使う場面 |
|---|---|---|
| 実保存容量 | 現在のオブジェクトの実サイズ合計 | 既存の利用量把握 |
| 請求対象容量 | 128KiB未満を128KiBとして丸めた容量 | 変更後の容量課金影響 |
| オブジェクト数 | 小さなファイルがどれだけあるか | 集約・設計変更の優先順位付け |
容量課金だけを見ると、「数十GiBだから問題ない」と見えてしまうことがあります。しかし、小さなファイルが数千万〜数億個ある場合は、請求対象容量がTiB単位に膨らむ可能性があります。
アクセス層ごとの注意点
Azure Blob Storageのアクセス層は、単に「安い順」に選べばよいものではありません。Cool、Cold、Archiveは保存単価を下げやすい一方で、読み取り、取得、トランザクション、早期削除、復元時間の条件が重くなります。
| アクセス層 | 主な用途 | 最小保持期間の目安 | 今回の変更での注意点 |
|---|---|---|---|
| Hot | 頻繁に読み書きするデータ | なし | 128KiBの最小課金対象外。小さいファイルを無理にCoolへ移す前に比較する |
| Cool | 低頻度アクセスのバックアップ、古いデータ | 30日 | 小さいオブジェクトの大量移動で節約効果が薄れる可能性 |
| Cold | まれに使うがオンラインで即時アクセスしたいデータ | 90日 | 小ファイル課金と早期削除の両方を確認する |
| Archive | 長期保管、監査、コンプライアンス用途 | 180日 | 小ファイル課金に加え、読み出し前のリハイドレーションが必要 |
Microsoft Learnでは、Coolは30日、Coldは90日、Archiveは180日の最小保持期間が示されています。またArchive層はオフライン層であり、読み取りやダウンロード前にHot、Cool、Coldなどのオンライン層へリハイドレーションする必要があります。(Microsoft Learn)
小さなオブジェクトが多い場合、Archive層に移せば必ず安くなるとは限りません。読み出しが少なくても、128KiB未満のオブジェクトが大量にあると、容量課金の丸め込みで期待したほど下がらないことがあります。加えて、Archiveから戻すには時間がかかるため、監査や障害対応で急に必要になるデータには不向きな場合があります。
対応策は「集約」「層の見直し」「自動化」の3方向
今回の変更に対する対応は、大きく3つです。すべてを一度に実施する必要はありません。まずは影響が大きいコンテナーやプレフィックスに絞って検証し、コスト削減効果と運用負荷のバランスを見ます。
小さなオブジェクトをまとめてからCool/Cold/Archiveへ移す
最も直接的な対策は、128KiB未満の小さなファイルをTAR、ZIP、Parquet、Avroなどの大きなファイルにまとめることです。Microsoftも、小さなファイルをより大きなオブジェクトにまとめてから低温層へ移すことをコスト影響低減策として示しています。(Microsoft Learn)
ただし、単純に圧縮すればよいわけではありません。集約すると、個別ファイルの読み出し、部分復元、削除、検索が難しくなります。
| 集約方法 | 向いているケース | 注意点 |
|---|---|---|
| ZIP/TARにまとめる | 長期保管、監査証跡、ほぼ読み返さないログ | 個別ファイルの直接取得がしづらい |
| Parquetに変換する | 分析基盤、Data Lake、バッチ分析 | スキーマ設計とパーティション設計が必要 |
| 日次・時間単位でまとめる | ログ、IoT、イベントデータ | 後から特定期間だけ読む要件を確認する |
| インデックスを別Blobで持つ | 検索性を残したいアーカイブ | インデックス更新と整合性管理が必要 |
実務では、本体データは大きなオブジェクトにまとめ、検索用インデックスやマニフェストはHot層に置く構成が扱いやすいです。たとえば、監査ログ本体は日次単位でParquet化し、検索に使うユーザーID、タイムスタンプ、元ファイル名、オフセット情報だけを小さなインデックスとして保持します。
Smart Tierで小さいオブジェクトをHotに残す
アクセスパターンが読みにくい場合は、Smart Tierの活用も候補になります。Smart TierはHot、Cool、Coldの間でデータを自動的に移動する仕組みで、既定では新しいデータをHotに置き、30日アクセスがなければCool、さらに90日相当の非アクティブ期間を経てColdへ移します。Archive層はSmart Tierの対象外です。(Microsoft Learn)
今回の変更と関係が深いのは、Smart Tierでは128KiB未満の小さなオブジェクトがHot容量層に残る点です。Microsoft Learnでは、128KiB未満のSmart Tierオブジェクトは効率のため容量層を移動せず、Hotにとどまると説明されています。また、Smart Tierの監視料金は128KiBを超えるオブジェクトが対象で、128KiB以下のオブジェクトには監視料金が課金されません。(Microsoft Learn)
ただし、Smart Tierには前提条件があります。標準の汎用v2ストレージアカウント、ZRS/GZRS/RA-GZRSなどのゾーン冗長構成、ブロックBlobなどの条件を確認してください。すべての既存環境でそのまま使えるわけではありません。(Microsoft Learn)
ライフサイクル管理ポリシーを見直す
既存環境では、Blob lifecycle managementで「30日後にCool」「90日後にCold」「180日後にArchive」といったルールを設定しているケースがあります。ライフサイクル管理は、条件に合うBlobを低温層へ移動したり、不要になったBlobを削除したりできる便利な仕組みです。(Microsoft Learn)
しかし、これからは「古いから低温層へ移す」だけでは不十分です。小さいオブジェクトは移さない、または集約してから移すという条件を設計に加える必要があります。
見直しの例は次の通りです。
| 既存ルール | 見直し案 |
|---|---|
| 30日後にすべてCoolへ移動 | 128KiB未満のログは日次で集約後にCoolへ移動 |
| 180日後にすべてArchiveへ移動 | 小ファイル比率が高いコンテナーはArchive化前に圧縮・Parquet化 |
| アクセス日時だけで層を決定 | オブジェクトサイズ、件数、読み出し頻度も判断材料にする |
| コンテナー単位で一律適用 | プレフィックスやタグ単位でルールを分ける |
ライフサイクル管理の変更は即時反映ではなく、ポリシーの反映や実行に時間がかかる場合があります。大量のBlobを対象にすると、操作回数や実行時間も無視できません。事前に小さな範囲で検証してから本番全体へ展開するのが安全です。
監視・レポートで壊れやすいポイント
今回の変更では、Blob Capacityメトリックに新しいBlob TypeとしてBlockBlobSmallとAzure Data Lake Storage Smallが導入されます。既存のダッシュボード、アラート、コストレポート、自動化処理がBlockBlobだけを前提にしている場合、集計漏れや想定外の結果が出る可能性があります。(Microsoft Learn)
特に注意すべきなのは、次のような運用です。
| 対象 | 起こり得る問題 | 対応 |
|---|---|---|
| Azure Monitorのメトリック分割 | Blob Type追加により既存グラフの合計値が変わる | BlockBlobSmallなどを含めて再集計 |
| Cost Managementの独自レポート | 容量増加の原因を単価上昇と誤解する | オブジェクト数とサイズ帯を併記 |
| 予算アラート | 2026年7月以降の新規アカウントで急に閾値超過 | 新規アカウント向けに別予算を設定 |
| 自動化スクリプト | BlockBlobのみを対象にして小オブジェクトを見落とす | Blob Typeの条件を見直す |
| 部門別配賦 | 実容量ベースの按分が請求実態とずれる | 請求対象容量ベースの配賦も検討 |
FinOpsの観点では、「誰が何GiB使っているか」だけでは不十分になります。「誰が何個の小さなオブジェクトを低温層に置いているか」を可視化する必要があります。
実務での調査手順
まずは、全社的な設計変更を始める前に、対象アカウントの棚卸しを行います。以下の順序で進めると、コスト影響と対応優先度を整理しやすくなります。
| 手順 | 作業内容 | 目的 |
| -: | —————————- | ———————————— |
| 1 | ストレージアカウントの作成日を確認する | 2026年7月1日適用か、2027年7月1日適用かを判定 |
| 2 | Cool、Cold、Archive層のBlobを抽出する | 影響対象を絞る |
| 3 | 128KiB未満のオブジェクト数と合計サイズを集計する | 追加請求対象容量を概算 |
| 4 | コンテナー、プレフィックス、タグ、部門別に分類する | 対応優先度と配賦影響を把握 |
| 5 | 読み出し頻度と保持期間を確認する | Hot維持、集約、Smart Tier、Archiveのどれが適切か判断 |
| 6 | 小規模に集約・移行をテストする | 性能、復元性、検索性、コストを検証 |
| 7 | ライフサイクル管理とレポートを修正する | 再発防止と運用定着 |
ここで重要なのは、ストレージ管理者だけで完結させないことです。小さなオブジェクトは、アプリケーションの出力形式、分析パイプライン、ログ設計、監査要件と密接に関係します。FinOps、アプリ開発、データエンジニア、セキュリティ、監査部門を巻き込んで判断する必要があります。
判断基準：Hotに残すべきか、集約して低温層へ移すべきか
実務では、すべての小さなオブジェクトをまとめるのが正解とは限りません。次の基準で判断すると、無理のない設計にできます。
| 判断軸 | Hotに残す選択が向くケース | 集約して低温層へ移す選択が向くケース |
|---|---|---|
| 読み出し頻度 | たびたび参照される | ほぼ参照されない |
| 復元要件 | すぐ個別ファイルを取り出したい | バッチ単位で復元できればよい |
| 検索要件 | ファイル単位の検索が多い | インデックスで検索できる |
| 保存期間 | 短期で削除される | 長期保管が必要 |
| オブジェクト数 | 少ない | 非常に多い |
| 運用負荷 | 集約処理を追加したくない | パイプライン変更を許容できる |
たとえば、障害調査で頻繁に参照する直近30日のアプリログはHotに残し、31日以降のログは日次でParquet化してCoolへ移す、といった設計が現実的です。監査用途で年単位保管するログは、個別JSONのままArchiveへ送るより、検索用インデックスを残したうえで圧縮・集約して保存した方が扱いやすくなります。
失敗しやすいポイント
実容量だけでコスト影響を判断する
今回の変更では、実容量よりもオブジェクト数が重要です。特に10KiB未満のファイルが大量にある環境では、実容量ベースの見積もりが大きく外れます。
Archive層なら必ず安いと考える
Archive層は保存単価を下げやすい一方で、リハイドレーション、読み出しコスト、早期削除、運用遅延を考慮する必要があります。小さなオブジェクトを大量にそのままArchiveへ移すと、期待したほど安くならない可能性があります。
集約後の検索性を考えない
小さなファイルをZIPやTARにまとめると、単純なコスト面では有利になりやすい一方で、個別ファイルを探す運用が難しくなります。必ず、元ファイル名、保存期間、ハッシュ、タイムスタンプ、オフセットなどを持つマニフェストやインデックスを設計してください。
ライフサイクル管理を一律に適用する
「すべて30日後にCool」「すべて180日後にArchive」のようなルールは、小ファイルが多い環境では粗すぎます。プレフィックス、Blob index tags、データ種別ごとにルールを分けることが重要です。
新しいBlob Typeをレポートに含め忘れる
BlockBlobSmallやAzure Data Lake Storage Smallを含めないまま既存ダッシュボードを使い続けると、容量や件数の把握がずれる可能性があります。コスト増の原因分析にも支障が出ます。
2026年7月までにやるべきこと
2026年7月1日以降に新しいストレージアカウントを作成する予定があるチームは、すぐに設計レビューを始めるべきです。既存アカウントだけを見て「まだ影響は先」と判断すると、新規プロジェクトや移行プロジェクトで先に影響を受ける可能性があります。
優先して実施すべき作業は次の通りです。
| 優先度 | 対応 | 対象 |
|---|---|---|
| 高 | 128KiB未満のCool/Cold/Archiveオブジェクト数を集計 | 全ストレージアカウント |
| 高 | 2026年7月1日以降に作成予定のアカウントを洗い出す | 新規・移行プロジェクト |
| 高 | Cost Management、Azure Monitor、独自レポートのBlob Type条件を確認 | FinOps、運用チーム |
| 中 | 小ファイル集約のPoCを実施 | ログ、IoT、監査データ |
| 中 | Smart Tierの利用可否を確認 | アクセスパターンが不明なデータ |
| 中 | ライフサイクル管理ポリシーをサイズ観点で見直す | 低温層への自動移動ルール |
| 低 | 部門別チャージバックの計算式を更新 | 組織内配賦を行う環境 |
2027年7月1日には既存アカウントも対象になります。特に長期保管データは移行・集約に時間がかかるため、2026年中に棚卸しと試算を済ませ、2027年度予算に反映できる状態にしておくのが安全です。
まとめ：小さいオブジェクトの扱いをストレージ設計の中心に置く
Azure Blob Storage / Azure Data Lake Storageの最小課金オブジェクトサイズ変更は、単なる料金表の変更ではありません。これまで「古いデータは低温層へ移せばよい」と考えていた運用に対し、オブジェクトサイズとオブジェクト数をコスト設計に組み込む必要があるというメッセージです。
まず行うべきことは、Cool、Cold、Archive層にある128KiB未満のオブジェクトを集計し、請求対象容量がどれだけ増えるかを試算することです。そのうえで、Hot層に残す、Smart Tierを使う、小さなファイルを集約する、ライフサイクル管理を分ける、といった対応をデータ種別ごとに選びます。
FinOpsチームは予算・配賦・レポートの見直しを、ストレージ管理者はアカウント作成時期、Blob Type、ライフサイクル管理、集約パイプラインの見直しを進めましょう。小さいオブジェクトを放置したまま低温層へ送り続ける運用は、2026年以降、想定外のコスト増につながりやすくなります。
コメント