Windows 10 から Windows 11 にアップグレードしたあと、ワイヤレス キャスト（Miracast）で別の Windows 11 PC へ画面を投影しようとすると、送信側は「拡張表示に成功」と表示されるのに、受信側は青い「〇〇は投影しようとしています」のまま止まるケースが増えています。本記事では、その主因となる Windows Defender ファイアウォールの設定と、過剰にポートを開け過ぎない「最小権限」で Miracast を復活させる具体的な手順を、実務レベルで解説します。
症状の整理：送信側は成功なのに、受信側が青画面のまま止まる
まず、今回よくあるパターンの症状を整理します。
| 項目 | 状況 |
|---|---|
| OS | 送信側：Windows 10 / 11 受信側：Windows 11（アップグレード直後が多い） |
| 接続操作 | 送信側で「ワイヤレス ディスプレイに接続」→ 対象 PC を選択 |
| 送信側の表示 | 「接続済み」「拡張表示」など、一見成功している表示になる |
| 受信側の表示 | 青い画面で「〇〇は投影しようとしています」のまま進まず、実際の画面は映らない |
| 一時的な回避策 | 受信側で「送信元 IP からの UDP をすべて許可」するファイアウォール規則を入れると映る |
| 問題点 | WUDFHost.exe のみを対象にした UDP 許可規則では映らない。どの UDP 規則が本当に必要か分からない |
つまり、「UDP を全部許可すれば動くが、それは怖い。必要な範囲だけに絞りたい」というのが現場での正直な悩みです。本記事では、その「必要最小限」を狙い撃ちにする設定方法を説明していきます。
Miracast / ワイヤレス ディスプレイの仕組みとポイント
正しいファイアウォール設定を作るには、ざっくりでも仕組みを押さえておくと話が早くなります。
- Miracast は主に UDP ベースのストリーミング を行う。
- 受信側の Windows 11 では、「ワイヤレス ディスプレイ」UWP アプリ（パッケージ名：Microsoft.PPIProjection） が映像受信を担当する。
- ドライバー関連プロセスとして WUDFHost.exe も通信に関わるが、アプリ本体は UWP アプリであり、ファイアウォール規則もアプリ パッケージ単位で評価される。
- 使用する UDP ポートは固定ではなく、動的なポート帯（1024–49151 など）が使われることが多い。
このため、WUDFHost.exe だけを許可しても、肝心の UWP アプリ（Microsoft.PPIProjection）がブロックされ続けてしまう、というのがよくあるハマりポイントです。
事前確認：Miracast が使える環境かどうか
ファイアウォールを疑う前に、ハードウェアや機能レベルで Miracast 非対応になっていないかを確認しておきましょう。
dxdiag で Miracast 対応状況を確認する
- Win + R キーを押し、「ファイル名を指定して実行」を開く。
dxdiagと入力し、Enter キーを押す。- 診断ツールが起動したら、右下の「すべての情報を保存」をクリックする。
- 保存したテキストファイルをメモ帳などで開く。
- 「Miracast: Available with HDCP」 などの行を探す。
| 表示内容 | 意味 |
|---|---|
| Miracast: Available with HDCP | Miracast 利用可能（正常） |
| Miracast: Not supported by graphics driver | GPU ドライバーが非対応。ドライバー更新またはハードウェア要件を要確認 |
| Miracast: Not Available | 無線 NIC やディスプレイ ドライバーなどが要件を満たしていない可能性 |
ここで「Available」でない場合は、いくらファイアウォールをいじっても Miracast 自体が成立しないので、まずはドライバー更新やハードウェア条件の見直しを優先します。
ネットワークの共有設定を確認する
Miracast は同一ネットワーク内の端末同士で動作することが前提です。Windows 11 では、次の共有関連設定がオフだと接続に失敗または不安定になることがあります。
- 「設定」アプリを開く。
- 「ネットワークとインターネット」→ 「高度なネットワーク設定」。
- 「共有の詳細設定」を開く。
- 以下の項目を プライベート / パブリック の両方で「オン」にする。
- ネットワーク探索
- ファイルとプリンターの共有
特に、受信側 PC が「パブリック ネットワーク」と認識されているときは、共有系の設定が軒並みオフになりやすいので、必要に応じてネットワーク プロファイルを「プライベート」に変更しておきましょう。
「ワイヤレス ディスプレイ」機能とドライバーを確認する
受信側 PC が「この PC へのプロジェクション」に対応し、かつ機能がインストールされている必要があります。
- 「設定」→「アプリ」→「オプション機能」を開く。
- 一覧に 「ワイヤレス ディスプレイ」 があるか確認する。
- ない場合は「機能を表示」から「ワイヤレス ディスプレイ」を検索し、インストールする。
- 念のため、無線 LAN／有線 NIC ドライバー および GPU ドライバー も最新に更新しておく。
ここまで問題がないのに症状が続く場合、ファイアウォールによるブロックが疑わしい状況だと考えられます。
なぜファイアウォールが原因になるのか
今回のケースでは、
- 送信元 IP からの UDP をすべて許可すると Miracast が正常に映る
- しかし、WUDFHost.exe のみを対象にした UDP 許可規則では映らない
という現象が起きています。ここから分かることは次の通りです。
- UDP 通信自体は必要であり、ファイアウォールが UDP パケットを落としている。
- しかし、通信の主体は WUDFHost.exe ではなく、UWP アプリ「ワイヤレス ディスプレイ（Microsoft.PPIProjection）」側である。
- Windows Defender ファイアウォールは、UWP アプリに対して「アプリ パッケージ単位」の規則を持つ仕組みになっている。
つまり、「特定の EXE（WUDFHost.exe）を許可すればよい」という感覚が Windows 11 の UWP アプリでは通用しないのです。必要なのは、
- Miracast が使用する 動的な UDP ポート帯（1024–49151 など） を
- 受信側 PC の 「ワイヤレス ディスプレイ」アプリ パッケージ（Microsoft.PPIProjection） に対して
- 最小限の範囲（送信元 IP やネットワーク プロファイルで制限）で許可する
というルールです。
最小権限で Miracast を通すファイアウォール設定の方針
以下は、「UDP 全許可」は避けつつ、実務上ほぼ問題なく Miracast を利用できることを狙った推奨設定です。
| 設定項目 | 推奨値 | 補足 |
|---|---|---|
| プロトコル | UDP | Miracast の映像・音声ストリームが UDP ベース |
| ローカル ポート | 1024–49151 （広めにとるなら 1024–65535） | 動的ポート帯に幅を持たせて許可する |
| リモート IP | 送信元 PC の IP または同一サブネット | 「すべてのリモート IP」ではなく、できるだけ絞る |
| プロファイル | プライベート（必要に応じてパブリック） | 通常の社内／家庭 LAN ならプライベートで十分 |
| 対象 | アプリ パッケージ： 「ワイヤレス ディスプレイ（Microsoft.PPIProjection_…）」 | EXE ではなく UWP アプリ パッケージに紐づけるのが重要 |
では、実際の画面操作手順を見ていきます。
手順：受信側 PC にカスタム受信規則を作成する
受信側 PC で「セキュリティが強化された Windows Defender ファイアウォール」を開く
- スタートボタン右クリック → 「Windows ターミナル（管理者）」ではなく、検索ボックスから「
wf.msc」と入力して実行するか、「セキュリティが強化された Windows Defender ファイアウォール」を検索して起動する。 - 左ペインの「受信の規則」を選択する。
カスタム規則の作成（UDP 1024–49151）
- 右ペインの「新しい規則」をクリック。
- 「規則の種類」で「カスタム」を選択 → 「次へ」。
- 「プログラム」画面では一旦「すべてのプログラム」のまま「次へ」。
（後でアプリ パッケージに紐づけ直すため、ここでは深く気にしません） - 「プロトコルおよびポート」で以下を設定して「次へ」。
- プロトコルの種類：UDP
- ローカル ポート：特定のポート → 1024-49151
- リモート ポート：すべてのポート（既定のまま）
- 「スコープ」で、可能であれば「リモート IP アドレス」に送信元 PC の IP、もしくは「ローカル サブネット」を指定する。
- 「操作」で「接続を許可する」を選択。
- 「プロファイル」で少なくとも「プライベート」にチェック。必要なら「パブリック」にもチェックする。
- 「名前」で「Miracast UDP In 1024-49151」など分かりやすい名前を付けて完了する。
規則を UWP アプリ「ワイヤレス ディスプレイ」に紐づける
作成直後の規則は「すべてのプログラム」に対して有効になっています。このままだと範囲が広すぎるため、アプリ パッケージ（Microsoft.PPIProjection）に限定します。
- 「受信の規則」の一覧から、先ほど作成した「Miracast UDP In 1024-49151」規則をダブルクリック。
- 「プログラムとサービス」タブを開く。
- 「このアプリ パッケージに適用」を選択し、「参照」ボタンをクリック。
- 一覧から 「ワイヤレス ディスプレイ」（Microsoft.PPIProjection_…） を選択する。
- 「OK」で閉じて設定を反映する。
これで、Miracast に必要な UDP ポート範囲だけを、受信側のワイヤレス ディスプレイアプリに対して許可する規則が完成します。
ポート範囲を 1024–49151 にする理由
「どうして 1024–49151 という中途半端な範囲なのか？」と疑問に思うかもしれません。ポイントは次の通りです。
- 1024 より小さいポート（1–1023）は「ウェルノウン ポート」と呼ばれ、他のサービスで使われることが多い。
- Windows でアプリが動的に利用するポート帯は、環境によって多少の差はあるものの、1024–49151 あたりに収まるケースが多い。
- 実際のログを確認すると、Miracast の受信ポートはこの範囲に集中している事例がよく見られる。
もちろん、より安全を期すなら、ログで実際に使用されているポート帯を特定し、もう少し狭い範囲に絞るのが理想的です。まずは 1024–49151 で動作を確認し、問題なければログを見ながら徐々に範囲を狭めていく、という運用も有効です。
既定の Miracast 関連規則の確認
Windows 11 には、最初から Miracast 関連の規則がいくつか用意されています。しかし、何らかのタイミングで 無効化されたり削除されたりしていると、正常に動作しません。
「受信の規則」一覧で、次のような名前の規則がないかチェックします。
- Wireless Display / ワイヤレス ディスプレイ
- PPIProjection
- WUDFHost もしくは「Windows ドライバー フレームワーク」関連の規則
| 確認ポイント | 見るべき状態 |
|---|---|
| 規則の有無 | Miracast 関連の規則が削除されていないか |
| 有効／無効 | 必要な規則にチェックマークが付いているか |
| プロファイル | 実際に接続しているネットワーク プロファイル（プライベート／パブリック）に対して有効になっているか |
もし既定の規則が無効化されている場合は、有効化した上で、今回作成したカスタム規則と併用することで安定するケースもあります。
管理者では成功するが、標準ユーザーでは失敗する場合
現場でよくあるのが、
- 管理者アカウントでログオンして試すと Miracast が使える
- 標準ユーザーでログオンすると、同じ PC なのに接続できない
というケースです。これは、UWP アプリがユーザー単位でインストールされることに起因します。
- 管理者用の Microsoft.PPIProjection アプリ パッケージにはアクセスが許可されている。
- 標準ユーザー用のパッケージには、同じファイアウォール規則が適用されていない。
こうした場合は、次のように「標準ユーザーのアプリ パッケージ」を対象にした規則を追加します。
- 標準ユーザーでログオンした状態で、「セキュリティが強化された Windows Defender ファイアウォール」を開く（管理者資格情報を求められたら入力）。
- 先ほどと同様に UDP 1024–49151 許可のカスタム規則を作成。
- 規則のプロパティ → 「プログラムとサービス」タブで「このアプリ パッケージに適用」を選択し、標準ユーザー側にインストールされた「ワイヤレス ディスプレイ」を選択する。
PowerShell を使って対象のパッケージ名を確認したい場合は、管理者として次のコマンドを実行すると一覧が取得できます。
Get-AppxPackage -Name Microsoft.PPIProjection
ただし、ファイアウォールの GUI からアプリ パッケージを選ぶ方が安全で確実です。
ログで本当にファイアウォールがブロックしているか確認する
「理屈の上ではファイアウォールっぽいが、本当にそうか？」を裏取りするには、Windows Defender ファイアウォールのログを確認するのが有効です。
ログを有効化する手順
- 「セキュリティが強化された Windows Defender ファイアウォール」を開く。
- 右ペイン「プロパティ」をクリック。
- 「プライベート プロファイル」タブ（必要に応じてパブリックも）を開く。
- 「ロギング」の「カスタマイズ」ボタンをクリック。
- 「ドロップされたパケットをログに記録する」を「はい」に変更。
- 必要なら「成功した接続をログに記録する」も「はい」にする。
- 「OK」で閉じる。
デフォルトでは、ログは次のパスに出力されます。
%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log
ログの読み方のポイント
Miracast の接続を試みた直後のログをメモ帳などで開き、UDP かつ「D（ドロップ）」になっている行に注目します。
| フィールド | 見るポイント |
|---|---|
| action | DROP（ドロップ）か ALLOW（許可）か |
| protocol | UDP であるかどうか |
| src-ip / dst-ip | 送信元 PC と受信側 PC の IP が一致しているか |
| src-port / dst-port | どのポート帯がドロップされているか（1024–49151 に集中していないか） |
もし、Miracast の接続タイミングに合わせて UDP の DROP が大量に記録されているなら、現在の規則でポート範囲やプロファイル、アプリ パッケージの指定が不十分である可能性が高いです。ログをもとに、開放するポート帯やリモート IP の範囲をチューニングしていくとよいでしょう。
ルーターや無線 LAN 側の追加チェックポイント
ファイアウォールが正しく設定されていても、ネットワーク機器側の制限で Miracast がうまくいかないことがあります。代表的なものを挙げます。
- AP 分離（クライアント間隔離）
無線 LAN ルーターの設定で「クライアント同士を通信させない」機能が有効になっていると、PC 間での Miracast が成立しません。AP 分離をオフにするか、Miracast 用の VLAN／SSID を分けるなどの対策が必要です。 - 異なるバンド／SSID 間接続の制限
送信側が 5GHz、受信側が 2.4GHz といった形で、別の SSID として扱われている場合、ルーターの設定によってはブロードキャストやマルチキャストが遮断され、検出や接続が不安定になります。 - 無線 LAN アダプターの詳細設定
一部の NIC では、デバイス マネージャー → 該当アダプターのプロパティ → 「詳細設定」タブにある Network Coalescing（パケット合体） を「無効」にすると、Miracast の安定性が向上したという報告があります。ただし他のアプリへの影響もあり得るため、変更前の状態を控えておき、問題があれば元に戻してください。
コマンドでベースのポート開放を先に作る方法（管理者向け）
GUI で設定する前に、まずは UDP ポート帯だけをコマンドで一気に定義してしまう方法もあります。アプリ パッケージの紐づけは後から GUI で行う想定です。
netsh advfirewall firewall add rule ^
name="Miracast UDP In 1024-49151" ^
dir=in action=allow protocol=UDP localport=1024-49151 profile=private
必要に応じて、次のようなオプションを付けて調整します。
remoteip=送信元IP：特定の送信元 IP のみ許可したい場合。profile=private,public：パブリック プロファイルでも Miracast を使う必要がある場合。
コマンドで規則を作成したあと、「セキュリティが強化された Windows Defender ファイアウォール」の GUI から規則のプロパティを開き、「プログラムとサービス」タブで アプリ パッケージ＝ワイヤレス ディスプレイ（Microsoft.PPIProjection） を指定してください。
それでも映らないときのチェックリスト
ここまで設定しても、まだ Miracast が動作しない場合のチェックポイントをまとめます。
| チェック項目 | 確認内容 |
|---|---|
| サードパーティ製セキュリティソフト | 独自ファイアウォール機能が有効になっていないか。必要に応じて一時的に無効化して切り分け。 |
| VPN クライアント | VPN 接続中はローカル ネットワークへのブロードキャストが制限される場合がある。VPN 切断状態で試す。 |
| 仮想スイッチ／仮想アダプター | Hyper-V や仮想化ソフトの仮想アダプターが優先され、想定外のネットワーク経路になっていないか。 |
| 「この PC へのプロジェクション」設定 | 「設定」→「システム」→「この PC へのプロジェクション」で「常にオフ」になっていないか。 |
まとめ：実務向けチェックリスト
最後に、現場でそのまま使えるようにチェックリスト形式で整理します。原因切り分けの順番としても、この順で確認していくとスムーズです。
- □ 受信側 PC の dxdiag で 「Miracast: Available with HDCP」 を確認した。
- □ 「ワイヤレス ディスプレイ」機能がインストール済みで、NIC（有線／無線）と GPU ドライバーを最新化した。
- □ 「ネットワーク探索」「ファイルとプリンターの共有」を、プライベート／パブリック両方でオンにした（少なくとも実際に接続中のプロファイルではオン）。
- □ 受信側 PC の Windows Defender ファイアウォールで、UDP 1024–49151 を許可するカスタム規則を作成し、アプリ パッケージ「ワイヤレス ディスプレイ（Microsoft.PPIProjection）」に紐づけた。
- □ 可能な範囲で、リモート IP を送信元 PC もしくはローカル サブネットに限定し、プロファイルは最低限「プライベート」を有効にした。
- □ 管理者アカウントでは接続できるが標準ユーザーでは失敗する場合、標準ユーザーの PPIProjection アプリ パッケージを対象にした規則を別途作成した。
- □ ファイアウォールのログ（pfirewall.log）を有効化し、Miracast 接続時に UDP の DROP がないかを確認した。
- □ ルーターの AP 分離（クライアント間隔離） や VPN クライアント、サードパーティ製ファイアウォールが原因になっていないか切り分けた。
これらを順に確認・設定していくことで、「UDP をすべて許可しないと Miracast が動かない」という危険な状況から卒業し、必要最小限のポートとアプリに絞った安全なワイヤレス キャスト環境を構築できるはずです。
コメント