会議のカクつきの原因:パケットロスとジッター、帯域ではない
ビデオ会議はリアルタイムの双方向ストリームです。エンコーダーはおよそ 20 ミリ秒ごとに 1 フレームを生成し、受信側は数十〜数百ミリ秒のジッターバッファでフレームを並べ直してから再生します。途中で 1 パケット落ちると、再送はもう間に合わず、再生側は前のフレームで代用するしかないため、映像はモザイクになったり一瞬止まったりします。パケットロスが続くと、先に音声が切れます。この一連の流れは遅延の揺らぎに極めて敏感で、ピーク帯域はほとんど必要としません。
むしろ帯域は最も満たしやすい条件です。1080p のグループ会議でおよそ 2.5〜4 Mbps の上り、1080p の画面共有でおよそ 1.5〜2.5 Mbps の上りが必要とされます。多くのオフィス回線の上りはこの範囲を上回っているため、「帯域は足りているのに会議がカクつく」というケースでは、原因はほぼ残り 3 つの指標にあります。
| 指標 | 会議への影響 | 体感しやすい目安 | 測定方法 |
|---|---|---|---|
| パケットロス率 | 映像がモザイク、音声が先に途切れる | 1% を超えると体感し始め、3% を超えると顕著 | 連続 ping、またはクライアント付属のロス統計 |
| RTT(往復遅延) | 発言がかぶる、反応が鈍い | 片道 150 ms を超えると体感し始める | 会議サービスのドメインに ping して平均値を確認 |
| ジッター | ジッターバッファが伸び、相手の音声が半拍遅れる | 変動が 30 ms を超える | 連続 ping で RTT の上下を観察 |
| 上り帯域 | 解像度が自動で下がり、共有画面がぼやける | 上りが飽和したときに発生 | 会議アプリ付属の統計パネル |
表の数値は一般的な経験値の目安であり、方向性を判断するためのもので、ベンダーの保証値ではありません。実際の挙動はエンコーダーや会議アプリの劣化戦略にも左右されます。
会議アプリの多くは UDP と TCP の両方に対応しています。UDP なら遅延は低いものの、パケットロスがそのまま映像に現れます。TCP ならロスが再送を引き起こし、全体の遅延が伸びる形で現れます。クライアントが TCP しかプロキシしない場合、会議の通信は回線を通らずローカルネットワークに出てしまう可能性があります。これは接続状態から推測するのではなく、クライアントの設定で確認してください。
3 つの回線タイプが夜間ピークに示す実際の違い
回線タイプが表すのは、パケットが自分の PC から目的のサーバーまでどの物理経路を通るかということで、どのプロトコルでカプセル化するかとは別の話です。プロトコル(Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC)はハンドシェイク方式、耐ロス性能、UDP 対応を決めます。経路は、午後 8 時から 11 時の間にその道がどれだけ混むかを決めます。この 2 つを分けて見ないと、「プロトコルが新しい」を「回線が安定している」と取り違えてしまいます。
直結:経路は最短だが、出口は全員で共有
クライアントが海外サーバーに直接接続し、通信は公共の国際出口を通ります。経路は最短で、遅延は通常もっとも低くなります。ただし公共出口は共有資源なので、夜間ピークにはパケットロス率とジッターが同時に上がります。帯域重視で遅延に鈍感な用途、たとえば夜間の大容量ファイル同期やイメージの取得に向いています。
中継:国内側の入口は安定、ボトルネックは海外区間
まず国内の中継入口に接続し、そこから中継サーバーが海外へ出ます。1 ホップ増えますが、国内区間は管理された回線を通るため入口の品質は安定しています。ボトルネックは海外に出る区間へ移り、夜間ピークの安定性は中継事業者の出口リソース次第です。多くの業務用途では、これを既定の回線と考えて問題ありません。
IEPL 専用線:公共出口を経由しないポイントツーポイント回線
国際イーサネット専用線はポイントツーポイントの回線で、公共出口の混雑の影響を受けず、夜間ピークでも帯域とパケットロスはほぼ変わりません。コストが高いため、一般的には主要エリアのみの提供となります。ビデオ会議やリモートデスクトップなど、パケットロスとジッターに敏感な用途は、このタイプの回線を優先して割り当ててください。
| 回線タイプ | 経路の特徴 | 夜間ピークのパケットロスとジッター | 向いている業務用途 |
|---|---|---|---|
| 直結 | 最短経路、公共の国際出口を経由 | 変動が大きく、出口の混雑に応じて悪化 | 大容量ファイル同期、夜間バックアップ |
| 中継 | 国内入口 + 海外区間の 2 ホップ | 入口は安定、海外区間はリソース次第 | 日常の共同作業、コードリポジトリ、クラウドストレージ |
| IEPL 専用線 | ポイントツーポイント専用線、公共出口を経由しない | 比較的安定 | ビデオ会議、リモートデスクトップ、インターネット電話 |
プロトコルの面では、QUIC ベースの Hysteria2 と TUIC はパケットロス環境に強く、ヘッドオブラインブロッキングも起きず、前方誤り訂正も使えます。代償として、UDP は一部のネットワークで速度制限や遮断を受けることがあり、その場合は Trojan や VLESS + TLS に戻したほうが安定します。ただし、どれほど優れたプロトコルでも、すでに混雑した物理経路は救えません。まず回線を見て、それからプロトコルを調整してください。
業務シーン別に回線を選ぶ
1 つのサブスクリプションには通常複数の回線が含まれており、どれを選ぶかは主な用途によって変わります。以下はよくある 4 つの業務シーンごとの優先順位です。判断基準はそれぞれ異なります。
ビデオ会議:Zoom / Teams / Meet
優先するのはパケットロスとジッターで、帯域は最後です。IEPL 専用線を選び、クライアントで UDP 転送が有効になっていることを確認してください。自動負荷分散があり、途中でノードを切り替える回線は避けてください。切り替えは接続の再確立を意味し、会議が数秒そのまま落ちます。
リモートデスクトップ / SSH / データベース
こうした対話的な操作は RTT にもっとも敏感で、帯域の要求はごく低く、5 Mbps 以内で通常は足ります。物理的な距離が近く RTT が安定した専用線の入口を選び、「帯域が大きい」という理由で遠回りのノードを選ばないでください。遠回りによる遅延のほうが、帯域の利得よりはるかに大きくなります。
ファイル同期 / コードリポジトリ / クラウドストレージ
こうした通信は TCP で流れ、パケットロスは再送で補われるため、体感は主に帯域に左右されます。中継や直結を安心して使ってよく、専用線は会議とリモートデスクトップに残しておきましょう。回線リソースを用途ごとに分けるほうが、全員が 1 本に集中するより効率的です。
インターネット電話 / オンラインサポート
帯域の要求はビデオ会議よりさらに低いものの、ジッターは同じくらい致命的です。判断基準は会議と同じで、まず夜間ピークの遅延の揺らぎを見て、そのあとに帯域を見ます。
分割ルールとクライアント設定
分割の意義は、限られた専用線の帯域を会議のために残すことで、すべての通信を 1 本の道に押し込むことではありません。基本は 3 段階です。国内のドメインと IP は直結、会議とコラボレーションのドメインは回線経由、それ以外の通信は既定の出口を通します。
# 分割ルールの例(ドメインと地域でマッチ、上から順に適用)
DOMAIN-SUFFIX,zoom.us,PROXY
DOMAIN-SUFFIX,teams.microsoft.com,PROXY
DOMAIN-SUFFIX,slack.com,PROXY
DOMAIN-SUFFIX,meet.google.com,PROXY
DOMAIN-SUFFIX,github.com,PROXY
GEOIP,CN,DIRECT
MATCH,PROXYルールは上から順にマッチし、最初に一致したものが適用されるため、具体的なドメインは GEOIP より前に書きます。会議アプリはメインドメインのほかに、複数の CDN とシグナリング用ドメインにも接続します。zoom.us を 1 行書いただけでは、映像は出ても画面共有は直結のまま、ということが起こります。そういう場合は、会議アプリのプロセスごと専用線に向けてしまうほうが簡単です。デスクトップ向けクライアントは通常、プロセス単位の分割に対応しています。
サブスクリプションリンクとインポート
各プラットフォームのクライアントは、サブスクリプションリンクを貼り付けるだけで、更新後はノード一覧が自動で更新され、手作業で 1 つずつ追加する必要はありません。サブスクリプションリンクはアカウントの認証情報と同じなので、公開の場に貼らないでください。同時接続デバイス数に制限はありませんが、同じ回線の帯域はすべてのデバイスで共有されます。複数のデバイスで同時に会議をするときは、会議以外のダウンロードを別の回線に移しておきましょう。
プラットフォーム別クライアントの違い
- Windows:TUN モードは、システムプロキシを参照しない会議クライアントを含め、すべての通信を引き受けられます。初回起動時には仮想ネットワークアダプターのドライバーをインストールする必要があります。
- macOS:システムのネットワーク拡張で接続を確立します。初回接続時はシステム設定で許可が必要で、一部の権限は手動で確認する必要があります。
- iOS:Network Extension を使用し、VPN 構成の許可を求めるダイアログが表示されます。バックグラウンド動作はシステムの制限を受けるため、長時間の会議では電源に接続し、低電力モードをオフにすることをおすすめします。
- Android:VPN 権限を付与し、クライアントをバッテリー最適化の除外リストに入れる必要があります。そうしないと画面オフ後にシステムに終了され、会議の途中で通信が切れることがあります。
- Linux:コマンドラインクライアントをシステムプロキシまたは TUN と組み合わせて使います。デスクトップ環境によって分割の効き方が異なるため、導入前に一度実測してください。
切り替え戦略と導入前チェック
どんなに安定した回線にもメンテナンス時間はあります。手間を減らすなら、メインと予備の 2 本を用意しましょう。メインは IEPL 専用線、予備は中継を 1 本。重要な会議の 10 分前にメイン回線へ切り替え、以下の手順をひととおり実行します。具体的な回線の構成は回線一覧で照合でき、出口が本当に切り替わったかは出口 IP 確認で確かめられます。
- クライアントを開き、現在の回線が専用線であることを確認します。前回の切り替えで残った予備ノードのままになっていないか見てください。
- 出口 IP 確認で、通信が実際に回線を通っていることを確かめます。表示される都市はノードの所在地と一致しているはずです。
- 会議クライアントでループバックテストを 1 回実行し、統計パネルのパケットロスと遅延を確認します。
- UDP 転送が有効になっていること、そして会議アプリが分割ルールから漏れていないことを確認します。
- 会議中はノードの切り替えもサブスクリプションの更新も行いません。どちらも接続を再確立してしまいます。
- ✅ 切り替えとセルフチェックは会議の 10 分前に済ませ、会議に入ってから調整しない。
- ✅ モバイルのクライアントは省電力の除外リストに入れてあり、画面オフでも通信が切れない。
- ✅ 会議のドメインは専用線を通り、UDP 転送も有効になっている。
- ✅ 予備回線が使え、ワンクリックで戻す方法も把握している。
- ❌ 「ノード数が多い」を唯一の選択基準にすること。ノードが多いからといって経路が良いとは限らない。
- ❌ 会議中にサブスクリプションを更新したり、ノードを切り替えたりすること。
- ❌ スピードテストの下りピークだけを見ること。それは一瞬の数値で、会議中のパケットロスやジッターとは別物。
スピードテストが測るのは帯域のピークですが、会議が必要とするのは持続的に安定した低パケットロスです。下りがどれだけ速くても、夜間ピークのパケットロスが 5% ある回線では、ビデオ会議の映像はやはりぼやけます。回線の良し悪しは、スピードテストのスクリーンショット 1 枚ではなく、10 分間連続の遅延の揺らぎで判断してください。接続は正常なのに会議がカクつく場合は、まずトラブルシューティングの手順で 1 つずつ切り分けていきましょう。
結論:ビデオ会議がカクつくかどうかは、帯域ではなくパケットロスとジッターで決まります。回線選びの順序は IEPL 専用線を最優先、次に中継、直結は最後の受け皿です。シーン別に分割し、専用線は会議とリモートデスクトップに残します。プロトコル面では、パケットロス環境なら Hysteria2 / TUIC を優先し、速度制限を受ける場合は Trojan または VLESS + TLS に戻します。導入前にチェックリストをひととおり実行するほうが、会議中に火消しするよりずっと割に合います。