Windows Server 2016 Launchpadの共有フォルダーがWi-Fiで開けない原因と対処法（Windows 10）

Windows Server 2016に接続したWindows 10 Proで、Launchpadの「共有フォルダー（Shared Folders）」だけがWi-Fi接続時に見つからない…。有線LANでは正常。原因になりやすいDNS/経路のズレと、Wi-Fi側のIPv4・DNSを手動固定して解消した手順をまとめます。

発生した症状と前提

今回の現象は「SMB共有そのものが壊れている」というより、Launchpadが共有フォルダーを“検出・列挙”する部分だけが失敗している点がポイントです。実際の現場では、次のような状態で相談されることが多いです。

接続方式	Launchpad → 共有フォルダー	体感/補足
Wi-Fi	「共有フォルダーに接続できない」などのエラー	サーバー名や共有一覧が出ない／見つからない
有線LAN（Ethernet）	正常に表示	同じPC・同じユーザーでも再現しない

さらに、切り分けを難しくするのが「有線／無線ともDNSの優先サーバーはServer 2016のIPにしているつもり」という状況です。ここで言う“つもり”は、実際には以下のようなズレが潜んでいることがあります。

• Wi-FiだけDHCPから別のDNS（ルーターやISP）を受け取っている
• IPv4はサーバーDNSでも、IPv6側のDNSが別になっていて、名前解決がブレる
• 複数のネットワーク（VPN、仮想NIC、テザリング等）が混在し、名前解決や経路が期待と違う
• Wi-Fiが「パブリック」扱いで、検出・列挙に必要な通信だけが落ちる

Launchpadとは（共有フォルダーが「見つからない」理由を理解する）

Launchpadは、Windows Server 2016（Essentials機能を使う構成を含む）でよく使われるクライアント側の入口で、ユーザーにとっては「サーバーの共有フォルダーをワンクリックで開く」ための便利ツールです。

ただし裏側では、単に共有にアクセスするだけでなく、

• 接続すべきサーバーの名前解決（DNS）
• 共有フォルダーの一覧を取得して表示するための検出・列挙
• ユーザー権限に応じた表示（見せる/見せない）

といった工程が挟まります。そのため「SMBは通っているのにLaunchpadだけダメ」という現象が起きえます。今回のWi-Fi限定トラブルも、この“検出や名前解決の揺らぎ”が主因になっていました。

原因を短時間で絞り込むチェック

対処を始める前に、Wi-Fi接続中に次の3点だけ確認すると、原因の当たりがつきやすくなります。

チェック項目	やり方	怪しい場合に起きやすいこと
Wi-FiのDNSが本当にServer 2016か	ipconfig /allでWi-Fiアダプターの「DNS サーバー」を見る	サーバー名が解決できない／別IPに解決される／Launchpadの検出が不安定
サーバー名が正しいIPを返すか	nslookup SERVER名	返るIPがルーターや過去のIPだと、Launchpadが別物に接続しに行く
Wi-Fiがゲスト/隔離ネットワークになっていないか	AP/ルーター設定で「ゲストSSID」「AP分離」「クライアント間通信遮断」を確認	SMB(445)や検出系が遮断され、共有一覧が取れない（有線だけ正常になりがち）

Wi-FiだけLaunchpadの共有フォルダー検出が失敗しやすい理由

UNCパス（\\SERVER\Share）を直打ちすれば開けるのに、Launchpadからだと失敗するケースがあります。これは、Launchpadが単に共有へアクセスするだけでなく、「どのサーバーに接続すべきか」「どの共有があるか」を“名前解決や検出”を使って判断しているためです。

UNC直打ちとLaunchpadの違い

項目	UNC直打ち	Launchpad（共有フォルダー）
必要な情報	サーバー名（またはIP）と共有名が分かれば到達できる	サーバー名の解決・サーバーの識別・共有の列挙が必要になりやすい
影響を受けやすい要素	到達できる経路と認証	DNS、ネットワークプロファイル、複数NIC時の優先度、検出系通信
症状の出方	開ける/開けないがハッキリ	「見つからない」「接続できない」など検出失敗っぽい挙動になりやすい

つまりWi-Fi接続時にだけ、

• サーバー名が別IPに解決される（例：ルーター側DNSが返す）
• 名前解決がIPv6優先でズレる
• ネットワークの種類がパブリックになり、探索系が制限される

といった要因が重なると、Launchpad側だけが「共有フォルダーを見つけられない」という状態になります。

解決策：Wi-FiのIPv4を手動（静的）にしてDNSを明示する

今回の解決はシンプルで、Windows 10のWi-Fi側IPv4を「手動」に変更し、DNSを明示的に固定したことで改善しました。Wi-Fiの接続が安定しない／DNSが勝手に変わる／検出が不安定、といったケースで効果が出やすい方法です。

設定手順（Windows 10 の「設定」アプリから）

1. Windows 10 の 設定 を開き、ネットワークとインターネット → 状態 を開きます。
2. 表示される画面から、利用中の Wi-Fi 接続のプロパティ（接続のプロパティ）を開きます。
3. IP 割り当て の編集で、手動 を選択します。
4. IPv4 をオンにし、環境に合わせて以下を入力します。
   • IP アドレス（例：192.168.1.50）
   • サブネット プレフィックス長（例：24）
   • ゲートウェイ（例：192.168.1.1）
   • 優先 DNS：Windows Server 2016 の IP
   • 代替 DNS：外部DNS（例：8.8.8.8）など
5. 保存し、Wi-Fi を一度切断→再接続（またはPC再起動）します。
6. Launchpad を開き、Shared Folders（共有フォルダー） が正常に表示されるか確認します。

設定手順（コントロールパネル経由のやり方：画面が見つからない時用）

Windows 10のビルドや表示言語によっては、設定アプリの項目が見つけづらいことがあります。その場合は次の手順が確実です。

1. コントロールパネル → ネットワークと共有センター → アダプターの設定の変更
2. Wi-Fi を右クリック → プロパティ
3. インターネット プロトコル バージョン 4（TCP/IPv4） → プロパティ
4. 「次のIPアドレスを使う」「次のDNSサーバーのアドレスを使う」で静的設定

設定値の例（入力に迷いやすい項目）

入力欄は環境に依存するため、以下は“考え方”の早見表です。静的IPにする場合は、DHCP配布範囲と被らないアドレスを選ぶのが安全です。

項目	例	ポイント
IP アドレス	192.168.1.50	DHCPの配布範囲外、または固定割り当て（予約）と整合させる
サブネット プレフィックス長	24（=255.255.255.0）	家庭/小規模オフィスでよくある。環境に合わせて設定
ゲートウェイ	192.168.1.1	通常はルーター。社内のL3機器がある場合はそれ
優先 DNS	Server 2016 のIP	Launchpadやサーバー名解決の安定に直結
代替 DNS	8.8.8.8 など	外部名解決が必要な場合の保険。ただしAD環境では注意

代替DNSに外部DNSを入れる場合の注意点

「優先DNS＝サーバー、代替DNS＝外部」という構成は、インターネット名前解決が必要な小規模環境では手軽です。一方で、Active Directory ドメインを運用している場合は、一般的にクライアントのDNSは内部DNS（ドメインDNS）に統一し、外部はDNSサーバー側のフォワーダーで解決させる設計が推奨されます。

ケース	クライアントDNSの推奨	理由
ドメイン環境（ADあり）	内部DNSのみ（Server 2016）	ドメイン参加やポリシー取得に必要なSRVレコード等の解決が最優先
ワークグループ/小規模（ADなし）	内部DNS＋外部DNS（必要なら）	内部名解決を安定させつつ、外部名解決の保険を持てる

「外部DNSを入れたら逆に不安定になった」という場合は、まず代替DNSを外して挙動を見てください。根本的には、Server 2016側でフォワーダー設定を整えて、クライアントは内部DNSだけにするのが再発しにくいです。

設定後にやっておきたい確認（切り分けが楽になる）

再発時に“どこで詰まっているか”を素早く判断できるよう、Wi-Fiで正常化した後に確認観点を控えておくと役立ちます。

確認したいこと	操作/コマンド例	見るポイント
Wi-FiのDNSが狙い通りか	ipconfig /all	Wi-Fiアダプターの「DNS サーバー」にServer 2016が出ている
サーバー名が正しく解決されるか	nslookup SERVER名	返るIPがServer 2016のIPになっている
SMB(445)に到達できるか	Test-NetConnection SERVER名 -Port 445	TCP接続が成功する（True）
Launchpad以外の経路で共有へ行けるか	エクスプローラーで \\SERVER\共有名	資格情報/権限の問題なのか、検出の問題なのかを切り分け

まだ直らない場合の追加チェック

静的IP/DNS固定で改善しない場合は、「Wi-Fi固有の制限」や「ネットワーク種別」「名前解決の優先順位」が原因になっていることがあります。以下のチェックは、同様の症状でのヒット率が高い順に並べています。

Wi-Fiのネットワークプロファイルを「プライベート」にする

Windows 10は、Wi-Fiを「パブリック」と判定すると共有や検出に関わる挙動が保守的になります。Launchpadの列挙が不安定なときは、Wi-Fiをプライベートへ寄せるだけで安定することがあります。

• 設定 → ネットワークとインターネット → Wi-Fi → 接続中のSSID → ネットワーク プロファイル を確認
• 可能なら プライベート に変更

ファイアウォール/共有系の基本設定を確認する

「共有フォルダーが見つからない」系は、実は通信が通っていないだけ、ということもあります。特に社内Wi-Fiがセグメント分離されている場合は要注意です。

• Windows Defender Firewall のネットワーク種類（プライベート/パブリック）と、ファイルとプリンターの共有 の許可
• ポート TCP 445（SMB）が遮断されていないか（社内FW、ルーター、APの設定含む）
• Wi-Fi側が「ゲストネットワーク」「AP分離（クライアント間通信遮断）」になっていないか

IPv6のDNS/経路が邪魔していないかを確認する

Wi-FiだけIPv6が有効で、しかもIPv6側のDNSがルーターになっていると、サーバー名解決がIPv6側に引っ張られて検出が不安定になることがあります。まずは「Wi-FiアダプターのDNS」がIPv4/IPv6とも意図したものか、ipconfig /allで確認してください。

検証として一時的にIPv6をオフにして挙動を見る方法もありますが、環境によっては影響が出るため、恒久対策にする場合はネットワーク全体の設計とセットで判断してください。

複数NIC/VPN/仮想アダプターで優先度が狂っていないか

有線と無線を切り替えているつもりでも、VPNや仮想スイッチ（Hyper-V、VMware等）が残っていると、名前解決や経路が別方向に出てしまうことがあります。

• route print でデフォルトゲートウェイがどのIFになっているか
• Get-NetIPInterface でInterfaceMetricが極端に低いIFがないか
• 使っていないVPN接続や仮想NICを一時的に無効化して再現するか

Launchpad（コネクタ）側の再登録も検討する

ネットワークを直してもLaunchpadだけが古い情報を掴んでいる場合、コネクタの再インストールや再接続で改善することがあります。特にサーバー名やIPを変更した履歴がある環境では、キャッシュの影響が出やすいです。

• Launchpadのサインアウト→サインイン
• PC再起動
• コネクタ（Launchpad）を一度アンインストールして入れ直す（業務影響に注意）

再発防止の考え方：Wi-Fiの“自動配布”を整えるのが本筋

今回のように「Wi-Fiだけおかしい」場合、根っこはWi-Fi側のDHCP配布内容（DNS/ゲートウェイ/サフィックス）がLANと揃っていないことが多いです。手元のPCを静的にして収束させるのは即効性が高い一方、台数が増えると運用が破綻しやすくなります。

対策	メリット	デメリット/注意
Wi-Fiを静的IP/DNSにする（今回の方法）	すぐ効く。原因がDNS/経路なら高確率で改善	台数が増えると管理が大変。IP競合リスク
DHCP予約（固定割り当て）を使う	IPは固定だが運用はDHCP。競合しにくい	ルーター/サーバー側の設定が必要
DHCPで配るDNSをServer 2016に統一する	根本解決。新規端末も自動で安定	ネットワーク機器の設計変更が必要な場合あり
DNSサーバーにフォワーダーを設定し、クライアントは内部DNSのみ	ドメイン環境の定石。内部解決が最優先で安定	DNSサーバー運用（外向き解決の整備）が必要

“とりあえず直す”だけでなく、同じ現象を繰り返さないためには、Wi-Fi側のDHCPが配るDNSを見直す、もしくはサーバーDNSのフォワーダー設定を整えて、クライアント側のDNSを内部に統一するのが堅実です。

まとめ

• Wi-Fi接続時だけLaunchpadの共有フォルダーが開けない場合、DNS解決や経路のズレで「検出だけ失敗」していることがある
• 対処として、Wi-FiのIPv4を手動（静的）にし、DNSを明示的にServer 2016へ固定すると改善しやすい
• 確認は ipconfig /all、nslookup、Test-NetConnection -Port 445 が効率的
• 再発防止には、Wi-FiのDHCP配布（DNS）をLANと揃える、またはDNSフォワーダー運用でクライアントDNSを内部に統一するのが本筋