VPN で社外からファイルサーバーに接続したとき、「同じ共有フォルダーなのに、UNC パスで開くと速いのに、マップドドライブ（M: など）だと毎回 1〜3 秒固まる」という相談は珍しくありません。特に Windows Server 2016 と Windows 10/11 クライアントの組み合わせでは、ウイルス対策ソフトやオフラインファイルの設定が原因になりやすく、放置すると業務効率に大きく影響します。
マップドドライブだけ遅い現象とは？環境と症状の整理
まずは、典型的なトラブルの状況を整理します。
- 社外から VPN 接続したクライアント PC（Windows 10 / 11）
- 社内のファイルサーバー：Windows Server 2016
- 共有フォルダーをドライブレター
M:としてマッピングして利用 - エクスプローラーで
M:を開くたびに 1〜3 秒以上「固まる」ような遅延 - しかし同じ共有を
\\fs01\clients\...などの UNC パスで開くと即座に表示される - 社内 500 名のうち、およそ 10 名で顕著に体感できるレベル
- 同じサーバー上の別共有（同一サブネット）では問題なし
- クライアント OS / ハードウェア / Windows ビルドはほぼ共通
このように、「一部ユーザー」「特定のマップドドライブだけ」が遅く、UNC パスでは問題が出ない場合、ネットワークやサーバー本体よりもクライアント側の追加ソフトウェアやフィルタードライバーを疑うのが効率的です。
| 切り分けポイント | 状況 | 示唆されること |
|---|---|---|
| UNC パスは速い | 即座に開く | SMB 通信やサーバー負荷は問題薄 |
| マップドドライブだけ遅い | 1〜3 秒フリーズ感 | ドライブレターに関連する処理が疑わしい |
| 一部ユーザーのみ | 10 名程度 | 個別クライアント設定 or ポリシー差異 |
| 他の共有では問題なし | 同じサーバー上 | フォルダー構成・権限・AV の除外設定などの違い |
UNC パスとマップドドライブは本来同じ速度のはず
技術的には、UNC（\\server\share）とマップドドライブ（M: など）は、どちらも内部的には同じ SMB セッションを利用します。単純に「UNC よりマップドドライブが遅くなる」ことは想定されていません。
それでも体感速度に差が出るとき、多くの場合は次のような「ドライブレター単位でフックする仕組み」が関係しています。
- オフラインファイル（クライアント側キャッシュ）
- サードパーティ製ウイルス対策ソフト（リアルタイムスキャン）
- バックアップソフトや DLP 製品などのフィルタードライバー
- エクスプローラーのシェル拡張（コンテキストメニューなど）
- 古いクライアント（SMB 1.0）や特殊な名前解決設定
今回のケースでは、この中でもウイルス対策ソフト（AV）のネットワークドライブ監視機能が、マップドドライブ経由のアクセスだけを遅くしていました。
| 原因候補 | マップドドライブで症状が出やすい理由 |
|---|---|
| ウイルス対策ソフト（リアルタイムスキャン） | 「ドライブレター単位」で監視対象を設定している製品が多く、M: などに対してのみ重い処理を行うことがある |
| オフラインファイル（CSC） | ネットワークドライブに対してキャッシュ・同期処理が走り、遅延やハングのような動作になる |
| バックアップ・DLP 製品 | ファイルオープン時に内容チェックやコピーを挟むため、回線が細い VPN では顕著な遅延になる |
根本原因：ウイルス対策ソフトのネットワークドライブ監視
実際の調査では、クライアント側のウイルス対策ソフトの特定機能が、マップドドライブの I/O をフックしていたことが分かりました。
- リアルタイムスキャンの設定で「ネットワークドライブを含める」が有効
- 特定バージョンのエンジンで、ドライブレター経由の SMB アクセスだけ処理が重い既知の不具合
- UNC パスアクセスは別ルールで扱われており、ほとんどスキャンされていなかった
この状態だと、エクスプローラーで M: を開くたびに、フォルダー内のファイルリストやサムネイル取得のたびに AV が介入し、VPN 越しの遅延も相まって、1〜3 秒以上の待ち時間が発生します。
なぜ UNC パスだけ速くなるのか
「同じ共有なのに、UNC パスでは速い」という現象は、AV の実装によっては以下のような理由で発生します。
- 監視対象の指定方法の違い
「ローカルドライブ」「リムーバブル」「ネットワークドライブ」などの区分があり、ドライブレターに対してだけ厳しめのスキャンが行われる。 - ポリシー上の例外設定
一部の企業環境では、\\fs01\…などの特定パスは例外に設定済みだが、M:は例外に入っていない。 - 古いエンジンの不具合
マップドドライブだけハンドリングが異なり、余分な名前解決やメタデータ取得が発生することがある。
今回の事例でも、AV ベンダーのサポートに問い合わせたところ、リアルタイムスキャンの「ネットワークドライブ監視」を無効化すると即座に症状が消えることが確認でき、これが決定打となりました。
検証手順：AV が原因かどうかを素早く見極める
本番環境のセキュリティを損なわず、最小限の範囲で AV の影響を切り分ける手順の一例を紹介します。
ステップ 1：テスト用クライアントを決める
- 現象が再現しているユーザー PC を 1 台選ぶ
- 情シス・セキュリティ担当が一時的に操作できる状態にしてもらう
- 可能であれば、同条件の正常な PC も 1 台用意し比較する
ステップ 2：ネットワークドライブのみリアルタイムスキャンを一時停止
- AV の管理画面を開く（またはエンドポイント管理サーバーのコンソール）
- 「リアルタイムスキャン」「オンアクセススキャン」などの項目から、
「ネットワークドライブ」「リモート共有」などに該当する設定を探す - その機能だけを一時的にオフにする（全体の保護は維持したまま）
- 設定を適用し、AV サービスが再起動するのを待つ
そのうえで、次のように動作を比較します。
- エクスプローラーで
M:を何度か開閉して、体感速度を確認 \\fs01\clients\...などの UNC パスも同じように開き、比較する
| 変更前 | 変更後（ネットワークドライブのみスキャン停止） | 判断 |
|---|---|---|
| マップドドライブで 1〜3 秒固まる | ほぼ一瞬で開く | AV のネットワークドライブ監視が原因とみなせる |
| 変化なし | 変化なし | 別要因（オフラインファイルや GPO など）を疑う |
ステップ 3：ログとイベントビューアーで確認
より確実にするために、次のようなログも確認しておくと安心です。
- AV のイベントログに「ネットワークドライブのスキャン」「リモートファイルスキャン」の記録が集中していないか
- Windows のイベントビューアー（アプリケーション／システム）に、AV ドライバーやフィルターに関連する警告・エラーが出ていないか
- パフォーマンスモニターで、SMB クライアントの待機時間が AV の動作と連動していないか
恒久対応：安全性を維持しながら高速化する設定例
原因が AV でほぼ確定したら、次は恒久対応です。ただし、単純に「ネットワークドライブのスキャンを全部オフ」はリスクもあるため、以下のようなバランスを取った設定を検討します。
対応パターンごとの比較
| 対応パターン | メリット | 注意点 |
|---|---|---|
| ネットワークドライブ監視を完全オフ | もっとも体感速度が改善しやすい | ファイルサーバー側での AV 保護が必須。社内ポリシーとの整合性確認が必要。 |
| 特定共有フォルダーだけスキャン除外 | 影響範囲を限定できる。重要共有にだけピンポイントで適用可能。 | 除外対象の選定を誤るとリスクが高まる。サーバー側 AV の設定とセットで考える必要。 |
| 拡張子ベースでスキャン除外 | 大きなアーカイブや動画・CAD など、ビジネス上安全と見なせる拡張子のみ除外できる。 | exe / dll / script などの実行ファイル系は必ずスキャン対象に残す。 |
| オンアクセスからオンデマンドスキャンへ切り替え | アクセス時の遅延が減る。夜間スキャンなどと組み合わせやすい。 | リアルタイム性が落ちるため、運用ルール（ダウンロード時や展開時に手動スキャンなど）が必要。 |
AV エンジン・パッチレベルの最新化
特定バージョンの不具合が原因であれば、AV ベンダーがリリースする以下のような更新で解消するケースも多くあります。
- エンジンバージョンの更新（コアコンポーネントのアップデート）
- クライアントモジュールの修正パッチ
- ネットワークドライブ監視に関する既知の不具合の修正
そのため、ベンダーのサポート窓口に「Windows Server 2016 のファイルサーバーで、マップドドライブだけ遅い」「VPN 越しで顕著」などの情報を添えて問い合わせると、具体的な回避策や推奨設定を教えてもらえることがあります。
どうしても無効化できない場合
セキュリティポリシー上、「ネットワークドライブのスキャン無効化は NG」というケースもあるはずです。その場合、次のような代替案を組み合わせます。
- クライアント側のスキャン設定は残したまま、ファイルサーバー側 AV でより厳格なスキャンを実施
- VPN 接続ユーザーには、特定共有のみ UNC パスでのアクセスを推奨する運用に変更する
- 同機能のない、またはネットワークドライブ監視が軽量な別 AV 製品への入れ替えを中長期で検討する
AV で改善しなかった場合の追加切り分けポイント
ネットワークドライブ監視をオフにしても改善しない場合、別の要因を疑う必要があります。代表的なものを挙げます。
IP アドレスでマッピングしてみる
名前解決に時間がかかっている場合、サーバー名ではなく IP アドレスでマッピングすると改善することがあります。
\\10.x.x.x\clients
- IP 指定でマッピングして速くなるなら、DNS / WINS / NetBIOS 解決の遅延が疑わしい
- VPN 接続時のみ遅い場合は、VPN 先の DNS 設定やスプリットトンネル構成も確認する
GPO マッピングと手動マッピングの比較
グループポリシー（GPO）で自動割り当てしているマップドドライブが遅い場合、手動で同じ共有をマッピングして比較します。
- 手動で割り当てたドライブは速い → GPO ログオンスクリプトやスタートアップスクリプトの影響の可能性
- どちらも遅い → GPO 由来ではなく、クライアント共通の別要因（AV / オフラインファイルなど）を疑う
オフラインファイル / クライアント側キャッシュの確認
Windows の「オフラインファイル」機能が有効になっていると、ネットワークドライブに対してもキャッシュや同期処理が発生します。VPN 越しでは特に顕著に効きます。
- コントロールパネルの「同期センター」からオフラインファイルの状態を確認
- 対象共有が自動的にオフライン対象になっていないか確認
- 一時的にオフラインファイルを無効化して動作を比較
フォルダー／ファイル数が極端に多くないか
1 つのフォルダーに数万ファイルが入っていると、エクスプローラーが一覧を取得するだけで時間がかかります。特に、サムネイル表示や詳細表示＋ソート・グループ化などが有効な場合は、ネットワーク越しの負荷が跳ね上がります。
- 1 フォルダーあたりのファイル数を数千程度に抑える
- 古いデータは別のアーカイブ共有に移動する
- ユーザーフォルダーごとに階層を分割し、一覧表示の単位を小さくする
Windows Update / SMB 関連設定の確認
Windows Server 2016 や Windows 10/11 クライアントには、SMB パフォーマンスやネットワークドライブ周りの不具合修正が多く含まれています。
- サーバー・クライアントともに最新の累積更新プログラムを適用する
- 古い SMB 1.0 を使用していないか確認し、可能であれば無効化する
- グループポリシーで SMB 署名や暗号化を過剰に設定しすぎていないか確認する
VPN 環境ならではの注意点
VPN 越しの SMB アクセスは、帯域よりも遅延（レイテンシ）の影響を受けやすく、AV やオフラインファイルのようにファイルオープン時に追加の往復が発生する仕組みがあると、一気に体感速度が悪化します。
| 回線条件 | レイテンシ | AV などの影響 |
|---|---|---|
| 社内 LAN | 1ms 前後 | 多少重いスキャンでも体感しにくい |
| VPN（自宅光回線） | 20〜50ms 程度 | 1 ファイルあたり数回の往復でも、まとめて 1〜2 秒の遅延になりうる |
| 海外拠点など長距離 VPN | 100ms 以上 | フォルダーを開くだけで数秒かかることもあり、設計を根本的に見直す必要 |
そのため、VPN ユーザーが多い環境では、ネットワークドライブのスキャン設定を社内 LAN と同じにするのではなく、VPN 接続時専用の軽量ポリシーを用意するのも有効です。
なぜ一部のユーザーだけ影響を受けるのか
同じファイルサーバーを使っていても、「500 名中 10 名だけ」顕著に遅い、といった偏りが出ることがあります。主な理由は以下の通りです。
- AV ポリシーの適用グループが異なる
管理コンソール上のグループ分けや OU 単位の GPO 適用により、一部ユーザーだけ別ポリシー（ネットワークドライブを厳しくスキャン）が設定されている。 - 特定のユーザーだけ大容量のデータを扱う
設計・開発・動画編集など、一部部署だけ巨大ファイルが多いと、AV スキャン時間の差が極端に出る。 - ホームネットワーク環境の違い
自宅の Wi-Fi 品質やルーター性能に差があり、VPN 越しの遅延が「遅い人」で大きくなっている。 - ローカル PC に別のセキュリティ製品が同居
エンドポイント保護や DLP、クラウドストレージクライアントなど、複数のフィルタードライバーが競合している。
このため、問題が発生しているユーザーの共通点（部署、PC モデル、AV グループ、接続元回線など）を洗い出し、共通の設定差分を特定することが重要です。
トラブルを未然に防ぐための運用チェックリスト
同様のトラブルを再発させないために、次のような運用ルールやチェック項目を用意しておくと安心です。
- AV のポリシー変更時には、VPN ユーザーを含むテストグループで事前検証する
- ファイルサーバー（Windows Server 2016）のパフォーマンス監視を継続し、SMB 関連の異常を早期検知する
- マップドドライブ設定を GPO やログオンスクリプトで集中管理し、ユーザー任せにしない
- 共有フォルダーの設計段階で、1 フォルダーあたりのファイル数を抑えるルールを定める
- VPN 用アーキテクチャ（帯域・遅延・DNS 設定）を定期的に見直す
| チェック項目 | 頻度 | 目的 |
|---|---|---|
| AV ポリシーの変更レビュー | 随時 / 月次 | 意図しないネットワークドライブ監視強化を防ぐ |
| ファイルサーバーの Windows Update 適用状況確認 | 月次 | SMB 関連不具合の早期解消 |
| VPN 利用時の体感速度アンケート | 四半期ごと | 「一部ユーザーだけ遅い」兆候の早期発見 |
| 共有フォルダー構成・容量の棚卸し | 半年〜年次 | フォルダー肥大化による遅延の予防 |
まとめ：UNC とマップドドライブの差は「クライアント側の差」が作る
UNC パス（\\fs01\clients\...）では速いのに、マップドドライブ（M:）だけ遅くなる問題は、本来同じ SMB セッションを使っているはずのところに、クライアント側のウイルス対策ソフトやオフラインファイルなどの「余計なひと手間」が挟まることで発生します。
特に、Windows Server 2016 のファイルサーバーと VPN 接続のクライアントという組み合わせでは、ネットワークドライブ監視の設定ひとつで、フォルダーを開くたびに 1〜3 秒の遅延が出ることも珍しくありません。
ポイントを整理すると次の通りです。
- UNC では速く、マップドドライブだけ遅い場合は、まず AV やオフラインファイルなどクライアント側を疑う
- AV の「ネットワークドライブ／リモート共有のリアルタイムスキャン」を一時停止し、症状が改善するか検証する
- 恒久対応では、共有フォルダー単位・拡張子単位の除外や、オンデマンドスキャンへの切り替えなど、セキュリティとのバランスを取る
- AV が原因でない場合は、IP 指定マッピング、GPO マップの見直し、オフラインファイル無効化、フォルダー構成改善などを順に試す
- 一部ユーザーだけ遅いときは、AV ポリシーグループや利用回線などの共通点を洗い出す
「マップドドライブが遅い」と感じたときは、闇雲にサーバーやネットワークを疑う前に、ここで紹介したような切り分け手順でクライアント側のフィルター処理を確認してみてください。短時間の検証で原因が特定でき、VPN 利用者のストレスを大きく減らせる可能性があります。
コメント