Azure Files入門｜SMBファイル共有をクラウドに移行するアクセス層・Azure File Sync・料金設計の実践ガイド

オンプレのWindowsファイルサーバーをAzureに移行しようとしたとき、「Azure Blob StorageとAzure Filesはどう違うのか」「既存のSMBパスをそのまま使えるのか」という疑問にぶつかる人は多い。結論から言うと、SMBファイル共有はAzure Filesが担う。Blobはオブジェクトストレージであり、アプリケーションからAPIでアクセスすることを前提とした設計だ。UNCパス（\\server\share形式）で使うファイルサーバーの置き換えには、Azure Filesが直接対応している。

この記事では、Azure Filesについてオンプレ経験者向けに解説する。パフォーマンス層とアクセス層の選び方、SMBマウントの手順、Azure File Syncを使ったハイブリッド移行、料金の仕組みと注意点まで、現場で必要な知識を体系的にまとめた。

Azure Filesとは？オンプレのWindowsファイルサーバーとの違い

Azure FilesはAzureが提供するフルマネージドのクラウドファイル共有サービスだ。SMBとNFSの両プロトコルに対応しており、Windows/Linux/macOSから標準プロトコルでマウントできる。AWSで対応するサービスを挙げるとすればAmazon FSxになるが、Azure FilesはAzureのエコシステムとの親和性が高く、Azure AD認証やAzure Backupとの連携が標準的に用意されている。

オンプレのWindowsファイルサーバーとの大きな違いは、ハードウェアとOSの管理が不要な点だ。ディスクの増設、OSパッチ、Active Directoryのメンテナンスといった作業から解放される。

オンプレのストレージ種別とAzure各サービスの対応については、オンプレストレージ（SAN・NAS・DAS）とクラウドの対応表も参照してほしい。Azureがどのオンプレストレージを何のサービスで代替できるのかが整理されている。

Azure Filesのパフォーマンス層とアクセス層の選び方

Azure Filesには2つのパフォーマンス層と、Standardに限り4つのアクセス層がある。「どれを選ぶか」でコストとIOPSが大きく変わるため、選定基準を理解しておく必要がある。

1. Standard層（汎用 v2 ストレージアカウント）

HDD（磁気ディスク）ベースのストレージで、4種のアクセス層から選択できる。

・Transaction Optimized（トランザクション最適化）: 汎用的なワークロード向け。最安価格帯ではないが、トランザクション料金が4層中最も低く、アクセス頻度が高いシナリオで割安になりやすい。デフォルト選択肢として迷ったらここから始めるとよい。
・Hot（ホット）: 頻繁にアクセスするファイルに向く。ストレージ単価はTransaction Optimizedとほぼ同等だが、読み取り操作のトランザクション単価がやや安い。
・Cool（クール）: 30日以上アクセスしないデータ向け。ストレージ単価は安くなるが、トランザクションとアクセス料金が上がる。誤ってアクセス頻繁なデータを入れると逆に高くなるので注意が必要だ。
・Cold（コールド）: 90日以上ほぼアクセスしない長期保存向け。ストレージ単価は4層中最安だが、取り出し時のトランザクション料金が最も高い。早期削除料金（90日未満での層変更）も発生する。

2. Premium層（FileStorage ストレージアカウント）

SSDベースで低レイテンシが必要なワークロードに向く。アクセス層の選択はなく、プロビジョニング容量に対する固定課金モデルだ。IOPSも容量に比例してプロビジョニングされる（100GiB = 100 IOPS基準＋バースト）。

データベースの補助ストレージ、CAD/GIS等のランダムI/O負荷が高いファイル共有、開発環境の共有コードリポジトリなどに適している。SMB Multichannelにも対応しており、複数のネットワーク接続を使って帯域幅を最大化できる。

アクセス層の設計思想についてはホットデータ・ウォームデータ・コールドデータの違いも参考にしてほしい。AzureとAWSのストレージ階層設計の考え方が横断的に整理されている。

Azure FilesをSMBでマウントする手順

1. ストレージアカウントとファイル共有の作成

Azureポータルで操作する場合は次の順序で進める。

・「ストレージ アカウント」を作成 → アカウントの種類を選択（Standardは「汎用 v2」、Premiumは「FileStorage」）
・冗長性（LRS/ZRS/GRS/GZRS）を選択（日本国内のみなら LRS または ZRS が現実的）
・ストレージアカウント内の「ファイル共有」ブレードから「+ ファイル共有」を作成
・共有名と割り当て容量を設定（Standardは後から実使用量に応じた課金なので、上限を大きめに設定しておいて問題ない）

Azure CLIで一括作成する場合：

# ストレージアカウントの作成（Standard LRS、大容量ファイル共有を有効化）
az storage account create \
  --name mystorageaccount \
  --resource-group myResourceGroup \
  --location japaneast \
  --sku Standard_LRS \
  --kind StorageV2 \
  --enable-large-file-share

# ファイル共有の作成（Hot層、クォータ100GiB）
az storage share-rm create \
  --resource-group myResourceGroup \
  --storage-account mystorageaccount \
  --name myshare \
  --quota 100 \
  --access-tier Hot

2. Windows ServerからのSMBマウント（PowerShell）

Azureポータルの「接続」ボタンをクリックすると、OSに合わせたマウントスクリプトが自動生成される。PowerShellで実行するだけで永続マウントが設定される。

# Azureポータルの「接続」から生成されるスクリプト（概要）
# まずポート445疎通確認
$connectTestResult = Test-NetConnection `
  -ComputerName "mystorageaccount.file.core.windows.net" `
  -Port 445

if ($connectTestResult.TcpTestSucceeded) {
    # 認証情報を資格情報マネージャーに登録
    cmd /c "cmdkey /add:`"mystorageaccount.file.core.windows.net`" /user:`"localhost\mystorageaccount`" /pass:`"ストレージアクセスキー`""
    # ドライブレターZとして永続マウント
    New-PSDrive -Name Z -PSProvider FileSystem `
      -Root "\\mystorageaccount.file.core.windows.net\myshare" -Persist
} else {
    Write-Error "ポート445に到達できません。ISPやファイアウォールの設定を確認してください。"
}

3. LinuxからのSMBマウント（cifs-utils）

# cifs-utilsのインストール（Ubuntu/Debian系）
sudo apt-get install -y cifs-utils

# 資格情報ファイルを作成（ストレージキーをここに記載）
sudo mkdir -p /etc/smbcredentials
sudo bash -c 'cat > /etc/smbcredentials/mystorageaccount.cred << EOF
username=mystorageaccount
password=ストレージアクセスキー
EOF'
sudo chmod 600 /etc/smbcredentials/mystorageaccount.cred

# マウントポイント作成とマウント
sudo mkdir -p /mnt/myshare
sudo mount -t cifs \
  //mystorageaccount.file.core.windows.net/myshare \
  /mnt/myshare \
  -o credentials=/etc/smbcredentials/mystorageaccount.cred,serverino,nosharesock,actimeo=30

# /etc/fstabへの追記（永続マウント）
echo "//mystorageaccount.file.core.windows.net/myshare /mnt/myshare cifs credentials=/etc/smbcredentials/mystorageaccount.cred,serverino,nosharesock,actimeo=30 0 0" | sudo tee -a /etc/fstab

【注意】ポート445ブロック問題

SMBマウントが失敗する最もよくある原因は、ポート445（SMB）がISPまたはオフィスのファイアウォールでブロックされていることだ。Azure FilesはHTTPS（443）経由のSMBを採用していないため、ポート445が通らない環境では以下の回避策を検討する。

・プライベートエンドポイントを使う: VNet内に専用のプライベートIPを割り当て、パブリックアクセスを無効化する。オンプレからはVPN/ExpressRoute経由でアクセスする形になる。
・Azure File Syncを使う: Windows ServerとAzureのSync通信はHTTPS（443）で行われる。ローカルのSMBマウントはそのまま維持しつつ、クラウドへはFile Sync経由で同期する。詳しくは次セクションで解説する。
・VPN/ExpressRoute経由のみに制限: オフィスとAzureを専用線・VPN接続し、ポート445はその閉域ネットワーク内でのみ通すように構成する。

Azure File Sync入門｜オンプレとクラウドをハイブリッド同期する

Azure File Syncは、オンプレのWindowsファイルサーバーとAzure Filesを双方向で同期するサービスだ。「ファイルサーバーをクラウドに移したいが、一気に切り替えるのはリスクが高い」という現場の要件にフィットする。段階的な移行や、複数拠点のファイル共有統合にも活用できる。

Azure File Syncのアーキテクチャ

主な構成要素は次の3つだ。

・Azure File Sync（ストレージ同期サービス）: Azureポータルで作成するリソース。同期グループとサーバー登録を管理する。
・同期グループ: 「どのAzure Filesの共有」と「どのWindows Serverのフォルダ」を同期するかを定義する単位。複数のサーバーエンドポイントを1つのクラウドエンドポイントに紐付けることで、複数拠点の同期も実現できる。
・Azure File Syncエージェント: Windows Server（2012 R2以降）にインストールするエージェント。AzureとはHTTPS（443）で通信するためポート445は不要。

クラウド階層化（Cloud Tiering）の仕組み

Cloud Tieringを有効にすると、アクセスされていないファイルをAzure Filesに移動し、ローカルには「スタブ（参照ポインタ）」だけを残す。ユーザーがスタブにアクセスすると、Azure Filesから透過的にリコールされるためユーザーはクラウドとローカルの違いを意識しない。

ローカルディスクの空き容量ポリシーを20%に設定した場合、ボリュームが80%に達するとアクセスが古い順にクラウドへ移される。ユーザーから見えるファイル一覧に変化はなく、容量が自動的に確保されていく仕組みだ。

Azure File Syncの導入手順（概略）

・Azureポータルで「Azure File Sync」リソース（ストレージ同期サービス）を作成
・オンプレのWindows ServerにAzure File Syncエージェントをインストール
・エージェントをAzureのストレージ同期サービスに登録（Azureアカウントで認証）
・同期グループを作成し、クラウドエンドポイント（Azure Filesの共有）とサーバーエンドポイント（ローカルフォルダパス）を紐付け
・初回同期が完了後、必要に応じてCloud Tieringを有効化

初回同期はデータ量によって数時間から数日かかることがある。本番移行前に小規模なテスト同期で動作確認することを強く勧める。また同期対象フォルダには250万ファイル/共有の上限がある点も把握しておく必要がある。

料金の仕組みと試算シナリオ（2026年9月時点）

Azure Filesの料金は「ストレージ容量」「トランザクション」「アクセス料金」の組み合わせで決まる。Premium層はプロビジョニング容量に対する固定課金モデルだ。正確な最新料金はAzure公式の料金計算ツールで確認することを勧めるが、試算のベースとして目安を示しておく。

Standard層の料金目安（東日本リージョン・LRS）

・Transaction Optimized: 約0.065 USD/GiB/月。トランザクション料金は最も低い層。
・Hot: 約0.065 USD/GiB/月。Transaction Optimizedと近い単価だが読み取りトランザクション料金がやや安い。
・Cool: 約0.050 USD/GiB/月。ストレージは安いがアクセス（読み取り）料金が加算される。
・Cold: 約0.040 USD/GiB/月。ストレージ単価は最安だが、取り出し料金と早期削除料金に注意。

試算例：1TiB（1,024GiB）のファイルサーバーをHot層で運用

ストレージ料金: 1,024 GiB × 0.065 USD ≒ 66.6 USD/月（約1万円、2026年9月時点・1USD≒150円）

これにトランザクション料金が加算される。ファイルの読み書き頻度が高いシステムでは、トランザクション料金がストレージ料金に匹敵するか上回ることもある。Cold層でも頻繁にアクセスすれば結果的に高くつくため、アクセスパターンの実測と层選択はセットで考える必要がある。

Premium層の料金目安（東日本リージョン・LRS）

約0.21 USD/GiB/月（プロビジョニング容量ベース）

試算例：100GiBをプロビジョニングする場合

100 GiB × 0.21 USD ≒ 21 USD/月（約3,150円）

PremiumはI/O集約型ワークロードでIOPSが保証される。ランダムI/Oが毎秒数百回を超えるような要件では、StandardのIOPS上限（最大1,000IOPS/共有）に引っかかるためPremiumを選択する必要がある。

Azure File Syncを使う場合の追加コスト

Azure File Sync自体の基本料金は無料だ。ただし、同期で発生するトランザクションは通常のAzure Files料金が適用される。Cloud Tieringでスタブからリコール（再ダウンロード）が発生すると、データ転送料金とアクセス料金がかかる。Cold層 × 高頻度リコールの組み合わせはコストが跳ね上がることがあるため、Tieringを有効化する際は事前の試算が欠かせない。

Azure Blob Storage入門も参照すると、Azureのオブジェクトストレージとファイルストレージのコスト特性の違いが理解しやすくなる。

スナップショットとバックアップの設計

Azure Filesは共有スナップショット機能を持つ。1ファイル共有あたり最大200スナップショット（保持期間最大10年）。誤削除・誤上書きへの対応として、ShareレベルのVSSスナップショットをAzure CLIやPortalから取得できる。

Azure Backupと連携すると、スナップショットの自動取得・保持ポリシー・リテンション管理を一元化できる。詳細はAzure Backup入門を参照してほしい。

スナップショット・バックアップ・レプリケーションの違いが混乱しやすい場合はバックアップ・スナップショット・レプリケーションの違いが整理の助けになる。

よくあるトラブルと対処法

① ポート445でマウントが失敗する

`Test-NetConnection -ComputerName mystorageaccount.file.core.windows.net -Port 445` でTCP疎通を確認する。失敗する場合はISP/ファイアウォールのブロックが原因の可能性が高い。プライベートエンドポイント＋VPN/ExpressRoute、またはAzure File Syncへの切り替えを検討する。

② SMBマウント後にファイルの書き込みが遅い

StandardのHDD層はランダムI/Oが苦手だ。IOPSが毎秒数百を超えるような負荷がかかる場合はPremium（SSD）層への移行を検討する。クライアント側のキャッシュ設定（`actimeo`パラメータ）の調整も効果的なことがある。

③ Azure File Syncで同期ステータスがエラーになる

よくある原因として次の3つがある。ファイルパスが260文字を超えること（Windowsのパス長制限）、ファイル名にSMBで使えない文字（コロン、アスタリスクなど）が含まれること、ファイルのアクセス権限エラーだ。Azureポータルのサーバーエンドポイント「同期のヘルス」でエラーファイルのリストを確認できる。

④ StorageアカウントのKindを間違えた

PremiumのAzure FilesはStorageV2（汎用 v2）ではなく「FileStorage」アカウントタイプが必要だ。StorageV2でPremiumのFile Storageを作ろうとするとオプションが表示されないため、アカウント作成時のKind選択を必ず確認する。

⑤ アクセス層を後から変更できるか

StandardのHot/Cool/Cold/Transaction OptimizedはAzure CLIやポータルからファイル共有ごとに後から変更できる。ただしCool/ColdはTier変更後30日/90日以内に再度Tier変更または削除した場合、早期削除料金が発生することを覚えておきたい。

⑥ Azure ADによるID認証が設定できない

Azure AD Kerberosを使った認証は、Windows Server 2019以降（またはAzure AD参加済みクライアント）が対象だ。Windows Server 2016以前ではオンプレAD DSとのKerberos認証を使う必要がある。いずれも共有レベルの権限（Azure RBACロール）とディレクトリ/ファイルレベルのNTFS ACLを組み合わせて権限管理を行う。

本記事のまとめ

Azure Filesは、SMBファイル共有のクラウド移行において最も現実的な選択肢だ。ポート445の問題や認証方式の設計さえ押さえておけば、オンプレのファイルサーバーをほぼそのままの操作感でクラウドに置き換えられる。Azure File Syncを活用すれば、既存の運用を維持しながら段階的に移行することも可能だ。

まずは検証環境でStorageアカウントを作成し、Azureポータルが自動生成する接続スクリプトでマウントを試してみてほしい。ファイルサーバー移行の第一歩として、ハードルは想像より低いはずだ。