Windows10でC$共有にアクセスできない原因と解決策｜管理共有・UAC・SMB・ファイアウォール

Windows 10 で \\PC名\C$ にアクセスできないと、リモート保守・ログ回収・一括配布などの作業が止まってしまいます。この記事では「管理共有（C$）」の前提を整理し、権限・UAC・共有設定・ファイアウォール・サービスまで、現場で切り分けしやすい順に対処法をまとめます。

起きている症状の整理（今回のケース）

まずは状況を言語化して、切り分けの方向を決めます。ここでは次のようなケースを想定します。

• OS：Windows 10（例：1909）
• エクスプローラーや「ファイル名を指定して実行」から \\computername\C$ を開こうとするとエラーになる
• 表示例：「Windows は \\computername\C$ にアクセスできません。名前の綴りを確認してください…」など
• 対象PCはオンラインのはず（ただし確証がない）

このメッセージは「ネットワークが悪い」とも「権限が足りない」とも読めるため、通信（SMB到達性）と認証・権限（管理共有の条件）を分けて確認するのが最短です。

そもそも C$（管理共有）とは何か

C$ は Windows が自動的に作成する「管理共有（Administrative Share）」の一種で、Cドライブ直下へリモートからアクセスするために使われます。代表的な管理共有は次のとおりです。

共有名	中身	用途の例
C$ / D$ など	各ドライブのルート	ファイル回収、配布、リモート保守
ADMIN$	Windows フォルダー（例：C:\Windows）	管理用ツールの配置、ログ確認
IPC$	通信のための特殊共有	認証の試験、列挙（net view など）の前段

重要なのは、管理共有は「便利だから誰でも使える共有」ではなく、管理者向けに意図的に制限された入口だという点です。つまり、C$ に入れないときは「権限が足りない」か「そもそもSMBでつながっていない」のどちらか（または両方）であることがほとんどです。

最初に結論：よくある原因トップ3

現場で特に多いのは次の3つです。この記事でも、この順番で深掘りします。

1. 接続に使っているユーザーが対象PCの管理者ではない
2. UACのリモート制限でローカル管理者が“権限フィルタリング”されている（LocalAccountTokenFilterPolicy）
3. 共有機能（ネットワーク探索／ファイルとプリンターの共有）が無効、またはファイアウォールでSMBが遮断されている

まずは通信確認：PCは本当に到達できているか（SMB 445番）

「オンラインのはず」という前提が崩れていると、どれだけ権限を直しても解決しません。名前解決 → 疎通 → SMBポートの順で確認します。PowerShell が使えるなら次が手早いです。

# 名前解決（DNS/NetBIOS）と疎通
Test-NetConnection -ComputerName <ターゲットPC名>

# SMB(445)の到達性

Test-NetConnection -ComputerName <ターゲットPC名> -CommonTCPPort SMB

# 共有の列挙（応答があるか）

net.exe view \<ターゲットPC名>

結果の読み方はシンプルです。

確認結果	意味	次に疑うポイント
Test-NetConnection が失敗	名前解決・疎通・経路の問題	DNS/WINS、同一セグメント、VPN、ルーティング、端末がスリープ
SMB(445)のみ失敗	SMBが遮断されている	Windowsファイアウォール、NW機器のACL、セキュリティ製品
net view が「アクセス拒否」	通信はできるが認証が通っていない/列挙が制限	資格情報、権限、UAC、ポリシー
ここまで全部成功するのに C$ だけ失敗	管理共有特有の条件で落ちている可能性が高い	管理者権限、UACのリモート制限、管理共有無効化

原因：接続ユーザーが管理者でないと C$ は開けない

C$ や ADMIN$ などの管理共有は、接続してくるユーザーが対象PCのローカル Administrators グループのメンバーであることが基本条件です。ここが満たせていないと、C$ に入れません。

ドメイン参加PCの場合

対象PCのローカル Administrators に、接続に使うドメインユーザー（またはそのユーザーが所属するドメイングループ）が含まれている必要があります。現場では、ヘルプデスク用の「端末管理者グループ」を作って配布するケースが多いです。

ワークグループの場合

ワークグループ環境では、対象PC上に存在するローカル管理者アカウントで接続するのが基本です。実務では次のどちらかが多いです。

• 対象PCのローカル管理者（例：PC名\Administrator）で接続
• 接続元PCにも同名・同パスワードのローカル管理者を用意して接続（資格情報の手間を減らす）

資格情報を明示して接続する（失敗の再現と切り分けに有効）

エクスプローラーでのアクセスは、既存の資格情報（キャッシュ）が影響して原因が見えにくいことがあります。コマンドで誰として接続しているかを固定すると、切り分けが速くなります。

:: いったん既存の接続（セッション）を切る
net use \\<ターゲットPC名>\* /delete /y

:: 資格情報を指定して C$ に接続（パスワード入力あり）
net use \<ターゲットPC名>\C$ /user:<ターゲットPC名><管理者ユーザー> *

ドメインなら /user:DOMAIN\user を使います。ここで「システム エラー 5（アクセスが拒否されました）」なら権限不足、「システム エラー 53（ネットワーク パスが見つかりません）」なら通信/名前解決の線が濃くなります。

対象PC側で管理者グループを確認する（GUI/コマンド）

可能なら対象PC側で、接続に使っているユーザーが Administrators に入っているかを確認します。

• GUI：コンピューターの管理 → ローカル ユーザーとグループ → グループ → Administrators
• PowerShell：Get-LocalGroupMember -Group "Administrators"（Windows 10 Pro など）
• コマンド：net localgroup administrators

原因：UACのリモート制限でローカル管理者が絞られる

ここが落とし穴になりやすいポイントです。Windows では、ローカルアカウントで管理者に属していても、リモートからのアクセスでは管理者権限が“フィルタリング”される動作があります（UACのリモート制限）。

結果として、

• 対象PC上では Administrators に入っている
• それでも \\computername\C$ が「アクセスが拒否されました」になる

という状況が起きます。ドメインアカウントで成功するのに、ローカル管理者で失敗する場合は特に疑います。

回避策：LocalAccountTokenFilterPolicy を設定する

対処としてよく使われるのが、対象PC（＝アクセスされる側）に対して LocalAccountTokenFilterPolicy=1 を設定する方法です。これにより、ローカル管理者でのリモート接続時にもフルの管理者トークンが使われ、管理共有にアクセスできるようになります。

項目	内容
場所	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
値名	LocalAccountTokenFilterPolicy（DWORD 32ビット）
設定値	1（フィルタリング無効化）

GUIでレジストリエディタを触れるならそれでもOKですが、作業手順のブレを減らすならコマンドでの設定が確実です。

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

反映後は再起動が確実です（少なくとも再ログオン）。

セキュリティ上の注意点（必ず理解してから適用）

この設定は、UACによる保護の一部を弱める方向に働きます。つまり「ローカル管理者でのリモート操作が通りやすくなる」反面、攻撃者にとっても都合が良くなる可能性があります。運用としては次を意識してください。

• 社内LANなど信頼できるネットワークに限定して使う（公衆Wi-Fiや不特定なセグメントは避ける）
• 可能ならドメインアカウント＋最小権限のグループで管理し、ローカル管理者の横展開を避ける
• 必要がなくなったら値を戻す（0にする、または値を削除する）
• 管理共有を使う運用自体を見直し、PowerShell Remoting（WinRM）や管理ツールに寄せる

原因：共有機能が無効（ネットワーク探索／ファイルとプリンターの共有）

通信も認証も合っていそうなのに「アクセスが拒否されました」になる場合、共有機能そのものがオフになっているケースがあります。特に、PCのネットワークプロファイル（パブリック/プライベート/ドメイン）ごとに設定が分かれるため、VPNやWi-Fi切り替えで意図せず変わっていることがあります。

確認手順（対象PC側）

1. コントロール パネル → ネットワークと共有センター
2. 左メニュー「共有の詳細設定の変更」
3. 現在のプロファイル（プライベート／ドメインなど）で次を確認
   • 「ネットワーク探索を有効にする」
   • 「ファイルとプリンターの共有を有効にする」

ここが無効だと、C$ を含む共有への到達が阻害されることがあります。設定を有効にしたら、改めて \\computername\C$ を試します。

ここまでで直らないときの追加チェック（現場で刺さる補足）

上の3つで大半は解決しますが、それでもダメな場合は「C$が存在しない」「SMBは開いているがポリシーで弾かれている」「名前解決の罠」のようなケースが残ります。次の観点で潰していきます。

書式ミスと名前解決（意外と多い）

• バックスラッシュは2本：\\computername\C$（1本だと別物です）
• PC名で失敗するなら IPアドレス指定：\\192.168.x.x\C$
• DNS確認：ping computername、nslookup computername、PowerShellなら Resolve-DnsName

ファイアウォールで SMB がブロックされていないか

管理共有は SMB（主に TCP 445）を使います。通信確認で 445 が閉じているなら、まずは対象PCの Windows Defender ファイアウォール設定を疑います。

確認ポイント	代表ルール名（表示）	補足
受信が許可されているか	ファイルとプリンターの共有（SMB-In）	プロファイル（ドメイン/プライベート/パブリック）に注意
共有の列挙・名前解決	ネットワーク探索（NB-Name-In など）	環境により不要な場合もあります

PowerShell での確認例です（表示名は環境により差があります）。

# 「ファイルとプリンターの共有」グループのルールを確認
Get-NetFirewallRule -DisplayGroup "ファイルとプリンターの共有" |
  Select-Object DisplayName, Enabled, Profile, Direction, Action

「Server（LanmanServer）」サービスが起動しているか

共有を提供する側（対象PC）で Server サービスが停止していると、共有には入れません。セキュリティ製品や最適化ツールの影響で止まっていることもあります。

Get-Service -Name LanmanServer

sc query lanmanserver

管理共有が無効化されていないか（AutoShareWks）

企業のハードニングや一部のチューニングで、そもそも管理共有が作られない設定になっていることがあります。この場合、どれだけ権限を整えても 「共有が存在しない」 ため接続できません。

対象PCで次のレジストリ値を確認します（存在しない＝既定動作のこともあります）。

項目	内容	意味
場所	HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters	SMBサーバー設定
値名	AutoShareWks（DWORD）	0だと管理共有を作らない方向

「C$が見えない／作られていない」疑いがあるときは、net share で共有一覧を確認すると判断が早いです。

net share

ローカル セキュリティ ポリシーで“ネットワークからのアクセス”が拒否されていないか

Windows 10 Pro などでは、ローカルセキュリティポリシーでネットワークアクセスを制限できます。次の設定が強化されていると、管理共有を含めたネットワークアクセスが失敗する場合があります。

• 「このコンピューターへネットワークからアクセス」
• 「このコンピューターへのネットワークからのアクセスを拒否」
• 「ネットワーク アクセス: ローカル アカウントの共有とセキュリティ モデル」（Guestのみ になっていないか）

確認場所は secpol.msc → ローカル ポリシー → ユーザー権利の割り当て／セキュリティ オプションです。ドメイン配下ならグループポリシーの可能性もあるため、変更前に適用元を確認してください。

「C$ だけ」問題かどうかを切り分ける（テスト共有を作る）

ネットワークが不安定なのか、C$固有の権限問題なのかを分けるには、対象PCで一時的にテスト共有を作るのが効果的です。

1. 対象PCで C:\TempShareTest のようなフォルダーを作成
2. 共有を作成し、共有権限に Everyone（読み取り）を付与（社内の安全な範囲で短時間のみ）
3. 接続元から \\computername\TempShareTest を開く

テスト共有には入れるのに C$ だけ入れないなら、管理共有の条件（管理者/UAC/ポリシー）に絞って調べられます。

症状から原因を当てる早見表（エラー別）

最後に、現場で問い合わせが来たときに使いやすいよう、エラーの傾向と当たりをまとめます。

よくある表示	原因の当たり	まず見るポイント	対処の方向性
「名前の綴りを確認…」	名前解決/到達性/パス誤り	\\ の本数、IP指定、Test-NetConnection	DNS/ルーティング/VPN/端末スリープを解消
「アクセスが拒否されました」	権限不足、UACリモート制限	net use の結果、Administrators、LocalAccountTokenFilterPolicy	管理者で接続、UAC設定見直し
資格情報の入力が何度も出る	認証失敗（別アカウントで接続済み含む）	net use で既存接続を削除、資格情報マネージャー	正しいユーザー/形式（PC名\user / DOMAIN\user）で再接続
「指定されたネットワーク名は利用できません」	共有が存在しない/SMB遮断/サービス停止	net share、LanmanServer、445番	管理共有無効化の解除、FW許可、サービス起動

再発防止の考え方（運用で詰まらないために）

管理共有は便利ですが、端末台数が増えるほど「個別の設定差」が障害になります。次のように運用設計しておくと、トラブルが減ります。

• ドメイン環境なら、端末管理用のグループを作り、ローカル Administrators に一括で入れる
• ローカル管理者での横展開は避け、必要な場合だけ LocalAccountTokenFilterPolicy を適用する（適用範囲を絞る）
• 共有機能・FWルール・サービスの状態を構成管理（GPO/Intune/スクリプト）で揃える
• ファイル転送や実行が目的なら、PowerShell Remoting（WinRM）や管理ツールへの移行も検討する

まとめ

Windows 10 で \\computername\C$ にアクセスできないときは、まず「SMBでつながっているか」を確認し、そのうえで次の3点を優先してチェックすると解決が近づきます。

• 接続ユーザーが対象PCの管理者であること（ローカル Administrators）
• UACのリモート制限（必要に応じて LocalAccountTokenFilterPolicy=1 を対象PCに設定）
• 共有設定とファイアウォール（ネットワーク探索／ファイルとプリンターの共有、SMB-In ルール、Serverサービス）

「通信」と「権限」を分けて見れば、C$ のトラブルは最短で原因にたどり着けます。現場での一次切り分けには、Test-NetConnection と net use の組み合わせが特におすすめです。