web会議でBluetoothイヤホンの音が悪い｜通話中だけ落ちる

2026年10月8日

机を左右に分けた図。左は目を閉じて音楽を聴いている人で、ノートパソコンからイヤホンへ太い管が2本伸び、中を背の高い波が流れている。右は同じ人が商談の画面に向かって話していて、管は細い1本だけになり、中の波は平らにつぶれている。2つの机のあいだにマイクが1本立っている

音楽を聴いている分にはいい音なのに、商談が始まると同じイヤホンの音がこもる。相手の声が遠く、こちらの声も「少し聞き取りにくい」と言われる。回線を疑って有線LANに替えても変わりません。替わっているのは回線ではなく、イヤホンとパソコンのあいだで使われている通信の方式です。 いつ切り替わるのか、なぜミュートでは戻らないのか、どの数字がどこまで落ちるのかを、Microsoft・Apple・Google の公式記述で確かめました。出典は本文に置きます。

この記事の内容

上位が書いていること、そこで止まっていること
方式はひとつずつ。どちらかしか選べない
落ちる幅は「低音質」ではなく、8kHzか16kHz
切り替わるきっかけは、話し始めた瞬間ではない
画面に出てくるものが、OSの版で違う
直す方法は公式に書かれている。ただし機械を替える話
うちは、何を選ばせていないか
商談で打てる手
分からなかったこと
Meetnect の場合
参考

上位が書いていること、そこで止まっていること

「Bluetoothイヤホン通話中だけ音が悪い」で検索すると、原因の説明はだいたい揃っています。高音質で再生する方式と、マイクが使える方式が別々にあって、マイクを使うと後者へ切り替わる。だから音がこもる。ここは正しく、争う気はありません。

対策として並んでいるのも、ほぼ同じ3つです。別のマイクを使う、パソコン側で「ハンズフリーテレフォニー」を無効にする、イヤホン側の接続を切り替える。

ただ、3つとも「聴くほうが大事な場面」を前提に書かれています。 出てくる例もゲーム配信や通話アプリの併用です。商談はそうではありません。聴こえることと、相手に聴こえることの両方が要るので、同じ対策がそのまま使えません。上位に無いのはこの部分です。

方式はひとつずつ。どちらかしか選べない

まず仕組みを、言葉の定義まで下げて確かめます。

Microsoft は、ステレオで再生する方式と、マイクが使える方式を分けて書いています。「Bluetooth Classic audio supports stereo audio playback over the Advanced Audio Distribution Profile (A2DP) and mono playback and capture over the Hands-Free Profile (HFP).」（Microsoft Learn）。

そして、片方にはできないことが明記されています。「A2DP only supports audio output from the host to the audio device. When audio capture (for example, voice capture using the microphone in the audio devices) is used, it's necessary to use HFP instead.」

高音質の側には、マイクが存在しません。 だから「高音質のまま、このイヤホンのマイクで話す」という選択肢そのものが無いということです。上位の対策2つ目（ハンズフリーテレフォニーを無効にする）は、ここで意味がはっきりします。無効にすると音は良くなりますが、そのイヤホンのマイクは使えなくなります。 ゲームなら正解で、商談では、口から離れたパソコン内蔵マイクで1時間話すことになります。

Apple も同じ言い方です。「A2DP is a stereo, output-only profile intended for higher bandwidth audio use cases, such as music playback.」（Apple Developer）。マイクを使える側は別の項目として立っていて、「An option that makes Bluetooth Hands-Free Profile (HFP) devices available for audio input.」（Apple Developer）と書かれています。

どちらも有効なときの優先順位も書いてあります。「when a single device supports both the Hands-Free Profile (HFP) and A2DP, the system gives hands-free ports a higher priority for routing.」両方できる機器なら、マイクが使える側が勝ちます。

落ちる幅は「低音質」ではなく、8kHzか16kHz

上位の説明は「低音質・モノラル」で止まっています。数字は Microsoft の表に書かれていて、2段階あります。

Narrowband speech … 「Operation of HFP at an 8 kilohertz (8kHz) sampling rate using the SBC codec」
Wideband speech … 「Operation of HFP at a higher 16 kilohertz (16kHz) sampling rate using the mSBC codec」

同じ「通話モード」でも、8kHzと16kHzで倍違います。そしてどちらになるかは選べません。 同じページに、落ちる条件が注として書かれています。「Some wideband capable audio devices aren't compatible with the Bluetooth radio in select Windows devices, causing these devices to revert to narrowband mode.」16kHzに対応したイヤホンでも、パソコン側の無線との組み合わせで8kHzに戻るという意味です。

ここに、商談での実務的な線が1本あります。16kHzという数字は、文字起こしに送る音の品質とちょうど同じです。 自分たちのツールは、文字起こしに回す音を16kHzまで落としています（public/room.html 2381行の srOut=16000。理由は音が聞き取りにくいときの話に書きました）。つまり16kHzで繋がっているBluetoothイヤホンは、文字起こしの側では何も失っていません。 損をしているのは耳だけです。

ところが8kHzに落ちた場合は違います。文字起こしが使う品質の半分しか届いていないので、人が聞き取りにくいだけでなく、文字にもなりにくくなります。 「通話モードだから仕方ない」で一括りにすると、この2段階が見えません。

切り替わるきっかけは、話し始めた瞬間ではない

いちばん誤解しやすいのがここです。切り替わるのは、喋ったときではありません。

Windows 11 について、Microsoft は条件を2つ挙げています。

> Windows selects HFP instead of A2DP when any of the following scenarios are true: > - An application opens the input (microphone) endpoint. > - An application creates an output (playback) stream with the category set to *Communications*.

1つ目は「アプリがマイクを開いたとき」です。喋ったときではありません。ブラウザの会議ツールなら、商談を始める前の待機画面でカメラとマイクを確かめた時点で、もう開いています。音が悪くなるのは、挨拶を交わす前です。

2つ目はもっと効きます。アプリが「これは通話の音です」と宣言して再生しただけで切り替わります。 マイクは一切使っていなくてもです。上位の対策1つ目（別のマイクを使う）は、この条件に当たると無効になります。設定でパソコン内蔵マイクを選んでも、アプリ側の宣言で切り替わるなら音は戻りません。「別のマイクにしたのに変わらない」は、相性の問題ではなくこちらの可能性があります。

同じページには、戻る条件も書かれています。「if media is playing and the device is in A2DP mode, and then the microphone is opened, the device switches to HFP mode. If media continues playing once the microphone is closed, the device switches back to A2DP momentarily.」

戻る条件は「closed」です。「muted」ではありません。 ミュートはマイクを閉じる操作ではないので、ミュートしても方式は戻りません。商談中に自分の番でないあいだミュートにしていても、相手の声は通話モードのままです。ミュートが相手にどう見えるかはミュートとマイクオフの違いに分けて書きましたが、音の品質についてはミュートは何の効果もないと考えてよいです。

左右2枚の図。左はノートパソコンの画面でマイクの印が青く光っていて、そこからイヤホンへ細い線が1本つながっている。右は同じ画面でマイクの印に斜線が入ってミュートになっているが、イヤホンへの線は細いまま。太い管へ戻ろうとする矢印には大きな×印が重なっている

画面に出てくるものが、OSの版で違う

上位の記事が噛み合わないもう1つの理由が、これです。Microsoft は Windows 10 と 11 を分けて書いています。

Windows 10 では、イヤホン1台につき最大3つの項目が作られます。再生だけの「{Device Name} Stereo」と、マイクつきの「{Device Name} Hands-Free」です。そして、こう書かれています。「When audio is streamed to the hands-free output, or an application opens the hands-free microphone input, regardless of if content is also being streamed to the Stereo output, the device switches into HFP mode, and any audio streaming to the stereo output is discarded.」Stereo の側へ流していた音は捨てられます。

Windows 11 では、この2つが1つにまとめられました。「In Windows 11, the endpoints are unified between A2DP and HFP. If an audio device supports HFP, a single output and single input endpoint are created for the device.」

ここが実務に直結します。「サウンド設定で Stereo のほうを選べばいい」という手順は、Windows 11 の画面では選ぶ対象そのものが存在しません。 古い手順を見ながら設定を探して見つからず、イヤホンを疑い始めるのは、だいたいこの食い違いが原因です。自分の画面に「Stereo」と「ハンズフリー」が別々に並んでいるかどうかを先に見れば、どちらの手順を読むべきか決まります。

Windows 11 は、ずれた品質を黙って合わせ直します。「Windows automatically resamples audio as needed for the currently selected profile. For example, if the microphone is used during a VoIP call, which puts the headset into HFP mode at 8kHz or 16kHz, and another application plays audio to the same device at 48kHz, the sound is resampled to match the HFP endpoint.」商談中に別のアプリで48kHzの音を鳴らしても、通話側の品質まで落とされてから届きます。 商談中に動画を見せる段取りなら、音の出口は分けたほうがよいという話になります。

直す方法は公式に書かれている。ただし機械を替える話

「将来こうなる」ではなく、すでに文書になっています。しかも限界だと認める書き方です。

Microsoft は Bluetooth LE Audio の説明でこう書いています。「One key limitation, with user-facing consequences, is the drop to mono audio whenever the microphone is active. This blocks experiences like spatial audio in Teams and other VoIP apps from working」（Microsoft Learn）。そして解決として「Bluetooth LE Audio closes the gap with improved audio fidelity and reduced latency by adding support for stereo playback while the microphone is in use.」マイクを使いながらステレオで再生できるようにした、という書き方です。

Google も同じことを、もっと短く書いています。「Bluetooth classic lowers audio quality when using Bluetooth microphones. With BLE Audio, input and output sampling can reach 32 kHz.」（Android Developers）。8kHzか16kHzだった入り側が、32kHzまで上がるという対比です。

ただし条件があります。Windows 側の対応は「Windows 11 version 22H2 (KB5026446)」からで、パソコンの無線とイヤホンの両方がこの方式に対応している必要があります。「もっと高いBluetoothイヤホンを買う」では解決しません。 対応しているかどうかを、パソコンとイヤホンの両方について確かめる話です。

Apple 側にも高音質で録る選択肢があります。ただ、注意書きが付いています。「This option may increase input latency when enabled and isn't recommended for real-time communication usage.」（Apple Developer）。遅れが増えるので、リアルタイムの通話には勧めないと、用意した側が書いています。同じページには「Bluetooth high-quality recording isn't currently supported in the European Union.」ともあります。高音質の抜け道はあるが、商談向けではない、というのが現状です。

うちは、何を選ばせていないか

自分たちのツールにも、この話に関わる判断が3つあります。

マイクを開くのは、商談が始まる前の画面です。 名前を入れてカメラの映りを確かめる画面で getUserMedia を呼び、音声については雑音抑制・エコー除去・音量の自動調整の3つだけを指定しています（public/room.html 721行）。つまり、その画面を開いた時点でイヤホンは通話モードに入ります。 これは意図した順番です。音が変わってから気づくのが商談中より待機中のほうがよく、イヤホンを替えるなら始める前に替えてほしいからです。

ミュートはマイクを閉じません。 ボタンは音声トラックの enabled を切り替えるだけで、機器は開いたままです（1053行、待機画面側は727行）。すぐ戻せることを優先した判断で、副作用として、ミュートしているあいだも方式は高音質側に戻りません。 戻したいなら商談を抜けるしかないので、「ミュート中だけ音楽を良い音で」はできません。

音の出口を選ぶ画面は置いていません。 設定パネルが一覧にするのはカメラとマイクだけで（1762〜1767行、videoinput と audioinput のみ）、再生先を選ぶ仕組みは public/ 配下に1つもありません。出口の選択はOSに任せています。理由は、上で確かめたとおり出口をアプリ側で選んでも方式は変わらないからです。Windows 11 では項目が1つにまとまっているので、選べるようにしても品質は動きません。選べるのに効かない操作を増やすと、原因を探す側が遠回りします。

ステレオや品質の指定も要求していません。 取得時の指定は処理の3つと機器の指定だけで、channelCount も sampleRate も書いていません。頼んでも方式が変わらないなら、頼む意味がないからです。機器の指定にだけ exact を付けている理由はイヤホンを挿しても相手に声が届かないときに書きました。

商談で打てる手

順番にすると、こうなります。

耳だけのために無線を使っているなら、そのまま。話す側に使うなら有線を一度試す。 対策というより、切り替えが起きない構成に寄せる話です
始める前に、自分の画面で音を確かめる。 待機画面を開いた時点でもう切り替わっているので、ここで聞こえる音が商談中の音です
自分の画面に「Stereo」と「ハンズフリー」が別々に並んでいるか見る。 並んでいなければ、Stereo を選ぶ手順の記事は自分の環境の話ではありません
ミュートでは戻らないと知っておく。 ミュート中に音が良くならないのは不具合ではありません
商談中に動画の音を聞かせるなら、出口を分ける。 通話側の品質まで落としてから届くので、音が主役の資料は向きません
直したいなら、パソコンとイヤホンの両方を確かめる。 片方だけ新しくしても、古い方式に揃えられます

機器を替えられないときに効くのは、結局マイクと口の距離です。8kHzでも、近ければ声の成分は残ります。

分からなかったこと

確かめられなかったことを残します。

ブラウザが「通話の音」として再生を宣言しているかは、確認できていません。 Windows 11 の2つ目の条件（Communications として再生する）に、どのブラウザがどの場面で当たるのかを書いた一次情報を見つけられませんでした。だから「別のマイクを選んでも戻らないことがある」とまでは言えますが、ブラウザの会議では必ずそうなる、とは書けません。 自分の環境で試して確かめてください。

Windows 以外で、切り替わるきっかけの一覧を見つけられませんでした。 Apple の文書は優先順位と選択肢の意味までで、マイクを開いた瞬間かどうかまでは書かれていません。Windows について書いたことを、そのまま Mac に当てはめないでください。

実際の音質の差は測っていません。 8kHzと16kHzという数字は公式の表から引いたもので、自分たちで録って比べた数値ではありません。体感の差を点数にして書くことはしません。

Meetnect の場合

Meetnect はブラウザだけで動くオンライン商談ツールです。相手にアプリを入れてもらわない作りなので、相手のイヤホンがどちらの方式で繋がっているかを、こちらから知ることも替えることもできません。 できるのは、音が変わるタイミングを商談中ではなく始める前に寄せること、そして効かない操作を設定画面に増やさないことです。相手の声が遠いときは、イヤホンを疑う前に「いまお使いのイヤホンは無線ですか」と1回聞くほうが早いです。