Azure Storage Moverは、オンプレミスのファイルサーバーやNAS、AWS S3などにあるファイル・フォルダーをAzure Storageへ移行するためのフルマネージド移行サービスです。結論から言うと、今回確認すべきポイントは「Azure Storageの既存データが自動的に変わる」ことではなく、移行方式・権限・エージェント配置・ネットワーク設計を事前に整理しないと、移行ジョブの開始や再実行でつまずきやすいことです。Azure Files、Azure Blob Storage、AWS S3、オンプレミス共有をまたぐ移行計画がある管理者や開発者は、対応するソースとターゲット、RBAC、エージェントのバージョン、ログ確認の流れを先に確認しておきましょう。Azure Storage Moverは、オンプレミスまたはAWS S3バケットからAzure Storageへファイルとフォルダーを移行し、ワークロードのダウンタイムを抑えることを目的としたサービスとして説明されています。(Microsoft Learn)
Azure Storage Moverとは：Azure Storageへの移行を一元管理するサービス
Azure Storage Moverは、単なるコピー用ツールではなく、移行プロジェクト、ソース、ターゲット、ジョブ、進捗確認をAzure上で管理するためのサービスです。オンプレミスの共有をAzure Filesへ移す、NFSデータをAzure Blobへ移す、AWS S3からAzure Blobへ移す、といった複数の移行シナリオを、1つのStorage Moverリソースから管理できます。公式情報では、リフトアンドシフトや繰り返し実行が必要な移行、グローバルに分散したファイル共有の管理にも使えるとされています。(Microsoft Learn)
重要なのは、Storage Moverリソース自体がファイルを処理するわけではない点です。オンプレミス移行では、ソースに近い場所へ移行エージェントを配置し、そのエージェントがAzure Storageのターゲットへデータを直接送信します。つまり、設計の中心は「Azure上にどのリソースを作るか」だけでなく、「エージェントをどこに置くか」「どの回線を使うか」「誰にどの権限を付与するか」になります。(Microsoft Learn)
なお、公開・更新日の扱いには注意が必要です。Microsoft Learnの該当概要ページはページ下部で「Last updated on 2025-10-19」と表示され、GitHub側のメタデータではms.date 10/17/2025となっています。2026年5月6日の公式情報として社内周知や記事化を行う場合でも、実装判断では概要ページだけでなく、リリースノートやシナリオ別ドキュメントを併せて確認するのが安全です。(Microsoft Learn)
何が変わるのか：移行設計の確認範囲が広がる
Azure Storage Moverの影響は、既存のAzure Storageアカウントの設定が勝手に変更されるようなものではありません。影響を受けるのは、これからファイル・フォルダー移行を計画するチームの設計、権限、展開手順、運用確認です。
| 確認項目 | 実務上の意味 | 最初に見るべきポイント |
|---|---|---|
| 移行元 | オンプレミスだけでなく、AWS S3も対象に含まれる | SMB、NFS、AWS S3のどれを使うか |
| 移行先 | Azure FilesかAzure Blobかで保持される意味が変わる | ACL、タイムスタンプ、フォルダー構造、HNSの要否 |
| 管理方法 | 共有単位ではなく、プロジェクト・エンドポイント・ジョブで管理する | ワークロード単位でプロジェクトを分ける |
| エージェント | オンプレミス移行ではソース近くのVMが重要 | 回線、名前解決、ファイアウォール、バージョン |
| 権限 | RBAC不足で登録・開始・再実行が止まりやすい | リソースプロバイダー登録と最小権限 |
| ログ・再実行 | 1回のコピーではなく、差分確認や再実行を前提にする | 検証用ジョブ、ログ、切り替え手順 |
見落としやすいのは、「Azure Storage Moverを使えば何でも移行できる」と考えてしまうことです。実際には、対応するソースとターゲットの組み合わせが決まっており、AWS S3の一部ストレージクラスやSMB 1.xなど、対象外になる条件があります。(Microsoft Learn)
対象者：管理者だけでなく開発者も確認すべき
Azure Storage Moverの主な対象者は、ファイルサーバーやNASを管理するインフラ管理者です。ただし、移行後のデータをアプリケーション、分析基盤、バッチ処理、Webサービスから参照する場合は、開発者も設計段階から関わるべきです。
特に、次の担当者は早めに確認しておく必要があります。
| 担当者 | 確認すべき理由 |
|---|---|
| Azure管理者 | Storage Moverリソース、RBAC、サブスクリプション、リソースグループを設計するため |
| ファイルサーバー管理者 | SMB/NFSのバージョン、ACL、フォルダー構造、空フォルダーの扱いを確認するため |
| ネットワーク管理者 | エージェントからAzure Storage、Azure Arc、Key Vaultなどへの接続を許可するため |
| セキュリティ担当者 | 移行時の権限、Private Link、監査ログ、S3バケット制限を確認するため |
| 開発者 | Blobとファイル共有の違い、パス構造、移行後の参照方法を検証するため |
開発者が後から参加すると、「移行は完了したがアプリが期待するディレクトリ構造やアクセス権と合わない」という問題が起きやすくなります。とくにAzure Blob Storageを移行先にする場合は、ファイルシステムと同じ前提で設計しないことが重要です。
対応するソースとターゲットを確認する
Azure Storage Moverでは、サポートされるソースとターゲットの組み合わせが決まっています。2026年5月時点で確認する場合、少なくとも次の組み合わせを整理してから移行計画を作るべきです。
| 移行元 | 移行先 | 注意点 |
|---|---|---|
| AWS S3 | Azure Blobコンテナー | GlacierまたはGlacier Deep Archiveのストレージクラスは移行対象外 |
| SMB 2.x / 3.xマウント | Azure FilesのSMB共有 | SMB 1.xソースは対象外。NFS Azure Files共有へのSMB移行も対象外 |
| SMB 2.x / 3.xマウント | Azure Blobコンテナー | フラット名前空間と階層型名前空間の両方が対象。HNSではADLS Gen2 REST APIが使われる |
| NFS 3 / 4マウント | Azure Blobコンテナー | フラット名前空間と階層型名前空間の両方が対象 |
| NFS 3 / 4マウント | Azure FilesのNFS 4.1共有 | NFSソースからNFS Azure Filesへの移行として整理する |
公式の概要ページでは、現在のリリースが特定のソース・ターゲット組み合わせについてフルフィデリティ移行をサポートすると説明しています。実務では「移行したいデータがある」から始めるのではなく、「そのプロトコルと移行先の組み合わせがサポートされているか」を先に確認することが重要です。(Microsoft Learn)
Azure FilesとAzure Blobの選び方
移行先をAzure FilesにするかAzure Blobにするかで、移行後の使い方は大きく変わります。既存のファイル共有として使い続けるならAzure Files、アプリケーションやデータ分析基盤からオブジェクトとして扱うならAzure Blobが候補になります。
| 判断基準 | Azure Filesが向いているケース | Azure Blobが向いているケース |
|---|---|---|
| 利用方法 | ファイル共有としてマウントして使う | アプリ、分析基盤、バックアップ、アーカイブで使う |
| プロトコル | SMBまたはNFSの共有を維持したい | REST APIやData Lake用途で使いたい |
| メタデータ | ACL、ファイル属性、タイムスタンプを重視する | オブジェクト単位の管理や階層型名前空間を重視する |
| 移行後の運用 | ユーザーやアプリが共有フォルダーとして利用 | Blobコンテナー、ライフサイクル管理、分析処理で利用 |
SMBソースからAzure Filesへ移行する場合、Azure Storage MoverはAzure Filesが持つファイル忠実性の範囲で、フォルダー構造、タイムスタンプ、ACL、ファイル属性などを保持します。一方、階層型名前空間が無効な標準Blobコンテナーでは、従来のファイルシステムと同じフォルダー構造を持たず、仮想フォルダーとして表現されます。NFSソースからBlobへ移行する場合、空フォルダーは空のBlobとして表現されることがあります。(Microsoft Learn)
この違いは、開発者にとっても重要です。たとえば、移行前のアプリが「空フォルダーの存在」や「フォルダー単位の権限」を前提にしている場合、Blob移行後に同じように動くとは限りません。移行先を決める前に、アプリが何を参照しているのか、ファイル名・パス・権限・メタデータのどれに依存しているのかを洗い出しましょう。
管理者が確認すべきRBACとサブスクリプション設定
Azure Storage Moverを使う前に、サブスクリプションとMicrosoft Entraテナントの関係を確認します。Storage Moverリソースを置くサブスクリプションは、移行先のAzure Storageアカウントと同じMicrosoft Entraテナントにある必要があります。また、Storage Moverリソースは、同じEntraテナント内であれば別サブスクリプションのAzure Storageへの移行もオーケストレーションできます。(Microsoft Learn)
次に、リソースプロバイダーを確認します。Azure Storage Moverでは、Microsoft.StorageMoverとMicrosoft.HybridComputeの登録が必要です。Azure portalから所有者または共同作成者としてデプロイする場合は自動登録される場合がありますが、Azure PowerShellやAzure CLIを使う場合は手動登録が必要になることがあります。(Microsoft Learn)
| 操作 | 最小限必要なRBACの目安 | 注意点 |
|---|---|---|
| リソースプロバイダー登録 | サブスクリプションのContributor | 初回利用前に必要 |
| Storage Moverリソースのデプロイ | サブスクリプションのReader、リソースグループのContributor | リソースプロバイダー登録済みが前提 |
| エージェント登録 | サブスクリプションのReader、リソースグループのContributor、Storage MoverのContributor | オンプレミス移行では重要 |
| 初回の移行開始 | サブスクリプションのReader、リソースグループのContributor、Storage MoverのContributor、ターゲットStorageアカウントのOwner | 最初のターゲット利用時に不足しやすい |
| 再実行 | サブスクリプションのReader、リソースグループのContributor、Storage Mover側のContributor | 初回と再実行で必要権限が異なる |
権限設計でありがちな失敗は、移行担当者にStorage Moverリソースの権限だけを付け、ターゲットStorageアカウント側の権限を忘れることです。特に初回ジョブではターゲットStorageアカウントのOwnerが必要になるため、事前に権限付与の申請ルートを決めておきましょう。(Microsoft Learn)
エージェント展開の注意点：ソースの近くに置く
オンプレミス移行では、Storage Moverエージェントが実際の転送作業を担います。公式情報では、エージェントは仮想マシンベースの移行アプライアンスであり、理想的には移行元ストレージにできるだけ近い仮想化ホスト上に配置すると説明されています。(Microsoft Learn)
Storage Moverリソースのリージョン選択も誤解しやすい点です。Storage Moverリソースのリージョンは、制御メッセージや移行メタデータの保存場所に関係しますが、移行データそのものはエージェントからターゲットのAzure Storageへ直接送信されます。そのため、パフォーマンス面ではStorage Moverリソースの場所より、ソース、エージェント、ターゲットStorageの距離やネットワーク品質のほうが重要です。(Microsoft Learn)
エージェントVMの最小要件も、移行規模に応じて確認が必要です。
| 移行規模の目安 | 最小メモリ | 最小vCPU |
|---|---|---|
| 100万アイテム | 8GiB | 4仮想コア |
| 1,000万アイテム | 8GiB | 4仮想コア |
| 3,000万アイテム | 12GiB | 6仮想コア |
| 5,000万アイテム | 16GiB | 8仮想コア |
| 1億アイテム | 16GiB | 8仮想コア |
エージェントイメージには少なくとも100GiBのローカルストレージが必要で、小さなファイルが大量にある移行ではキャッシュにより必要量が増える可能性があります。また、最小構成で動作してもパフォーマンスが最適とは限らないため、本番移行ではソースのアイテム数、ファイルサイズ分布、回線帯域を踏まえて余裕を持たせるべきです。(Microsoft Learn)
エージェントのバージョン管理で失敗しない
Azure Storage Moverはハイブリッドサービスであり、クラウドサービスとエージェントの両方に継続的に機能追加や改善が入ります。新機能には対応するエージェントバージョンが必要になることがあるため、「以前ダウンロードしたイメージを使い回す」運用は避けたほうが安全です。(Microsoft Learn)
リリースノートでは、GA以降のエージェントは将来のバージョンへ自動更新されると説明されています。ただし、更新確認にはエージェントが実行中でインターネットに接続されている必要があります。また、2025年10月22日のリリースではエージェントバージョン4.0.902が現行とされる一方、既存エージェントから更新できずVMイメージとして利用する形であることも示されています。(Microsoft Learn)
実務では、次の確認を移行前チェックに入れてください。
| 確認項目 | 確認しない場合のリスク |
|---|---|
| Microsoft Download Centerから最新イメージを取得しているか | サポート外または古い機能セットで移行を始める |
| エージェントが実行中で外部接続できるか | 自動更新や登録が進まない |
| 使いたい移行シナリオに必要なバージョンか | NFS、SMB、Blobなどの組み合わせでジョブ作成・実行に失敗する |
| 本番前に小規模な検証ジョブを実行したか | ACL、空フォルダー、長いパス、特殊文字の問題を本番で発見する |
ネットワークとセキュリティの確認ポイント
オンプレミス移行では、エージェントVMがAzureの複数サービスへ接続できる必要があります。公式の前提条件では、エージェントはジョブ割り当ての受信、進捗報告、ログ送信、ソースデータの読み取り、Azure Storageへの転送を行うと説明されています。さらに、ファイアウォールが有効なStorageアカウントではエージェントからのトラフィックを許可する必要があり、SMBソースでKey Vaultを使う場合も同様に通信許可が必要です。(Microsoft Learn)
プライベートネットワーク構成では、すべてがPrivate Endpointだけで完結するとは限りません。Storage Moverエージェントがプライベートネットワーク内で動作するには、いくつかのAzureサービスへ接続する必要があり、サービスによってはプライベートエンドポイントに対応するものと、パブリックエンドポイントへのアクセスが必要なものがあります。(Microsoft Learn)
AWS S3からAzure Storageへ、かつAWS側がVPC内にある場合は、Private Link Service Direct ConnectやPrivate Endpointを使ったプライベート接続の設計も検討対象になります。この構成では、Private Link Serviceを事前に用意し、Storage Mover側でPrivate Connectionを作成・承認してから移行ジョブで使います。承認済みでない接続はジョブ作成時に選択できません。(Microsoft Learn)
AWS VPC連携では、S3バケットとVPC Endpointのリージョン不一致、S3バケットポリシーのaws:SourceVpce制約、Private Connection数の上限にも注意が必要です。公式情報では、Private Connectionは1リージョンあたり最大10個まで構成でき、Private Link Service Direct ConnectはStorage Moverリソースと同じリージョンに構成する必要があるとされています。(Microsoft Learn)
大規模移行ではAzure Data Boxとの併用も検討する
数十TBからPB級のデータをネットワークだけで移すと、帯域、移行期間、業務影響が大きくなります。この場合、初回の大量転送にAzure Data Boxを使い、その後の差分反映にAzure Storage Moverを使う構成が現実的です。
公式情報では、Data Boxを使った初期移行中にもソース側で変更が発生する可能性があるため、Azure Storage Moverでクラウド側との差分を検出し、Data Boxで取り込まれなかった更新ファイルや新規ファイルを転送できると説明されています。ファイルの変更が権限などのメタデータだけであれば、ファイル全体ではなく新しいメタデータのみをアップロードできます。(Microsoft Learn)
この使い方は、停止時間を短くしたいファイルサーバー移行に向いています。先にData Boxで大半のデータを取り込み、切り替え直前にStorage Moverで差分同期を行い、最後にアプリケーションやユーザーの参照先を切り替える流れです。
Azure内のBlob間移行も別シナリオとして確認する
Azure Storage Moverには、Azure Blobコンテナー間で大規模データを転送するAzure-to-Azure Migrationのシナリオも用意されています。これは、異なるStorageアカウントやリージョン間でBlobデータを移す場合に使える機能です。公式ドキュメントでは、Blob間移行は1ジョブあたり5億オブジェクトの転送をサポートし、サブスクリプションあたり最大10個の同時ジョブがサポートされると説明されています。(Microsoft Learn)
ただし、「移動」という名前に惑わされないようにしてください。Blobは実際にはコピーされ、元のBlobコンテナーは残ります。また、Archive層のBlobは自動リハイドレートされないため、移行前に復元しておく必要があります。アーカイブ済みデータを含むコンテナーを移す場合は、ジョブ作成前に対象Blobのアクセス層を棚卸ししておきましょう。(Microsoft Learn)
移行前に使えるチェックリスト
本番移行前には、次の順で確認すると抜け漏れを減らせます。
| 順番 | 確認内容 | 判断基準 |
| -: | ———– | ————————————— |
| 1 | 移行元の棚卸し | SMB/NFS/S3、容量、ファイル数、空フォルダー、ACL、特殊文字を確認 |
| 2 | 移行先の決定 | ファイル共有用途ならAzure Files、分析・API用途ならBlobを優先 |
| 3 | 対応組み合わせの確認 | 公式のソース・ターゲット表に一致するか確認 |
| 4 | サブスクリプション準備 | Entraテナント、リソースグループ、リソースプロバイダー登録を確認 |
| 5 | RBAC設計 | 初回移行と再実行で必要権限が違う点を確認 |
| 6 | エージェント準備 | 最新イメージ、配置場所、VMスペック、ネットワーク接続を確認 |
| 7 | 小規模検証 | 代表的なフォルダー、ACL、空フォルダー、長いパスでテスト |
| 8 | ログ確認 | Copyログ、Job runログ、警告・失敗ファイルの確認手順を決める |
| 9 | 差分同期 | Data Box併用や再実行のタイミングを決める |
| 10 | 切り替え | 利用者停止時間、DNS/マウント先変更、アプリ設定変更を手順化 |
このチェックリストで特に重要なのは、最初の棚卸しです。Storage Moverは移行を管理しやすくするサービスですが、移行元の権限、パス、ファイル数、アプリ依存関係まで自動で正しく判断してくれるわけではありません。移行前に「何を保持すべきか」を明確にしておくことが、移行後の手戻りを減らします。
管理者・開発者が取るべき次の行動
Azure Storage Moverを検討している場合、まずは本番全体ではなく、代表的な1共有または1バケットを選んで検証してください。確認すべき観点は、転送速度だけではありません。ACL、タイムスタンプ、空フォルダー、Blob上のパス表現、ログの見え方、再実行時の挙動、権限申請の流れまで含めて確認する必要があります。
管理者は、サブスクリプション、RBAC、リソースプロバイダー、エージェント、ネットワークを先に整えます。開発者は、移行先がAzure FilesなのかAzure Blobなのかを理解し、アプリケーションが移行後のパス構造やメタデータに対応できるかを検証します。大規模移行では、Azure Data BoxとStorage Moverの組み合わせや、差分反映のタイミングも事前に設計しましょう。
Azure Storage Moverは、ファイル移行を場当たり的なコピー作業から、計画・実行・監視・再実行できる管理対象のプロセスへ変えるサービスです。次にやるべきことは、公式ドキュメントを読み込むことだけではなく、自社の移行元を棚卸しし、サポートされる組み合わせにマッピングし、小さな検証ジョブで実際の結果を確認することです。
コメント