web会議で自分の声が返ってくる｜エコーの原因は相手側にある
2026年10月7日
商談中、自分が話した声が少し遅れて自分のスピーカーから返ってくる。相手に伝えると「こちらでは何も聞こえません」と言われる。これは相手が嘘をついているわけではなく、音の輪ができている場所と、それが聞こえる場所が別だからです。どちら側で何が起きているのかを、仕様の文面と3社の公式ヘルプで確かめました。出典は本文に置きます。
上位は「マイクとスピーカーを離せ」で終わっている
「web会議 エコー」で検索すると、上位はほぼ同じ構成です。原因としてマイクとスピーカーが近いことが挙がり、対策としてヘッドセットを使う、スピーカーの音量を下げる、発言しないときはミュートする、マイクとスピーカーを1メートル以上離す、が並びます。
どれも正しい対策です。ただ、その対策を誰がやるのかが書かれていません。
記事は読んでいる人に向けて書かれているので、読み手は自分の机の上を直します。ところが自分の声が返ってくる場合、直すべき機材は自分の机の上にありません。ここが抜けていると、ヘッドセットを買って付け替えても症状が変わらず、原因の切り分けが振り出しに戻ります。
自分の声が返ってくるとき、輪ができているのは相手側
順番に追うと場所が決まります。
- 自分が話す。声は相手の端末に届く
- 相手のスピーカーがそれを鳴らす
- 相手のマイクが、その鳴った音を拾う
- 拾われた音が自分の端末に戻ってくる
自分に聞こえているのは、4で戻ってきた自分の声です。 輪が閉じているのは2と3のあいだ、つまり相手の机の上です。相手の耳には、自分の声が自分のスピーカーから出ているだけなので、おかしなところは何もありません。
ブラウザの仕様も、この向きで書かれています。エコー消しの設定値 remote-only の定義はこうです。「Only user system-generated audio captured by the user's microphone from remote sources ... is removed」（MDN）。消す対象は「自分のマイクが拾ってしまった、遠くから来た音」です。つまりエコー消しは、輪ができている側の端末で働く仕組みです。聞こえている側の端末でいくら設定を変えても、消す対象がそこにありません。
ひとつだけ例外があります。自分の端末の中で、マイクに入った音がそのまま自分のスピーカーへ回されている場合です。この場合は相手と無関係に自分の声が返ります。確かめ方は単純で、相手が退出したあとにひとりで話してみること。それでも返るなら自分側、返らないなら相手側です。
エコー消しは機能ではなく、その場で走っている処理
ここが、対策の記事に出てこない部分です。エコー消しは「付いているか、付いていないか」ではありません。会議中ずっと計算し続けている処理で、計算の余力と引き換えに効きが変わります。
Zoom は設定画面でその強さを選べるようにしていて、それぞれの説明に計算量が書かれています。自動は「Automatically adjust echo cancellation, balancing CPU and performance」、低は「low CPU utilization」、高は「Enabling this option may increase CPU utilization」（Zoom サポート KB0066398）。
エコー消しと端末の軽さは、同じ資源を取り合っています。 商談の相手が資料を開き、別の会議ツールを立ち上げ、画面共有もしている状態は、エコー消しにとっていちばん不利な条件です。機材は何も変わっていないのに、会議の途中からエコーが出はじめるのは、ここで説明がつきます。
「自動で試行する」とは書いてあるが、消し切るとは書いていない
公式の書き方も、そこを言い切っていません。Google Meet のヘルプにはこうあります。「使用するマイクと外部スピーカーの機器の組み合わせが適切でない場合、エコーが発生することがあります。会議ではエコーの除去が自動的に試行されますが、ユーザーがヘッドフォンを使用したり、スピーカーの音量を下げたり、発言するとき以外は自分の音声をミュートすることで、さらに効果的に反響音を抑えることができます」（Google Meet ヘルプ）。
「試行されます」です。 そのうえで、人の側でやることが3つ並んでいます。
仕様はもっとはっきりしています。エコー消しを頼んだときの挙動が、こう定義されています。「the user agent will attempt to obtain media with echo cancellation enabled or disabled as specified, if possible, but will not fail if this can't be done」（MDN）。頼んだとおりにならなくても、エラーにはなりません。 失敗を知らせる代わりに、そのまま会議が始まります。
厳密に要求する書き方もあって、その場合は「if it can't be met, then the request will result in an error」になります。ただしエラーになれば、音声そのものが取れません。エコーが出るか、音が一切入らないか、という二択です。
Microsoft が会議室向けに書いている指示は、この前提の上に立っています。マイクを有効にする台数についてこうあります。「Make sure you enable the microphone only on one device. If you enable it on more than one device, you'll experience audio echo and feedback」。さらに、マイクを担当しない端末については、オンにする操作自体を使えなくしておけと書かれています。「so that participants can't accidentally turn on a microphone and cause audio echo or feedback」（Microsoft Learn）。人が気をつける前提を置いていません。 会議室に複数人で入るときの話は会議室に複数人で入ったときのハウリングに分けて書きました。
気づけるのは相手だけなので、頼む順番を変える
原因の側に自覚が無く、しかも自動で消える保証も無い。この2つが重なると、商談でできることは限られます。実務で効くのはこの3つです。
- 自分の機材を触る前に、相手が退出したあとひとりで話して確かめる。 返らなければ自分側は原因ではないので、ヘッドセットを買い替えても直りません
- 相手に伝えるとき「エコーが出ています」と言わない。 相手には聞こえていないので、確かめようがなく話が止まります。「こちらに私の声が返ってきているので、お手数ですがイヤホンをお使いいただけますか」のように、相手が実行できる行動まで言い切ります
- 複数人が同席している商談では、話す人以外の端末のスピーカーを切ってもらう。 ミュートは拾う側を止めるだけで、鳴る側は止まりません
音量を下げる、という頼み方は避けています。下げる幅がこちらから見えないので、直ったかどうかを相手の耳で判断してもらうことになり、確認の往復が増えます。
公式に書かれていなかったこと
確かめられなかったことを残します。
自分の端末でマイクの音がそのままスピーカーへ回る設定について、公式の説明ページを見つけられませんでした。 Windows のマイクのプロパティにそういう項目がある、という話は Microsoft Q&A の投稿では出てきますが（Microsoft Q&A）、これは利用者の投稿で、公式ヘルプの記述ではありません。項目名も環境で変わるようなので、ここは断定しません。上に書いた「ひとりで話して確かめる」のほうが確実です。
どのくらいの遅れで返ってくるかを示した一次情報も見つかりませんでした。 体感では半秒ほどずれて返りますが、こちらで測っていないので数字は書きません。
Meetnect の場合
Meetnect はブラウザだけで動くオンライン商談ツールです。相手にアプリも設定画面も持たせない作りなので、相手側のエコー消しを「設定してもらう」ことができません。 そのため映像と音を取る時点で、エコー消し・雑音抑制・音量の自動調整の3つを全員に同じ指定で付け、会議の途中でマイクを切り替えたときも同じ指定を付け直しています。厳密に要求する書き方（exact）は使っていません。使うと、効かない環境では音声そのものが取れなくなるからです。仕様どおり、効かなかったときにエラーは出ません。音が聞き取りにくいときの切り分けはweb会議の音声が聞き取りにくい原因にも書きました。