Microsoftは、Azure Storageの「レガシー（Legacy）Blob Storageアカウント」を2026年10月に完全廃止する。対象アカウントを期限までに汎用v2（General-purpose v2、以下GPv2）へ移行しない場合、Microsoftが自動的に移行を実施し、結果として課金体系が変わる可能性がある。日本語での言及がまだ少ない話題だけに、該当アカウントを持つ企業は今のうちに確認しておきたい。

レガシーBlob StorageとGPv2、何が違うのか

従来のレガシーBlob Storageアカウントは、アクセス層（Hot/Cool/Archive）の設定が「アカウント単位」でしかできなかった。これに対しGPv2は、Blobごとの個別階層設定に加えて、ライフサイクル管理による自動階層移行、不変（Immutable）Blobストレージ、Event Grid連携、そしてBlob以外のTable・Queue・Filesサービスへの対応まで含む、Azure Storageの標準構成だ。料金体系も一貫しており、Microsoftとしてはプラットフォームを単純化し、全顧客に最新機能と統一された課金モデルを提供する狙いがある。

廃止までのタイムラインと「自動移行」の重み

  • 2025年9月: 廃止方針を発表
  • 2026年9月: レガシーBlob Storageアカウントの新規作成を停止
  • 2026年10月: 完全廃止。残存するレガシーアカウントはGPv2へ自動移行され、以降アクセスがブロックされる

注意すべきは、Microsoftの公式文書が「移行しないという選択は、Microsoftが代わりに移行することへの同意とみなす」と明記している点だ。つまり何もしなければ、自分の与り知らぬところで移行が実行され、気づいたときには課金額が変わっている、という展開になりかねない。

実務への影響

日本のエンジニア・IT管理者が今すぐ取るべき行動は明確だ。まずAzure Resource GraphやAzureポータル、CLIを使って自社のレガシーBlob Storageアカウントを棚卸しする。幸い、大半のBlobオンリーのワークロードはGPv2移行にあたってコード変更が不要だ。ただし、階層を意識しない古いコストロジックやハードコードされた料金前提が残っていないかは要チェックとなる。移行前にはAzure料金計算ツールで新しい課金モデル（Blobごとの階層別課金・トランザクション課金）を試算しておくと安心だ。また、多数のアカウントを抱える組織では、deployIfNotExistsのAzure Policyを使えば対象アカウントの検知から非破壊的なアップグレードまで自動化できる。手動で個別対応するより、ポリシーベースで横展開する方が現実的だろう。

筆者の見解

Azureのプラットフォームとしての信頼は、今も揺るがないと筆者は考えている。ストレージ層のような地味な基盤コンポーネントを、派手なAI発表の裏で地道にモダナイズし続ける姿勢は、実は最も評価すべき部分だ。ただ、今回のような重要な廃止告知について日本語での発信がまだ薄いのは正直もったいない。せっかく価値のある移行パスを用意しているのだから、日本の顧客によりわかりやすく届ける努力があってもいいはずだ。

もう一つ、これは筆者が一貫して主張していることだが、「今動いているから大丈夫」という発想はクラウド運用において通用しない。今回のレガシーBlob Storageのように、明示的に手を打たなければ気づかぬうちに構成や課金体系が変わるケースは、Azureに限らず今後も起こり得る。定期的な構成の棚卸しを「やらされ仕事」として片付けるのではなく、標準的な運用プロセスに組み込んでおくことが、こうした変更に振り回されないための最善策だ。

出典: この記事は Legacy Blob Storage account retirement overview の内容をもとに、筆者の見解を加えて独自に執筆したものです。