SMB経由でファイルサーバー（Windows Server 2012 R2）へ大量のファイルをコピーすると、転送ダイアログが「99%」のまま固まったように見え、閉じるまで毎回約35秒待たされる──。ネットワークやSMB設定を疑いがちですが、実は“別の場所”で待たされているケースが多々あります。現象の仕組みと、最短で原因を確定する切り分け、現実的な恒久対策をまとめます。
現象の整理：何が「遅い」のかを言語化する
今回の症状は、単純な「転送速度が遅い（スループットが出ない）」とは少し違います。ポイントは、ファイルデータの送信自体は終わっているように見えるのに、最後のひと押しで待たされることです。
| 観測できる挙動 | よくある誤解 | 実際に待っている可能性が高い処理 |
|---|---|---|
| 進捗が99%で止まったまま閉じない | ネットワークが詰まっている／SMBが不安定 | コピー完了後のクローズ処理、メタデータ確定、ロック解放待ち |
| 最終的には閉じるが毎回約35秒かかる | ファイルサイズが大きいから時間がかかる | サイズと無関係な“後処理の待ち”が発生している（スキャンやフック処理など） |
| 問題のファイルを削除して再コピーしても同じ | そのファイルが壊れている | ファイル内容や拡張子・判定ルールに紐づく処理が毎回走っている |
| DirectoryCacheLifetime=0でも改善しない | SMBのキャッシュが原因のはず | ディレクトリキャッシュより後段の処理（スキャン等）がボトルネック |
このパターンで最も多い本命が、ウイルス対策ソフト／EDR等のリアルタイム（オンアクセス）スキャンです。
結論：本命はリアルタイムスキャン（ウイルス対策／EDR）による「クローズ待ち」
ファイルコピーは「データを書き込み終えたら完了」ではありません。ユーザーに見える“転送”が終わった後も、OSやSMBスタック、アプリ（エクスプローラ）側では、次のような後処理が残っています。
- ファイルハンドルのクローズ（CLOSE）
- バッファのフラッシュ、書き込み確定（コミット）
- タイムスタンプや属性、セキュリティ情報の確定
- ディレクトリエントリ更新（一覧や検索で見える状態にする）
この「書き込み直後〜クローズ直前」のタイミングは、セキュリティ製品のリアルタイムスキャンが最も介入しやすい区間です。多くの製品は、ファイルが作成・更新された瞬間にフックして内容を検査し、判定が終わるまでファイルアクセスやロック解放を遅延させることがあります。
結果として、エクスプローラの転送ダイアログは“残り1%”のまま止まって見えますが、実際には「最後の後処理（クローズの完了待ち）」で待たされている、という構図になります。
なぜ「99%」で止まるのか：コピーUIの仕組みを知る
エクスプローラのコピー進捗は、単純に「送ったバイト数」だけで動いているわけではありません。特に多数ファイルのコピーでは、全体の見積もり・ファイル列挙・メタ情報処理なども絡みます。
体感としては、次のようなイメージが近いです。
| 段階 | ユーザーから見える表示 | 裏側で起きやすいこと |
|---|---|---|
| データ転送中 | 0%→98%程度まで順調に進む | SMBでの書き込みが進む（速度はネットワーク・ディスクの影響） |
| 転送完了直後 | 99%付近で止まって見える | クローズ処理、メタデータ確定、セキュリティ製品のスキャン介入 |
| 完全完了 | ダイアログが閉じる | すべてのハンドルが解放され、OSが完了を返す |
つまり「99%」は、ユーザーに見えない“終端処理”が残っているサインになりやすいのです。今回のように「サイズに依存せず」「毎回ほぼ一定時間」「削除しても再現」なら、スループットやSMBキャッシュより、フック系（AV/EDR/DLP等）の待ちを疑うのが近道です。
最短で原因を確定する切り分け：まず“止めて”みる（ただし手順は慎重に）
原因の切り分けで最も効くのは、「セキュリティ製品のリアルタイム機能を一時的に無効化して再現するか」を見ることです。今回のケースも最終的に、ウイルス対策ソフトとEDR系（質問ではEDMと表現）を停止すると症状が消えた、という結末でした。
ただし、停止にはリスクがあります。安全にやるための現実的な手順をまとめます。
切り分け手順（推奨）
- 同一条件のテストデータ（問題が出るファイルを含む）を用意する
- まずはクライアント側（コピー元PC）のリアルタイムスキャンを一時停止し、同じコピーを実施
- 次にサーバー側（ファイルサーバー）のリアルタイムスキャンを一時停止し、同じコピーを実施
- どちらを止めた時に再現しなくなるかで、影響箇所（クライアント／サーバー／両方）を特定する
「サーバー側を止めたら解消」なら、書き込み完了後のサーバー側スキャンが濃厚です。「クライアント側を止めたら解消」なら、ネットワーク共有上の書き込み・検査をクライアント側製品がフックしている可能性があります。両方止めて初めて改善するなら、二重スキャンや、片側はAV・片側はEDR/DLPのように複数レイヤーで待ちが発生していることもあります。
停止テストを実施する際の注意点
- 可能なら検証環境、難しければメンテナンス時間で実施する
- 停止時間は最短（コピー検証の間だけ）にする
- テストが終わったら必ず元に戻す（リアルタイム保護、EDRエージェント、DLP機能など）
- 組織の運用ルール（変更管理、承認）に従う
「何がロックしているか」を可視化する観測ポイント
停止テストで当たりが付いたら、次は「本当にセキュリティ製品がファイルを掴んでいるか」を確認できると、関係者説明や恒久対策の交渉が一気に楽になります。
リソースモニターで関連ハンドルを確認する
Windows標準のリソースモニターでも、どのプロセスがそのファイルを掴んでいるかの手がかりが取れます。
- サーバー側で「リソースモニター」→「CPU」または「ディスク」→「関連付けられたハンドル」
- ファイル名（または共有フォルダ名）で検索
- セキュリティ製品のプロセス（例：Defender系、AVエンジン、EDRセンサー等）が表示されないか確認
もし該当ファイルが表示され、コピー完了直後の約35秒間だけ特定プロセスがハンドルを保持しているようなら、「99%で止まる＝ロック解放待ち」という説明が成立します。
Sysinternals（Handle / Process Explorer）で確度を上げる
より確実に見たい場合は、Microsoft Sysinternalsのツールが定番です。特にHandleやProcess Explorerでファイル名検索をすると、掴んでいるプロセスが一発で見えることがあります。
- コピー中（または99%で止まっている最中）にファイル名で検索
- EDRやAVのサービス名・エージェント名がヒットしないかを見る
運用上、ツール導入が難しければ、停止テスト＋リソースモニターだけでも十分な場合があります。
Procmonで「Close/cleanupが遅い」を証拠化する
さらに踏み込むなら、Process Monitor（Procmon）でファイルI/Oのイベントを追う方法があります。コピー対象パスでフィルタし、クローズ系のイベントに長いDurationが出る、またはセキュリティ製品のプロセスが直後に読み取りを入れている、といった形で裏付けが取れます。
ただしログ量が膨大になりやすいので、対象フォルダでフィルタし、短時間のキャプチャに絞るのが現実的です。
恒久対策：現実的な落としどころは「除外」と「挙動調整」
原因がリアルタイムスキャンだと確定した場合、理想は「スキャンは維持しつつ、コピーの完了を阻害しない設定」に寄せることです。実務では、次の3段階で検討するとスムーズです。
対策の優先順位
- 製品を最新版に更新（エージェント・エンジン・定義ファイル・EDRポリシー含む）
- 除外設定（共有パス／データドライブ／拡張子／プロセスなど）を最小限で入れる
- スキャン方式を調整（書き込み後スキャン、ネットワーク共有のスキャン、スケジュールスキャン寄せ）
製品側の不具合・非効率な判定ルールが原因なら、更新だけで改善することもあります。一方、設計上「書き込み後に必ず検査する」タイプの製品だと、除外または挙動調整が必要になります。
除外設定の代表例（ファイルサーバー向け）
| 除外の種類 | 例 | 効果 | 注意点（落とし穴） |
|---|---|---|---|
| パス除外 | D:\Shares\ / D:\Data\ などデータ用ボリューム配下 | 大量ファイルの書き込み後スキャンを抑制し、クローズ遅延を大幅に減らせる | 除外範囲が広いほどリスク増。運用ルールとセットで設計する |
| 拡張子除外 | .log / .tmp / .bak / 大容量の中間生成物など | 業務上“危険性が低い”データでの遅延を回避しやすい | アーカイブ（.zip等）や実行形式（.exe等）は慎重に |
| プロセス除外 | バックアップソフト、同期ツール、基幹アプリの書き込みプロセス | 特定の大量書き込みワークロードだけを改善できる | プロセス名変更・更新で効かなくなることがある |
| 共有のスキャン設定 | 「ネットワーク共有をスキャンする」機能の見直し | クライアント側の二重スキャンを減らせる | クライアント保護要件と衝突しやすい。設計合意が必要 |
現場で多いのは「ファイルサーバーはサーバー側でスキャンし、クライアント側のネットワーク共有スキャンは抑える（または逆）」という役割分担です。二重スキャンはセキュリティ的に安心に見えますが、実際にはI/O遅延・ロック競合・ユーザー体感劣化を招きやすく、結果として“例外だらけ”になることもあります。どこで何を守るかを決めてから例外を最小化するのが、長期的には安定します。
「書き込み後スキャン」の調整が効くケース
製品によっては、次のような項目が用意されていることがあります。
- ファイル作成直後のスキャンを抑制し、アイドル時・スケジュールで実施する
- 一定サイズ以上のファイルはスキャン方式を変える（延期・分割・優先度調整など）
- ネットワーク共有（SMB）への書き込み時は別ポリシーにする
「ユーザー操作のコピー完了（クローズ）をブロックしない」方向に寄せられると、今回の“35秒待ち”が劇的に改善することがあります。
DirectoryCacheLifetimeはなぜ効かなかったのか
SMBのクライアント側キャッシュ（ディレクトリ情報・ファイル情報など）に関するレジストリとして、次のような値が話題になることがあります。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
DirectoryCacheLifetime
FileInfoCacheLifetime
FileNotFoundCacheLifetimeこれらは「ディレクトリ一覧やファイル情報をどれだけキャッシュするか」に関係し、変更が効く場面もあります。しかし、今回の症状は「コピーの終端で一定時間待つ」タイプで、ディレクトリ一覧が古い／反映が遅いといった類とはズレています。
要するに、DirectoryCacheLifetimeを0にしても“最後にロックが解放されない”問題は別レイヤーなので、改善しなかった、という説明ができます。
「他の原因」の可能性も潰しておく：似た症状との見分け表
切り分けの場では「本当にAV/EDR？」と聞かれることが多いので、似た症状を起こし得る要素と、今回の特徴（サイズ非依存・一定時間・再コピーでも同じ）との相性を整理しておくと説得力が上がります。
| 候補 | 起きやすい症状 | 今回の特徴との一致度 | 簡易チェック |
|---|---|---|---|
| ウイルス対策／EDRのリアルタイムスキャン | コピー終端で待つ、ファイルクローズが遅い、特定拡張子で顕著 | 非常に高い | 一時停止で再現しなくなるか。ハンドル保持プロセスが見えるか |
| ディスクI/O逼迫（サーバー側） | 全体的に転送が遅い、時々詰まる、I/O待ちが増える | 中 | タスクマネージャのディスク使用率、待ち行列、他ジョブ（バックアップ等） |
| ネットワーク品質（遅延・パケットロス） | 転送速度の揺れ、再送、コピー全体が伸びる | 低〜中 | 大きい単一ファイル転送でも遅いか。pingやperfで傾向を見る |
| SMB署名／暗号化の影響 | CPU使用率が上がりスループットが落ちる | 低 | 転送中にCPUが張り付くか。一定の“終端待ち”にはなりにくい |
| インデックス（Windows Search） | 作成直後に負荷が増えることはあるが、毎回一定秒の終端待ちは起きにくい | 低 | インデックス対象か、検索サービスの負荷が高いか |
| クォータ／ファイルスクリーニング（FSRM等） | 特定ファイルで拒否・遅延、イベントログが残ることがある | 中 | ファイル種別で規制していないか。拒否ログや警告が出ていないか |
「サイズに依存しない一定時間」「削除しても同じ」「停止で消える」という3点セットは、やはりリアルタイムスキャン起因の説明が最も筋が通りやすいです。
実務で効く改善の進め方：関係者が納得する形に落とす
ファイルサーバーのコピー遅延は、情シス／サーバー担当だけで完結しないことが多いです。セキュリティチームやベンダーと合意形成し、監査的にも説明できる形にするのが重要です。
合意形成のための材料（用意すると強い）
- 停止テスト前後の再現条件と結果（同一データ、同一経路、同一時間帯）
- 99%で止まっている間に掴んでいるプロセスの証跡（スクリーンショット等）
- 除外を入れた場合の対象範囲とリスク評価（どの共有、どの拡張子、運用でどう担保するか）
- ユーザー影響（待ち時間×回数×利用部門）を簡単に数値化したもの
「遅いから除外して」では通りにくい一方、「完了処理がスキャンでブロックされ、業務上これだけの時間損失が出ている。除外はこの範囲に限定し、代替としてスケジュールスキャンと監視を強化する」のように整理すると、現実的に動きやすくなります。
再発防止チェックリスト
- ファイルサーバーの共有パスは、セキュリティ製品の推奨設定（ファイルサーバー向けプロファイル）に沿っているか
- クライアントとサーバーで二重スキャンになっていないか（ネットワーク共有スキャンの扱い）
- EDR/DLPのポリシーで書き込み後の検査が強すぎないか（隔離・解析待ち・クラウド照会待ち等）
- 大量コピーが発生する業務（移行、アーカイブ、バックアップ、同期）を洗い出し、例外を必要最小限にできているか
- 製品更新後にコピー遅延が再発した場合に備え、検証手順（停止テスト・観測手順）を手順書に残しているか
よくある質問（現場で詰まりやすいポイント）
約35秒という“きれいな固定値”になるのはなぜ？
製品によっては、クラウド照会やサンドボックス解析、ポリシー判定などの内部処理にタイムアウトや待ちキューの制御があり、結果として「一定秒数待ってから解放」という挙動になることがあります。また、複数エンジン（AV＋EDR＋DLP）が直列に介入すると、固定値に見える遅延が出ることもあります。重要なのは、固定値の遅延は“ネットワーク帯域”より“制御処理の待ち”を示唆しやすい点です。
除外を入れるとセキュリティ的に危険では？
無条件に広範囲を除外するのは推奨できません。ただし、ファイルサーバーは役割上「大量データを安全に保管する」ことが目的なので、スキャンを“ゼロにする”のではなく、どこで・いつ・何を検査するかを設計し直すのが現実解です。たとえば「リアルタイムは最小限＋夜間スケジュールスキャン＋EDR監視は継続」のように組み合わせると、業務影響とリスクのバランスを取りやすくなります。
特定のファイルだけ止まりやすいのはなぜ？
拡張子やファイル構造によって、スキャンエンジンが深く解析するもの（圧縮ファイル、Office文書、実行形式、スクリプト等）があります。さらに、内容が似ていると毎回同じルールに引っかかり、同じタイミングで同じ遅延が起きるため、「削除して再コピーしても同じ」になりやすいです。
エクスプローラではなくrobocopyなら回避できる？
UI上の見え方は変わることがありますが、根本原因が「ファイルクローズの完了待ち」なら、ツールを変えても待ちは発生します。逆に、robocopyでも同様の待ちが出るなら、OSや製品がフックしている可能性がより濃厚になります。切り分けには、エクスプローラとrobocopyの両方で同じデータを試すのが有効です。
DirectoryCacheLifetimeを触るのは意味がない？
意味がないわけではありません。ディレクトリ一覧の反映遅延や参照系の挙動で効く場合があります。ただし今回のように「コピー完了間際で一定秒数待つ」タイプには直撃しにくく、優先度は下がります。まずは“どこで待っているか”を特定し、原因レイヤーに合った施策を選ぶ方が早いです。
Windows Server 2012 R2だから起きるの？
特定OS固有の不具合というより、ファイルサーバーという役割と、セキュリティ製品の介入タイミングが噛み合ったときに起きやすい現象です。とはいえ古いOSほど、最新のセキュリティ製品との組み合わせやポリシー更新で予期しない遅延が出ることもあるため、長期的には基盤更改も含めた検討が望ましいです。
まとめ：99%で止まる“最後の35秒”は、SMBより「ロック解放待ち」を疑う
SMB大量コピーで「99%で止まり、閉じるまで毎回約35秒かかる」現象は、転送そのものよりも、コピー完了後のクローズ処理が何かにブロックされているケースが多いです。特に、ウイルス対策ソフト／EDRのリアルタイムスキャンは、書き込み直後に介入してファイルロック解放を遅らせることがあり、今回の症状と非常に整合します。
最短の切り分けは“一時停止で再現が消えるか”を安全に確認すること。原因が確定したら、除外設定やスキャン方式の調整、製品更新を組み合わせ、業務影響を抑えつつセキュリティ要件も満たす形に落としていくのが現実的です。
コメント