Windows Subsystem for AndroidでBluetooth権限が付与できない原因と対処法【2025年最新版】

Windows 11 の Windows Subsystem for Android（WSA）で Android アプリを動かしていると、「Bluetooth を許可してください」「近くのデバイスへのアクセスを許可しますか？」といったダイアログが出るのに、結局どの設定画面からも Bluetooth を有効化できず機器に接続できない――本記事では、この原因と現実的な対処策を、WSA のサポート終了状況も含めて詳しく解説します。

WSA 上で発生する「Bluetooth 権限を付与できない」問題とは

よくある症状

WSA 上の Android アプリで Bluetooth を使おうとすると、典型的には次のような挙動になります。

アプリ起動時や接続ボタン押下時に、Android 標準の「Bluetooth / 近くのデバイス」権限ダイアログが表示される
許可しても、アプリ上では Bluetooth が「オフのまま」または「アダプタ無し」と認識される
場合によっては Windows 側の「設定＞ Bluetooth とデバイス」が開くだけで、WSA 内のアプリは一切デバイスを検出できない
BluetoothAdapter.getDefaultAdapter() が null を返したり、「Bluetooth binder is null」といったログが出続ける

この挙動は、あなたの Windows や Android アプリの設定ミスではなく、WSA の仕様によるものです。

結論：WSA はそもそも Bluetooth / BLE をサポートしていない

Microsoft の公式 Q&A では、WSA チームの PM が以下の趣旨を明言しています。

Windows Subsystem for Android では Bluetooth デバイスはサポートされていない
WSA 上で動作する Android アプリは、物理 Android 端末のように Bluetooth デバイスを検出することはできない

つまり、Android アプリ側でいくら Bluetooth 権限を「許可」にしても、WSA から見える世界には Bluetooth アダプタ自体が存在しません。「電源が切れている」のではなく、「最初から繋がっていない」状態だと考えるとわかりやすいです。

環境	Android から見える Bluetooth 状態	典型的な挙動
物理 Android 端末	実デバイスの BT/BLE スタックに直接アクセス可能	スキャン・ペアリング・接続が正常に動作
Windows 11 ＋ WSA	Bluetooth アダプタが「存在しない」または「常にオフ」	スキャンしても何も見つからない／アダプタ null／接続不可

このため、「WSA のどこかに隠し設定があるのでは？」と探しても、残念ながら解決には至りません。機能自体が実装されていないためです。

WSA の仕組みと、なぜ Bluetooth が見えないのか

WSA のアーキテクチャ概要

WSA は、Windows 11 上で Android を仮想マシンとして走らせ、その中に Android アプリをインストールしているイメージです。Windows と Android の間は、以下のような形でブリッジ（仲介）されています。

機能	WSA 上のサポート状況（概念イメージ）	Android アプリからの見え方
ネットワーク（Wi‑Fi / LAN / インターネット）	仮想 NIC を通じて Windows のネットワークに接続	通常のモバイルネットワークや Wi‑Fi と同様に利用可能
ストレージ	仮想ディスク／共有フォルダを介して一部共有	Android 的には内部ストレージとして見える
入力（キーボード・マウス・タッチ）	Windows の入力を仮想デバイスとして中継	タッチ／ジェスチャーなどとして利用可能
Bluetooth / BLE	ブリッジ無し（未実装）	アダプタが存在しない・常にオフと認識される

Bluetooth だけが特殊なわけではなく、「USB パススルー」「シリアルポート」なども同様に制限があります。WSA の主な用途は、画面ベースのモバイルアプリを Windows 上で動かすことにあり、低レベルなデバイスアクセスは設計段階から優先度が低かったと考えられます。

Windows 側で Bluetooth が接続されていても関係ない理由

「Windows の設定画面では Bluetooth 機器とペアリングできているのに、WSA のアプリからは見えない」のは次のような構造になっているからです。

Windows 側：ネイティブな Bluetooth スタックにより、ヘッドセットや BLE 機器とペアリング・通信が可能
WSA 側：仮想マシン内の Android OS が、独自の Bluetooth スタックを持つ設計だが、そこに Windows の Bluetooth 層が接続されていない

このため、「Windows 側でペアリングすれば、WSA 内の Android にも共有されるはず」と期待しても、それは実現されていません。WSA が Bluetooth を認識するためには、「Windows ⇔ WSA 間で Bluetooth を中継する仕組み」が必要ですが、これが提供されていないのが現状です。

なぜ権限ダイアログだけ表示されるのか（Android 12 以降の仕様）

Android 12 以降の Bluetooth 権限の分割

Android 12（API 31）以降では、Bluetooth 関連の権限が従来の BLUETOOTH / BLUETOOTH_ADMIN から、次の 3 つのランタイム権限に分割されました。

権限名	主な用途	代表的な API
`BLUETOOTH_SCAN`	周辺の Bluetooth / BLE デバイスをスキャンする	`startLeScan()` / スキャン関連 API
`BLUETOOTH_CONNECT`	既にペアリング済みの機器と接続・通信する	`BluetoothDevice.connectGatt()` など
`BLUETOOTH_ADVERTISE`	自デバイスを BLE ビーコンなどとして送信する	`BluetoothLeAdvertiser.startAdvertising()` など

これらはすべて ランタイム権限 であり、アプリは実行時にユーザーの許可を求める必要があります。権限をリクエストすると、Android が「近くのデバイスへのアクセスを許可しますか？」というダイアログを表示する、というのが現在の仕組みです。

WSA では「権限が通っても Bluetooth 実装が無い」状態

WSA 上でこのダイアログが表示されるのは、あくまで「Android の挙動として正しい」からです。アプリはマニフェストに Bluetooth 権限を宣言し、コード上で requestPermissions() を呼び出しています。Android はそれに応じてダイアログを出しているだけで、WSA 固有の事情は知りません。

しかし、その裏側にある Bluetooth スタック（ハードウェア＋ドライバ＋OS の Bluetooth サービス）が WSA では未実装のため、たとえダイアログで「許可」を押しても：

BluetoothAdapter.getDefaultAdapter() が null を返す
アダプタ状態が常に「OFF」として報告される
スキャンしても結果が一件も返らない

といった状態になります。これはバグではなく、「権限はあるが使うべきハードウェアが存在しない」ことによる自然な結果です。Stack Overflow などでも、同様の症状と「WSA では BLE スキャンなどの Bluetooth 機能はサポートされていない」との回答が共有されています。

WSA と Amazon Appstore on Windows のサポート終了状況

2025 年 3 月 5 日で WSA は事実上エンドオブライフ

WSA と Amazon Appstore on Windows 11 は、2025 年 3 月 5 日を境に大きな区切りを迎えました。

Microsoft サポートの公式ページでは、「2025 年 3 月 5 日以降、Windows Subsystem for Android と Amazon Appstore は Microsoft Store から提供されない」と明記されています。
Amazon 開発者ブログでも、「Microsoft が WSA のサポートを終了するため、Amazon Appstore on Windows 11 も 2025 年 3 月 5 日以降サポート対象外になる」とアナウンスされています。

これにより、WSA は：

新規インストール：Microsoft Store からは入手不可
既存ユーザー：一定期間は利用継続できるものの、今後の機能追加や改善は期待できない

という「メンテナンス終了済みのレガシー環境」に分類されます。少なくとも公開情報の範囲では、Bluetooth を含む新機能が WSA に追加される可能性は極めて低いと考えておくべきです。

実務で取れる現実的な回避策

ここからは、「WSA 上で Bluetooth を動かすことはできない」という前提に立ったうえで、実務的にどのような選択肢があるかを整理します。

回避策 1：物理的な Android 端末でアプリを利用する

もっとも確実でトラブルが少ないのは、スマートフォンやタブレットなどの物理端末でアプリを動かす方法です。

Bluetooth/BLE 対応は端末の OS によって完全にサポートされている
アプリ開発者も「実機」を前提にテストしていることがほとんど
WSA 固有の制約に悩まされることがない

「でも操作や画面を PC から扱いたい」という場合は、次のような併用が現実的です。

スマホ連携（Phone Link）：通知や一部アプリの画面を PC にミラー表示しつつ、実際の Bluetooth 通信はスマホ側で行う
画面ミラーリングツール（例：scrcpy など）：USB 接続や Wi‑Fi 経由でスマホ画面を PC に映し、マウス・キーボードで操作する

これらはあくまで「表示と操作を PC に持ってくる」だけであり、スマホの Bluetooth を PC に転送してくれるわけではありません。しかし、ユーザー体験としては「PC 上でアプリを操作しつつ、Bluetooth 機器にはスマホから接続している」形になるため、運用上は十分実用的なケースが多いです。

回避策 2：Bluetooth を使わない接続方式に切り替える

対象機器やシステムが Bluetooth 以外の接続手段を持っている場合、そもそも Bluetooth に依存しない構成へ切り替えるのも有力な選択肢です。

想定シナリオ	もともとの接続	代替案（例）	メリット
IoT センサーや機器の監視	スマホアプリ経由で BLE 接続	機器を Wi‑Fi / 有線 LAN に接続し、REST API や MQTT でアクセス	サーバーや PC から直接監視・制御できる
計測器・バーコードスキャナ	専用 Android アプリが BLE 経由でデータ取得	PC 向けアプリ／Web UI／シリアル over USB など、他のインターフェースがあればそちらを利用	Windows ネイティブな運用が可能
クラウド連携機能を持つ機器	ローカルで BLE 経由設定後、クラウドにデータ送信	初期設定だけスマホで行い、その後はクラウド API 経由で PC アプリから利用	日常運用は PC から完結できる

最近の機器は、セットアップや詳細設定こそ Bluetooth に依存しているものの、日常利用はクラウド経由で完結できるケースも少なくありません。機器のマニュアルやメーカーの FAQ を確認し、Wi‑Fi や LAN 経由の運用が可能かどうかを見直してみる価値があります。

回避策 3：別の Android 実行環境（エミュレーター・仮想環境）を検討する

「どうしても PC で Android アプリを動かしたい」という場合、WSA 以外の選択肢も検討できます。

Android Studio 付属の公式エミュレーター：開発用途に最適だが、多くのケースで物理 Bluetooth の直接パススルーは非対応
サードパーティ製 Android エミュレーター（BlueStacks 等）：ゲーム用途に最適化されているものが多く、BLE デバイスとの直接連携を公式にサポートしていない場合がほとんど
物理 Android デバイスを仮想マシンから ADB 接続する：VM 上から USB デバッグ経由で実機を操作することで、「PC で開発」「実機で Bluetooth」を両立させる

重要なのは、「BLE を含む Bluetooth の完全なパススルーを提供しているかどうか」を製品ごとの仕様で必ず確認することです。多くの環境では、WSA と同様に Bluetooth 周りが制限されているため、過度な期待は禁物です。

環境	主な用途	Bluetooth/BLE についての一般的な状況	備考
WSA（サポート終了）	Windows 11 上での軽量な Android 実行	公式に非サポート	2025 年 3 月 5 日で事実上 EOL
Android Studio エミュレーター	アプリ開発・UI テスト	物理 BT パススルーは限定的または非対応	多くの場合、BLE 部分は実機テスト必須
サードパーティエミュレーター	ゲーム・一般アプリの PC 実行	ヘッドセット等のオーディオ用途は OS 側で吸収、BLE 機器は非サポートのことが多い	製品ごとに仕様や制約が大きく異なる

結局のところ、「Bluetooth をフルに使いたいなら、物理 Android 端末一択」と割り切り、PC 側は開発や画面操作のための補助環境として位置付けるのが安全です。

開発者向け：Bluetooth アプリのテスト戦略

ここからは、Android アプリ開発者の視点で「WSA をどう位置付けるか」「Bluetooth アプリをどのようにテストするか」を整理します。

設計のポイント：Bluetooth 層を抽象化する

Bluetooth を使うアプリでは、アーキテクチャ設計段階で次のような分離を行うと、WSA やエミュレーター上でのテスト効率が上がります。

アプリのコアロジック（ビジネスロジック）：計算・状態管理・画面遷移など、通信方式に依存しない部分
通信層（Bluetooth / Wi‑Fi / Cloud API）：実際にデバイスとデータをやりとりする部分

通信層をインターフェースで抽象化し、

実機用：本物の BLE 実装
テスト用：モック（疑似デバイス）実装

のように差し替えられるようにしておけば、WSA や公式エミュレーター上では「モック実装」を使って UI やロジックの部分だけを集中的にテストできます。BLE が絡むバグは最終的に実機で確認する必要がありますが、全テストを実機で回すよりも格段に効率が良くなります。

テスト環境の組み合わせ例

環境	テスト内容	備考
Android Studio エミュレーター	画面遷移・バリデーション・エラーハンドリングなど、Bluetooth 不要なロジック	モック Bluetooth 実装を注入して動作確認
WSA（サポート終了後も手元に残っている環境）	Windows での操作感・キーボード／マウス操作時の UI 最適化	Bluetooth 部分は全てモック化し、「接続中」「切断」など状態遷移だけ確認
物理 Android デバイス	BLE スキャン・ペアリング・通信など、実機依存の機能	最終的なリリース前検証は必ず実機複数台で実施

Google Play の要件では、今後も新しい Android バージョンへのターゲット API 更新が求められ続けますが、Bluetooth 権限の扱いも Android 12 以降で大きく変わっています。 WSA は既に過去の存在となりつつあるため、「最新 Android に準拠した設計・テスト戦略」を優先しつつ、PC 上での動作確認はあくまで補助的に考えるのが現実的です。

よくある誤解とアンチパターン

誤解 1：「Windows 側の Bluetooth をオンにすれば WSA からも使えるはず」

前述の通り、Windows と WSA の Bluetooth はまったく別のレイヤーで動いており、現状それらを橋渡しする仕組みは実装されていません。Windows 側の Bluetooth 設定をいくら変更しても、WSA 内の Android には届きません。

誤解 2：「レジストリや隠し設定をいじれば有効になるのでは？」

WSA に Bluetooth スタック自体が実装されていない以上、レジストリや設定ファイルを調整しても、物理的に存在しない機能を呼び出すことはできません。ネット上には非公式ツールや改造版 WSA による「なんちゃって Bluetooth 対応」をうたう情報もありますが、

セキュリティリスクやマルウェア混入の可能性
Microsoft のライセンス違反やサポート対象外になるリスク
Windows Update との相性問題・動作不安定化

などのデメリットが非常に大きく、おすすめできません。

誤解 3：「将来のアップデートで追加される可能性があるのでは？」

かつては Microsoft の Q&A で「将来のリリース向けに検討中」といったコメントもありましたが、WSA 自体が 2025 年 3 月 5 日でサポート終了となったことで、その可能性は事実上なくなりました。今から新規に WSA の Bluetooth 対応を期待して待つのは、現実的ではありません。

Android の Bluetooth 権限を正しく理解しておくメリット

WSA では Bluetooth が使えないとはいえ、Android アプリ開発者にとって Bluetooth 権限の仕組みを正しく理解しておくことは重要です。

Android 12 以降は、BLUETOOTH_SCAN / BLUETOOTH_CONNECT / BLUETOOTH_ADVERTISE を用途に応じて使い分ける必要がある
Google Play の要件では、旧来の BLUETOOTH / BLUETOOTH_ADMIN から新しい権限への移行が求められている
位置情報との関係（スキャン結果を位置情報として扱うかどうか）も審査のポイントになりうる

WSA の有無に関わらず、実機でのテストと、Play ストアのポリシーへの準拠は今後も必須です。「WSA で Bluetooth を使えないこと」をきっかけに、Bluetooth 権限設計そのものを見直しておくと、長期的にはアプリの品質向上にもつながります。

まとめ：WSA で Bluetooth は割り切りが必要

最後に、本記事のポイントを整理します。

WSA は設計上 Bluetooth / BLE をサポートしておらず、Android アプリから物理 Bluetooth デバイスにアクセスすることはできない
Android 12 以降の仕様により Bluetooth 権限ダイアログ自体は表示されるが、WSA には Bluetooth 実装が無いため、許可しても実際の通信は行えない
WSA および Amazon Appstore on Windows 11 は 2025 年 3 月 5 日にサポート終了を迎え、新機能追加は事実上期待できない
実務的な回避策は、「物理 Android 端末での利用」「Bluetooth を使わない接続方式への切替」「他のエミュレーター／仮想環境の検証」のいずれか（複数の組み合わせも有効）
開発者は、Bluetooth 層を抽象化し、モックを活用したテスト戦略を取ることで、PC 上の環境と実機テストをうまく使い分けられる

WSA による「なんとかして Bluetooth を動かす」方向に時間を費やすよりも、「Bluetooth がきちんと動く環境（実機）を前提に設計し、PC は補助的に使う」という割り切りをした方が、トラブルも少なく長期的な生産性も高くなります。WSA のサポート終了を機に、開発・運用の体制を見直してみてください。

参考情報（公式ドキュメントなど）

Microsoft Q&A：Windows Subsystem for Android での Bluetooth 対応状況（Bluetooth デバイスはサポートされない旨の回答）
Microsoft サポート：Install mobile apps and the Amazon Appstore on Windows（2025 年 3 月 5 日以降の提供終了について）
Amazon Developer Blog：Amazon Appstore on Windows 11 to be discontinued（WSA サポート終了と 2025 年 3 月 5 日以降のサポート終了）
Android Developers：Bluetooth permissions（Android 12 以降の Bluetooth 権限の詳細）
Android Developers：Meet Google Play’s target API level requirement（新しい Bluetooth 権限利用の要件）

この記事を書いた人

佐藤健司

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