Bluetooth 6とは？公開日・6.0〜6.3の違い、Channel Soundingの仕組みと普及状況

Bluetooth 6.0の一般向け公開発表は2024年9月3日です。一方、規格の版履歴には理事会による採択日として2024年8月27日が記録されています。日付が違うのは、同じ出来事を二通りに書いているからではありません。規格の承認と、一般向けの案内は別の手続きです。

表が収まらない場合は、左右にスクロールできます。

Bluetooth 6.xの採択・公開発表と主な変化

版	採択日	公開・発表日	主な変化
6.0	2024-08-27	2024-09-03	Channel Sounding、探索・音声転送・パケット間隔などの改善
6.1	2025-05-05	2025-05-06	プライベートアドレスの更新時刻をランダム化
6.2	2025-11-03	2025-11-04	短い接続間隔、測距への攻撃対策、USB経由の音声転送など
6.3	2026-05-05	2026-05-06	測距の位相補正・精度情報の改善、HCI拡張など

6.1以降は年2回のリリース周期で更新が続きました。これをスマホの買い替え周期と同一視する必要はありません。規格の改訂は、設計者が採用できる機能や接続手順を増やす活動です。すでに販売された機器が、次の版の発表日に一斉に使えなくなるわけではありません。

また、店頭の「Bluetooth 6」という表記だけでは、6.xのどの追加機能が有効なのかは分かりません。以下では6.0で加わった土台を先に説明し、その後の改訂が何を変えたのかを重ねて見ていきます。

6.0の代表的な新機能がChannel Sounding（チャネルサウンディング）です。接続した2台のBluetooth LE機器が電波をやり取りし、互いの距離を推定するための測定データを得ます。1回の測定ステップで先に信号を送る役割をInitiator、応答する役割をReflectorと呼びます。Reflectorは壁や鏡のような受動的な反射物ではなく、無線信号を受けて応答する機器です。

この送信順序と、測定手順全体の開始要求は別です。手順の開始はどちらの役割からも要求できます。また、Bluetooth LE接続のCentral・Peripheralという役割と、測距のInitiator・Reflectorは固定の対応関係ではありません。

従来から受信信号の強さ、RSSIを利用した近接判定はありました。しかし「電波が弱い」原因は、遠いことだけではありません。人体や家具による遮蔽、機器の向き、周囲の反射も影響します。音の大きさだけで話し手までの距離を当てようとすると、声量や壁の有無も考慮しなければならないのと似ています。

Channel Soundingは、強さだけではなく、位相の変化を使うPBRと往復時間を使うRTTを利用します。この二つは、単独または組み合わせて使える測距方法です。規格が扱うのは、そのための信号交換や測定結果の受け渡しです。測定値から最終的な距離を推定するアルゴリズムまで、一つの方式に固定されているわけではありません。

したがって「6.0なら誤差は必ず何cm」とは言えません。同じ機能に対応していても、アンテナ、校正、推定処理、使用環境によって結果が変わります。ここを理解すると、規格対応と製品の測距性能を別々に確認する意味が見えてきます。

電波には周期があり、その周期のどこにいるかを表すのが位相です。同じ道のりでも周波数が変われば波長が変わり、到着時の位相も変わります。PBR（Phase-Based Ranging）は、複数の周波数で得た位相の変化を、距離を知る手掛かりにします。

ただし、一つの位相だけでは「何周進んだか」が分かりません。時計の針だけを見ても、何日が経過したか分からないのと同じです。周波数を変えた複数の測定を使うのは、この繰り返しによる曖昧さを扱いながら、距離に関係する変化を取り出すためです。

1周期後は、また同じ位相

0周期
同じ位相

1周期
同じ位相

2周期
同じ位相

PBRでは、周波数を変えたときの位相の変化も使います。双方向の測定と発振器のずれなどの補正を経て、距離を推定します。

ここで注意したいのは、測った位相に含まれるのが伝搬の遅れだけではないことです。2台はそれぞれ発振器を持つため、そのずれも含まれます。実装では双方向の測定と補正を用います。「片方が送った波のずれを、そのまま距離に換算する」という一工程ではありません。

表が収まらない場合は、左右にスクロールできます。

測距で得られる情報を混同しない

方法	主に見る情報	読み方の注意
RSSIによる推定	受信信号の強さ	距離以外の遮蔽・向きなどにも影響される
PBR	周波数を変えたときの位相の変化	位相の繰り返し、発振器のずれ、反射経路を扱う必要がある
RTT	信号の往復に要する時間	応答待ちと回路の遅れを、伝搬時間と分ける必要がある

部屋の中では、直接届く電波に加えて壁などで反射した電波も届きます。こうした複数経路をマルチパスと呼びます。周波数やアンテナ経路を変えて測る価値はありますが、障害物の影響が消えるわけではありません。宣伝の「cm級」は、どの環境・距離・成功率で評価した値なのかまで読む必要があります。

RTT（Round-Trip Timing）は、信号が行って戻る時間から距離を求めます。ただし、Aが送ってから返事を受け取るまでには、Bが応答を準備する時間も含まれます。この待ち時間を、電波が空間を進む時間から分けなければなりません。

RTTで測るのは、応答待ちを除いた電波の往復時間

A

B

A：この信号交換で先に送る側（Initiator）
B：応答する側（Reflector）

緑の斜線：電波の伝搬
赤茶色の縦線：Bでの応答待ち
時間は上から下へ進みます。距離・時間の縮尺は省略しています。

片道距離 ≈ 光速 ×（Aで測った経過時間 − Bの応答待ち時間）÷ 2

感覚をつかむために、編集部の単純化した計算例を考えます。光速を約3億m/sとすると、片道1mの伝搬時間は約3.33ns、往復では約6.67nsです。1nsは10億分の1秒です。往復の時間見積もりが1nsずれるだけで、距離の見積もりには約15cmの差が生じます。

この例は、製品の誤差を予測する式ではありません。測距に、精密な無線回路側の時間計測や補正が必要な理由を示しています。スマホアプリから送信APIを呼び、返事のコールバックまでをストップウォッチで測っても、OSの待ち時間などが入り込み、同じ測定にはなりません。

PBRとRTTを併用する意味もここにあります。一つの観測量だけを信用するのではなく、異なる手掛かりを組み合わせて距離の曖昧さや不自然な測定を扱います。それでも安全性は測距機能だけで完結しません。鍵の用途なら、近くにいることと、解錠する権限があることは別々に確認する必要があります。

Channel Soundingの紹介では、10cm級の測距への期待が語られてきました。例えばSIG掲載の2023年11月の記事は、規格策定前の性能を扱ったものです。その数値を、現在の全製品の保証値として引用することはできません。現行の技術解説でも、距離推定アルゴリズムは規格が指定しないと説明しています。規格名は、すべての対応製品に対する精度保証ではありません。

約150mという数字にも注意が必要です。これは1MHzの周波数間隔を使うPBRで、位相の繰り返しによる距離の曖昧さが現れる目安として説明される値です。「一般のタグが150m先から必ず見つかる」「その距離でもcm精度」という保証ではありません。到達距離には送信出力や受信感度、アンテナ、周囲の環境も関係します。

また、距離と位置は違います。スマホから2m離れていると分かっても、それだけでは右か左か、壁の向こうかは決まりません。方向の推定や地図上の位置表示には別の観測や処理が必要です。距離表示のイメージから、あらゆる製品に方向矢印が出ると想像しない方がよいでしょう。

「2m先」は分かっても、どちらにあるかは決まらない

中心：スマホ
紫の点：相手機器があり得る場所の例

どの候補も中心から同じ2m。距離だけでは、一つに絞れません。

方向・位置の特定には、別の観測や処理が必要です。

UWBも近距離の測距に使われますが、BluetoothのChannel Soundingとは別の無線技術です。Androidの測距APIも両者を別の方式として扱います。用途が重なることと、互換であることは違います。UWB用タグがBluetooth 6スマホにつながったとしても、それだけでChannel Sounding測距へ自動変換されるわけではありません。

機器を比べるなら、「UWBかBluetoothか」という二択より、対応端末、アプリ、測距できる相手、利用環境、電池持ちを一組で確認する方が実用的です。本記事では、条件の異なるメーカーのデモ値を並べて精度の優劣を決めることはしません。

6.0は測距だけの更新ではありません。Bluetooth LE機器は、自分の存在や情報を知らせるアドバタイズという信号を出します。受信側があらゆる続きの情報を追い掛けると、不要な受信にも時間を使います。Decision-based Advertising Filteringは、最初に受けた情報を判断材料に、関連する追加パケットを追うか選べるようにする改善です。ここでのadvertisingは広告表示ではありません。

Monitoring Advertisersは、注目している相手がまだ観測できているかをホスト側が把握するための改善です。重複通知を省いて省電力にしても、以前見つけた機器が今も近くにいるとは限りません。「通知を減らす」と「相手の状態を知る」の両立に意味があります。

音声関連では、ISOALというデータを転送単位へ整える層に改善が入りました。新しいフレーミング方式は、データを分割することに伴う遅延などを減らすためのものです。これは音声コーデックそのものの置き換えではなく、6.0という数字だけで音質が決まるわけでもありません。

さらに、接続内のパケット間隔を、従来の固定150µsから、対応機器どうしで調整できるようにしました。これは後述する6.2の「接続間隔」短縮とは別です。駅のホームで車両どうしの間を詰める話と、列車の発車頻度を増やす話を分けるように、どの待ち時間を変えているのかを区別すると理解しやすくなります。

6.0と6.2は、短くする「間隔」が違う

6.0：パケットの終わりから、次のパケットの始まりまで

緑の括弧＝パケット間隔。従来の固定150µsから調整可能に。

6.2：接続イベントの開始から、次の開始まで

赤茶色の括弧＝接続間隔。SCIで下限を短縮します。

6.1：アドレスだけでなく、更新する時刻も変える

Bluetooth LEには、固定の識別子を出し続けないためにResolvable Private Address（RPA）を使う仕組みがあります。6.1のRandomized RPA Updatesは、更新のタイミングをランダム化し、時刻の規則性を手掛かりにした追跡を難しくします。更新処理をコントローラー側で扱うことによる省電力面の利点もあります。

ただし、これは「あらゆる追跡が不可能になる」という意味ではありません。アプリが送る情報、サービス側の識別、利用者が許可した位置情報とは別の層の対策です。住所の表札を変えても、本人が別の場所で名乗れば識別されるのと同じで、一つの仕組みを匿名性全体の保証へ広げてはいけません。

6.2：375µsは条件付きの下限であり、総遅延ではない

Shorter Connection Intervals（SCI）は、LE接続の通信機会の間隔を短くする拡張です。従来の下限7.5msに対し、SCIの基本範囲は1.25msから、追加の拡張範囲では375µsまで短くできます。375µsへの対応は、SCI対応機器すべてに一律で必須ではありません。

短くなるのは、まず「通信の機会どうしの間隔」

従来の下限：7.5 ms
SCIを使わない接続の基準

SCIの基本範囲の下限：1.25 ms
RCV：SCI対応時の必須範囲

SCIの追加拡張の下限：0.375 ms
ECV：追加対応と条件の確認が必要

7.5ms ÷ 0.375ms = 20なので、間隔の下限同士は20倍違います。しかし「ゲーム操作が20倍速い」「音声遅延が375µs」という意味ではありません。入力を取得する時間、OSの処理、待ち行列、再送、音声の符号化・再生などは別に残ります。短い間隔を選ぶ際には、消費電力や無線の混雑との兼ね合いも考える必要があります。

6.2には測距信号の振幅を操作する攻撃への対策、ホストとコントローラーをUSBで接続する場合のLE音声データ転送、無線試験の改善も含まれます。「短い接続間隔」だけで版全体の更新を説明し切れるわけではありません。

6.3：測距を支える補正と能力の伝達を改善する

6.3のInline PCT Transferは、Reflector側で位相を補正して応答する仕組みを加えます。従来の双方向測定・補正の考え方を保ちつつ、測定結果の受け渡しや処理の負担を減らすための改善です。利用には両端の対応と機能の有効化が必要です。

加えて、RTTの精度に関する能力をPHY（無線の物理方式）ごとに伝えられるようになりました。HCIのコマンド・イベントを表す領域の拡張なども含みます。これらは、仕様表の数字だけで伝わる派手な変化というより、実装を正しく組み合わせるための改良です。「6.3なら誰でも精度が何倍」という比較はできません。

公式資料から確認できるのは、一般向けスマホへの採用に加え、スマホのアプリと開発キットで距離を測る評価例まで公開されているという状況です。一方、Bluetooth 6搭載端末の台数や、Channel Soundingを日常的に使っている人の割合までは、以下の資料から算出できません。本記事は市場シェアや日本国内の普及率を推定しません。

表が収まらない場合は、左右にスクロールできます。

公式資料で確認できる採用例と、そこからは分からないこと（2026年11月10日確認）

対象	確認できる記載	この資料だけでは断定できないこと
Apple iPhone 17	仕様にBluetooth 6。UWBは別の項目として記載	すべての6.x追加機能や、任意のタグとのChannel Sounding利用
Google Pixel 10	仕様にBluetooth v6、アンテナダイバーシティを記載	すべての測距アプリ・相手機器への対応
Samsung Galaxy S26 英国向けSM-S942BLBHEUB	確認した公式仕様はBluetooth v5.4	別モデル・別地域の仕様への一般化
Android 16以降のRanging API	BLE Channel Sounding、BLE RSSI、UWB、Wi-Fi RTTを扱うAPI	Android 16搭載の全端末に、全方式のハードウェアがあること
Nordic nRF54L15 DK	2台の開発キットでInitiator・Reflectorのサンプルを試せる	そのまま市販タグとして使えることや、全スマホとの接続保証
Pixel 9/10とnRF Toolbox	NordicがnRF54L15 DKとの測距を案内。必要なOS・アプリ・SDKは本文に記載	市販探索サービスへの対応、全端末・全環境の精度保証

iPhone 17とPixel 10のような採用例があっても、「新しいスマホは全部6」とは言えません。逆に、5.xの製品があることをもって「6はまだ製品化されていない」とするのも誤りです。同じ市場で複数の世代が併存しています。

NordicはnRF54Lシリーズについて、nRF Connect SDK 3.0.1以降で認証済みのホスト・コントローラーによるChannel Sounding対応を案内しています。これは開発者が試せる土台があることの証拠です。しかし、開発サンプルが動くことと、消費者が買ったタグを既存の探索サービスへ登録できることは同じではありません。

より具体的には、NordicはPixel 9/10とnRF54L15 DKを組み合わせる開発・評価用の手順を公開しています。Android 16 QPR2、nRF Toolbox 4.1.4以降、nRF Connect SDK 3.0.1以降を使い、DKにはReflectorサンプルをandroid_ranging.conf付きでビルドして書き込みます。スマホから接続・ペアリングすると、スマホ側の測距機能を利用してアプリに距離を表示する構成です。これはメーカーが案内する評価例であり、編集部の実機検証ではありません。手順書にはAndroid 17の案内もありますが、本稿では正式版QPR2での構成を例にし、個別のベータ版の検証結果を全OS版へ一般化しません。

Android側にもAPIがありますが、公式ガイドは利用時に機器の能力と、その時点で利用可能かどうかを調べる手順を示しています。OSの版だけで機能を決め打ちする設計は適切ではありません。端末の仕様表とOSのAPI説明は、互いの代わりにはならない資料です。

利用できる場面にも制限があります。AndroidのRangingモジュールを使う第三者アプリでは、バックグラウンド測距は対応端末のUWBに限られ、Channel Soundingでは許可されません。アプリを前面で操作して距離を確かめることと、別のアプリを使っている間も常時測り続けることは分けて考える必要があります。これは当該Android APIの制約であり、メーカー独自のシステム機能や組み込み機器全般に同じ制限があるという意味ではありません。

「Bluetooth 6搭載」から「距離が分かる」まで

スマホ側
対応する無線部

相手機器側
対応する無線部

両端がChannel Soundingに対応

ファームウェア・OS
機能を有効にし、測定データを扱う

アプリ・サービス
対応する相手と測距し、結果を取得・表示する

利用時の条件
権限・設定・電波条件・前面での利用など

AndroidのRangingモジュールを使う第三者アプリでは、Channel Soundingのバックグラウンド測距は許可されません。機器が対応していることと、常時測れることは別です。

以上からの編集上の判断は、Bluetooth 6の採用は実製品に届き、Channel Soundingも具体的な組み合わせで試せる一方、一般の探索サービスでの利用条件は個別確認が必要というものです。開発者が評価できる段階と、市販タグを普段のアプリですぐ使える段階は同じではありません。

Bluetooth 6なら音が良い？

音質の比較に必要なのは、使用するコーデック、プロファイル、送受信側の対応と実際の接続設定です。LE Audio・LC3・Auracastを、6.0という版番号の別名として扱ってはいけません。詳しくは既存記事「Bluetooth LE AudioとAuracast」で解説しています。

古い機器とはつながらない？

新しい版だから古い機器との通信が一律に禁止されるわけではありません。ただし、両端が使える無線方式・プロファイル・機能が必要です。「接続できる」ことは「新機能も使える」ことではありません。昔のイヤホンが接続できても、距離測定や新しい音声方式へ自動的に変わるわけではないのです。

ソフトウェア更新で6へ変えられる？

更新で有効になる機能もありますが、測距に必要な無線回路やタイミング制御を備えない機器へ、ソフトだけで何でも追加できるわけではありません。メーカーが対象モデルと対応機能を明示しているかを確認します。チップが理論上対応しているという説明を、製品の更新予定へ読み替えるのも避けるべきです。

7.0が出た今、6は避けるべき？

Bluetooth SIGは2026年11月4日に、Core 7.0のオプション機能HDTの採用を発表しました。しかし、新規格の発表は、その日の店頭製品が入れ替わることを意味しません。必要な機能を満たす製品を選ぶことと、将来の仕様を追うことは分けて考えられます。本記事では7.0の機能を6.xへ混ぜず、別の更新として扱います。

購入する人は、まず「何をしたいか」を一つ決めると確認しやすくなります。音楽を聴きたいなら音声機能、鍵を探したいなら対応する探索サービスと測距方式、低遅延の入力機器が欲しいならその接続方式での動作条件です。すべてをBluetoothの版番号一つで評価しようとすると、判断を誤りやすくなります。

• 仕様：Bluetoothの版とは別に、目的の機能名が書かれているか。
• 相手：自分のスマホ・PC・タグとの組み合わせが明記されているか。
• ソフト：OS、アプリ、ファームウェアの最低条件と提供時期は何か。
• 性能：精度・遅延の数字に、試験環境と測定対象が付いているか。
• 提供段階：発売済み、開発キット、将来の更新予定を区別できているか。

開発者なら、これに測定失敗時の扱いを加えます。例えば鍵の解錠を考えるなら、瞬間的に距離が短く見えた結果だけで許可するのか、測定の不確かさや不自然な結果をどう扱うのかが設計課題です。ここは規格の採用だけで自動的に解決する部分ではありません。

Bluetooth 6.xの価値は、単に数字が一つ上がったことではなく、近くの機器との関係をより細かく扱えるようになったことにあります。6.0で測距などの土台が加わり、6.1でアドレス更新、6.2で接続間隔や安全性、6.3で測距の補正・能力伝達が改善されました。

規格は設計の共通言語、製品はその実装、利用体験は相手機器とソフトも含めた結果です。この三つを分ければ、「6が普及し始めたのに、もう7」という状況も矛盾しません。新しい仕様を作りながら、前の世代の実装とサービスが広がっていく。その時間差まで含めて見るのが、Bluetoothの進化を理解する近道です。