Bluetooth 7.0とは？6との違い・HDT最大7.5Mbpsの仕組みと対応状況

Bluetooth Core Specification 7.0の日付は2026年11月2日です。Bluetooth SIGの機能概要は11月3日、HDTの採択を知らせるプレス発表は11月4日。これらは同じ出来事の日付違いではなく、仕様文書・解説資料・ニュース発表という別々の記録です。

「Bluetooth 7は2027年から」とだけ覚えると、ここを取り違えます。すでに成立したCore仕様と、その上で製品を動かすための応用仕様や実装には時間差があります。SIGが2027年を見込むと述べたのは、HDTの最初の主要用途となる、標準化された高品質ワイヤレスオーディオの展開です。特定のスマホやヘッドホンの発売を約束した発表ではありません。

読者として大切なのは、「いつ規格ができたか」と「自分の組み合わせで何が動くか」を別の問いにすることです。本記事では前半で規格を、後半で確認できた実装状況を扱います。将来の見通しを現在使える機能の一覧へ混ぜないためです。

6系にも複数の改訂があり、6.0と6.3は同じ内容ではありません。6.0で注目されたChannel Soundingは、電波を使って機器間の距離を推定する仕組みです。一方、7.0のHDTが主に変えるのはデータを運ぶ能力。距離を測る機能と、多くのデータを送る機能は目的が違います。

この表は各版の代表的な変更を選んだもので、エラッタを含む全変更の一覧ではありません。7.0は6の測距を捨てて音声専用になるのではなく、従来の仕組みに転送・制御・暗号化の選択肢を追加します。版を「音質の等級」として読むより、必要な機能名を個別に確認する方が確実です。

測距のPBR・RTTや6系の細かな差は、Bluetooth 6の仕組みと普及状況を解説した記事にまとめています。ここからは、7.0で加わったHDTを中心に掘り下げます。

PHYは、ビット列をどのような無線信号へ変え、受信側で取り戻すかを定める物理層です。従来のLE 2Mは2 Mbps。HDTの最大7.5 Mbpsと比較すると7.5 ÷ 2 = 3.75倍ですが、これはPHYのレート同士の比較です。ファイル転送が必ず3.75倍になる、音が3.75倍よくなる、と読み替えることはできません。

HDTはCore 7.0の任意機能です。さらにHDTを実装した場合でも、HDT2・HDT3・HDT4が基本の必須レートで、HDT6・HDT7.5は追加の任意対応です。7.5 Mbps対応の受信には6 Mbps受信も必要で、7.5 Mbps送信には6 Mbps送信と7.5 Mbps受信も必要になる、といった送受信別の要件もあります。「HDT対応」の一言だけでは最大レートまで確定しません。

相手と共通に使える能力や通信条件も関わります。買う側にとっては、仕様欄の版番号だけでなく、HDTの有無、必要な送受信レート、接続する相手を確認することになります。開発側も、単一の固定速度を前提にせず、実装が報告する能力を扱う必要があります。

なお、今回のHDTは2.4 GHz帯のBluetooth LEを拡張するものです。Wi-Fiを併載するチップの5 GHz・6 GHz対応や、別の高周波数帯への拡張構想を、HDTそのものの周波数と混ぜないようにします。

無線では、受信側が区別できる信号の状態へビットを対応付けます。この区切りをシンボルと呼びます。選べる状態が4通りなら2 bit、8通りなら3 bit、16通りなら4 bitを表せます。HDTはπ/4 QPSK、8PSK、16QAMという変調方式を使い分けます。

ただし、状態を増やすだけでは不十分です。信号が雑音や伝搬の影響でずれたとき、どの状態だったか判別する必要があります。そこでHDTは誤り訂正（FEC）も使います。情報に冗長性を加えることで受信側の復元を助けますが、その分も無線で運ぶ必要があります。「1シンボル4 bit」と「利用できる情報が毎回4 bit」は別の話です。

HDTのシンボルレートは毎秒200万シンボルです。これに変調のビット数と実効符号化率を掛けると、各レートの由来が分かります。符号化率は、符号化後のビット列に対する情報ビットの割合です。高いほど冗長性に使う割合は小さくなります。

HDT7.5：2,000,000 × 4 × 15/16 = 7,500,000 bit/s = 7.5 Mbps。一方、HDT2は2,000,000 × 2 × 1/2 = 2,000,000 bit/sです。同じ2 MbpsでもLE 2MとHDT2は別方式であり、同じ名前の速度が同じ無線実装を意味するわけではありません。

ここから導けるのは、最高レートが唯一の正解ではないということです。送れる情報量と、無線信号を安定して判別する条件を両立させる必要があります。最高値だけを示す広告より、どのレートをどの条件で使えるかという説明の方が、実用上の判断に役立ちます。

通信には、運びたいデータ以外の時間も必要です。受信の同期、ヘッダー、応答、送信の間隔があり、失敗すれば再送も発生します。アプリで観測する速度は、これらを含む全経過時間で、実際に届いたデータ量を割った値です。

HDTの高速化は変調だけではありません。データをまとめる仕組みや、ブロック単位の確認・再送も備えます。長い転送の一部が失われたとき、失敗した部分を扱いやすくする設計です。ただし、どのパケット形式や追加機能を使うかまで、すべての製品で同じとは限りません。

短いパケットでは、HDTがLE 2Mより遅くなる場合もあります。Nordicの技術解説が指摘するように、パケットには同期や制御などに使う固定の時間があります。運ぶデータが少ないと、その時間の割合が大きくなり、無線の最高レートを上げても転送全体では不利になることがあります。反対に、長いパケットで多くのデータを運ぶ用途では、この負担をデータ量に対して小さくできます。どの程度のデータ量から有利になるかは実装や通信条件に依存するため、一律の境界値ではなく、実際に送るデータ量・頻度で比較する必要があります。

例えば1 MBを8,000,000 bitとする十進表記なら、7.5 Mbpsでそのビットだけを運ぶ理想計算は約1.07秒です。しかし、それを製品の転送時間として掲載するのは不適切です。実際には制御情報や通信条件、ホスト側の処理が加わります。ファイルのMBとMiBの違いまで含め、比較時には測定条件が必要になります。

電池についても同様です。同じデータを短時間で送り終えられれば、無線部を休ませる余地が生まれます。一方で、高いレートを維持する処理や製品全体の消費電力もあります。これは省電力化の可能性であり、HDT搭載だけで電池寿命が一定割合伸びるという意味ではありません。

音声のデータ量を考えると、帯域の意味が具体的になります。非圧縮PCMの必要量は、サンプリング周波数 × 量子化ビット数 × チャンネル数です。ステレオなら2チャンネルとして計算します。

4.608が7.5より小さいからといって、96 kHz / 24 bitのロスレス再生が全製品で成立するとは言えません。音声データだけの量と、無線リンクの最大PHYレートを引き算しても、必要な余裕や相互接続の条件は決まりません。可逆圧縮を使えばデータ量は内容によっても変わります。

HDTは運ぶ仕組み、コーデックは音声を表現する仕組みです。高い転送能力は音声設計の余地を増やしますが、音声方式やプロファイル、双方の実装を省略できるわけではありません。「HDTならコーデック不要」「既存の音源が自動的に高音質化する」とは書けません。

この区別は買い替え判断にも直結します。Bluetooth 7.0と書かれた片方の機器だけを用意しても、もう片方やソフトが必要な機能に対応していなければHDTの利点は得られません。逆に、現在の機器で目的の音声方式が安定して使えているなら、新しい版番号だけを理由に買い替える必然性はありません。音質は無線の版番号だけで決まらないからです。

7.0のもう一つの方向性は、接続を続けながら状況に合わせやすくすることです。IPU（LE Isochronous Parameter Update）は、時間をそろえてデータを届ける接続型のストリーム、CISの伝送設定を変更する仕組みです。ストリームを作り直す代わりに、事前に用意した設定へ協調して切り替えます。音声の用途変更や電波状態への適応に役立つ可能性がありますが、どんな変更でも無音・無遅延で行えるという保証ではありません。

EKS（Encryption Key Schedule）は、鍵の導出・分離・更新の枠組みです。TAK（Transient Application Key）は、上位アプリ側で認証と鍵の確立を行い、その鍵でリンクを暗号化するための仕組み。短期間のやり取りで、従来型のペアリングや鍵の長期保存に頼らない選択肢を提供します。ペアリングに頼らないことと、相手を確認しなくてよいことは別です。

暗号化通信を開発・相互接続試験で解析するためのEPDも追加されています。これらは通信の制御・安全性・検証を支える変更であり、単純な音質向上機能としてまとめない方が内容を正確に理解できます。利用する機能に応じた実装と評価が必要です。

今回の調査では、仕様採択、メーカーによるHDT対応の説明、実シリコンでの実証、OSのAPIという段階までは一次資料で確認できました。一方、それらを足し合わせても、今買えるスマホとイヤホンがHDT音声で相互接続できるという証明にはなりません。

Qualcommの例は、見出しだけで判断しない重要性を示します。HDTという機能名と、現行の仕様版欄・ドラフト注記が併存しています。本記事ではそれを勝手に「Bluetooth 7.0製品として発売済み」と読み替えません。メーカーが最終仕様への適合や搭載製品を明記した時点で、別の確認が必要です。

Nordicの発表は、アイデアだけでなく実シリコンの段階へ進んでいる根拠になります。ただし、当該ニュースは仕様採択前の10月発表であり、本文中の「年内に仕様公開予定」は当時の見通しです。現在の規格状態は11月のSIG発表と合わせて読む必要があります。

Androidでは、BluetoothAdapter.isLeHighDataThroughputPhySupported()が対応状態を返し、BluetoothDevice.PHY_LE_HDTなどでHDTのPHYを表します。APIがあることは開発基盤が整いつつある根拠ですが、ハードウェアがない端末に無線方式を追加する魔法ではありません。非対応や状態不明も扱う設計が必要です。

今回確認した公式資料の範囲では、HDTの利用を明示した市販スマートフォンとイヤホンの組み合わせ、および市場普及率は確認できませんでした。これは市場の全製品を調査して「存在しない」と証明した意味ではありません。iOS・Windowsも、資料が見つからなかったことだけで一律に非対応とは断定しません。地域やモデル別の正式仕様がそろった段階で追記するのが妥当です。

Bluetooth 7.0を待つべきかは、現在困っていることによります。紛失物の距離を測りたいなら、HDTの最高速度よりChannel Soundingの実装と対応アプリが重要です。音楽を聴きたいなら、今使うスマホと相手側の共通音声方式、接続の安定性、装着感なども判断材料になります。大きなセンサーログやファームウェアを転送したい開発者には、HDTの実効速度と消費電力を測れる評価環境が重要です。

一方、センサーの値など少量のデータを頻繁に送る用途では、LE 1M・LE 2Mも比較対象に残ります。大きなログを一括転送する場面と、短い通知を繰り返す場面を分け、速度だけでなく待ち時間と消費電力も測って選ぶのが実用的です。

• 機能名：HDT対応なのか、必要な送受信レートまで対応するのか。
• 利用可能な状態：予告・試作・SDK対応・製品での有効化のどの段階なのか。
• 相手とソフト：通信する両端、OS、ファームウェア、音声方式がそろうのか。
• 測定条件：最大PHYレートか、実効転送速度か。距離・干渉・再送・電力の条件が示されているか。

ソフト更新で対応できるかも、版番号だけでは決められません。必要な無線回路がなければHDTを追加できず、回路があってもメーカーの実装・有効化・検証が必要です。「すべて買い替え」「すべて更新で対応」のどちらも、個別の根拠なしには言えません。

今回の進歩を一言でまとめるなら、Bluetooth LEが運べる情報量を増やし、通信中の適応と鍵管理も拡張したということです。規格の成立は重要な出発点ですが、利用者の価値になるのは両端とソフトがそろったとき。新しい数字に期待しつつ、機能・条件・実装段階を確かめる読み方が、Bluetooth 6から7へ移る時期には特に役立ちます。