Windows 11 Bluetooth 5.3でSCO接続がSTATUS_NOT_SUPPORTEDになる原因と対処法

Windows 11＋Bluetooth 5.3（Intel アダプタ）環境に変えてから、HFP/HSP の SCO 音声リンクだけがなぜか張れない・STATUS_NOT_SUPPORTED が返る――そんな現象にハマっていませんか。本記事では、公式フォーラムで受理された回答内容をベースに、BRB_SCO_OPEN_CHANNEL_RESPONSE を使った SCO 着信応答が Windows 11 Bluetooth 5.3 世代で失敗する原因候補と、実務で役立つ切り分け・回避の具体的な手順を詳しく整理します。

症状の整理：Windows 11＋Bluetooth 5.3 で SCO 着信応答が失敗

今回の現象をあらためて整理すると、ポイントは次のとおりです。

OS：Windows 11（22H2 以降、Bluetooth Core 5.3 をサポート）
Bluetooth アダプタ：Intel 製、Bluetooth 5.3 対応ドライバー
用途：HFP/HSP の音声用 SCO リンク（ハンズフリー通話用音声チャネル）
操作：SCO 着信要求に対して BRB_SCO_OPEN_CHANNEL_RESPONSE で応答
結果：brb->PacketType や brb->ContentFormat をどう変えても
戻り値が STATUS_NOT_SUPPORTED (0xC00000BB) になる
同一コードは「Windows 11 だが Bluetooth 5.3 以前」の環境では成功していた
BRB_SCO_GET_SYSTEM_INFO の結果は以下のとおりで、一見 SCO 自体はサポートされている：
- Features = 3
- MaxChannels = 2
- PacketTypes = 0x3F
- DataFormats = 0x0F

実際に OSR フォーラムに投稿されたコード断片は次のようなイメージです。

brb = (struct _BRB_SCO_OPEN_CHANNEL*) &amp;(connection-&gt;ConnectDisconnectBrb);
devCtx-&gt;ProfileDrvInterface.BthReuseBrb((PBRB)brb, BRB_SCO_OPEN_CHANNEL_RESPONSE);

brb-&gt;Hdr.ClientContext[0] = connectionObject;
brb-&gt;BtAddress            = ConnectParams-&gt;BtAddress;
brb-&gt;ChannelHandle        = ConnectParams-&gt;ConnectionHandle;
brb-&gt;Response             = SCO_CONNECT_RSP_RESPONSE_SUCCESS;
brb-&gt;TransmitBandwidth    = 8000;
brb-&gt;ReceiveBandwidth     = 8000;
brb-&gt;MaxLatency           = 0xFFFF;
brb-&gt;PacketType           = 0x3F;
brb-&gt;ContentFormat        = SCO_VS_IN_CODING_LINEAR |
                             SCO_VS_IN_SAMPLE_SIZE_16BIT |
                             SCO_VS_AIR_CODING_FORMAT_CVSD;
brb-&gt;RetransmissionEffort = SCO_RETRANSMISSION_MIN1_QUALITY;
brb-&gt;ChannelFlags         = SCO_CF_LINK_SUPPRESS_PIN;
brb-&gt;CallbackFlags        = CALLBACK_DISCONNECT;
brb-&gt;Callback             = &amp;HpSrvIndicationCallback;
brb-&gt;CallbackContext      = connectionObject;

status = SendBrbAsync(..., (PBRB)brb, sizeof(*brb), ...);

この呼び出しが Windows 11 + Intel Bluetooth 5.3 ドライバーでは常に STATUS_NOT_SUPPORTED を返してしまいます。

環境と症状を表でざっくり俯瞰

項目	内容
OS バージョン	Windows 11（22H2 以降、BT 5.3 対応）
Bluetooth	Intel アダプタ＋Bluetooth 5.3 ドライバー
用途	HFP/HSP の SCO 音声リンク（着信側）
API	`BRB_SCO_OPEN_CHANNEL_RESPONSE` で応答
エラー	`STATUS_NOT_SUPPORTED (0xC00000BB)`
以前の挙動	Windows 11（BT 5.3 以前）では同じコードで成功
システム SCO 情報	`Features = 3, PacketTypes = 0x3F, DataFormats = 0x0F` など

前提知識：SCO / eSCO と HFP/HSP、Windows 11 の Bluetooth 音声

まずは、この問題に関係するキーワードをざっくり整理しておきます。

SCO（Synchronous Connection-Oriented）：
- Bluetooth Classic (BR/EDR) の音声用リンク。8kHz〜16kHz 程度の narrow band / wide band 音声。
- HFP / HSP の通話音声で使われる。
eSCO：
- 拡張 SCO。再送やパケットバリエーションが増え、品質・レイテンシの調整がしやすい。
HFP / HSP：
- Hands-Free Profile / Headset Profile。ヘッドセットの通話用プロファイル。
- Windows 11 でも HFP 1.7.2 などが in-box でサポートされている。
LE Audio（LC3, BAP, TMAP など）：
- 最近の Windows 11 では、LE Audio 対応・ゲームチャット向けの高音質機能が強化されている。
- 将来的には、従来の HFP + SCO ベースの経路から、LE Audio による音声経路へシフトしていく流れ。

つまり、SCO は「レガシーだが、今も HFP/HSP の根幹」であり、Windows 11 ではその上に「OS 標準の HFP/HSP スタック」や「LE Audio ベースの新しい音声経路」が共存している、という構図です。

BRB_SCO_OPEN_CHANNEL_RESPONSE と STATUS_NOT_SUPPORTED の意味

BRB_SCO_OPEN_CHANNEL_RESPONSE は、Bluetooth プロファイルドライバーが「リモートから飛んできた SCO 接続要求を受けるかどうか」をスタックに伝えるための BRB です。

Microsoft Docs では、この BRB のステータスとして代表的に次の値が挙げられています。

Status	概要
`STATUS_SUCCESS`	BRB は正常に完了し、SCO 接続が成立した。
`STATUS_PENDING`	非同期で処理中。完了はコールバックで通知される。
`STATUS_INVALID_PARAMETER`	BRB 内のパラメータが不正。
`STATUS_INVALID_BUFFER_SIZE`	バッファ長が足りない。
`STATUS_INSUFFICIENT_RESOURCES`	メモリなどリソース不足。
`STATUS_NOT_SUPPORTED`	要求された操作を Bluetooth スタック／ドライバーがサポートしていない。

今回返っている STATUS_NOT_SUPPORTED は、典型的には「その BRB のタイプや操作自体が、そのスタックのポリシー上許可されていない」場合に返されます。単にパラメータの値がバグっているだけなら、普通は STATUS_INVALID_PARAMETER です。

一方で BRB_SCO_GET_SYSTEM_INFO は、「ローカルシステムがサポートする SCO の上限（チャネル数／パケットタイプ／データフォーマット）を問い合わせるための BRB」です。
今回の結果（Features = 3, MaxChannels = 2, PacketTypes = 0x3F, DataFormats = 0x0F）からは、少なくともローカルスタックとしては SCO 自体をサポートしているように見えます。

つまり、「SCO 自体はサポートされているが、BRB_SCO_OPEN_CHANNEL_RESPONSE による着信応答という操作が、特定組み合わせ（Windows 11 + Intel BT 5.3 ドライバー）で ポリシー的にブロックされている 可能性が高い」、というのが現状の解釈になります。

公式フォーラムで受理された回答の要点

Microsoft Q&A に投稿された同様の質問に対し、受理された回答では次のような一般的な対処が提示されています。

Bluetooth ハードウェア／ドライバーのサポート確認
Bluetooth 5.3 と SCO を正しくサポートする最新ドライバー／ファームウェアに更新し、ベンダーのリリースノートも確認すること。
Windows 11 との互換性の確認
対象の Bluetooth デバイス／ドライバーが「Windows 11 対応」と明言されているかどうか、公式サポート情報を確認すること。
Windows Update の適用
オプション更新プログラムを含め、Bluetooth 関連の修正が含まれる更新をすべて適用すること。
別マシンでの再現性確認
同系統の Bluetooth ハードウェアを搭載した別の Windows 11 PC で同じ SCO コードを動かし、現象がシステム固有なのか、ハードウェア固有なのかを切り分けること。
ハードウェア／ソフトウェアベンダーへの問い合わせ
解消しない場合は Bluetooth アダプタ（Intel 等）やソフトウェアベンダーに連絡し、詳細ログを添えて調査を依頼すること。

これらは「原因そのもの」ではなく、あくまで 前提を埋めるためのチェックリストです。実務では、ここを最低限クリアしたうえで、さらに深い切り分けに進む必要があります。

公式回答ベースのチェック一覧

観点	具体的に確認すること
ドライバー	Intel 公式・PC メーカー公式の最新版 Bluetooth ドライバー／FW かどうか
OS	Windows 11 の累積更新・オプション更新をすべて適用済みか
互換性	製品ページ／ドキュメントに「Windows 11 対応」と明記されているか
再現性	別の Windows 11 + 同一 Bluetooth チップ環境でも再現するか
ベンダー問い合わせ	ログ（ETW/HCI）と再現手順を添えて、Intel または PC ベンダーに投げられる状態か

実務で効く「原因切り分け」と「回避」ステップ

ここからは、実際にドライバー開発・検証を行う立場で「次に何をすべきか」を、優先度順に具体化していきます。

1. BRB 呼び出し前提の再確認：本当に“着信応答”になっているか

BRB_SCO_OPEN_CHANNEL_RESPONSE は「リモートからの SCO 接続要求に対する応答専用」の BRB です。Docs では、以下のような流れが明示されています。

BRB_SCO_REGISTER_SERVER で SCO サーバーを登録し、SCO Callback が呼ばれるようにする。
リモートから SCO 接続要求が来ると、SCO Callback に ScoIndicationRemoteConnect が届く。
そのコールバックの中で、受信した _BRB_SCO_OPEN_CHANNEL 構造体を元に BRB_SCO_OPEN_CHANNEL_RESPONSE を組み立てて送る。

ここで次の点をチェックします。

BtAddress／ChannelHandle が直前の ConnectIndication と一致しているか
ConnectParams->BtAddress や ConnectParams->ConnectionHandle が、有効な接続要求から取ってきた値であることを確認します。古い接続のハンドルを流用しているとスタック側で拒否される可能性があります。
Indication から応答までのタイミング
SCO の接続要求に対する応答は、ある程度のタイムアウト内に行う必要があります。遅延しすぎるとスタック側で接続要求を破棄してしまい、その後の応答が「意味のない BRB」とみなされる可能性があります。
CallbackContext / ClientContext
ClientContext や CallbackContext に格納しているオブジェクトが解放済み・未初期化になっていないかも確認します。Docs では、SCO 関連の通知コンテキストとしてこれらを利用することが前提になっています。

簡易チェックとして、「SCO Callback が呼ばれてから何ミリ秒以内に BRB_SCO_OPEN_CHANNEL_RESPONSE を送っているか」をトレースログに出すのがおすすめです。

2. 構造体サイズと WDK のバージョン整合性を疑う

質問のコードでは、BthReuseBrb を使って ConnectDisconnectBrb を BRB_SCO_OPEN_CHANNEL_RESPONSE として再利用しています。これはサンプルコードでもよく見るパターンですが、次のような場合に STATUS_NOT_SUPPORTED になり得ます。

ビルドに使っている WDK が古く、_BRB_SCO_OPEN_CHANNEL の構造体定義が古い。
OS 側の bthport.sys が新しくなり、内部的に期待する構造体サイズが変わっている。
BTH_PROFILE_DRIVER_INTERFACE のバージョンと、BRB の種類の組み合わせが現在のスタックにマッチしていない。

Docs によると、_BRB_SCO_OPEN_CHANNEL は「リモートへの SCO オープン要求」だけでなく、「着信に対する応答」を表現するためにも使われます。
スタックは BRB_HEADER 内のタイプ情報とサイズを見て BRB の解釈を行うため、ヘッダ情報に矛盾があると「この BRB はサポートしていない」と判断される可能性があります。

そこで、一度次のような検証を行うとよいでしょう。

再利用せず、新しい BRB をゼロ初期化して組み立てる
ExAllocatePoolZero などで sizeof(BRB_SCO_OPEN_CHANNEL) を確保し、ヘッダから全フィールドを明示的に初期化してみます。
BRB_HEADER.Size / Type の実際の値をログに出す
brb->Hdr.BrbLength や brb->Hdr.BrbType をトレースし、Docs に書かれた期待値とずれていないか確認します。
WDK／SDK のバージョンを Windows 11 用に揃える
古い WDK（例：Windows 10 向け）でビルドしている場合は、Windows 11 対応の WDK に更新して再ビルドします。

この検証で新規 BRB では成功し、BthReuseBrb でのみ STATUS_NOT_SUPPORTED になる場合、構造体レイアウトかヘッダ情報のずれが濃厚です。

3. パラメータを「超保守的」にして接続テストする

次に、PacketType／ContentFormat／MaxLatency／RetransmissionEffort などのパラメータを、スタックが受け入れやすい「保守的な値」に振ってみます。

BRB_SCO_GET_SYSTEM_INFO で返ってきた PacketTypes = 0x3F, DataFormats = 0x0F は、「スタックが受け入れ可能なビットマスク」です。
その範囲内で、かつ現実的に問題になりにくい設定に絞り込みます。

eSCO 優先：
- 可能なら EV3/EV4/EV5 のみを指定し、HV1/2/3 を外してみる。
- 例：PacketType = SCO_PKT_EV3 | SCO_PKT_EV5; のように限定。
ContentFormat はまずデフォルト：
- カスタムの SCO_VS_* を組み合わせる前に、SCO_VS_SETTING_DEFAULT でテストする。
- 接続が張れたあとで、必要に応じて再設定する方針にする。
RetransmissionEffort を DONT_CARE に：
- 再送ポリシーにこだわらず、SCO_RETRANSMISSION_DONT_CARE 相当でスタックに任せる。
MaxLatency を現実的な値に：
- 0xFFFF のような極端な値ではなく、たとえば 0x0010〜0x00FF の範囲で試す。

イメージとしては次のような「保守設定」を一度試してみると、挙動の変化を観察しやすくなります。

brb-&gt;MaxLatency           = 0x0020;            // ほどほどのレイテンシ
brb-&gt;PacketType           = SCO_PKT_EV3;      // eSCO に絞る
brb-&gt;ContentFormat        = SCO_VS_SETTING_DEFAULT;
brb-&gt;RetransmissionEffort = SCO_RETRANSMISSION_DONT_CARE;

ここで STATUS_INVALID_PARAMETER など別のエラーに変わるなら、「パラメータがポリシーに合わずに落ちている」線が濃くなります。あくまで STATUS_NOT_SUPPORTED のままなら、ポリシーレベルで BRB 自体が拒否されている可能性が高いと考えられます。

4. Windows 11 の HFP/HSP スタックとの「所有権競合」を疑う

Windows 11 では、Bluetooth オーディオの扱いが Windows 10 時代よりも OS 主導になってきています。HFP デバイスの接続状態やハンズフリー経路も、システムのオーディオスタックが積極的に制御します。

その結果として、次のような状況が起こり得ます。

OS 標準の HFP バイパス経路・音声サービスが SCO をすでに掴んでいて、別のカーネルドライバーからの SCO オープンを受け付けない。
特定のデバイスクラス（ヘッドセットなど）については、ユーザーモードのオーディオスタックに専有させるポリシーになっている。

開発中に試せる確認・回避としては：

対象ヘッドセットの「ハンズフリー電話サービス」を一時的に無効化
デバイスのプロパティやサービス一覧から「Hands-free Telephony」等を無効にし、OS 標準の HFP サービスが SCO を掴まない状態を作ってからテストする。
システム側の音声アプリを極力閉じる
Teams / Skype / 通話アプリなど HFP を使い得るアプリをすべて終了させた状態で再現性を確認する。
別クラスのデバイスで試す
同じ SCO コードを、ヘッドセットではなく専用ハード（例：医療機器・バーコードリーダなど）で試してみる。ヘッドセット専用のポリシーに引っかかっているかどうかの切り分けになります。

こうした検証で現象が変わるようであれば、「Windows 11 標準の HFP/HSP スタックとカスタムドライバーが SCO を取り合っている」ことがほぼ確定します。

5. 「OS が拒否している」のか「コントローラが拒否している」のかをログで分離

STATUS_NOT_SUPPORTED が返ってきたとき、それが

カーネルの Bluetooth ポートドライバー（bthport.sys）が、BRB を受け取った直後に返しているのか
HCI コマンドを投げた結果、Bluetooth コントローラ／ファームウェアが「Unsupported Feature/Parameter」などを返し、そのエラーを上位にマップしているのか

を分けて考える必要があります。

そのために使えるのが、ETW（Event Tracing for Windows）と Bluetooth 専用のトレースです。Microsoft は Bluetooth ドライバー開発向けに WPR（Windows Performance Recorder）と ETW を使ったトレース取得を推奨しており、Bluetooth 向けのスクリプトも公開しています。

おおまかな手順は次のようになります。

Windows Performance Toolkit（WPR/WPA）をインストール。
Bluetooth テスト向けの WPR プロファイル（またはバスツールのスクリプト）を使用してトレースを開始。
SCO 着信〜BRB_SCO_OPEN_CHANNEL_RESPONSE 発行〜エラー発生までの操作を再現。
トレースを停止し、.etl ファイルを Windows Performance Analyzer などで解析。
BTHPORT / Bluetooth 関連イベント（BRB 送信・完了、HCI コマンド／イベント）を確認し、
- BRB 完了ステータスがドライバー内部で即座に付与されていないか
- HCI レベルでエラー（Unknown HCI Command, Unsupported Parameter など）が返っていないか

もし HCI でエラーが返っているなら「コントローラ／FW 由来」、そうでなければ「OS スタック／ドライバーのポリシー由来」と判断できます。ベンダーへのエスカレーション時にも、この違いは重要な手がかりになります。

6. 設計面の見直し：カーネルで SCO を握るやり方はいつまで通用するか

Windows 11 では、前述のとおり Bluetooth 5.3 対応に加え、LE Audio / BAP / TMAP など新しい音声プロファイルが順次サポートされており、ゲームチャットや通話の音質改善も進められています。

同時に、HFP デバイスに対するサポートや「HFP Bypass」を使ったオーディオ経路の最適化など、OS 主導の音声ルーティングが推奨されています。

この流れを踏まえると、

カーネルモードの独自 Bluetooth ドライバーが SCO セッションを直接開いて音声ストリームを扱う、という設計は、今後ますます制約を受ける可能性が高い

と言わざるを得ません。

要件によっては、次のような方向性を検討するのが現実的です。

OS が提供する HFP/HSP API やメディアスタックに寄せる
可能な限り、ユーザーモード側から WASAPI / メディア API を通して音声を扱い、SCO の管理は OS に任せる。
LE Audio など別の音声経路へ移行する
新規機能であれば、LE Audio（LC3 コーデック）や BAP/TMAP を前提にした設計へ切り替えることで、従来の SCO ベースの制約を回避できる可能性があります。
どうしてもカーネル側で SCO 管理が必要なら、Windows 11 向けの明示的なサポートをベンダーと調整する
Intel などの Bluetooth チップベンダーと連携し、「BRB_SCO_OPEN_CHANNEL_RESPONSE を使った SCO 着信応答をサポートしてもらう」ことを前提に設計する必要があります。

ここまでの内容を「チェックリスト」で再整理

最後に、今回の Windows 11 + Bluetooth 5.3 + Intel 環境で SCO 着信が失敗する問題に対して、「実務で役に立つチェックリスト」としてまとめます。

ステップ	確認／実施内容	狙い
1. 前提環境の更新	Windows Update・Intel Bluetooth ドライバー・FW を最新化する。	既知バグや互換性問題をまず潰す。
2. 別マシン検証	同じ SCO コードを別の Windows 11 + 同一チップ環境で試す。	マシン固有か、プラットフォーム固有かを切り分け。
3. BRB 前提の確認	SCO Callback からの応答になっているか、BtAddress / ChannelHandle が一致しているか確認。	そもそも「正しい着信応答」になっているかを確認。
4. BRB の構造体整合性	BthReuseBrb をやめて新規 BRB をゼロ初期化で構築し、ヘッダサイズ／タイプをログに出す。	構造体レイアウト不整合や古い WDK 利用をあぶり出す。
5. 保守的パラメータでテスト	eSCO 優先・ContentFormat デフォルト・Retransmission DONT_CARE・現実的 MaxLatency でテスト。	パラメータ由来の拒否かどうかを切り分け。
6. 所有権競合の排除	ハンズフリー電話サービス無効化、音声アプリ終了などで OS 標準 HFP スタックとの競合を疑う。	SCO を OS が専有していないか確認。
7. ETW / HCI ログ取得	WPR + Bluetooth プロファイルで ETW トレースを取り、BRB 完了と HCI レスポンスを確認。	OS 由来の拒否か、コントローラ由来の拒否かを明確にする。
8. 設計方針の見直し	可能なら OS 提供の HFP/HSP API や LE Audio ベースの実装へ寄せる。	将来も通用する構成にシフトし、SCO への依存度を下げる。
9. ベンダーへのエスカレーション	上記ログ・再現手順・環境情報を一式まとめて Intel／PC ベンダー／Microsoft に問い合わせ。	スタック／ドライバーのポリシーやバグの有無を公式に確認。

まとめ：現状は「スタック／ドライバーのポリシー変更 or 制約」の可能性が高い

今回のケースでは、

BRB_SCO_GET_SYSTEM_INFO 上は SCO サポートが報告されているにもかかわらず
BRB_SCO_OPEN_CHANNEL_RESPONSE が常に STATUS_NOT_SUPPORTED を返す
しかも Windows 11 の Bluetooth 5.3 世代から挙動が変わっている

という点から、

「SCO そのものは残っているが、特定の条件（Windows 11 + Intel Bluetooth 5.3 ドライバー）では、カーネルドライバーからの SCO 着信応答を許可しない／強く制約している」

というスタック側のポリシー変更、あるいはドライバー実装上の制約・バグである可能性が高いと考えられます。

開発側でできることは、

まずはドライバー／OS／ファームウェアを最新化し、所有権競合やパラメータ不整合といった「自分側の要因」を潰すこと
それでも解決しない場合には、ETW/HCI ログを添えてベンダーにエスカレーションし、「この組み合わせで BRB_SCO_OPEN_CHANNEL_RESPONSE がサポートされるべきかどうか」をはっきりさせること
中長期的には、SCO ベースのハンズフリー制御から、OS 提供の HFP/HSP / LE Audio ベースの設計へ移行すること

です。

「SCO が使えない＝お手上げ」ではなく、どこまでが自分のコード／設定の問題で、どこからがスタック／ドライバーの制約なのかを線引きし、ビジネス要件と照らし合わせながら、現実的な代替案（HFP API 利用、LE Audio、ユーザーモードへの移行）を検討していくのが、Windows 11 + Bluetooth 5.3 世代での賢い付き合い方と言えるでしょう。

この記事を書いた人

佐藤健司

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

Windows 11 Bluetooth 5.3でSCO接続がSTATUS_NOT_SUPPORTEDになる原因と対処法