エクスプローラーの「ネットワーク」に他の Windows PC は見えるのに、いざ共有フォルダーを開こうとすると「ネットワーク エラー」で弾かれる――この現象は、設定の“噛み合わせ”が崩れたときに起こります。本記事は最短で直す手順と、原因を確実に切り分けるための深掘りポイントを、家庭／社内LANどちらでも通用する形でまとめました。
目次
現象の整理：「見えるのに開けない」の正体
エクスプローラーのネットワーク一覧にPCが表示されるのは、PC同士が同一セグメントで発見プロトコル（WS-Discovery／SSDP 等）に反応している証拠です。一方で共有フォルダーへ入れないのは、SMBアクセス（TCP 445）、認証（資格情報）、権限（共有／NTFS）、ファイアウォール、名前解決のいずれかが詰まっている可能性が高い、ということを意味します。
まずは最短で直す・全PC共通チェックリスト
- ネットワーク プロファイルを「プライベート」に統一
設定 → ネットワークとインターネット →（Wi‑Fi または イーサネット）→ 接続のプロパティ → ネットワーク プロファイル をプライベートに。
「パブリック」だと共有関連通信が既定で遮断されます。 - プライベート プロファイルの共有を有効化
設定 → ネットワークとインターネット → 共有の詳細設定（または「詳細共有設定の変更」）で、ネットワーク探索をオン／ファイルとプリンターの共有をオン。
共有させるPC〈サーバー側〉だけでなく、アクセスするPC〈クライアント側〉でも有効化します。 - ファイアウォールの例外を確認
Windows セキュリティ → ファイアウォールとネットワーク保護 → ファイアウォール経由でアプリを許可。
「ファイルとプリンターの共有」「ネットワーク探索」にチェック（プライベート、ドメイン参加PCならドメインにも）。 - 保存済み資格情報を一掃
Win + R→rundll32.exe keymgr.dll,KRShowKeyMgrを実行し、古い／無効な資格情報をすべて削除。その後、エクスプローラーを再起動 or サインインし直します。 - 直接パスで接続テスト
エクスプローラーのアドレスバーに\\PC名\共有名を入力。失敗したら\\192.168.x.x\共有名（IP直指定）も試す。
IPで通るがPC名で失敗 → 名前解決の問題。どちらも失敗 → 認証／権限／ファイアウォールの再確認。 - クイックリセット コマンド
net use * /delete /y ipconfig /flushdns既存セッションの切断と名前解決キャッシュのクリアを先に実行してから再接続を。
役割別チェック（ひと目で分かる早見表）
| 観点 | アクセス側 PC（クライアント） | 共有側 PC（サーバー） | 判定の目安 |
|---|---|---|---|
| ネットワーク プロファイル | プライベート | プライベート | 双方プライベートであること |
| 共有設定 | ネットワーク探索 ON | ネットワーク探索／ファイル共有 ON | 片側だけ ON でも一覧表示はされうるがアクセスは不可になりがち |
| ファイアウォール | 例外：ネットワーク探索 | 例外：ファイルとプリンターの共有 | プロファイル（プライベート／ドメイン）に合っているか |
| サービス | Workstation/FDResPub 稼働 | Server/FDResPub 稼働 | 停止していないか |
| 認証 | 正しい資格情報を入力 | 対象ユーザーに共有＆NTFS権限 | 「拒否」や Everyone だけに頼っていないか |
| 名前解決 | DNS/LLMNR/NetBIOS 正常 | PC 名重複なし | IP直指定なら開けるかで切り分け |
| 物理・L2 | 同一セグメント | 同一セグメント | 例：192.168.1.x と 192.168.2.x は別セグメント |
確実に通すための詳細手順
Windows 10／11 のUIで迷わないナビ
- ネットワーク プロファイル
Windows 11：設定 → ネットワークとインターネット →（Wi‑Fi／イーサネット）→ ネットワークのプロパティ → プライベート。
Windows 10：設定 → ネットワークとインターネット → 状態 → 接続のプロパティ変更 → プライベート。 - 共有の詳細設定
設定 → ネットワークとインターネット → 共有の詳細設定（クラシック コントロールパネルの「詳細な共有設定の変更」でも可）。 - ファイアウォール例外
Windows セキュリティ → ファイアウォールとネットワーク保護 → ファイアウォール経由でアプリを許可 → 「ファイルとプリンターの共有」「ネットワーク探索」にチェック。
サービス状態の確認（発見・公開・SMBの土台）
管理者の PowerShell で次を確認します。
# クライアント側
Get-Service -Name LanmanWorkstation,FDResPub,fdPHost,Dnscache,SSDPSRV,upnphost
# 共有側（サーバー機）
Get-Service -Name LanmanServer,FDResPub,fdPHost,Dnscache Stopped のものがあれば Start-Service <サービス名>。恒久化はサービスのスタートアップ種類を「自動」に設定します。
特に LanmanServer（Server） が止まっていると共有自体が提供されません。
SMB 到達性のテスト
Test-NetConnection -ComputerName 192.168.x.x -Port 445
TcpTestSucceeded : True であればポート到達はOK。Falseならファイアウォールや経路（VPN／VLAN／ルータ）が疑わしいです。
資格情報の整理と正しい接続コマンド
# 保存済みセッションを一括切断
net use * /delete /y
# 正しい資格情報で接続（サーバーPC上のローカルユーザー）
net use \PC名\共有名 /user:PC名\ユーザー名 パスワード /persistent:no
# ドメイン参加環境では
net use \サーバー名\共有名 /user:DOMAIN\ユーザー名 パスワード まずは一時接続（/persistent:no）で通ることを確認し、その後ドライブ割り当て（右クリック「ネットワークドライブの割り当て」）を行うとトラブルを固めて回避できます。
共有とNTFS権限の“二段階”を理解する
- 共有権限：共有名に対する入り口の許可（既定では「Everyone：読み取り」）。
- NTFS権限：フォルダー自体の許可。最終的にはより厳しい方が適用されます。
例：共有権限「Everyone：変更」でも、NTFSが「読み取り」なら書き込みは不可。検証時は一時的に「共有権限：Everyone フル」「NTFS：対象ユーザー フル」を設定し、通ることを確認してから最小権限に絞ると原因の切り分けが速くなります。
名前解決があやしいときの手当て
- IPで通るがPC名で失敗：DNS/LLMNR/NetBIOS の問題が濃厚。
暫定対処としてC:\Windows\System32\drivers\etc\hostsに192.168.x.x PC名を追記（管理者でメモ帳を開く）。
恒久対処としては、正しいDNSサフィックスや、ルータのローカルDNS、NetBIOS over TCP/IP（NIC詳細→IPv4→詳細→WINS）を確認します。 - PC名重複：家庭LANでありがち。
sysdm.cplからコンピュータ名を変更して再起動。
よくあるエラーと原因の対比表
| 表示／コード | 主因 | 手当て |
|---|---|---|
| 0x80070035（ネットワーク パスが見つかりません） | 名前解決失敗／ポート445遮断 | IP直指定で検証、Test-NetConnection -Port 445、DNS/NetBIOSとFW例外を確認 |
| 0x80004005（不明なエラー） | 資格情報の不整合／権限不足 | 資格情報の削除→再入力、共有／NTFS権限を一時的に広げて切り分け |
| システム エラー 53 | 名前解決失敗 | \\IP\共有名で試す、hostsで暫定回避 |
| システム エラー 67 | ネットワーク名が無効／共有名が存在しない | 共有名のスペル、共有が有効か、LanmanServer 稼働を確認 |
| システム エラー 5（アクセスが拒否されました） | 認証／権限／時間ずれ | 正しいユーザーで接続、権限見直し、端末間の時刻ずれ（±5分以内）を修正 |
深掘り：セキュリティ設定とバージョン差異の落とし穴
ゲストアクセスは既定でブロック
最近の Windows は匿名（ゲスト）アクセスを拒否します。古いNASや家電系共有に接続する場合だけ、自己責任で以下ポリシーを一時的に許可します（推奨は対象デバイス側を更新）。
ローカル グループポリシー（gpedit.msc）
[コンピューターの構成]→[管理用テンプレート]→[ネットワーク]→[Lanman ワークステーション]
「安全でないゲスト ログオンを有効にする」＝[有効]
（レジストリ）HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
AllowInsecureGuestAuth (DWORD) = 1
SMB1 が必要なレガシー機器
SMB1無効環境では、非常に古いNAS／複合機の共有に失敗します。やむを得ず有効化する場合は、必要な期間だけ限定してください。
# PowerShell（管理者）
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
作業後は再起動が必要です。セキュリティリスクが高いため運用での常用は不可。代替：機器のファーム更新／Samba設定の見直し。
SMB サイン／NTLM ポリシーの不一致
企業ネットワークで「片側だけ SMB サイン必須」「古いNASが NTLMv1しか話せない」などの不一致があると、認証後に落とされるケースがあります。以下をそろえてください。
- ローカル セキュリティ ポリシー（secpol.msc）→
[ローカル ポリシー]→[セキュリティ オプション]
「Microsoft ネットワーク クライアント：デジタル署名（常に）」／「Microsoft ネットワーク サーバー：デジタル署名（常に）」の有効／無効を両端で一致。 - 同ポリシー「ネットワーク セキュリティ：LAN Manager 認証レベル」は原則「NTLMv2 のみ」を推奨（古機器のために緩めるのは最終手段）。
VPN／VLAN／ルーター越えの注意
- 同一サブネットに見えて別セグメント：IPの3オクテット目（例 192.168.1.10 と 192.168.2.15）が異なるとブロードキャスト系発見が届きません。
発見はできても SMB は別経路で落ちることもあるため、Test-NetConnection -Port 445とpingの双方で確認。 - ルーターのSMBフィルタ：一部ルーターはセキュリティ目的で 445/TCP を遮断します。家庭内通信は通す設定に。
- VPN は名前解決が別：DNSサフィックスやスプリットトンネルの設定により、
\\PC名が不安定になりがち。IP直指定で先に疎通を固めます。
電源・スリープ・NICの省電力で見える／見えないが変わる
- 共有側PCがスリープすると共有は停止。
電源オプション → 詳細設定 → ネットワーク接続のスリープ中のスタンバイを「無効」に。 - デバイス マネージャー → ネットワーク アダプター → プロパティ → 電源の管理で「電力節約のために…」のチェックを外して改善するケースあり。
イベントログで“犯人”を特定する
- アプリケーションとサービス ログ → Microsoft → Windows → SMBClient/Connectivity
接続失敗の理由（拒否・タイムアウト・サイン不一致）を示すイベントが出ます。 - セキュリティ ログ（監査）
ログオン失敗（イベントID 4625）や共有アクセス（5140）を確認。アカウントロックや認証方式のヒントになります。
「Windows 共有の基本」を一度リセットする手順（安全な初期化）
- 両PCで プライベート プロファイル／発見ON／共有ON／FW例外有効 をそろえる。
- 共有側で新規テスト用フォルダー
C:\ShareTestを作成し、共有名ShareTestとして公開。共有：Everyone 読み取り、NTFS：対象ユーザー 読み取り。 - アクセス側でセッション削除 →
\\IP\ShareTestにアクセス → 資格情報ダイアログでPC名\ユーザー名を入力。 - 通ったら、必要に応じて「変更（書き込み）」権限を最小権限で追加。最後に PC名 アクセスへ切り替え、名前解決を整える。
トラブル時の“決め手”になるコマンド集
# 共有一覧（サーバー側）
Get-SmbShare
# 現在のSMBセッション（クライアント側）
Get-SmbConnection
# ポート疎通
Test-NetConnection -ComputerName PC名 -Port 445
# 共有の状況（コマンドプロンプト）
net view \PC名
# セッションの全削除（クライアント側）
net use * /delete /y
# DNSキャッシュのクリア
ipconfig /flushdns
# 名前解決の状況
ping PC名
nbtstat -n
nbtstat -a PC名 家庭／小規模オフィスでありがちな“あるある”と対処
- サードパーティ製セキュリティソフトのFWが遮断：一時的に無効化して切り分け。製品側で「プライベートネットワーク」「ファイル共有」を許可に。
- Workgroup 名がバラバラ：直接の必須条件ではありませんが、同一 Workgroup（例：WORKGROUP）にそろえると発見が安定しやすい。
- Microsoft アカウント vs ローカル アカウント：共有側PC上にローカルユーザーを作成し、その資格情報で接続すると安定します。
- OneDrive フォルダーの共有：クラウド側の共有と混同しがち。ローカルパスに共有を作ってから試す。
VPNやVLANが絡む社内LANでの“本格的な”切り分け手順
- クライアント→サーバーの経路で TCP 445 が通ることを
Test-NetConnectionで確認。 - DNSの逆引き／サフィックス設定を確認。
nslookup PC名で正しいIPに解決されるか。 - グループポリシーで SMB サイン／NTLM ポリシーの整合性をチェック（クライアント＆サーバー）。
- サーバー側イベントログ（SMBServer/Operational）でリジェクト理由を追跡。
- スイッチ／FWのACLに445ブロックがないかをネットワーク担当と共に確認。
最終手段の前に：問題を一発で絞る「三段ジャンプ」
- IP直指定での読み取りができるか（できれば名前解決問題）。
- ローカル管理者で接続して通るか（通れば権限問題）。
- 新規フォルダーのまっさら共有で通るか（通れば元フォルダーのNTFS／継承設定問題）。
この順で試すと、90％以上のケースで原因領域が一つに絞れます。
セキュリティ上の注意
- 一時的に緩めた設定（ゲスト許可／SMB1有効化／Everyone フル）は、検証後に必ず元に戻してください。
- 共有データは最小権限で設計し、「変更」権限の付与はグループ単位で。
- 外出先で「プライベート」プロファイルのまま公衆Wi‑Fiに接続しないように。ネットワークは都度見直しを。
まとめ：発見できるのにアクセスできないときの“勝ち筋”
まずはプライベート統一／共有ON／FW例外を合わせ、資格情報をリセットしてから \\IP\共有名 で接続テスト。通るかどうかを軸に、名前解決・権限・サイン/認証ポリシー・経路へと切り分けていけば、ほとんどのトラブルは短時間で解消できます。困ったらイベントログと Test-NetConnection／Get-SmbConnection が“決定打”になります。
付録：一括で確認できる PowerShell スクリプト（貼って実行）
以下はクライアントPCでのセルフチェック用サンプルです。結果はコンソールに要点のみを表示します。
$target = Read-Host "接続先（PC名 もしくは IP）"
Write-Host "=== ネットワーク プロファイル ==="
(Get-NetConnectionProfile).Name, (Get-NetConnectionProfile).NetworkCategory
Write-Host "=== 共有系サービス ==="
Get-Service LanmanWorkstation,FDResPub,fdPHost,Dnscache | Select-Object Name,Status,StartType
Write-Host "=== TCP 445 到達性 ==="
Test-NetConnection -ComputerName $target -Port 445 | Select-Object ComputerName,RemoteAddress,TcpTestSucceeded
Write-Host "=== 名前解決 ==="
Resolve-DnsName $target -ErrorAction SilentlyContinue
Write-Host "=== 既存SMB接続 ==="
Get-SmbConnection | Select-Object ServerName,ShareName,UserName,Dialect
到達性（TcpTestSucceeded）が False の場合はファイアウォール／経路、True で Get-SmbConnection に出ない場合は資格情報や権限周りが焦点です。
FAQ（現場でよく出る質問）
- 「ネットワークに他のPCが表示されない」：FDResPub（Function Discovery Resource Publication）やネットワーク探索が無効、またはパブリック プロファイルになっている可能性。
- 「片方向だけアクセスできない」：共有側のFW例外が不足していることが多い。双方向で設定を合わせる。
- 「共有名は見えるが中が空」：NTFSの継承切りやアクセス拒否エントリが影響。継承の有効化／上位からの許可を見直し。
- 「ドライブ割り当てが起動のたびに切れる」：資格情報マネージャーで永続保存し、割り当て時に「サインイン時に再接続」を有効に。
コメント