UbuntuからWindows 11（24H2/25H2）へ移行した直後に、MicrosoftブランドのBluetoothマウスだけがスリープ復帰やBluetoothのオフ／オン後に自動で戻らず、毎回底面ボタンで再ペアリング……。ヘッドホンや他社キーボードは問題なし――この“あるある”は、マウスの不良ではなくWindows側の電源管理とBluetoothサービスの挙動が原因であるケースが大半です。本記事では、最短で直す具体手順と、なぜそれで直るのかまでを徹底解説します。
Microsoft製Bluetoothマウスが自動再接続しない：症状と前提
対象読者は次のような環境・症状に当てはまる方です。
- OS：Windows 11（24H2 または 25H2 を含む）
- デバイス：Microsoft製Bluetoothマウス（Surface Mouse、Modern Mobile Mouse、Precision Mouse など）
- 現象：スリープ復帰後やBluetoothのトグル（オフ→オン）後に、マウスが自動で再接続しない。ペアリング操作（底面のボタン長押し）が必要になる。
- 比較：同じPC・同じBluetoothアダプターで、他のBluetooth機器は正常に自動再接続する。
この場合、疑うべきはWindowsの電源管理とBluetoothサービス（bthserv）の動作です。Ubuntu（Linux）ではスタックの省電力挙動が異なるため発生しにくく、OS差に起因する“接続維持の閾値”の違いが結果として表面化していると考えられます。
結論（先に要点のみ）
次の手順を上から順に実施してください。多くの環境で手順1と2で解消します。
| 手順 | 操作内容 | 目的／効果 |
|---|---|---|
| 1 | デバイス マネージャー → Bluetoothアダプター → プロパティ → [電源の管理]で 「電力節約のためにこのデバイスをオフにできるようにする」のチェックを外す | Bluetooth無線をOSが勝手に休止させない（D3移行の抑制） |
| 2 | services.msc → Bluetooth サポート サービス → プロパティ → [ログオン]を「ローカル システム アカウント」に設定し、サービスを再起動 | サービス権限を強化し、ペアリング情報・再接続処理の安定化 |
| 3 | 設定 → システム → トラブルシューティング → その他のトラブルシューティングで「Bluetooth」「電源」を実行 | 自動診断で設定不整合や古い構成を修正 |
| 4 | デバイス マネージャー → Bluetoothアダプター → ドライバーの更新（またはPCメーカー提供の最新版を適用） | 古いBluetoothスタックや既知不具合の回避 |
| 5 | （USBドングル使用時）コントロール パネル → 電源オプション → 詳細設定 → USB設定 → USBセレクティブサスペンドを「無効」 | USB経由アダプターの選択的休止を防止 |
| 6 | 改善しない場合は、外付けBluetoothドングル（独自ドライバー付属・Windows 11対応）へ切替 | 内蔵無線の実装差・固有不具合の影響を分離 |
結果：実際の検証では、手順1・2の適用時点でスリープ後もマウスが安定して自動再接続するようになったとの報告があります。
なぜこれで直るのか：技術的背景をやさしく解説
Bluetoothマウス（特にMicrosoft製の近年モデル）は、Bluetooth Low Energy（BLE）上のHID over GATT（HOGP）プロファイルで動作します。BLEは超低消費電力を実現する代わりに、待機時のアドバタイジング間隔・スキャン間隔や、OS側の無線電源管理（D0→D3hot/D3cold）のチューニングによって、再接続タイミングのズレが発生しやすい特性があります。
- OS省電力と再接続のズレ：Modern Standby（S0 Low Power Idle）や選択的サスペンドによって、OSがBluetooth無線を積極的にスリープさせると、復帰の瞬間にマウスのアドバタイジングを取り逃がすことがあります。その結果、OSは「以前のBonding情報があるが現在見つからない」と判断し、再スキャン→失敗→ユーザーの再ペアリング促進という負のループに陥ります。
- サービス権限と状態管理：Bluetooth サポート サービス（bthserv）は、ペアリング情報（リンクキー/IRK等）や接続状態の管理に関与します。ログオンアカウントをローカル システムにすることで、スリープ復帰・ユーザ切替直後でも安定して処理できるようになり、Bondingの再利用がスムーズになります。
- Ubuntuで起きにくい理由：LinuxのBlueZスタックは、ディストリビューションや電源管理の既定値によっては無線をオフにしにくく、またスキャン再開が積極的です。このため、同じマウスでも症状が出にくいのです。
再現条件を素早く切り分けるチェックリスト
| 試すこと | 期待される挙動 | 判定 |
|---|---|---|
| Bluetoothをオフ→オンして60秒以内に待つ | 自動で「接続済み」に戻る | 戻らなければ省電力/サービスの疑いが濃厚 |
| PCをスリープ→30秒後に復帰 | マウスが即操作可能 | 不可ならD3遷移/USBセレクティブサスペンドを疑う |
| 別のBluetoothマウス（他社）で同条件テスト | 同じならアダプター/OS側、異なるなら互換性の問題 | Microsoft製に限るならHOGP×省電力の相性が本命 |
| 有線マウス接続のまま復帰 | OS操作可だがBTマウスは復帰が遅延/失敗 | ユーザログオン直後のbthserv再開タイミングを疑う |
手順の詳細：画面どおりに進めるだけ
手順1：Bluetoothアダプターの「電源の管理」を見直す
- Win + X → デバイス マネージャーを開く。
- Bluetoothを展開し、内蔵アダプター（例：Intel(R) Wireless Bluetooth(R) / Realtek / Qualcomm など）を右クリック→プロパティ。
- [電源の管理]タブで、「電力節約のためにこのデバイスをオフにできるようにする」のチェックを外す→[OK]。
この設定により、OSがスリープやアイドル時にアダプターを深く眠らせる（D3cold）ことを抑制します。BLEの再接続はミリ秒～数秒単位の“タイミング勝負”であるため、無線側の復帰遅延を減らすのが鍵です。
手順2：Bluetooth サポート サービス（bthserv）のログオン権限を「ローカル システム」に
- Win + R → services.mscを実行。
- Bluetooth サポート サービスをダブルクリック。
- [ログオン]タブで「ローカル システム アカウント」を選択し、必要に応じてサービスを再起動。
ユーザーセッション切替やスリープ復帰直後でも、サービスが十分な権限で素早く再開できるようになります。結果としてBonding情報の読み出しとHOGP再接続が安定します。
手順3：Windows標準トラブルシューティングを実行
- 設定 → システム → トラブルシューティング → その他のトラブルシューティング。
- 「Bluetooth」と「電源」の両方を[実行]。
OS内部の診断で、構成不整合（古いレジストリエントリ、無効化された関連サービス、破損した既定値など）を自動修復できます。手順1・2と併用すると効果的です。
手順4：Bluetoothドライバー／ファームウェアを更新
- まずはデバイス マネージャー → Bluetoothアダプター → ドライバー → ドライバーの更新。
- ノートPCやデスクトップPCのメーカーが提供するチップセットドライバー／Bluetoothスタックの最新版も要確認。
特にWindows 11 24H2/25H2期は省電力機構の最適化が進む一方で、アダプターの古いドライバーではBLEの再接続タイミングが合わず、「見えているのに掴めない」状態が起きがちです。
手順5：（USBドングル使用時）USBセレクティブサスペンドを無効化
- コントロール パネル → 電源オプション → プラン設定の変更 → 詳細な電源設定の変更。
- USB設定 → USBセレクティブサスペンドの設定を「無効」（バッテリー駆動・電源接続の両方）に。
USB子デバイスがアイドルで休止し、復帰信号を取りこぼすと、物理的には挿さっているのに論理的に消えているように見えます。無効化で再発を抑えられます。
手順6：外付けBluetoothドングルで切り分ける（最終手段）
内蔵無線の実装差や固有バグの影響を回避するため、Windows 11対応・BLE 5.x対応・独自ドライバー付属の外付けBluetoothドングルに切り替える方法です。オンボード無線をBIOSやデバイス マネージャーで無効化し、外付けを既定にすることで、ハード／ドライバー層の問題切り分けが明確になります。
症状×原因×対策のマッピング表
| 具体的な症状 | 考えられる原因 | 優先すべき対策 |
|---|---|---|
| スリープ復帰後にだけ再接続しない | アダプターがD3からの復帰に失敗／遅延 | 手順1・5（電源の管理・USBセレクティブサスペンド） |
| Bluetoothオフ→オン後に見つからない | bthservの再開タイミング不整合 | 手順2（ログオン：ローカル システム、再起動） |
| 長時間アイドル後だけ接続が切れる | BLEアドバタイジング間隔とOSスキャンのミスマッチ | 手順1・3（省電力抑制＋トラブルシューティング） |
| 他社マウスは問題ない | HOGP実装差×省電力閾値の相性 | 手順4・6（ドライバー更新／外付けで回避） |
検証方法：直ったかを確かめる再現シナリオ
| シナリオ | 操作 | 合格基準（OKの状態） |
|---|---|---|
| 短時間スリープ | Win + X → スリープ → 30秒放置 → 復帰 | 復帰直後からマウス操作が可能（遅延1秒未満が理想） |
| Bluetoothトグル | 設定 → Bluetooth → トグル オフ→オン | 60秒以内に「接続済み」と表示され、実操作可能 |
| 長時間アイドル | 画面ロック状態で1時間放置→解除 | 再ペアリング不要で操作可 |
より深く知る：Windowsの電源状態とBluetooth
Windowsのデバイス電源状態は主にD0（動作）～D3（休止）に分かれます。省電力が強化された24H2/25H2では、アイドル時にD3へ落ちやすく、復帰時にBLEデバイスのアドバタイジングを取りこぼすことがあります。手順1はこのD3遷移の積極性を下げる対策です。
また、Modern Standby（S0ix）環境では、スリープ中も最低限の処理を継続します。bthservの再開タイミングやユーザーセッションとの整合が崩れると、Bonding情報は残っているが接続確立が進まない状態になりがちです。手順2はこのボトルネックを緩和します。
Ubuntuでは発生しにくい理由
- BlueZのスキャン再開が積極的で、復帰直後の探索ウィンドウが広い。
- 省電力の既定値が控えめで、無線そのものをオフにしにくい配慮がある。
- ユーザー空間の権限モデルが異なり、再接続経路がシンプルになりやすい。
つまりマウスの品質問題ではなく、OSごとの省電力設計方針の差が主因という理解が実態に近いと言えます。
副作用とリスク（現実的なトレードオフ）
| 設定変更 | 想定副作用 | 回避策 |
|---|---|---|
| 電源の管理で省電力無効化 | わずかに待機消費電力が増える可能性 | バッテリー運用時のみ有効化する等、運用で調整 |
| USBセレクティブサスペンド無効化 | USBデバイス全体の省電力効果の低下 | 内蔵BTの場合は影響なし、外付け時のみ適用 |
| bthservをローカル システムで動作 | 実害はほぼないが、企業環境ではポリシー確認が必要 | IT管理下ではグループポリシーの許可範囲を確認 |
ここまでで直らない場合の追加テクニック
- マウス側のバッテリー残量確認：BLEは低電圧時にアドバタイジング間隔が伸びる傾向あり。電池新規交換／満充電で検証。
- 再ペアリング前に既存デバイス削除：設定 → Bluetooth とデバイス → デバイス → マウスを[削除]してから再ペアリング。GATTキャッシュの不整合を解消。
- PC名の変更・多重ペアリングの整理：同じマウスを複数PCとペアリングしていると、接続優先度がぶつかることがあります。
- BIOSの無線設定確認：無線共存（WLAN/Bluetooth共存）や電源最適化の項目がある場合、デフォルトへ戻して比較。
- 「このデバイスでPCのスリープ解除を許可」：デバイス マネージャー → HID準拠マウス → プロパティ → 電源の管理で有効化すると、復帰トリガーとして認識され改善する場合あり。
導入現場での実績：最短で効くのは「手順1＋2」
複数の現場・検証機で、デバイス マネージャーの省電力チェックを外す（手順1）＋bthservのログオンをローカル システムに変更（手順2）の組み合わせで、スリープ・トグルともに再接続が安定したケースが多数確認されています。特に24H2/25H2へ更新した直後は省電力の既定値・ドライバーの相性で再接続が不安定化しやすいため、まずこの2点から着手するのが合理的です。
運用Tips：再発を抑える小さな習慣
- Windows Update適用後は一度スリープ復帰テストを行い、再発の有無を即確認。
- 複数Bluetoothレシーバーを同時使用しない：USBドングルと内蔵を併用するとルートが競合しやすい。
- USBハブの電力供給を安定化：バスパワー不足は復帰直後の初期化失敗の温床。
- マウスのファーム更新（適用可能機種のみ）も定期チェック。
よくある質問（FAQ）
Q. マウスだけが再接続に失敗します。他機器は正常です。マウスが故障ですか？
A. まずはOS側の省電力とサービスを疑ってください。本記事の手順1・2で改善する場合が多く、マウス自体は正常であることがほとんどです。
Q. 毎回、底面ボタンを長押ししないと戻りません。
A. Bonding情報は残存している可能性が高いものの、復帰のタイミングずれでOSが再接続に失敗している状態です。電源の管理設定を緩め、bthservの権限を強化してください。
Q. 企業管理PCで「ローカル システム」への変更ができません。
A. ITポリシーで制限されている可能性があります。管理者に相談のうえ、手順1・4・5から試してください。
Q. 外付けドングルを選ぶポイントは？
A. Windows 11正式対応、BLE 5.0/5.1以上、ドライバー更新が継続提供されているものを選びましょう。
まとめ：まず電源管理、次にサービス。これで大抵は直る
- 本件はマウス不良ではなくOS側の省電力とサービスの挙動が主因であるケースが大半。
- 手順1（電源の管理）＋手順2（bthservのログオン変更）で改善する確率が高い。
- ドライバー更新・USBセレクティブサスペンド無効化・外付けドングルで、残る相性問題も切り分け可能。
- Ubuntuで起きにくいのは、スタックの省電力方針が控えめで復帰スキャンが積極的だから。
スリープ復帰やBluetoothトグル後も、Microsoft製Bluetoothマウスが何事もなく即座に使える――その状態は、ほんの数分の設定見直しで取り戻せます。まずは本記事の順番どおりに実施してみてください。
付録：この記事のポイントを一枚に
| やること | 場所 | 設定／操作 | 狙い |
|---|---|---|---|
| アダプターの省電力無効化 | デバイス マネージャー | 「電力節約のために…」のチェックを外す | BLE再接続のタイミングずれを抑制 |
| Bluetoothサービス権限調整 | services.msc | 「ローカル システム アカウント」＋再起動 | Bonding活用と再接続の安定化 |
| 自動診断の実行 | 設定→トラブルシューティング | 「Bluetooth」「電源」を実行 | 設定/レジストリ不整合の修復 |
| ドライバー更新 | デバイス マネージャー／メーカーサイト | 最新版へ | 既知不具合・相性の回避 |
| USB選択的休止の無効化 | 電源オプション | USBセレクティブサスペンド「無効」 | 外付けBTドングルの復帰安定化 |
| 外付けドングルで切り分け | — | Windows 11対応モデルへ切替 | 内蔵固有問題の回避 |
補足メモ
- Windows 11の最新ビルドではバッテリー最適化機能が強化され、低消費電力デバイス（特にマウス）で再接続失敗が起きやすい。
- UbuntuではBluetoothスタックが電源管理で無線を積極的にオフにしない傾向があるため、本症状が発生しにくい。
- 同様の症状がある場合、電源管理関連の設定の見直しが最短ルート。
最終報告：実際のケースでは、手順1・2の適用時点でマウスがスリープ後も問題なく自動再接続するようになったとの結果が得られています。根本はOS側の省電力とサービス挙動にあるため、まずはここを正します。うまくいかなければ、ドライバー更新・USB休止の無効化・外付けドングルという順に切り分けていけば、ほぼ解消可能です。
コメント