相手の画面だけが固まるとき、原因になっている机はどこにあるか

2026年10月7日

相手の映像が止まる。こちらの回線は速度計測で問題なく、音も届いている。相手に伝えると「こちらは普通です」と返ってくる。検索すると回線とルーターとパソコンの性能の話が並びますが、どれも読んでいる本人の机に向けて書かれています。 この記事では、W3Cの仕様とGoogle・Zoom・Webexの公式記述から、「固まった」が誰の端末で起きている出来事なのかと、1対1の商談で原因の机をどこまで絞れるかを整理します。出典は本文に置いています。

上位に並ぶのは「自分の机の直し方」

この語で検索して上位9件を読むと、原因は7つくらいに分かれています。回線が遅い、ルーターの置き場所、通信制限、端末の性能不足、開きすぎたアプリ、古いバージョン、サービス側の障害。対処は再起動、画質を下げる、有線にする、ルーターを置き直す。

1本だけ「特定の1人の映像だけが頻繁に途切れるなら、その人の環境に問題がある可能性が高い」と書いていました。ここまで来ているページもあります。ただ、それをどう確かめるかと、確かめられない場合があることには触れていません。

そして9件のうち、「固まっている」が何秒からなのかを決めたページは1本もありませんでした。

公式側も、見ている側に向いていません。Zoomの動画のクラッシュやフリーズのトラブルシューティングは、冒頭が If your Zoom video freezes or your camera crashes during a meeting, there are some quick fixes that can help. です。自分の映像が固まる人に向けた文で、以降の手順もすべてその人の端末の中です。カメラを使っている別のアプリを閉じる、ドライバを確かめる、再インストールする。見ている側に向けたページは見つかりませんでした。

Google Meetの会議の動画と音声の品質に関するトラブルシューティングも当たりました。ブラウザの更新、反響音の警告、周辺機器、VPNの無効化、タブを閉じる、と項目は並びますが、固まりについての記述も、どちら側の問題かについての記述もありません。

「固まっている」には定義があって、受け取る側にしかない

ブラウザのWeb会議が使っている仕組みには、固まりを数える決まりがあります。W3CのWebRTC Statistics API（Candidate Recommendation Draft、2025年9月25日）の freezeCount の定義です。

> Count the total number of video freezes experienced by this receiver. It is a freeze if frame duration, which is time interval between two consecutively rendered frames, is equal or exceeds Max(3 * avg_frame_duration_ms, avg_frame_duration_ms + 150)

絵が1枚出てから次の1枚が出るまでの間が、それまでの平均の3倍か、平均に150ミリ秒を足した値か、長いほうを超えたら1回の固まり、という決め方です。毎秒30枚なら平均は約33ミリ秒なので、183ミリ秒を超えた時点で1回と数えられます。 止まって見えるずっと前から数は増えています。

同じ仕様には、別の名前も用意されています。

> Count the total number of video pauses experienced by this receiver. Video is considered to be paused if time passed since last rendered frame exceeds 5 seconds.

5秒を超えると「固まり」ではなく「止まり」に名前が変わります。

ここで大事なのは、どちらの定義にも experienced by this receiver（この受け取り手が経験した）と書かれていることです。送る側に、これに対応する数字はありません。「固まった」は、受け取った人の端末でしか成立しない出来事です。 だから相手に「固まっています」と言っても、相手の画面では何も起きていません。嘘をつかれているのでも、気を使われているのでもありません。

理由は2つに分けられていて、記録は送る側に残る

同じ仕様の、送る側の統計を見ると、別のことが分かります。qualityLimitationReason という項目があり、取りうる値が4つ決められています。

• none … the user agent is not limiting the quality
• cpu … the quality is limited due to CPU constraints
• bandwidth … the quality is limited due to bandwidth constraints
• other … the quality is limited for some other reason

回線（bandwidth）と端末の処理（cpu）が、別の値として分けられています。 さらに qualityLimitationDurations で、理由ごとに何秒ずつ続いたかまで記録されます。

つまり、回線を直しても戻らない場合が、仕様の側で最初から想定されています。 上位記事の対処が「回線」と「性能」を同じチェックリストに混ぜているのは、この区別を捨てているということです。

そして、この記録が残るのは送っている側の端末です。固まって見えている人の手元ではありません。答えを持っているのは、何も困っていない側の机です。

公式の切り分け方は、3人目がいないと使えない

では公式はどう切り分けるのか。Google Workspaceの管理者向けのTroubleshoot Meet network, audio, & video issuesに、はっきり書かれています。

> Identify whether the issue is on the sender or receiver side. If all viewers are receiving poor video quality from the same participant, it's likely to be a sender-side issue.

同じ1人の映像が、全員の手元で悪いなら送り手側 という判定です。方法として筋が通っています。ただし受け手が2人以上いないと成立しません。 1対1の商談では、この唯一の公式な切り分け方が使えません。

同じページには、固まりについてこう書かれています。

> If the video freezes, you might have an unstable network. At the receiver's location, measure the bandwidth and latency in your network to verify they meet the requirements.

測るのは受け手の場所です。ところが直前の文で、原因は送り手側かもしれないと書かれています。測る場所と、原因がある場所が、同じ文書の中で分かれています。 矛盾ではなく、受け手の側は自分の場所しか測れないという事実が、そのまま出ているだけです。

「その人の環境」で終わらない場合もある

上位記事の「特定の1人なら、その人の環境」も、いつも当たるわけではありません。CiscoのKnown issues and limitations for Webex videoに、こう書かれています。

> If any participant on the Webex Meetings side experiences poor network conditions, the resolution between video systems and the Webex Meetings application downgrades to accommodate that participant. As a result, video resolution will also be poor for all other participants.

誰か1人の回線が悪いと、他の全員の映像まで落ちるという記述です。3人の会議で、Aさんの映像が自分の手元で荒れているとき、原因がCさんの回線だったということが起こります。Aさんの机を調べても何も出てきません。

同じページには、操作ひとつで相手側が止まる例も載っています。

> When presenters switch to full-screen video view while sharing their screen, application, or document, sharing is paused on the attendee side (the last-shared screen freezes).

資料を出している人が映像を全画面にしただけで、受け手の画面は最後の1枚で止まります。どちらの端末にもエラーは出ません。 送り手は映像を大きくしただけなので、自分が何かを止めたとは思っていません。資料が相手の手元で止まるときの話は別の記事に書きました。

うちは、固まりを画面に出していない

Meetnectでは、相手の映像が固まったことを画面に出していません。一方で、相手がカメラを切ったことは出しています。 この差が、そのまま仕組みの説明になります。

カメラの入り切りは、ボタンを押した端末が自分で宣言しています。sendMediaState() が {type:"media", mic, cam} を送り（public/room.html の1042行）、カメラボタンを押したときと、相手とつながった時点で一度、これが飛びます（1055行・832行）。受け取った側は applyPeerMedia（960行）でタイルに camoff を付け、映像の代わりに名前の頭文字の丸を出します（975〜976行）。本人が押したことを本人が宣言しているから、相手の画面に出せます。

固まりは、誰も宣言しません。映像の線は生きたままで、最後の1枚がそこに残るだけです。線の状態を見ている onconnectionstatechange（930行）が動くのは failed と disconnected のときだけなので、connected のままフレームが止まっても何も起きません。切れたときに戻す作りは別の記事に書いています。

自分のタイルに出しているのは、カメラから取った映像そのものです（777行で localVideo.srcObject = localStream）。相手に送るために圧縮した後の映像ではありません。だから送っている側の画面には、最後まで何も出ません。 資料提示のほうは送っている映像そのものを自分にも出していて（そちらの話はこちら）、カメラとは作りが違います。

数えて出すこともできます。やっていないのは、出せるのが「止まって見える」までだからです。それは人が見れば分かります。どの机が原因かまでは、こちらの端末からは出せません。 出せない数字を画面に足すと、相手に伝える言葉が1つ増えるだけで、打てる手は増えません。

1対1で、順番に絞る

1対1では公式の切り分けが使えないので、別の順で絞ります。

1. 何秒止まっているかを言う。 「固まっています」ではなく「10秒ほど止まっています」。5秒を超えると仕様でも名前が変わるので、相手が自分の端末を疑う強さが変わります
2. 音が無事かを分けて言う。 映像が止まっても声が続いているなら、線そのものは生きています。声の側が苦しいときの話は別の記事に書きました
3. カメラを一度切って、また入れてもらう。 頭文字の丸に変われば宣言は届いているので、止まっているのは映像の中身だけだと分かります
4. 回線だけを疑わない。 仕様が cpu と bandwidth を分けているので、重いアプリを閉じるのと回線を替えるのは別の手です
5. 3人目がいる会議なら、もう1人に聞く。 これが公式の方法です。1対1で詰まったら、社内の誰かを一度だけ同席させるのが、いちばん確実に机を当てられます

分からなかったこと

3つあります。ひとつ、各サービスが固まりの回数を利用者の画面に出しているかは確かめられませんでした。仕様に項目があることと、画面に出ていることは別です。

ふたつ、固まって見え始めるまでに何回ぶん数が増えているかは測っていません。183ミリ秒という値は、毎秒30枚という前提からこちらで計算したもので、実測ではありません。

みっつ、上に挙げた絞り方の効果も測っていません。根拠は仕様と公式の記述だけです。

Meetnectは相手の映像が固まったことを画面に出さず、カメラの入り切りだけを相手の宣言として出しています。自分のタイルに出るのはカメラから取った映像そのもので、送った後の映像ではありません。線が切れたときに戻す作りは入れていて、戻す回数と待ち時間は接続が不安定なときの記事に書きました。