Windowsの大容量コピーが止まる原因とRobocopyでの転送整理

本記事が扱う事象は、WindowsのFile Explorer（ファイルエクスプローラー）で大容量ファイルや大量フォルダをコピーする際に、進捗が固まったように見えたり、転送が中断しやすかったりする点です。小さな文書や画像の移動では表面化しにくい一方で、数GB級の動画、何千階層にもなるフォルダ、またはバックアップ用途の一括転送では、処理の前提が変わります。そのため、同じ「コピー」でも、内部の見積もり手順、エラー時の扱い、転送の再開方法が結果を左右します。
この点から、本記事ではWindows標準のコピーが抱える構造を整理し、コマンドライン（コマンド入力画面）で利用できるRobocopy（ロボコピー）が前提としている設計と、運用上の確認点をつなげて説明します。

• 大容量転送で問題が出る理由と前提整理
• 「計算中」が長引く仕組みと進捗推定の限界
• エラー処理・再開・整合性確認が分かれ目になる
• Robocopyが前提にする設計と主要機能の整理
• 使い分けで分かれる条件と運用上の確認点

大容量転送で問題が出る理由と前提整理

普段のファイル移動は、数十枚の写真や短い文書が中心になりがちです。ただし、動画編集素材やバックアップのように、容量が大きい単体ファイル、または小さなファイルが大量にぶら下がるフォルダ構造を扱うと、同じ操作でも負荷の種類が変わります。読み出しと書き込みの速度だけではなく、転送前に何を数えるか、途中で止まったときにどこから再開するかが、完了までの時間と失敗率に影響します。

一方で、File Explorer（ファイルエクスプローラー）のコピーは、視覚的な進捗表示を重視した設計です。そのため、転送開始前に「総ファイル数」と「総サイズ」を把握しようとし、これが巨大なディレクトリ（フォルダ階層）では待ち時間の原因になります。さらに、進捗の残り時間推定は瞬間的な速度に引きずられ、転送が安定していても表示が大きく揺れます。

要点を整理すると、転送の本体処理より前段の集計と見積もりが、コピー全体を止める要因になり得ます。 そのため次章では、なぜ「計算中」の状態が長く続きやすいのかを、仕組みとして分けて扱います。

「計算中」が長引く仕組みと進捗推定の限界

File Explorer（ファイルエクスプローラー）は、コピー開始前に対象を列挙し、総量を推定してから転送を進めます。小規模なら実務上の支障は出ませんが、何万ファイルや深い階層がある場合、列挙とサイズ計算そのものが重い処理になります。そのため、転送が始まらないまま「残り時間を計算中」の表示が続き、利用者側は停止と区別しにくくなります。

さらに、残り時間の推定は、転送速度の瞬間値を基に変動しやすい構造です。ディスクのキャッシュ、別プロセスの読み書き、ネットワーク共有の混雑などで速度が揺れると、推定が「数分」から「数日」へ跳ぶこともあります。言い換えると、転送そのものが進んでいても、推定ロジックが安定していないために、状況把握が難しくなります。

つまり、進捗表示を成立させるための前処理と推定が、大容量転送ではボトルネックになりやすい設計です。 この結果として、転送完了の見通しが立てにくくなり、次に問題となるのが「途中で止まった場合に、どこまで成功したか」を判定しにくい点です。

エラー処理・再開・整合性確認が分かれ目になる

大量ファイルの転送では、個々のファイルがロックされていたり、読み取りエラーが混ざったりする可能性が上がります。File Explorer（ファイルエクスプローラー）は、ある1件で問題が起きたとき、全体を一時停止し、対話的な選択を求める場面が出ます。そうすることによって、夜間の一括転送や、操作なしで完走させたいバックアップ用途では中断が発生しやすくなります。

再開機能はWindowsの近年の版で改善されてきた一方で、なお効率てきとは言い切れません。再開時に宛先側の状態を再確認する手順が入り、扱う量が大きいほど再検証の負荷が目立ちます。また、コピーが完了しても、書き込まれたデータの整合性をチェックサム（checksum、検査用の値）で検証する工程は標準では行いません。以上を踏まえると、「存在しているが中身が壊れている」状態を工程内で検出しにくい、という構造上の弱点が残ります。

要点は、失敗時の継続性と完了後の検証性が弱いと、転送の成否を後から判断しにくい点です。 そのため次章では、同じWindows内で利用できるコマンドラインのRobocopy（ロボコピー）が、どの点を違う前提で設計しているかを整理します。

Robocopyが前提にする設計と主要機能の整理

Robocopy（ロボコピー）は、Windowsに用意されているコマンドラインのファイルコピー機能で、ディレクトリの複製や同期を想定した作りです。GUI（グラフィカルユーザーインターフェース）の進捗表示よりも、転送の継続性、ログ、再試行といった運用要件を優先します。この点から、途中で一部が失敗しても設定した回数だけ再試行し、待機時間を挟みつつ処理を進める、といった条件分岐を組み込みやすくなっています。

また、マルチスレッド（複数同時処理）で小ファイルを並列に運べるため、対象が「大量の小さなファイル」のときに差が出やすいとされています。さらに、転送断の後に続きから再開するモードや、ミラー（同期）として宛先をソースに一致させる動作も用意され、手作業の差分確認を減らす方向の設計です。

言い換えると、Robocopyは見た目の操作性より、失敗しにくく再現しやすい転送を重視した機能体系です。 なお、違いを整理するため、代表的な比較軸を表にまとめます。

ただし、条件指定を誤ると宛先側のファイル整理に影響し得ます。そのため次章では、どの利用場面で条件差が生じるのかを、運用上の確認点として整理します。

使い分けで分かれる条件と運用上の確認点

一般的な利用場面では、File Explorer（ファイルエクスプローラー）の操作性が有利です。進捗バーやドラッグ操作で完結し、短時間の小規模転送では、前処理の重さやエラー時の対話停止が表に出にくいからです。他方、業務データ、映像素材、バックアップのように、容量と件数が増えるほど、途中停止や成否確認の難しさが工程リスクになります。

Robocopy（ロボコピー）は、ログを残し、再試行や待機を条件として固定できる点が判断材料として重要です。一方で、同期やミラーの指定は、宛先側の不要ファイル削除に結びつく可能性があり、記載が不足している状態で運用すると、転送後の構造が想定とずれる余地が残ります。つまり、利便性の代わりに「条件設定が結果を決める」性格が強くなります。

以上を踏まえると、転送対象の規模と停止時の許容度に応じて、GUI中心かログ中心かで前提を分ける整理が必要です。 この結果、同じWindows環境でも、日常の小規模移動と、大容量の継続転送では、適合する道具が異なるという構造が明確になります。