トップ / ブログ

web会議で共有した動画の音が途切れる|相手だけに起きる理由

2026年10月7日

左の人のノートPCからは音の波が滑らかに連なって出ているのに、ケーブルでつながった右の人のノートPCでは同じ音の波が歯抜けに途切れていて、右の人が怪訝な顔をしている様子
左の人のノートPCからは音の波が滑らかに連なって出ているのに、ケーブルでつながった右の人のノートPCでは同じ音の波が歯抜けに途切れていて、右の人が怪訝な顔をしている様子

商品紹介の動画を流したら、相手から「音がブツブツ切れています」と言われる。こちらのスピーカーからは最後まで滑らかに鳴っているので、何が起きたのか見当がつきません。検索すると「有線にする」「ルーターを再起動する」で終わるページばかりでした。Zoom・Teams・Google Meetの公式ヘルプに出ている数字と但し書きを並べると、声は無事なのに動画の音だけが崩れるのは十分に起こりうることだと分かります。出典は本文に置いています。

この記事の内容
  1. 上位は「有線にする」で終わっている
  2. 声の道は、ごく細く作られている
  3. 非音声は「消すべき音」として扱われている
  4. 動画を流すと、上りとCPUが同時に要る
  5. 相手が聞いているのは、送った音そのものではない
  6. うちは、動画の音を運ぶ道を持っていない
  7. 商談で打てる手
  8. 分からなかったこと
  9. Meetnectの場合

上位は「有線にする」で終わっている

この語で検索して上位9件を読むと、書いてあることはほぼ同じです。上りの速度が落ちていると自分の音が相手側で途切れる。無線をやめて有線にする。ルーターや端末を再起動する。全員に起きているのか1人だけなのかを確かめる。

切り分けとしては正しく、音声が聞き取りにくいときの順番もこれと同じです。ただ、どのページも「声」の話をしています。 声は普通に通じているのに動画の音だけが崩れる、という分かれ方には1件も触れていませんでした。この記事はそこだけを書きます。音がそもそも送られているかどうかは別の記事に書いたので、ここでは送れている前提で進めます。

声の道は、ごく細く作られている

まず、音声に割り当てられている量を見ます。Microsoftのネットワークの準備には、通信量の目安が機能ごとの表で載っています。音声は最小 10/10、推奨 58/58、最良 76/76 kbps。画面共有は会議で最小 250/250、推奨 2,500/2,500、最良 4,000/4,000 kbps です。

音声は推奨でも58kbps、画面共有の40分の1です。 同じページには、足りないときの振る舞いも書かれています。

> when bandwidth is insufficient, Teams prioritizes audio quality over video quality.

帯域が足りないとき、映像より音声を優先する。声が最後まで残るように作られている、ということです。58kbpsで足りるのは、それが人の声だからです。映像のほうが先に削られる話は前に書きました。

ただし、この表のどの行に「共有した動画の音」が入るのかは書かれていません。 声と同じ行なら細い道を通ることになり、音楽や効果音を58kbpsに収めるのは無理があります。

非音声は「消すべき音」として扱われている

量より効いているのは、処理のほうです。各社とも、会話以外の音を消す仕組みを既定で動かしています。

Googleの会議のノイズを除去するには、Meet cancels non-speech noises(Meetは音声以外のノイズを除去します)とあり、続けてこう書かれています。

> If you need other sounds in your meeting, like music, turn off noise cancellation.

音楽のような他の音が必要なら、ノイズ除去を切る。音楽を流すなら切れ、と公式が自分で書いています。 言い換えると、切っていないあいだ、動画のBGMや効果音は「消す対象」の側に置かれています。同じページには、会話は守られるとも書かれています(Voices from TV or people talking won't be canceled.)。ナレーションは残り、音楽が削られる、という分かれ方になります。

Zoomも同じ分け方を、別の名前で持っています。プロ用音声の設定にある高音質モードの説明です。

> This disables echo cancellation and post-processing, while raising audio codec quality to 48KHz, 96Kbps mono/192kbps stereo.

エコー除去と後処理を止めて、音声の品質を48kHz・モノラル96kbps/ステレオ192kbpsまで上げる。専用モードに入らないと、この品質にならないと書いているわけです。 同じページは Live-performance audio also has higher network requirements for best performance, so Ethernet connections are recommended. とも書いていて、非音声を運ぶほうが回線に厳しいことを認めています。

動画を流すと、上りとCPUが同時に要る

共有そのものの前提条件も、声を運ぶときより重いです。Zoomの録画した動画を音つきで共有するには、At least 1.5Mbps uplink and downlink for full screen HD とあり、プロセッサーは 4 cores or higher が並んでいます。動画の形式も Only the H.264 AVC codec for both mov and mp4 videos is supported と限定されています。

全画面の動画を最適化するのほうには、はっきりした警告があります。

> If the content is higher than 1080p, Zoom will downsample the footage to conserve bandwidth usage, which will cause increased CPU usage and poorer quality.

1080pを超える素材は帯域を節約するために縮小され、その結果CPU使用率が上がって品質が落ちる。手元で4Kの動画を開いただけで、送り出し側の計算量が増えます。 同じページは、動画でないものを共有するときはこの設定を切るよう書いています(this will make static text and images distorted)。切り替え忘れると、こんどは文字が崩れます。資料の文字をどこまで読めるかは解像度の記事に書きました。

ここで足りなくなったときに、映像と音のどちらから削るのかは、どのページにも書かれていませんでした。

相手が聞いているのは、送った音そのものではない

3段の図。上段は手元のスピーカーから滑らかな音の波。中段は細い管に押し込まれて歯抜けになった波。下段は受け手側で機械が歯抜けの隙間を点線で描き足している様子
3段の図。上段は手元のスピーカーから滑らかな音の波。中段は細い管に押し込まれて歯抜けになった波。下段は受け手側で機械が歯抜けの隙間を点線で描き足している様子

もう1つ、受け取る側でも音は作り替えられています。Googleの音声と映像を良くするにあるスタジオサウンドの説明です。

> Studio sound will automatically improve poor audio quality from typical bluetooth headsets and dial-in participants

その手段が by using AI to recreate higher audio frequencies、つまり高い周波数をAIで作り直すことです。 しかも Studio sound is automatically applied when noise cancellation is enabled. とあり、ノイズ除去が入っていれば自動で効きます。声を聞き取りやすくするには良い仕組みですが、音楽に当てたときにどう聞こえるかは書かれていません。

そして送り手には、どれも見えません。自分の耳に届いているのは、自分の端末が自分のスピーカーで鳴らしている音です。細い道を通ったあとの音、ノイズ除去をかけたあとの音、作り直されたあとの音を、送り手は一度も聞きません。だから「音がブツブツ切れています」と言われるまで気づけません。 これは手元の音量バーが動いていても相手に届いている証拠にはならない話と、まったく同じ形です。

うちは、動画の音を運ぶ道を持っていない

ここはMeetnectの中身の話です。画面共有は映像だけを要求しています。navigator.mediaDevices.getDisplayMedia({video:true}) の1行(public/room.html の1825行)で、音声を頼んでいません。

マイク側の処理も、切る手段を作っていません。エコー除去・ノイズ抑制・自動音量調整の3つは、最初にマイクを取るところ(721行)と設定画面で切り替えたところ(1774行)の2か所だけで指定していて、どちらも常に有効です。false にする分岐も、高音質モードに当たるものも、コードにありません。

この2つを合わせると、よくある回避策がそのまま塞がっています。 スピーカーから動画を鳴らしてマイクで拾わせる、というやり方です。ノイズ抑制は会話以外の音を削る向きに働くので、BGMや効果音ほど消えます。文字起こしに回す音はそこから16kHz・モノラルまで落としていて(2381行)、音量が0.004を下回る区間は送っていません(2394行)。歌や効果音が記録に残る作りにもなっていません。

そうしているのは、見せるものをファイルで渡す側に寄せたからです。資料は1280×720の板に焼いて1枚ずつ送っていて、音のあるものは相手の手元で再生してもらう前提です。

商談で打てる手

送り手に確かめる手段がないので、確かめなくても成り立つ運びに寄せるほうが早いです。3つあります。

音のある動画は、先にファイルで渡す。 相手の手元で再生してもらえば、帯域も処理も関係なくなります。資料を先に渡すかどうかの判断は別に書きました。

会議の中で流すなら、冒頭の5秒で1回聞く。 「音は途切れていませんか」を動画の頭で挟む。終わってから聞くと、流した時間がまるごと無駄になります。

ナレーションのある素材を選ぶ。 3社とも、会話は守って非音声を削る向きに作られています。音楽で雰囲気を伝える素材より、人が喋って説明する素材のほうが崩れにくいはずです。

分からなかったこと

3つ、確かめられませんでした。ひとつ、Teamsの通信量の表で、共有した動画の音がどの行に入るのかは書かれていません。ふたつ、上りやCPUが足りないときに映像と音のどちらから削られるのかも、3社とも書いていません。みっつ、ノイズ除去やスタジオサウンドが音楽にどう効くかは、こちらで測っていません。この記事の記述は、各社の公式ヘルプの文面と、うちのコードの中身だけです。

Meetnectの場合

Meetnectは資料をファイルとして渡し、画面共有では映像だけを送ります。動画の音を運ぶ道を持っていないので、音のあるものは相手の手元で再生してもらう形になります。カメラ映像のほうが何fpsまで出るかは別の記事に書きました。この記事で挙げた進め方の効果は測っていません。

商談しながら、議事録ができています

Meetnect はブラウザだけで動くオンライン商談ツールです。相手は登録不要、URLを開くだけ。通話中に文字起こしが進み、終わった時点で「誰が何を言ったか」まで残った議事録ができています。7日間、カード登録なしで試せます。