Azure Storage の GPv1 storage account retirement は、古い「汎用 v1（GPv1）ストレージ アカウント」を GPv2 へ移行する必要がある重要な変更です。結論からいうと、GPv1 を利用している環境では、2026年10月13日の廃止期限までに GPv2 へアップグレードし、課金・アクセス層・冗長性・自動化スクリプトへの影響を事前に確認する必要があります。Microsoft Learn の 2026年7月2日更新情報では、期限までに移行しない場合、既存の GPv1 アカウントは GPv2 へ自動移行される可能性があり、意図しない課金増につながる点が強調されています。(Microsoft Learn)
この記事では、「GPv1 storage account retirement overview – Azure Storage」の更新ポイントをもとに、影響範囲、移行期限、設定変更、費用面の注意点、Azure 管理者が今すぐ確認すべき実務ポイントを整理します。特に、グローバル環境で複数サブスクリプションや複数リージョンを運用している組織では、「対象アカウントの棚卸し」と「費用試算」を先に行うことが重要です。
Azure の「GPv1 storage account retirement overview」で押さえるべき変更点
今回の更新で最も重要なのは、GPv1 が段階的に廃止され、GPv2 への移行が事実上必須になる点です。GPv1 は、Blob、Files、Queues、Tables といった初期の Azure Storage シナリオを支えるアカウント種別でしたが、現在は GPv2 が標準的なストレージ アカウントとして推奨されています。GPv2 では、Blob のアクセス層、ライフサイクル管理、より柔軟な冗長性、最新機能への対応などが利用できます。(Microsoft Learn)
今回の変更は、単なる名称変更ではありません。ストレージ アカウントの種類が GPv2 に変わることで、Blob Storage の課金モデル、アクセス層の考え方、運用自動化、コスト最適化の設計が変わります。移行自体は多くのケースでダウンタイムなしに実行できますが、アップグレード後は GPv1 に戻せないため、事前確認を省略すると運用面・費用面で問題が出る可能性があります。(Microsoft Learn)
GPv1 廃止の対象になる Azure Storage アカウント
対象になるのは、主に kind が Storage の汎用 v1 ストレージ アカウントです。Microsoft Learn の概要では、GPv1 だけでなく、レガシー Blob Storage アカウントも影響対象として確認する必要があるとされています。複数の Azure サブスクリプションを持つ企業では、古い検証環境、部門管理のリソース グループ、長期間変更されていないバックアップ用ストレージに残っていることがあります。(Microsoft Learn)
| 確認対象 | 見るべきポイント | 実務上の注意 |
|---|---|---|
| GPv1 ストレージ アカウント | kind が Storage になっていないか | 古い ARM テンプレートやスクリプトで作成されている場合がある |
| レガシー Blob Storage アカウント | kind が BlobStorage になっていないか | GPv2 へ統合する前提で確認する |
| ZRS など古い冗長構成 | SKU とリージョンの組み合わせ | 現在の GPv2 で選べる冗長性と違う場合がある |
| 自動化テンプレート | Bicep、ARM、Terraform、CLI など | StorageV2 を前提に修正が必要なことがある |
| 請求・タグ管理 | 部門、用途、コストセンターのタグ | 移行後の費用比較に必要 |
ポイントは、「本番で使っている大きなストレージ」だけを探さないことです。ログ保管、古いアプリの添付ファイル、監査データ、部門別バックアップなど、普段あまり触らないアカウントほど GPv1 のまま残りやすくなります。
移行期限とスケジュール
Microsoft Learn の FAQ では、GPv1 ストレージ アカウントは 2026年10月13日に廃止され、この日付より前に GPv2 へアップグレードする必要があると説明されています。また、2026年9月以降は Azure Resource Manager API 経由での新規 GPv1 作成もブロックされるとされています。(Microsoft Learn)
| 時期 | 変更内容 | 管理者がやるべきこと |
|---|---|---|
| 2025年9月 | GPv1 廃止が発表 | 既存環境に GPv1 が残っていないか棚卸しする |
| 2026年7月時点 | 公式ドキュメントが更新 | 移行計画、費用試算、検証環境でのテストを進める |
| 2026年9月 | 新規 GPv1 作成がブロックされる段階 | テンプレートや自動化スクリプトの StorageV2 対応を完了する |
| 2026年10月13日 | GPv1 廃止期限 | 本番環境の GPv2 移行を完了しておく |
| 期限後 | 未移行の GPv1 が自動移行される可能性 | Microsoft 任せにせず、事前に課金・設定を管理する |
「自動移行されるなら放置してもよい」と考えるのは危険です。自動移行では、組織側がアクセス層、ライフサイクル管理、コスト最適化、検証タイミングを十分にコントロールできません。Microsoft も、期限までに移行しない場合は GPv2 へ自動移行され、課金コストが高くなる可能性があると説明しています。(Microsoft Learn)
GPv1 と GPv2 の主な違い
GPv2 は GPv1 の後継として、Azure Storage の最新機能を利用できるアカウント種別です。特に大きな違いは、Blob のアクセス層、ライフサイクル管理、イベント連携、冗長性、価格モデルです。(Microsoft Learn)
| 項目 | GPv1 | GPv2 |
|---|---|---|
| Blob アクセス層 | 非対応 | Hot、Cool、Cold、Archive などに対応 |
| ライフサイクル管理 | 非対応 | ルールに基づく自動階層移動に対応 |
| Immutable Blob Storage | 非対応 | 対応 |
| Event Grid 連携 | 限定的 | 対応 |
| 冗長性オプション | 限定的 | LRS、ZRS、GRS、RA-GRS、GZRS、RA-GZRS などに対応 |
| 課金モデル | 古いモデル | アクセス層・操作回数を考慮したモデル |
| 推奨度 | 廃止対象 | 多くの Azure Storage シナリオで推奨 |
GPv2 へ移行すると、単に新しい機能が使えるだけではありません。アクセス頻度に応じて Blob を Hot、Cool、Cold、Archive に分けたり、一定期間アクセスされていないデータをライフサイクル管理で自動的に低コストな層へ移動したりできます。一方で、読み取り・書き込み・一覧取得などのトランザクションが多いワークロードでは、費用が増える可能性があります。(Microsoft Learn)
影響範囲：アプリケーションよりも「課金」と「運用設計」に注意
GPv1 から GPv2 へのアップグレードは、多くの場合、アプリケーションの接続先エンドポイントやデータを変更せずに実行できます。Microsoft Learn でも、アップグレードは中断を伴わず、同じエンドポイント名とデータを維持できると説明されています。(Microsoft Learn)
ただし、影響がないと考えるのは早計です。実務では、次のような部分に影響が出やすくなります。
| 影響箇所 | 起こり得る問題 | 確認方法 |
|---|---|---|
| Blob Storage の課金 | 読み書きや一覧取得が多い環境で費用が増える | Azure Cost Management、請求明細、Azure Monitor メトリックを確認 |
| 既定のアクセス層 | Hot/Cool の選択を誤ると想定外の料金になる | アクセス頻度、保持期間、復元要件を確認 |
| ライフサイクル管理 | 早期削除や階層移動の費用を見落とす | 保持期間と削除ルールを設計 |
| IaC・自動化 | Storage 前提のテンプレートが残る | Bicep、ARM、Terraform、CLI、PowerShell を検索 |
| 監視・運用手順 | メトリックやアラートの前提が古い | 移行後に監視項目と費用アラートを再確認 |
| セキュリティ・コンプライアンス | Immutable Blob や監査要件との整合が必要 | 保持ポリシー、バックアップ、監査要件を確認 |
特に注意したいのは、バックアップやログ保管のように「保存量は多いがアクセス頻度は低い」ワークロードです。この場合、GPv2 のアクセス層を適切に設計すればコストを下げられる可能性があります。一方、アプリが大量の小さな Blob を頻繁に読み書きする場合、トランザクション課金の影響を試算する必要があります。
設定変更で重要になるアクセス層の選び方
GPv2 では、Blob データに対して Hot、Cool、Cold、Archive といったアクセス層を利用できます。Hot は頻繁にアクセスするデータ向け、Cool や Cold はアクセス頻度が低いがオンラインで取り出したいデータ向け、Archive は長期保管で即時アクセスが不要なデータ向けです。Microsoft Learn では、Cool は最低 30 日、Cold は最低 90 日、Archive は最低 180 日の保持を前提に設計する必要があると説明されています。(Microsoft Learn)
| アクセス層 | 向いている用途 | 注意点 |
|---|---|---|
| Hot | Web アプリの添付ファイル、頻繁に参照する画像、処理中データ | 保存単価は高めだがアクセスコストは低め |
| Cool | 月次レポート、短期バックアップ、たまに参照するデータ | 30日未満で削除・移動すると早期削除料金に注意 |
| Cold | 低頻度アクセスのログ、長めのバックアップ、監査用データ | 90日未満での削除・移動に注意 |
| Archive | 長期保管、法定保存、ほぼ参照しない原本データ | オフライン層のため、読み取り前にリハイドレートが必要 |
移行時に既定のアクセス層を指定しない場合、Hot が既定になる可能性があります。Hot は頻繁にアクセスするデータには適していますが、長期保管データまで Hot に置き続けるとコスト最適化の機会を逃します。逆に、頻繁に読み取るデータを Cool や Cold に置くと、アクセスコストが増える可能性があります。移行前に、少なくとも過去 30〜90 日程度のアクセス傾向を確認してから既定層を決めるのが安全です。(Microsoft Learn)
費用面で確認すべきポイント
GPv1 から GPv2 へのアップグレードで最も見落とされやすいのが費用です。Microsoft Learn では、GPv2 では容量単価やアクセス層による最適化が可能になる一方、読み取り、書き込み、一覧取得などの操作が多いワークロードではコストが増える可能性があると説明されています。(Microsoft Learn)
費用試算では、次の順番で確認すると実務に落とし込みやすくなります。
| 確認項目 | 具体的に見るもの | 判断のポイント |
|---|---|---|
| 保存容量 | Blob の総容量、月次増加量 | 容量が大きいほどアクセス層設計の効果が出やすい |
| 読み取り量 | GetBlob、CopyBlob、Egress など | 参照頻度が高いデータは Hot を検討 |
| 書き込み量 | PutBlob、PutBlock、AppendBlock、Ingress など | バックアップやログの書き込み頻度を確認 |
| 一覧・メタデータ操作 | List、Get Properties など | 大量の小ファイル管理で増えやすい |
| 冗長性 | LRS、ZRS、GRS、RA-GRS など | 可用性要件と費用のバランスを確認 |
| データ保持期間 | 30日、90日、180日以上の保持有無 | Cool、Cold、Archive の早期削除料金に注意 |
Azure Files や Azure Disks については、それぞれ独立した価格モデルがあるため、GPv1 から GPv2 へ変換しても Blob Storage の価格にのみ影響すると Microsoft Learn で説明されています。ただし、ストレージ アカウント全体の運用方針やタグ、請求配賦は変わる可能性があるため、FinOps 担当者と一緒に確認するのが安全です。(Microsoft Learn)
管理者が最初に行うべき棚卸し
まず行うべき作業は、Azure Resource Graph、Azure CLI、Azure Policy、ポータルなどを使って GPv1 とレガシー Blob Storage アカウントを洗い出すことです。Microsoft Learn でも、Azure Resource Graph などを使って対象アカウントを特定する手順が示されています。(Microsoft Learn)
Azure Resource Graph で確認する場合は、まず次のような観点で対象を抽出します。
Resources
| where type =~ "microsoft.storage/storageaccounts"
| where kind in~ ("Storage", "BlobStorage")
| project name, kind, location, resourceGroup, subscriptionId, sku=tostring(sku.name), tags
| order by subscriptionId, resourceGroup, nameこのクエリでは、GPv1 に該当しやすい Storage と、レガシー Blob Storage アカウントに該当する BlobStorage を一覧化します。抽出後は、単にアカウント名だけを見るのではなく、所有部門、用途、データ量、最終アクセス傾向、接続しているアプリ、バックアップ要件まで確認してください。
大規模環境では、次のように優先順位を付けると進めやすくなります。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | 本番アプリが利用する GPv1 | 影響範囲が大きく、検証期間が必要 |
| 高 | 大容量 Blob を持つ GPv1 | 費用影響が大きくなりやすい |
| 中 | バックアップ・ログ保管用 GPv1 | アクセス層設計でコスト最適化しやすい |
| 中 | IaC で再作成される可能性がある環境 | 2026年9月以降の作成ブロックで失敗しやすい |
| 低 | 未使用・検証用の小規模アカウント | 削除や統合を検討できる |
GPv2 への移行手順
GPv1 から GPv2 へのアップグレードは、Azure portal、PowerShell、Azure CLI などで実行できます。Microsoft Learn では、アップグレードは Azure Resource Manager 操作としてアカウント種別を変更するものであり、ダウンタイムやデータ損失のリスクはないと説明されています。ただし、アップグレード後は GPv1 に戻せません。(Microsoft Learn)
移行の基本ステップ
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | GPv1 / BlobStorage アカウントを棚卸し | 対象一覧 |
| 2 | 用途、所有者、接続アプリを確認 | 影響範囲表 |
| 3 | Azure Monitor と請求データで利用状況を確認 | 容量・操作・転送量の基準値 |
| 4 | GPv2 のアクセス層と冗長性を設計 | 移行設計書 |
| 5 | 検証環境または低リスク環境でアップグレード | 検証結果 |
| 6 | 本番移行を実施 | GPv2 化されたアカウント |
| 7 | 移行後の動作、請求、監視を確認 | 移行完了確認 |
Azure CLI でアップグレードする場合は、次のようなコマンドを使用します。
az storage account update \
-g <resource-group> \
-n <storage-account> \
--set kind=StorageV2 \
--access-tier=HotPowerShell の場合は、次のように実行します。
Set-AzStorageAccount `
-ResourceGroupName <resource-group> `
-Name <storage-account> `
-UpgradeToStorageV2 `
-AccessTier Hot--access-tier や -AccessTier では、移行後の既定アクセス層を指定します。頻繁にアクセスするデータが中心なら Hot、低頻度アクセスのデータが中心なら Cool を検討します。ただし、既定アクセス層の選択だけで全データの最適化が終わるわけではありません。Blob 単位の階層設定やライフサイクル管理も合わせて設計する必要があります。(Microsoft Learn)
Azure Policy を使った移行管理
複数サブスクリプションを管理している場合、手作業だけで GPv1 を探して移行するのは現実的ではありません。Microsoft Learn では、deployIfDoesNotExist Azure Policy を使って GPv1 アカウントを検出し、非中断のインプレース アップグレードを実行できると説明されています。(Microsoft Learn)
Azure Policy を使う場合は、いきなり自動修復を本番全体に適用するのではなく、次の順序が安全です。
| フェーズ | 推奨アクション |
|---|---|
| 監査 | まずは Audit 効果で GPv1 の残存状況を確認する |
| 分類 | 本番、検証、未使用、削除候補に分ける |
| 検証 | 低リスクなアカウントで GPv2 化を確認する |
| 展開 | 管理グループまたはサブスクリプション単位で段階適用する |
| 継続監視 | 新規に GPv1 相当の構成が作られないようにする |
組織のルールとしては、「新規作成するストレージ アカウントは原則 StorageV2」「例外が必要な場合は期限付きで承認」「テンプレートとポリシーの両方で制御」としておくと、移行後の再発を防ぎやすくなります。
移行前に確認すべきチェックリスト
GPv2 への移行で失敗しやすいのは、技術的なアップグレード操作そのものではなく、周辺の確認不足です。次のチェックリストを使うと、抜け漏れを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| 対象アカウント | GPv1 とレガシー Blob Storage をすべて一覧化したか |
| 所有者 | 各アカウントの業務担当、アプリ担当、運用担当を特定したか |
| 利用状況 | 容量、読み取り、書き込み、一覧取得、転送量を確認したか |
| アクセス層 | Hot / Cool / Cold / Archive の方針を決めたか |
| 冗長性 | 現在の SKU と移行後の冗長性を比較したか |
| 費用試算 | Azure 料金計算ツールや請求データで移行後費用を見積もったか |
| アプリ影響 | 接続文字列、SDK、API、ハードコードされた前提を確認したか |
| IaC | Bicep、ARM、Terraform、CLI、PowerShell を修正したか |
| 監視 | 移行後のメトリック、アラート、予算アラートを設定したか |
| ロールバック方針 | GPv1 には戻せない前提で、事前検証と変更承認を行ったか |
特に「アップグレードは非中断だから検証不要」と判断するのは避けるべきです。エンドポイントやデータが維持されても、アプリケーション側でアカウント種別を参照していたり、課金前提を固定していたり、ライフサイクル管理に対応していない運用手順が残っていたりする場合があります。
グローバル環境での注意点
今回の GPv1 廃止は、Azure の全リージョンにグローバルで適用される変更です。Microsoft Learn の概要でも、廃止はすべての Azure リージョンに適用されると説明されています。(Microsoft Learn)
グローバル企業や海外拠点を持つ組織では、次の点を追加で確認してください。
| 観点 | 確認ポイント |
|---|---|
| リージョン差 | 各リージョンで利用している冗長性と GPv2 の対応状況 |
| 時差・変更窗口 | 本番移行の作業時間を地域ごとに調整 |
| データ主権 | データ所在地、バックアップ、レプリケーション先の要件 |
| 課金通貨 | リージョン別料金、為替、契約形態の違い |
| 運用権限 | 各国・各部門のサブスクリプション管理権限 |
| コンプライアンス | 監査ログ、保持期間、削除ポリシー、暗号化要件 |
特に、海外拠点が独自に作成した古いサブスクリプションや、買収した企業の Azure 環境には GPv1 が残っている可能性があります。管理グループ単位で Resource Graph を実行し、タグが未整備のアカウントも含めて確認することが重要です。
よくある失敗パターン
費用試算をせずに一括移行する
GPv2 は多くのシナリオでコスト最適化しやすい一方、アクセス回数が多いワークロードではトランザクション料金の影響を受けます。特に、大量の小さな Blob を頻繁に一覧取得するアプリや、短時間に大量の読み書きを行う処理では、移行後の請求を必ず確認してください。(Microsoft Learn)
既定アクセス層を何となく Hot にする
Hot は無難に見えますが、低頻度アクセスの長期保管データが多い場合、Cool、Cold、Archive やライフサイクル管理を使わないとコスト最適化の効果が出にくくなります。一方で、参照頻度が高いデータを安易に Cool や Cold にすると、アクセスコストや早期削除料金が問題になります。
IaC やスクリプトの修正を忘れる
既存アカウントを GPv2 にしても、Terraform、Bicep、ARM テンプレート、社内 CLI スクリプトが GPv1 前提のままだと、再デプロイ時にエラーや差分が発生します。2026年9月以降は新規 GPv1 作成がブロックされるため、移行作業と同時にテンプレートも修正しておく必要があります。(Microsoft Learn)
未使用アカウントを移行対象に含めてしまう
棚卸しで見つかった GPv1 をすべて移行する前に、削除できるもの、統合できるもの、保管要件が切れているものを確認しましょう。移行はよい機会ですが、不要なストレージをそのまま GPv2 化すると、古い運用負債を延命してしまいます。
まず着手すべき実務アクション
GPv1 storage account retirement への対応では、次の順番で進めると無理がありません。
| 期限の目安 | アクション |
|---|---|
| すぐ | Resource Graph で GPv1 / BlobStorage を棚卸しする |
| 1〜2週間以内 | 所有者、用途、容量、アクセス傾向を整理する |
| 1か月以内 | 費用試算とアクセス層設計を行う |
| その後 | 低リスク環境から GPv2 へ移行する |
| 2026年9月前 | IaC、テンプレート、Azure Policy を GPv2 前提に修正する |
| 2026年10月13日前 | 本番環境の GPv2 移行と移行後確認を完了する |
最初のゴールは「すべての GPv1 をすぐ移行すること」ではなく、「どこに何があり、どれをいつ移行すべきかを把握すること」です。対象が数個であれば Azure portal で確認しても構いませんが、複数サブスクリプションを運用している場合は、Azure Resource Graph と Azure Policy を組み合わせて継続的に管理するのが現実的です。
まとめ：GPv1 廃止対応は「期限前の自主移行」が基本
Azure の GPv1 storage account retirement は、2026年10月13日の廃止期限に向けて、GPv1 ストレージ アカウントを GPv2 へ移行する必要がある変更です。期限までに対応しない場合、既存の GPv1 は自動的に GPv2 へ移行される可能性がありますが、課金や構成を自社でコントロールするためにも、期限前の自主移行が基本です。(Microsoft Learn)
管理者はまず、Resource Graph などで対象アカウントを棚卸しし、Blob の容量、アクセス頻度、トランザクション数、冗長性、アクセス層を確認してください。そのうえで、費用試算、検証環境でのアップグレード、IaC の修正、Azure Policy による継続管理を進めると、移行リスクを抑えられます。
GPv2 への移行は、古いストレージ アカウントを新しい標準へ合わせるだけでなく、アクセス層やライフサイクル管理を使ってストレージ コストを見直す機会でもあります。まずは対象一覧を作成し、2026年9月までに移行計画とテンプレート修正を終えることから始めましょう。
コメント