2026年4月8日、Microsoft は Azure Migrate で Azure Files 評価がパブリック プレビューで利用できるようになったと案内しました。結論から言うと、今回の追加で価値が大きいのは、オンプレミスのファイル共有を「Azure Files に寄せられるもの」と「Azure VM 側で受けるべきもの」に、移行の初期段階で切り分けやすくなった点です。共有の発見、準備状況の判定、月額コスト、Azure Files SKU 推奨、オンプレミス比のビジネスケースまで Azure Migrate 内で確認できるため、容量だけで移行先を決めて後から性能や冗長性で詰まるリスクを下げやすくなります。 (Microsoft)
この記事では、Azure Migrate がプレビューで Azure Files 評価を追加したことで何が変わるのか、Azure Files 評価サポートが移行計画に重要な理由、実務での判断基準、始め方、失敗しやすいポイントまで整理します。
Azure Migrate がプレビューで Azure Files 評価を追加したポイント
Microsoft のリリース情報と Learn ドキュメントを整理すると、今回の Azure Files 評価追加で、移行前に見える判断材料は次のように増えました。 (Microsoft)
| 見えるようになった項目 | 移行計画での使い道 |
|---|---|
| オンプレミスの SMB/NFS 共有の発見と一覧化 | 共有の抜け漏れ、想定外の大容量共有、Linux/Windows 混在を早めに把握する |
| グループ化・タグ付け・フィルター | 部門別、システム別、波次別で評価範囲を切りやすい |
| 準備完了 / 条件付きで準備完了 / 非対応の判定 | Azure Files にそのまま寄せられる共有と、事前対処が必要な共有を分ける |
| リージョン、冗長性、メディア種別、性能を踏まえた SKU 推奨 | Standard と Premium、LRS/ZRS/GRS/GZRS などの設計を勘ではなく根拠ベースで決める |
| 月額コスト見積もりと Business case | 稟議用の TCO 比較や、先に移すべき共有の優先順位付けに使う |
| Azure Files が合わない共有の Azure VM 代替案 | 無理に PaaS 化せず、現実的な着地点を選べる |
Azure Migrate の良い点は、Azure Files 一択の評価ではないことです。評価結果では、Azure Files が適していれば PaaS 優先の Modernize 寄りに判断しつつ、適さない共有は Azure VM ベースの移行パスも提示します。つまり今回の追加は、「Azure Files へ寄せる圧力」を強める機能というより、「どこまで寄せられるかを先に見える化する」機能として受け取ると実務で使いやすいです。 (Microsoft Learn)
Azure Files 評価サポートが移行計画に重要な理由
ファイル共有移行は、コピーより前の棚卸しと切り分けで詰まりやすい
大規模なファイルサーバー移行では、最初の難所はデータコピーそのものよりも、「どの共有が存在し」「どれくらい使われ」「どの依存関係があり」「どれを同じ設計でまとめられるか」を把握することです。Microsoft Learn でも、発見フェーズはサイズ、件数、依存関係を洗い出す難しく時間のかかる工程だと説明しています。Azure Migrate の Azure Files 評価は、このあとに続く評価フェーズで IOPS、スループット、サイズ、容量、リージョン可用性を見て準備状況を判定するため、移行先設計の入口として理にかなっています。 (Microsoft Learn)
容量だけでは、正しい Azure Files 設計は決められない
Azure Files のコストは、課金モデル、メディア層、冗長性、リソース モデルの4要素で決まります。さらに、Standard の HDD は汎用向けで、Premium の SSD は一貫した高性能と低待機時間向けです。一方で冗長性の選択肢は対称ではなく、geo 冗長の GRS/GZRS は HDD でのみ利用でき、SSD は LRS または ZRS が前提です。つまり、「何TBあるか」だけで Premium/Standard や冗長化方式を決めると、性能不足にも過剰コストにもつながりやすいということです。 (Microsoft Learn)
加えて、Azure Files のパフォーマンスは公開ターゲットだけで決め打ちすればよいわけではありません。Microsoft は、デプロイ内の他の変数もターゲットに影響するため、実際の使用パターンでテストすることを勧めています。Azure Migrate の評価は有用ですが、業務アプリがぶら下がる高負荷共有では「評価で当たりを付ける → 実測で確かめる」という順番が安全です。 (Microsoft Learn)
「Azure Files に寄せる共有」と「VM で受ける共有」を早めに分けられる
Azure Migrate は、各共有について Azure Files と Azure VM のどちらが適するかを見ながら、準備状況と月額コストを提示します。評価が成功し、要件とコストメリットを満たす場合は Azure Files が推奨され、逆に Azure Files に向かない共有は Azure VM ベースのパスに落とせます。サイズ推定などで評価エラーが出た共有や、Azure Files の最大サイズを超える共有は、そのまま進めず再設計や分割を検討すべきだと早い段階で判断できます。 (Microsoft Learn)
実務での判断基準
まずはこの3軸で見ると迷いにくい
評価結果を読むときは、次の3軸で判断すると整理しやすくなります。 (Microsoft Learn)
| 判断軸 | 見るポイント | 実務での判断例 |
|---|---|---|
| 性能 | IOPS、スループット、日中の利用密度 | 多人数・多アプリが使う高負荷共有は Premium や分離配置を優先 |
| 可用性 | LRS/ZRS/GRS/GZRS の要件 | geo 冗長が必要なら HDD 前提、SSD は LRS/ZRS 前提で考える |
| 運用方式 | クラウド専用か、オンプレミス併用か | 切替後もローカルキャッシュや低停止が必要なら Azure File Sync を組み合わせる |
高負荷共有は「どのストレージ アカウントに載せるか」まで考える
Standard の Azure file share では、同じストレージ アカウントに複数の共有を入れると IOPS とスループットが共有プールになります。アーカイブ用途や日常負荷が低い共有なら集約しやすい一方、多くのユーザーやアプリが使う高負荷共有は、1共有ごとにストレージ アカウントを分ける設計が勧められています。Azure Files 評価で SKU だけ見て安心せず、「同居させる共有は何か」まで設計に落とし込むことが重要です。 (Microsoft Learn)
高負荷共有を分離していくと、今度はストレージ アカウント数の上限も現実的な論点になります。Microsoft Learn では、サブスクリプション・リージョンあたり 250 アカウント、クォータ引き上げで 500 までとしています。大量の共有を一律に「1共有1アカウント」にするのではなく、評価結果から本当に分離が必要な共有だけを切り出すほうが現実的です。 (Microsoft Learn)
権限・認証・UNC パスの維持は、評価の次に詰める
Azure Files に寄せると決めたあとで後回しにしがちなのが、認証、ACL、ネットワーク、既存パスの維持です。Azure Files では、共有レベルの ACL とファイル/フォルダーの NTFS ACL を使い、オンプレ AD DS や Microsoft Entra Domain Services を使った ID ベース認証も可能です。さらに、既存の共有パスを変えたくないなら DFS-N を検討する余地があります。評価結果が良くても、ここを詰めないと切替時にユーザー影響が大きくなります。 (Microsoft Learn)
大規模コピーでは、ルート ディレクトリの ACL を先に設定しておくのも見落としやすいポイントです。Microsoft Learn では、大量のファイルをコピーしたあとにルート ACL を変更すると反映に時間がかかるため、先に設定することを勧めています。これは実務上かなり効く注意点です。 (Microsoft Learn)
Assessment と Business case は役割が違う
Azure Migrate では、Assessment は「どう移すか」を見る材料で、準備状況、サイジング、Azure 側コストを把握するためのものです。一方、Business case は「なぜ Azure か」を見る材料で、オンプレミス費用、Azure 費用、TCO、年次効果を比較するためのものです。Azure Files 評価が追加されたことで、ファイル共有移行でもこの2層を分けて考えやすくなりました。技術判断と稟議判断を混ぜないことが、プロジェクトを前に進めやすくします。 (Microsoft Learn)
移行実行フェーズは、評価結果に合わせてツールを選ぶ
Azure Files 評価が良くても、移行ツールの選び方を誤ると停止時間や権限維持で失敗します。Microsoft の公式ガイドをベースにすると、ざっくり次の整理が実務向きです。 (Microsoft Learn)
| シナリオ | 向いている手段 | 使いどころ |
|---|---|---|
| Windows ファイルサーバーを止めたくない、オンプレミス キャッシュも残したい | Azure File Sync | 低停止で移したい、ハイブリッド運用を続けたい |
| Cloud-only で SMB/NFS 共有を Azure Files に寄せたい | Azure Storage Mover | フル マネージド寄りに進めたい、停止時間を抑えたい |
| 数十〜数百TB級、回線が細い、拠点が遠い | Azure Data Box + オンライン追随 | まず大量データをオフライン搬送し、差分だけ後追いする |
| Windows からシンプルに段階コピーしたい | RoboCopy | 複数回のミラーで停止時間を短くしたい |
補足すると、Azure File Sync は Windows ファイルサーバー移行で near-zero downtime とハイブリッド運用に強く、サーバーを稼働させたまま移行したいケースに向きます。反対に、Linux の SMB 共有をクラウド専用で Azure Files に寄せるなら、公式の移行ガイドでは Azure Storage Mover が有力です。 (Microsoft Learn)
大容量移行では、Azure Data Box で初回の大半を持ち込み、Azure Storage Mover で差分とメタデータ変更だけを追随させる組み合わせが有効です。Storage Mover は、権限のようにメタデータだけが変わった場合、ファイル本体を再転送せず更新だけ送れるため、最終同期を軽くしやすいのが強みです。 (Microsoft Learn)
また、ACL やタイムスタンプ、属性の保持が重要なら、どのコピー ツールでも同じと考えないことが大切です。Microsoft のガイドでは、Azure Storage Mover、Data Box、RoboCopy、Azure File Sync は SMB Azure file share で高い忠実性を確保しやすい一方、Storage Explorer や Azure Data Factory はメタデータ保持の面で不向きとされています。 (Microsoft Learn)
Azure Migrate で Azure Files 評価を始める最短手順
- すでに Azure Migrate アプライアンスをサーバー移行向けに入れているなら、そのまま追加設定なしで Windows / Linux 上の SMB・NFS 共有を検出できます。まずは共有の一覧とおおよそのサイズを出して、評価対象の全体像を掴みます。 (Microsoft Learn)
- Azure portal の Azure Migrate で インフラストラクチャ > ファイル共有 に進み、列フィルターやカスタム タグで評価対象を絞ります。部門別、業務別、波次別でタグを切っておくと、後の評価や移行順序付けが楽になります。 (Microsoft Learn)
- 評価の作成 で Azure Files 評価を作成します。このとき、正確な計算のために、選択した共有と同じサーバーにある併置共有が自動で評価スコープに追加されることがあります。想定外の共有が増えても、まずは仕様として確認してください。 (Microsoft Learn)
- 評価結果では、推奨パス、準備状況、月額コスト、ターゲット SKU、上位の大容量共有などを確認します。既定では PaaS を優先する Modernize が推奨されますが、Azure Files に合わない共有は Azure VM パスも候補に残せます。 (Microsoft Learn)
- 技術面は Assessment、費用対効果は Business case で切り分けて見ます。費用説明まで必要なら、オンプレミス費用と Azure 費用の比較まで見られる Business case を併用したほうが社内説明が早いです。 (Microsoft Learn)
- 評価結果はスナップショットです。ソース環境やパフォーマンス データが変われば結果も変わるため、設計確定前やカットオーバー前には再評価しておくほうが安全です。 (Microsoft Learn)
失敗しやすいポイント
- 容量だけで Standard / Premium を決める
実際は、課金モデル、メディア層、冗長性、リソース モデルでコスト構造が変わります。性能面も実利用での検証が必要なので、容量だけで決めると過剰投資か性能不足になりやすいです。 (Microsoft Learn) - 高負荷共有を同じ Standard ストレージ アカウントに集約する
HDD の Azure file share は、同じストレージ アカウント内で IOPS とスループットを共有します。低負荷共有の集約は有効ですが、業務ピークが重なる共有までまとめると、移行後に遅延の原因になります。 (Microsoft Learn) - SSD でも geo 冗長を選べると思い込む
Azure Files の GRS / GZRS は HDD のみで、SSD は LRS / ZRS が前提です。可用性要件から逆算すると、最初からメディア選択が変わることがあります。 (Microsoft Learn) - ルート ACL や認証方式を後回しにする
ルート ACL の後設定は大規模コピー後だと反映が重くなりがちです。ID ベース認証、共有レベル ACL、NTFS ACL、DFS-N まで含めて、評価後すぐに設計へ入るのが安全です。 (Microsoft Learn) - 0 byte 共有や最大サイズ超過の警告を流す
共有サイズが 0 と見なされるとターゲット推奨が生成されず、Azure Files の最大サイズを超える共有はそのまま移行できません。こうした共有は、存在確認や分割設計を先に行う必要があります。 (Microsoft Learn) - コピー ツールなら何でも同じだと考える
ACL や属性を維持したいなら、ツールごとの忠実性の差を見ないと危険です。特に Storage Explorer や Azure Data Factory は、フル フィデリティ前提のファイル共有移行には向きません。 (Microsoft Learn) - 古い OS でも同じように評価できると思う
Azure Migrate は Windows Server 2008 R2 でのファイル共有の検出と TCO 評価をサポートしていません。古いサーバーが含まれる環境では、先に対象整理か代替手順を考える必要があります。 (Microsoft Learn)
まとめ
Azure Migrate がプレビューで Azure Files 評価を追加したことで、ファイル共有移行は「まず全部 Azure VM に載せる」か「感覚で Azure Files を選ぶ」かの二択ではなくなりました。共有の発見、準備状況、SKU 推奨、月額見積もり、Business case、そして Azure VM へのフォールバックまでを同じ流れで見られるため、Azure Files に向く共有だけを根拠付きで先に切り出しやすくなっています。 (Microsoft)
次にやるべきことは明快です。まず Azure Migrate で共有一覧を出し、Azure Files 評価で 準備完了 / 条件付き / 要再設計 を分けてください。そのうえで、高負荷共有の分離、冗長性、認証、ACL、パス維持、移行ツール選定までを続けて決めると、後戻りの少ない移行計画になります。 (Microsoft Learn)
コメント