テレワークでVPNを使うとき、一番失敗しやすいのはウェブページが開かない場面ではなく、ビデオ会議の途中でカクつき始めることです。画面が固まり、声が途切れる——それなのに速度測定を走らせると数字はきれいなまま、ということも少なくありません。理由は、会議ソフトがパケットロスと遅延に敏感で、その敏感さは帯域幅とは桁違いだからです。この記事ではまずこの仕組みを掘り下げ、地域・回線タイプ・プロトコルの3ステップで選ぶ順序と、会議中のトラブル対応チェックリストを紹介します。
速度測定は速いのに、会議だけカクつく理由
ビデオ会議は、双方向に流れ続ける小さなデータストリームです。720p通話なら上下各数百Kbps〜2Mbpsもあれば足り、ほとんどの家庭回線はそれを大きく上回ります。問題は「流れ続ける」点にあります。会議のストリームは毎秒何百・何千もの小さなパケットを送り、その一部でも越境の公衆網区間で失われると、受信側は再送を待つかフレームを諦めるしかありません。体感としては、声がロボットのように途切れ、画面が数秒固まったまま一気に飛ぶ、という形で現れます。
一方、一般的な速度測定ツールが測るのは「一気にどれだけ速く流せるか」です。複数の並列接続でパケットロスの影響を薄め、数秒単位の揺れも平均に埋もれます。つまり測定結果が良くても分かるのは帯域が十分だというだけで、経路が安定だとは言えません。会議品質を測る業界標準の指標は遅延・ジッター・パケットロス率の3つで、Zoom公式の推奨しきい値は次の通りです:
回線は3方式、耐パケットロス性はまるで違う
越境VPNの回線は通常3種類に分かれます。違いは、端末から接続先サーバーまでの間をどんな経路で流れるかです。経路が違えば、公衆網の揺れを受ける度合いもまったく変わってきます:
| 回線タイプ | データの流れ | 安定性の特徴 | 会議での評価 |
|---|---|---|---|
| IEPL専用回線 | 端末 → 通信事業者の閉域網 → 接続先。越境区間は公衆網を経由しない | パケットロス率はバックボーン並み。夜間ピーク時も安定 | ビデオ会議の第一選択 |
| 公衆網中継 | 端末 → 中継サーバー → 接続先。越境区間は公衆網を通る | 入口の品質は管理可能。ピーク時は公衆網区間が揺れる可能性 | 日常のブラウジングには十分。会議は次善の選択 |
| 直結 | 端末 → 接続先サーバー。経路が最短 | ホップ数が少なく遅延で有利。ただし越境公衆網区間の品質は制御不可 | 遅延は有利、安定性は時間帯次第 |
まとめると、IEPL専用回線の越境区間は閉域網の中にあり、公衆網の混雑が伝わりません。中継と直結の越境区間はどちらも公衆網上にあるため、夜間ピークで公衆網が混雑すると、パケットロスがそのまま会議ストリームに届きます。39VPNの回線リストは100以上の国・180以上の回線をカバーしており、会議の時間帯は専用回線を優先して選ぶのがテレワークで最も安心なやり方です。具体的な回線一覧はサーバー一覧ページから地域別に確認できます。
回線選びの順番:まず地域、次にタイプ、最後にプロトコル
「会議に必要なのは安定」と分かったら、回線選びは3ステップに固定できます。環境が変わっても同じ順序で進めましょう:
- まず地域を決める。会議プラットフォームがあなたのトラフィックをどの地域のサーバーに振り分けるかは制御できませんが、どこから接続するかは自分で決められます。アジア地域の会議なら香港・日本・シンガポールなど近場の接続先を選んで往復遅延を低く抑え、欧米の同僚との会議では対応地域の回線に切り替えて、トラフィックが地球を一周するのを避けます。
- 次にタイプを選ぶ。会議の時間帯はIEPL専用回線を固定で使い、会議後の調べものやメールの送受信は中継や直結に戻します。専用回線を、安定性に敏感なトラフィックのために残しておくという使い分けです。
- 最後にプロトコル。プロトコルは、パケットを「どんな方式で送り出すか」を決めます。UDPベースのHysteria2・TUICは前方誤り訂正(FEC)を備え、送信側が冗長情報を添えて送るため、パケットロスのある経路でも再送を待たずに復元でき、会議ストリームへの恩恵は大きいです。一方、TCPベースのShadowsocks・Trojan・VLESSは、パケットロスに遭うと輻輳制御が働き、転送レートを自ら絞ります。クライアントがマルチプロトコル切り替えに対応しているなら、会議ではUDP系を優先しましょう。
クライアントで調整する価値のある3つの設定
回線を選んだ後も、クライアント側の3つの設定が会議体験に直結します。最初の設定時に済ませておく価値があるものです:
- 分割ルール。端末全体をプロキシ化するより、会議ソフトと業務トラフィックだけをトンネルに通す方が良いです。主要クライアントはプロセス単位・ドメイン単位の分割に対応しています。プリンター・NAS・社内システムなどのローカルリソースは直接接続のまま残し、会議やコラボツールだけプロキシ経由にすれば、通信量も抑えられ、変数も一つ減ります。
- DNS設定。クライアントのリモートDNS(いわゆる「漏えい防止DNS」)オプションを有効にして、名前解決のリクエストもトンネル経由にします。解決リクエストがプロキシを迂回してローカルネットに露出するのを防ぐ、いわゆるDNS漏えい対策です。社内ドメインを利用している場合は、必ず直接接続ルールに追加し、解決がプロキシ経由になって失敗するのを防ぎましょう。
- 複数端末の待機。39VPNは端末台数の制限がないため、PCで会議しながらスマートフォンを同じ回線に接続して待機させておけます。メイン端末にトラブルが起きたらすぐ切り替えられ、再ログインも再設定も不要です。
会議中にカクついたときの応急対応
実際にカクついたら、影響の小さいものから順に対応します。最初から設定を大きく変えるのは禁物——変更が増えるほど変数も増えます:
- ✅ 同じ地域の別回線に切り替える——単一回線の一時的な混雑はよくあることで、変えるだけで復帰することも多い
- ✅ 映像を切って音声優先に——音声ストリームは帯域とパケットロスへの耐性が最も高く、まず会議を続けられるのが優先
- ✅ スマートフォンのテザリングで数分比較——テザリングで正常なら、問題はVPNではなくローカル回線側
- ❌ 会議中にサブスクリプションの更新や設定の再インストールをしない——会議が終わってから。一度に変えるのは一つまで
- ❌ クラウド同期や大容量ダウンロードを並走させない——上り帯域を一瞬で食い潰し、会議ストリームを押しのけます
会議ではまず安定性、次に遅延、最後に帯域幅の順で見る。会議用にはIEPL専用回線を1本固定し、プロトコルはHysteria2かTUICを優先。普段のブラウジング用に近場の地域の回線を1本組み合わせれば、「会議の品質は運任せ」からほぼおさらばです。39VPNは30日間の無条件返金に対応しているので、新しい回線を定例会議で数日試してから判断しても遅くありません。