web会議で2人が同時に話すと声が切れる｜運べる声は3〜4本
2026年10月16日
相手の言葉にかぶせて一言返した瞬間、「すみません、いま途切れました」と言われる。1人で話しているときは何も起きない。同時に話したときだけ起きるなら、原因は回線の太さだけではありません。 会議の音は、全員分が常に同じように運ばれているわけではないからです。Googleは「大きい3人」、Microsoftは「上位4人」と、自社の仕様書に本数を書いています。読んだ原文の順に書きます。
上位は回線の話で終わっている
「2人で同時に話すと切れる」で調べると、ルーターの新しい機能が原因だった例（日経クロステック）、Wi-Fiの置き場所と帯域（INTERNET Watch）といった記事が並びます。回線が細ければ、同時に話して2人分に増えた音の、増えた分が先に落ちます。そこは書かれているとおりです。
同時発言そのものを扱った記事も2件あり、どちらも会議システムの販売元でした。原因をエコー除去の破綻に置いて、対策を「性能が良い機器に替える」「話さないときはミュートする」「同時発言に強いシステムに替える」に着地させています（LoopGate）。見立ては合っていますが、どの記事も各社の公式記述を引いていません。 回線にも機器にも余裕があって切れる理由が、このあと2つ出てきます。
Google Meetは「大きい3人」と書いている
Googleは、Meetの音を外部のプログラムへ渡す口（Meet Media API）の仕様書を公開しています。そこに音声の本数があります。
> To receive audio, the client must offer exactly three audio media descriptions, creating three local audio transceivers.
> Audio sessions through the Meet Media API use three distinct media streams, each having its own static SSRC.
（Manage virtual media streams in Meet Media API）
3本です。 参加人数ではなく、音声の線の数が3本に固定されています。では3人より多く話したときはどうなるか。同じページに続きがあります。
> Meet transmits the three loudest people across the three SSRCs.
> If any of the original streams in the conference are no longer one of the loudest streams, Meet switches the RTP packets that make up the SSRC to the loudest.
選び方は「大きい順」です。 大きい順が入れ替わったら、線の中身がそのまま差し替わると書かれています。順位で選ぶ処理が会議の中で動いていて、それは会議中ずっと動き続けるということです。
1つ注意が要ります。この仕様書は、人が使うMeetのアプリの説明ではありません。外部のプログラムが音を受け取るときの決まりです。アプリでも同じ上限が掛かるとは書かれていないので、そこは断定しません。
Teamsは「声が毎コマ聞こえるとは限らない」と分けている
Microsoftも同じ種類の仕様書を持っています。Teamsの会議に入るプログラム向けの説明に、話している人の数え方が2通り書かれています。
> Active speakers identify which participants are being heard in each received audio frame. Dominant speakers identify which participants are most active or dominant in the group conversation, though their voice isn't heard in every audio frame.
（Real-time Media Call & Meeting for Bots）
言葉を2つに分けた理由が、後半にそのまま書かれています。会話でいちばん活発な人でも、音声の1コマごとに声が聞こえているとは限らない。 同じページに「One second of audio is transmitted as a sequence of 50 frames」「Each frame contains 20 ms」とあるので、1コマは20ミリ秒です。活発に話している人の声が、20ミリ秒単位では抜けている瞬間があるという書き方になっています。
本数の上限は、同じ仕組みのAPIリファレンスのほうに書かれています。
> Allows the bot to receive separate unmixed audio buffers for individual speakers in a meeting. When set to true, up to four audio buffers, each corresponding to the top four active speakers, will be received at a time.
（AudioSocketSettings（Microsoft Graph 通信サンプル））
上位4人までです。 Googleが3、Microsoftが4。数が違うだけでなく、選ぶ基準の呼び方も「大きい順（loudest）」と「活発な順（active）」で違います。同じ「同時に話した」という状況に、各社が別々の答えを自分の言葉で書いている、という状態です。
Zoomは既定でエコー除去を通している。外すモードもある
もう1つの層は端末の中です。マイクに入った音は、相手に送る前に処理を通ります。Zoomは会議中に切り替えられるマイクのモードを並べていて、その説明に「何を通さないか」が書かれています。
> allow for greater preservation of audio received from your microphone without using Zoom's echo cancellation and audio filters
（Changing audio settings during a Zoom meeting）
これは「Original sound for musicians」と「Live performance audio」という2つのモードの説明です。裏返すと、既定のモードではエコー除去と音声フィルタを通しているということになります。エコー除去は、スピーカーから鳴っている相手の声を、マイクに入った音から引き算する処理です。相手の声が鳴っている最中に自分が話すと、引き算の対象と自分の声が同じ音の中に重なります。
Microsoftも同じ場所に切る手段を置いています。高音質の音楽モードの説明に「You can also turn off noise suppression, echo cancellation, and other audio effects.」とあります（Microsoft サポート）。切る設定が用意されているのは、通すのが既定だからです。 エコー除去が機能のオン・オフではなく会議中ずっと走っている処理であることは、web会議で自分の声が返ってくるに書きました。
商談の前のテストでは、同時発話だけが再現できない
ここが実務でいちばん厄介なところです。同時発話は、自分1人では起こせません。カメラとマイクの接続テストで確かめられるのは「片方が話している」状態だけで、相手と自分の声が重なる状態は作れません（商談前の接続テストで分かること、分からないこと）。
しかも、切れていることに気づくのは切れた側ではなく聞いた側です。自分の耳には自分の声がそのまま聞こえています。マイクのテストで相手に聞こえている音を確かめると同じ構図で、確かめたいのは自分の手元ではなく相手の耳に届いたものです。
商談の場でできることは、順番としてはこれだけです。
- 同時のときだけか確かめる。 1人で話しているときも切れるなら回線側の話になります（web会議の回線が不安定なときの対処）
- スピーカーで聞いているならイヤホンに替えてもらう。 鳴っている音をマイクが拾わなくなれば、引き算する対象そのものが減ります
- かぶせない。根本の直し方ではありませんが、上の2つが効かないときに残る手です
- 切れた部分が金額や納期なら、言い直すか文字で送る。聞き返しでは「切れた」と気づけないことがあります
3番を「オンラインのマナー」として書いている記事が多いのですが、理由はマナーではありません。運べる本数と引き算の都合で、かぶせた側が削られるほうが先に決まっているからです。
うちは4人までなので、声を選んでいない
Meetnectは、同時に参加できる人数を4人までにしています（src/worker.js の MAX_ACTIVE = 4）。この上限を先に決めたので、誰の声を運ぶかを選ぶ処理を持っていません。 サーバーで音をまとめず、相手ごとに1本ずつ線を張り（public/room.html 915行の new RTCPeerConnection）、自分の音と映像をその線にそのまま乗せています（919行）。大きい順に並べ替えて差し替える場所が、コードの中にありません。
端末の中の処理は、逆に選べないようにしています。マイクを取るとき、エコー除去・雑音抑制・自動音量調整の3つを常にオンで要求しています（721行。会議中にマイクを切り替えたときの1774行も同じ指定です）。音楽モードのような「切る」設定は付けていません。 相手にアプリも設定画面も持たせない作りなので、片方だけ処理が外れた状態を作らないほうを選びました。同時発話のときにエコー除去で削られる側に留まる、ということでもあります。
記録のほうは、同時に話されたときの結果が2つに分かれます。録画は映像と音を1本にまとめて保存するので、重なった部分は重なったまま残ります。議事録は別の経路です。話す人ごとに別々に録って、25秒ごとに区切って文字起こしし、時刻順に並べ直しています（2121〜2153行、SEG_MS=25000）。同時に話した部分は、混ざった1行ではなく2行として残ります。話者ごとに分けた議事録の作りは話者つきの議事録に書きました。
確かめられなかったこと
人が使うアプリでも同じ上限かどうか。 3本・上位4人という数字は、どちらも外部プログラム向けの仕様書とAPIリファレンスの記述です。MeetやTeamsのアプリで会議に出ているときに同じ上限が掛かるかは、どちらの公式にも書かれていませんでした。
同時に話したとき、どれだけの時間が削られるか。 公式に数字がありません。こちらでも測っていないので書きません。
Zoomが同時に運ぶ音声の本数。 エコー除去についての記述は見つかりましたが、本数を書いた公開仕様書は見つけられませんでした。なお、1台を複数人で囲む場合は本人の声だけを通す別の仕組みが関わるので、会議室の1台で複数人がweb会議に参加に分けて書いています。
Meetnectの場合
Meetnectはブラウザだけで動くオンライン商談ツールです。参加は4人まで、音は相手ごとの線にそのまま乗せていて、誰の声を運ぶかを選ぶ処理は持っていません。同時に話された部分は録画では重なって残りますが、議事録は話す人ごとの別録りなので2行に分かれます。音の取り込みをこう決めた理由はweb会議の音声が聞き取りにくい原因に書いています。
参考
- Manage virtual media streams in Meet Media API（Google for Developers）
- Real-time Media Call & Meeting for Bots（Microsoft Learn）
- AudioSocketSettings クラス（Microsoft Graph 通信サンプル）
- Changing audio settings during a Zoom meeting（Zoom サポート KB0064198）
- Use high-fidelity music mode to play music in Microsoft Teams（Microsoft サポート）