リモートワークVPNの選び方:会議と共同編集ツールの回線選び

リモートワークVPNの良し悪しはノード数では決まらない。決め手は、毎日実際に流れているトラフィックの種類だ。ビデオ会議、クラウドドキュメント、コードホスティング、クラウドストレージの同期では、ネットワークに求めるものがそれぞれ違う。ノードを十数個試しても会議が固まる人もいれば、振り分けルールを直しただけで快適になる人もいる。まず負荷を分類し、そのあとに回線を選ぶ。順序を逆にすると試行錯誤が終わらない。

まず3種類の負荷を分ける:会議・共同編集・同期

リモートワークのトラフィックは一種類ではない。ビデオ会議はリアルタイムの音声・映像で、主に UDP で運ばれる。クラウドドキュメント、オンラインホワイトボード、コードホスティングはリクエスト・レスポンス型の対話トラフィック。クラウドストレージのクライアントや大容量アップロードは長時間の上りスループットだ。3者は求めるネットワーク指標がまったく違い、1本の回線ですべてを賄おうとすると、たいていどこかのシーンで先に破綻する。

判断の順序は固定しておきたい。まず会議が安定しているか、次に共同編集が遅れなく追従するか、最後に同期が上りを出し切れるか。会議の不調はコミュニケーションそのものに響くので優先度が最も高い。同期が遅いのは待ち時間の問題なので、時間帯をずらせばよい。

ビデオ会議:パケットロスとジッターは帯域より深刻

リアルタイムの音声・映像は UDP で流れるため、落ちたパケットを待って再送する仕組みがない。エンコーダは前方誤り訂正とパケットロス隠蔽で補うが、補えるのは「聞き取れる」レベルまで。補いきれない分は画面のモザイク、音切れ、そして相手がいつも半拍遅れるという形で現れる。

3つの指標で実際にどう感じるか

• パケットロス:経験上、ロス率が1〜2%を長時間超えるとビットレートが引き下げられ、映像はくっきりからぼやけへ、音はこもって金属的な響きになる。
• ジッター:パケットの到着間隔が不安定になると、受信側のバッファが強制的に長くなり、会話にエコーのような響き、話し出しの被り、画面共有のページ送りの残像として現れる。
• 帯域:1対1の1080p会議なら双方向合計で通常2〜4 Mbpsあれば足りる。多人数会議に画面共有が重なると、上りの必要量は倍々で増えていく。

会議で専用線を優先する理由

IEPL 専用線は独立したチャネルで、端から端まで他のユーザーと公共出口の待ち行列を奪い合わない。中継はバックボーンノードを経由して転送するため、ピーク時間帯は待ち時間が長くなる。直結はローカル出口を使うので、越境の回り込みも輻輳も制御できない。会議はパケットロスをほぼ許容しないため、ノードを専用線に置くことは不確実性をあらかじめ減らすことになる。どの都市に専用線があるかは回線の説明で地域別に確認できる。

コラボツール:遅延が操作の追従性を決める

クラウドドキュメントは入力のたびに往復確認が発生し、オンラインホワイトボードはカーソル位置を同期し、コードホスティングの push と pull は典型的なリクエスト・レスポンスだ。こうしたトラフィックは帯域の要求は低いが、往復遅延には極端に敏感で、遅延が倍になれば入力もドラッグも明らかに遅れ、カーソルが一マス遅れてついてくるように見える。

プロトコル層の違い

コラボツールの多くは TCP か QUIC の上で動く。TCP はパケットを1つ落とすと再送を待つため、遅延の揺らぎが増幅される。QUIC は UDP 443 を使うのでロスからの復帰は速いが、UDP を帯域制限しているネットワークではかえって遅くなる。見分け方は簡単だ。同じノードで Web 版とデスクトップクライアントをそれぞれ10分ずつ使い、追従がよいほうを常用すればよい。

DNS と振り分け

接続しても遅いままなら、DNS 問い合わせがトンネルを通っていないことがよくある。名前解決の結果がローカルの位置で返り、遠くのエッジノードへ振られてしまう。確認方法は、接続前と接続後にシステムが実際に使っているリゾルバをそれぞれ見ること。2回の結果が同じなら、問い合わせはローカルに残っている。

# VPN 接続の前後に1回ずつ実行し、名前解決の出口を比較する
# macOS
scutil --dns | grep -m3 nameserver
# Linux(systemd-resolved)
resolvectl status | grep -i "current dns"

振り分けルールも10分かけて設定する価値がある。社内ネットワークや社内 OA は直結、会議と共同編集ドキュメントは専用線、クラウドストレージと大容量ファイル同期は帯域に余裕のあるノードへと分ければ、3種類の負荷が互いを圧迫しない。ルールはドメインのサフィックスと IP レンジで書けばよく、1件ずつ列挙する必要はない。

ファイル同期:上り帯域と通信量の枠

クラウドストレージの同期、素材のアップロード、コードリポジトリの初回クローンは上り帯域を消費し、しかも数十分単位で走り続ける。こうしたタスクに低遅延は不要で、必要なのは安定したスループットと途切れない接続だ。実のところ会議と同じ上りを取り合っているが、会議が負けたときのほうが症状は派手に出る。

振り分けで両者を分けられる。クラウドストレージとリポジトリのドメインは帯域に余裕のあるノードへ、会議と共同編集ドキュメントは専用線に残せば、2本の経路が互いを圧迫しない。多くのクライアントはルールベースの振り分けに対応しており、OS 側で TUN モードに引き受けさせてからドメイン単位で除外し、同期タスクを別の出口へ向けることもできる。

通信量の枠は前もって計算しておきたい。VPNWing の月額プランは ¥9.9 で 60GB、¥18 で 250GB、¥28 で 500GB で、通信量は開通日ごとに毎月リセットされる。大きなファイルを同期するときはトラフィックパックを追加できる。¥158/300GB、¥358/1000GB、¥658/3000GB で、使い切るまで有効、期限はなく失効しない。途中でプランをアップグレードした場合、差額は残り日数で按分される。各プランの対応表はプランと料金を参照。

回線種別とプロトコル:本当に見るべきパラメータ

ノード名の都市は位置にすぎず、体感を決めるのは回線種別だ。3種類の回線は経路も向く用途も大きく違う。

プロトコルについて。Shadowsocks は軽量な暗号化プロキシ。VMess は時刻検証があり、クライアントの時刻が大きくずれると接続できない。VLESS はより軽量で、TLS の上に載ることを前提とする。Trojan はトラフィックを通常の HTTPS に見せかけ、443 番ポートを使う。Hysteria2 と TUIC は QUIC ベースで輻輳制御がより積極的、パケットロスのある経路での復帰が速いが、UDP が帯域制限されていないことが前提だ。実際の利用ではプロトコルはサーバー側から配信され、サブスクリプションリンクをクライアントに取り込めばよく、手動でパラメータを入力する必要はない。

プラットフォームごとのクライアントにも違いがある。Windows と macOS はシステムプロキシと TUN の2通りの接管方法に対応する。iOS はシステムのネットワーク拡張として動作するため、Wi-Fi とモバイル回線を切り替えたあとに接続状態のままか確認したい。Android はシステムレベルの VPN サービスとして動き、アプリ単位の振り分けができる。Linux は TUN デバイスとコマンドラインを組み合わせる。5つのプラットフォームすべてにクライアントがあり、登録に必要なのはユーザー名とパスワードだけ、メールアドレスは不要だ。

シーン別にそのまま使える回線選びのルール

ここまでの内容を5つのルールに圧縮した。日常的にはこれに従えばよく、毎回ゼロから考え直す必要はない。

1. 会議は専用線に固定:よく使う会議ツールは IEPL 専用線の1本に固定し、ダウンロードや同期タスクと同じ出口を共有しない。
2. 共同編集は近くの低遅延で:クラウドドキュメントとホワイトボードは遅延が最も小さい中継または直結ノードで十分。専用線を狙う必要はなく、専用線はリアルタイムの音声・映像に取っておく。
3. 同期は別の1本で:大容量ファイルの同期は帯域に余裕のあるノードへ向け、会議のない時間帯に配置して上りを奪わないようにする。
4. 先に測ってから決める:同じ時間帯に候補の2回線でそれぞれ会議を1回、ドキュメントを10分ずつ書き、固まりと遅れを記録してから常用する回線を決める。
5. まず回線を変えてから切り分ける:問題が出たらまず別の回線に変える。変わって回復すれば回線側の問題。変わっても同じなら、自宅の回線、ルーター、端末の負荷を調べる。

作業開始前の点検リスト

ネットワーク環境が変わるたび(出張先のホテル、自宅回線、シェアオフィス)に、以下を一通り確認しておくと、「つながるけど使いにくい」の切り分け時間を大幅に減らせる。

• ✅ 会議ツールは専用線ノードで一度フル通話を試し、映像も音声も正常だった。
• ✅ クラウドドキュメントの入力、ホワイトボードのドラッグに目立った遅れがなく、カーソルも正常に追従する。
• ✅ 接続後に名前解決の出口を確認し、DNS 問い合わせがトンネル内のサーバーを通っている。
• ✅ 振り分けルールで、クラウドストレージとリポジトリは帯域に余裕のあるノード、会議のドメインは専用線に向いている。
• ✅ 大容量ファイルの同期は会議の外に配置し、リアルタイムのトラフィックと上りを奪い合っていない。
• ❌ 会議中に回線を切り替える——再ネゴシエーションが走り、かえって固まりやすくなる。
• ❌ サブスクリプションリンクを同僚に送って共用する——サブスクは資格情報と同じなので、各自が自分のアカウントを使うほうが安全だ。
• ❌ ノード名だけ見て回線種別を見ない——同じ都市名でも専用線と中継が併存していることがある。

回線さえ合っていれば、あとは習慣の問題だ。会議の10分前に余裕を持ち、同期タスクは時間帯をずらし、サブスクリプションリンクは外に出さない。この3つを守れば、リモートワークのネットワークがボトルネックになることはまずない。つながらない、あるいはつながるのにページが開かない場合はトラブル診断で項目ごとに確認してほしい。