Azure StorageでAzure Filesの「Create a classic file share – Azure Files」を確認している場合、最初に押さえるべき結論はシンプルです。新規にクラシック ファイル共有を作成するなら、基本的にはProvisioned v2を第一候補にし、Azure portalの手順書や運用チェックリストではAdvancedタブとSecurityタブの設定場所を見直してください。
今回の公式情報は、Azure Filesのクラシック ファイル共有をAzure portal、Azure PowerShell、Azure CLIで作成する方法を整理したものです。対象はMicrosoft.Storageリソースプロバイダーで作成する従来型のAzure file shareであり、プレビューとして扱われるMicrosoft.FileSharesリソースプロバイダーのファイル共有には適用されません。管理者は、課金モデル、ストレージアカウント種別、SKU、SMB/NFS、暗号化、バックアップ、ネットワーク設定を作成前に確認する必要があります。(Microsoft Learn)
Create a classic file share – Azure Filesの更新でまず見るべきポイント
Microsoft Learn上の該当ページは、公式メタデータでms.date: 05/08/2026、ページ末尾でも「Last updated on 2026-05-08」と示されています。2026年5月9日時点でこの情報を確認する場合、実務上の読みどころは「Azure Filesの作成手順が、現在のAzure portalの画面構成に合わせて整理されたこと」です。(GitHub)
特に重要なのは、単なる画面キャプチャ差し替えではなく、ストレージアカウント作成時に確認すべき設定が「Advanced」「Data protection」「Security」「Encryption」などに分かれて説明されている点です。既存の手順書で「AdvancedタブのSecurityセクション」といった古い導線を前提にしている場合、レビュー時に設定漏れが起きやすくなります。GitHubの更新履歴でも、2026年5月8日に「portalの変更に合わせた手順更新」が行われ、Securityタブの項目が追加・整理されています。(GitHub)
| 確認項目 | 変更・整理されたポイント | 管理者が取るべき対応 |
|---|---|---|
| 対象リソース | Microsoft.Storageで作成するクラシック ファイル共有が対象 | Microsoft.FileSharesプレビュー向け手順と混同しない |
| 推奨課金モデル | 新規デプロイではProvisioned v2が推奨 | 新規作成時の既定案としてProvisioned v2を検討する |
| Azure portalの導線 | AdvancedタブとSecurityタブの説明が整理 | 社内手順書、スクリーンショット、レビュー項目を更新する |
| セキュリティ設定 | SMB/NFSの転送時暗号化、Secure transfer、キーアクセスなどを個別に確認 | 既存クライアント、認証方式、運用ポリシーとの整合性を見る |
| NFS利用 | NFSではネットワークレベルの設定が必須 | Private Endpoint、Service Endpoint、ポート2049を事前確認する |
対象者と影響範囲
今回の情報は、Azure Filesを新規に作成する担当者だけでなく、既存の運用手順を保守している管理者にも関係します。特に、Azure portalで作成してからPowerShellやCLIで運用自動化するチームでは、ポータル上の選択項目とスクリプト上のkind、sku、enabled-protocolsが一致しているかを確認してください。
| 対象者 | 影響を受けやすい場面 | 確認すべきこと |
|---|---|---|
| Azure管理者 | 新しいファイル共有をAzure portalで作成する | 課金モデル、冗長性、ソフト削除、バックアップ、暗号化 |
| インフラ運用担当 | 社内手順書や監査チェックリストを更新する | 画面導線、Securityタブ、Data protectionタブの記載 |
| 開発者・DevOps担当 | PowerShell、Azure CLI、IaCで展開する | ストレージアカウント種別とSKUの組み合わせ |
| セキュリティ担当 | SMB/NFS、キーアクセス、TLS、Defenderを確認する | 旧クライアントや共有キー利用の可否 |
| 移行担当 | オンプレミスのファイルサーバーからAzure Filesへ移行する | アクセス層、IOPS、スループット、ネットワーク経路 |
作成前に決めるべき課金モデルとストレージアカウント種別
Azure classic file shareは、ストレージアカウント内に作成します。ここで間違えやすいのは、ファイル共有を作る前に選ぶストレージアカウントのkindとSKUが、後から作れるファイル共有の種類を決めることです。公式情報では、Azure Filesで考慮すべき主な組み合わせとして、Provisioned v2、Provisioned v1、Pay-as-you-goが整理されています。(Microsoft Learn)
| 課金モデル | 主な用途 | ストレージアカウント種別 | 主なSKU例 | 注意点 |
|---|---|---|---|---|
| Provisioned v2 | 新規デプロイの第一候補。容量、IOPS、スループットを個別に設計したい場合 | FileStorage | PremiumV2_LRS、PremiumV2_ZRS、StandardV2_LRSなど | プロビジョニングした容量・性能に基づいて課金される |
| Provisioned v1 | SSDの既存設計や特定要件がある場合 | FileStorage | Premium_LRS、Premium_ZRS | IOPSとスループットは容量に応じて決まる |
| Pay-as-you-go | HDDのSMB共有で、実使用量ベースの課金を選びたい場合 | StorageV2 | Standard_LRS、Standard_ZRS、Standard_GRS、Standard_GZRS | HDDのみ、SMBのみ。アクセス層の選択が重要 |
新規構築ではProvisioned v2が推奨されていますが、すべてのケースで無条件に最適という意味ではありません。たとえば、小規模でアクセス頻度が低いHDDのSMB共有ではPay-as-you-goが検討対象になります。一方、性能要件が明確で、IOPSやスループットを個別に調整したい場合はProvisioned v2の方が設計しやすくなります。(Microsoft Learn)
クラシック ファイル共有とプレビューのFile sharesを混同しない
公式ページの冒頭では、この手順が「Classic SMB and NFS file shares created with the Microsoft.Storage resource provider」に適用される一方、Microsoft.FileSharesリソースプロバイダーで作成するプレビューのFile sharesには適用されないと明記されています。(Microsoft Learn)
実務では、ここを混同すると設計レビューで話がずれます。クラシック ファイル共有はストレージアカウントの中に作成するため、同じストレージアカウント内の複数共有でアカウント単位の上限や課金追跡の影響を受けます。一方、Microsoft.FileSharesのファイル共有はトップレベルリソースとして扱われるため、設計思想が異なります。現時点でこの記事の対象は、あくまでストレージアカウント配下に作るクラシック ファイル共有です。(Microsoft Learn)
Azure portalで作成する場合の実務手順
Azure portalでAzure classic file shareを作成する流れは、大きく分けて「ストレージアカウントの作成」と「ファイル共有の作成」の2段階です。既存のストレージアカウントを使う場合でも、kindとSKUが目的のファイル共有に合っているかを先に確認してください。
ストレージアカウント作成時のBasicsで確認すること
Basicsタブでは、サブスクリプション、リソースグループ、ストレージアカウント名、リージョン、Primary service、Performance、File share billing、Redundancyを確認します。ストレージアカウント名はSMBでマウントする際のサーバー名にも使われ、3〜24文字の小文字英数字で、グローバルに一意である必要があります。(Microsoft Learn)
特にProvisioned v2を選ぶ場合は、Primary serviceでAzure Filesを選ぶことが重要です。公式情報では、この項目自体は任意とされているものの、Provisioned v2 billingを選ぶにはAzure Filesの選択が必要と説明されています。(Microsoft Learn)
AdvancedではAzure Filesに効く設定と効かない設定を分けて見る
Advancedタブには、Hierarchical namespace、SFTP、NFSv3、Blob storage関連の項目が表示されることがあります。しかし、これらの多くはAzure Blob Storage向けの設定であり、Azure Filesには適用されません。Azure Filesで重要なのは、SMBまたはNFSに対する「Require Encryption in Transit」の設定です。(GitHub)
ここで失敗しやすいのは、「NFSv3を有効化したからAzure FilesのNFSが使える」と誤解することです。Azure FilesのNFSはファイル共有側でプロトコルを選ぶ設計であり、Blob向けのNFSv3設定とは別物です。特にNFSv4.1の利用を想定する場合は、ファイル共有作成時のProtocolとネットワーク設定を確認してください。(GitHub)
Securityではキーアクセス、TLS、Defenderを確認する
Securityタブでは、Secure transfer、匿名アクセス、ストレージアカウントキーアクセス、Microsoft Entra認可、最小TLSバージョン、コピー操作の許可範囲、Microsoft Defender for Storageなどを確認します。Azure Filesでは、ストレージアカウントキーが有効な場合、SMBマウントやFileREST APIアクセスに共有キーを使えます。無効化する場合は、既存のマウント方式や自動化スクリプトへの影響を事前に確認してください。(Microsoft Learn)
旧クライアントを利用している環境では、Secure transferの扱いにも注意が必要です。公式情報では、SMB 2.1のように暗号化されていないSMBアクセスが必要なクライアントがある場合、設定を外す必要があるケースに触れています。ただし、これはセキュリティを下げる判断になるため、例外対応としてリスクを記録し、可能であればクライアント更新を優先してください。(Microsoft Learn)
Data protectionではファイル共有のソフト削除を確認する
Data protectionタブでは、Azure Files向けのソフト削除を確認します。ファイル共有のソフト削除は誤削除対策として有効ですが、削除済みとして保持されている容量にも課金が発生するため、保持期間を長くしすぎるとコストに影響します。公式情報では既定の保持期間が7日と説明されています。(Microsoft Learn)
頻繁に検証用の共有を作成・削除する開発環境では、ソフト削除の保持期間が想定外のコストにつながることがあります。本番環境では保護を優先し、開発・検証環境では保持日数と削除運用を明確に分けるのが現実的です。
ファイル共有作成時は課金モデルごとに入力項目が変わる
ストレージアカウントを作成したら、Data storageのFile sharesから「+ File share」を選びます。Provisioned v2では、共有名、プロビジョニング容量、IOPS、スループット、Protocolを指定します。IOPSとスループットは推奨値を使うことも、必要に応じて手動指定することもできます。(Microsoft Learn)
Provisioned v1では、主にプロビジョニング容量とProtocolを指定します。Pay-as-you-goでは、アクセス層としてTransactionOptimized、Hot、Coolを選びます。移行時はトランザクションが増えやすいため、公式情報では、移行中のトランザクション費用を抑える目的でTransaction optimizedを選び、完了後に必要に応じて低い階層へ切り替える考え方が示されています。(Microsoft Learn)
PowerShellとAzure CLIで作成する場合の最小例
PowerShellまたはAzure CLIで作成する場合も、考え方は同じです。最初にストレージアカウントを作成し、その後にクラシック ファイル共有を作成します。公式手順では、Azure PowerShellとAzure CLIはいずれも最新バージョンの利用が前提とされています。(Microsoft Learn)
Provisioned v2のPowerShell例
$resourceGroupName = "rg-files-prod"
$storageAccountName = "stfilesprod001"
$region = "japaneast"
$shareName = "share01"
New-AzStorageAccount `
-ResourceGroupName $resourceGroupName `
-AccountName $storageAccountName `
-Location $region `
-Kind FileStorage `
-SkuName StandardV2_LRS
New-AzRmStorageShare `
-ResourceGroupName $resourceGroupName `
-AccountName $storageAccountName `
-ShareName $shareName `
-QuotaGiB 1024 `
-EnabledProtocol SMBProvisioned v2では、FileStorageとStandardV2_LRSやPremiumV2_LRSなどのSKUを組み合わせます。共有作成時には、必要に応じてIOPSやスループットの指定も検討します。公式例では、指定しない場合は推奨プロビジョニングが使われることが示されています。(Microsoft Learn)
Provisioned v2のAzure CLI例
resourceGroupName="rg-files-prod"
storageAccountName="stfilesprod001"
region="japaneast"
shareName="share01"
az storage account create \
--resource-group $resourceGroupName \
--name $storageAccountName \
--location $region \
--kind FileStorage \
--sku StandardV2_LRS \
--output none
az storage share-rm create \
--resource-group $resourceGroupName \
--storage-account $storageAccountName \
--name $shareName \
--quota 1024 \
--enabled-protocols SMB \
--output noneCLIでNFSを作成する場合は、--enabled-protocols NFSを指定する前に、ストレージアカウントの性能層、ネットワーク、バックアップ非対応などの制約を確認してください。HDDのPay-as-you-goファイル共有はSMBのみであるため、NFS用途に流用する設計は避けるべきです。(Microsoft Learn)
管理者が必ず確認すべき設定
Azure Filesのクラシック ファイル共有は、作成できた時点で終わりではありません。後から変更できる設定もありますが、最初の設計で間違えると移行や再作成が必要になる項目もあります。
| 設定 | 確認ポイント | 失敗しやすい例 |
|---|---|---|
| Resource provider | クラシック共有はMicrosoft.Storageが対象 | Microsoft.FileSharesプレビューの手順と混同する |
| Storage account kind | Provisioned v2/v1はFileStorage、Pay-as-you-goはStorageV2 | StorageV2でProvisioned v2共有を作ろうとする |
| SKU | SSD、HDD、LRS/ZRS/GRS/GZRSの要件に合わせる | SSDでGRS/GZRSを選べると誤解する |
| Protocol | SMBかNFSを共有作成時に選ぶ | Blob向けNFSv3設定をAzure FilesのNFS設定と誤解する |
| Encryption in transit | SMB/NFSごとの転送時暗号化要件を確認 | 旧SMBクライアントが接続できなくなる |
| Storage account key access | 共有キーでSMB/FileRESTを使うか確認 | キーアクセス無効化後にマウントや自動化が失敗する |
| Soft delete | 保持日数とコストを確認 | 削除済み共有の保持容量が課金対象になる |
| Backup | portal作成時の既定バックアップを確認 | 検証環境で不要なバックアップを有効にする |
| NFS networking | Private EndpointまたはService Endpoint、ポート2049を確認 | NSGやオンプレ側FWで2049が遮断される |
| Access tier | Pay-as-you-goのTransactionOptimized、Hot、Coolを選ぶ | 移行中にCoolを選び、トランザクション費用が増える |
NFSを使う場合はネットワーク設計を先に決める
SMBファイル共有では、作成そのものにネットワーク構成は必須ではありません。ただし、本番環境ではPrivate Endpointやネットワーク制限を検討すべきです。一方、NFSファイル共有ではネットワークレベルのセキュリティ構成が必須です。公式情報では、NFSv4.1がポート2049を使用し、オンプレミスから接続する場合はクライアント側の送信通信やNSGの受信ルールで2049がブロックされていないことを確認するよう説明されています。(Microsoft Learn)
Private Endpointを使うと、ファイル共有に仮想ネットワーク内のプライベートIPアドレスを割り当てられます。Service Endpointを使う場合は、特定のサブネットからのアクセスに制限できます。オンプレミスからNFS共有へアクセスする場合は、VPNまたはExpressRouteを含めた経路設計も必要です。(Microsoft Learn)
移行・展開で失敗しやすいポイント
ストレージアカウント単位の上限を見落とす
クラシック ファイル共有は、同じストレージアカウント内で上限を共有します。Provisioned v2のクラシック ファイル共有では、同一ストレージアカウント内の共有がストレージ、IOPS、スループットの上限を共有し、公式情報では将来の成長を見込んで3〜5年分の余裕を計画する考え方が示されています。(Microsoft Learn)
複数部門の共有を1つのストレージアカウントにまとめると、コスト配賦も難しくなります。プロジェクト別、部門別、顧客別に費用を追跡したい場合は、共有単位ではなくストレージアカウント単位で分ける設計も検討してください。
推奨IOPSと実ワークロードを同一視する
Provisioned v2では、容量に基づいてIOPSとスループットの推奨値が示されます。ただし、これは一般的な利用を前提にした目安であり、実際のワークロードがランダムIO中心なのか、大容量ファイル転送中心なのかで必要性能は変わります。性能要件が不明な場合は推奨値で開始し、メトリックを見ながら調整するのが安全です。(Microsoft Learn)
また、Provisioned v2では容量、IOPS、スループットを動的に変更できますが、増加後に減少できるタイミングには制約があります。短時間の検証で過剰に引き上げると、すぐに戻せない場合があるため、負荷試験では期間とコストを事前に決めておきましょう。(Microsoft Learn)
NFS共有にAzure Backupを期待する
Azure portalでファイル共有を作成する場合、バックアップは既定で有効になると説明されています。ただし、NFS共有はAzure Backupをサポートしないと公式情報で明記されています。NFS用途では、バックアップ方式、スナップショット、アプリケーション側の保護方式を別途設計してください。(Microsoft Learn)
Blob Storage向け設定をAzure Filesの設定と誤解する
ストレージアカウント作成画面には、Blob Storage向けの階層型名前空間、SFTP、Blobのソフト削除、Blobバージョニングなどが表示されることがあります。これらの多くはAzure Filesには適用されません。Azure Filesで見るべき項目は、ファイル共有のソフト削除、SMB/NFSの転送時暗号化、キーアクセス、TLS、Defender、ネットワーク設定です。(GitHub)
どの構成を選ぶべきかの判断基準
最初の判断は「性能を明示的に確保したいか」「実使用量ベースで始めたいか」「SMBかNFSか」です。迷った場合は、次の基準で絞り込むと設計しやすくなります。
| 要件 | 選びやすい構成 | 理由 |
|---|---|---|
| 新規の本番ファイル共有を作る | Provisioned v2 | 新規デプロイ向けの推奨モデルで、容量・IOPS・スループットを個別に設計できる |
| 低レイテンシが重要 | SSD + Provisioned v2 | SSDは高性能・低レイテンシ用途に向く |
| 汎用的なSMBファイル共有を安価に始めたい | HDD + Provisioned v2またはPay-as-you-go | コスト重視の一般用途に向く |
| オンプレから大量移行する | Pay-as-you-goならTransactionOptimizedを検討 | 移行中はトランザクションが多くなりやすい |
| LinuxからNFSv4.1で使う | SSD + NFS + Private EndpointまたはService Endpoint | NFSではネットワークレベルの制御が必須 |
| 部門別に費用を明確化したい | ストレージアカウントを分ける | クラシック共有では課金追跡の粒度がストレージアカウント単位になりやすい |
実装前チェックリスト
作成前に、次の項目をチーム内で確認しておくと、作成後の手戻りを減らせます。
- 使用するリソースプロバイダーは
Microsoft.Storageであり、クラシック ファイル共有の手順である - 新規作成ではProvisioned v2を第一候補として検討した
- ストレージアカウントの
kindとskuが目的の課金モデルと一致している - 共有名は小文字、数字、単一ハイフンのみで、先頭と末尾が小文字または数字になっている
- SMBとNFSのどちらを使うか決めている
- NFSの場合、Private EndpointまたはService Endpointとポート2049の許可を確認した
- 旧SMBクライアントがある場合、転送時暗号化とSecure transferの影響を確認した
- ストレージアカウントキーアクセスを有効にするか無効にするか決めている
- ソフト削除の保持日数とコスト影響を確認した
- バックアップの要否を環境ごとに決めている
- PowerShellまたはAzure CLIのバージョンを最新化している
- 移行時のアクセス層、IOPS、スループットを事前に見積もった
まとめ：まずは手順書と設定レビューを更新する
「Create a classic file share – Azure Files」の今回の公式情報で重要なのは、Azure Filesのクラシック ファイル共有を作成する際の判断軸が、課金モデル、ストレージアカウント種別、SKU、セキュリティ、ネットワークにまたがって明確化されている点です。
新規作成ではProvisioned v2を基本候補にしつつ、SMB/NFS、SSD/HDD、LRS/ZRS/GRS/GZRS、バックアップ、ソフト削除、キーアクセス、Private Endpointの要否を具体的に決めてから展開してください。既存の社内手順書がAzure portalの古い画面を前提にしている場合は、AdvancedタブとSecurityタブの記載を見直すことが最初のアクションです。
コメント