MENU

Windows 11の共有フォルダが片方からしか見えない原因と対処法｜システムエラー53・\ADMIN.localで解決

Windows11

Windows 11の共有フォルダが突然「片方からしか見えない」──pingは通るのに、エクスプローラーの「ネットワーク」や \\PC名 では開けず「システムエラー53（ネットワーク パスが見つかりません）」になる。そんなときは、SMBの疎通と名前解決（DNS）を分けて考えるのが最短です。2台のWindows 11で実際に起きた事例をもとに、\\ADMIN.local で復旧した手順を具体的にまとめます。

目次

今回のトラブルの前提（環境と役割）

「突然つながらない」系の共有トラブルは、環境の書き出しがそのまま原因候補の絞り込みになります。今回の構成は、社内用のWindows 11が2台、同一LAN内でファイル共有（SMB）を使うケースです。

項目内容現場での意味
PC台数Windows 11 × 2台Windows同士のSMB共有が前提
役割ADMIN（共有の“サーバー役”）／ADMIN2（端末）QuickBooks会社ファイルなどをADMIN側に置く運用
アカウント両方とも同じMicrosoftアカウントでサインイン資格情報（認証）で詰まりにくい構成
ネットワーク同一LAN・同一プライベートネットワーク共有を許可してよい前提（Publicだと遮断されやすい）
ルーターCharter（ISP）提供機器の可能性ローカル名解決（PC名→IP）の挙動が一般家庭用と異なることがある
セキュリティWindows Defenderのみ（McAfeeは削除済み）3rdパーティのFW干渉は少ない想定

症状：ADMIN→ADMIN2は見えるのに、ADMIN2→ADMINが見えない

今回やっかいなのは「完全にネットワークが死んだ」わけではなく、片方向だけが不調という点です。こういうときは、共有設定だけでなく名前解決（DNS）や探索（Network Discovery）も疑う必要があります。

現象状況典型的な原因候補
ADMINからADMIN2へはアクセスできるOK同一LANでの基本通信は成立している可能性が高い
ADMIN2からADMINへはアクセスできないNG名前解決（PC名）、共有元の受信FW、共有権限、資格情報など
pingは相互に通るOKIPレベル到達性はありそう（ただし共有成功とは別）
\\ADMIN が開けないNG（エラー53）名前解決（ADMIN→IP）が怪しい、または経路が見つからない
エクスプローラーの「ネットワーク」ADMINが見えない／入れない探索系（WS-Discovery/関連サービス）か名前解決が怪しい

まず理解する：Windows 11の共有アクセスは「SMB＋名前解決＋権限」のセット

共有フォルダは「\\PC名\共有名」を打てば終わりに見えますが、内部的には次の3要素が同時に成立して初めて動きます。切り分けの順番を間違えると、時間だけが溶けます。

要素何が起きているか崩れたときの典型症状
名前解決「ADMIN」をIPアドレス（例：192.168.x.x）に変換\\ADMIN が失敗、システムエラー53が出やすい
通信（SMB疎通）共有に必要なTCP 445（SMB）へ接続できるタイムアウト、接続できない、共有一覧が取れない
権限（認証＋共有/NTFS権限）ユーザーに閲覧/更新の権利がある「アクセスが拒否されました」、資格情報を求められる

今回の結論は、「SMBは生きているが、短いPC名（ADMIN）が解決できない」という名前解決寄りのトラブルでした。ここに到達するまでの最短手順を、実例ベースで紹介します。

最短で原因に辿り着く切り分け手順（おすすめの順番）

共有トラブルは「設定を片っ端からON/OFF」すると再発の原因を残しがちです。まずは結果がはっきり出るテスト順で進めます。

段取りテスト目的結果の読み方
土台の整備ネットワーク探索／共有／サービス／FWWindows側の基本条件を揃えるここが崩れていると後続テストが全部ノイズになる
SMB疎通確認TCP 445に届くか共有の通信経路が生きているか届かないならFWやネットワーク分離が主因
IP直指定\\IP\共有名 が開くか“名前解決”をバイパスして共有の実体を確認IPで開くなら、原因はほぼ名前解決側へ寄る
名前解決の確定nslookup/Resolve-DnsName/\\ADMIN.localどの方式で解決されているかを特定短い名前がダメで.localがOKならDNS/名前解決設計が原因

ステップ：ネットワーク探索（Network Discovery）を点検・修復する

まず「相手がネットワークに出ない」系の原因として多いのが、探索関連サービス停止やファイアウォールルール無効化です。今回も、最初にここをPowerShellで確認・修復しました（両PCで実施）。

確認用：CheckNetworkDiscovery.ps1（例）

管理者としてPowerShellを起動し、ネットワークプロファイル・サービス・ファイアウォールをまとめて確認します。

#requires -runasadministrator
Write-Host "=== Network profile ==="
Get-NetConnectionProfile |
  Select-Object InterfaceAlias, NetworkCategory, IPv4Connectivity, IPv6Connectivity |
  Format-Table -AutoSize

Write-Host "`n=== Discovery-related services ==="
$services = @(
  "Dnscache",   # DNS Client
  "upnphost",   # UPnP Device Host
  "FDResPub",   # Function Discovery Resource Publication
  "FDPHost",    # Function Discovery Provider Host
  "SSDPSRV"     # SSDP Discovery
)
Get-Service $services |
  Select-Object Name, StartType, Status |
  Format-Table -AutoSize

Write-Host "`n=== Firewall rule groups ==="
Get-NetFirewallRule -DisplayGroup "Network Discovery" |
  Select-Object DisplayName, Enabled, Profile |
  Format-Table -AutoSize

Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" |
  Select-Object DisplayName, Enabled, Profile |
  Format-Table -AutoSize

修復用：FixNetworkDiscovery.ps1（例）

社内LANがプライベートネットワークであることが前提です。外出先Wi-FiなどPublic環境で無闇に有効化しないでください。

#requires -runasadministrator

# 1) Set all connected profiles to Private
Get-NetConnectionProfile | ForEach-Object {
  if ($_.NetworkCategory -ne "Private") {
    Set-NetConnectionProfile -InterfaceIndex $_.InterfaceIndex -NetworkCategory Private
  }
}

# 2) Ensure discovery services are Automatic and Running
$services = @("Dnscache","upnphost","FDResPub","FDPHost","SSDPSRV")
foreach ($s in $services) {
  Set-Service -Name $s -StartupType Automatic -ErrorAction SilentlyContinue
  Start-Service -Name $s -ErrorAction SilentlyContinue
}

# 3) Enable firewall rules for Private/Domain
Get-NetFirewallRule -DisplayGroup "Network Discovery" |
  Set-NetFirewallRule -Enabled True -Profile Private,Domain

Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" |
  Set-NetFirewallRule -Enabled True -Profile Private,Domain

Write-Host "Done. Re-check with CheckNetworkDiscovery.ps1."

今回の事例では、修復後に再チェックして「問題なし」状態（サービスは自動＋実行中、FWルール有効、プロファイルPrivate）になりました。しかし、それでもADMIN2→ADMINは改善しませんでした。つまり、探索やFWだけが原因ではないと判断できます。

ステップ：SMB（TCP 445）に届いているかを確認する

共有が見えないときに最優先で確認したいのは、SMBポート（TCP 445）へ到達できるかです。名前が解決できても、ここが閉じていれば共有は使えません。

# ADMIN2（端末側）で実行
Test-NetConnection ADMIN -CommonTCPPort SMB

# IPが分かるなら、IPでも確認
Test-NetConnection 192.168.101.224 -Port 445

今回のケースでは、Test-NetConnectionが成功しました。つまり、ADMIN側の共有機能（SMB）が完全に遮断されているわけではなく、次に「名前」を疑える状況になります。

ステップ：IPアドレスで共有が開くか（名前解決をバイパス）

ここが分岐点です。\\PC名がダメでも、\\IPなら開けるなら、共有の実体（SMBと権限）は概ね生きています。残る主因は「名前解決」です。

# 例：共有の中身が見えるか確認
dir \\192.168.101.224\Documents

今回の事例では、IP直指定でフォルダ内容が見えました。これで「共有フォルダが壊れた」「権限が全部ダメ」よりも、ADMINという名前で辿れない方向にほぼ確定します。

実例：どのテストが成功し、どれが失敗したか

現場で混乱しやすいので、実際の結果を「意味」とセットで整理します。

コマンド／操作結果分かること
Test-NetConnection ADMIN -CommonTCPPort SMB成功SMB（TCP 445）には到達できている可能性が高い
net view \\ADMINシステムエラー53「ADMIN」という名前で目的地へ辿れない（名前解決・参照方式が怪しい）
dir \\192.168.101.224\Documents成功共有の実体は生きている（SMBと権限は少なくとも一部OK）
dir \\ADMIN.local\Documents成功.localでなら名前解決できる＝DNS/名前解決の方式が鍵

今回の核心：短いPC名（ADMIN）が解決できない「DNSの落とし穴」

この事例で重要だったのが、nslookupなどからDNS参照先がISP（Charter）のDNSサーバーになっていたことです。小規模オフィスでは、ルーターが「外向けDNSの中継」だけでなく「ローカル名解決（端末名→IP）」も担当することが多いのですが、環境によっては次のような状態になります。

  • PCのDNS設定が、ルーターではなくISPのDNSを直接参照している
  • ISPのDNSには社内LANのPC名（ADMINなど）は存在しない
  • 結果、\\ADMIN が「どこにあるか分からない」＝エラー53

さらに、Windowsには名前解決の経路が複数あります。ここを知っておくと、なぜ「.localだけ通る」という現象が起きるのかが腹落ちします。

名前解決の方式例ざっくり説明今回の現象との関係
DNSADMIN → 192.168.x.xDNSサーバーが答えを持っていないと解決できないISP DNSのみ参照だとローカルPC名が引けない可能性
mDNS（.local）ADMIN.local → 192.168.x.x.localを付けると、ローカル内にブロードキャスト/マルチキャストで問い合わせられる環境がある\\ADMIN.local が成功した理由になりやすい
LLMNR/NetBIOSADMIN →（ローカル探索）古い方式。セキュリティ強化やポリシーで無効化されることがある「突然、短い名前だけ解決できなくなった」の原因になり得る

解決策：\\ADMIN.local を正しい入口として使う

最終的に使えるようになったのは、ADMIN2から次のようにアクセスする方法です。

\\ADMIN.local
\\ADMIN.local\Documents
\\ADMIN.local\Shared Files

ポイントは、ショートカットやネットワークドライブも「.local付きのパス」で統一することです。「たまたま開けた」を「毎日確実に開ける」に変えられます。

実運用の手順：ショートカットとネットワークドライブで固定する

エクスプローラーで共有一覧へ入る

  1. ADMIN2でエクスプローラーを開く
  2. アドレスバーに \\ADMIN.local を入力してEnter
  3. 共有一覧（Documents、Users、プリンタ、共有フォルダ等）が表示されるか確認

よく使う共有パスを、迷わない形で残す

業務では「毎回ネットワークから探す」運用が一番事故ります。最初からパスを固定しましょう。

用途推奨パス例補足
共有の入口\\ADMIN.local「ネットワーク」に表示されなくてもここから入れる
共有フォルダ（例：SHARED FILES）\\ADMIN.local\Shared Files共有名にスペースがあってもUNCはそのまま利用可能
ドキュメント共有\\ADMIN.local\Documentsユーザープロファイル配下共有は揺れやすいので専用共有が理想

ネットワークドライブに割り当てる（必要なら）

QuickBooksや会計業務は「設定画面でパスを選ぶ」機会が多く、長いUNCパスは設定ミスの温床です。業務共有はドライブレターで固定すると安定します。

# 例：Z: に Shared Files を割り当て（一般ユーザーでも実行できることが多い）
net use Z: \\ADMIN.local\Shared Files /persistent:yes

資格情報（ユーザー名・パスワード）を求められる場合は、Windowsの資格情報マネージャーに保存するか、共有にアクセスするアカウントを整理します。ゲスト共有（Guest/匿名）は推奨しません。

QuickBooks（会社ファイル共有）で追加で気をつけたいポイント

今回のように「会社ファイルをADMINに置き、ADMIN2で作業する」構成では、共有が復旧したら次の点も確認しておくとトラブルの連鎖を防げます。

観点おすすめ理由
ファイルの置き場所OneDrive直下ではなく、ローカルディスクの専用共有フォルダ同期とファイルロックの競合を避けやすい
共有設計「QBData」など短い共有名で運用設定画面で選びやすく、ミスが減る
権限必要最小限のユーザーに限定誤削除・上書き・情報漏えいリスクを下げる
バックアップQuickBooksのバックアップ＋別媒体（外付け/NAS等）共有トラブル時でも復旧が速い

今回のフォルダ例（EVERYDAY、SHARED FILES など）がユーザープロファイルやOneDrive配下にある場合、パスが揺れたり共有が意図せず変わったりしがちです。業務データはC:\CompanyDataのように専用フォルダへ集約し、そこで共有を切ると復旧が簡単になります。

恒久対策：再発を減らすなら「DNS」と「IP」を安定させる

\\ADMIN.local で運用が回るようになっても、根本は「短いPC名が解決できない」状態です。端末追加やルーター更新で再発する可能性があるため、長期運用では以下を検討すると安心です。

DHCP予約（固定IP）で共有先を固定する

DHCPのままでも運用できることはありますが、IPが変わると切り分けが難しくなります。ルーター側でADMINにDHCP予約を設定して、常に同じIPを配布するのが定石です。

  • メリット：障害切り分けが速くなる／端末追加時も迷わない
  • デメリット：ルーター設定に管理権限が必要

DNS参照先を「ルーター（ローカル側）」へ寄せる

今回のように、端末がISPのDNSを直接参照していると、ローカルPC名が解決できないことがあります。可能なら、優先DNSをルーター（例：192.168.101.1）にすることで改善するケースがあります（機種やISPポリシー次第）。

方法内容向いている状況注意点
PC側で手動設定IPv4のDNSをルーターIPに設定台数が少ない／まず試したい端末が増えると管理が煩雑
ルーターのDHCPで配布配布DNSをルーターにする（DNSプロキシ）端末追加が多い／社内標準にしたいISP提供ルーターでは制限されることがある
ローカルDNSを立てるWindows Server等でDNSを運用安定性・拡張性重視運用コストは上がるが最も確実

Charter提供ルーターのように、仕様や設定ポリシーが絡む場合は、「なぜローカル名解決が不安定なのか」「ルーターがローカルDNSとして機能するか」をISP側へ確認するのが早いこともあります。

hostsファイルは検証に強い（恒久運用は慎重に）

名前解決が原因かどうかを短時間で確定させるには、hostsファイルが非常に便利です。例えばテスト用の別名を追加し、\\別名 で共有に入れるか確認します。

notepad.exe C:\Windows\System32\drivers\etc\hosts

# 例：テスト用の別名（IPはADMINのもの）
192.168.101.224  admin3

この方法で成功するなら「SMBや権限ではなく名前解決が問題」と確定できます。ただし、IPが変わると破綻するため、恒久運用はDHCP予約やDNS整備のほうが安全です。

Windows 11の「ネットワーク」に出ないのは異常？（表示に頼りすぎない）

Windows 11では、エクスプローラーの「ネットワーク」表示が不安定に見えることがあります。表示は探索系サービスやネットワーク状況に左右され、共有が生きていても一覧に出ないことがあります。

  • 「ネットワークに出るか」より、UNCパス（\\ADMIN.local\共有名）で開けるかを運用基準にする
  • 毎日使う場所はショートカット／ネットワークドライブに固定する
  • 端末追加時は「IPで開ける→名前で開ける」の順で確認する

再発防止チェックリスト（社内向けに落とし込む）

復旧後に最低限ここだけ押さえると、同種トラブルの再発率が下がります。

カテゴリチェック項目推奨状態理由
ネットワークネットワーク プロファイルプライベート共有・探索の前提条件
ファイアウォールNetwork Discovery / File and Printer Sharingプライベートのみ有効利便性と安全性の両立
名前解決DNS参照先ルーター or ローカルDNS「PC名が引けない」を防ぐ
アドレスADMINのIPDHCP予約（実質固定）共有先が変わらない
データQuickBooks会社ファイルの保存場所専用共有フォルダ（ローカル）同期競合やロック問題を避けやすい

よくある質問

\\ADMIN.local が通るなら、もう直さなくてもいい？

2台運用で固定なら実務上は回ります。ただし、端末追加やルーター更新で挙動が変わる可能性があります。長期運用では、DHCP予約やDNSの整備までやっておくと安心です。

pingは通るのに共有がダメなのはなぜ？

ping（ICMP）と共有（SMB/TCP 445）は別物です。共有は「名前解決＋SMB＋権限」が同時に成立して初めて動くため、ping成功＝共有OKではありません。

ゲスト共有を有効にすれば早い？

短期的に通ることはありますが、社内でも推奨しません。資格情報なしでアクセスできる状態は誤操作・情報漏えいリスクが上がります。アカウント認証でアクセスできる設計にしておくほうが安全です。

まとめ

Windows 11同士の共有が「片方からしか見えない」場合、原因はネットワーク探索やファイアウォールだけとは限りません。今回の事例では、探索・サービス・ファイアウォールを整えても改善せず、短いPC名（ADMIN）の名前解決が不安定なことが本質でした。

  • SMB（TCP 445）の到達性を確認
  • IP直指定で共有が生きていることを確認
  • \\ADMIN.local で成功したため、名前解決（DNS）問題と判断
  • 実運用は \\ADMIN.local\共有名 を基準にショートカット／ネットワークドライブ化して復旧

同じように「Windows 11 共有 システムエラー53」で困ったら、“IPで行けるか”を境に、名前解決へ一気に寄せて切り分けるのが最短ルートです。

Windows11
DNS ネットワーク共有 Windows11 SMB QuickBooks システムエラー53

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次