web会議の画面共有が相手の画面で止まる｜遅れは送り手に見えない

2026年10月4日

資料を出して説明していたら、相手が「止まっています」と言う。何秒遅れているのか、もう直ったのかを、こちらの画面から確かめられません。検索すると回線とドライバの話ばかりで、送っている側から相手の遅れをどこまで見られるかに答えたページが見つかりませんでした。ZoomとTeamsとGoogle Meetの公式ヘルプを当たって、送り手の画面に出る数字がどこまでの話なのかを整理します。出典は本文に置いています。

上位に出てくるのは「原因と対処」で終わっている

この語で検索して上位9件を読むと、中身はほぼ同じです。原因は帯域の不足、ブラウザやGPUドライバが古いこと、拡張機能やVPNやセキュリティソフトの干渉。対処は回線を確かめる、設定を見直す、更新する。

そして最後が必ず「相手側にもネットワークの状態を確認してもらう」で終わります。こちらからは分からない、ということを、対処の形で書いているだけです。

公式側も触れていません。Googleの画面共有に関する問題のトラブルシューティングの項目は、ブラウザを更新する、Chromeを完全に再起動して権限をリセットする、共有ボタンが押せないときの対処です。フレームレートや相手側の見え方の記述はありませんでした。

送り手の画面に出る数字は、どこまでが自分の話か

会議中に数字を見る場所はあります。ただし何を測っているかが、公式の説明で書き分けられています。

Zoomには統計タブがあり、公式ヘルプに項目と推奨値が並んでいます。Latency は Typically, a latency of 150ms or less is recommended.（150ms以下が推奨）、Jitter は40ms以下、Packet Loss は2%以下です。

同じページに、画面共有のときの列の扱いが書かれています。

> When sharing a screen, the Receive column is blank. When viewing a shared screen, the Send column is blank.

共有している側の画面では、受け取りの列が空欄になります。受け取りの数字が埋まるのは、受け取っている人の画面の中だけです。

Teamsは「通話の正常性」（設定 → 通話の正常性）です。公式ヘルプの画面共有の欄には Sent frame rate の典型値が Between 1-30 fps (Variable based on what content is being shared.) とあります。Received frame rate のほうは received per second by your system、つまり自分の端末が受け取った数です。

遅れに近いのは Roundtrip time ですが、説明はこうです。In group calls, it's the response time between your system and the Teams Service. 3人以上の会議では、測っているのは自分とTeamsのサービスの間で、相手の端末までではありません。更新も Call health metrics update every 15 seconds. で15秒ごとです。

2つ並べると同じ形をしています。数字は出る。ただしそれは自分から先のどこかまでの話で、相手の手元に絵が着いた時刻ではありません。商談の前にテストしても同じ切れ目が残ります（事前接続テストの話）。

「動きを優先する切り替え」は、入っているかが画面に出ない

もうひとつ詰まるところがあります。画面共有は既定で動きより解像度を優先していて、それを切り替える操作があるのに、切り替わったかどうかが分かりません。

Microsoftの画面共有のビデオ表示ラグの問題を修正するには「既定では、Teams での画面共有のフレーム レートは低フレーム レートに設定されています」とあり、理由も「一般的に共有されるコンテンツが静的であるため」と明記されています。動きの多いものを共有すると「ビデオが遅れているように見える場合があります」。切り替えは Ctrl + Alt + Shift + T です。

そして同じページに、こうあります。

> キーボード ショートカットを実行すると、高モーション表示が有効になっていることを示す視覚的な表示は表示されません。

しかもトグルで、2回押すと既定に戻ります。押したあと、いまどちらで送っているかを確かめる場所がありません。 解像度のほうは「高いフレーム レートに合わせて低下する可能性があります」とされています。

Zoomの「Optimize for video clip」も性質が似ています。公式ヘルプによると、必要な回線は At least 1.5Mbps uplink and downlink for full screen HD。そして Zoom recommends disabling this option when not sharing a video, as this will make static text and images distorted（動画を共有していないときは無効にすることを推奨。静止したテキストや画像が歪むため）と書かれています。

目を引くのは downlink の側です。条件には相手の下りの回線が入っているのに、その相手の下りが足りているかどうかは、先ほどの空欄の列です。

うちは切り替えを出さず、送るフレーム数を中身で決めた

Meetnectでは、送り手に画質や動きの切り替えを出していません。送るフレーム数を、送るものの種類ごとにコードで決めています。

資料提示は1280×720の板を1枚作り、200ミリ秒ごとに1フレームだけ送ります（presentCanvas.captureStream(0) に setInterval で requestFrame() を200ms間隔。public/room.html の1901行と1907行）。秒5フレームです。ページを送ったときは、そのタイミングでもう1フレーム押します。手動でフレームを押せないブラウザでは、同じ経路が8fpsの自動キャプチャに落ちます（判定は manualFrameOK、2441行）。

カメラ側は別で、上限30fps・約4Mbpsにしてあり、帯域やCPUが苦しいときはフレームを落として解像度を残す側に寄せています（maxFramerate=30、degradationPreference="maintain-resolution"、890〜896行）。

切り替えを人に選ばせなかったのは、押した結果が画面に出ないスイッチだと、送り手が毎回「いまどちらだったか」を思い出す作業になるからです。資料は動かない、顔は動く。どちらを送っているかは送る側のコードで決まっているので、人に選ばせる必要がありません。 相手の遅れを測る処理は入れていません。測っていないので、画面にも出しません。

相手が「止まっています」と言ったときに打てる手

見えないものを見ようとするより、見えなくても成り立つ進め方に寄せるほうが早いです。3つあります。

ページを送ったら、送ったことを声に出す。「次のページに行きます」と言えば、相手は自分の画面が追いついているかを自分で判断できます。何秒遅れているかを知る必要がなくなります。

動くものは画面共有で送らない。 動画を見せるならファイルを先に渡して、相手の手元で再生してもらう。Zoomが「動画を共有していないときは無効にすることを推奨」と書いているのは、同じ経路に静止した資料と動画を流すと両方が崩れるからです（資料を先に渡す判断）。

「見えていますか」ではなく中身を聞く。「いまどのページが出ていますか」なら答えが返ってきます。読めているかを問う質問は「大丈夫です」で終わります（相手の画面の大きさも同じ）。

分からなかったこと

3つ、確かめられませんでした。

ひとつ、相手の手元で何秒遅れているかを送り手に見せる機能は、3社のヘルプに見つかりませんでした。無いと言い切れるわけではなく、見つからなかっただけです。ふたつ、実際に回線を細くして各社で何秒の遅れが出るかは測っていません。この記事の数字は、公式ヘルプの推奨値と、うちのコードの中身だけです。

みっつ、Google Meetの会議中の「トラブルシューティングとヘルプ」に何が並ぶかは確かめられませんでした。公式ヘルプは「ネットワークの安定性グラフなどの診断結果をご確認ください」としか書いておらず、項目名が載っていません。

Meetnectの場合

Meetnectは資料を画面共有ではなくファイルとして送り、1280×720に焼いた板を200ミリ秒ごとに1枚ずつ届けます。画質や動きの切り替えは送り手に出していません。回線が不安定になったときに接続を戻す仕組みは別の記事に書きました。この記事で挙げた進め方の効果は測っていません。