VM上のWindows Serverで「大量の小さいファイル」をコピーすると、転送速度（MB/s）ではなく“ファイル1個ごとの処理”が支配的になり、想像以上に遅くなることがあります。特に同一ストレージ上の複数ドライブ（C/D/E/F）運用では、ストレージのIOPS上限・断片化・ウイルス対策のリアルタイムスキャンなどが重なると、数MB/s→数KB/s級まで落ち込むケースも珍しくありません。
まず押さえる：なぜ「大量の小ファイル」は遅くなるのか
数GBの大きなファイルをコピーするのは得意でも、数百万個の小ファイルは別競技です。小ファイルコピーが遅くなる主因は、データ本体よりもメタデータ処理（ファイル作成・属性更新・ディレクトリエントリ更新・セキュリティ情報・タイムスタンプ・MFT更新など）が支配的になるためです。
- 1ファイルごとに「作る→書く→閉じる」が発生し、そのたびにストレージへ小さなI/Oが大量に出ます
- ウイルス対策が新規作成・更新のたびにスキャンすると、コピー処理が待たされます
- NTFSのMFT（Master File Table）や空き領域の断片化が進むと、さらにI/Oが増えます
- VMの場合、仮想ディスク・コントローラ・共有ストレージの都合でIOPS上限に早々にぶつかります
状況の整理：E→F が8MB/s、もう一方が100KB/s級…何が違う？
提示の状況は次の通りです。
- Eドライブ：約300万ファイル。E→Fのコピーが約8MB/s
- Fドライブ：約200万ファイル。「F側のファイルをFにコピー」が約100KB/s
ここで重要なのが、後者の「F→F」が同一ドライブ内の別フォルダへコピーなのか、記述上の省略でF→別ドライブなのか、という点です。同一ボリューム内のコピーでも、実態は“読み取り＋書き込み＋メタデータ更新”が発生するため、遅くなること自体はあり得ますが、100KB/s級は「どこかが詰まっている」サインです。
| 症状 | 起きやすいボトルネック | 優先して疑うもの |
|---|---|---|
| 数MB/s程度で遅い | 小I/Oの積み重ね（IOPS不足） | robocopy未使用、並列度不足、ストレージIOPS上限 |
| 数十〜数百KB/sまで落ちる | 待ちが常態化（スキャン/断片化/再試行） | ウイルス対策のリアルタイム、断片化、空き容量不足、エラー再試行 |
| 一部フォルダだけ極端に遅い | 権限/圧縮/暗号化/重複排除など | NTFS圧縮/EFS/BitLocker、Dedup、アクセス権継承の複雑化 |
最短で原因に当てる切り分け（やる順番）
コピー元・コピー先が「同じ実体のストレージ」か確認する
Windows上ではC/D/E/Fに見えても、裏側は同一LUN・同一VHDX・同一Datastore上の可能性があります。これが同じだと、結局は同じI/Oプールを奪い合います。さらに同時に別処理（バックアップ、スナップショット、ウイルススキャン、インデックス作成）が走っていれば一気に悪化します。
“遅い時”の待ち先を見る（ディスクなのかCPUなのか）
次のどれが増えているかで、対策が変わります。
| 見るもの | 場所 | 増えていたら |
|---|---|---|
| ディスクのアクティブ時間が常に高い／キューが長い | リソースモニター / パフォーマンスモニター | IOPS不足・断片化・ストレージ過負荷。並列度調整やストレージ側確認へ |
| CPUが高い（特にAntimalware等） | タスクマネージャー | リアルタイムスキャンが疑い濃厚。除外や一時停止（方針に従う）へ |
| コピーが“止まる→進む”を繰り返す | robocopyログ / イベントログ | エラー再試行、アクセス権、パス長、競合（別プロセス）を疑う |
まず手軽に効く対策：デフラグ（最適化）を“正しく”試す
提示された回答の中核は「Fドライブのデフラグ（最適化）」です。大量小ファイルでは、MFTや空き領域の断片化があると、1ファイル作るたびに余計なI/Oが増え、速度が落ちます。特にHDD系や、空き容量が少ないボリュームでは効きやすいです。
実施前に「分析」で当たりを付ける
いきなり実行せず、まず状態を見てからにすると安全です。
defrag F: /A /V結果に断片化が目立つ、MFT周りの問題が示唆される、空き容量が少ない、といった場合は改善余地があります。
HDD/SSD/共有ストレージで考え方が変わる
| ストレージの傾向 | 推奨アクション | 注意点 |
|---|---|---|
| HDD（物理/仮想問わずHDD相当） | デフラグ実行が効きやすい | 長時間かかることがある。ピーク時間を避ける |
| SSD | 「最適化（TRIM）」中心 | 不要なフルデフラグは避けたいが、状況によりメタデータ改善が効く場合も |
| SAN / 共有ストレージ / 仮想化基盤のストレージ | まずは混雑状況とIOPS上限を確認 | デフラグが“書き込み増”になり悪化する場合も。分析してから |
空き容量が少ないと、デフラグもコピーも不利
小ファイルが数百万あるボリュームでは、空き容量が少ないだけで速度が落ちやすいです。最低でも十分な空き（目安として15〜20%程度）を確保すると改善することがあります。空きが増えると、ファイル配置の自由度が上がり、MFTや空き領域の断片化も抑えやすくなります。
体感が変わりやすい：robocopyで“並列コピー”する
エクスプローラーのコピーは、数百万ファイルだとオーバーヘッドが大きく、途中で遅くなりがちです。速度改善目的なら、まずrobocopyを試す価値があります。特に/MT（マルチスレッド）で並列化すると、環境によって体感が大きく変わります。
定番の基本形（例）
robocopy "E:\source" "F:\dest" /E /MT:32 /R:0 /W:0 /NP /NFL /NDL /LOG+:C:\temp\robocopy.log- /MT:32：並列数。まず16〜64程度で様子見（上げすぎると逆に詰まることもあります）
- /R:0 /W:0：失敗時の無駄な再試行で“見かけの速度”が落ちるのを防ぐ
- /NP /NFL /NDL：進捗・ファイル一覧の表示を減らし、ログ負荷を下げる（管理しやすい）
- /E：サブフォルダ含めてコピー（空フォルダも）
用途別オプションの選び方
| 目的 | おすすめオプション | ポイント |
|---|---|---|
| 初回フルコピーを速くしたい | /MT /R:0 /W:0 /NP | “待ち”を減らして並列化 |
| 差分だけ更新したい | /MIR（または /E + 除外） | 運用に合えば、以降の負荷が激減 |
| 更新日時が揺れる環境 | /FFT | タイムスタンプの丸め差を許容し再コピーを減らす |
| 権限も含めて移行 | /COPY:DATS /DCOPY:T | 権限コピーは重くなりがち。必要性を確認 |
重要：/MTは万能ではありません。ストレージがすでにIOPS飽和している場合、並列を上げるとキューが伸びて逆効果になることがあります。16→32→64のように段階的に試し、リソースモニターでディスクキューの伸び方を見ながら調整すると失敗が減ります。
盲点になりやすい：ウイルス対策（Windows Defender等）のリアルタイムスキャン
数百万ファイルのコピーでは、リアルタイム保護が“ファイル作成のたびに検査”を挟み、速度が極端に落ちることがあります。特に「F→Fで100KB/s級」のような落ち込みは、スキャン待ちが絡んでいることが多いです。
- 対策の王道は、コピー対象フォルダ/拡張子/プロセスの除外（運用ポリシーとセキュリティ要件に従って実施）
- いきなり除外が難しい場合は、まず遅い時間帯だけ一時的に制御し、改善幅を測る（手順と承認が前提）
- 除外の設計は「書き込み先だけ」「バックアップ領域だけ」など範囲を絞ると事故が減ります
“改善したかどうか”が分かりにくい場合は、同じフォルダで小規模サンプル（数万ファイル程度）を作って比較すると判断しやすくなります。
VM/ストレージ側で詰まりやすいポイント（同一ストレージ運用の落とし穴）
C/D/E/Fが同一ストレージプールにある場合、どのドライブで作業しても最終的に同じI/O上限に当たります。特に小ファイルはIOPSが必要なので、帯域（MB/s）が余っていても頭打ちになります。
| チェック項目 | 起きること | 改善の方向性 |
|---|---|---|
| 仮想ディスクがThin（動的拡張） | 拡張やメタ処理で遅延が増える | 可能なら固定（Fixed）や事前拡張を検討 |
| スナップショット/チェックポイントが多い | 書き込みが複雑化し遅くなる | 運用整理（保持期間・統合） |
| 仮想SCSI/コントローラ設定が非最適 | キュー深度が低くIOPSが伸びない | 推奨コントローラ（環境に応じて）へ |
| 同居VMが同じDatastore/LUNを酷使 | 時間帯で速度が激変 | 移動・分散、QoS、メンテ時間の調整 |
| ストレージ側のIOPS制限/ポリシー | 一定以上速度が出ない | 上限引き上げ、ティア変更、キャッシュ増強 |
“F→Fが極端に遅い”ときに効く追加観点
同一ドライブ内コピーなら「空き領域の断片化」と「MFT」を疑う
同一ボリューム内で別フォルダへコピーする場合でも、新規ファイルとして作られるので、空き領域が細切れだと配置が難しくなり、I/Oが増えます。さらにMFTの断片化が進んでいると、ファイル作成そのものが重くなります。
- 空き容量の確保 → 再度defrag分析 → 必要なら最適化
- 特定の巨大フォルダ配下だけ遅いなら、ディレクトリ構造（階層の深さ、1フォルダ内のファイル数）も見直し
NTFSの“余計なメタデータ更新”を減らす（慎重に）
環境によっては、NTFSの8.3短縮名生成や最終アクセス日時更新が、膨大なファイル数で効いてくることがあります。ただし互換性に影響する設定もあるため、変更するなら影響範囲の確認と検証が前提です。
fsutil 8dot3name query F:
fsutil behavior query disablelastaccess変更を検討する場合は、アプリ互換性（古いソフトやバッチ）を必ず確認してください。
圧縮/暗号化/重複排除/インデックスの影響
以下が有効になっていると、コピーでCPUやI/Oが余計にかかる場合があります。
- NTFS圧縮、EFS暗号化、BitLocker
- Windows Searchのインデックス（対象フォルダにより負荷増）
- データ重複排除（環境次第で有利にも不利にも）
根本改善：コピーの“やり方”を変える（小ファイル地獄から脱出）
「数百万ファイルをそのままコピー」は、どうしても時間がかかります。運用要件が許すなら、発想を変えると一気に楽になります。
まとめて1ファイルにして移動（アーカイブ方式）
例えば、更新されない静的データであれば、フォルダ単位でアーカイブ（圧縮または無圧縮）してからコピーし、コピー先で展開する方法が効きます。ネットワークコピーやストレージがIOPS不足の環境で特に有利です。
- コピーは「大きな連続I/O」になり、ストレージが得意な形になる
- 欠点は、展開に時間がかかる、差分更新が難しいこと
“毎回フルコピー”をやめて差分同期に寄せる
定期運用（バックアップ的なコピー）なら、robocopyでミラーリングや差分同期に寄せるだけで、2回目以降の負荷が激減します。
robocopy "F:\data" "F:\data_copy" /MIR /MT:32 /R:0 /W:0 /NP /LOG+:C:\temp\mirror.log注意：/MIRは削除も同期します。誤操作が致命傷になり得るため、運用に組み込む前にテストと保護（世代管理、アクセス権、確認手順）が必須です。
おすすめの実行プラン（“効く順”）
- 現象の言語化：「F→F」は同一ドライブ内か、別ドライブかを確定
- 遅い時の待ち先確認：ディスクキュー、CPU（特にAV）、再試行の有無
- robocopy /MTでコピー：16〜64で調整し、/R:0 /W:0で無駄待ちを削る
- ウイルス対策の影響評価：除外や運用調整で改善幅を確認（ルール遵守）
- defrag（最適化）：defrag /A /Vで状態確認→必要なら実施
- VM/ストレージ側確認：IOPS上限、スナップショット、Thin、同居負荷、コントローラ
- 運用の再設計：差分同期・アーカイブ方式・データ配置見直し
よくある質問
エクスプローラーコピーではダメ？
ダメではありませんが、数百万ファイルになるとオーバーヘッドが大きく、途中で遅くなりやすいです。ログ・再開性・並列化の面でもrobocopyが運用向きです。
デフラグで本当に速くなる？
HDD相当や空き容量が少ないボリュームでは効きやすいです。一方で、共有ストレージやSSDでは効果が限定的だったり、書き込み増で悪化する場合もあるため、まず分析（/A /V）で当たりを付けるのが安全です。
100KB/sみたいな速度は“普通”？
大量小ファイルでは遅くなるのは普通ですが、100KB/s級まで落ちるのは、リアルタイムスキャン、断片化・空き容量不足、再試行（エラー/アクセス拒否）、ストレージ過負荷など、何かしら強いボトルネックがある可能性が高いです。切り分けで“待ち先”を特定すると、最短で改善に近づけます。
まとめ：改善の鍵は「メタデータ負荷」と「IOPS」を意識すること
大量小ファイルのコピー最適化は、単純なMB/s勝負ではありません。ファイル作成回数が膨大になるほど、IOPS・断片化・スキャン・VM/ストレージ構成の影響が露骨に出ます。まずrobocopyの並列化と無駄待ち削減で体感を上げ、次にウイルス対策と断片化を疑い、最後に基盤側（IOPS上限・混雑・仮想ディスク方式）まで踏み込むと、現実的な改善に繋がります。
コメント