1GBの動画はすぐコピーできたのに、合計1GBの写真フォルダーはなかなか終わらない。新しいSSDにしたのに、細かいファイルを移すと転送速度が急に落ちる。
容量が同じなら時間も同じになりそうですが、コピー時間を決めるのは「何バイト運ぶか」だけではなく、「何個のファイルを扱うか」でもあります。
この記事は、Windows 11で写真や資料を外付けドライブ・NASへコピーする一般ユーザー向けの入門です。仕組みを説明したうえで、同じ合計容量のデータを自分で比較する手順を紹介します。2026年9月5日に確認した公式資料に基づく解説で、特定のPCやNASの速度を測定した結果ではありません。
1. 「1GBを運ぶ」と「1万件を処理する」は別の仕事
引っ越しで考えると、荷物の総重量が同じでも、大きな箱一つと、宛名を確認する小包1万個では手間が違います。ファイルにも、中身を運ぶ前後の仕事があります。
flowchart TB
accTitle: 同じ容量でも違うファイルの数
accDescr: 合計1GBのデータでも、一つのファイルと多数のファイルでは管理処理の回数が異なります。
A["合計1GBのデータ"] --> B["大きなファイル1個"]
A --> C["小さなファイル1万個"]
B --> D["ファイル単位の処理が少ない"]
C --> E["ファイル単位の処理を繰り返す"]
図1: バイト数が同じでも、ファイル数まで同じとは限りません。
Microsoftも、多数の小さなファイルをネットワーク越しに順番にコピーする場合、データ転送以外の処理が効き、回線速度を使い切れないことを説明しています。1
もちろん「写真は遅い、動画は速い」という形式別の法則ではありません。数枚の大きな写真と、何万個もの小さな画像では条件が違います。まずフォルダーのプロパティで、合計サイズとファイル数の両方を見てみましょう。比較では「ディスク上のサイズ」ではなく、ファイルの中身の合計バイト数をそろえます。
図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全11件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle
2. コピーでは、中身以外の情報も扱っている
ファイルをコピーするときは、コピー元を開き、コピー先のファイルを作り、中身を読み書きし、必要な情報を設定して閉じます。Windowsのファイルを開く処理では、アクセス権や、ほかの処理と同時に開いてよいかといった条件も扱います。2
名前・サイズ・日時など、ファイルを管理する情報をメタデータと呼びます。たとえばNTFSというファイルシステムは、ファイルごとの管理情報をMFT(マスターファイルテーブル)などに記録します。写真の画素データだけを書けば終わり、という仕組みではありません。3
flowchart TB
accTitle: 一つのファイルをコピーするときの仕事
accDescr: コピー元の読み出しに加え、コピー先の作成や情報の管理、クローズがファイルごとに必要になります。
A["コピー元を開く"] --> B["コピー先を作る"]
B --> C["中身を読み書きする"]
C --> D["情報を整えて閉じる"]
D -.-> E["次のファイルでも繰り返す"]
図2: 概念的な流れです。実際の処理順や並行実行は、コピー方法とファイルシステムによって変わります。
SSDでも、この管理の仕事がなくなるわけではありません。製品の大きな転送速度の数字だけから、1万個のファイルのコピー時間は求められません。また、小さなファイルのコピーをそのまま「すべてランダムI/O」と呼ぶのも乱暴です。読み書きの配置だけでなく、ファイルを扱う処理そのものを分けて考える必要があります。
3. NASでは「相手の返事を待つ時間」も加わる
NASは、ネットワーク経由で使う保存装置です。Windowsの共有フォルダーで使われるSMB(Server Message Block)では、ファイルの操作を相手へ依頼し、相手の処理と応答を待つ場面があります。
flowchart TB
accTitle: ネットワーク越しのファイル操作
accDescr: PCの操作要求はネットワークを通って相手のファイル処理になり、応答がPCへ戻ります。
A["PCからファイル操作を依頼"] --> B["ネットワークを通る"]
B --> C["相手がファイルを処理"]
C --> D["応答がPCへ戻る"]
図3: 一度に運べる量が多いことと、一つの操作の返事が早いことは別です。
道路の車線数に相当するのが帯域、返事が戻るまでの時間に相当するのが遅延です。小さなファイルごとに待つ時間が増えると、帯域に余裕があっても転送量は伸びません。ウイルス対策による検査も、ファイルごとの処理時間に影響する場合があります。1
ただし、ファイル一つにつき必ず一定回数の通信をする、という意味ではありません。SMBには要求をまとめる仕組みがあり、キャッシュや並行処理の条件でも待ち方は変わります。45 家庭内LANと遠隔地の共有フォルダーでも結果は変わります。
数字で考えるための、単純化した例
重なりなく順番に処理すると仮定すると、考え方は次のようになります。
コピー時間 ≒ 合計バイト数 ÷ データ転送速度
+ ファイル数 × 1ファイルあたりの追加時間
これは測定値でも、Windowsの正確な計算式でもありません。 説明用に、データ部分は100MB/秒、追加時間は1ファイルあたり2ミリ秒と仮定します。ここでは1GB=1,000MBです。
1GBのデータ部分は10秒。ファイル1個なら追加は0.002秒ですが、1万個なら20秒となり、合計は約30秒になります。並列化、キャッシュ、CPUやストレージの制約を省いた模型ですが、「同じ容量なのに時間が違う」ことは説明できます。
flowchart TB
accTitle: コピー時間を二つに分けて考える
accDescr: 合計容量から決まる転送時間と、ファイル数に応じて積み上がる追加時間を区別します。
A["合計容量に応じた時間"] --> C["コピー全体の時間"]
B["ファイル数に応じた追加時間"] --> C
図4: ファイル数が増えると、データ量だけでは見えなかった時間が効いてきます。
4. ZIPは「小さくする」だけでなく「一つにまとめる」
ZIPには、データを圧縮する役割と、複数のファイルを一つの入れ物にまとめる役割があります。JPEGはすでに圧縮された形式なので、ZIPにしても容量があまり減らないことがあります。6
それでも、転送時に扱うファイルが1万個から一つになる効果は別にあります。圧縮率だけを見て「ZIPにする意味がなかった」と判断するのは早いのです。
flowchart TB
accTitle: ZIPの二つの役割
accDescr: ZIPにまとめることによるファイル数の変化と、圧縮による容量の変化は別の効果です。
A["写真をZIPにまとめる"] --> B["転送するファイルは一つ"]
A --> C["容量の変化は中身次第"]
図5: ほとんど圧縮できなくても、転送するファイルの個数は減らせます。
ただし、まとめる処理も展開する処理も無料ではありません。写真を通常のフォルダーとして使いたいなら、次の合計で比較します。
ZIP経由の所要時間 = ZIP作成 + ZIP転送 + 展開
ZIPを作る段階で小さなファイルを読み、展開先で再び作成します。ファイルごとの仕事を消すのではなく、その仕事を行う場所と転送の形を変えるのがポイントです。転送前後の処理が重ければ、まとめない方が早いこともあります。1
5. 「どこで展開するか」で、ZIPの効果は変わる
受信側のPCにZIPを送り、そのPCのローカルドライブ上で展開するなら、小さなファイルを一つずつネットワークへ流さずに済みます。Microsoftの案内も、アーカイブは転送先のシステムで展開する方法を挙げています。1
flowchart TB
accTitle: 転送先で展開する場合とPCから共有先へ展開する場合
accDescr: 転送先で内部的に展開する経路と、PCが展開したファイルを共有先へ書き込む経路を区別します。
A["ZIPを転送先へ送る"] --> B["転送先自身で内部に展開"]
C["PCのアプリで展開"] --> D["小さなファイルを共有先へ送る"]
図6: 「ZIPはNAS上にある」だけでは、展開の処理もNAS内で行われるとは限りません。
ここは間違えやすいところです。PCのエクスプローラーでNAS上のZIPを開き、展開先に同じ共有フォルダーを指定すると、PCが展開した小さなファイルをNASへ書くため、細かいネットワーク操作が再び発生します。
NAS自身に対応する展開機能があり、管理画面などからNAS内部で実行できる場合とは区別してください。そうした機能がないなら、「ZIPを送れば解決」とはせず、実際に使う経路全体を測ります。NAS内部への展開とPCのローカルへの展開を比較するなら、最終的にファイルを置く場所が違うことも忘れてはいけません。
6. 同じ1GBで、大・小・ZIPを比べてみる
まずは手持ちの動画と写真で試しても構いません。ただし、内容、ファイル数、圧縮しやすさまで違うので、原因を切り分けたいときは実験用データを使います。以下は速度の測定結果ではなく、読者の環境で行う比較手順です。
用意するのは、大きなファイル1個、小さなファイル1万個、その1万個をまとめた無圧縮ZIPの三つです。AとBの中身の合計はどちらも正確に1,000,000,000バイト。CにはZIPの管理情報が加わるので、ファイルサイズはA・Bと完全には一致しません。
flowchart TB
accTitle: 三種類の比較用データ
accDescr: 同じ合計容量の大きなファイルと小さなファイル群を作り、後者から無圧縮ZIPも作成します。
A["同じ合計1GBを用意"] --> B["1GBのファイル1個"]
A --> C["100KBのファイル1万個"]
C --> D["同じ中身を無圧縮ZIPへ"]
図7: 無圧縮ZIPなら、圧縮率の差とファイル数をまとめる効果を分けて観察しやすくなります。
実験用ファイルを作る(任意)
コマンドを使える方向けです。Windows PowerShell 5.1以降で、ローカルの一時フォルダーに新しい実験用フォルダーを作ります。大きなファイルと小さなファイル群だけで約2GB、ZIP込みで約3GBを使い、転送先にも別途空き容量が必要です。ディスクを満杯にしないよう、コピー元には少なくとも5GB程度の余裕を確保してください。
既存の写真や資料は使いません。疑似乱数のデータを生成するので、動画や写真として開けるファイルではありません。ゼロ埋めデータだけを使ったときの極端な圧縮を避けますが、実際の写真に対する検査やアプリの動作まで再現するものではありません。
$ErrorActionPreference = 'Stop'
$lab = Join-Path ([System.IO.Path]::GetTempPath()) ('copylab-' + [guid]::NewGuid().ToString('N'))
$drive = New-Object System.IO.DriveInfo ([System.IO.Path]::GetPathRoot($lab))
if ($drive.AvailableFreeSpace -lt 5GB) {
throw '実験用ドライブに5GB以上の空き容量を確保してください。'
}
$largeDir = Join-Path $lab 'large'
$smallDir = Join-Path $lab 'small'
[System.IO.Directory]::CreateDirectory($largeDir) | Out-Null
[System.IO.Directory]::CreateDirectory($smallDir) | Out-Null
Write-Host "作成先: $lab"
$fileCount = 10000
$buffer = New-Object byte[] 100000
$random = New-Object System.Random 20260905
$large = [System.IO.File]::Open(
(Join-Path $largeDir 'one.bin'),
[System.IO.FileMode]::CreateNew,
[System.IO.FileAccess]::Write,
[System.IO.FileShare]::None
)
try {
for ($i = 0; $i -lt $fileCount; $i++) {
$random.NextBytes($buffer)
$name = 'part-{0:D5}.bin' -f $i
[System.IO.File]::WriteAllBytes((Join-Path $smallDir $name), $buffer)
$large.Write($buffer, 0, $buffer.Length)
}
}
finally {
$large.Dispose()
}
Write-Host "準備完了。各データ群の中身は $([long]$fileCount * $buffer.Length) バイトです。"
同じバイト列を小分けと一つのファイルの両方へ書きます。続けて、同じPowerShell画面で無圧縮ZIPを作ります。作成時間をここで記録します。NoCompressionは、圧縮せずZIPに格納する指定です。7
$zip = Join-Path $lab 'small.zip'
$watch = [System.Diagnostics.Stopwatch]::StartNew()
Compress-Archive -LiteralPath $smallDir -DestinationPath $zip -CompressionLevel NoCompression
$watch.Stop()
Write-Host "ZIP作成: $($watch.Elapsed.TotalSeconds) 秒"
Write-Host "ZIPのサイズ: $((Get-Item -LiteralPath $zip).Length) バイト"
この手順は、生成した通常ファイル専用です。Compress-Archiveには隠しファイルを無視するなどの制限があるため、大事なフォルダーの完全バックアップへそのまま流用しないでください。7 エラーで止まったらその回を測定に使わず、表示された実験用フォルダーを確認します。後片付けも、自分で作ったフォルダーと確認してから行います。
測る条件をそろえる
コピー元とコピー先の装置、ネットワーク、コピー方法をそろえます。最初は三つともエクスプローラーでコピーし、移動は使いません。コピー先は毎回新しい空のフォルダーにして、既存ファイルのスキップや上書き確認を混ぜないようにします。
flowchart TB
accTitle: 比較条件をそろえる手順
accDescr: コピー経路と方法を固定し、空のコピー先へ順序を入れ替えて複数回コピーし、完了後に内容も確かめます。
A["同じ装置・経路・方法"] --> B["毎回空のコピー先"]
B --> C["順序を変えて複数回測る"]
C --> D["件数と内容も確認"]
図8: コピー済みのファイルがスキップされた時間を、転送が速くなった結果として扱わないようにします。
各ケースをたとえば3回ずつ、順序を入れ替えて測り、中央値とばらつきを記録します。Windowsはファイルをメモリにキャッシュするため、2回目だけ速くなることがあります。新しいコピー先にしても読み取り側のキャッシュは消えません。この手順で分かるのは普段のコピーに近い傾向であって、厳密なキャッシュなしの媒体性能ではありません。5
同じ物理ドライブ内のコピーは読み書きが競合するので、別の装置へのコピーと混ぜません。オンラインのみのクラウドファイルは取得時間が入るため使わず、ウイルス対策や同期などの条件も途中で変えないようにします。
| ケース | 作成時間 | 転送時間 | 展開時間 | 写真群などが使えるまでの合計 |
|---|---|---|---|---|
| A:大きなファイル1個 | 比較用の準備なので除外 | 実測して記録 | 不要 | 転送時間(対照用) |
| B:小さなファイル1万個 | 比較用の準備なので除外 | 実測して記録 | 不要 | 転送時間 |
| C:Bをまとめた無圧縮ZIP | ZIP作成を記録 | 実測して記録 | 必要なら記録 | 作成+転送+展開 |
これは記録用の表で、結果の数値は入れていません。Aは転送の性質を見る対照であり、ファイル構造が違うためBの代用品ではありません。BとCの実用上の比較では、同じファイル群を同じ最終保存先へ置くことをゴールにします。展開場所も必ず記録してください。
コピーや展開の後は件数・合計バイト数を照合し、必要ならハッシュで中身を確認します。確認の読み出しは計測外で行い、次の試行のキャッシュにも影響する点を記録します。コピー画面が閉じるまでの時間は、電源断に耐えられる状態までの時間を測るものではないため、外付け機器を直後に抜く実験もしません。5
7. ZIPにできないときは、少しずつ並列にコピーする
コピー先ですぐ個別ファイルを使いたい、毎回変わったファイルだけ送りたい、といった用途ではZIPにまとめることが向かない場合もあります。Windows標準のrobocopyには、複数ファイルを並列に扱う/MTがあります。89
flowchart TB
accTitle: ファイルごとの待ち時間を並列化する
accDescr: 複数のファイル処理を進めることで、一つのファイルが待っている間に別の転送を進められます。
A["複数ファイルを並行処理"] --> B["ファイルAは応答待ち"]
A --> C["ファイルBは転送中"]
B --> D["待ち時間を重ねる"]
C --> D
図9: 並列化は待ち時間を重ねる方法で、回線やディスク自体を速くするわけではありません。
以下は、先ほど作った$smallDirからコピーする例です。$targetRootだけ、自分が書き込めるコピー先へ変更します。毎回別のコピー先フォルダーを作り、元データやコピー先を削除する指定は使いません。
$targetRoot = '\\NAS\share\CopyLab' # 自分のコピー先へ変更する
$runId = [guid]::NewGuid().ToString('N')
$target = Join-Path $targetRoot ('small-mt8-' + $runId)
$log = Join-Path $lab ('robocopy-' + $runId + '.log')
robocopy $smallDir $target /E /MT:8 /R:1 /W:1 /XJ "/LOG:$log"
$code = $LASTEXITCODE
if ($code -ge 8) {
throw "コピーに失敗がありました。終了コード=$code、ログ=$log"
}
Write-Host "終了コード=$code。ログのコピー件数・失敗件数と、コピー先の内容を確認してください: $log"
/MT:8は8スレッド、/R:1 /W:1は失敗時の再試行回数と待ち秒数、/LOGはログ保存です。robocopyは終了コード1でも正常コピーで、8以上は失敗を含みます。0〜7なら内容確認が不要、という意味ではありません。8
/MT:8は比較の出発点の例で、最適値ではありません。並列数を増やしすぎると相手の負荷が増え、かえって遅くなることもあります。1 同じ方法で/MT:1と/MT:8を比べるなど、一度に変える条件を絞ります。ZIPと並列化を同時に変えた結果から、一方だけの効果を判断しないようにします。
8. 「遅いから故障」と決める前に
多数の小さなファイルだけが遅いのか、大きなファイルも遅いのか。同じファイルをローカルへコピーするとどうか。これを分けると、調べる場所を絞れます。途中から速度が落ちる場合はキャッシュの影響も考えられ、表示速度だけでは原因を特定できません。5
flowchart TB
accTitle: コピーの遅さを切り分ける
accDescr: 小さなファイルだけの遅さと、データの種類に関係なく遅い場合を分けて調べます。
A{"小さなファイルだけ遅い?"} -->|はい| B["ファイル数と待ち時間を見る"]
A -->|いいえ| C["装置・接続・負荷も調べる"]
B --> D["失敗や切断の有無も確認"]
C --> D
図10: 小さなファイルで速度が伸びないことと、コピー失敗や装置の異常は同じ話ではありません。
コピー失敗や接続切断が出る、以前より急に悪化した、といった場合は、ファイル数だけで説明して終わらせません。重要なデータの保全を優先し、ログや装置の状態を確認します。
また、速度を上げるためにウイルス対策を止めたり、SMB署名を無効にしたりすることは勧めません。SMB署名には通信の改ざんなどを防ぐ役割があります。10 管理されたPCでは設定を回避せず、担当者と相談してください。
まとめ
コピー時間には、データの量に応じた時間と、ファイルの数に応じた仕事の両方があります。「1GBだから同じ時間」とは限らないのは、そのためです。
ZIPを試すなら圧縮率だけでなく、作成・転送・展開まで。並列コピーを試すなら、一度に変えるのは並列数だけ。速い装置を買う前に、合計サイズとファイル数を一緒に見ると、今のWindowsで何が起きているかを考えやすくなります。
参考リンク
-
Microsoft Learn, Slow SMB files transfer speed. 多数の小さなファイル、ファイル作成・通信・検査の負担、並列コピーと転送先でのアーカイブ展開について。 ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, CreateFileW function. ファイルを開く・作成する操作、アクセス権と共有モードについて。 ↩
-
Microsoft Learn, Master File Table. NTFSがファイルごとの管理情報を保持する仕組みについて。 ↩
-
Microsoft Open Specifications, Sending Compounded Requests. SMB2で複数の関連操作をまとめて送る仕組みについて。 ↩
-
Microsoft Learn, File Caching. システムファイルキャッシュと、書き込みを遅らせて反映する仕組みについて。 ↩ ↩2 ↩3 ↩4
-
Microsoft Support, Zip and unzip files. ZIPによるファイルの集約と、JPEGは追加圧縮しても小さくなりにくいことについて。 ↩
-
Microsoft Learn, Compress-Archive. NoCompressionの指定、隠しファイルなどの制限について。 ↩ ↩2
-
Microsoft Learn, robocopy. 並列数、再試行、ログ、コピーオプションと終了コードについて。 ↩ ↩2
-
Microsoft Learn, Performance Tuning for SMB File Servers. 小さなファイルのコピーに対するrobocopyの並列化とログ出力について。 ↩
-
Microsoft Learn, SMB signing overview. SMB署名の保護目的と運用上の考え方について。 ↩
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
Windowsの「ハードウェアアクセラレータによるGPUスケジューリング」とは? オンにすると速くなる?
WindowsのハードウェアアクセラレータによるGPUスケジューリング(HAGS)を、一般ユーザー向けに図解します。仕組み、オン・オフの判断、設定が表示されない理由、フレーム生成との関係、安全な比較手順を整理します。
「残り1秒」が終わらないのはなぜ? ── 進捗バーと残り時間の仕組み
残り1秒が長い、99%で止まる、準備中から進まない。その理由を、進捗率の分母、速度の予測、最後の処理、画面更新に分けて解説します。同じ処理を異なる表示で比べるデモ付きです。
WPR/WPA実践 ── 「PC全体が重い」をシステム全体から調べる性能調査入門
「PC全体が重い」「起動が遅い」など、タスクマネージャーでは追えない性能問題は、OS全体のETWトレースを採って読むWPR/WPAで調べられます。wpr.exeでの採取手順から、WPAでのCPU・待ち時間・ディスクI/Oの読み方まで解説します。
Windowsアプリ開発者のためのCPU設定入門:優先度・アフィニティ・Pコア/Eコア
Windowsアプリ開発者向けに、CPU優先度、アフィニティ、Pコア/Eコア、省電力設定、EcoQoS/Efficiency Modeの関係と、性能・応答性・発熱を測る考え方を整理します。
共有フォルダにつながったり、つながらなかったりする理由 ── Kerberos・NTLM・資格情報を切り分ける
共有フォルダに接続できたりできなかったりする原因を、症状とログから切り分けます。IPと名前の違い、アプリだけの失敗、空パスワード、1219、再起動、SMB署名を確認する手順と、結果の読み方をまとめます。
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。
このテーマがつながるサービス
この記事は次のサービスページにつながります。近い入口からご覧ください。
Windowsアプリ開発
業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。
よくある質問
この記事のテーマについて、相談時によくある質問をまとめています。
- 同じ容量なのに写真フォルダーのコピーが遅いのはなぜですか?
- コピーは中身の転送だけではありません。ファイルを作り、情報を管理し、閉じる処理などがファイルごとに発生します。小さなファイルが多数あると、この処理や待ち時間の割合が増えます。写真という形式そのものより、ファイル数と一つあたりの大きさが重要です。
- SSDや高速なLANでも、小さいファイルのコピーは遅くなりますか?
- はい。SSDでもファイル管理の処理は残り、NASなどへのコピーでは通信と相手側の処理を待つ時間も加わります。大きなファイルを連続転送したときの速度と、多数の小さなファイルを処理する速度は別です。
- JPEGをZIPにしても小さくならないなら、まとめる意味はありませんか?
- 容量がほとんど減らなくても、転送するファイルを一つにまとめる効果はあります。ただしZIPの作成と展開にも時間がかかります。展開が必要な用途では、作成・転送・展開の合計時間で比較します。
- ZIPをNASへ送ってから、PCで共有フォルダーに展開しても速くなりますか?
- その方法では展開された小さなファイルをPCからNASへ書き込むため、ネットワーク越しのファイル作成が再び発生します。NAS自身の対応機能で内部に展開する場合とは区別し、展開も含めて測定してください。
- robocopyの並列コピーは増やすほど速くなりますか?
- いいえ。並列化はファイル処理の待ち時間を重ねられる一方、ストレージやNASの負荷も増やします。少ない並列数から同じ条件で比べ、コピーの失敗や取りこぼしもログで確認します。