Azure Storageアカウント間でBlobをコピーするなら、基本は AzCopy v10のazcopy copyコマンドを使うのが最短です。ローカルPCや踏み台VMにいったんダウンロードして再アップロードする必要はなく、AzCopyはサーバー間APIを使ってストレージサーバー間で直接コピーします。(Microsoft Learn)
ただし、実運用では「コマンドを実行すれば終わり」ではありません。Microsoft Entra IDのテナント条件、RBACロール、SAS、Storage firewall、Private Endpoint、Premium Block Blobのアクセス層、Blob index tagsの扱いを確認しないと、403エラーやコピー後のメタデータ差分、性能不足につながります。
この記事では、Azure Storageの「Copy blobs between Azure storage accounts with AzCopy v10」について、管理者・開発者が押さえるべき変更点、影響範囲、確認すべき設定、移行・展開時の注意点を実務目線で整理します。
AzCopy v10でのAzure Storageアカウント間コピーは何が重要なのか
今回のポイントは、単に「Blobをコピーできる」という話ではありません。重要なのは、アカウント間コピーを標準的な運用手段として扱う場合に、認証・ネットワーク・データ属性・性能設計を明確に確認する必要があるという点です。
AzCopy v10では、Blob、ディレクトリ、コンテナー、ストレージアカウント配下のデータを別のStorageアカウントへコピーできます。Blob Storageエンドポイントだけでなく、Data Lake Storage Gen2で使うdfs.core.windows.net形式のエンドポイントも例示されています。(Microsoft Learn)
特に管理者が見落としやすいのは、次の5点です。
| 確認項目 | 影響 | 見落とした場合に起きやすい問題 |
|---|---|---|
| 認証方式 | Microsoft Entra IDまたはSASでのアクセス制御 | RBAC不足、SAS権限不足、403エラー |
| テナント条件 | Entra認証では送信元・送信先が同一テナントである必要 | 別テナント間コピーで認証が成立しない |
| ネットワーク制限 | Storage firewall、VNet、Private Endpoint、Network Security Perimeter | CannotVerifyCopySourceなどの403エラー |
| データ属性 | アクセス層、Blob index tags、Blob種別 | コピー後に検索・ライフサイクル管理・階層設定が想定とずれる |
| 性能設計 | 並列度、ジョブ分割、ログ量 | 大量Blobコピーで時間がかかる、ジョブ管理の負荷が増える |
対象者：誰が確認すべきか
この内容は、Azure Storageを扱うすべての利用者に関係しますが、特に影響が大きいのは次の担当者です。
Azure管理者
ストレージアカウントの移行、リージョン間複製、環境分離、バックアップ、データ退避を担当する管理者は、RBACとネットワーク制限を必ず確認する必要があります。AzCopyのアカウント間コピーはクライアントのローカル帯域に依存しにくい一方、クライアントが送信元・送信先の両方にアクセスできる必要があります。(Microsoft Learn)
開発者・DevOps担当者
CI/CD、バッチ処理、データ連携、検証環境へのデータ複製でAzCopyを組み込む場合は、対話ログインではなくサービスプリンシパル、マネージドID、SASのどれを使うかを先に決める必要があります。AzCopyはスクリプトやスケジュール転送にも組み込めますが、コピー元またはコピー先が転送中に変更されるシナリオはサポートされない点に注意が必要です。(Microsoft Learn)
セキュリティ担当者
SASトークンを使う場合は、有効期限、権限、対象範囲を最小化する必要があります。Microsoftの認証ドキュメントでは、可能な場合はMicrosoft Entra IDとマネージドIDの利用が推奨され、SASを使う場合もユーザー委任SASが推奨されています。(Microsoft Learn)
基本コマンド：Blob、ディレクトリ、コンテナーをコピーする
最小構成では、azcopy copyに送信元URLと送信先URLを指定します。
単一Blobをコピーする
azcopy copy \
'https://<source-account>.blob.core.windows.net/<container>/<blob-path>' \
'https://<destination-account>.blob.core.windows.net/<container>/<blob-path>'Data Lake Storage Gen2の階層型名前空間を使っている場合は、dfs.core.windows.netエンドポイントを使う構成もあります。
azcopy copy \
'https://<source-account>.dfs.core.windows.net/<container>/<path>' \
'https://<destination-account>.dfs.core.windows.net/<container>/<path>'公式例では、Blob単体、ディレクトリ、コンテナー、アカウント全体のコピーが示されており、コピー操作は同期的に行われます。コマンドが戻った時点で、対象ファイルのコピー完了を示します。(Microsoft Learn)
ディレクトリを再帰的にコピーする
仮想ディレクトリ配下をまとめてコピーする場合は、--recursiveを付けます。
azcopy copy \
'https://<source-account>.blob.core.windows.net/<container>/<directory-path>' \
'https://<destination-account>.blob.core.windows.net/<container>' \
--recursiveコンテナー全体をコピーする
azcopy copy \
'https://<source-account>.blob.core.windows.net/<container>' \
'https://<destination-account>.blob.core.windows.net/<container>' \
--recursiveアカウント配下をまとめてコピーする
azcopy copy \
'https://<source-account>.blob.core.windows.net/' \
'https://<destination-account>.blob.core.windows.net/' \
--recursiveこの形式は便利ですが、コンテナー数やBlob数が多い環境では、最初から全量コピーにせず、コンテナー単位・プレフィックス単位で分割する方が安全です。失敗時の再実行範囲を小さくでき、ログ確認や差分検証もしやすくなります。
認証方式はMicrosoft Entra IDとSASのどちらを使うべきか
AzCopyでは、主にMicrosoft Entra IDまたはSASトークンで認証します。公式ドキュメントでは、Storageアカウントの所有者であっても、Blobデータへ自動的にアクセスできるわけではないと説明されています。データ操作には、別途Blobデータ用の権限が必要です。(Microsoft Learn)
| 認証方式 | 向いている場面 | 注意点 |
|---|---|---|
| Microsoft Entra ID | 管理者作業、社内運用、自動化、監査を重視する環境 | 送信元・送信先が同一Entraテナントである必要がある |
| マネージドID | Azure VM、Azure Functions、AutomationなどAzure上の自動処理 | 対象リソースへのRBAC割り当てが必要 |
| サービスプリンシパル | CI/CD、外部実行基盤、非対話スクリプト | シークレットや証明書の保護が必要 |
| SASトークン | 一時的なコピー、外部委託、限定作業 | URLに権限情報が含まれるため取り扱いに注意 |
Entra ID利用時の確認ポイント
Microsoft Entra IDで送信元と送信先の両方を認証する場合、両方のStorageアカウントは同じMicrosoft Entraテナントに属している必要があります。(Microsoft Learn)
また、Blobデータ操作にはAzure RBACのデータプレーン権限が必要です。たとえば、Storage Blob Data ContributorはBlob Storageリソースへの読み取り、書き込み、削除権限を付与するロールとして説明されています。(Microsoft Learn)
よくある失敗は、AzureサブスクリプションのOwnerやContributorを持っているだけでAzCopyも実行できると思い込むことです。管理プレーンの権限とBlobデータの権限は別物です。
SAS利用時の確認ポイント
SASを使う場合は、送信元URLまたは送信先URLにSASトークンを付与します。送信元には読み取り、送信先には書き込み・作成など、操作内容に合った権限が必要です。公式例でも、SASトークンをURLに追加する形式が示されています。(Microsoft Learn)
実務では、次のように分けて考えると安全です。
| URL | 必要になりやすい権限 | 用途 |
|---|---|---|
| 送信元 | Read、List | コピー対象の読み取り、一覧取得 |
| 送信先 | Write、Create、List | Blob作成、上書き、ディレクトリ配下コピー |
| index tagsを扱う場合 | Tags関連権限 | Blob index tagsの追加・再適用 |
SASは便利ですが、ログやシェル履歴、CI/CDの実行ログに残ると情報漏えいにつながります。スクリプトに直接書かず、環境変数やシークレット管理サービスから渡す運用にしましょう。
ネットワーク制限があるStorageアカウントでは403エラーに注意
Storage firewall、VNet、Private Endpoint、Network Security Perimeterを使っている環境では、AzCopyのアカウント間コピーで403エラーが発生することがあります。
ここで重要なのは、AzCopyがサーバー間コピーを行う場合でも、単純に「ローカルPCから両方に疎通できればよい」とは限らないことです。ネットワーク制限がある場合、送信先Storageが送信元Blobを取得しようとする経路も考慮する必要があります。
Microsoftのトラブルシューティング記事では、ネットワーク制限があるStorageアカウント間コピーについて、クライアント、送信元、送信先のアクセス経路を確認する必要があると説明されています。特に、Storage firewallで両方のアカウントを制限している場合は追加構成が必要になることがあります。(Microsoft Learn)
典型的な確認パターン
| 構成 | 確認すべきこと |
|---|---|
| パブリックエンドポイント利用 | クライアントのグローバルIPまたはVNetが送信元・送信先の許可リストに入っているか |
| Private Endpoint利用 | 実行元VM、送信元Storage、送信先StorageのVNet接続とDNS解決が正しいか |
| Hub-Spoke構成 | Hub上のVMから異なるSpokeのPrivate Endpointにコピーしていないか |
| Network Security Perimeter利用 | client-to-destination、client-to-source、destination-to-sourceの3経路が許可されているか |
Hub-Spoke構成で、異なるSpoke VNet上のPrivate Endpointに接続されたStorageアカウント間をHub上のVMからAzCopyでコピーすると、CannotVerifyCopySourceを含む403エラーが出るケースがあります。Microsoftは回避策として、送信元VNetに送信先StorageのPrivate Endpointを作成する、VMを送信元Storageと同じVNetに配置してVNetピアリングする、一時的なステージングアカウントを使う、最終手段としてVMにダウンロードしてからアップロードする方法を示しています。(Microsoft Learn)
Premium Block Blobへコピーする場合はアクセス層を保持しない
Premium Block Blob Storageアカウントにコピーする場合は、--s2s-preserve-access-tier=falseを指定して、コピー操作でアクセス層を保持しないようにします。Premium Block Blob Storageアカウントではアクセス層がサポートされないためです。(Microsoft Learn)
azcopy copy \
'https://<source-account>.blob.core.windows.net/<container>' \
'https://<destination-account>.blob.core.windows.net/<container>' \
--recursive \
--s2s-preserve-access-tier=falseHot、Cool、Archiveなどのアクセス層を前提にライフサイクル管理を設計している場合、コピー先のアカウント種類によって運用設計を見直す必要があります。特に、標準Blob StorageからPremium Block Blobへ移行する場合は、コピー後に同じライフサイクルポリシーがそのまま適用できるとは考えない方が安全です。
Blob index tagsは自動保持前提にしない
送信元BlobにBlob index tagsがあり、それをコピー先でも維持したい場合は、コピー先Blobにタグを再適用する必要があります。公式ドキュメントでは、タグを追加するために--blob-tagsオプションを使い、URLエンコードしたキーと値のペアを指定する方法が示されています。(Microsoft Learn)
azcopy copy \
'https://<source-account>.blob.core.windows.net/<container>/<blob>' \
'https://<destination-account>.blob.core.windows.net/<container>/<blob>' \
--blob-tags='env=prod&system=crm'日本語やスペースを含む値はURLエンコードが必要です。たとえば、my tagはmy%20tagのように扱います。
注意したいのは、ディレクトリ、コンテナー、アカウントを指定して--blob-tagsを付けた場合、コピー先のすべてのBlobに同じタグが付くことです。公式ドキュメントでも、ソースにディレクトリ、コンテナー、アカウントを指定した場合、コピー先にコピーするすべてのBlobがコマンドで指定した同じタグを持つと説明されています。(Microsoft Learn)
タグ運用で失敗しやすい例
| 失敗例 | 何が問題か | 対策 |
|---|---|---|
すべてのBlobに同じdepartmentタグを付けてしまう | 部門別検索や課金分析が崩れる | プレフィックス単位でジョブを分ける |
| タグの書き込み権限がない | コピーはできてもタグ付与で失敗する | Entra IDならStorage Blob Data Ownerまたはタグ書き込み権限を確認 |
| 日本語タグをそのまま指定する | エンコード不備で意図通りに反映されない | URLエンコード済み文字列を使う |
| 送信元タグが自動で引き継がれると思い込む | コピー後の検索条件が変わる | コピー後にタグを検証する |
タグは検索、分類、ライフサイクル、データ管理に影響します。移行作業では、コピー件数だけでなく、タグの一致確認も検証項目に入れてください。
--from-toは自動判定が不安なときに指定する
AzCopyはコピー元とコピー先の種類を自動判定しますが、パイプ処理やエミュレーターなど、自動検出が失敗する可能性がある場合は--from-toで明示できます。公式ドキュメントでは、Blob Storage間のBlobBlob、Blob StorageからData Lake Storage Gen2へのBlobBlobFS、Data Lake Storage Gen2からBlob StorageへのBlobFSBlobなどが示されています。(Microsoft Learn)
| 値 | 用途 |
|---|---|
BlobBlob | Azure Blob Storage間のコピー |
BlobBlobFS | Blob StorageからData Lake Storage Gen2へのコピー |
BlobFSBlob | Data Lake Storage Gen2からBlob Storageへのコピー |
BlobFSBlobFS | Data Lake Storage Gen2間のコピー |
BlobFile | Blob StorageからAzure Filesへのコピー |
FileBlob | Azure FilesからBlob Storageへのコピー |
通常のBlob間コピーでは省略しても動作することが多いですが、スクリプト化する場合は明示指定しておくと、実行環境差による誤判定を避けやすくなります。
azcopy copy \
'https://<source-account>.blob.core.windows.net/<container>' \
'https://<destination-account>.blob.core.windows.net/<container>' \
--recursive \
--from-to=BlobBlob大量コピーでは並列度とジョブ分割を設計する
AzCopyのアカウント間コピーはサーバー間APIを使うため、クライアントPCの処理能力を直接大量に消費するタイプの転送ではありません。性能を上げたい場合は、AZCOPY_CONCURRENCY_VALUE環境変数を調整できます。公式の性能最適化ドキュメントでは、Storageアカウント間でBlobをコピーする場合、AZCOPY_CONCURRENCY_VALUEを1000より大きい値に設定することも検討できると説明されています。(Microsoft Learn)
Linuxの例です。
export AZCOPY_CONCURRENCY_VALUE=1500Windowsコマンドプロンプトの例です。
set AZCOPY_CONCURRENCY_VALUE=1500ただし、むやみに大きくすればよいわけではありません。大量Blobのコピーでは、ストレージアカウント側のトランザクション、他ワークロードへの影響、ログ量、ジョブ管理のオーバーヘッドも考慮します。公式ドキュメントでは、大量ファイルの転送ではジョブサイズを小さくすること、必要に応じてジョブを分割すること、ログ量を減らすことが性能改善策として示されています。(Microsoft Learn)
実務での分割基準
| コピー規模 | 推奨する進め方 |
|---|---|
| 数百〜数千Blob | コンテナー単位でコピーし、ログ確認で十分 |
| 数十万Blob | プレフィックス、日付、業務単位で分割 |
| 数百万Blob以上 | ジョブ設計、再実行計画、検証スクリプト、監視を事前に用意 |
| 本番移行 | リハーサル、本番差分、切り戻し手順を分ける |
なお、--cap-mbpsによるスループット上限は、アップロード・ダウンロードでは使えますが、Storageアカウント間コピーではサポート対象ではありません。帯域を絞りたい場合にこのオプションだけで制御できると思い込まないようにしてください。(Microsoft Learn)
コピー前に確認すべきチェックリスト
AzCopyによるAzure Storageアカウント間コピーを本番で使う前に、次の項目を確認してください。
| 分類 | 確認内容 | 判断基準 |
|---|---|---|
| 認証 | Entra ID、マネージドID、サービスプリンシパル、SASのどれを使うか | 定常運用はEntra ID系、一時作業はSASも検討 |
| RBAC | 送信元の読み取り、送信先の書き込み権限があるか | Storage Blob Data Contributorなどデータロールを確認 |
| テナント | 送信元・送信先が同一Entraテナントか | Entra認証で異なる場合はSASなど別方式を検討 |
| ネットワーク | Storage firewall、Private Endpoint、NSPの経路が通るか | client-to-source、client-to-destination、destination-to-sourceを確認 |
| アカウント種類 | StandardかPremiumか | Premium Block Blobではアクセス層保持を無効化 |
| データ属性 | index tags、metadata、access tier、blob type | コピー後の差分検証を用意 |
| 実行単位 | Blob、ディレクトリ、コンテナー、アカウント全体 | 失敗時の再実行範囲が大きすぎないか |
| 性能 | 並列度、ジョブ分割、ログ量 | 小規模テスト後に本番値を決める |
| 変更凍結 | コピー中に送信元・送信先が更新されないか | 更新がある場合は差分同期や停止時間を設計 |
| 監査 | ログ、ジョブID、実行者、SAS管理 | 後から追跡できる形で保存 |
移行・展開時の安全な進め方
本番データをコピーする場合は、いきなり全量コピーしないことが重要です。以下の順序で進めると、失敗時の影響を抑えやすくなります。
小さなBlobで疎通確認する
まず、テスト用コンテナーや小さなBlobを使って、認証・ネットワーク・書き込み権限を確認します。
azcopy copy \
'https://<source-account>.blob.core.windows.net/test/sample.txt' \
'https://<destination-account>.blob.core.windows.net/test/sample.txt'ここで403が出る場合は、コマンドの問題よりも、RBAC、SAS、Storage firewall、Private Endpointの問題である可能性が高いです。
プレフィックス単位でリハーサルする
次に、実データの一部だけをコピーします。
azcopy copy \
'https://<source-account>.blob.core.windows.net/app-logs/2026/05/' \
'https://<destination-account>.blob.core.windows.net/app-logs/2026/05/' \
--recursiveこの段階で、件数、サイズ、タグ、アクセス層、アプリケーションからの参照可否を確認します。
本番コピーではログと再実行方針を決めておく
AzCopyはジョブ単位でログとプランファイルを扱います。大量コピーでは、途中失敗を前提に、どの単位で再実行するかを決めておきます。
おすすめは、次のようにコピー対象を分割することです。
container-a/year=2024/
container-a/year=2025/
container-a/year=2026/
container-b/master/
container-b/archive/コンテナー全体を一度にコピーすると、失敗時の確認範囲が広くなります。業務システム単位、年月単位、データ分類単位で分けると、検証と切り戻しが簡単になります。
よくあるトラブルと対処法
403 Forbiddenが出る
最も多い原因は、認証またはネットワーク制限です。
Entra ID利用時は、送信元・送信先の両方にBlobデータ権限があるか確認します。SAS利用時は、送信元URLに読み取り権限、送信先URLに書き込み・作成権限があるか確認します。ネットワーク制限環境では、クライアントだけでなく送信先Storageから送信元Storageへの取得経路も確認します。
コピー後にBlob index tagsが期待通りでない
--blob-tagsを指定していない場合、必要なタグがコピー先に反映されない可能性があります。逆に、ディレクトリやコンテナー単位で--blob-tagsを指定すると、対象Blobすべてに同じタグが付きます。タグを業務分類や検索に使っている場合は、コピー後にAzure CLIやSDKでタグを検証してください。
Premium Block Blobへのコピーでエラーになる
コピー先がPremium Block Blob Storageの場合は、アクセス層の保持が問題になることがあります。--s2s-preserve-access-tier=falseを指定して、アクセス層をコピー操作から除外します。(Microsoft Learn)
コピーが遅い
まず小規模テストで基準値を取り、Blob数が多い場合はジョブを分割します。Storageアカウント間コピーではAZCOPY_CONCURRENCY_VALUEの調整も検討します。ただし、同じStorageアカウントで本番アプリが稼働している場合は、トランザクション増加による影響を見ながら調整してください。
コピー中にデータが更新される
AzCopyは、送信元または送信先が転送中にアクティブに変更されるシナリオをサポートしないと説明されています。(Microsoft Learn)
移行では、アプリケーションの書き込み停止、メンテナンス時間、差分コピー、整合性検証のどれを使うかを事前に決める必要があります。
開発者向け：スクリプト化するときの実装ポイント
CI/CDやバッチでAzCopyを使う場合は、コマンドそのものよりも、認証情報とログ管理を安全に扱うことが重要です。
SASを直接スクリプトに書かない
悪い例です。
azcopy copy "https://source.blob.core.windows.net/container?<SAS>" "https://dest.blob.core.windows.net/container?<SAS>" --recursiveこの形だと、Git、CIログ、シェル履歴にSASが残る危険があります。
改善例です。
azcopy copy \
"${SOURCE_URL}${SOURCE_SAS}" \
"${DEST_URL}${DEST_SAS}" \
--recursiveSASはAzure Key Vault、GitHub Actions Secrets、Azure Pipelinesのsecret variablesなどから注入する方が安全です。
終了コードとログを必ず見る
スクリプトでは、AzCopyの終了コードを確認し、失敗時にログを保存します。大量コピーでは、標準出力だけを見て成功判定しないでください。
azcopy copy "$SOURCE_URL" "$DEST_URL" --recursive
RESULT=$?
if [ $RESULT -ne 0 ]; then
echo "AzCopy failed. Check AzCopy logs."
exit $RESULT
fi本番と検証で同じコマンド構造にする
検証環境では手作業、本番ではスクリプトという運用にすると、環境差によるミスが起きやすくなります。検証段階から、本番と同じ変数名、同じ認証方式、同じオプションで実行しましょう。
管理者向け：運用設計で決めておくこと
AzCopyのアカウント間コピーを標準運用に入れるなら、次のルールを決めておくとトラブルを減らせます。
| 運用項目 | 決めること |
|---|---|
| 認証標準 | 原則Entra ID、例外的にSASなど |
| ロール付与 | コンテナー単位かStorageアカウント単位か |
| SAS発行 | 発行者、期限、権限、保管場所 |
| 実行場所 | 管理者端末、Azure VM、Automation、CI/CD |
| ネットワーク | Public Endpoint、Private Endpoint、NSPの標準構成 |
| ログ保存 | 保存期間、保存先、監査対象 |
| 失敗時対応 | 再実行単位、切り戻し、エスカレーション |
| 性能管理 | 実行時間帯、並列度、他システムへの影響 |
特に、Private Endpointを使う環境では「どのVMから実行するか」を固定しておくことが大切です。実行元が変わるだけでDNS解決、VNet経路、Firewall許可条件が変わり、同じコマンドでも結果が変わることがあります。
AzCopy v10でStorageアカウント間コピーを使うべき場面
AzCopyによるアカウント間コピーは、次のような場面に向いています。
| 利用シーン | AzCopyが向いている理由 |
|---|---|
| Storageアカウント移行 | コンテナー単位、ディレクトリ単位でコピーしやすい |
| 本番から検証環境へのデータ複製 | 必要な範囲だけ切り出してコピーできる |
| リージョン間退避 | ローカルに全量保持せずコピーできる |
| アカウント分割・統合 | プレフィックスやコンテナー単位で段階移行できる |
| 一時的なバックアップ | スクリプト化しやすい |
一方で、常時双方向同期、リアルタイムレプリケーション、アプリケーション更新中の完全整合コピーには向きません。その場合は、Azure Storageの冗長性、オブジェクトレプリケーション、アプリケーション側の停止設計、データベース連携なども含めて検討する必要があります。
まず取るべき行動
AzCopy v10でAzure Storageアカウント間のBlobコピーを行う場合は、次の順番で確認してください。
- コピー対象をBlob単位、ディレクトリ単位、コンテナー単位、アカウント単位のどれにするか決める。
- 認証方式をMicrosoft Entra ID、マネージドID、サービスプリンシパル、SASから選ぶ。
- 送信元と送信先のRBACまたはSAS権限を確認する。
- Storage firewall、Private Endpoint、Network Security Perimeterの経路を確認する。
- Premium Block Blob、Blob index tags、アクセス層などデータ属性の扱いを決める。
- 小さなBlobで疎通確認し、プレフィックス単位でリハーサルする。
- 本番コピーではジョブ分割、ログ保存、失敗時の再実行方法を決めてから実行する。
AzCopyのコマンド自体はシンプルです。しかし、本番運用で差が出るのは、コマンドの暗記ではなく、認証、ネットワーク、データ属性、性能、検証手順を先に設計できているかどうかです。まずは小さな範囲でコピーを成功させ、その結果をもとに本番用の実行単位とチェックリストを固めるのが安全です。
コメント