リモートワーク VPN の出来は、会議中の数分で分かります。Zoom、Teams、Slack が求めるネットワーク要件はそれぞれ異なります。ビデオ会議はパケットロスとジッターに弱く、メッセージ連携は常時接続がリセットされることに弱く、ファイル同期は途中の切断に弱いものです。この記事ではリモートワーク VPN のおすすめとして、この 3 種類の負荷ごとに要件を整理し、IEPL 専用線・中継・直結回線がそれぞれどんな場面に向くのか、そして遅延・ジッター・パケットロスを数分で自分で測る方法を解説します。
遅延、ジッター、パケットロス:会議がカクつく 3 つの本当の原因
帯域はもっとも過大評価されやすい指標です。Zoom の公式ネットワーク要件ドキュメントでは、720p のグループビデオで上下およそ 1.5 Mbps、1080p ではもう少し多く必要とされています。Teams の公式も 720p 通話で上下 1.5 Mbps 程度を推奨しています。一般的な家庭回線や 4G/5G ならこの水準は満たせるため、会議のカクつきはほとんどの場合、帯域不足ではなく次の 3 つの指標が原因です。
遅延は通常、往復遅延時間(RTT)で見ます。自分が話してから相手に届くまでの間隔です。150 ms 未満なら会話はほぼ自然に進みますが、200 ms を超えると話の被りや間が目立ち、「お先にどうぞ」という気まずいやり取りが生まれます。
ジッターは遅延の変動幅です。ジッターが大きいと音声バッファが追いつかず、音が途切れたりロボットボイスのように聞こえたりします。ビデオ会議アプリは遅延よりもジッターへの耐性が低くなっています。
パケットロスは破棄されたデータパケットの割合です。少量のランダムなロスなら符号化で補えますが、連続したロスが起きると映像はブロックノイズ状になり、ひどい場合は切断されて再接続になります。
3 つの指標のうち、遅延は我慢でき、ジッターは我慢しにくく、パケットロスは最も我慢できません。だからこそ、普段は遅延が低い直結回線が、夜のピーク時には遅延が少し高くてもパケットロスがほぼゼロの専用線に劣ることがあります。
Zoom、Teams、Slack のネットワーク要件を比較
3 社の公式ドキュメントが示す推奨しきい値はほぼ同じで、遅延 150 ms 未満、ジッター 30 ms 未満、パケットロス 1% 未満です。実際の違いは、どこに敏感かと、切断後の挙動にあります。
| ツール | 主な負荷 | 最も敏感な指標 | 劣化時の症状 | 回線選びのポイント |
|---|---|---|---|---|
| Zoom | リアルタイム音声・映像(RTP/UDP) | パケットロス、ジッター | 映像のフリーズ、音声の途切れ、解像度の自動低下 | パケットロスが少なく経路が安定した専用線 |
| Microsoft Teams | 音声・映像 + 画面共有 | ジッター、UDP の可用性 | 共有画面のぼやけ、遅延の蓄積 | UDP 転送に対応し、ジッターが小さい回線 |
| Slack | WebSocket の常時接続 + Huddle 音声 | 接続の安定性 | メッセージ通知の遅延、再接続後の再同期 | ノードを固定し、頻繁に切り替えない |
| クラウドストレージ / コードリポジトリの同期 | 大容量ファイル転送(TCP) | 帯域、切断 | 転送中断後の再送、進捗の巻き戻り | 帯域に余裕があり、会議の回線を圧迫しない |
この表を一言でまとめると、会議はパケットロスとジッター、コラボは接続が長期的に安定するか、同期は帯域が足りるかを見る、ということです。3 種類の負荷で要件が異なるので、回線も分けて選ぶべきです。
IEPL 専用線、中継、直結:3 種類の回線の違い
直結:クライアントが現地の出口から対象地域のサーバーへ直接接続します。経路は最短ですが、全区間が公衆インターネットの国際出口を通ります。日中は通常問題ありませんが、夜のピーク時に出口が混雑すると、遅延とパケットロスが同時に悪化します。
中継:まず中継ノード(一般的には香港、シンガポール、日本)に接続し、そこから対象へ転送します。一見遠回りですが、避けているのは最も混雑する国際出口の区間なので、夜のピーク時の安定性は通常、直結より優れています。
IEPL 専用線:企業向けの国際イーサネット専用線で、ポイントツーポイントで専用回線を通り、公衆インターネットを経由しません。遅延が安定しパケットロスも極めて少なく、3 つの中で長時間のビデオ会議に最も適しています。コストも最も高いため、大容量ファイルのダウンロードではなく、会議のように安定性に敏感な通信に向いています。
| 回線タイプ | 経路の特徴 | 遅延の傾向 | ピーク時の安定性 | 向く負荷 |
|---|---|---|---|---|
| IEPL 専用線 | ポイントツーポイントの専用線、公衆網を経由しない | 安定していて予測しやすい | 高い | ビデオ会議、地域をまたぐリアルタイム共同作業 |
| 中継 | 中継ノードを経由して転送 | 中程度、直結よりやや高い | 中～やや高め | メッセージ連携、Web とドキュメント |
| 直結 | 現地の出口から対象へ直接接続 | オフピーク時は最短 | 変動が大きい | 大容量ファイルの同期、リアルタイムでないタスク |
VPNFN は現在 120+ の国・地域、180+ の回線をカバーしており、回線一覧には 3 種類すべてが揃っています。これが負荷ごとに回線を分けて選べる前提でもあります。
ツール別の回線選び:会議・コラボ・同期は分けて通す
ビデオ会議:まず IEPL 専用線
会議の通信は唯一の「リアルタイム」負荷で、少しの揺らぎも聞き取られてしまいます。会議専用に IEPL 専用線を 1 本指定し、クライアントの振り分けルールに会議関連のドメインを書き込みます。専用線の入口がない地域なら、パケットロスが少ない中継回線に切り替え、最も混雑する時間帯の長時間会議は避けましょう。
メッセージ連携:速さより安定性
Slack や Teams のメッセージは常時接続でやり取りされるため、遅延が数十ミリ秒増えても誰も気づきませんが、接続が一度リセットされると通知が遅れ、未読状態も再同期が必要になります。この種の通信に専用線は不要で、必要なのは「ノードを頻繁に切り替えないこと」です。自動切り替えや遅延に応じた自動選択といった機能をオフにして、中継回線を 1 本固定しましょう。
ファイル同期とコードリポジトリ:帯域優先
クラウドストレージ、Git の取得、素材のアップロードは TCP の大容量通信で、遅延には敏感ではありませんが、回線全体を占有します。これらを会議の通信と同じ回線に載せると、会議は必ずカクつきます。合理的なのは振り分けです。同期系の通信は直結か通常の中継、会議のドメインは専用線に通し、互いに帯域を奪い合わないようにします。
プランの選び方:月額プランかトラフィックパックか
リモートワークは「毎日オンライン」の使い方で、会議・メッセージ・同期が一日中回線を使うため、月額プランが向いています。月額プランは ¥9.9、¥18、¥28 の 3 段階です。出張がたまにある、数週間だけ一時的に使うといった場合は、トラフィックパックが ¥158 / 300GB、¥358 / 1000GB、¥658 / 3000GB で、使い切るまで有効、期限なしで失効しないため、月末にゼロになる心配はありません。デバイスは台数無制限で、1 台を専用線で会議に、もう 1 台を中継で同期に使っても問題ありません。
振り分けルールと DNS:最もつまずきやすい 2 つの落とし穴
振り分けルールは、どの通信をどの回線に通すかを決めます。ルールモードではドメイン、IP レンジ、地域でマッチングし、該当したものは指定ノードへ、それ以外はデフォルトノードへ送ります。リモートワークでは、少なくとも会議ドメイン、コラボドメイン、同期ドメインを 3 つのグループに分けます。会議グループは専用線へ、コラボグループは固定の中継ノードへ、同期グループは直結へ。グローバルモードはすべての通信を 1 本の回線に押し込むため、会議のカクつきを最も招きやすい設定です。
UDP 転送は会議の必須条件です。ビデオ会議は WebRTC ベースで、UDP を優先して使います。クライアントや回線が UDP 転送に対応していないと、会議は TCP 中継にフォールバックし、遅延とジッターが明らかに悪化、ひどい場合は接続すらできません。回線を選ぶときは「UDP 対応」を必須項目にしましょう。
DNS リークとは、ドメイン名の解決がトンネルを通らず、現地キャリアの DNS に委ねられてしまうことです。結果は 2 つあります。解決結果がより遠い接続ポイントを指す可能性があり、最初のパケットの遅延が高くなります。さらに、アクセスの意図も現地 DNS に露出します。会議アプリは接続を確立する前に大量の名前解決を行うため、この段階で遠回りすると、その後の回線がどれだけ良くても取り戻せません。クライアントでリモート DNS 解決を有効にするか、信頼できる DNS を手動で指定しましょう。
会議の途中でノードを切り替えない
ノードを切り替えると接続が再構築され、会議クライアントは再ネゴシエーションが必要になり、映像が一瞬途切れ、場合によっては入り直しになります。回線を変えるなら会議の前に済ませ、会議中は切り替えないようにしましょう。
5 分で実測:遅延・ジッター・パケットロスを自分で測る
宣伝ページの数字を見るより、自分で一度測ってみるほうが確かです。以下の手順は Windows、macOS、Linux のいずれでも使えます。順番は変えないでください。
ping -c 50 対象ドメイン # 遅延 / ジッター概算 / パケットロス率
mtr -rwzbc 100 対象ドメイン # ホップごとのパケットロスとジッター(Windows は tracert)- まずローカル側の問題を除外:プロキシを切り、ルーターのゲートウェイに ping して、ローカルの Wi-Fi 自体にパケットロスがないか確認します。ローカルで落ちているなら、どの回線に変えても意味がありません。
- ping の 3 行の結果を見る:平均遅延(avg)、ジッターの概算(mdev)、パケットロス率(packet loss)。mdev が大きいほどジッターも大きくなります。
- 経路を見る:mtr の出力では、ときどき 1 ホップだけ落ちている箇所ではなく、継続的にパケットロスが出ているホップを探します。バックボーンのルーターが ICMP をレート制限するのはよくあることで、単一ホップの偶発的なロスはリンクの問題を意味しません。
- 会議中は公式の統計パネルを見る:Zoom の「統計情報」、Teams の「通話の状態」はジッター、パケットロス、実際の解像度をリアルタイム表示します。会議中に見える数字こそが実際の体感です。
- 日中と夜のピーク時にそれぞれ測る:同じノードの遅延とパケットロスの変化を比べます。変化幅が大きければ、その回線は混雑の激しい公衆網経路を通っているということです。
- ✅ 平均遅延 150 ms 未満、ジッター 30 ms 未満、パケットロス 1% 未満:会議には十分で、あれこれいじる必要はありません。
- ✅ 日中と夜のピーク時の数値が近い:経路が安定しており、長期的な会議に向いています。
- ❌ 遅延は正常なのにジッターが 30 ms を超える:回線を変えましょう。クライアントのパラメータ調整では解決しません。
- ❌ パケットロスが 1% を継続的に超える、または数秒ごとに規則的にロスする:典型的な混雑か回線品質の問題で、ノードを変えるべきです。
- ❌ クライアント表示の遅延は低いのに、会議中のジッターが高い:クライアントが表示するのは主にプローブ遅延で、リアルタイムのリンク品質とは同じではありません。
よくある質問
リモートワークでは必ず IEPL 専用線が必要ですか?
いいえ、必ずしも必要ありません。会議が多く安定性に敏感な場合に必要で、たまに会議をする程度ならパケットロスの少ない中継回線で十分です。専用線の価値は主に夜のピーク時に現れます。
なぜ日中は快適なのに夜はカクつくのですか?
公衆インターネットの国際出口は夜のピーク時に混雑し、直結回線が真っ先に影響を受けます。中継や専用線はこの区間を避けるため、より安定します。
会議に必要な帯域はどのくらいですか?
720p のグループビデオでは公式に上下 1.5 Mbps 程度が推奨され、1080p ではさらに多く必要です。多くの家庭回線で足りるため、カクつきは通常、遅延とパケットロスの問題です。
スマホとパソコンを同時に接続できますか?
デバイスは台数無制限で、1 台を専用線で会議に、もう 1 台を中継で同期に使っても互いに影響しません。
始めるのにメールアドレスは必要ですか?
メールアドレスなしで登録でき、30 日以内は理由を問わず返金できます。本サービスはログを記録しません。