「Meet が重いんですけど」という申告が情シスに来たとき、返す言葉はだいたい決まっています。「回線でしょうか」「PC を再起動してみてください」。そして翌週、同じ人からまた同じ申告が来ます。
この会話が繰り返されるのは、申告の言葉が原因を何も区別していないからです。自分の回線が細いときも、相手の部屋が暗いときも、PC の CPU が別の処理で埋まっているときも、利用者にとっては全部「重い」です。症状の名前が同じなので、聞いた側は毎回ゼロから推測することになります。
Google 管理コンソールには、終わった会議の通信状態が数値で残っています。ジッター、パケットロス、輻輳、そして参加者の端末の CPU 使用率です。ここを見れば原因の候補を、参加者・端末・時間帯ごとに絞れます。数値だけで根本原因まで確定するわけではありません。そこから先の対処が変わるので、順番として先に見る価値があります。
「重い」を3つに割ってから調べる
利用者の言う「重い」は、実務上は次の3つのどれかです。最初にこれを聞き取るだけで、調べる先が変わります。
- 音声が途切れる・ロボットのような声になる：ネットワークのパケットロスやジッターを確認し、音声デバイスや端末負荷も切り分ける
- 映像がカクつく・止まる／PC のファンが回る：CPU 使用率とネットワークの両方を確認する
- 会議に入れない・入るのに時間がかかる：認証、権限、ブラウザ、ネットワーク到達性などを別途確認する
入室できなかった場合は品質データが十分に残らないこともあるため、参加エラーの表示や接続状況も確認します。ここを混ぜたまま調べ始めると時間を溶かします。
そのうえで、もうひとつ確認することがあります。その人だけか、その会議の全員かです。全員なら回線や会議室の設備、1人だけならその人の端末か自宅回線、という大きな分岐がここで決まります。会議室の機材が絡む場合は、会議室デバイスと BYOD の構成側の設定も見る対象に入ります。
管理コンソールの Meet 品質ツールで何が見えるか
Google 管理コンソールには、会議単位で通信状態を追える品質ツールがあります。使うには品質ダッシュボードの管理者権限が必要なので、特権管理者以外の担当者に調査を任せるなら先に権限を配っておきます。管理コンソールの権限委任を整理していない組織だと、ここで止まります。
Google公式ガイドが示すMeet品質ツールの位置と主な操作領域です。実際の画面を簡略化した案内図として参照してください。 出典：Google Workspace公式資料。
見られるのは主に次の値です。
| 見る値 | 何を示すか | 目安として疑い始める状態 |
|---|---|---|
| パケットロス | 届かなかったデータの割合 | 音声が途切れる申告と時間帯が一致する |
| ジッター | パケット到着間隔のばらつき | 値が大きい参加者だけ声が崩れている |
| 輻輳 | 帯域が足りずに詰まっている状態 | 特定の時間帯・特定の拠点に集中する |
| CPU 使用率 | 端末側の処理負荷 | 映像がカクつく側の参加者だけ高い |
大事なのは、これらが参加者ごとに出ることです。5人の会議でひとりだけパケットロスが出ていれば、その参加者の送受信経路を優先して調べます。全員に症状がある場合も、共通ネットワークだけでなく、送信者側やサービス側の障害を確認します。「Meet が重い」という同じ申告に対して、前者はその人の在宅環境の話になり、後者は拠点の回線契約や機器の話になります。対処の範囲と費用が変わるので、ここを取り違えると無駄な投資になります。
MQT のデータ保持期間は30日です。一部のデータには表示の遅延があり、リアルタイム監視の代わりにはなりません。品質ダッシュボードのカスタム権限だけを付けた担当者は、管理コンソールではなく直接リンクから開きます。
品質ツールには、問題を検出したときに対処方法を自動で提示する機能もあります。ただしこれは一般的な助言なので、自社の回線構成や端末の配り方まで踏まえた判断は結局こちら側で必要です。
その場で効く手当てと、根本の対処を分ける
利用者が困っているのは「今」なので、調査と並行して会議を成立させる手当ては要ります。ただし手当てを恒久対策と呼ばないことが大切です。
その場で効くのは、送受信の映像品質を落とす操作です。Meet 側の設定で解像度を標準（360p）に下げる、参加者のタイルを減らすレイアウトに変える、それでも足りなければ映像を切って音声だけにする。映像は帯域と CPU の両方を食うので、下げると両方の症状に同時に効きます。逆に言えば、これで直ったからといってどちらが原因だったかは分かりません。
根本の対処は、品質ツールで見た数値の出方によって分かれます。
- 特定の人だけ・在宅時だけ — 個人の回線環境。会社として何をどこまで負担するかの方針を決める話になり、技術の問題ではなくなります
- 特定の拠点・特定の時間帯 — 回線の帯域か、同時に走っている別トラフィック。バックアップや大容量同期の時間帯をずらすだけで解消することがあります
- 特定の端末だけ CPU が高い — 端末の世代か、常駐しているソフトの影響。買い替えの前に、何がリソースを使っているかを確認します
- 会議室からの参加だけ — 機材とその設置。会議室機材の世代と接続方式まで遡ることがあります
2番は実際によくあります。「昼休み明けの会議だけ重い」という申告が、別部署の定期処理と重なっていた、という形です。数値を時間帯で並べないと見つかりません。
調査を始める前に残しておくもの
品質ツールで会議を特定するには、いつ・誰の・どの会議かが要ります。ところが申告は「昨日の会議」で来ます。会議コードも開始時刻も残っていないと、探すところから始めることになります。
問い合わせを受ける窓口に、次の3つだけ聞く欄を作っておくと調査が一気に速くなります。
- 会議コード、主催者、会議の日時（おおよそでもよい）
- 参加していた人数と、自分以外にも同じ症状の人がいたか
- 症状は音声か映像か、入室そのものか
3つ目は前述の切り分けをそのまま聞いているだけです。これが埋まっていれば、品質ツールを開く前に見るべき値が決まります。逆にこの3つが空欄のまま調査依頼が回ってくる組織では、担当者が毎回「どの会議ですか」と聞き返すところから始まっていて、そこで一往復ぶんの時間が失われています。
会議の記録そのものの扱い方については、議事録の自動生成をどこまで信じるかの整理も合わせて見ておくと、会議まわりの運用ルールが一通り揃います。
次にやること
まず、品質ダッシュボードを見られる権限が情シス担当者に配られているかを確認してください。特権管理者しか見られない状態だと、調査のたびに管理者を呼ぶことになり、結局「再起動してください」で終わります。
そのうえで、直近で申告のあった会議をひとつ品質ツールで開き、参加者ごとの値を見てみてください。全員に出ているのか、ひとりだけなのか。それが分かるだけで、次に誰と何を話すかが変わります。
Google Workspace の管理設計、拠点や在宅を含めた会議環境の見直し、情シス業務の分担整理については、グリームハブの IT・Google Workspace 無料相談で承っています。現在の拠点構成や端末の配り方によって進め方が変わるため、お問い合わせからご相談ください。
