MENU

Storage AccountsのRetirementとは？GPv1・Legacy Blobの作成停止と移行期限

Azure

2026年6月11日に公開・更新されたAzureの公式情報では、Storage Accountsの「Retirement: GPv1 and Legacy Blob storage account creation」が案内されました。結論として、新しいストレージアカウントはGPv2（StorageV2）で作成し、既存のGPv1とLegacy Blob Storageは2026年10月13日までにGPv2へアップグレードする必要があります。

期限まで放置した場合はMicrosoftによる自動移行の対象となり、料金体系の変化や一時的なアクセス影響が発生する可能性があります。ストレージアカウントがすぐ停止する変更ではありませんが、管理者は対象アカウントの棚卸し、IaCの修正、料金試算を早めに進めるべきです。(Microsoft Azure)

目次

Storage AccountsのRetirementで何が変わるのか

今回の変更では、Azure Storageの旧世代アカウントであるGPv1とLegacy Blob Storageが段階的に廃止され、GPv2へ集約されます。

対象となるアカウントの違いは次のとおりです。

アカウントの種類ARM上のkind主な用途対応
General-purpose v1（GPv1）StorageBlob、Files、Queue、TableGPv2へアップグレード
Legacy Blob StorageBlobStorageBlob専用GPv2へアップグレード
General-purpose v2（GPv2）StorageV2Azure Storageの標準アカウント今回の廃止対象外

GPv1はBlob、Azure Files、Queue、Tableを利用できますが、Blobのアクセス層やライフサイクル管理など、現在のAzure Storageで一般的な機能に制限があります。

Legacy Blob StorageはBlob専用の旧アカウントです。GPv2ではBlob単位のアクセス層、ライフサイクル管理、より多くの冗長性オプションなどを利用できます。(Microsoft Learn)

新規作成の停止と既存アカウントの廃止は別の変更

今回の情報を理解するうえで重要なのは、新規作成のブロックと既存アカウントの廃止を分けて考えることです。

時期変更内容管理者が行うこと
2026年6月1日Azure Updatesでは新規アカウント作成のブロックを案内新規構築をStorageV2へ変更
2026年10月13日GPv1とLegacy Blob Storageの最終的な廃止期限既存アカウントを期限前にGPv2へ移行
期限経過後残存アカウントがMicrosoftによる自動移行の対象になる自動移行に任せず事前に対応

2026年6月11日のAzure Updatesでは、2026年6月1日から新規作成をブロックし、2026年10月13日に最終廃止すると案内されています。(Microsoft Azure)

一方、Microsoft Learnの一部ページには、ARM API経由のGPv1作成やLegacy Blob Storageの作成を「2026年9月からブロック」とする記載も残っています。資料間で日付に差があるため、実務ではすでに新規作成できない前提でテンプレートや構築手順を修正してください。(Microsoft Learn)

影響を受けるユーザーとシステム

主に影響を受けるのは、Azureサブスクリプションやデプロイ環境を管理している担当者です。

既存のGPv1またはLegacy Blob Storageを所有している

Azure Portalでストレージアカウントの種類が「Storage」または「BlobStorage」と表示される場合は対象です。

データを参照するだけの一般ユーザーが直接操作する必要はありませんが、アカウントを所有する管理者やシステム担当者による対応が必要です。

ARM、Bicep、Terraformなどで旧アカウントを作成している

IaCテンプレートやスクリプトで、アカウントの種類を次のように指定していないか確認してください。

Storage
BlobStorage

旧アカウントの指定が残っていると、新しい環境のデプロイや災害復旧時の再構築が失敗する可能性があります。既存環境が動作していても、再デプロイできるとは限らない点に注意が必要です。

新規作成では、原則として次の値を使用します。

StorageV2

料金やアクセス層を前提にした処理がある

GPv1とGPv2では、Blob Storageの容量単価やトランザクション課金の考え方が異なります。

特に、次のようなシステムは事前確認が必要です。

  • 読み書き回数が非常に多い
  • 小さなBlobを大量に処理する
  • 料金計算をアプリケーションや運用手順に組み込んでいる
  • アカウント単位のアクセス層を前提にしている
  • アカウントのkindを条件分岐に利用している

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

アカウント数が少ない場合はAzure Portal、複数のサブスクリプションを管理している場合はAzure Resource Graphを使うと効率的です。

Azure Portalで確認する

  1. Azure Portalで「ストレージ アカウント」を開きます。
  2. 対象のストレージアカウントを選択します。
  3. 「概要」または「構成」を開きます。
  4. 「アカウントの種類」を確認します。
  5. StorageまたはBlobStorageであれば移行対象として記録します。

アカウント名だけで種類を判断しないでください。命名規則に「v2」などが含まれていても、実際のkindが旧形式の可能性があります。

Azure Resource Graphでまとめて確認する

Azure PortalのResource Graph Explorerで、次のクエリを実行します。

resources
| where type == "microsoft.storage/storageaccounts"
| where sku.name in~ (
    "Standard_LRS",
    "Standard_GRS",
    "Standard_ZRS",
    "Standard_RAGRS",
    "Standard_RAGZRS"
)
| where kind != "StorageV2"
| project
    name,
    kind,
    location,
    resourceGroup,
    subscriptionId,
    sku,
    managedBy

結果に表示されたアカウントについて、利用システム、管理者、データ量、冗長性、移行予定日を整理します。MicrosoftもAzure Resource Graphを利用したGPv1とLegacy Blob Storageの棚卸し方法を案内しています。(Microsoft Learn)

Databricks管理アカウントは個別に判定する

Databricksの管理対象リソースグループにあり、ユーザー側では読み取り専用となっているDBFS用アカウントは、Microsoftが期限前にGPv2へ移行すると案内されています。

アカウント名がdbstorageから始まることがありますが、名前だけでは確定できません。Databricksの管理対象リソースグループ内にあることと、ユーザーが変更・削除できないことを確認してください。(Microsoft Learn)

GPv1とLegacy Blob StorageをGPv2へアップグレードする手順

通常は、新しいアカウントを作ってデータをコピーするのではなく、既存アカウントの種類をStorageV2へ変更するインプレースアップグレードを利用できます。

標準的なアップグレードでは、データ、サービスエンドポイント、アクセスキー、SASなどが維持され、停止時間やデータコピーも必要ありません。ただし、アップグレード後にGPv1やLegacy Blob Storageへ戻すことはできません。(Microsoft Learn)

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

実行前に、最低限次の項目を確認します。

確認項目確認内容
利用サービスBlob、Files、Queue、Tableのどれを利用しているか
データ容量現在の使用量と月ごとの増加量
トランザクション読み取り、書き込み、一覧取得などの回数
アクセス層HotとCoolのどちらを既定値にするか
冗長性LRS、ZRS、GRS、RA-GRSなど
依存アプリアカウント種類や料金体系を固定的に判定していないか
IaC旧kindがテンプレートに残っていないか

本番アカウントを変更する前に、同じ構成の検証環境で接続、読み書き、バックアップ、監視処理を確認すると安全です。

Azure Portalからアップグレードする

  1. Azure Portalで対象のストレージアカウントを開きます。
  2. 「設定」から「構成」を選択します。
  3. 「アカウントの種類」に表示される「アップグレード」を選択します。
  4. 確認欄にストレージアカウント名を入力します。
  5. 設定内容を確認してアップグレードを実行します。

Azure PowerShellでアップグレードする

Set-AzStorageAccount `
  -ResourceGroupName "<resource-group>" `
  -Name "<storage-account>" `
  -UpgradeToStorageV2 `
  -AccessTier Hot

アクセス頻度が低いBlobを中心に保存している場合は、利用状況と料金を確認したうえでCoolを選択します。

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

az storage account update \
  --resource-group "<resource-group>" \
  --name "<storage-account>" \
  --set kind=StorageV2 \
  --access-tier Hot

アクセス層を指定しない場合は、通常Hotが既定値になります。後からアクセス層を変更すると、保存済みデータに対する読み取りまたは書き込み相当の料金が発生する場合があるため、アップグレード時に決めておくことが重要です。(Microsoft Learn)

Standard_ZRSを利用している場合の注意点

旧GPv1のStandard_ZRSは、現在のGPv2で利用されるZRSとは仕組みが異なります。

対象リージョンが現行のZRSに対応していない場合、同じ冗長性設定のままアップグレードできないことがあります。その場合は、Azureサポートを通じてLRSまたはGRSへ変更するか、ZRS対応リージョンへの移行を検討します。

Resource Graphの結果にStandard_ZRSが含まれている場合は、通常のGPv1よりも先に対応可否を確認してください。(Microsoft Learn)

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

GPv2へのアップグレード操作自体は無料ですが、アップグレード後はGPv2の料金体系が適用されます。

GPv2は一般に容量単価を抑えやすく、Blob単位のアクセス層やライフサイクル管理による最適化が可能です。一方で、読み書き回数が多いワークロードでは、トランザクション料金が増える可能性があります。(Microsoft Learn)

利用状況特に確認する費用
大容量データを長期保存容量単価、Cool・Cold・Archiveの活用
読み書きが多い読み取り・書き込みトランザクション
Coolなどから頻繁に読み出すデータ取得料金
GRS・RA-GRSを利用geoレプリケーションの転送費用
Azure外や別リージョンへ転送アウトバウンドデータ転送料
アクセス層を後から変更層変更に伴う読み取り・書き込み相当料金

料金試算では、Azure Monitorの容量とトランザクションのメトリック、現在の請求明細、Azure Pricing Calculatorを組み合わせます。

特に確認したいのは、次の数値です。

  • Blobの保存容量
  • 1か月あたりの読み取り量と書き込み量
  • GetBlob、PutBlob、CopyBlobなどの操作回数
  • データの保持期間
  • データを再取得する頻度
  • リージョン外への転送量

なお、MicrosoftのFAQでは、GPv1からGPv2への変更で主に影響するのはBlob Storageの料金であり、Azure FilesとAzure Disksは独立した料金体系とされています。(Microsoft Learn)

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

アップグレードが成功したことだけで作業を終了せず、次の項目を確認してください。

アカウントの種類

Azure PortalまたはCLIで、kindがStorageV2になっていることを確認します。

アプリケーションの動作

Blobだけでなく、利用しているAzure Files、Queue、Tableについても読み取りと書き込みをテストします。

エンドポイントやアクセスキーは通常維持されますが、アプリケーション側がStorageやBlobStorageという種類を固定的に判定している場合は修正が必要です。(Microsoft Learn)

監視と料金

アップグレード後は、少なくとも次の項目を監視します。

  • エラー数
  • 可用性
  • 読み取り・書き込みの遅延
  • トランザクション数
  • Blobのアクセス層
  • 日次および月次の料金

移行直後にCost Managementの予算アラートを設定しておくと、想定外のトランザクション増加を早期に検知できます。

よくある疑問

既存のストレージアカウントはすぐ使えなくなる？

新規作成のブロックと同時に、既存アカウントが直ちに停止するわけではありません。ただし、2026年10月13日までにGPv2へ移行する必要があります。(Microsoft Learn)

ストレージアカウントを作り直す必要はある？

標準的なGPv1またはLegacy Blob Storageであれば、既存アカウントをStorageV2へインプレースアップグレードできます。リージョン変更や特殊な冗長性変更を伴う場合は、新規GPv2アカウントへのデータ移行が必要になることがあります。(Microsoft Learn)

接続文字列やURLは変わる？

通常のインプレースアップグレードでは、サービスエンドポイント、アクセスキー、SASなどは維持されます。念のため、アップグレード後に接続テストを実施してください。(Microsoft Learn)

何もしなくても自動移行されるなら放置してよい？

推奨できません。自動移行では、料金、アクセス層、冗長性などが自社の想定と一致しない可能性があります。Microsoft Learnでも、自動移行のタイミングや結果は変動し、アクセスが一時的に影響を受ける可能性があると案内されています。(Microsoft Learn)

GPv2からGPv1へ戻せる？

戻せません。GPv2へのアップグレードは不可逆です。料金試算とアプリケーション検証を行ってから本番環境を変更してください。(Microsoft Learn)

まず対象アカウントの一覧を作成する

最初に行うべき作業は、Azure Resource GraphでStorageV2以外の標準ストレージアカウントを抽出することです。

その後、次の順序で対応します。

  1. StorageとBlobStorageの所有者を特定する
  2. ARM、Bicep、Terraformなどの新規作成定義をStorageV2へ変更する
  3. 容量、トランザクション、アクセス頻度から料金を試算する
  4. HotまたはCoolの既定アクセス層を決める
  5. Standard_ZRSなどの特殊構成を確認する
  6. 検証環境でアップグレードと接続テストを行う
  7. 2026年10月13日より前に本番アカウントをアップグレードする
  8. 移行後のエラー、性能、料金を監視する

今回のStorage AccountsのRetirementは、単に旧アカウントを利用できなくする変更ではありません。新規デプロイの失敗や料金体系の変化にも関係します。自動移行を待たず、対象アカウントの棚卸しとGPv2への計画的なアップグレードを進めることが重要です。

Azure
Azure Storage Blob Storage GPv2 Storage Accounts GPv1

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次