Azure Legacy Blob Storage account retirementとは？2026年10月13日の廃止とGPv2移行手順

AzureのLegacy Blob Storageアカウントは、2026年10月13日に廃止されます。対象は、ストレージアカウントの種類がBlobStorageになっている旧式のBlob専用アカウントです。対象アカウントを利用している場合は、汎用v2（GPv2、StorageV2）へのアップグレードが必要です。

2026年6月11日の公式情報更新では、新規Legacy Blob Storageアカウントの作成停止時期が2026年9月へ変更されました。ただし、廃止日である2026年10月13日は延長されていません。管理者は、対象アカウントの洗い出し、料金試算、動作検証、GPv2へのアップグレードを早めに進める必要があります。(GitHub)

Azureの新機能・変更点：Legacy Blob Storage account retirementの要点

今回の変更は、Azure Blob Storageというサービス全体の廃止ではありません。廃止されるのは、Azure Storageの旧アカウント種別であるLegacy Blob Storageアカウントです。

重要な変更点を整理すると、次のとおりです。

確認項目	変更内容
対象アカウント	アカウント種別が`BlobStorage`のLegacy Blob Storage
移行先	汎用v2ストレージアカウント（GPv2、`StorageV2`）
新規作成停止	2026年9月
廃止日	2026年10月13日
移行方式	通常は既存アカウントをそのままGPv2へアップグレード
データコピー	通常は不要
エンドポイント	アップグレード後も既存エンドポイントを継続利用可能
ダウンタイム	通常のアップグレードでは不要
注意点	料金体系、アクセス層、IaC定義、アプリの判定処理を要確認
未対応の場合	Microsoftによる自動移行対象となり、料金増加や一時的なアクセス影響の可能性がある

Microsoftは、Legacy Blob StorageアカウントからGPv2へのアップグレードについて、データコピーやダウンタイムを必要としないAzure Resource Manager操作として案内しています。一度GPv2へアップグレードすると、Legacy Blob Storageへ戻すことはできません。(Microsoft Learn)

2026年6月11日の更新で何が変わったのか

2026年6月11日の公式ドキュメント更新で変更されたのは、新規アカウントの作成停止時期です。

以前の記載では2026年3月3日に新規作成を停止する予定でしたが、更新後は2026年9月へ変更されています。廃止日そのものは変更されていません。(GitHub)

時期	内容
2025年9月	Legacy Blob Storageアカウントの廃止を発表
2026年6月11日	新規作成停止時期を2026年9月へ更新
2026年9月	新規Legacy Blob Storageアカウントの作成を停止
2026年10月13日	Legacy Blob Storageアカウントを廃止

ここで注意したいのは、移行期限が延びたわけではないことです。

新規作成停止から廃止までの期間は短いため、2026年9月になってから移行調査を始めると、検証や社内調整が間に合わない可能性があります。また、新規作成が可能な経路が残っていたとしても、新しいシステムでLegacy Blob Storageを採用すべきではありません。新規構築では最初からGPv2を選択してください。

影響を受けるアカウントと受けないアカウント

影響の有無は、ストレージアカウントの用途や名称ではなく、Azure Resource Manager上のアカウント種別（kind）で判断します。

アカウント種別	Azure上のkind	今回の影響
Legacy Blob Storage	`BlobStorage`	対象。GPv2へのアップグレードが必要
汎用v1	`Storage`	今回とは別の廃止対象だが、同じ2026年10月13日までにGPv2への移行が必要
汎用v2	`StorageV2`	対象外
Premium Block Blob	`BlockBlobStorage`	今回のLegacy Blob Storage廃止の対象外
Premium File Shares	`FileStorage`	対象外

Microsoftの資料では、Legacy Blob Storageに加えてGPv1も2026年10月13日の廃止対象として案内されています。そのため、調査時にはBlobStorageだけでなく、Storageも同時に確認するのが安全です。(Microsoft Learn)

「Azure Blob Storageを使っているだけ」では対象とは限らない

GPv2アカウントでもAzure Blob Storageは利用できます。そのため、アプリケーションがBlobを保存しているだけでは、今回の対象かどうかを判断できません。

たとえば、次のアカウントは今回の廃止対象ではありません。

Account kind: StorageV2 (general purpose v2)

一方、次の表示であれば対応が必要です。

Account kind: BlobStorage

「Blobを利用しているか」ではなく、「ストレージアカウントのkindが何か」を確認してください。

Legacy Blob StorageとGPv2の違い

Legacy Blob Storageは、ブロックBlobと追加Blobを中心とした旧式のBlob専用アカウントです。GPv2は現在の標準的なストレージアカウントで、Blob以外のAzure Storageサービスにも対応します。

機能	Legacy Blob Storage	GPv2
Blobの保存	対応	対応
アクセス層の管理	主にアカウント単位	Blob単位で設定可能
ライフサイクル管理	非対応	対応
イミュータブルストレージ	対応	対応
Event Grid連携	対応	対応
Queue Storage	非対応	対応
Table Storage	非対応	対応
Azure Files	非対応	対応
高度な冗長化オプション	制限あり	LRS、ZRS、GRS、RA-GRS、GZRS、RA-GZRSなど
Azure Data Lake Storage機能	非対応	構成により対応
ポイントインタイムリストア	非対応	対応可能
ライフサイクルによる自動階層化	非対応	対応

GPv2はLegacy Blob Storageで利用できるBlob機能を包含し、Blob単位のアクセス層、ライフサイクル管理、高度な冗長化などを利用できます。(Microsoft Learn)

ただし、機能が増えることと、料金が必ず安くなることは同じではありません。GPv2ではトランザクションやアクセス層ごとの料金体系が適用されるため、利用パターンによっては移行後の請求額が増える可能性があります。

対象アカウントを確認する方法

複数のサブスクリプションを運用している場合、Azureポータルで一つずつ確認するだけでは見落としが発生しやすくなります。少数ならポータル、大規模環境ならAzure Resource Graphを利用すると効率的です。

Azureポータルで確認する

Azureポータルで「ストレージアカウント」を開きます。
確認するストレージアカウントを選択します。
3.「概要」または「構成」を開きます。
4.「アカウントの種類」を確認します。
BlobStorageと表示されていれば今回の対象です。
Storageと表示されている場合はGPv1のため、別途GPv2への移行が必要です。
StorageV2であれば今回の対応は不要です。

アカウント名だけで判断してはいけません。「blob」「backup」「archive」といった名前が付いていても、実際のkindがStorageV2であれば対象外です。

Azure Resource Graphで一括確認する

Azureポータルの「Resource Graph Explorer」で、次のクエリを実行します。

resources
| where type =~ "microsoft.storage/storageaccounts"
| where kind in~ ("BlobStorage", "Storage")
| project
    subscriptionId,
    resourceGroup,
    name,
    location,
    kind,
    sku = tostring(sku.name)
| order by kind asc, name asc

結果の見方は次のとおりです。

BlobStorage：Legacy Blob Storage。今回の廃止対象
Storage：GPv1。同じ2026年10月13日までにGPv2への移行が必要
結果に表示されないStorageV2：今回の調査対象外

MicrosoftもAzure Resource Graph、Azure CLI、Azure Inventory、Azureポータルを利用したアカウントの棚卸しを推奨しています。(Microsoft Learn)

Azure Advisorの廃止推奨事項も確認する

Azure Advisorの「Service Upgrade and Retirement recommendations」では、廃止対象リソースが提示される場合があります。

2026年10月13日の項目には、Legacy Blob StorageとGPv1ストレージアカウントについて、影響を受けるリソースを確認できる対象として掲載されています。Resource Graphの結果とAzure Advisorの両方を照合すると、見落としを減らせます。(Microsoft Learn)

IaCやCI/CDの定義も検索する

稼働中のリソースだけでなく、今後のデプロイでLegacy Blob Storageを再作成しようとするコードも修正が必要です。

次の文字列を、Bicep、ARMテンプレート、Terraform、スクリプト、社内テンプレートから検索してください。

BlobStorage
kind: BlobStorage
"kind": "BlobStorage"
Microsoft.Storage/storageAccounts

該当する新規作成処理は、要件を確認したうえでStorageV2を使用する定義へ変更します。

Terraformを利用している場合は、Azure上だけ先にアップグレードすると、次回のterraform planで意図しない差分が出る可能性があります。Azure側の変更とコード側の変更を同じ作業計画に含めてください。

GPv2へアップグレードする前に確認すること

アップグレード操作自体はシンプルですが、料金やアプリケーションの前提条件まで自動的に最適化されるわけではありません。

作業前に次の項目を記録します。

確認項目	確認する内容
利用システム	どのアプリ、バッチ、バックアップ製品がアクセスしているか
所有者	障害時に判断できるシステム担当者は誰か
データ容量	現在容量と月ごとの増加量
アクセス傾向	読み取り、書き込み、一覧取得の回数
アクセス層	HotまたはCoolのどちらを既定値にするか
冗長化	LRS、ZRS、GRS、RA-GRSなどの現在設定
ネットワーク	ファイアウォール、仮想ネットワーク、Private Endpoint
認証	Microsoft Entra ID、マネージドID、SAS、アクセスキー
監視	Azure Monitor、診断設定、アラート
自動化	Terraform、Bicep、ARMテンプレート、Azure Policy
外部製品	バックアップ、アーカイブ、ETLなどの対応状況
料金	現在請求額とGPv2移行後の試算

特に見落としやすいのが、アプリケーションや運用スクリプト内のアカウント種別判定です。

kind == "BlobStorage"

このような判定を行っている場合、アップグレード後はStorageV2になるため、処理が実行されなくなる可能性があります。

AzureポータルからGPv2へアップグレードする手順

通常は、既存のストレージアカウントをそのままGPv2へアップグレードできます。

Azureポータルへサインインします。
対象のストレージアカウントを開きます。
3.「設定」から「構成」を選択します。
4.「アカウントの種類」にある「アップグレード」を選択します。
アップグレード後のアクセス層を確認します。
確認欄にストレージアカウント名を入力します。
7.「アップグレード」を実行します。
完了後、アカウントの種類がStorageV2になっていることを確認します。

このアップグレードは元に戻せません。本番環境では、変更管理の記録と動作確認手順を用意してから実行してください。(Microsoft Learn)

「アップグレード」が表示されない、操作がエラーになる、特殊な冗長化構成を利用しているといった場合は、設定を無理に変更せずAzureサポートへ問い合わせます。

Azure CLIでアップグレードする方法

Azure CLIでは、次のコマンドを使用します。

az storage account update \
  --resource-group <リソースグループ名> \
  --name <ストレージアカウント名> \
  --set kind=StorageV2 \
  --access-tier Hot

Coolを既定のアクセス層にする場合は、HotをCoolへ変更します。

az storage account update \
  --resource-group <リソースグループ名> \
  --name <ストレージアカウント名> \
  --set kind=StorageV2 \
  --access-tier Cool

実行後は次のコマンドでアカウント種別を確認できます。

az storage account show \
  --resource-group <リソースグループ名> \
  --name <ストレージアカウント名> \
  --query "{name:name, kind:kind, accessTier:accessTier, sku:sku.name}" \
  --output table

公式手順では、最新のAzure CLIを利用するよう案内されています。(Microsoft Learn)

PowerShellでアップグレードする方法

Azure PowerShellでは、Set-AzStorageAccountを使用します。

Set-AzStorageAccount `
  -ResourceGroupName "<リソースグループ名>" `
  -Name "<ストレージアカウント名>" `
  -UpgradeToStorageV2 `
  -AccessTier Hot

Coolを選ぶ場合は、-AccessTier Coolを指定します。

実行後は次のように確認できます。

Get-AzStorageAccount `
  -ResourceGroupName "<リソースグループ名>" `
  -Name "<ストレージアカウント名>" |
  Select-Object StorageAccountName, Kind, AccessTier, Sku

古いAzureRMモジュールではなく、最新のAz PowerShellモジュールを使用してください。(Microsoft Learn)

アップグレード後に確認する項目

操作が成功しただけでは、移行作業の完了とはいえません。少なくとも次の確認を行います。

アプリケーションから読み書きできるか

本番で使用している認証方法と同じ条件で、次の操作を試します。

Blobの一覧取得
Blobのアップロード
Blobのダウンロード
Blobの上書きまたは追加
SASを使用したアクセス
マネージドIDによるアクセス
Private Endpoint経由のアクセス

エンドポイントと接続経路を確認する

通常のGPv2アップグレードでは、ストレージアカウント名と既存のBlobエンドポイントは維持されます。(Microsoft Learn)

ただし、次の設定は実際のアプリケーションから確認してください。

DNS名前解決
ストレージファイアウォール
仮想ネットワークルール
Private Endpoint
プロキシや許可リスト
固定IPアドレスへの依存

Azure StorageのIPアドレスは変更される可能性があります。ストレージアカウントのIPを固定値としてアプリケーションやファイアウォールへ埋め込む運用は避ける必要があります。(Microsoft Learn)

IaCの状態を更新する

Azure側でBlobStorageからStorageV2へ変更した後は、TerraformやBicepの定義も更新します。

Terraformでは、変更後に必ず次を確認します。

terraform plan

アカウントの再作成や意図しない設定変更が表示された場合は、そのままapplyしないでください。リソース定義、プロバイダーのバージョン、stateの内容を確認します。

監視と請求額を確認する

アップグレード後は、少なくとも数週間にわたり次の指標を確認します。

使用容量
トランザクション数
読み取り・書き込み・一覧取得の回数
IngressとEgress
成功率とエラー率
可用性
応答時間
サービス別、メーター別の請求額

アップグレード前の値と比較できるように、事前にAzure MonitorやCost Managementの画面を保存しておくと原因調査がしやすくなります。

GPv2移行で料金はどう変わるのか

GPv2へのアップグレード操作自体は無料です。ただし、アップグレード後はGPv2の料金体系が適用されるため、月額料金が変わる可能性があります。(Microsoft Learn)

主な料金要素は次のとおりです。

保存しているデータ容量
Hot、Cool、Cold、Archiveなどのアクセス層
読み取り、書き込み、一覧取得などのトランザクション
CoolやArchiveデータの読み出し
冗長化方式
geoレプリケーションのデータ転送
Azureリージョン外への送信
アクセス層の変更

容量単価だけでアクセス層を決めない

CoolやArchiveは容量単価を抑えられる一方、読み出しやトランザクションの料金が高くなる傾向があります。

たとえば、毎日参照する画像やログをCoolへ移すと、保存料金は下がってもアクセス料金が増え、合計額が高くなる可能性があります。

反対に、長期間保管し、障害時にしか読み出さないバックアップデータでは、CoolやArchiveとライフサイクル管理を組み合わせることで費用を抑えられる場合があります。

トランザクションの多い処理に注意する

次のようなワークロードでは、データ容量よりトランザクション料金の影響が大きくなることがあります。

小さなファイルを大量に読み書きする
Blob一覧を短い間隔で繰り返し取得する
バックアップソフトが頻繁にメタデータを走査する
ETL処理が大量のBlobを個別に確認する
監視処理が全コンテナーを定期スキャンする

料金試算では、保存容量だけでなく、読み取り、書き込み、一覧取得の回数を入力してください。

移行前に用意する料金データ

Azure料金計算ツールで試算する前に、直近30日から90日程度の次の情報を集めます。

平均保存容量
月末時点の保存容量
月間の読み取り回数
月間の書き込み回数
月間の一覧取得回数
読み出したデータ量
書き込んだデータ量
Azure外へ送信したデータ量
現在の冗長化方式
現在の請求書に記載されたストレージ関連メーター

Microsoftも、Azure Monitorの容量・トランザクション指標と現在の請求データを使って、GPv2移行後の費用を試算するよう案内しています。(Microsoft Learn)

Microsoftの自動移行に任せてもよいのか

期限までに対応しなかったLegacy Blob Storageアカウントは、MicrosoftによるGPv2への自動移行対象になります。自動移行によって請求額が増える可能性があり、移行タイミングや結果はアカウントによって異なると案内されています。(Microsoft Learn)

そのため、自動移行を通常の移行計画として利用することは推奨できません。

自動移行に任せると、次の問題が起きやすくなります。

変更日時を自社で管理できない
本番アプリケーションの検証を事前に実施できない
アクセス層を費用面から十分に検討できない
IaCの定義が旧アカウント種別のまま残る
移行後の料金増加に気付くのが遅れる
一時的なアクセス影響が発生した際に原因を特定しにくい

公式FAQでは、廃止期限に対する例外は提供されないとされています。(Microsoft Learn)

Azure DatabricksのDBFSアカウントは特別扱い

Azure Databricksが管理するリソースグループ内にあるDBFS用ストレージアカウントは、通常のユーザー管理アカウントとは扱いが異なります。

Microsoftの案内では、Databricks管理リソースグループ内にある読み取り専用のDBFSアカウントについて、利用者側の対応は不要です。Microsoftが2026年10月13日より前にGPv2へ移行します。(Microsoft Learn)

DBFSアカウントには、次のような特徴があります。

アカウント名がdbstorageで始まることが多い
DatabricksのManaged Resource Group内にある
利用者が変更や削除を実行できない
ワークスペース内部の処理に使用されている

ただし、dbstorageは予約済みの接頭辞ではありません。名前だけで判断せず、Databricksの管理リソースグループに含まれ、ユーザーが読み取り専用になっていることを確認してください。

自社で作成し、自社のワークロードから直接利用しているBlobStorageまたはStorageアカウントは、通常どおり対応が必要です。

移行時によくある失敗

Azure Blob Storageを使っているアカウントをすべて対象にしてしまう

対象判定はBlobの利用有無ではなく、アカウントのkindで行います。StorageV2を利用しているアカウントは今回の廃止対象ではありません。

新規作成停止の延期を廃止日の延期と勘違いする

2026年6月11日に変更されたのは、新規作成停止時期です。廃止日は2026年10月13日のままです。

アクセス層を容量単価だけで選ぶ

CoolやArchiveを選ぶと保存料金を抑えられる場合がありますが、読み出しやトランザクションが多いシステムでは総額が増えることがあります。

Azure上のリソースだけ変更する

Terraform、Bicep、ARMテンプレート、Azure PolicyなどがBlobStorageのまま残ると、後日のデプロイで失敗したり、意図しない差分が出たりします。

アプリケーション検証を省略する

エンドポイントが変わらなくても、アカウント種別の判定、アクセス層に関する処理、外部製品のサポート条件などが原因で問題が起きる可能性があります。

自動移行があるため何もしない

自動移行は、料金や実施日時を自社で最適化できません。移行後の一時的な影響についても注意が必要です。

Legacy Blob Storage廃止に関するよくある質問

すべてのAzure Blob Storageが使えなくなるのですか

使えなくなるわけではありません。

廃止対象は、アカウント種別がBlobStorageのLegacy Blob Storageアカウントです。GPv2のStorageV2上で提供されるAzure Blob Storageは引き続き利用できます。

データを新しいアカウントへコピーする必要はありますか

通常のLegacy Blob StorageからGPv2へのアップグレードでは、既存アカウントをそのまま変更できるため、データコピーは不要です。Microsoftは、アカウント名やエンドポイントを維持したままアップグレードできると案内しています。(Microsoft Learn)

別リージョンへの移行、アカウント分割、階層型名前空間を有効にした新構成への変更などを同時に行う場合は、新規アカウントへのデータ移動が必要になることがあります。

アップグレードで停止時間は発生しますか

通常のGPv2アップグレードでは、ダウンタイムやデータ損失は発生しないと案内されています。(Microsoft Learn)

ただし、業務システムでは事前検証と作業後の疎通確認を省略しないでください。

アップグレード後に元へ戻せますか

戻せません。GPv2へのアップグレードは不可逆です。(Microsoft Learn)

アップグレードすると必ず料金が上がりますか

必ず上がるわけではありません。

GPv2ではアクセス層やライフサイクル管理を利用できるため、データの利用状況に合わせて費用を抑えられる場合があります。一方、読み書きや一覧取得が多いワークロードでは、トランザクション料金によって請求額が増える可能性があります。

2026年10月13日までに移行できない場合、延長できますか

公式FAQでは例外を提供しないとされています。対象アカウントが見つかった時点で、AzureサポートやMicrosoft担当者へ相談し、期限前の対応計画を作成してください。(Microsoft Learn)

管理者が今すぐ実施すべきこと

最初に、Azure Resource GraphでBlobStorageとStorageを検索してください。

対象が見つかった場合は、次の順番で対応します。

アカウントごとのシステム所有者を決める
接続しているアプリ、バッチ、外部製品を洗い出す
Azure Monitorと請求書から利用状況を取得する
GPv2移行後の料金を試算する
検証環境または影響の小さいアカウントでアップグレードを試す
TerraformやBicepなどのIaC定義を更新する
本番アカウントをGPv2へアップグレードする
アプリケーション、監視、料金を確認する
Resource Graphを再実行し、BlobStorageが残っていないことを確認する

2026年6月11日の更新で新規作成停止時期は2026年9月へ変更されましたが、廃止日は2026年10月13日のままです。新規作成停止を待たず、まず対象アカウントの有無を確認し、料金と動作を自社で管理できる状態でGPv2へ移行することが最も安全です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。