リモートワーク向けVPNおすすめ：Web会議とコラボツールの回線実測比較

リモートワーク向けVPNの結論を1つだけ残すなら、Web会議はまずパケット損失とジッタ、ドキュメント共同編集は遅延、コードホスティングとパッケージ管理は帯域と再送コストを見る。回線の順序は専用線、中継、直結の順だ。以下では3つの指標を分解して説明し、自分で再現できる比較方法を示したうえで、振り分けルールと各プラットフォームのクライアントの違いに触れる。

オフィスの回線と家庭の回線で最も違うのはピーク速度ではなく安定性だ。日中は国際出口が比較的空いているが、夜8時を過ぎると同じ回線群のパケット損失は明らかに増える。リモートワークの不満はほぼこの時間帯に集中するので、回線は「最悪の時間帯」で選ぶべきで、スピードテストで最も良い数字が出た1回を基準にしてはいけない。

パケット損失・遅延・ジッタ：3つの重要指標

パケット損失は、一定時間内に宛先へ届かなかったパケットの割合だ。Web会議はUDPで動くため、失われたパケットは再送されず、映像はそのままモザイク状に劣化し、音声は途切れた機械音になる。一般に1〜2%の損失でも聞き分けられる。一方、コードの取得やクラウドストレージの同期はTCPなので、損失が再送を引き起こし、画質が落ちるのではなくプログレスバーが数十秒止まる形で現れる。同じ回線でも2種類のツールで体感がまったく違うことがあり、「他人は快適と言うのに自分は固まる」原因の多くはここにある。

遅延はデータが往復する時間、つまりRTTだ。音声会議では200ミリ秒を超えると話がかぶり始め、リモートデスクトップや共同編集はさらに敏感で、カーソルの追従が目に見えて遅れる。国際アクセスには物理的な下限があり、光がファイバーを一往復するだけで数十ミリ秒かかり、そこにルーティングの回り込みが加わる。「ゼロ遅延」という主張は成立せず、できるのは回り込みをより短くすることだけだ。

ジッタは遅延の変動幅、つまり遅延の分散だ。平均遅延よりも通話品質に効く。平均80ミリ秒でもジッタが60ミリ秒ある回線は、150ミリ秒で安定している回線より聞き心地が悪いことが多い。会議の途切れの苦情の多くは、実は帯域不足ではなくジッタだ。

3種類のツールの要件差

リモートワークで使うツールは、トラフィックの形で3種類に分けられる。小さなパケットを流し続ける会議とドキュメント、大きなパケットを断続的に出すコードとパッケージ管理、長時間つながったままリクエストはまばらなAI補完だ。回線への負荷のかかり方が違うので、すべてを同じプロキシグループに入れるべきではない。

会議とダウンロードを同じプロキシグループに入れるのは最もよくある間違いだ。OSのアップデート1回で会議用回線の帯域が埋まり、会議では「相手の声が聞こえない」と言われるだけになる。グループ分けの意味は分類を見やすくすることではなく、種類の違うトラフィックが互いの帯域を奪わないようにすることにある。

専用線・中継・直結の違い

直結はクライアントが海外ノードに直接つなぎ、出国は公共の国際出口を通る。コストは最も低いが、夜のピークで国際出口が混雑すると損失とジッタが同時に増える。単発のダウンロードやミラー同期など、再試行できる作業に向き、やり直しのきかないリアルタイム用途には向かない。

中継はまず近隣の中継ノード（通常は香港・日本・シンガポール）につなぎ、そこから海外へ出る。国内区間は最適化された経路を通り、国際区間は公衆網なので、直結より安定し専用線より安い。日常のドキュメント共同編集やコードホスティングはおおむねこの帯に収まる。

専用線（IEPLなど）は事業者グレードの国際イーサネット専用線で、出国後は私有リンクを通り、公共の国際出口を経由しない。価値はピーク帯域ではなく、夜のピークでの変動が最小であることにある。Web会議、リモートデスクトップ、ライブ配信など再試行できない用途にこそ、専用線のリソースを割く価値がある。

回線選定の順序：4ステップで実践

上の結論を操作に落とすと、順序は次の4ステップになる。変更する順番を入れ替えないこと。入れ替えると測ったデータに比較の価値がなくなる。

1. まずローカル出口のベースラインを測る。プロキシを一切かけずに対象サービスへpingし、損失とジッタを記録する。これが対照群になる。
2. 会議は専用線を1本確保する。会議サービスのドメインを独立したプロキシグループに入れ、専用線だけを使い、ダウンロードやアップデートと同じ出口を共有しない。
3. ドキュメントとコードは中継を使う。リクエスト量は多いが数百ミリ秒の追加遅延は許容できるので、中継グループに任せれば専用線の帯域を節約できる。
4. 直結は非リアルタイムの作業だけに残す。OSアップデート、ミラー同期、大容量ファイルのダウンロードは直結に置き、会議用回線を占有させない。

サブスクに回線が1本しかない場合は、会議の時間帯だけ独占を優先し、それ以外の時間に他のツールへ回す。会議は通常1日2〜3時間なので、その数時間の回線品質を固定するほうが、1日を通した平均速度より重要だ。

再現できる実測方法

使うツールはOS標準のping、mtr、curlだけだ。3つのコマンドがそれぞれ損失とジッタ、経路のホップごとの品質、TCPハンドシェイクと初回バイトをカバーし、その回線で会議ができるか判断するには十分である。対象ドメインは実際に使っているサービスに置き換えればよい。

# 1. 損失とジッタ：200パケット連続で送り、loss% と mdev を見る
ping -c 200 zoom.us

# 2. 経路のホップごとの品質：どのホップから損失が出るか
mtr -rwzc 100 github.com

# 3. TCPハンドシェイクと初回バイト：UDPの影響を排除
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer}\n' https://github.com

結果の読み方：pingのloss%はパケット損失率、mdevはジッタの目安で、最も良い1回を拾うのではなく200パケット全体の分布を見る。mtrのLoss%はホップごとに見て、あるホップから継続的に上がっていれば問題はその区間のリンクにあり、クライアントを変えても無駄だ。curlのtime_connectとtime_starttransferはそれぞれTCPハンドシェイクと初回バイトに対応し、ドキュメント共同編集とAI補完は主にこの2項目を見る。

比較方法：同じ時間帯（たとえば20時から23時）に直結・中継・専用線をそれぞれ測定し、それぞれ3回連続で、各回の間隔を2分あけて中央値を取る。同じ時間帯・同じ対象・同じマシンのデータでしか横比較はできず、時間帯をまたいだ比較に意味はない。

振り分けルールとDNSリークの対処

振り分けとは、ドメインを用途ごとにグループ化し、クライアントがルールでマッチさせる仕組みだ。Clash系クライアントはrule-providersでドメイン集合を取得し、sing-boxはroute.rulesでdomain_suffixを設定する。ルールは上から下へマッチするので、会議グループは必ず最上部に置く必要がある。そうしないと後続のルールに拾われ、設定したつもりで実際には効いていない状態になる。

DNSリークとは、DNSクエリがプロキシを通らず、そのままローカルの回線事業者に解決されることだ。これには2つの問題がある。クエリ内容が平文DNSに露出すること、そして解決結果が自分から遠いCDNノードになり、遠回りした結果かえって遅延が増えることだ。対処はクライアントにDNSを任せ、fake-ipモードかリモート解決を使い、同時にブラウザ内蔵の「セキュアDNS」をオフにすること。オンのままだとプロキシを迂回して自分で問い合わせてしまう。

プロトコル面では、Shadowsocks（AEAD暗号化）、VMess、Trojan（TLSで通常のWebトラフィックに偽装）、VLESS（より軽量で、XTLSやRealityと組み合わせることが多い）は主にTCPで動く。Hysteria2とTUICはQUICベースでUDP上を走り、損失と遅延の大きい回線に強いが、一部のネットワークではUDPが速度制限されたり遮断されたりする。サブスク内の全回線は統一された強力な暗号化を採用しており、プロトコルの違いは主に転送特性と弱い回線での挙動に現れる。

各プラットフォームのクライアントの違い

同じサブスクでもOSによって挙動は一致しない。違いは主に2点、すべてのトラフィックを引き受けられるか、バックグラウンドでOSに停止されないかだ。

• Windows：TUNモードで全トラフィックを引き受ける。システムプロキシとTUNを同時に有効にしないこと。2つのルールが互いを上書きしてしまう。
• macOS：初回起動時にネットワーク拡張の許可が必要。会議アプリで「直接接続」オプションが有効だと、プロキシを迂回してローカル出口を使う。
• iOS：サブスクを読み込んだらVPN構成が有効になっているか確認する。バックグラウンドプロセスはOSに停止されるため、会議の前にクライアントを開き直して接続状態を見る。
• Android：クライアントを省電力のホワイトリストに入れる。入れないと画面オフ後にプロセスが終了され、会議の途中で切断される。
• Linux：コマンドラインクライアントをsystemdで常駐させる。デスクトップ環境ではプロキシを別途設定するか、TUNを直接使う。

会議の前に接続状態をもう一度確認するほうが、後から原因を調べるよりはるかに楽だ。特にノートPCの蓋を閉じて開き直した後、多くのクライアントは「接続済み」の表示のまま実際のリンクは切れている。

導入前の自己点検リスト

以下のチェックリストは会議の場面ごとに整理したものだ。1項目ずつ確認すれば、当日のトラブルの大半は排除できる。

• ✅ 会議開始10分前にpingを1回実行し、パケット損失が0であることを確認
• ✅ 会議のドメインは専用のプロキシグループに分け、ダウンロードやアップデートと共有しない
• ✅ curlで出口IPと地域が想定どおりか確認
• ✅ DNSはクライアントに任せ、ブラウザ内蔵のセキュアDNSはオフにする
• ✅ サブスクにTCP回線を1本残し、UDPが制限されたときのバックアップにする
• ❌ 無料の公共ノードで顧客との会議に臨む
• ❌ 会議中に回線を切り替えたりルールを変更したりする
• ❌ サブスクのリンクを公開リポジトリやチャットグループに貼る

結論と料金対応

VPNDHの回線表は地域と回線タイプ別にグループ化されており、会議用グループでは専用線ノードだけを選べる。月額プランは ¥9.9 で 60GB、¥18 で 250GB、¥28 で 500GB。通信量は開通日ごとに毎月リセットされ、途中でアップグレードした場合の差額は残り日数で按分される。台数制限はなく、ノートPC、タブレット、オフィスのデスクトップで同時にログインできる。メールアドレスは不要で、ユーザー名とパスワードだけで登録でき、初回支払い後60日以内なら無条件返金を申請できる。回線が合わなかったときの試行錯誤のコストは抑えられる。

よくある3つの質問