既存の Azure Storage Account を Data Lake Gen2 にアップグレードしようとした際に「Upgrade to a storage account with Azure Data Lake Gen2 capabilities is temporarily unavailable.」と表示され先へ進めない――そんな“あるある”な詰まりを、原因別に切り分けて再現性高く解決するための実務ガイドです。ポータルで失敗しても CLI で突破できるケースや、非互換機能の洗い出し・除去のコマンド例、やむを得ず新規作成＋移行する場合の現実的な運用まで、現場で使える手順をまとめました。
結論サマリ（最初に全体像）
- 一時的なサービス側停止でアップグレード画面がブロックされることがあります。数時間～1日程度のリトライで解消する場合があります。
- 非互換機能の有効化・残骸（スナップショット／ソフト削除／暗号化スコープ／イミュータブル／ページ Blob など）が原因のことが最も多く、無効化→内部クリーンアップ待ちが必要です。
- ポータルで失敗しても、Azure CLI で「HNS Migration」を開始できる場合があります（コマンドは後述）。
- 止まらないシステムでは、新しい HNS 有効アカウントを作成し、AzCopy で逐次移行が安全です。
事象の再現とメッセージ
Azure ポータルのストレージアカウント画面 > データレイク構成（もしくは アップグレード ウィザード）で HNS（階層型名前空間）を有効化しようとすると、ステップ3（実行）で以下のバナーが表示され先に進めないことがあります。
Upgrade to a storage account with Azure Data Lake Gen2 capabilities is temporarily unavailable.
このメッセージは「恒久的に不可能」を意味しません。多くは①サービス側の一時停止、②アカウント側の非互換機能、のどちらかです。以降は、現場の運用で迷いがちなポイントをチェックリスト形式で解消していきます。
アップグレード前の総合チェックリスト
次のいずれかが残っているとアップグレードが拒否される（あるいは開始できない）可能性が高い項目です。表の「確認コマンド例」は代表例であり、環境により権限やパラメータが異なります。
| 項目 | ブロック理由の要点 | 確認ポイント | 代表的な無効化・除去方法 | 補足・落とし穴 |
|---|---|---|---|---|
| Blob スナップショット | HNS への移行時に整合性が取れない | スナップショットが 1 つでも残っていないか | 対象 Blob のスナップショットを削除 | ライフサイクルで自動生成されている場合も |
| Blob / コンテナのソフト削除 | 削除保留中のオブジェクトが残ると移行できない | データ保護設定が有効か、保留件数があるか | 一時的に無効化し、内部クリーンアップ完了まで待機 | 保持期間を短縮してから待つのが現実的 |
| 暗号化スコープ（Encryption Scopes） | スコープ付き暗号化が移行の妨げになる | 定義済みスコープの有無・利用状況 | 使っていないスコープを削除、必要なら一時的に既定暗号化に統一 | アプリ側でスコープ指定していないか確認 |
| イミュータブル（変更不可）/ リーガルホールド | 改ざん不可ポリシーが移行処理をブロック | 対象コンテナ/Blob にポリシーや保留がないか | 一時的に解除（解除可否や承認フローに注意） | 法務手続きが必要な場合あり |
| ページ Blob の存在 | HNS はページ Blob をサポートしないため | どこかに Page Blob が残っていないか | すべて削除し、Block Blob に限定 | VHD 等の痕跡に注意（古いバックアップなど） |
| バージョニング / 変更フィード / PITR | 関連機能がデータ整合の邪魔をすることがある | 有効化状況（特に検証環境での設定） | 一時的に無効化し、残骸が消えるまで待機 | 再有効化の手順をメモしておく |
ポータルでの前処理：どこを見ればいいか
- データ保護（Blob/コンテナの削除保護、バージョニング、ポイントインタイム復元）：一時的にオフにし、保持日数も最短へ。
- 暗号化：暗号化スコープを使用していないか確認。スコープが不要なら削除。
- コンテナごとのイミュータブル/リーガルホールド：有効なものがあれば一時解除。
- コンテナ内のページ Blob：VHD や古いバックアップが残っていないか総点検。
- サービス正常性：対象リージョンで Storage の障害・メンテがないか確認。
CLI での実務チェック（サンプル集）
以下は「代表的な」確認・無効化コマンド例です。Azure CLI のバージョン差異や権限によりパラメータ名が異なることがあります。必ず検証環境で手順を事前確認してください。
アカウント基本情報と HNS 状態
# アカウントの要点確認
az storage account show \
-n <ストレージアカウント名> -g <リソースグループ名> \
--query "{name:name, hns:isHnsEnabled, kind:kind, location:primaryLocation}" -o table
データ保護（ソフト削除・バージョニング等）の確認/一時無効化
# 現在の Blob サービスの保護設定を確認（管理プレーン）
az storage account blob-service-properties show -n <アカウント名> -g <リソースグループ名>
# 一時的に保持機能をオフ（パラメータは CLI のバージョンで差異あり）
az storage account blob-service-properties update
-n <アカウント名> -g <リソースグループ名>
--enable-delete-retention false
--enable-container-delete-retention false 現実的な運用：まず保持日数を最短（例：1日）に下げてから機能を無効化し、内部クリーンアップが完了するまで待機します。保持オブジェクトが多いほど時間がかかります。
暗号化スコープの洗い出しと削除
# スコープ一覧
az storage account encryption-scope list \
-n <アカウント名> -g <リソースグループ名> -o table
# 使っていないスコープを削除（利用中の場合は削除不可）
az storage account encryption-scope delete
-n <スコープ名> --account-name <アカウント名> -g <リソースグループ名> イミュータブル/リーガルホールドの確認と解除
# コンテナ一覧（必要に応じてメタデータも）
az storage container list --account-name <アカウント名> --auth-mode login -o table
# 特定コンテナのイミュータブルポリシー状況（例）
az storage container immutability-policy show
--account-name <アカウント名> -n <コンテナ名>
# リーガルホールド（タグ）解除の例（タグは環境依存）
az storage container legal-hold clear
--account-name <アカウント名> -n <コンテナ名> --tags <タグ1> <タグ2> ページ Blob の検出と除去
# すべてのコンテナで Page Blob を横断検出（Bash 例）
for c in $(az storage container list --account-name <アカウント名> --auth-mode login --query "[].name" -o tsv); do
echo "checking container: $c"
az storage blob list --account-name <アカウント名> --container-name $c --auth-mode login \
--query "[?properties.blobType=='PageBlob'].{name:name,size:properties.contentLength}" -o table
done
# 検出した Page Blob を削除（スナップショットも含めて）
az storage blob delete
--account-name <アカウント名> --container-name <コンテナ名> --name
--auth-mode login --delete-snapshots include アップグレードの実行（CLI 回避策）
ポータルが「一時的に利用不可」で止まる場合でも、CLI から「HNS Migration（タイプ: upgrade）」を開始できることがあります。非互換機能の除去が済んだら実行します。
az storage account hns-migration start --type upgrade \
-n <ストレージアカウント名> \
-g <リソースグループ名>
開始後の確認（CLI のバージョンにより異なります）：
# 進捗/状態を見る（利用可能な場合）
az storage account hns-migration show -n <アカウント名> -g <リソースグループ名>
# 有効化されたかを最終確認
az storage account show -n <アカウント名> -g <リソースグループ名> --query "isHnsEnabled" 重要：アップグレード中は高頻度の書き込みやメタデータ操作でエラー/遅延が発生する可能性があります。可能なら計画停止または低トラフィック時間帯で実施してください。
「いつ再開できるか？」に関する現実的な考え方
- サービス側の一時停止：通常は短時間～1日程度で解消されることが多い印象です。監視・アラートと組み合わせて定期的にリトライしましょう。
- 非互換機能の残骸：保持ポリシーの内部クリーンアップ完了まで待つ必要があり、実データ量・保持期間・リージョンの負荷で数時間～数日かかることがあります。
- 切迫している場合：新規 HNS 有効アカウント作成＋段階移行にシフトすることで、全体の所要時間を可視化しやすくなります。
新規 Gen2 アカウント作成＋データ移行（確実策）
ビジネス継続性を最優先するなら、既存アカウントのアップグレードに固執せず、新規に HNS 有効の汎用 v2 アカウントを作成して移行するのが確実です。
作成時のポイント
- アカウント種別：汎用 v2（General-purpose v2）。
- 階層型名前空間（HNS）を「有効」で作成。
- 必要に応じてネットワーク制限（プライベートエンドポイント/ファイアウォール）、暗号化（CMK）、ログ/メトリクスを初期から整備。
AzCopy による移行例（大容量＆再開可能）
# ローカル -> ADLS Gen2 の例（SAS を利用）
azcopy copy "https://<src-account>.blob.core.windows.net/<container>?<SAS>" \
"https://<dst-account>.dfs.core.windows.net/<filesystem>?<SAS>" \
--recursive=true --overwrite=ifSourceNewer --check-length=true
# アカウント間コピー（サーバーサイドの最短ルートを活用）
azcopy sync "https://.blob.core.windows.net/?"
"https://.dfs.core.windows.net/?"
--recursive=true 運用のコツ：ログ出力・帯域制限（--cap-mbps）・再実行性（同一コマンドで再開）を組み込み、移行ドライラン → 本番差分同期 → 切替の 3 段構えにします。
アップグレード後にやること（再有効化と検証）
- データ保護の再有効化：ソフト削除／バージョニング／PITR など、必要な機能を元に戻します。
- ACL/RBAC の整備：ADLS Gen2 では POSIX 風 ACL が使えます。
Storage Blob Data Owner/Contributor/Readerの RBAC と合わせて最小権限に。 - アプリ検証：BFS エンドポイント（
https://<account>.dfs.core.windows.net）の疎通、SDK/ドライバー（ABFS/ADLS Gen2）での読み書き、既存アプリの互換性を確認します。
ADLS Gen2 コマンド（ファイルシステム操作）
# 必要に応じて拡張を追加してから利用（環境による）
# az extension add -n storage-preview
# ファイルシステム（=従来のコンテナ相当）の一覧
az storage fs list --account-name <アカウント名> --auth-mode login -o table
# ルートの ACL を確認
az storage fs access show --account-name <アカウント名> -f --path / エラー別・すぐに使える対処早見表
| エラー/症状 | 原因の切り口 | 一次対応 | 恒久対応 |
|---|---|---|---|
| temporarily unavailable | サービス側の一時停止 / メンテ | 時間を空けて再試行、CLI での開始も試す | メンテ情報の監視と実施ウィンドウの確保 |
| Page Blob detected | ページ Blob が 1 つでも残っている | 全コンテナ横断で Page Blob を削除 | 以後は Block Blob のみ運用に統一 |
| Soft delete must be disabled | Blob/コンテナのソフト削除が有効 | 無効化し内部クリーンアップ完了まで待つ | 再有効化のポリシーをドキュメント化 |
| Encryption scopes in use | 暗号化スコープが残っている/利用中 | 未使用スコープ削除、使用中は一時切替 | 移行後の暗号化設計を整理 |
| Immutability policy blocks upgrade | 変更不可/リーガルホールドが有効 | 手続きの上で一時解除 | 必要に応じて移行後に再設定 |
運用に効く「手順書テンプレ」（コピペ用）
- 周知・承認：影響範囲とリスク（短時間の書込み失敗可能性）を関係者に周知し承認取得。
- 事前バックアップ：必要に応じてエクスポートや DR 側との整合を確認。
- 前提チェック：前掲チェックリストを実施（スナップショット/ソフト削除/暗号化スコープ/イミュータブル/ページ Blob）。
- データ保護を最小化：保持日数短縮 → 機能無効化。
- 内部クリーンアップ待機：ジョブ監視（メトリクス/ログ）を行い、完了を待つ。
- CLI でアップグレード開始：
az storage account hns-migration start --type upgrade ... - 有効化確認：
isHnsEnabledがtrueになること、BFS エンドポイント疎通、ACL 操作を確認。 - 機能の再有効化：ソフト削除/バージョニング等を元に戻す。
- アプリ検証：読み書き・リネーム・権限変更・ジョブの一巡確認。
- ドキュメント更新：運用基準・監視項目・権限表を更新。
新規作成＋移行とアップグレード直適用の比較
| 方式 | メリット | デメリット | 向いているケース |
|---|---|---|---|
| 既存アカウントをアップグレード | 名前や接続先の変更が最小 | 前処理が煩雑、クリーンアップ待ちで読めない時間が読みづらい | 非互換機能が少なく、停止許容がある |
| 新規 HNS アカウント＋移行 | 切替の見通しが良く、リハーサルしやすい | 接続先変更・DNS/接続文字列の切替が必要 | 止められない・大容量・期日が明確 |
権限とセキュリティの観点
- 管理プレーン：ストレージアカウントの更新やデータ保護設定の変更には、Storage Account Contributor 等の権限が必要。
- データプレーン：ADLS Gen2 のアクセス制御は Storage Blob Data* ロールと POSIX 風 ACL の二層構造。最小権限で段階付与を徹底。
- 監査：変更履歴（活動ログ）、アクセスログ（診断設定）を有効化して追跡性を担保。
互換性の注意点（アプリ側）
- HNS 有効化後は dfs.core.windows.net（BFSエンドポイント） が追加され、Hadoop/ABFS ドライバー等でのアクセスが可能になります。
- 多くの Blob API は継続利用可能ですが、ページ Blob が使えないなどの差分があるため、アプリの I/O パターン（特に大規模リネームやフォルダ操作）を実検証します。
- SDK/ドライバのバージョン要件（ABFS/ADLS Gen2）がある場合は早めに更新を。
トラブルシュートの深掘り
内部クリーンアップが終わったか判断できない
保持機能を無効化しても、削除保留中のオブジェクトが多いとバックグラウンドのクリーンアップに時間がかかります。メトリクスや監視ログで削除件数が収束しているか、コンテナ列挙で削除保留が消えているかを観察し、再度アップグレードを試みます。
暗号化スコープが削除できない
コンテナや Blob が暗号化スコープに紐づいていると削除できません。アプリの接続文字列やアップロード処理でスコープ指定していないかを洗い出し、既定暗号化へ切り替えてから再試行します。
イミュータブル/リーガルホールドが解除できない
法的要件や監査要件で強制されています。アップグレードのタイムラインと要件を関係部門と調整し、新規アカウント＋移行へ切り替える判断が安全です。
実行後の健全性チェック（サンプル）
# HNS 有効化の最終確認
az storage account show -n <アカウント名> -g <RG> --query "isHnsEnabled"
# BFS 経由のファイル作成 → 取得テスト（擬似例）
az storage fs file upload --account-name <アカウント名> -f
-s ./README.txt -p /README.txt --auth-mode login
az storage fs file show --account-name <アカウント名> -f -p /README.txt よくある質問（FAQ）
Q. アップグレードはロールバックできますか？
A. できません。HNS を無効化する操作は提供されていないため、戻す必要がある場合は非 HNS の新規アカウントを用意し、データを戻します。
Q. コストは変わりますか？
A. 課金モデル（容量・トランザクション）の根本は大きく変わりませんが、HNS によりディレクトリ操作が増えるとトランザクション課金の傾向が変わることがあります。監視で傾向把握を。
Q. いつアップグレード可能になりますか？
A. サービス側停止の場合は短時間～1日程度で復旧するケースが多く、アカウント側要因の場合は保持データ量に依存します。非互換機能の除去を完了→定期リトライ→期限が近いなら新規作成＋移行へ切り替えが実務的です。
まとめ：迷ったら「前処理の徹底」か「新規＋移行」
HNS へのアップグレードが止まる根っこは、（1）タイミング依存の一時停止、（2）アカウント側の非互換機能です。前処理のチェックリストと CLI による強制開始で多くのケースは解決できます。どうしても前に進まないときは、新規 Gen2 アカウントを用意して AzCopy で段階移行――この二段構えを標準手順にしておけば、期日と品質の両立が現実的になります。
付録：コマンド早見カード
| 目的 | コマンド例 |
|---|---|
| HNS 状態確認 | az storage account show --query "isHnsEnabled" |
| Blob 保護設定の表示 | az storage account blob-service-properties show -n <acct> -g <rg> |
| 保護設定の一時無効化 | az storage account blob-service-properties update --enable-delete-retention false --enable-container-delete-retention false |
| 暗号化スコープ一覧/削除 | az storage account encryption-scope list / delete |
| イミュータブル/リーガルホールド | az storage container immutability-policy show / legal-hold clear |
| ページ Blob 検出 | az storage blob list --query "[?properties.blobType=='PageBlob']" |
| HNS 移行開始 | az storage account hns-migration start --type upgrade -n <acct> -g <rg> |
付録：作業前後のチェックリスト（印刷推奨）
- 権限確認（管理/データプレーン）。
- バックアップ/リストア手順の点検。
- 非互換機能の棚卸し（スナップショット、ソフト削除、暗号化スコープ、イミュータブル、ページ Blob）。
- 保持日数の最小化・無効化と、内部クリーンアップ完了の監視。
- CLI で HNS 移行開始、完了の確認。
- データ保護/監視/ログの再有効化。
- アプリのエンドツーエンド検証。
- ドキュメント更新と関係者への周知。
コメント