Windows Server 2012 のファイルサーバーに割り当てたマップドライブ（M: など）から、Windows 10 クライアントでコピーすると途中で「場所が利用できません（Location is not available）」「M:\ は利用できません」と出て失敗する。特に C:\Program Files (x86) へのコピーだけ失敗しやすい――この症状は、ほぼ UAC（ユーザー アカウント制御）の昇格と、マップドライブが“別セッション扱い”になる挙動が原因です。
今回のケースでよくある環境・前提
同じエラー文言でも原因は複数ありますが、次の条件がそろうと「UAC 起因のマップドライブ切断（見えなくなる）問題」が出やすくなります。
| 項目 | 内容（例） | ポイント |
|---|---|---|
| サーバー | Windows Server 2012 Standard（AD／ファイル／プリント兼用） | サーバー側よりも、クライアント側の権限切り替えが主因になりやすい |
| クライアント | Windows 10（ドメイン参加） | UAC 有効＋管理者権限が絡む操作で再現しやすい |
| 共有の参照方法 | ドライブレター（M: など）で複数割り当て | ドライブレターは“ログオンセッション”に依存しやすい |
| 操作 | エクスプローラーでコピー＆貼り付け | 貼り付け先が保護領域だと途中で昇格が発生しやすい |
再現パターン：Downloads は成功するのに Program Files (x86) は失敗する
現場で特に多いのが次の流れです。「ネットワークが不安定なのでは？」と疑われがちですが、貼り付け先によって結果が変わるのが大きなヒントです。
- マップドライブ M:（ファイルサーバー上の共有）からファイルをコピーする
- 貼り付け先が Downloads などユーザープロファイル配下だと、そのまま完了する
- 貼り付け先が C:\Program Files (x86) だと、途中で権限確認（UAC）や保護の処理が入りやすい
- その直後に「場所が利用できません」「M:\ は利用できません」で失敗する
症状の特徴：なぜ「Program Files (x86) だけ」失敗しやすいのか
結論から言うと、Downloads（ユーザープロファイル配下）へのコピーは通常権限のまま実行できる一方、Program Files 配下は保護領域なので、操作の途中で昇格（管理者権限）が絡みやすいためです。昇格が入った瞬間、同じエクスプローラー操作に見えても内部的には「別の権限コンテキスト（別トークン／別ログオンセッション）」で処理され、通常権限で見えていたドライブレター（M:）が昇格側では見えず、「利用できません」になります。
| 貼り付け先 | UAC の関与 | 起こりやすい挙動 | 結果 |
|---|---|---|---|
| Downloads / Desktop / Documents | 基本的に不要 | 同一（通常）権限でコピーが完了 | 成功しやすい |
| C:\Program Files / C:\Program Files (x86) | 必要になりやすい | 途中で昇格が絡み、昇格側で M: が見えない | 失敗しやすい |
| C:\Windows / C:\Windows\System32 | ほぼ必須 | 昇格後にネットワークドライブが消える問題が顕在化 | 失敗しやすい |
根本原因：UAC の昇格で「マップドライブが見えない」仕組み
Windows の UAC が有効な環境で、管理者権限が必要な操作を行うと、Windows は「通常トークン」と「昇格トークン（管理者）」を分けて扱います。このとき、ドライブレターの割り当て（M: など）は、通常トークン側のセッションに紐づくことが多く、昇格トークン側のプロセスから見ると M: が存在しない状態になります。
つまり、エクスプローラーで「M: → Program Files (x86)」のコピーを開始しても、貼り付け先が保護領域のために途中で昇格が必要になると、処理主体が昇格側に切り替わり、そこで M: が見えずにエラーになります。UNC パス（\\server\share）だと安定しやすいのは、ドライブレターという“セッション依存の入口”を避けられるためです。
まずは切り分け：本当に UAC 起因か確認するチェック
原因のあたりが付いていても、運用やポリシー次第で症状が混ざることがあります。以下のチェックで「UAC／昇格とマップドライブの分離」が当たりかどうかを短時間で確認できます。
| チェック項目 | やり方 | 期待する結果 | 示唆 |
|---|---|---|---|
| 管理者として起動した cmd で M: が見えるか | スタート → 「cmd」右クリック → 管理者として実行 → net use | M: が一覧に出ない | UAC 分離が濃厚 |
| 同じ共有を UNC で参照できるか | 管理者 cmd で dir \\server\share | UNC は参照できる | ドライブレターだけが消えている |
| 保護領域以外へのコピーは成功するか | M: → Downloads へコピー | 成功 | 昇格の有無で差が出ている |
| UAC を一時的に無効化すると再現するか | （検証環境のみ）UAC を下げて再テスト | 症状が軽減／消失 | UAC がトリガー |
対処法の優先順位：現場で“事故が少ない”順
この問題は「一発で直す魔法」より、運用として安定する選択を優先した方が後々ラクです。以下は、実務で採用されやすい順に並べています。
| 対処 | おすすめ度 | メリット | デメリット／注意 | 向いているケース |
|---|---|---|---|---|
| UNC パス（\\server\share）を使う | ★★★★★ | 仕組みとして安定。昇格の影響を受けにくい | ドライブレター運用を変える必要 | 運用変更が可能／最短で再発防止したい |
| EnableLinkedConnections を有効化 | ★★★★☆ | ドライブレター運用を維持しやすい | 全端末適用が必要。セキュリティ評価が必要 | どうしてもドライブレターが前提 |
| 昇格側で再マップ（net use） | ★★★☆☆ | 部分的・一時的に回避できる | 手順が増える。人依存になりやすい | 限定ユーザー／限定PCのみ発生 |
| UAC のプロンプト方式の見直し | ★★☆☆☆ | 環境によっては症状が軽くなる | セキュリティとトレードオフ。推奨しづらい | 統制済みで例外的に調整できる |
対処法 1：UNC パスでコピーする（推奨）
最も堅実なのは、ドライブレター（M:）ではなく UNC パスでアクセスすることです。UAC 昇格で「ドライブレターが見えない」問題を根本から回避できます。
エクスプローラーで UNC を使う具体例
- アドレスバーに
\\fileserver01\shareと入力して開く - よく使う共有は「クイックアクセスにピン留め」しておく（ドライブレターより再現性が高い）
- 「ネットワークの場所の追加」を使い、UNC をショートカット化する
「ネットワークの場所の追加」を使う手順（ドライブレター運用の代替）
- エクスプローラーを開き、「PC」を表示する
- 「コンピューター」タブ（または「…」メニュー）から「ネットワークの場所の追加」を実行
- ウィザードで
\\fileserver01\shareを指定し、分かりやすい名前で登録 - 以後は「ネットワークの場所」として参照でき、昇格の影響を受けにくい
robocopy で確実にコピーする例（管理者権限が必要な配置でも安定）
GUI コピーは状況によって権限の切り替わりが発生しやすいので、配置作業としてはコマンドの方が安定します。
robocopy "\\fileserver01\share\app" "C:\Program Files (x86)\YourApp" /E /COPY:DAT /R:2 /W:2ポイントは、コピー元を UNC にすることです。これだけで「M: が消える」影響を受けにくくなります。さらに確実にしたい場合は、コピー作業そのものを管理者として実行（管理者 cmd / PowerShell から実行）し、作業ログを残す運用にするとトラブルシュートが容易です。
対処法 2：EnableLinkedConnections を有効化する
「運用上どうしても M: などのドライブレターが必要」という場合に現実的なのが、EnableLinkedConnections の有効化です。これにより、通常権限で作られたネットワークドライブの接続情報を、昇格側でも参照できるようにします。
設定場所（レジストリ）
以下に DWORD 値を作成します（存在しない場合は新規作成）。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections (DWORD 32-bit) = 1.reg ファイル例（配布しやすい）
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLinkedConnections"=dword:00000001PowerShell で設定する例
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" `
-Name "EnableLinkedConnections" -PropertyType DWord -Value 1 -Force設定後は再起動が必要です。適用確認は「管理者として実行した cmd で net use を見て、M: が表示されるか」で行うのが簡単です。
注意点（セキュリティ／運用）
- UAC の分離を“つなぐ”設定なので、端末のセキュリティポリシーと整合するか確認してください（監査要件がある場合は特に注意）。
- 共有に別資格情報で接続している場合、意図しない資格情報の引き回しや、接続競合が起こることがあります。
- GPO でドライブマッピングしている場合、再起動後の反映タイミング（ログオン時）も考慮します。まずは影響範囲の小さい端末で検証するのが安全です。
対処法 3：昇格側で再マップする（回避策）
EnableLinkedConnections を使えない／UNC 運用にすぐ移れない場合、最小の回避策は「管理者として起動したプロセス側で再度マップする」です。昇格側セッションに M: を作るイメージです。
管理者 cmd での例
net use M: "\\fileserver01\share" /persistent:yesこの状態で、管理者権限が必要なコピー操作（Program Files 配下への配置など）を行うと、M: が見えて成功することがあります。ただし、端末やユーザーごとに手順が分かれやすいので、恒久対策としては推奨度が下がります。
UAC の昇格方式を見直すと改善するケース
環境によっては、UAC のプロンプト方式が「資格情報の入力を要求する」設定になっていると、昇格時に追加のログオンセッションが作られ、マップドライブがより見えなくなることがあります。ポリシーを「同意を求める」方向へ寄せることで、症状が軽くなるケースがあります。
ただし、これは セキュリティ要件と直結します。端末が社内標準のセキュリティベースラインに準拠している場合は、むやみに変更せず、UNC 化や EnableLinkedConnections で解決する方が安全です。
それでも起きるときの“落とし穴”
UAC 起因が大半とはいえ、以下の要素が絡むと再現条件がブレたり、別のエラーが混ざったりします。「対処を入れたのにまだ不安定」というときは、このあたりを順番に潰すと収束が早いです。
同一サーバーへ複数資格情報で接続している
ファイルサーバー 1 台に対して複数のマップドライブを割り当てる運用では、ユーザーが気付かないうちに「別の資格情報」で接続してしまうことがあります。Windows は同一サーバーに対して複数ユーザー名で同時接続できない制約があり、結果として接続が張り替わる／切断されるなど、症状が複雑になります。資格情報マネージャーや net use で、意図しない接続がないか確認してください。
ドライブマッピングの方式（GPO / ログオンスクリプト）
グループポリシーの「ドライブ マップ」やログオンスクリプトで割り当てている場合、再起動直後やネットワーク初期化が遅い端末では、割り当てが遅れてコピー中に切れるように見えることがあります。まずは「ログオン後に M: が確実に張れているか」「切断と再接続が発生していないか」をイベントログや net use で確認してください。
オフラインファイル（同期）や VPN 絡み
オフラインファイル（CSC）や VPN、社外からのリモート接続が絡むと、共有の状態変化で一時的にアクセスできなくなることがあります。ただし「Downloads は成功するのに Program Files (x86) だけ失敗しやすい」という偏りがある場合は、まず UAC 分離を疑うのが近道です。
運用の見直し：Program Files (x86) へ手作業コピーは避ける
最後に重要なポイントです。Program Files (x86) へファイルを“コピー＆貼り付け”で置く運用は、UAC／権限トラブルの温床になりやすいです。可能であれば、配置方法そのものを見直すと再発が激減します。
| やりたいこと | おすすめの配置先 | 理由 |
|---|---|---|
| アプリ本体の配置（共有で配布） | インストーラー（MSI 等）で Program Files へ | 権限・更新・アンインストールが管理しやすい |
| アプリが書き換える設定・データ | %ProgramData% / %AppData% / ユーザープロファイル配下 | 標準ユーザーでも書き込み可能で事故が減る |
| 配布したいだけのツール（ポータブル） | C:\Tools など（ACL を設計して運用） | Program Files を避け、昇格が不要になりやすい |
どうしても Program Files へ置く必要がある場合の現実解
- 配置作業は 管理者権限で実行する仕組み（MSI、配布ツール、管理者用スクリプト）に寄せる
- コピー元は UNC 参照に統一し、ドライブレター依存を減らす
- 更新頻度が高いなら、手作業よりも ソフトウェア配布（GPO、SCCM、Intune など）へ移行する
まとめ：最短で安定させるなら「UNC 化」＋必要なら EnableLinkedConnections
- 「M:\ が利用できません」「場所が利用できません」は、UAC 昇格でドライブレターが見えなくなることが主因になりやすい
- 最も安定するのは、コピー元を UNC パス（\\server\share）に切り替えること
- ドライブレター運用を維持するなら、EnableLinkedConnections を検討（再起動が必要）
- 恒久対策としては、Program Files 配下への手作業コピー運用を減らすのが効果的
コメント