UWP の WiFiDirectAdvertisementPublisher は、Wi‑Fi Direct を使って端末同士を“ホットスポット風”につなげられます。ただし実装で必ず壁になるのが「どの Wi‑Fi チャンネル／どの帯域（2.4GHz/5GHz）で動くのか」。本記事では、チャンネルが決まる責任範囲、国別規制の扱い、LegacySettings の落とし穴、そして実務で使える観測・切り分け手順までまとめます。
WiFiDirectAdvertisementPublisherで作れるのは「Wi‑Fi Directの広告」
まず前提として、WiFiDirectAdvertisementPublisher は「アクセスポイントの設定を細かくいじるAPI」ではありません。UWP アプリが行えるのは、Wi‑Fi Direct の広告（advertisement）を開始・停止し、必要に応じてレガシー（非 Wi‑Fi Direct 端末向け）接続のための SSID/パスフレーズ等を設定することです。公開されているクラス構成を見ても、チャンネルや帯域を指定するプロパティが存在しないのがポイントです。
また、Windows には「モバイル ホットスポット（Mobile Hotspot）」という OS 機能があり、こちらは“テザリング的”な用途に最適化されています。一方で、Mobile Hotspot と Wi‑Fi Direct 技術は同時に動作できず、Mobile Hotspot が優先されるという制約も明記されています。つまり「OS のホットスポット」と「アプリの Wi‑Fi Direct」を混同すると、想定どおりに動かなかったり、突然機能が止まったりします。
| 項目 | Wi‑Fi Direct（WiFiDirectAdvertisementPublisher） | Mobile Hotspot（OS機能） |
|---|---|---|
| 主目的 | 端末間（P2P）接続・サービス提供 | インターネット共有（テザリング） |
| アプリからの制御 | 広告開始/停止、LegacySettings 等（範囲は限定的） | 基本は設定アプリ/OSが制御 |
| チャンネル/帯域指定 | 公開 API では不可（ドライバ/OS依存） | OSのUIで帯域選択できるケースあり（環境依存） |
| 同時利用 | Mobile Hotspot 実行中はサポートされず停止し得る | Wi‑Fi Direct より優先される |
結論：チャンネルはアプリから指定できない
一番重要な結論から言うと、WiFiDirectAdvertisementPublisher で「チャンネルを固定する／選ぶ」ことはできません。Microsoft の Q&A でも、Wi‑Fi Direct 広告で使用されるチャンネルはアプリ側では直接制御できず、下位の Wi‑Fi ドライバと OS が選択を行うとされています。
同様に「帯域（2.4GHz/5GHz）を選ぶ」「GO（Group Owner）のチャンネル幅や帯域を制御する」といった要望も、公開 API の範囲では基本的にできません。別スレッドでも、GO のチャンネル/帯域幅を制御する API はない旨が案内されています。
| やりたいこと | UWP（公開API）で可能？ | 現実的な代替策 |
|---|---|---|
| チャンネルを指定（例：1/6/11 の固定） | 不可 | 干渉を避けたいなら設計でスループットを要求しすぎない／物理環境を改善／外部AP利用 |
| 2.4GHz のみ／5GHz のみを強制 | 不可 | ドライバ設定（IHV依存）や端末構成で“誘導”を狙う（保証は弱い） |
| 国の規制に合うチャンネルのみ使用 | アプリが指定できないため「OS/ドライバが順守」前提 | 出荷国ごとに実測・検証、ドライバ更新、規制ドメインの取り扱い確認 |
なぜ指定できないのか：Wi‑Fi Directは「物理層はドライバの領域」
Wi‑Fi Direct は、端末同士が P2P（Peer to Peer）でグループを作り、どちらが Group Owner（GO）になるか、どのチャネルで運用するか、といった低レイヤの意思決定を含みます。UWP の WiFiDirectAdvertisementPublisher はその上にある「広告・接続フロー」を提供しますが、周波数やチャンネルは無線制御そのものなので、最終的には IHV（無線ベンダ）のドライバ実装に寄ります。
Windows ドライバ向けのドキュメントを見ると、Wi‑Fi Direct の「listen channel」を OS が指定しうるが、それはヒントとして扱われ得る（採用するかはデバイス次第、いつでも変えられる）と記載されています。つまり、OS でさえ「必ずこのチャネルに固定」とは言い切れない構造です。
国別のチャンネル規制は守られる？「守る責任」はOS/ドライバ側
「利用国で許可されたチャンネルだけを使う保証があるのか」は、製品設計として重要です。Microsoft の Q&A では、Wi‑Fi ドライバと OS が国の規制要件に従い、許可されたチャンネルのみが選択されると案内されています。
ただし実務目線で言うと、ここは“だからアプリは何もしなくていい”ではありません。なぜなら、規制ドメインの扱いは以下のように複数の要素が絡み、端末やドライバの挙動差が出やすいからです。
- 無線チップ/ファームウェアが持つ規制情報（地域コード、送信電力、使用可能チャネル）
- ドライバが OS とやり取りする国・地域情報（802.11d の country string など）
- 接続している AP がビーコンで通知する country 情報（環境によってはこれが効く）
- 端末の地域設定やロケーション情報（後述）
Windows ドライバの属性には、802.11d の「国または地域文字列」をサポートする仕組みがあり、複数の規制ドメインを扱えることが示されています。
つまり「規制は OS が守る」は方向性として正しい一方、実装の主体はドライバ/ファームウェアであり、アプリがそこを直接コントロールできない以上、出荷前の検証や問い合わせが重要になります。
Windowsの「設定 > 地域 > 国または地域」は規制ドメインに影響する？
追加質問として多いのが、「Windows の地域設定が規制ドメインを決めるのか」です。Microsoft Q&A のやり取りでは、「設定 > 地域 > 国または地域」が正しいチャンネル使用を駆動する旨の回答があります。
ただし、ここも誤解が生まれやすいので補足します。
- 実装上、無線デバイスはファームウェアに「地域」を焼き込んでいることが多く、OS の設定だけで完全に切り替わるとは限りません。
- 企業端末や OEM 機では、ポリシーやドライバ設定で地域が固定されている場合があります。
- Wi‑Fi の規制（特に 5GHz 帯の DFS など）は国ごとの差が大きく、端末側が「安全側」に倒して 5GHz を積極的に避けるケースもあります。
したがって、アプリ開発者としては「地域設定が影響し得る」ことは理解しつつ、実際の運用国・利用端末の組み合わせで必ず実測し、想定外の帯域/チャネルになっても破綻しない設計にしておくのが安全です。
2.4GHzだけ？5GHzも使う？：答えは「使い得るが、条件次第」
Wi‑Fi Direct が 2.4GHz 限定かどうかは、結論としては限定ではありません。Microsoft Q&A でも、Wi‑Fi Direct は一般に 2.4GHz と 5GHz の両方を使い得て、実際にどちらになるかはハードウェア能力と国の規制要件に依存するとされています。
また別の Q&A でも、Wi‑Fi Direct の広告に対して帯域/チャネルを選ぶ公開 API はなく、選択は IHV ドライバ側の実装詳細として扱われる、と明言されています。
5GHzが選ばれにくい（または不安定になる）典型パターン
- クライアント側（接続してくる端末）が 2.4GHz のみ対応（IoT 機器で非常に多い）
- 端末の無線実装が、Wi‑Fi Direct を 5GHz で動かす場合に制約がある（同時接続・省電力・ドライバ都合）
- DFS が絡む 5GHz チャンネルを避ける実装になっている（国・ドライバにより挙動差が出やすい）
- 近傍環境で 5GHz が混雑、または干渉・電波状況が悪い
2.4GHz/5GHzの選択に影響する「Wi‑Fi ハードウェア側要因」
UWP からは直接参照しづらいのですが、ドライバ層で見ると Wi‑Fi Direct に関して「同時に GO/Client を何個持てるか」などの属性が定義されています。これは、端末がどの程度 Wi‑Fi Direct の同時利用・共存（concurrency）に強いかに関係してきます。
| 要因 | 起きがちな現象 | アプリ側でできること |
|---|---|---|
| ドライバが 5GHz P2P を積極的に使わない | いつも 2.4GHz 側に寄る／混雑に弱い | 帯域選択はできない前提でスループット要件を見直す、端末選定・検証を強化 |
| 既存の Wi‑Fi 接続（インフラ）との共存制約 | 現在の接続バンドに引っ張られる、または片方が不安定 | 運用手順で“誘導”（例：特定バンドの AP に接続してから開始） |
| 規制ドメイン/DFS の都合 | 5GHz が使えない／特定チャンネルが避けられる | 国別の実機検証、ドライバ更新、運用国の設定確認 |
| クライアント端末の対応（2.4 のみ等） | 5GHz で広告すると接続できない | クライアント要件を先に確定、接続失敗時のフォールバック設計 |
「問い合わせ・抑制（強制的に使わせない）」はできる？
結論として、公開 API の範囲では「この帯域/チャネルを使うな」という抑制はできません。Microsoft の回答でも、帯域・チャンネルの選択は IHV ドライバの実装詳細であり、Windows が公開 API として提供していない、という整理です。
ただ、実務で「完全にゼロではない」打ち手もあります。いずれも保証が弱い点を理解したうえで、試す価値があるという位置づけです。
- ドライバの詳細設定（例：「Preferred band」など）で OS 全体の傾向を変えられる場合がある（ただし端末依存）。
- GO になりやすい側を変える（後述の GroupOwnerIntent など）ことで、結果的に運用チャネルの“決定権”がある側を調整する。
- 特定の Wi‑Fi デバイスに固定できるなら、IHV（無線ベンダ）にドライバ設定の有無を確認する。
現場で効く小技：既存の Wi‑Fi 接続が Wi‑Fi Direct に影響することがある
Wi‑Fi Direct は「Wi‑Fi 機能の一部」として動くため、端末がすでにインフラ Wi‑Fi に接続している場合に、Wi‑Fi Direct 側の挙動が影響を受けることがあります。実際、IsAutonomousGroupOwnerEnabled を true にすると、現在の Wi‑Fi 接続と同じチャンネル/帯域幅で GO を作るように見えるという報告があります。
ここから導ける現実的な運用例は次のとおりです。
- 「5GHz で動いてほしい」なら、先に 5GHz の AP に接続してから Wi‑Fi Direct を開始してみる（端末/ドライバによっては効果が出る）。
- 逆に IoT 機器など 2.4GHz のみクライアントが混ざるなら、5GHz に寄りすぎない端末選定や設定（必要ならドライバ設定）を検討する。
ただし繰り返しになりますが、これは公開仕様で保証された動作ではなく実装依存です。製品要件として“必ずこうなる”を期待するのは危険です。
GroupOwnerIntentで「GOになりやすさ」を調整できる
チャンネルそのものは指定できない一方で、接続のパラメータとして「どちらが GO になりやすいか」を調整する手段はあります。たとえば WiFiDirectConnectionParameters.GroupOwnerIntent は、GO 交渉で使われる intent 値で、既定値は 14（GO になろうと強く試みる）と説明されています。
実装上は、GO が運用チャネルの決定に影響するため、GO の役割をどちらが持つかで結果が変わる可能性があります。とはいえ、これも「チャネル指定」ではないため、最終的な帯域/チャネルはドライバ判断になります。
LegacySettingsは「レガシー端末向けの簡易AP」：2.4GHz固定になり得る？
WiFiDirectAdvertisement.LegacySettings は、Wi‑Fi Direct 非対応の端末でも接続できるようにするための“legacy mode”設定です。Microsoft Learn の説明では、このモードを有効にすると「通常の Wi‑Fi アクセスポイントとして振る舞う」ことが意図されており、ただし一般用途の AP ではない点が明記されています。
では「LegacySettings を使うと 2.4GHz 固定になるのか？」ですが、ここは固定とは言い切れません。実際、Wi‑Fi Direct（レガシー含む）が 5GHz で開始されて困っている、という事例もあり、帯域選択はドライバの実装詳細として扱われています。
つまり現実的な整理はこうです。
- 2.4GHz になりやすい理由：レガシー端末の多くが 2.4GHz しか持たない／互換性重視で 2.4GHz を選びがち。
- 5GHz になり得る理由：端末・ドライバによっては 5GHz でのレガシー運用も可能（ただし制御は不可）。
接続後に 5GHz に「移行」できる？
Wi‑Fi Direct のグループが確立したあとに、アプリが「じゃあ 5GHz に切り替えよう」と命令できるような公開 API はありません。帯域/チャネル選択はドライバ側の領域で、Windows が公開 API として提供していない、という整理になります。
運用上どうしても帯域を変えたいなら、一般的には一度切断して再確立（条件を変えて再試行）という形になります。ただし、その再確立でも希望する帯域/チャネルになる保証はありません。
「実際にどのチャンネルで動いたか」を観測する方法
チャンネルを制御できないなら、次に必要なのは観測です。障害解析（スニファでの電波確認）や、現地環境での再現性確認には「今どの帯域/チャンネルなのか」が必須になります。
方法：別端末でスキャンして中心周波数からチャンネル換算
Microsoft Q&A では、Wi‑Fi スキャン結果の WiFiAvailableNetwork.ChannelCenterFrequencyInKilohertz を使い、中心周波数をチャンネルに換算する方法が提案されています。プロパティ自体は「ビーコン/プローブ応答を受信した帯域の中心周波数」を返すものです。
注意点として、同じ Q&A スレッド内で「自分自身がホストしている Wi‑Fi Direct SSID を同一マシン上のスキャンで検出するのはサポートされない可能性が高い」とも述べられています。つまり、観測は“別端末”で行うのが基本です。
周波数 → チャンネルの換算（代表例）
中心周波数（MHz）からチャンネル番号を求めるとき、よく使われる近似は次のとおりです。
- 2.4GHz 帯（ch1〜13 の範囲）：ch ≒ (周波数[MHz] − 2407) / 5
- 5GHz 帯（ch36 など）：ch ≒ (周波数[MHz] − 5000) / 5
実装では、整数に丸めたり、例外（2.4GHz の ch14=2484MHz など）を別処理したりします。下の表は、スニファやログの読み合わせで頻出する値をまとめたものです。
| 帯域 | 中心周波数（MHz） | チャンネル | メモ |
|---|---|---|---|
| 2.4GHz | 2412 | 1 | 代表的な非重複候補 |
| 2.4GHz | 2437 | 6 | 代表的な非重複候補 |
| 2.4GHz | 2462 | 11 | 代表的な非重複候補 |
| 2.4GHz | 2472 | 13 | 国により扱いが異なる |
| 2.4GHz | 2484 | 14 | 例外（国・方式依存） |
| 5GHz | 5180 | 36 | 屋内でよく使われる |
| 5GHz | 5200 | 40 | 同上 |
| 5GHz | 5220 | 44 | 同上 |
| 5GHz | 5240 | 48 | 同上 |
| 5GHz | 5260 | 52 | DFS が絡む場合あり |
| 5GHz | 5280 | 56 | DFS が絡む場合あり |
| 5GHz | 5300 | 60 | DFS が絡む場合あり |
| 5GHz | 5320 | 64 | DFS が絡む場合あり |
| 5GHz | 5500 | 100 | DFS が絡む場合あり |
| 5GHz | 5560 | 112 | DFS が絡む場合あり |
| 5GHz | 5700 | 140 | DFS が絡む場合あり |
| 5GHz | 5745 | 149 | 国により可否が変わりやすい |
| 5GHz | 5765 | 153 | 同上 |
| 5GHz | 5785 | 157 | 同上 |
| 5GHz | 5805 | 161 | 同上 |
| 5GHz | 5825 | 165 | 同上 |
方法：OSツールでの確認（運用向け）
開発者が「いま接続している Wi‑Fi のチャンネル」を素早く確認したいなら、OS ツールも有効です。たとえば次のようなコマンドで、インターフェース状態やチャンネルが表示されるケースがあります。
netsh wlan show interfacesただし、Wi‑Fi Direct の仮想アダプタやレガシー AP 状態が必ずしも期待どおりに表示されるとは限りません。確実性が必要なら、別端末でのスキャン + 周波数換算や、電波スニファによる観測が堅いです。
実務での設計ポイント：チャンネル非制御を前提に“壊れない”作りにする
WiFiDirectAdvertisementPublisher を「ホットスポット的」に使う場合、アプリで帯域/チャネル制御ができない以上、設計で吸収すべきポイントがあります。
スループット要件を“固定チャネル前提”で置かない
2.4GHz は混雑しやすく、近傍環境で性能が大きく変動します。チャネル変更で逃げられない場合、アプリ側でできるのは、転送サイズや送信間隔を調整し、混雑時にもタイムアウトや切断が連鎖しないようにすることです。
接続失敗を「仕様どおりの揺らぎ」として扱う
たとえば相手機器が 2.4GHz のみ対応なのに、ホスト側が 5GHz 側で広告してしまい、接続できないケースがあります。この場合は「再試行」「ユーザーへのガイダンス」「運用手順（端末設定/ドライバ設定）」などで回避します。帯域選択 API がないことは Microsoft からも明言されています。
“どうしても制御が必要”なら選択肢を変える
製品要件として「国ごとにチャネルを固定」「常に 5GHz を強制」などが必須なら、UWP の Wi‑Fi Direct だけで完結させるのは難易度が上がります。選択肢としては次が現実的です。
- OS の Mobile Hotspot を採用し、OS 側の帯域選択に寄せる（ただし Wi‑Fi Direct と同時利用できない制約を理解する）
- 特定ベンダ（IHV）のドライバ設定・OEM API で制御できるかを検討する（一般化は難しい）
- 要件次第では外部の小型ルータ/専用 AP を採用して“無線制御をアプリから切り離す”
- より踏み込んだ内部仕様が必要なら、有償サポートで確認する（Microsoft Q&A でも案内あり）
トラブルシュート用チェックリスト
現場で詰まりやすい箇所を、検証項目としてまとめます。
- Mobile Hotspot が動いていないか（動いていると Wi‑Fi Direct が止まる/動かない可能性）
- 接続してくる端末は 5GHz 対応か（2.4 のみ端末が混ざると設計が変わる）
- 運用国の設定（端末の地域設定、出荷/運用手順）
- Wi‑Fi ドライバのバージョン（挙動差が出やすい。特に帯域選択や DFS 周り）
- 実測ログの取り方（同一マシンでは SSID が見えない場合があるため、別端末観測を用意）
参考になる一次情報（仕様確認に便利）
- Microsoft Q&A（WiFiDirectAdvertisementPublisher のチャンネル選択はドライバ/OSが担当、規制順守、2.4/5の可能性、地域設定の影響）
- Microsoft Learn：WiFiDirectAdvertisementPublisher クラス（Mobile Hotspot との非共存など）
- Microsoft Learn：WiFiDirectLegacySettings（レガシーモードの意図と注意点）
- Microsoft Q&A（Wi‑Fi Direct の帯域/チャネルを WinRT から選べない、IHV ドライバ実装の詳細）
- Microsoft Learn（ドライバ層）：DOT11_WFD_DEVICE_LISTEN_CHANNEL（OSが listen channel を“ヒント”として指定し得る）
- Microsoft Learn：WiFiAvailableNetwork.ChannelCenterFrequencyInKilohertz（スキャンから周波数を取得してチャンネル換算）
まとめ
WiFiDirectAdvertisementPublisher を使った“ホットスポット的”な実装では、チャンネル/帯域をアプリから固定できないことが最大の前提になります。国別規制の順守や 2.4GHz/5GHz の選択は OS/ドライバが担いますが、挙動は端末・ドライバ・運用国・周辺環境で変動します。だからこそ、制御ではなく観測と設計での吸収（再試行、要件の現実化、端末選定、検証手順の整備）で品質を作るのが近道です。
コメント