リモートワークVPN 比較検証:ビデオ会議とコラボツールが最も苦手とするパケットロス、回線はこう選ぶ

なぜ会議は動画視聴よりパケットロスに弱いのか

同じ国際回線でも、夜に4K動画を見る分にはまったく問題なくても、翌朝の会議では途切れが続くことがあります。原因は帯域の大きさではなく、この2種類のトラフィックがパケットロスを扱う仕組みの違いにあります。

動画サイトは HTTP over TCP で通信します。プレーヤーはあらかじめ一定量を先読みしてバッファにためておき、経路上でパケットが1つ失われても TCP が再送します。バッファが尽きる前に再生が追いついていれば、ユーザーは気づきません。バッファの役割は、ネットワークの揺らぎを吸収することにあります。

ビデオ会議は別の道を通ります。Zoom、Teams、Google Meet といったツールは WebRTC をベースにしており、音声は Opus、映像は VP8 / VP9 / H.264 / AV1 で符号化し、メディアデータは RTP に格納して SRTP で暗号化し、UDP 上で流します。UDP は到達を保証しませんし、リアルタイムのメディアストリームも再送を待ってはくれません。往復1回分の再送を待つ間に、その一瞬の音声はとうに再生されるべき時刻を過ぎています。会議アプリの対処は、失われたものはそのままにし、直前の音声で補間するというものです。そのため経路上で1%のパケットが失われると、聴感上は1〜2秒ごとに軽い途切れが起きる状態になります。

3つの指標のうち、会議への影響が大きい順に並べると、パケットロス > ジッタ > 遅延です。パケットロスは内容の欠落を直接引き起こし、ジッタは受信側のバッファが調整に追いつかず音声が速くなったり遅くなったりする形で現れ、遅延が大きくなると会話で互いに話をかぶせるようになります。

1% パケットロス率の目安:この水準になると音声の途切れが聞き取れ、映像にもブロックノイズが出はじめる
150ms ITU-T G.114 が示す片方向遅延の推奨上限。これを超えると会話で話がかぶりやすくなる
20ms Opus でよく使われるフレーム長。受信側のジッタバッファはこのオーダーで調整される
0 UDP メディアストリームが再送を待つ回数:失われた部分は飛ばし、直前の音声で補間する

「帯域」と「品質」は分けて考えてください。帯域は同時に何本のトラフィックを流せるかを決め、パケットロスとジッタは1本1本の品質を決めます。会議のカクつきはほとんどの場合が後者の問題で、帯域を2倍にしても途切れは消えません。

リモートワーク3用途の回線要件比較

リモートワークはひとつの用途ではなく、いくつかの用途の集まりです。中心となるのは会議・ファイル同期・リモートデスクトップの3つで、その外側にオンラインドキュメントとパッケージマネージャーの取得という、見落とされがちな2種類のトラフィックがあります。それぞれ回線に求める条件が違うので、同じ基準でまとめて扱うと、どれか一つは必ず使いにくくなります。まず1日の業務を分解し、どの用途の比率が最も高いかを見てください。

用途	代表的なツールとプロトコル	最も影響が大きい指標	向いている回線	不調時の症状
ビデオ会議 / 音声通話	Zoom、Teams、Google Meet;WebRTC / SRTP over UDP	パケットロス、ジッタ	IEPL専用線を優先、次に中継	音声の途切れ、映像のブロックノイズ、発言がかぶる
ファイル同期 / コードリポジトリ	Git、クラウドストレージクライアント、オブジェクトストレージ;TCP + TLS	帯域、往復遅延(RTT)	中継または直結	プログレスバーが進んだり止まったりし、大きなファイルは再送を繰り返す
リモートデスクトップ / SSH	RDP、VNC、SSH;TCP	往復遅延、パケットロス	IEPL専用線または中継	マウスカーソルがずれる、入力遅延がはっきり分かる、画面がブロック単位で描画される
オンラインドキュメント / ホワイトボード	WebSocket、HTTPS	往復遅延	中継または直結	カーソルが同期しない、保存がずっと読み込み中のまま
パッケージ管理 / ミラー取得	npm、pip、Docker Registry;TCP	帯域	中継または直結	取得がタイムアウトする、検証に失敗して再ダウンロードになる

表からはひとつの法則が読み取れます。即時性に依存するトラフィックほどパケットロスとジッタを許容できず、待てるトラフィックほど帯域と往復遅延だけを見ればよいということです。回線選びの第一歩は価格の比較ではなく、自分が毎日どの種類のトラフィックを流しているかを確認することです。

IEPL専用線・中継・直結の使い分け

回線タイプが決めるのは「トラフィックがどの出口から海外へ出るか」です。よくある3つの経路は、コストと安定性がほぼ一対一で対応します。安定するほど高く、安いほど時間帯の影響を受けやすくなります。

直結:コストは最小、夜のピーク時間帯に最も影響を受けやすい

クライアントが海外ノードに直接接続し、トラフィックは自宅回線の国際出口から公共インターネットの国際ルートを通ります。利点は設定が簡単で帯域も十分に取れること、欠点は夜のピーク時間帯に国際出口が最も混雑し、パケットロスとジッタが増えることです。直結はファイル同期、パッケージ管理、ミラー取得など再送が効くトラフィックや、急がないダウンロードに向いています。

中継:国際区間を最適化ルートに任せる

クライアントはまず最寄りの中継ノードに接続し、そこから最適化されたルートで海外へ出ます。いわば「ラストワンマイル」と「国際区間」を分けて扱う形で、国際区間の経路は直結より安定し、遅延の変動も小さくなります。中継はリモートデスクトップ、オンラインドキュメント、Web での共同作業、そして日常的な海外サービスへのアクセスの大半に向いています。

IEPL専用線:リアルタイムトラフィックのための経路

IEPL は端末間をつなぐイーサネット専用線で、国際区間は公共インターネットの出口を通りません。パケットロスとジッタは非常に低く抑えられ、遅延も安定します。ビデオ会議、音声通話、ライブ配信といったリアルタイムトラフィックに向いています。代わりに帯域コストが最も高く、通常は回線ごとに割り当てられるため、大きなファイルの転送には向きません。専用線の帯域をクラウドストレージの同期に食わせてしまうと、会議に回す分がなくなります。

回線タイプ	経路	最も向いている用途	コストと注意点
直結	ローカルの出口 → 公共インターネットの国際ルート → 海外ノード	ファイル同期、パッケージ管理、ピーク外のダウンロード	夜のピーク時間帯はパケットロスとジッタが目立ち、会議には向かない
中継	最寄りの中継ノード → 最適化ルート → 海外ノード	リモートデスクトップ、オンラインドキュメント、日常のブラウジング	直結より安定するが、国際区間は依然として混雑の影響を受ける
IEPL専用線	端末間の専用線で、国際区間は公共インターネットの出口を通らない	ビデオ会議、音声通話、ライブ配信	帯域コストが高く、回線ごとの割り当てなので大きなファイルの転送には使わない

結論を一言で:リアルタイム系は専用線、対話系は中継、スループット系は直結か中継。3つの経路はどれか1つを選ぶものではなく、同じサブスクリプションの中で用途ごとに分担し、同時に存在して互いの帯域を奪い合わないようにします。

ルーティングルール:会議通信は遠回りさせない

ルーティングの目的は「接続できるかどうか」ではなく、それぞれのトラフィックを本来通るべき回線に通すことです。同じサブスクリプションの中で、会議は専用線、リモートデスクトップは中継、大きなファイルの同期は直結と振り分ければ、3つの経路がそれぞれの位置に収まり、どれかが他を押しのけることもありません。

振り分けの根拠は通常3つあります。ドメインと IP レンジ、プロセス名(デスクトップクライアント)、アプリ(モバイル)です。最も手間が少ないのはドメイン単位のグループ分けで、会議アプリやコラボツールのドメインは比較的固定しているため、メンテナンスのコストが最も低くなります。

# ルーティング設定の例:フィールド名は使用するクライアントの設定形式に準拠
groups:
  meeting:                        # 会議通信 → IEPL専用線
    - DOMAIN-SUFFIX,zoom.us
    - DOMAIN-SUFFIX,teams.microsoft.com
    - DOMAIN-SUFFIX,meet.google.com
  interactive:                    # リモートデスクトップ / オンラインドキュメント → 中継
    - DOMAIN-SUFFIX,notion.so
    - IP-CIDR,198.51.100.0/24     # サンプル用のネットワークセグメント。自分のリモートデスクトップのアドレスに置き換えてください
  bulk:                           # ファイル同期 / パッケージ管理 → 直結
    - DOMAIN-SUFFIX,github.com
    - DOMAIN-SUFFIX,registry.npmjs.org
    - DOMAIN-SUFFIX,pypi.org

ルールを書いたら、2つのことを検証します。ひとつは会議のドメインが確かに会議グループにヒットしているか、もうひとつは中国国内のドメインが誤ってプロキシグループに入っていないかです。中国国内のトラフィックまで国際回線に流し込めば、専用線はさらに混雑するだけです。クライアントが「グローバル」と「ルール」の2段階しか提供せず、カスタムポリシーグループがない場合は、一歩引いて会議アプリだけを別の段に設定し、会議のときだけ切り替え、終わったら戻すという運用でも構いません。

ルーティングルールは、ドメイン解決が正しく行われることが前提です。クライアントがドメインの解決をローカル ISP の DNS に任せると、解決リクエストがプロキシの外に出てしまいます。いわゆる DNS リークです。返ってくる IP も回線の入口と一致するとは限らず、IP をもとに振り分けるクライアントではルールが噛み合わないことがあります。確認方法は次の節で扱います。

クライアントと DNS:サブスクリプション導入後に確認したい項目

サブスクリプションのリンクは、ノードを手入力する手間を省くだけのものではありません。ノード一覧、回線の変更、ルーティングルールはすべてサブスクリプション経由で更新されるため、サーバー側で回線が調整されても、クライアントが次に取得した時点で同期されます。端末ごとに設定を書き換える必要はありません。多くのクライアントは定期的な自動更新に対応しているので、1日1回に設定しておくのがおすすめです。

プロトコル面では、クライアントが対応する主な種類に Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC があります。リモートワークにおいてプロトコルは最優先事項ではありません。同じサーバーでプロトコルを変えても、パケットロスやジッタは消えません。Hysteria2 と TUIC は QUIC ベースで、パケットロスがある環境向けの独自の輻輳制御と再送戦略を持ち、回線状況が悪いときの体感は良くなりますが、それでも公共インターネット上を走るため、専用線の代わりにはなりません。会議の品質を実際に決めるのは回線タイプと出口の経路です。

プラットフォームごとのクライアントの違いは、振り分けが使えるかどうかに直結します。

Windows / macOS:TUN モードとプロセス単位の振り分けに対応し、会議クライアント、ブラウザ、クラウドストレージをそれぞれ別のポリシーグループに振り分けられます。
iOS / iPadOS:システムの VPN 構成プロファイルで動作し、初回有効化時に「構成の追加を許可しますか」というダイアログが出るので、必ず許可を押してください。システム上、同時に有効化できる VPN 構成は1つだけです。
Android:VpnService を使い、アプリ単位の振り分けに対応します。システムの省電力設定でクライアントが終了させられることがあるため、ホワイトリストに追加しておく必要があります。
ルーター / サブルーター:会議室のハードウェアビデオ端末など、クライアントを入れられない機器はサブルーターでカバーします。

DNS リークとは、トラフィックはプロキシを通っているのに、ドメイン解決のリクエストだけがローカルネットワークから出てしまう状態を指します。解決記録が露出するだけでなく、振り分けルールが一致しない IP を受け取る原因にもなります。クライアントで「プロキシ DNS を使用」を有効にするか DoH / DoT を指定したうえで、DNS リーク検出ページで一度確認してください。解決の出口は、プロキシの出口と同じ地域になっているはずです。

✅ サブスクリプションを導入したら、まずノード一覧が正常に更新できることを確認してから会議に入る
✅ DNS リーク検出ページを開き、解決リクエストの出口とプロキシの出口が同じ地域であることを確認する
✅ クライアント側で会議アプリを専用のポリシーグループに入れ、グローバル設定に従わせない
✅ 会議の前に、クライアントが表示する回線遅延を見て、現在の回線が利用可能な状態かを確認する
❌ 会議の最中にノードを切り替えたり、ルーティングルールを変更したり、サブスクリプションを更新したりしない
❌ グローバルモードで大きなファイルを同期しない。専用線の帯域が同期タスクに奪われます

会議がカクつくときは、この順番で切り分ける

会議がすでにカクついている状態で設定を大きくいじると、余計に混乱するだけです。以下の5ステップを順に進めれば、それぞれの段階で原因の種類をひとつずつ切り分けられます。

まずネットワークの問題かデバイスの問題かを切り分けます。タスクマネージャーやアクティビティモニタで CPU とメモリの使用率を確認し、同時に進行中のクラウドストレージ同期やダウンロードを一時停止して、もう一度再現させてみてください。デバイス側のカクつきと回線の途切れでは、症状の出方が違います。
現在どの回線を通っているかを確認します。クライアントで会議トラフィックがヒットしているポリシーグループとノード種別を見て、直結ノードに落ちている場合はまず専用線に切り替えて再試行します。
同じ会議を2つの回線で比べます。途切れが消えればボトルネックはパケットロス、それでもカクつくなら問題はデバイス、相手側、あるいは会議アプリ自体にあります。
振り分けと DNS を確認します。会議のドメインが会議グループにヒットしているか、解決の出口とプロキシの出口が一致しているかをチェックします。
最後に MTU を見ます。ハンドシェイクは正常で小さなファイルは転送できるのに、メディアストリームだけ途切れ続ける場合は、MTU の不一致で大きなパケットが破棄されている可能性があります。クライアントの MTU を既定値から1段階小さくして(たとえば 1400)、もう一度試してください。

切り分けの順番の核心:まずデバイスとローカル帯域を除外し、次に回線タイプを確認し、最後に設定ファイルに手を入れる。順番を逆にすると、本来問題のないクライアントを延々といじり続けることになります。

会議のカクつきと回線選びに関するよくある質問

動画はスムーズなのに、会議になるとカクつくのはなぜ?

2種類のトラフィックではパケットロスの扱いが違います。動画は TCP で、バッファと再送が支えてくれます。会議は UDP のメディアストリームで再送がなく、パケットロスがそのまま音声の欠落になります。同じ回線で動画が問題なくても、会議も問題ないとは言えません。

専用線は必ず中継より速い?

「速い」は分けて考える必要があります。専用線の強みはパケットロスとジッタが低く、遅延が安定していることで、ピーク帯域が中継より大きいとは限りません。大きなファイルの転送なら中継や直結のほうが速いこともあり、会議や通話なら専用線のほうが安定します。

1つのサブスクリプションでこの3つの用途をすべてカバーできる?

できます。ただしクライアントが振り分けとポリシーグループに対応していることが前提です。VPNEM のサブスクリプションは同時接続台数に制限がなく、ノート PC、タブレット、会議室の端末で1つのサブスクリプションを共有し、それぞれが用途に応じた回線を使えます。

会議の前にどんな準備が必要?

事前にクライアントを起動し、サブスクリプションが更新済みであること、会議アプリが会議グループにヒットしていること、DNS 解決の出口が正常であることを確認してください。会議中はノードの切り替え、ルールの変更、サブスクリプションの更新をしないでください。

結論:そのまま運用できる回線構成

ここまでの結論を一文にまとめると、リアルタイム系は専用線、対話系は中継、スループット系は直結か中継に振り分け、それをルーティングルールで固定する、となります。会議がカクつくかどうかはパケットロスとジッタで決まり、ファイル転送が速いかどうかは帯域と往復遅延で決まります。2つの課題は2つの経路で解決し、1本の回線で同時に満たそうとは考えないでください。

使用量の目安は次のとおりです。会議とドキュメント共同作業が中心で使用量が多くないなら、月額 ¥9.9 / 60GB のプランで足ります。終日接続して頻繁に同期するなら ¥18 / 250GB、複数端末で大量のファイルをやり取りするなら ¥28 / 500GB を検討してください。使用量が安定せず、周期ごとのリセットを避けたい場合は、トラフィックパック ¥158 / 300GB から。使い切るまで有効で期限はなく、補助として適しています。

VPNEM の場合、回線側は110+ か国、210+ 回線を用意し、サブスクリプションは同時接続台数に制限がなく、登録にメールアドレスは不要、返金保証は60日です。支払いは Alipay、WeChat、USDT に対応しています。まず1つのサブスクリプションで振り分けと回線を動かしてみて、実際の使用量に合わせてプランを調整するほうが、最初から大きなプランを買うより堅実です。