Azure StorageでAzure Filesを設計・運用している場合、2026年5月20日に更新された「Azure Files scalability and performance targets」で最初に確認すべき点は、Azure Filesのスケール上限が Microsoft.Storage の classic file share と Microsoft.FileShares の file share に分けて整理されていることです。SMBが必要なら従来のclassic file share、NFS中心でSSD・provisioned v2前提ならMicrosoft.FileSharesも候補になります。単に最大容量やIOPSの表を見るだけでなく、「どのリソースモデルで作るか」「ストレージアカウント単位で上限を共有していないか」「プロビジョニング値と実測値が合っているか」を確認することが重要です。Microsoft Learnの対象ページは2026年5月20日に更新され、GitHub上の差分でもms.dateの更新と本文表現・構成の整理が確認できます。(Microsoft Learn)
Azure Files scalability and performance targetsの要点
Azure Files scalability and performance targetsは、Azure Filesで利用できるファイル共有の容量、IOPS、スループット、スナップショット数、管理APIのレート制限などをまとめた公式情報です。
今回の情報で特に押さえるべきなのは、Azure Filesの設計単位が大きく2つに分かれる点です。
| リソースモデル | 作成単位 | 主な特徴 | 向いているケース |
|---|---|---|---|
Microsoft.Storage | ストレージアカウント配下のclassic file share | SMBとNFSをサポート。ストレージアカウント内の複数リソースで容量・IOPS・スループット上限を共有する | SMBが必要なWindowsファイル共有、既存構成の継続、複数のAzure Storage機能を同じアカウントで使う構成 |
Microsoft.FileShares | リソースグループ直下のfile share | ストレージアカウントを作らずにファイル共有を直接デプロイできる。NFSのみ対応し、provisioned v2モデルを使用する | NFS中心、SSD、共有ごとの独立した性能設計・コスト管理を重視する構成 |
公式ドキュメントでは、classic file shareはMicrosoft.Storageリソースプロバイダー、file shareはMicrosoft.FileSharesリソースプロバイダーとして説明されています。Microsoft.FileSharesのfile shareはNFSのみをサポートするため、SMBが必要な場合はclassic file shareを選ぶ必要があります。(Microsoft Learn)
2026年5月20日更新で何が変わったのか
2026年5月20日の更新は、「単純に最大IOPSが増えた」といった一点だけを見るより、Azure Filesの設計判断を誤らないための整理として読むべきです。
GitHubの差分では、ページタイトルが「Azure Files Scale and Performance Targets」に整理され、ms.dateが2026年5月20日に更新されています。差分の多くは表記や説明文の改善ですが、実務上は、Microsoft.StorageとMicrosoft.FileSharesを分けて上限を確認する流れがより明確になった点が重要です。(GitHub)
実務で見るべき変更・確認ポイント
| 確認ポイント | 管理者・開発者への影響 |
|---|---|
| classic file shareとfile shareの区別 | 「Azure Filesだから同じ上限」と考えると設計ミスにつながる。リソースプロバイダーとプロトコルを先に確認する |
Microsoft.FileSharesの位置づけ | ストレージアカウント不要で作れるが、NFSのみ。SMBワークロードを移す候補としては使えない |
| provisioned v2の前提 | 新規展開では容量・IOPS・スループットを個別に見積もる必要がある。過剰プロビジョニングはコスト増になる |
| ストレージアカウント共有上限 | classic file shareでは、同じストレージアカウント内の共有やBlob、Queue、Tableと上限を共有する場合がある |
| 管理APIの制限 | IaCや自動化で大量の作成・更新・削除を短時間に実行すると制限に当たる可能性がある |
「今まで動いていたから問題ない」と判断するのは危険です。特に複数のfile shareを1つのストレージアカウントに集約している環境では、個々の共有ではなく、ストレージアカウント全体のIOPSやスループットがボトルネックになることがあります。
まず確認すべき対象者
この更新を確認すべきなのは、Azure Storageの管理者だけではありません。Azure Filesを使うアプリケーション開発者、IaCテンプレートを管理するDevOps担当者、VDIやアプリケーション基盤の運用担当者も対象です。
| 対象者 | 確認すべきこと |
|---|---|
| Azure管理者 | 共有がclassic file shareなのか、Microsoft.FileSharesなのか。ストレージアカウント単位の上限に近づいていないか |
| アプリケーション開発者 | 単一ファイルへの集中アクセス、パス長、メタデータ操作の多さが制限に当たらないか |
| インフラ設計者 | SMB/NFS、SSD/HDD、冗長性、リージョン、provisioned v2の容量・IOPS・スループット設計 |
| DevOps担当者 | ARM/Bicep/Terraformなどで大量の共有を作成・更新する際の管理API制限 |
| 移行担当者 | 既存のSMB共有をMicrosoft.FileSharesへ直接移せると誤解していないか |
classic file shareのスケール目標
classic file shareは、従来どおりストレージアカウント配下に作成するAzure Filesのファイル共有です。SMBを利用する場合は、このモデルを選ぶ必要があります。
classic file shareでは、ファイル共有そのものの上限だけでなく、親であるストレージアカウントの上限も同時に考える必要があります。公式ドキュメントでは、ストレージアカウント配下のすべてのリソースが、そのストレージアカウントに適用される制限を共有すると説明されています。(Microsoft Learn)
ストレージアカウント単位の主な上限
| 項目 | 主な上限 |
|---|---|
| サブスクリプション・リージョンあたりのストレージアカウント数 | 250 |
| ストレージアカウントあたりのclassic file share数 | SSD/HDD provisioned v2は50、SSD provisioned v1は1,024、HDD pay-as-you-goは無制限。ただし多くのケースで50以下が推奨される |
| classic file shareあたりのスナップショット数 | 200 |
| ストレージアカウントあたりの仮想ネットワークルール数 | 200 |
| ストレージアカウントあたりのIPアドレスルール数 | 200 |
| 管理読み取り操作 | 5分あたり800 |
| 管理書き込み操作 | 1秒あたり10、または1時間あたり1,200 |
| 管理一覧操作 | 5分あたり100 |
ストレージアカウント単位の制限は、運用自動化で見落とされやすいポイントです。たとえば、BicepやTerraformで多数の共有、ネットワークルール、スナップショット関連設定を短時間に更新すると、データアクセスではなく管理操作側で制限に当たる可能性があります。
SKU別に見る容量・IOPS・スループットの違い
Azure Filesの性能目標は、SSDかHDDか、provisioned v2かprovisioned v1か、pay-as-you-goかで大きく変わります。主な上限は次のとおりです。(Microsoft Learn)
| 種類 | ストレージアカウント種別 | 最大容量 | 最大IOPS | 最大スループット |
|---|---|---|---|---|
| SSD provisioned v2 | FileStorage | 256 TiB | 102,400 IOPS | 10,340 MiB/s |
| HDD provisioned v2 | FileStorage | 4 PiB | 50,000 IOPS | 5,120 MiB/s |
| SSD provisioned v1 | FileStorage | 100 TiB | 102,400 IOPS | 10,340 MiB/s |
| HDD pay-as-you-go | StorageV2 | 5 PiB | 通常20,000 IOPS、対象リージョンでは40,000 IOPS | 通常は受信3,200 MiB/s・送信6,400 MiB/s、対象リージョンでは受信7,680 MiB/s・送信25,600 MiB/s |
日本語圏の利用者にとっては、HDD pay-as-you-goの増強対象リージョンにJapan Eastが含まれている点も確認しておきたいところです。ただし、リージョンごとの対応状況や提供条件は変わる可能性があるため、展開前に対象リージョンの公式情報を確認してください。(Microsoft Learn)
file share（Microsoft.FileShares）のスケール目標
Microsoft.FileSharesのfile shareは、ストレージアカウントを介さず、リソースグループ直下にファイル共有を作成する新しい管理モデルです。公式ドキュメントでは、Microsoft.FileSharesで作成されたfile shareはprovisioned v2課金モデルを使用し、SSDの値として最大256 TiB、最大102,400 IOPS、最大10,340 MiB/sのスループットが示されています。(Microsoft Learn)
| 項目 | Microsoft.FileSharesの値 |
|---|---|
| プロトコル | NFS |
| 課金モデル | provisioned v2 |
| 最小プロビジョニング容量 | 32 GiB |
| 最小プロビジョニングIOPS | 3,000 IOPS |
| 最小プロビジョニングスループット | 100 MiB/s |
| 最大プロビジョニング容量 | 256 TiB |
| 最大プロビジョニングIOPS | 102,400 IOPS |
| 最大プロビジョニングスループット | 10,340 MiB/s |
| 最大メタデータIOPS | 最大35,000 IOPS |
| フルパス長 | 2,048文字 |
| パス構成要素ごとの最大長 | 255文字 |
Microsoft.FileSharesは、共有ごとに独立して性能とコストを管理しやすい点が魅力です。一方で、SMBに対応していないため、Windowsクライアント中心の共有フォルダー、FSLogixプロファイル、既存SMBアプリケーションの移行先としてはclassic file shareを検討する必要があります。
provisioned v2で注意すべきこと
provisioned v2は、容量、IOPS、スループットを個別にプロビジョニングするモデルです。Microsoftの課金モデル説明では、provisioned v2は新しいAzure Files展開に推奨されるモデルとして説明されています。使用量ではなくプロビジョニングした値に基づいて課金されるため、性能を確保しやすい一方で、見積もりを誤るとコストが膨らみます。(Microsoft Learn)
特に重要なのは次の3点です。
| 項目 | 実務上の注意点 |
|---|---|
| 容量・IOPS・スループットを別々に決める | 「容量を増やせば性能も十分」と考えない。アプリケーションのI/O特性を見て個別に設定する |
| 変更はすぐ反映されるが制約がある | プロビジョニング値の変更は数分で有効になるが、増加後に減少できるのは24時間経過後 |
| ガードレールがある | IOPSとスループットは、プロビジョニング容量に対する推奨値の5倍を上限とするガードレールがある |
たとえば、少容量の共有に極端に高いIOPSだけを割り当てようとしても、ガードレールにより設定できない場合があります。その場合は、必要な性能に合わせて容量側も引き上げる設計が必要です。(Microsoft Learn)
管理者が確認すべき設定
Azure Files scalability and performance targetsを確認したら、管理者はまず既存環境を棚卸ししてください。見るべき順番は、容量よりも「リソースモデル」「プロトコル」「共有上限」です。
リソースモデルとプロトコルを確認する
最初に確認するのは、対象のファイル共有がclassic file shareなのか、Microsoft.FileSharesなのかです。次にSMBかNFSかを確認します。
判断基準はシンプルです。
| 要件 | 選択肢 |
|---|---|
| SMBが必要 | classic file share |
| NFSのみでよい | classic file shareまたはMicrosoft.FileShares |
| ストレージアカウント単位の共有上限を避けたい | Microsoft.FileSharesを検討 |
| Blob、Queue、Tableなどと同じストレージアカウントで管理したい | classic file share |
| 共有ごとにコストを明確に分けたい | Microsoft.FileSharesまたはclassic file shareの分離設計 |
SMBが必要な環境でMicrosoft.FileSharesを前提に設計すると、後から構成を見直すことになります。移行計画の初期段階で必ず確認してください。
ストレージアカウント内の共有数を確認する
classic file shareでは、ストレージアカウントあたりの共有数にも注意が必要です。SSD/HDD provisioned v2では50共有が上限です。SSD provisioned v1は1,024共有、HDD pay-as-you-goは無制限とされていますが、公式情報では50以下の利用が推奨されています。(Microsoft Learn)
共有数だけを見るのではなく、次の観点で確認します。
- 同じストレージアカウントに高負荷な共有が集中していないか
- Blob、Queue、Tableなど他のStorageリソースも同居していないか
- 将来3〜5年で容量やIOPSが伸びる共有を同じアカウントに詰め込みすぎていないか
- 部門別・顧客別のコスト按分が必要なのに、1つのアカウントにまとめていないか
classic file shareでは、複数の共有を同じストレージアカウントに配置すると、ストレージアカウント側の容量・IOPS・スループット上限を共有します。Microsoftの課金モデル説明でも、将来の成長を見込んでストレージアカウントに十分な余裕を持たせることが推奨されています。(Microsoft Learn)
スナップショットとバックアップ設計を確認する
Azure Filesでは、ファイル共有あたりのスナップショット数は200です。バックアップ保持期間を長く設定している場合や、頻繁にスナップショットを取得する運用では、この上限に近づく可能性があります。(Microsoft Learn)
確認すべきポイントは次のとおりです。
- スナップショットの保持期間が業務要件に合っているか
- バックアップポリシーが過剰に細かく設定されていないか
- テスト用・移行用の一時スナップショットが残っていないか
- 復旧要件をAzure Backupなどの周辺サービスと合わせて設計しているか
開発者が確認すべき性能上の注意点
アプリケーション開発者は、共有全体の最大IOPSだけでなく、単一ファイル、メタデータ操作、パス長の制限を確認する必要があります。
単一ファイルにアクセスが集中しないようにする
Azure Filesには、個別ファイル単位のスケール目標があります。classic file shareでは、SSDの個別ファイルは最大8,000 IOPS、最大1,024 MiB/s、HDDの個別ファイルは最大1,000 IOPS、最大60 MiB/sが目標値として示されています。Microsoft.FileSharesのfile shareでは、個別ファイルの最大IOPSは8,000、最大スループットは1,024 MiB/sです。(Microsoft Learn)
つまり、共有全体で102,400 IOPSを確保していても、1つの巨大なログファイルや1つのインデックスファイルにアクセスが集中すると、ファイル単位の制限が先に問題になる可能性があります。
対策としては、次のような設計が有効です。
- ログファイルを日付、アプリケーション、インスタンス単位で分割する
- 一時ファイルやキャッシュを単一ディレクトリに集中させない
- 大量の小ファイルを扱う処理では、ディレクトリ階層と並列度を設計する
- 性能テストでは、共有全体だけでなくホットファイルの有無を確認する
メタデータ操作が多いワークロードに注意する
ファイルを開く、フォルダーを列挙する、属性を確認する、といった操作はメタデータ操作です。公式ドキュメントでは、SSD上のSMB共有はメタデータキャッシュを使うことで最大35,000メタデータIOPSまでスケールできると説明されています。一方、メタデータキャッシュなしのSMBや一部のHDD構成では、上限がより低くなります。(Microsoft Learn)
大量の小ファイルを頻繁に列挙するアプリケーションでは、データ転送量よりもメタデータ操作がボトルネックになることがあります。たとえば、ビルド成果物、画像サムネイル、機械学習の小さなデータファイル、ユーザープロファイルのようなワークロードでは注意が必要です。
パス長の制限を確認する
Azure Filesでは、フルパス長は2,048文字、パス内の個別コンポーネントは255文字までです。(Microsoft Learn)
深いディレクトリ階層を自動生成するアプリケーションでは、オンプレミスでは動いていた命名規則がAzure Filesでは問題になることがあります。特に、ユーザー名、部署名、案件名、日付、GUIDなどを連結してパスを作る処理では、移行前に最大長をテストしてください。
移行時に失敗しやすいポイント
Azure Filesの移行で失敗しやすいのは、容量不足よりも「モデルの選び間違い」と「性能測定の不足」です。
SMB共有をMicrosoft.FileSharesへ直接置き換えようとする
Microsoft.FileSharesはNFSのみをサポートします。SMBが必要なWindowsファイル共有を移行する場合、基本的にはclassic file shareを検討します。(Microsoft Learn)
特に注意が必要なのは、既存のWindowsクライアント、業務アプリ、認証・アクセス制御、ドライブマップ、GPOなどがSMB前提になっているケースです。この場合、NFSへ移すにはアプリケーション側やクライアント側の変更が必要になります。
古いpay-as-you-go共有のクォータを確認しない
HDD pay-as-you-goのAzure file shareは現在100 TiBまで拡張できますが、古いストレージアカウントではlarge file share機能に関連して、ファイル共有クォータの変更が必要になる場合があります。(Microsoft Learn)
既存環境を拡張する場合は、次を確認してください。
- 現在の共有クォータ
- 実使用量ではなく設定上の上限
- large file share機能導入前から存在する古いアカウントか
- 100 TiBまで拡張する運用・バックアップ・復旧計画があるか
RA-GRSやRA-GZRSの読み取りアクセスを期待する
classic file shareはStandard_RAGRSやStandard_RAGZRSのストレージアカウントにデプロイできますが、Azure Filesはgeo冗長ストレージアカウントのread-accessibility modeをサポートしません。公式ドキュメントでは、Azure Filesのclassic file shareは暗黙的にStandard_GRSまたはStandard_GZRSを使用すると説明されています。(Microsoft Learn)
災害対策設計で「セカンダリリージョンから読み取れるはず」と考えている場合は、アーキテクチャを見直してください。
展開前のチェックリスト
Azure Filesを新規展開または移行する前に、次の順番で確認すると判断しやすくなります。
| 手順 | 確認内容 | 判断基準 |
| -: | ————– | ——————————————————— |
| 1 | プロトコル | SMBが必要ならclassic file share。NFSならMicrosoft.FileSharesも候補 |
| 2 | メディア層 | 高IOPS、低レイテンシ、大量の並列処理が必要ならSSDを優先 |
| 3 | 課金モデル | 新規展開ではprovisioned v2を基本候補にし、使用量・性能要件・コストを比較 |
| 4 | 容量・IOPS・スループット | 平均値ではなくピーク値、I/Oサイズ、並列度を見て決める |
| 5 | ストレージアカウント共有上限 | classic file shareでは同じアカウント内の他リソースも含めて確認 |
| 6 | リージョン | 必要なメディア層、冗長性、上限、機能が対象リージョンで使えるか確認 |
| 7 | 管理API制限 | IaC、自動作成、スナップショット運用で短時間に大量操作しないよう調整 |
| 8 | 性能テスト | 数分のテストで判断せず、実運用に近い頻度・時間・並列度で測定 |
Microsoftの性能ガイドでは、短時間・低頻度のテストでは実際の性能を誤解しやすく、十分な頻度と期間でテストすることが推奨されています。また、IOPS、I/Oサイズ、スループット、レイテンシ、キュー深度を分けて理解することが重要です。(Microsoft Learn)
性能問題が起きたときの切り分け
Azure Filesで「遅い」と感じた場合、すぐにAzure Filesの上限不足と決めつけないことが大切です。性能ガイドでは、エンドツーエンドレイテンシとサービスレイテンシを分けて確認する考え方が示されています。SuccessE2ELatencyはクライアントからAzure Filesまでの往復全体、SuccessServerLatencyはAzure Filesサービス内の処理時間を示します。(Microsoft Learn)
| 症状 | 見るべき指標 | 考えられる原因 |
|---|---|---|
SuccessServerLatencyは低いがSuccessE2ELatencyが高い | ネットワーク、クライアント、ルーティング | VPN、ExpressRoute、オンプレミス側回線、クライアント負荷 |
| IOPSがプロビジョニング値に近い | IOPS使用率、スロットリング | IOPS不足、単一ファイル集中、メタデータ操作過多 |
| スループットが伸びない | I/Oサイズ、並列度、キュー深度 | 小さいI/Oが多い、並列処理不足、クライアント側制約 |
| 一部の処理だけ遅い | ファイル単位のアクセス状況 | ホットファイル、単一ディレクトリ集中、パス列挙の多発 |
オンプレミスからAzure Filesにアクセスしている場合、ネットワーク距離や回線設計の影響も大きくなります。性能確認では、同じAzureリージョン内のVMからアクセスした場合と、オンプレミスからアクセスした場合を比較すると、サービス側とネットワーク側の問題を分けやすくなります。
管理者・開発者が次に取るべき行動
Azure Files scalability and performance targetsを確認したら、次の3つを実施してください。
まず、既存のAzure Filesを棚卸しし、classic file shareかMicrosoft.FileSharesか、SMBかNFSか、SSDかHDDか、provisioned v2かどうかを一覧化します。
次に、ストレージアカウント単位の上限を確認します。classic file shareを使っている場合、共有単体の余裕だけでなく、同じストレージアカウント内の全リソースが容量・IOPS・スループットを奪い合っていないかを見る必要があります。
最後に、移行や新規展開では、実ワークロードに近い性能テストを行います。平均IOPSだけで判断せず、ピーク時のI/Oサイズ、並列度、メタデータ操作、単一ファイルへの集中、エンドツーエンドレイテンシまで確認してください。
今回の更新は、Azure Filesの上限表を読むだけでなく、リソースモデルの選び方を見直すきっかけになります。SMBが必要ならclassic file share、NFS中心で共有ごとの独立性を重視するならMicrosoft.FileShares、複数共有をまとめるならストレージアカウント上限の余裕を必ず確認する。この順番で判断すれば、移行後のスロットリングやコスト超過を避けやすくなります。
コメント