同じ1GBなのに、動画1本より写真フォルダーのコピーが遅いのはなぜ？

同じ1GBでも、ファイルを開く・作る・閉じる仕事の回数によってコピー時間は変わります。ファイル数と待ち時間の仕組みを理解し、ZIPと並列コピーを同じ条件で比較する方法を説明します。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全11件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

問題・質問

1GBの動画はすぐコピーできたのに、合計1GBの写真フォルダーはなかなか終わらない。SSDや高速なLANを使っていても、細かいファイルを移すと表示速度が下がるのはなぜでしょうか。

この記事で答えるのは、「同じ合計容量でもコピー時間が違う理由」と「ZIPにまとめる方法や並列コピーが、自分の環境で役立つかを確かめる方法」です。写真という形式だけで遅さや故障を判断せず、ファイル数と使える状態になるまでの時間を比較します。

対象環境

Windows 11で、ローカルに実体のある写真・資料などの通常ファイルを、外付けドライブやSMB共有のNASへコピーする一般ユーザーを対象にします。NASはネットワーク経由で使う保存装置、SMBはWindowsのファイル共有で使われる通信プロトコルです。

操作例にはエクスプローラー、Windows PowerShell 5.1以降のCompress-Archive、Windows標準のrobocopyを使います。コマンド例を使う場合は、コピー元の読み取り権限、実験用フォルダーとコピー先への作成・書き込み権限が必要です。管理者権限でアクセス制御を回避する手順ではありません。[S7: Compress-Archive] [S9: robocopy]

NAS自身でのZIP展開は、その製品に対応機能があり、利用権限を持つ場合に限ります。サーバー向けのSMB資料は仕組みの根拠として参照しており、すべてのNASに同じ設定や機能があるとみなすものではありません。

2026年9月17日に確認した公式資料に基づく説明です。以下の数値例は仮定による計算、操作は読者の環境で行う確認手順であり、特定のWindows端末・SSD・NASで測定した結果ではありません。オンラインのみのクラウドファイルの取得や、完全バックアップの設計は対象外です。

回答・解決方法

コピー時間を決めるのは合計バイト数だけではありません。ファイルごとの作成・管理・終了処理を多数繰り返すと、中身の転送以外の時間が増えます。SMB共有では相手の処理と応答を待つ時間も影響します。ZIPによる集約やrobocopyの並列化が役立つ場合がありますが、速くなることは保証されません。[S1: Slow SMB files transfer speed]

まず合計サイズとファイル数を確認し、同じ経路・同じ最終保存先で比較します。ZIPは作成・転送・必要な展開の合計、並列コピーは同じデータとオプションで並列数だけを変えた時間を比べます。速度とコピーの成功は、別々に確認してください。

定義

ファイルコピーは、ファイルの中身を別の場所へ書き込むだけでなく、コピー先のファイルを作り、必要な属性や日時などを設定する処理です。この記事では中身の転送と区別して、ファイルを扱うための処理や待ち時間を「ファイル単位の追加時間」と呼びます。[S2: CreateFileW function]

「小さなファイル」は写真という形式の別名ではありません。数枚の大きな写真と、何万個もの小さな画像では条件が異なります。比較するのはフォルダーの「サイズ」に相当する中身の合計バイト数とファイル数で、「ディスク上のサイズ」だけをそろえるのではありません。

引っ越しなら、荷物の総重量が同じでも、大きな箱一つと宛名を確認する小包1万個では手間が違います。同様に、「1GBを運ぶ」と「1万件のファイルを処理する」は別の仕事です。

flowchart TB
    accTitle: 同じ容量でも違うファイルの数
    accDescr: 合計1GBのデータでも、一つのファイルと多数のファイルでは管理処理の回数が異なります。
    A["合計1GBのデータ"] --> B["大きなファイル1個"]
    A --> C["小さなファイル1万個"]
    B --> D["ファイル単位の処理が少ない"]
    C --> E["ファイル単位の処理を繰り返す"]

図1: バイト数が同じでも、ファイル数まで同じとは限りません。

以降の説明用データでは、1GBを1,000,000,000バイト、100KBを100,000バイトとして扱います。Windowsやツールの丸め表示ではなく、比較時には実際のバイト数を記録します。

役割

コピーの目的は、必要なファイル群を目的の場所で使える状態にすることです。転送画面のMB/秒が高くても、ZIPを作る時間や展開する時間が長ければ、その目的に早く到達できるとは限りません。

ZIPは転送するファイルをまとめ、並列コピーは複数のファイル処理の待ち時間を重ねる方法です。どちらも回線やディスク自体を速くするわけではなく、得意な条件が違います。[S1: Slow SMB files transfer speed] [S4: Performance Tuning for SMB File Servers]

flowchart TB
    accTitle: コピー方法を選ぶときのゴール
    accDescr: 同じファイル群を目的の場所へ置き、内容を確認してから使えるまでの時間を比較します。
    A["同じファイル群を目的の場所へ"] --> B["コピーを完了"]
    B --> C["件数・内容を照合"]
    C --> D["使えるまでの時間を比較"]

図2: 方法選びのゴールは、同じファイル群を正しく使える状態にすることです。

大きなファイル1個は、ファイル数による違いを見るための対照です。小さなファイル1万個と構造が異なるので、そのまま実用上の代用品にはなりません。実際の方法選びでは、元のファイル群を同じ最終保存先へ置けることをゴールにします。

構成

中身・管理情報・コピー経路

コピーでは、コピー元を開き、コピー先のファイルを作り、中身を読み書きし、必要な情報を設定して閉じます。Windowsのファイルを開く操作は、アクセス権や、ほかの処理と同時に開いてよいかという共有モードも扱います。[S2: CreateFileW function]

名前・サイズ・日時など、ファイルを管理する情報をメタデータと呼びます。NTFSはファイルごとの管理情報をMFT（マスターファイルテーブル）などに記録します。写真の画素データだけを書けば終わり、という構成ではありません。[S3: Master File Table]

flowchart TB
    accTitle: 一つのファイルをコピーするときの仕事
    accDescr: コピー元の読み出しに加え、コピー先の作成や情報の管理、クローズがファイルごとに必要になります。
    A["コピー元を開く"] --> B["コピー先を作る"]
    B --> C["中身を読み書きする"]
    C --> D["情報を整えて閉じる"]
    D -.-> E["次のファイルでも繰り返す"]

図3: 概念的な流れです。実際の処理順や並行実行は、コピー方法とファイルシステムによって変わります。

SSDでもファイル管理の仕事は残ります。連続転送の大きな速度の数字だけから1万個のコピー時間を求めたり、小さなファイルのコピーをすべてランダムI/Oと呼んだりせず、データ配置とファイル処理の負担を分けて考えます。[S3: Master File Table] [S1: Slow SMB files transfer speed]

仕組み

同じ容量で差が出る仕組みを、応答待ち、ZIPへの集約、展開場所の三つに分けます。

NASでは帯域と応答待ちが別に効く

SMB共有では、PCがファイル操作を要求し、相手のファイルシステムで処理され、その応答が戻るのを待つ場面があります。多数の小さなファイルを順番にコピーすると、データを送る時間よりファイル作成などの割合が増え、回線の帯域を使い切れないことがあります。[S1: Slow SMB files transfer speed]

flowchart TB
    accTitle: ネットワーク越しのファイル操作
    accDescr: PCの操作要求はネットワークを通って相手のファイル処理になり、応答がPCへ戻ります。
    A["PCからファイル操作を依頼"] --> B["ネットワークを通る"]
    B --> C["相手がファイルを処理"]
    C --> D["応答がPCへ戻る"]

図4: 一度に運べる量が多いことと、一つの操作の返事が早いことは別です。

道路の車線数に相当するのが帯域、返事が戻るまでの時間に相当するのが遅延です。ウイルス対策の検査もファイルごとの処理時間に影響する場合があります。[S1: Slow SMB files transfer speed]

ただし、ファイル一つにつき一定回数の通信が必ず発生する、という意味ではありません。SMBには複数の操作要求をまとめる仕組みがあり、キャッシュや並行処理によっても待ち方は変わります。家庭内LANと遠隔地の共有フォルダーを同じ条件として扱わないでください。[S5: Sending Compounded Requests] [S8: File Caching]

ZIPは圧縮と集約を別々に考える

ZIPには、データを圧縮する役割と、複数のファイルを一つの入れ物へまとめる役割があります。JPEGはすでに圧縮された形式なので、ZIPにしても容量があまり減らないことがあります。それでも、転送するファイルを1万個から一つへ減らす効果は別にあります。[S6: Zip and unzip files]

flowchart TB
    accTitle: ZIPの二つの役割
    accDescr: ZIPにまとめることによるファイル数の変化と、圧縮による容量の変化は別の効果です。
    A["写真をZIPにまとめる"] --> B["転送するファイルは一つ"]
    A --> C["容量の変化は中身次第"]

図5: ほとんど圧縮できなくても、転送するファイルの個数は減らせます。

写真を通常のフォルダーとして使うなら、次の合計で比較します。

ZIP経由の所要時間 ＝ ZIP作成 ＋ ZIP転送 ＋ 展開

ZIP作成時には小さなファイルを読み、展開先で再び作成します。ファイルごとの仕事を消すのではなく、その仕事を行う場所と転送の形を変えます。転送前後の処理が重ければ、まとめないほうが早い場合もあります。[S1: Slow SMB files transfer speed]

展開を実行する装置を区別する

受信側のPCへZIPを送り、そのPCのローカルドライブ上で展開すれば、小さなファイルを一つずつネットワーク越しに作る必要はありません。Microsoftも、アーカイブは転送先のシステムで展開し、遠隔から展開しない方法を挙げています。[S1: Slow SMB files transfer speed]

flowchart TB
    accTitle: 転送先で展開する場合とPCから共有先へ展開する場合
    accDescr: 転送先で内部的に展開する経路と、PCが展開したファイルを共有先へ書き込む経路を区別します。
    A["ZIPを転送先へ送る"] --> B["転送先自身で内部に展開"]
    C["PCのアプリで展開"] --> D["小さなファイルを共有先へ送る"]

図6: ZIPがNAS上にあるだけでは、展開処理もNAS内部で行われるとは限りません。

PCのエクスプローラーでNAS上のZIPを開き、同じ共有フォルダーを展開先にすると、PCが展開した小さなファイルをNASへ書き込みます。細かいネットワーク操作が再び発生するため、NAS自身の対応機能で内部に展開する方法とは区別します。

NASに対応機能がなければ、実際に利用できる経路全体を測ります。NAS内部への展開とPCのローカルへの展開は、最終保存先が違うので、同じ仕事の速さとして単純比較できません。

具体例

ここでは、説明用の計算と、手順で作る比較用データを示します。どちらも実機の速度を報告するものではありません。

1GB・1万ファイルの単純化した計算

重なりなく順番に処理すると仮定した、考え方の模型は次のとおりです。Windowsの正確な計算式ではありません。

コピー時間 ≒ 合計バイト数 ÷ データ転送速度
           ＋ ファイル数 × 1ファイルあたりの追加時間

説明用に、データ部分の速度を100MB/秒、追加時間を1ファイルあたり2ミリ秒と仮定します。1GB＝1,000MBなのでデータ部分は10秒です。ファイル1個の追加は0.002秒、1万個では20秒となり、後者の合計は約30秒になります。

flowchart TB
    accTitle: コピー時間を二つに分けて考える
    accDescr: 合計容量から決まる転送時間と、ファイル数に応じて積み上がる追加時間を区別します。
    A["合計容量に応じた時間"] --> C["コピー全体の時間"]
    B["ファイル数に応じた追加時間"] --> C

図7: ファイル数が増えると、データ量だけでは見えなかった時間が効いてきます。

これは仮定から求めた計算値です。並列化、キャッシュ、CPUやストレージの制約を省いているため、実際の装置で30秒になるという予測には使いません。

大きなファイル・小さなファイル群・無圧縮ZIP

比較用データの対応

手持ちの動画と写真でも傾向を見られますが、内容や圧縮しやすさまで異なります。以下の生成手順では同じバイト列を一つのファイルと小分けのファイル群へ書き、さらに後者から無圧縮ZIPを作ります。

flowchart TB
    accTitle: 三種類の比較用データ
    accDescr: 同じ合計容量の大きなファイルと小さなファイル群を作り、後者から無圧縮ZIPも作成します。
    A["同じ合計1GBを用意"] --> B["1GBのファイル1個"]
    A --> C["100KBのファイル1万個"]
    C --> D["同じ中身を無圧縮ZIPへ"]

図8: 無圧縮ZIPで、圧縮率の差とファイル数をまとめる効果を分けて観察します。

AとBの中身の合計は同じですが、CのZIPファイルの大きさまで1,000,000,000バイトになるわけではありません。疑似乱数で作る.binは実際の写真や動画として開けず、写真に対する検査やアプリの動作を再現するデータでもありません。

手順

まずエクスプローラーで比較し、必要な場合だけrobocopyの並列数を比較します。大事な写真や資料ではなく実験用データを使い、コピーと移動を取り違えないでください。

保護機能、SMB署名、同期設定などを途中で変更しません。書き込み権限やNASの操作が管理されている場合は、設定を回避せず担当者に確認します。[S10: SMB signing overview]

同じ合計容量の実験用ファイルを作る

Windows PowerShell 5.1以降を使い、一時フォルダーがローカルドライブを指していることを確認します。AとBで約2GB、ZIP込みで約3GBを使用します。コピー元には少なくとも5GB程度の余裕を取り、コピー先にも試行回数分のコピー・展開用の空き容量を確保してください。以下のPowerShell例は同じ画面で順に実行します。

flowchart TB
    accTitle: 同じバイト列から二つの比較用データを作る
    accDescr: 各回で作る100000バイトの疑似乱数を大きなファイルへ追記し、小さなファイルにも保存します。
    A["100000バイトを生成"] --> B["one.binへ追記"]
    A --> C["別名のpartファイルへ保存"]
    B --> D["1万回繰り返す"]
    C --> D

図9: 同じ生成データを両方へ書くことで、中身の合計バイト数をそろえます。

1. 既存データを使わず、新しい実験用フォルダーで作業することを確認する。

   このコードは一意の名前のcopylabフォルダーを作ります。表示された作成先を記録してください。処理中に同じ手順を重ねて実行せず、エラー時はその回のデータを比較に使いません。

2. 次のコードを実行し、大きなファイルと小さなファイル群を作る。

   $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) バイトです。"
   

3. 準備完了の表示を確認し、largeとsmallの件数・合計サイズを調べる。

   large内のone.binは1,000,000,000バイト、small内の1万ファイルは各100,000バイトです。フォルダーのプロパティなどで中身のバイト数を確認します。完了表示だけでコピー先の正しさまで確認できたとは扱いません。

一つの実験用フォルダーにAとBができます。同じバイト列を一つと小分けの両方へ書いており、どちらのデータ群も1,000,000,000バイトです。ゼロ埋めの極端な圧縮は避けますが、実際の写真群の性能を保証するものではありません。

無圧縮ZIPを作り、作成時間を記録する

直前の生成手順が正常に完了し、同じPowerShell画面に$labと$smallDirが残っていることを確認します。対象は生成した通常ファイルだけです。Compress-Archiveは隠しファイルを無視するなどの制限があるため、重要なフォルダーの完全バックアップへ流用しないでください。

1. 同じPowerShell画面で次のコードを実行する。

   $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) バイト"
   

   NoCompressionは、圧縮せずにZIPへ格納する指定です。アーカイブの管理情報は含まれます。[S7: Compress-Archive]

2. ZIP作成の秒数と、ZIPファイルのバイト数を記録する。

   small.zipができたことを確認します。展開後のファイルはsmallフォルダーの中に入るため、後の件数確認ではそのフォルダー内を比較します。作成が失敗した回は除外し、元の実験用データと空き容量を確認してください。

Bと同じファイル群を入れたCと、ZIP作成時間の記録ができます。A・Bの生成時間は実験準備ですが、ZIP作成はZIP経由の方法に必要な費用として比較に含めます。

同じ経路でコピーし、必要な展開まで測る

コピー元とコピー先の装置、接続、アプリ、同時負荷を固定します。各試行に新しい空のコピー先を用意できる権限と容量が必要です。コピー後の検証は計測の外で行い、同じ最終保存先でBとCを使える状態にすることを比較のゴールにします。

flowchart TB
    accTitle: 比較条件をそろえる手順
    accDescr: コピー経路と方法を固定し、空のコピー先へ順序を入れ替えて複数回コピーし、完了後に内容も確かめます。
    A["同じ装置・経路・方法"] --> B["毎回空のコピー先"]
    B --> C["順序を変えて複数回測る"]
    C --> D["件数と内容も確認"]

図10: コピー済みファイルがスキップされた時間を、転送の高速化と取り違えないようにします。

1. 装置・経路・コピー方法と、展開を実行する装置を記録する。

   同じ物理ドライブ内のコピーと別の装置へのコピーを混ぜません。オンラインのみのクラウドファイルは使わず、ウイルス対策や同期の条件も固定します。NASで展開する機能がない場合は、PCから共有先へ展開する経路として記録します。

2. A・B・Cを一つずつ、エクスプローラーで新しい空のコピー先へコピーする。

   「移動」は使いません。コピー開始から完了表示が閉じるまでを同じ基準で測り、見込みの残り時間や一瞬の表示速度ではなく所要時間を記録します。既存ファイルのスキップや上書き確認が入った回は、同条件の比較に使わないでください。

3. Cを個別ファイルとして使う場合は、展開時間も測る。

   展開が必要な比較では、ZIP作成＋転送＋展開を合計します。ZIPの作成時間は先に測った固定費として各比較に含め、ZIPを何度も再利用する運用は別の条件として記録します。保存先が同じでも、展開処理をPCとNASのどちらで行ったかを省略しません。

4. 順序を入れ替えて各ケースをたとえば3回ずつ測り、中央値とばらつきを記録する。

   新しいコピー先でも、読み取り側のキャッシュは消えません。2回目だけ速くなる場合や、内容確認の読み出しが次の試行へ与える影響も記録します。この手順は普段のコピーに近い傾向を見るもので、厳密なキャッシュなしの媒体性能測定ではありません。[S8: File Caching]

A・B・Cの時間と測定条件が残ります。下の「確認」の記録表で、Aを対照、BとCを同じファイル群の配置方法として比較し、成功した試行だけを速度の判断に使います。

ZIPが向かない場合にrobocopyの並列数を比較する

実験用データを作った同じPowerShell画面を使います。$smallDirがそのデータを指すこと、$labへログを書けること、コピー先の親フォルダーが書き込み可能であることを確認します。元データは残し、毎回新しいコピー先を作ります。/MIR、/PURGE、/MOVEなどの削除を伴う指定は追加しないでください。

flowchart TB
    accTitle: ファイルごとの待ち時間を並列化する
    accDescr: 複数のファイル処理を進めることで、一つのファイルが待っている間に別の転送を進められます。
    A["複数ファイルを並行処理"] --> B["ファイルAは応答待ち"]
    A --> C["ファイルBは転送中"]
    B --> D["待ち時間を重ねる"]
    C --> D

図11: 並列化は待ち時間を重ねる方法で、回線やディスク自体を速くするわけではありません。

1. 個別ファイルをすぐ使う・変更分を繰り返し送るなど、ZIPを使わない目的を確認する。

   robocopyの/MTは複数ファイルを並列に扱います。一つが応答待ちの間に別の転送を進められますが、回線や装置自体の速度は変えません。[S9: robocopy] [S4: Performance Tuning for SMB File Servers]

2. $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"
   

   例示のNAS名と共有名は置き換えます。コマンドを実行する前から完了までの時間を同じ基準で測り、表示されたログの場所と終了コードを保存します。

3. /MT:1と/MT:8を同じ方法で比べ、並列数以外の条件を固定する。

   再実行では毎回新しいGUIDのコピー先とログが作られます。例のsmall-mt8というフォルダー名は識別用なので、/MT:1を試す際はその名前もsmall-mt1へ直すと記録を区別できます。ZIP化と並列化を同時に変えて、一方だけの効果を判断しないでください。

   /MT:8は比較の出発点で、最適値ではありません。多すぎる並列数は相手の負荷を増やし、遅くなる場合があります。エラーが出た回を高速化の成功として扱わず、ログと内容を確認します。[S1: Slow SMB files transfer speed]

同じBのファイル群について、並列数別の時間・ログ・内容確認結果が残ります。8以上の終了コードは失敗を含むためコードが停止しますが、0～7でも次の確認は必要です。

確認

完了の判定は「内容がそろったこと」と「同条件で使えるまでの時間が短くなったこと」の二つに分けます。コピー終了の表示や終了コードだけを、完全性の確認の代わりにしません。

件数・内容・コマンドの結果を照合する

期待する内容と失敗時の戻り先

件数とサイズが同じでも中身の同一性までは証明できません。必要ならコピー元とコピー先の対応するファイルのハッシュを計測外で照合します。確認の読み出しは次回のキャッシュにも影響するので、実施のタイミングを記録してください。

flowchart TB
    accTitle: 時間を比べる前の内容確認
    accDescr: 件数とサイズを確認し、必要に応じてハッシュも照合して、不一致や失敗がある試行を高速化の成功として扱わない流れです。
    A["件数・サイズを確認"] --> B{"一致する？"}
    B -->|はい| C["必要ならハッシュも照合"]
    B -->|いいえ| D["その回を除外して調べる"]
    C --> E{"不一致や失敗がない？"}
    E -->|はい| F["同条件の時間を比較"]
    E -->|いいえ| D

図12: 表示上の速さとコピー内容の正しさは、別々に確認します。

robocopyの指定と終了コード

オプションと終了コードはMicrosoftのrobocopy資料で確認できます。既定のコピー対象はデータ・属性・日時で、ACLなどを含む完全バックアップの例ではありません。[S9: robocopy]

実測値を記録する

結果を埋めるための表

次の表には結果の数値を入れていません。各試行の条件・順序・展開場所・エラーの有無を添え、中央値だけでなく生の時間とばらつきも残します。

BとCは、同じファイル群が同じ最終保存先で利用できる条件で判断します。単にZIPを保管する運用では展開不要ですが、個別ファイルを使う場合とは別条件です。数回の結果が重なるなら、誤差を超えて速くなったとは断定しません。

遅さと失敗を切り分ける

多数の小さなファイルだけが遅いのか、大きなファイルも遅いのか、同じファイルをローカルへコピーするとどうかを分けます。途中から速度が落ちる場合にはキャッシュも影響し、表示速度だけでは原因を特定できません。[S8: File Caching] [S1: Slow SMB files transfer speed]

flowchart TB
    accTitle: コピーの遅さを切り分ける
    accDescr: 小さなファイルだけの遅さと、データの種類に関係なく遅い場合を分けて調べます。
    A{"小さなファイルだけ遅い？"} -->|はい| B["ファイル数と待ち時間を見る"]
    A -->|いいえ| C["装置・接続・負荷も調べる"]
    B --> D["失敗や切断の有無も確認"]
    C --> D

図13: 小さなファイルで速度が伸びないことと、コピー失敗や装置の異常は同じ話ではありません。

コピー失敗・接続切断が出る、以前より急に悪化した場合は、ファイル数だけで説明して終わらせません。比較を中断し、重要なデータの保全を優先して、ログ・接続・空き容量・装置の状態を確認します。管理された環境では担当者へ条件とログを渡します。

後片付けは、表示されたcopylabフォルダーと各試行のコピー先が自分で作った実験用データだと確認してから行います。自動削除コマンドは示しません。元の写真・資料を削除しないでください。

制約

この比較で分かることと分からないこと

この説明はファイル数が時間へ影響する仕組みを示すもので、読者の装置の根本原因を確定した診断ではありません。数値例は仮定であり、比較手順も実測済みの結果ではありません。ZIPや並列数の変更が必ず速くなるとは保証しません。

新しい空のコピー先を使っても、OSの読み取りキャッシュや装置側の状態は統一されません。コピー画面が閉じるまでの時間は、電源断に耐えられる状態までの時間を測るものでもありません。外付け機器を直後に抜く実験は行わず、通常の安全な取り外しを使います。[S8: File Caching]

バックアップと保護機能は別の要件

生成した.binと無圧縮ZIPは比較用です。Compress-Archiveには隠しファイルを無視するなどの制限があり、通常のrobocopy指定もすべての属性・権限を保存するものではありません。重要なデータの完全バックアップを、この速度比較だけで設計しないでください。[S7: Compress-Archive] [S9: robocopy]

速度向上のためにウイルス対策を止めたり、SMB署名を無効にしたりする手順は勧めません。SMB署名は通信の改ざんなどから保護する機能です。管理されたPCの設定を回避せず、担当者と相談してください。[S10: SMB signing overview]

速い装置を買う前に、合計サイズとファイル数、実際のコピー経路、使えるまでの合計時間を一緒に見ることが出発点です。改善策の採否と、コピー内容が正しいかという確認を切り離さずに判断します。

参考資料

2026年9月17日確認。各資料が支える内容を併記します。サーバー向け資料の設定例を、そのまま一般ユーザーやすべてのNASへ適用するものではありません。

[S1] Microsoft Learn, Slow SMB files transfer speed。多数の小さなファイル、ファイル作成・通信・検査の負担、並列コピーと転送先でのアーカイブ展開について。

[S2] Microsoft Learn, CreateFileW function。ファイルを開く・作成する操作、アクセス権と共有モードについて。

[S3] Microsoft Learn, Master File Table。NTFSがファイルごとの管理情報を保持する仕組みについて。

[S4] Microsoft Learn, Performance Tuning for SMB File Servers。小さなファイルのコピーに対するrobocopyの並列化とログ出力について。

[S5] Microsoft Open Specifications, Sending Compounded Requests。SMB2で複数の関連操作をまとめて送る仕組みについて。

[S6] Microsoft Support, Zip and unzip files。ZIPによるファイルの集約と、JPEGは追加圧縮しても小さくなりにくいことについて。

[S7] Microsoft Learn, Compress-Archive。NoCompressionの指定、隠しファイルなどの制限があることについて。

[S8] Microsoft Learn, File Caching。システムファイルキャッシュと、書き込みを遅らせて反映する仕組みについて。

[S9] Microsoft Learn, robocopy。並列数、再試行、ログ、コピーオプションと終了コードについて。

[S10] Microsoft Learn, SMB signing overview。SMB署名の保護目的と運用上の考え方について。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

同じ容量なのに写真フォルダーのコピーが遅いのはなぜですか？

コピーは中身の転送だけではありません。ファイルを作り、情報を管理し、閉じる処理などがファイルごとに発生します。小さなファイルが多数あると、この処理や待ち時間の割合が増えます。写真という形式そのものより、ファイル数と一つあたりの大きさが重要です。

SSDや高速なLANでも、小さいファイルのコピーは遅くなりますか？

はい。SSDでもファイル管理の処理は残り、NASなどへのコピーでは通信と相手側の処理を待つ時間も加わります。大きなファイルを連続転送したときの速度と、多数の小さなファイルを処理する速度は別です。

JPEGをZIPにしても小さくならないなら、まとめる意味はありませんか？

容量がほとんど減らなくても、転送するファイルを一つにまとめる効果はあります。ただしZIPの作成と展開にも時間がかかります。展開が必要な用途では、作成・転送・展開の合計時間で比較します。

ZIPをNASへ送ってから、PCで共有フォルダーに展開しても速くなりますか？

その方法では展開された小さなファイルをPCからNASへ書き込むため、ネットワーク越しのファイル作成が再び発生します。NAS自身の対応機能で内部に展開する場合とは区別し、展開も含めて測定してください。

robocopyの並列コピーは増やすほど速くなりますか？

いいえ。並列化はファイル処理の待ち時間を重ねられる一方、ストレージやNASの負荷も増やします。少ない並列数から同じ条件で比べ、コピーの失敗や取りこぼしもログで確認します。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。