みなさん、こんにちは。
Windows環境でファイルをコピーしているとき、「あれ？ データの転送速度が妙に遅いな…」と感じたことはありませんか？ 特に、新しくビルドしたプログラムの実行ファイル（EXE）やライブラリファイル（DLL）をサーバーにデプロイしようとした際、ファイルサイズ自体はそこまで大きくないのに、エクスプローラーの進行バーがピタッと止まってしまうような現象です。
先日、私もまったく同じトラブルに遭遇しました。.NETアプリのEXEやDLLをWindows 11（クライアントPC）からWindows Server 2019（リモートサーバー）にコピーしたところ、転送速度が異常に低下してしまったのです。ファイルは数個、容量も数十メガバイト程度しかないのに、ファイル1つの転送に数分もかかってしまうという、明らかに普通ではない状態でした。
「これはきっと、受け手であるサーバー側のWindows Defender（ウイルス対策機能）が、ネットワーク越しに入ってきたファイルを厳重にチェックしていて重くなっているに違いない！」
そう確信してサーバー側のセキュリティ設定を色々と弄り回したのですが、原因を徹底的に突き詰めていくと、犯人はまったく逆の「送信元のWindows 11（手元のPC）」だったことが判明しました。
今回は、この「Windows間でEXE/DLLをコピーすると異常に遅い問題」の正体について、私が行った検証プロセスと技術的な原因、そして実運用で今すぐ使える4つの解決策を共有します。
ファイル数個のEXE/DLLコピーが異常に遅い？
まずは、今回遭遇したトラブルの具体的なシチュエーションからお話しします。
開発環境であるWindows 11マシン上で、「.NET 8 SDK」を使ってアプリケーションをビルドしました。本番環境（またはテスト環境）へデプロイするために、publish フォルダ内に生成されたEXEファイルと、いくつかのDLLファイルを、ネットワーク経由（ファイル共有 / SMBプロトコル）でWindows Server 2019へエクスプローラーを使ってコピーしようとしたのが始まりです。
ファイルサイズ自体は合計で数十MB程度、ファイル数も片手で数えられるほど。ネットワーク帯域にも余裕がある環境なので、普通なら一瞬、10秒もかからずに「サクッ」と終わるはずの処理です。
しかし、コピーを開始した瞬間にエクスプローラーのプログレスバーの速度が数KB/sまで急降下し、そのままフリーズしたかのように進まなくなってしまいました。タスクマネージャーを見ても、ネットワーク帯域はほとんど使われていません。
「これはサーバー側のセキュリティ機能が、未知のバイナリに対して過剰に反応しているんだな」
そう思った私は、一般的なトラブルシューティング手順に則り、サーバー側の設定変更を試してみました。
- 試したこと①：Windows Server 2019の「コントロールされたフォルダアクセス」をオフにする
- 結果 → 変化なし。相変わらず亀のような速度。
- 結果 → 変化なし。相変わらず亀のような速度。
- 試したこと②：Windows Server 2019の「Microsoft Defender（リアルタイム保護）」をオフにする
- 結果 → これでも改善なし！まったく速度が上がりません。
- 結果 → これでも改善なし！まったく速度が上がりません。
ファイルを受け取ってディスクに書き込む側のセキュリティをこれだけ緩めても状況が変わらないとなると、「OSのネットワークスタックのバグか、あるいはハードウェアの不調か……」と、いよいよ頭を抱えかけました。
犯人は「送信元（クライアント）のDefender」だった
ここで視点を180度変えてみることにしました。
「待てよ、書き込み側（サーバー）が原因じゃないなら、データを読み出している側（手元のPC）に原因があるのでは？」
そこで、送信元であるWindows 11側の「Microsoft Defender（リアルタイム保護）」を一時的にオフにしてみました。ちなみに、先ほどオフにしたサーバー側のDefenderは、比較のために「オン（通常状態）」へと戻してあります。
すると、驚くべき結果が出ました。
「一瞬でコピーが終わった……！」
それまで数分間もプログレスバーが止まっていたのが嘘のように、一撃でコピーが完了したのです。
さらに条件を確定させるため、いくつかのパターンで検証を繰り返しました。その結果がこちらです。
| パターン | 送信元（Win11）の設定 | 受信側（Server）の設定 | コピー速度の結果 |
| パターンA | Defender：オン | Defender：オン | 異常に遅い（数分かかる） |
| パターンB | Defender：オン | Defender：オフ | 異常に遅い（改善せず） |
| パターンC | Defender：オフ | Defender：オン | 爆速（一瞬で完了！） |
| パターンD | Defender：オフ | Defender：オフ | 爆速（一瞬で完了！） |
このマトリクス分析から導き出される結論は、ただ一つしかありません。
Windows間におけるファイルコピーの速度を完全に支配していたのは、受信側（サーバー）の設定ではなく、圧倒的に「送信元側（クライアントPC）のDefender」だったのです。
サーバーのスペックが低いわけでも、ネットワークの経路が細いわけでもなく、自分の手元のマシンのセキュリティ機能がブレーキを全力で踏み込んでいた、というのが事の真相でした。
なぜ「送信元」のDefenderがここまで重いのか？
では、なぜファイルを送信する側のWindows Defenderが、これほどまでにコピー速度に壊滅的な悪影響を与えるのでしょうか？
これには、Windowsにおけるファイルコピーの内部処理と、リアルタイムスキャンが走るタイミングのシステム的な挙動が深く関係しています。
Windowsのエクスプローラーがネットワーク越しにファイルをコピーするとき、内部的には以下のようなステップで処理が進みます。
- 送信元（Windows 11）
エクスプローラーがディスクからファイルデータを「読み出す（Read）」 - 送信元（Windows 11）
【ここが罠】Defenderが読み出されたデータを深くスキャンする（超重い！） - ネットワーク転送
SMBプロトコルを介して、スキャン済みの安全なデータをサーバーへ送信する - 受信側（Windows Server）
送られてきたデータをメモリに受け取り、ディスクに「書き込む（Write）」 - 受信側（Windows Server）
Defenderが書き込まれたデータを軽くスキャンする（または信頼されたセッションとしてほぼスルー）
お分かりいただけたでしょうか。
Windows Defenderのリアルタイム保護は、新しくファイルが「書き込まれる時」だけでなく、ファイルが「読み出される時（開かれる時）」にも強力に作動します。
そして、ファイルコピーにおいて最もCPU負荷が高く、時間の Tolling（消費）が発生する「ディープスキャン（ファイル構造の解析）」は、この読み出し側（送信元）で発生する仕組みになっているのです。
特に「EXE」や「DLL」が狙われる理由
テキストファイル（.txt）や画像ファイル（.png）をコピーするときは、ここまで遅くなりませんよね。なぜEXEやDLLなどの「実行可能ファイル（PEファイル）」だけがターゲットになり、これほど遅くなるのでしょうか。
それは、DefenderにとってEXEやDLLが「最も警戒すべき、かつ解析に時間がかかる対象」だからです。送信元のDefenderは、ファイルが読み出される瞬間に、バックグラウンドで以下のような膨大なチェックを大真面目に走らせています。
- PE（Portable Executable）ヘッダの解析
ファイルの構造が不正でないか、不審なセクションが埋め込まれていないかを精査します。 - メタデータおよびIL（中間言語）の静的解析
特に.NETアプリの場合、マネージドコードのメタデータやILを読み解き、不審な挙動（難読化の有無や、危険なAPIの呼び出しコードなど）がないかをチェックします。 - デジタル署名の確認とハッシュ計算
ファイルに有効な署名があるかを確認し、クラウド上の脅威データベースとファイル全体のハッシュ値を照合します。 - MOTW（Mark of the Web / Zone.Identifier）の付与判断
そのファイルがどこから来たものなのか、転送時にどのようなゾーン識別子を引き継ぐべきかを評価します。
これだけのヘビーな処理を、エクスプローラーが1ファイルずつ読み出すたびに、送信元マシンのCPUとメモリをフル活用して実行しているのです。
しかも、ファイル共有（SMB）を介したコピーでは、データが細切れのブロック単位で要求されることがあるため、スキャンのオーバーヘッドがさらに増幅されます。エクスプローラー側は、Defenderが「よし、このファイルは安全だ！」と太鼓判を押すまで次のブロックの送信を待つため、結果としてプログレスバーが完全に停止してしまうのです。
一方で、受信側（サーバー）のDefenderは、すでに送信元でチェックが終わり、確立されたネットワークセッションを通じて流れてきたデータをただディスクに書き込むだけなので、比較的「軽い簡易スキャン」で済ませます。そのため、サーバー側のセキュリティをいくらオフにしても、速度向上にはほとんど寄与しなかったわけです。
実運用で使える！劇的にコピーを高速化する4つの対策
原因が「送信元のDefenderによる読み出しスキャン」だと分かれば、こちらのものです。実務の現場でこのイライラを解消するための、現実的かつ効果的な対策を4つご紹介します。状況に合わせて使い分けてみてください。
対策1 – ZIPに固めてからコピーする（最も安全で一番オススメ！）
「手元のPCのセキュリティ設定は一切変更したくないし、変更できない権限になっている」という場合に、最も安全で、かつ劇的な効果があるのが「ZIP圧縮」です。
たとえEXEやDLLが数個しかない場合でも、それらを一度ローカルで1つのZIPファイルにまとめてから、ネットワーク経由でサーバーへコピーしてください。これだけで信じられないほど爆速になります。
- Defenderのスキャン回数が「ファイル数分」から「1回（ZIPファイルのみ）」に激減する。
- 内部にある個別のEXE/DLLに対する深い静的解析（メタデータやILの解析）が、圧縮状態のままではスキップされる。
- MOTW（Zone.Identifier）の処理や、SMBのパケット往復回数も最小限に抑えられる。
サーバー側で「解凍（展開）する」というひと手間は増えますが、転送にかかる待機時間は圧倒的に短縮されます。本番環境やステージング環境へのデプロイなどでは、安全性を担保する意味でもこの方法がベストプラクティスと言えます。
対策2 – 送信元（開発環境）のDefenderに「除外設定」を入れる
開発中のアプリケーションを頻繁にビルドし、1日に何度も何度もサーバー環境へコピーしてテストを繰り返すようなデバッグフェーズであれば、毎回ZIPに固めるのは手間でしかありませんよね。
その場合は、送信元マシン（手元のPC）のWindows Defenderに「除外設定」を入れましょう。
具体的な設定手順は以下の通りです。
- Windowsの「設定」>「プライバシーとセキュリティ」>「Windows セキュリティを開く」をクリック。
- 「ウイルスと脅威の防止」を選択し、ウイルスと驚異の防止の設定の「設定の管理」をクリック。
- 下部にある「除外」の項目から「除外の追加または削除」をクリック。
- 「除外の追加 > フォルダー」をクリックし、.NETアプリをビルドしている開発用のローカルワークスペース（フォルダ全体）を除外対象として登録する。
これにより、その除外フォルダ内にあるEXEやDLLが読み出される際、Defenderのスキャンが丸ごとスキップされるようになります。結果として、エクスプローラーでのコピーは一瞬で終わるようになり、開発のテンポが非常に良くなります。ただし、除外フォルダ内に本当に危険なファイルを紛れ込ませないよう、フォルダの管理には十分注意してください。
対策3 – エクスプローラーの代わりに「robocopy」コマンドを使う
Windowsに標準で搭載されている高機能コピーツール「robocopy」を、コマンドプロンプトやPowerShellから使用するのも非常に効果的です。
以下のようなコマンドを叩きます。
robocopy "C:\Your\Development\Publish" "\\YourServer\DeployFolder" /E /MT:8
標準のエクスプローラーによるファイルコピーは、「1ファイルずつ順番に同期を取りながら、画面を更新しつつ進める」というシングルスレッドかつ同期的な挙動をします。そのため、Defenderのスキャン待ちが発生すると全体の処理が完全にストップしてしまいます。
一方、robocopy はマルチスレッド転送（上記の /MT:8 は8スレッドで並列処理するオプション）に対応しており、エクスプローラーよりも効率的なバッファリングと非同期処理を行います。「1ファイルのスキャン待ちのせいで全体がフリーズする」という事態を回避し、バックグラウンドでガシガシ並行してデータを送ってくれるため、これだけでも体感速度が大きく向上します。
対策4 – コピーする瞬間だけ「リアルタイム保護」をオフにする
あまり積極的には推奨できない力技ですが、社内の閉じられた検証環境など、完全に安全性が確保されているネットワークにおいて「今すぐこの大容量のEXE/DLL群をサクッと送りたいんだ！」という緊急時には、前述の送信元のリアルタイム保護を一時的にオフにするのが手っ取り早いです。
ただし、コピー作業が終わったら、必ずリアルタイム保護を「オン」に戻すことを忘れないようにしてください。うっかり戻し忘れると、PC全体が文字通り無防備な状態になってしまうため、あくまで最終手段・自己責任での運用となります。
Windowsのファイルコピーは「送信元」が鍵を握る
今回の検証をまとめると、重要なポイントは以下の3点です。
- EXE/DLLのコピー速度を低下させている主犯は、受信側ではなく「送信元（読み出し側）のWindows Defender」。
- ファイルの読み出し時に、PEヘッダや.NETメタデータの解析、署名チェックなどの「超重いスキャン」が手元で走っている。
- 受信側（サーバー）のセキュリティをどれだけオフにしても、送信元のブレーキが解除されない限りコピー速度は改善しない。
これまでは、ネットワーク経由のファイルコピーが遅いと「サーバーのスペックが低いんじゃないか」「社内LANのどこかのスイッチが詰まっているのではないか」「サーバーのアンチウイルスが過剰反応しているのでは？」と、どうしても「受け手（サーバー側）」の方ばかりを疑ってしまいがちでした。
しかし、Windowsのファイルシステムの設計上、「データを読み出している側に最大の負荷がかかる」というセキュリティの仕組みになっています。
この本質を知っているだけで、無駄なサーバー設定の変更で時間を浪費したり、インフラ担当者に問い合わせて苦労したりすることなく、手元でのZIP圧縮や除外設定といった、的確で効果的なアプローチで即座に問題を解決できるようになります。
特に、日々新しいプログラムをビルドしては環境へ転送している開発者の方や、システム管理者の方は、この挙動に悩まされることが多いかと思います。もしファイルコピーが異常に遅いと思ったら、今回の方法を試してみてください。
本日も最後までお読みいただきありがとうございました。
それでは、よいWindowsライフを！
