目次
結論｜Blobの移動は「Copy→Delete」で実装する
Azure Blob Storageでは「ファイルを移動する（Move）」という操作は存在しません。
そのため、Blobを別のフォルダやコンテナへ移動したい場合は、以下の手順で実装します。
・コピー（Copy）
・元ファイル削除（Delete）
この「Copy→Delete」の流れが、Azureにおける正しい移動方法です。
特にAzure Functionsで処理を自動化する場合、コピー完了前に削除してしまうとデータ消失のリスクがあるため、順序と確認処理が重要になります。
本記事では、C#（Azure Functions）を用いてBlobを安全に移動する具体的な方法を解説します。
なぜBlobは直接移動できないのか？
Azure Blob Storageで直接「移動（Move）」ができない理由は、ストレージの仕組みにあります。
Blobは「ファイルシステム」ではなく「オブジェクトストレージ」として管理されており、パス（フォルダ構造）は実体ではなく仮想的なものです。
そのため、ファイルの位置を変更するという概念自体が存在しません。
この仕様により、Blobの移動は内部的にも「コピーして別の場所に新規作成し、元を削除する」という処理になります。
実務ではこの点を理解していないと、「Moveできるはず」と考えて実装し、想定外の挙動やデータ消失リスクにつながるケースがあります。
そのため、最初から「Copy→Deleteで実装する前提」で設計することが重要です。
Azure Functionsでの実装方法（C#）
Azure Functions（C#）でBlobを移動する場合は、「コピー完了を確認してから削除する」実装が基本になります。
以下はシンプルな実装例です。
var sourceBlobClient = sourceContainerClient.GetBlobClient("source-folder/sample.txt");
var destinationBlobClient = destinationContainerClient.GetBlobClient("processed-folder/sample.txt");
// コピー開始
await destinationBlobClient.StartCopyFromUriAsync(sourceBlobClient.Uri);
// コピー完了まで待機
BlobProperties properties;
do
{
await Task.Delay(500);
properties = await destinationBlobClient.GetPropertiesAsync();
}
while (properties.CopyStatus == CopyStatus.Pending);
// コピー成功時のみ削除
if (properties.CopyStatus == CopyStatus.Success)
{
await sourceBlobClient.DeleteIfExistsAsync();
}このように、StartCopyFromUriAsyncでコピーを開始し、CopyStatusを確認してから削除することで、安全に移動処理を実現できます。
特に非同期コピーは即時完了しない場合があるため、「完了確認をせずに削除する」実装は避ける必要があります。
詳細はMicrosoft公式ドキュメントも参考にしてください。
安全に移動するための注意点（実務でハマるポイント）
Blobの移動処理で最も多いミスは、「コピー完了前に削除してしまう」ことです。
StartCopyFromUriAsyncは非同期処理のため、呼び出し直後にコピーが完了しているとは限りません。
この状態で元ファイルを削除すると、コピーが失敗した場合にデータが完全に失われます。
また、CopyStatusはSuccess以外にもFailedやAbortedになる可能性があります。
実務では通信エラーや権限設定の問題でコピーが失敗するケースもあるため、必ずステータスを確認する必要があります。
さらに、大容量ファイルや別リージョン間のコピーでは処理時間が長くなり、タイムアウトや再試行が必要になる場合があります。
そのため、安全に運用するには以下を徹底します。
- CopyStatusがSuccessになるまで削除しない
- Failed時のログ出力と再試行処理を用意する
- タイムアウトを考慮した設計にする
実際の現場ではCopyStatusの確認を入れていない実装も多く、後からデータ欠損に気づくケースがあります。
特にバッチ処理や大量データ移行ではこのミスが致命的になりますが、この3点を守ることで実務でも安全にBlob移動処理を運用できます。
実務での使い方と設計のポイント
実務では、Blobの移動処理は単なるファイル操作ではなく、「処理ステータスの管理」とセットで設計することが重要です。
例えば、アップロードされたファイルを処理対象フォルダへ移動する場合、移動＝処理完了のトリガーとして扱うケースがあります。
このとき、Copy→Deleteの途中で失敗すると「未処理なのに移動済み」といった不整合が発生します。
そのため、以下のような設計が有効です。
- 処理中フォルダと完了フォルダを分ける
- コピー成功後にのみ状態を更新する（DBやログで管理）
- 再実行可能な構成にする（冪等性を持たせる）
また、Azure Functionsで実装する場合は、トリガー（BlobTriggerやQueueTrigger）と組み合わせて、「処理 → コピー → 確認 → 削除」という一連の流れを一貫して管理するのが一般的です。
このように「ファイル移動＝状態遷移」として設計することで、障害時にも安全にリカバリできる構成になります。
別記事にて解説していますが、以下のようなエラーが発生することがあるため設計時は注意が必要です。
- 大容量ファイル処理時にAzure Functionsのメモリ制限により処理がログ出力なしで中断されるケース
- CosmosDBとの連携時に状態管理の不整合
まとめ
Azure Blob Storageでは「移動（Move）」という操作は存在しないため、Blobを移動する場合は「Copy→Delete」で実装する必要があります。
特にAzure Functionsで自動化する場合は、コピー完了前に削除しないようにCopyStatusを必ず確認することが重要です。この確認処理を省略すると、データ消失のリスクが高まります。
また、実務では単純なファイル移動ではなく、「状態遷移」として設計し、失敗時の再試行やログ管理まで含めて考える必要があります。
本記事のポイントをまとめると以下の通りです。
- Blobは直接移動できない（Copy→Deleteが前提）
- CopyStatusを確認してから削除する
- 処理全体を安全に設計する（再試行・状態管理）
この3点を押さえることで、Azure環境でも安全にBlob移動処理を実装できます。