Azure Filesの「Microsoft.FileShares」は、Azure Storageにおけるファイル共有の管理単位を大きく変える更新です。結論から言うと、NFS 4.1のSSDファイル共有を新規に作る場合は、ストレージアカウント中心ではなく、ファイル共有を独立したAzureリソースとして管理できる選択肢が一般提供になりました。
一方で、すべてのAzure Files環境をすぐ置き換えるものではありません。SMB、HDD、Azure File Sync、カスタマー管理キー、AKS CSIドライバーなどが要件に入る場合は、従来のクラシックファイル共有を使う判断が必要です。この記事では、2026年6月3日付のAzure Updatesで案内された「Generally Available: File share centric management model (Microsoft.FileShares) for Azure Files」について、変更点、影響範囲、管理者・開発者が確認すべき設定や移行時の注意点を整理します。(Microsoft Azure)
Azure FilesのMicrosoft.FileSharesとは
Microsoft.FileSharesは、Azure Filesのファイル共有をストレージアカウント配下の子リソースではなく、独立したトップレベルのAzureリソースとして扱う管理モデルです。
従来のAzure Filesでは、まずストレージアカウントを作成し、その中にファイル共有を作成するのが基本でした。これに対してMicrosoft.FileSharesでは、ファイル共有をリソースグループへ直接デプロイできます。Microsoft Learnでも、Microsoft.FileSharesはストレージアカウントの必要性をなくし、ファイル共有を最上位レベルのリソースとして扱うモデルだと説明されています。(Microsoft Learn)
今回の一般提供で重要なのは、単に作成画面が変わったことではありません。性能、ネットワーク、セキュリティ、課金をファイル共有単位で分離しやすくなった点が実務上の大きな変化です。
たとえば、部門Aと部門Bで別々のNFS共有を使う場合、従来は同じストレージアカウントにまとめるか、分離のためにストレージアカウントを分けるかを考える必要がありました。Microsoft.FileSharesでは、ファイル共有そのものを管理単位にできるため、共有ごとのタグ付け、課金追跡、ネットワーク境界の設計がしやすくなります。
何が変わったのか
Microsoft.FileSharesの一般提供で変わるポイントは、主に次の5つです。
| 変更点 | 従来のクラシックファイル共有 | Microsoft.FileShares | 実務での意味 |
|---|---|---|---|
| 管理単位 | ストレージアカウント中心 | ファイル共有中心 | 共有ごとに独立したリソースとして扱いやすい |
| デプロイ方法 | ストレージアカウント配下に作成 | リソースグループへ直接作成 | IaCやCI/CDで共有単位の管理がしやすい |
| 性能設計 | ストレージアカウント内の共有全体を考慮 | 共有ごとにストレージ、IOPS、スループットを指定 | ワークロード単位で性能を見積もりやすい |
| ネットワーク・セキュリティ | 多くの設定がストレージアカウント単位 | 共有単位でネットワーク・セキュリティ設定 | チームやアプリごとに境界を分けやすい |
| コスト管理 | アカウント配下の利用状況を整理する必要あり | 共有ごとの課金追跡とタグ管理がしやすい | 部門別・顧客別のコスト配賦に向く |
Microsoftの新機能ページでは、この新しい管理エクスペリエンスにより、各ファイル共有が専用のパフォーマンス、セキュリティ、ネットワーク、課金を持ち、分離性や予測可能なパフォーマンス、詳細なコスト追跡につながると説明されています。また、リージョンごとにサブスクリプションあたり最大10,000個の共有をサポートし、ARMテンプレート、Bicep、CI/CDワークフローによる自動化にも触れられています。(Microsoft Learn)
対象はNFS 4.1のSSDファイル共有。SMBやHDDは対象外
今回の更新で最も誤解しやすいのは、Azure Files全体がMicrosoft.FileSharesへ完全移行するわけではないという点です。
Microsoft.FileSharesの現時点の主な対象は、SSDストレージ上のNFSファイル共有です。Microsoft Learnの作成手順でも、Microsoft.FileSharesはSSD、NFS、プロビジョニング済みv2課金モデル、LRS/ZRSに限定されることが明記されています。SMBプロトコルや標準HDDが必要な場合は、クラシックファイル共有を使う必要があります。(Microsoft Learn)
| 要件 | Microsoft.FileSharesでの扱い | 判断 |
|---|---|---|
| NFS 4.1 | 対応 | 新規構築では検討候補 |
| SSD/Premium相当の低レイテンシ | 対応 | 高性能NFS用途に向く |
| SMB | 非対応 | クラシックファイル共有を選ぶ |
| HDD/Standard | 非対応 | クラシックファイル共有を選ぶ |
| LRS/ZRS | 対応 | 要件に応じて選択 |
| GRS/GZRS | 非対応 | 地理冗長が必須ならクラシックを検討 |
| Azure File Sync | 非対応 | SMBキャッシュ用途ではクラシックを選ぶ |
| カスタマー管理キー | 非対応 | CMK必須ならクラシックを検討 |
| スナップショット | 対応 | ただしバックアップ設計は別途必要 |
| 論理削除 | 非対応 | 削除保護の設計に注意 |
公式の比較表でも、Microsoft.FileSharesはSMB、Azure File Sync、HDD、GRS/GZRS、AKS CSIドライバー、データプレーンREST API、論理削除、カスタマー管理キーなどが未対応として整理されています。また、クラシックファイル共有からMicrosoft.FileSharesへの自動移行は現時点でサポートされていません。(Microsoft Learn)
管理者への影響：ストレージアカウント単位の設計を見直す必要がある
管理者が最初に確認すべきなのは、既存のAzure Files設計が「ストレージアカウントを境界」として組まれているかどうかです。
クラシックファイル共有では、ネットワークやセキュリティの多くがストレージアカウント単位で適用されます。複数の共有を同じストレージアカウントに入れる場合、同じセキュリティ設定で問題ないか、容量やIOPSのボトルネックが起きないかを考える必要がありました。Microsoft.FileSharesでは、共有単位で容量、性能、ネットワーク、セキュリティを設計しやすくなります。(Microsoft Learn)
確認すべき管理項目
| 確認項目 | 見るべきポイント | 注意点 |
|---|---|---|
| 利用プロトコル | NFSかSMBか | SMBはMicrosoft.FileShares対象外 |
| 冗長性 | LRS/ZRSで足りるか | GRS/GZRSが必要ならクラシックを検討 |
| リージョン | 利用予定リージョンで作成できるか | 提供リージョンは更新される可能性があるため、展開前に最新ドキュメントを確認 |
| ネットワーク | 共有単位のPrivate EndpointやService Endpointを設計するか | ストレージアカウント単位の前提で作った運用手順は見直しが必要 |
| コスト配賦 | 共有ごとのタグ、プロジェクト、部門、顧客単位で管理するか | プロビジョニング量に応じて課金されるため過剰割り当てに注意 |
| 削除保護 | スナップショット、バックアップ、運用承認をどうするか | 論理削除が必要な場合は機能差を確認 |
Microsoft.FileSharesの提供リージョンには東日本と西日本も含まれていますが、クラウドサービスの提供状況は変わる可能性があります。展開前には、必ず公式ドキュメントのリージョン一覧を確認してください。(Microsoft Learn)
開発者・IaC担当者への影響：リソース種別とデプロイ手順が変わる
開発者やIaC担当者にとって重要なのは、デプロイ対象が従来のMicrosoft.Storage配下のファイル共有ではなく、Microsoft.FileShares/fileSharesというリソースとして扱われる点です。
Azure CLIではfileshares拡張機能を追加して、az fileshare createで作成します。公式ドキュメントでは、プロビジョニング済み容量、NFSプロトコル、冗長性を指定して作成する例が示されています。IOPSやスループットを指定しない場合は、推奨プロビジョニングが使われます。(Microsoft Learn)
az extension add --name fileshares
az fileshare create \
--name prod-nfs-share01 \
--resource-group rg-storage-prod \
--location japaneast \
--provisioned-storage-GiB 1024 \
--protocol NFS \
--redundancy Localこの変更により、BicepやARMテンプレート、CI/CDパイプラインでは、既存のストレージアカウント作成テンプレートを流用するだけでは不十分になる可能性があります。特に、以下のようなスクリプトは見直し対象です。
- ストレージアカウント名からファイル共有のエンドポイントを組み立てているスクリプト
Microsoft.Storage/storageAccounts配下の共有を前提にしたBicep/ARMテンプレート- ストレージアカウント単位でPrivate Endpointを作成する自動化
- ストレージアカウント単位のタグやコスト配賦を前提にしたFinOpsレポート
- 既存のSMB共有と同じ方式でNFS共有を作ろうとするデプロイ手順
ネットワーク設計の注意点：Private Endpointはファイル共有単位になる
Microsoft.FileSharesでは、ネットワーク設計も変わります。クラシックファイル共有では、パブリックエンドポイントやプライベートエンドポイントはストレージアカウントに存在します。一方、Microsoft.FileSharesで作成されたファイル共有では、これらのエンドポイントがファイル共有レベルで作成されます。(Microsoft Learn)
Private Endpointを作成する場合、リソースの種類はMicrosoft.FileShares/fileShares、ターゲットサブリソースはFileShareです。DNSレコード名もストレージアカウント名ではなく、ファイル共有に割り当てられるホスト名プレフィックスを使います。(Microsoft Learn)
ネットワークで失敗しやすいポイント
| 失敗しやすい点 | 起きる問題 | 対策 |
|---|---|---|
| ストレージアカウントのPrivate Endpointと同じ感覚で作る | 接続先リソースやサブリソースを誤る | Microsoft.FileShares/fileSharesとFileShareを指定する |
| DNSをストレージアカウント名で設計する | 名前解決やマウントに失敗する | ファイル共有のhostNameを確認してDNS検証する |
| 共有ごとにPrivate Endpointが増えることを見落とす | ネットワーク運用やコストが複雑になる | 命名規則、サブネット設計、DNS運用を事前に決める |
| パブリックアクセス制御をストレージアカウント側だけで考える | 意図しない公開・遮断が起きる | 共有単位のパブリックネットワークアクセス設定を確認する |
セキュリティを重視する環境では、作成時または作成後にPrivate Endpointを構成し、Private DNS統合を有効にしたうえで名前解決を検証する流れが現実的です。公式手順でも、Private Endpoint構成時にはターゲットサブリソースFileShareを選び、Private DNS Integrationを有効にする手順が示されています。(Microsoft Learn)
性能と課金の注意点：プロビジョニング済みv2を理解してから作成する
Microsoft.FileSharesでは、プロビジョニング済みv2課金モデルのみが使われます。これは、必要なストレージ容量、IOPS、スループットを指定し、プロビジョニングした量に応じて課金されるモデルです。(Microsoft Learn)
実務では、ここを曖昧にしたまま作成すると、次のような問題が起きます。
- 実データ量だけを見て容量を小さくしすぎ、すぐ拡張が必要になる
- 将来のピークI/Oを見込まず、アプリ側でレイテンシが悪化する
- 逆に大きくプロビジョニングしすぎ、使っていない性能分のコストが増える
- 複数共有を作ったあと、どの共有がどのコストを生んでいるか整理できない
Microsoft.FileSharesでは、ファイル共有ごとに課金を追跡でき、タグを使ってプロジェクト、部門、顧客単位でコストを整理できます。これはFinOpsの観点では大きな利点です。ただし、利点を活かすには、作成時点でタグの命名規則を決めておく必要があります。(Microsoft Learn)
作成前に決めておきたい性能値
| 項目 | 決め方の例 | 確認ポイント |
|---|---|---|
| プロビジョニング容量 | 現在の使用量＋6〜12か月の増加見込み | 最小32GiB、最大262,144GiBの範囲で設計 |
| IOPS | アプリのピーク時の読み書き回数から見積もる | 推奨値を使うか、手動指定するかを決める |
| スループット | 大容量ファイル転送やバッチ処理の転送量から見積もる | MiB/秒単位で必要値を整理 |
| 冗長性 | 可用性要件とコストのバランスで選択 | Microsoft.FileSharesではLRS/ZRSのみ |
| タグ | 部門、環境、システム名、課金先など | 作成後に後付けするより、最初から統一する |
作成・展開時の実務チェックリスト
Microsoft.FileSharesで新しいAzure Files共有を作成する場合は、いきなり本番ワークロードを移すのではなく、次の順番で確認するのがおすすめです。
| 手順 | 実施内容 | 確認すること |
| -: | ———— | —————————————————– |
| 1 | 要件確認 | NFS 4.1、SSD、LRS/ZRSで要件を満たすか |
| 2 | 機能差の確認 | SMB、Azure File Sync、CMK、論理削除などが不要か |
| 3 | リージョン確認 | 利用リージョンでMicrosoft.FileSharesが作成可能か |
| 4 | リソースプロバイダー登録 | Microsoft.FileSharesとMicrosoft.Storageが登録済みか |
| 5 | ネットワーク設計 | Public access、Service Endpoint、Private Endpointをどう使うか |
| 6 | DNS設計 | ファイル共有のhostNameを前提に名前解決できるか |
| 7 | 性能設計 | 容量、IOPS、スループットを推奨値にするか手動指定するか |
| 8 | IaC更新 | Bicep、ARM、CLI、PowerShellのリソース種別を修正する |
| 9 | 運用設計 | スナップショット、バックアップ、監視、タグ、削除承認を決める |
| 10 | 検証 | 非本番でマウント、読み書き、フェイル時の挙動、コスト見積もりを確認する |
作成前提として、サブスクリプションにMicrosoft.FileSharesとMicrosoft.Storageの両方のリソースプロバイダー登録が必要です。Azureポータルでは、サブスクリプションの「リソースプロバイダー」から登録状態を確認できます。(Microsoft Learn)
既存環境からの移行で注意すべきこと
既存のAzure Files環境を使っている場合、今回の更新を「すぐ移行すべき」と捉える必要はありません。公式ドキュメントでも、クラシックファイル共有の非推奨化は残りの機能ギャップが閉じるまで開始されず、クラシックファイル共有からMicrosoft.FileSharesへの自動移行は現時点でサポートされていないとされています。(Microsoft Learn)
つまり、既存環境では次のように判断するのが現実的です。
| 現在の利用状況 | 判断 |
|---|---|
| SMB共有を利用中 | 原則としてクラシックファイル共有を継続 |
| Azure File Syncを利用中 | クラシックファイル共有を継続 |
| HDD/Standardでコスト重視 | クラシックファイル共有を継続 |
| NFS 4.1の新規ワークロード | Microsoft.FileSharesを検証する価値が高い |
| 複数チーム・複数顧客向けにNFS共有を大量管理 | Microsoft.FileSharesの分離性と課金追跡を検討 |
| CMKや論理削除が必須 | 機能差を確認し、クラシック継続を検討 |
移行を検討する場合は、単純な「設定変更」ではなく、新しい共有を作成してデータを移し、マウント先やDNS、運用手順を切り替えるプロジェクトとして扱うべきです。特にNFSクライアント側のマウント設定、アプリケーションのパス、Private Endpointの名前解決、バックアップ・復旧手順は必ず検証してください。
運用時の注意点：スケール変更、スナップショット、削除
Microsoft.FileSharesでは、作成後に容量、IOPS、スループットを変更できます。ニーズに応じてスケールアップ・スケールダウンできますが、プロビジョニング済み容量を減らせるのは、最後に容量を増やしてから24時間経過した後です。変更は通常、プロビジョニング変更後数分以内に有効になると説明されています。(Microsoft Learn)
スナップショットについては、Microsoft.FileSharesで作成されたNFSファイル共有でもAzureポータル、PowerShell、Azure CLIから作成できます。誤削除や更新ミスへの備えとして有効ですが、スナップショットだけでバックアップ要件を満たせるとは限りません。保持期間、別リージョン保管、ランサムウェア対策、復旧手順まで含めて設計することが重要です。(Microsoft Learn)
削除時にも注意が必要です。Microsoft.FileSharesで作成したファイル共有を削除する前に、関連付けられたPrivate Endpointを削除または切断しておく必要があります。Private Endpointが残っていると、ファイル共有の削除は失敗します。また、削除時にスナップショットなどの依存リソースも削除され、復旧できない場合があるため、本番環境では削除承認フローを設けるべきです。(Microsoft Learn)
採用すべきケース、まだ待つべきケース
Microsoft.FileSharesは、Azure FilesのNFS利用をよりクラウドネイティブに管理したい組織に向いています。ただし、機能差が残っているため、要件に合う場合だけ採用するのが安全です。
採用を検討しやすいケース
- NFS 4.1のSSDファイル共有を新規に作る
- 部門、顧客、アプリごとにファイル共有を分離したい
- 共有ごとに性能、ネットワーク、課金を明確に分けたい
- Bicep、ARM、CI/CDでファイル共有単位の自動化を進めたい
- ストレージアカウント単位の容量・性能設計が複雑になっている
- NFS共有を多数管理しており、命名、タグ、コスト配賦を整理したい
まだクラシックを選ぶべきケース
- SMBが必要
- Azure File Syncを使う
- HDD/Standardでコスト最適化したい
- GRS/GZRSが必要
- カスタマー管理キーが必須
- 論理削除が必須
- AKS CSIドライバー連携が前提
- 既存の運用・監視・バックアップがストレージアカウント前提で固まっている
判断に迷う場合は、既存環境をすぐ移行するのではなく、新規のNFS検証環境でMicrosoft.FileSharesを試し、ネットワーク、DNS、性能、課金、バックアップまで一通り確認するのが現実的です。
今回の更新で管理者が次にやるべきこと
今回のAzure Storage更新は、Azure FilesのNFS共有をより細かく、独立して管理したい組織にとって大きな前進です。特に、複数チームや複数ワークロードでNFS共有を使う場合、ファイル共有ごとの性能、ネットワーク、セキュリティ、課金を分けられるメリットがあります。
ただし、Microsoft.FileSharesは万能な置き換えではありません。SMB、HDD、Azure File Sync、CMK、論理削除などが必要な環境では、引き続きクラシックファイル共有が適切です。
まずは、次の3点を確認してください。
- 既存・新規のAzure Files要件を、NFS/SMB、SSD/HDD、冗長性、バックアップ要件で分類する
- 新規NFS 4.1 SSD共有について、Microsoft.FileSharesを検証候補に入れる
- IaC、Private Endpoint、DNS、タグ、コスト配賦、削除手順をファイル共有単位で見直す
Microsoft.FileSharesを採用するかどうかは、「新しいから使う」ではなく、ファイル共有単位で分離したい理由があるかで判断するのが失敗しにくい進め方です。
コメント