Azure StorageのBlob Storage feature supportとは？2026年5月更新の変更点と確認ポイント

Azure Storageの「Blob Storage feature support in Azure storage accounts」は、ストレージアカウントの種類と、HNS、NFS 3.0、SFTPを有効化しているかによって、Blob Storage各機能の対応状況を判断するための公式対応表です。2026年5月の更新で特に見るべき点は、SFTP有効時のMicrosoft Entra securityの扱いが見直されたことです。一方で、Blob versioning、Change feed、Object replication、Point-in-time restoreなどは、HNS/NFS/SFTP有効時に未サポートの組み合わせが残るため、管理者や開発者は「使いたい機能」と「有効化している設定」をセットで確認する必要があります。(Microsoft Learn)

この情報は、新規構築よりも既存環境の見直しで重要です。たとえば「SFTPを有効にしたストレージアカウントで、Entra ID認証、ライフサイクル管理、レプリケーション、復元機能をどう扱うか」「HNSを有効にしたあとにBlobの保護機能を期待通り使えるか」といった判断に直結します。公式表は今後も変わる可能性があるため、設計書やIaCに一度書いて終わりではなく、機能追加や移行前のチェックリストとして使うのが実務的です。(GitHub)

Azure StorageのBlob Storage feature support in Azure storage accountsとは

Blob Storage feature support in Azure storage accountsは、Azure Blob Storageの各機能が、次の条件で利用できるかを整理したMicrosoft Learnの公式ドキュメントです。

確認軸	見るべき内容
ストレージアカウントの種類	Standard general-purpose v2、Premium block blob account
有効化している機能	HNS、NFS 3.0、SFTP
サポートレベル	完全サポート、プレビュー、未サポート
対象機能	Entra ID認可、Blob versioning、Change feed、Lifecycle management、Object replication、Soft delete、Immutable storage、監視など

ここで重要なのは、この表が「HNS、NFS、SFTPを有効化したことによる影響」を示すものであり、「そのプロトコル経由で機能を実際に使えるか」を完全に保証する表ではない点です。公式ドキュメントでも、たとえばNFS 3.0を有効化してもMicrosoft Entra security自体への影響はない一方、NFS 3.0リクエストをMicrosoft Entra IDで認可することはできない、と説明されています。(Microsoft Learn)

つまり、読み方を間違えると次のような誤解が起きます。

誤解	正しい読み方
✅なら、そのプロトコルで必ず使える	✅は「その設定を有効化しても機能サポートに悪影響がない」という意味で読む
SFTPが✅なら、すべてのSFTP認証方式が一般提供されている	SFTPのMicrosoft Entra IDベースアクセスは別途プレビュー情報を確認する
HNSを有効にしても従来のBlob機能は全部そのまま使える	Versioning、Change feed、Object replicationなどは未サポートの組み合わせがある
Premium block blob accountは高性能なので機能面も標準より広い	アクセス層やライフサイクル階層化、フェールオーバーなどで制限がある

2026年5月更新の主な変更点

2026年5月の更新で注目すべき変更は、SFTP有効時のMicrosoft Entra securityに関する制限表示の見直しです。GitHub上の更新履歴では「SFTP and Entra IDの制限を取り除く」趣旨のコミットがあり、Standard general-purpose v2とPremium block blob accountの両方で、Microsoft Entra securityのSFTP列から制限注釈が外されています。(GitHub)

変更対象	更新前に起こりやすかった判断	更新後の読み方
Microsoft Entra security × SFTP	SFTPを有効化するとEntra ID関連のBlobアクセスに制限があると解釈しやすい	SFTPを有効化しただけでは、Microsoft Entra securityのサポート評価はStandard/Premiumともに✅
Microsoft Entra security × NFS	NFSとSFTPの両方に同じ制限があるように見えやすい	制限注釈はNFS 3.0リクエストに対するものとして残る
SFTP設計	ローカルユーザー前提でしか設計できないと考えがち	SFTPのEntra IDベースアクセスは別機能としてプレビュー提供されているため、採用可否を個別に判断する

ただし、ここで「SFTPのMicrosoft Entra ID対応がすべて一般提供になった」と読むのは危険です。Azure Blob Storage SFTPのMicrosoft Entra IDベースアクセスはパブリックプレビューとして説明されており、有効化するとサブスクリプション全体に適用される点、OpenSSH証明書を使う点、パスワードベース認証はサポートされない点など、別途確認すべき条件があります。(Microsoft Learn)

対象者：誰がこの更新を確認すべきか

この更新は、Azure Storageを単なるファイル置き場として使っている場合よりも、複数のBlob機能を組み合わせている環境で影響が出やすい内容です。

対象者	確認すべきポイント
Azure管理者	既存ストレージアカウントの種類、HNS/NFS/SFTPの有効状態、監査・保護機能の対応状況
クラウドアーキテクト	新規アカウントをStandard GPv2にするかPremium block blobにするか、HNS/SFTP/NFSを同一アカウントにまとめるか
開発者	SDK、REST API、SFTP、NFS、Data Lake Storage APIのどの経路でアクセスするか
セキュリティ担当者	Microsoft Entra ID、RBAC、ローカルSFTPユーザー、Shared Key、SASの使い分け
SRE/運用担当	復元、レプリケーション、フェールオーバー、Azure Monitor、ライフサイクル管理の実効性

特に、SFTPを外部取引先とのファイル連携に使っている組織、Data Lake Storage Gen2としてHNSを有効化している組織、Blob versioningやChange feedを前提にバックアップ・監査設計をしている組織は、早めに棚卸しするべきです。

Standard general-purpose v2 accountsで確認すべき機能

Standard general-purpose v2 accountsでは、HNS、NFS、SFTPを有効化しても多くの基本機能はサポートされています。アクセス層、Blob Storage API、Azure CLI/PowerShell、Blob events、Azure Monitorのログ・メトリック、Soft delete、Lifecycle managementなどは、主要な列で✅になっています。(GitHub)

一方で、次の機能は設計上の注意が必要です。

機能	Default	HNS	NFS	SFTP	実務上の注意
Blob versioning	✅	未サポート	未サポート	未サポート	バージョン管理前提の復旧設計は、HNS/NFS/SFTP有効アカウントでは見直す
Change feed	✅	未サポート	未サポート	未サポート	変更検知や監査連携をChange feedに依存しない設計にする
Object replication for block blobs	✅	未サポート	未サポート	未サポート	アカウント間レプリケーション要件がある場合は別アカウント構成を検討する
Point-in-time restore	✅	未サポート	未サポート	未サポート	誤削除・誤更新対策はSoft deleteやバックアップ手段も組み合わせる
Blob index tags	✅	プレビュー	プレビュー	プレビュー	本番の検索・分類基盤に使う場合はプレビュー扱いを前提にリスク評価する
Blob snapshots	✅	プレビュー	プレビュー	プレビュー	スナップショット中心の復旧設計は動作検証を必須にする
Immutable storage	✅	✅	未サポート	未サポート	WORM要件がある場合、NFS/SFTP有効アカウントに集約しない
Customer-provided keys	✅	未サポート	未サポート	未サポート	リクエストごとの暗号化キー利用が必要なら別構成を検討する
Cross-tenant customer-managed keys	✅	✅	未サポート	未サポート	クロステナントKey Vault利用時はNFS/SFTPと相性を確認する
Customer-managed planned failover	✅	✅	未サポート	✅	NFS有効時のDR設計では計画フェールオーバーに注意する

Standard GPv2でよくある失敗は、「Data Lake用途でHNSを有効化したあとに、Blob versioningやChange feedも当然使える」と考えることです。HNSは分析基盤では有効な選択肢ですが、Blobの保護・監査・レプリケーション機能とはトレードオフがあるため、同じアカウントにすべてを詰め込まない判断が必要です。(Microsoft Learn)

Premium block blob accountsで確認すべき機能

Premium block blob accountsは低レイテンシや高トランザクション性能を重視する用途で選ばれますが、Blob機能の対応範囲はStandard GPv2と同じではありません。公式表では、Premium block blob accountsのアクセス層、ライフサイクル管理の階層化、Customer-managed planned/unplanned failover、Point-in-time restoreなどが未サポートになっています。(GitHub)

機能	Premiumでの注意点
Access tiers	Hot/Cool/Cold/Archiveのアクセス層は未サポート
Lifecycle management policies（tiering）	階層化は未サポート。削除ポリシーとは分けて考える
Customer-managed failover	計画/非計画ともに未サポート
Point-in-time restore	Defaultを含め未サポート
Metrics in Azure Monitor	Defaultは✅、HNS/NFS/SFTPではプレビュー
Blob versioning / Change feed / Object replication	Defaultでは使えるものがあるが、HNS/NFS/SFTP有効時は未サポート
Storage Analytics metrics（classic）	全列で未サポート。Azure Monitorへの移行前提で考える

Premium block blob accountを選ぶ場合は、「速いストレージだから後から保護機能や階層化で最適化できる」と考えないほうが安全です。ログ、監査、世代管理、災害復旧、コスト最適化まで含めると、Standard GPv2のほうが運用要件に合うケースもあります。

SFTPとMicrosoft Entra IDの扱いで誤解しやすい点

今回の更新で、SFTPを有効化したストレージアカウントにおけるMicrosoft Entra securityの見え方は改善されています。ただし、SFTPのアクセス方式は通常のBlob REST APIやAzure SDKの認可方式と同じように考えないほうがよいです。

Azure Blob Storage SFTPはHNSを必要とし、従来はローカルユーザーを作成してパスワードまたはSSHキーで接続する設計が中心でした。Microsoft Learnでは、SFTPのMicrosoft Entra IDベースアクセスがパブリックプレビューとして案内されており、利用時はOpenSSH証明書を取得して接続します。証明書は65分間有効で、現時点では証明書取得のサポートはAzure CLIとAzure PowerShellが中心です。(Microsoft Learn)

SFTPで確認すべき実務ポイントは次の通りです。

確認項目	判断基準
SFTPを常時有効にする必要があるか	SFTP有効化には時間単位の課金があるため、常時利用しないなら有効/無効の運用を検討する
HNSを有効化してよいか	HNSは一度有効化するとフラット名前空間へ戻せないため、Blob専用用途なら慎重に判断する
ローカルユーザーで運用するか	取引先ごとのユーザー管理、キー配布、棚卸し、退職・契約終了時の無効化が必要
Entra IDベースSFTPを使うか	プレビュー機能であること、サブスクリプション全体への影響、証明書運用、ABAC制限を確認する
ネットワーク制御は十分か	SFTPはポート22を使うため、ファイアウォール、VNet、Private Endpointなどの設計を確認する

SFTPは「既存のファイル転送業務をAzure Storageに寄せる」には便利ですが、REST APIやSDKとは制約が異なります。とくに外部ベンダー連携では、ローカルユーザーの権限とMicrosoft Entra ID/RBACの権限が混在しやすいため、誰がどの経路で何をできるかを一覧化しておくべきです。(Microsoft Learn)

NFS 3.0を使う場合の影響範囲

NFS 3.0は、Linux系ワークロードからBlob Storageをファイルシステムのように扱いたい場合に有用です。しかし、NFS 3.0を有効化するにはHNSが必要であり、NFS 3.0サポートは既存ストレージアカウントに後から有効化できず、有効化後に無効化することもできないとされています。(Microsoft Learn)

また、公式表ではNFS有効時に未サポートとなるBlob機能が多くあります。代表例は、Blob versioning、Change feed、Object replication、Point-in-time restore、Immutable storage、Customer-provided keys、Cross-tenant customer-managed keys、Customer-managed planned failoverです。さらに、NFS 3.0クライアントからのリクエストはMicrosoft Entra securityで認可できないという注釈も残っています。(GitHub)

NFSを選ぶべきか迷ったら、次の基準で判断すると失敗しにくくなります。

要件	NFS採用の向き・不向き
Linuxアプリからマウントして大量データを扱いたい	向いている
既存のPOSIX風アクセスやファイルパス前提の処理を維持したい	向いている
Blob versioningやPoint-in-time restoreを重視する	不向き
Entra IDでリクエスト単位の認可を統一したい	不向き
DRで計画フェールオーバーを重視する	注意が必要
後から設定を戻せる柔軟性が必要	不向き

NFSは「一時的に試して、だめなら無効化する」という扱いに向きません。検証環境で機能互換性、マウント方式、権限、監視、バックアップ、DRを確認してから本番アカウントを作成するのが安全です。

管理者が最初に確認すべき設定

管理者は、まずストレージアカウントごとに「種類」と「有効化済み設定」を棚卸しします。公式ドキュメントで確認対象になっているのは、アカウント種別とHNS/NFS/SFTPの有効状態です。ARM/Bicepのストレージアカウント定義にも、isHnsEnabled、isNfsV3Enabled、isSftpEnabledなどのプロパティがあります。(Microsoft Learn)

Azure CLIとAzure Resource Graphを使う場合は、次のようなクエリで横断確認できます。

az graph query -q "
Resources
| where type =~ 'microsoft.storage/storageaccounts'
| project
    subscriptionId,
    resourceGroup,
    name,
    location,
    kind,
    sku=tostring(sku.name),
    hns=tostring(properties.isHnsEnabled),
    nfs=tostring(properties.isNfsV3Enabled),
    sftp=tostring(properties.isSftpEnabled),
    localUsers=tostring(properties.isLocalUserEnabled),
    allowSharedKey=tostring(properties.allowSharedKeyAccess),
    publicNetworkAccess=tostring(properties.publicNetworkAccess)
| order by subscriptionId, resourceGroup, name
"

確認後は、次の3分類に分けると対応の優先順位を付けやすくなります。

分類	条件例	対応
要注意	HNS/NFS/SFTPが有効で、Versioning、Change feed、Object replication、PITRを使いたい	代替設計または別アカウント分離を検討
設計確認	SFTP有効で、Entra IDベースアクセスや外部連携を計画している	プレビュー条件、証明書運用、ローカルユーザー管理を確認
低リスク	Default構成で、Soft deleteやAzure Monitor中心の運用	公式表の変更を定期確認しつつ現状維持

棚卸しの時点で「ストレージアカウント名」「用途」「所有チーム」「使用中のBlob機能」「アクセス経路」「復旧要件」を一緒に記録しておくと、後の移行判断が速くなります。単に設定値だけを集めても、実際にどのアプリが何に依存しているかが分からなければ、リスクは判断できません。

開発者が確認すべき実装上のポイント

開発者は、ストレージアカウントの設定だけでなく、アプリケーションがどのAPI・プロトコル・認可方式を使っているかを確認する必要があります。Microsoft Entra IDを使ったBlobデータアクセスでは、セキュリティプリンシパルの認証後にOAuth 2.0トークンを取得し、Azure RBACのロールでBlobリソースへの権限を付与します。(Microsoft Learn)

確認すべき観点は次の通りです。

観点	確認する内容
SDK/REST API	Azure Identity、Managed Identity、Service Principal、SAS、Shared Keyのどれを使っているか
SFTP	ローカルユーザーか、Entra IDベースSFTPプレビューか
NFS	Entra IDではなくNFS側の制約でアクセスしている処理がないか
変更検知	Change feedやEvent Gridに依存しているか
復旧	Blob versioning、Soft delete、PITR、スナップショットのどれを前提にしているか
レプリケーション	Object replicationを使っているか、または別のバックアップ/DRで代替しているか

特に注意したいのは、RBACの権限付与直後に動作確認して失敗し、「設定が間違っている」と判断してしまうケースです。Azureロール割り当ては反映に時間がかかる場合があり、公式ドキュメントでは最大30分かかる可能性が示されています。(Microsoft Learn)

また、OwnerやContributorなどの管理ロールを持っていても、BlobデータへのMicrosoft Entra IDアクセス権限が自動的に付与されるわけではありません。Blobデータにアクセスするには、Storage Blob Data Reader、Storage Blob Data Contributor、Storage Blob Data Ownerなど、データアクセス用のロールを適切なスコープで割り当てる必要があります。(Microsoft Learn)

移行・展開で失敗しやすいポイント

HNSは後戻りしにくい設定として扱う

HNSはAzure Data Lake Storage Gen2やSFTP/NFSの前提になる重要な設定ですが、一度有効化するとフラット名前空間に戻せません。バックアップ、画像保管、単純なオブジェクトストレージ用途など、HNSのメリットが小さいワークロードでは、Blob機能の制約を受けてまで有効化する価値があるかを事前に確認しましょう。(Microsoft Learn)

NFSは検証用アカウントで先に試す

NFS 3.0は既存アカウントへの後付けや有効化後の無効化ができないため、本番アカウントで直接試すべきではありません。検証用の新規アカウントを作り、マウント、権限、アプリケーションの読み書き、監視、障害時の復旧まで確認してから本番展開します。(Microsoft Learn)

SFTPは「有効化コスト」と「認証方式」を分けて考える

SFTPは有効化している時間に応じたコストが発生するため、常時使わない連携であれば、必要な時間帯だけ有効化する運用も検討できます。また、SFTPはポート22を使い、ネットワーク制御の影響を受けるため、ファイアウォール、VNet、Private Endpointの設定も合わせて確認が必要です。(Microsoft Learn)

Premium block blobに階層化やPITRを期待しない

Premium block blob accountは性能面の選択肢であり、Standard GPv2の全機能を上位互換で使えるわけではありません。アクセス層、ライフサイクル階層化、Point-in-time restore、Customer-managed failoverが必要な場合は、Premium採用前に公式表で未サポート項目を確認しましょう。(GitHub)

プレビュー機能を本番要件の中核に置く場合は承認プロセスを用意する

Blob index tags、Blob snapshots、Custom domains、SFTPのEntra IDベースアクセスなど、条件によってプレビュー扱いになる機能があります。プレビュー機能を本番で使う場合は、障害時の代替手段、サポート条件、運用手順、将来の仕様変更への追随方法を設計書に残しておくべきです。(GitHub)

新規構築時のおすすめ判断基準

新規にAzure Storageアカウントを作る場合は、「使いたいプロトコル」からではなく、「守りたいデータ運用要件」から逆算するのが安全です。

要件	おすすめの考え方
Blob versioning、Change feed、Object replication、PITRを重視	HNS/NFS/SFTPを有効化しないアカウントを基本にする
Data Lake分析、ディレクトリ操作、Spark/Databricks連携を重視	HNS有効アカウントを検討し、未サポートBlob機能を代替設計する
外部とのSFTP連携を重視	SFTP専用または連携専用アカウントを用意し、他用途と混在させない
LinuxワークロードからNFSマウントしたい	NFS専用アカウントとして設計し、後戻りできない前提で作る
低レイテンシが最優先	Premium block blob accountを検討し、階層化やDR機能の制約を確認する
コスト最適化と長期保管を重視	Standard GPv2でアクセス層とライフサイクル管理を活用する

実務では、1つのストレージアカウントにすべての要件を詰め込むより、用途ごとに分けたほうが安全です。たとえば、SFTP連携用、分析用HNSアカウント、監査・長期保管用のStandard GPv2アカウントを分けると、機能制約や権限管理の衝突を避けやすくなります。

既存環境で今すぐやるべきチェックリスト

既存のAzure Storage環境では、次の順序で確認すると手戻りを減らせます。

手順	作業	目的
1	ストレージアカウントを棚卸しする	kind、sku、HNS、NFS、SFTP、ネットワーク設定を把握する
2	使用中のBlob機能を確認する	Versioning、Change feed、Object replication、PITR、Soft delete、Lifecycle managementの有無を確認する
3	アクセス経路を分類する	REST/SDK、Portal、AzCopy、SFTP、NFS、Data Lake Storage APIを分ける
4	認証・認可方式を確認する	Entra ID、Managed Identity、SAS、Shared Key、SFTPローカルユーザーを整理する
5	公式表と照合する	未サポートまたはプレビューの組み合わせを洗い出す
6	影響の大きいものから対応する	本番データ保護、外部連携、DR、監査ログを優先する
7	IaCと運用手順を更新する	Bicep/Terraform/ARM、設計書、監視、復旧手順に反映する

棚卸し後は、次のような結論に落とし込むと実行しやすくなります。

判定	対応例
そのまま利用可能	現在の設定と利用機能に矛盾がない。定期レビューだけ行う
設計変更が必要	HNS/NFS/SFTPと未サポート機能が衝突している。別アカウントへ分離する
移行が必要	既存アカウントの設定では要件を満たせない。新規アカウントを作成してデータ移行する
検証が必要	プレビュー機能やSFTP Entra IDベースアクセスを使う。検証環境で接続・権限・運用を確認する

まとめ：次に取るべき行動

Blob Storage feature support in Azure storage accountsの2026年5月更新では、SFTP有効時のMicrosoft Entra securityの扱いが見直された点が大きなポイントです。ただし、Azure Storage全体で見ると、HNS、NFS、SFTPを有効化したアカウントでは、Blob versioning、Change feed、Object replication、Point-in-time restoreなどに未サポートの組み合わせが残っています。(GitHub)

まずは全ストレージアカウントを棚卸しし、Standard GPv2かPremium block blobか、HNS/NFS/SFTPが有効か、どのBlob機能に依存しているかを一覧化してください。そのうえで、SFTP連携、Data Lake分析、NFSマウント、世代管理、復旧、レプリケーションを同じアカウントにまとめてよいかを判断します。

新規構築では「あとから変更できるだろう」と考えず、HNSやNFSのように戻しにくい設定を最初に見極めることが重要です。既存環境では、未サポート機能に依存しているアカウントを優先的に洗い出し、必要に応じて用途別アカウントへの分離、認証方式の見直し、運用手順の更新を進めましょう。

この記事を書いた人

佐藤健司

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