VPNの速度を比較するには、端末・ローカルネットワーク・測定先を固定し、時間帯を変えて接続状況を確認します。スピードテストの最高値はあくまで参考値です。普段使いに適しているかどうかは、目的のアプリが安定して開くか、通信が続く間に滞らないか、夜間の混雑時も作業を続けられるかで判断しましょう。

この記事では、あらかじめ決めたランキングを掲載したり、1回の測定結果を回線の性能保証として扱ったりしません。以下の方法で自分の測定結果を記録すれば、原因がローカルネットワーク、選択した回線、接続先のウェブサイトのどこにあるかを見分けやすくなります。

まずは測定条件をそろえる

比較を始める前に、用途を明確にします。ウェブ閲覧では表示の応答、ファイルのダウンロードでは持続的な転送速度、オンライン会議やストリーミングでは通信の安定性が重要です。用途によって重視する指標は異なります。ダウンロードの最高速度だけで、あらゆるアプリの使い心地を判断することはできません。

同じ端末、同じ接続方式を使い、ローカル環境が近い状態で測定します。有線と無線の結果は同じグループに混ぜないでください。無線しか使えない場合は端末の位置を固定し、クラウドストレージの同期、システム更新、ほかの端末での大容量ダウンロードを一時停止します。そうしないと、回線の違いではなく、家庭内ネットワークの混雑を測ってしまう可能性があります。

  • ✅ 端末、クライアントのバージョン、接続ネットワーク、プロキシモードを記録し、比較時も同じ条件にします。
  • ✅ バックグラウンドでの大容量通信を止め、ほかのネットワーク高速化ツールが同時に接続を処理していないことを確認します。
  • ✅ 回線名、出口の地域、測定先、測定時間帯を記録します。結果のスクリーンショットだけを保存するのでは不十分です。
  • ✅ まずローカルネットワークの基準値を測り、その後に回線へ接続して測定します。基準値の測定先には、現在のネットワークから正常にアクセスできるものを選びます。
  • ❌ 異なる測定サーバーやネットワーク環境で得た最高値を、そのまま順位付けしないでください。

基準値はローカルの接続に異常がないかを確認するためのもので、海外回線でも同じ速度が出ることを示すものではありません。接続前にアクセスできないウェブサイトは「基準値の測定対象外」と記録し、アクセス失敗をダウンロード速度ゼロとして扱わないでください。

速度測定ツールの選び方

ブラウザーの速度測定では、現在のプロキシ設定を通るウェブ通信のスループットを確認できます。Speedtestは、画面上で測定サーバーを固定できる場合、繰り返し比較するのに便利です。Cloudflareの速度測定ページも、ネットワーク品質を調べる別の手段として使えます。それぞれ測定先や方法が異なるため、結果は分けて保存し、ひとつのスコアとして合算しないでください。

速度測定ツールが自動で選ぶ「近くのサーバー」は、出口の地域によって変わることがあります。同じ地域の回線を比較する場合は、できるだけ同じ測定先に固定します。異なる地域を比較する場合は、測定先を固定した結果と実際のアプリでの結果をそれぞれ記録できます。ただし後者は、回線単体の性能ではなく、アクセス経路全体を測ったものだと明記してください。

ブラウザーの開発者ツールにあるNetworkパネルは、特定のウェブページの問題を調べるのに適しています。リクエストが長時間待機していないか、失敗していないか、リソースがキャッシュから読み込まれていないかを確認できます。純粋な帯域幅の測定ツールではありません。ファイルのダウンロードを測る場合は、信頼でき、テストが許可されている配布元を選び、開始直後の瞬間的な数値だけでなく、転送中の速度を確認します。

システムプロキシは、通常、一般的なターミナルのICMP pingを経由させません。クライアントに表示される「遅延」も、TCP接続やHTTPによる確認にかかった時間である場合があります。数値を解釈する前に測定方法を確かめ、どの結果も同じ経路を測ったものだと決めつけないでください。

コマンドラインツールも、システムプロキシを自動で使うとは限りません。選択した回線を経由しているか確認できない場合は、まずブラウザーや実際に使うアプリで測定してください。TUNモードを有効にしていても、ルーティング、分割トンネルのルール、クライアントによる対象通信の処理方法を確認する必要があります。

遅延・ジッター・パケットロス・ダウンロード速度

これらの指標は、それぞれ異なる問題を表します。遅延が小さくてもスループットが高いとは限らず、スループットが高くても長時間の接続が安定しているとは限りません。記録には測定方法、単位、接続先も残し、異なるツールに同じ名前で表示される指標を直接比較しないようにしましょう。

指標の意味と用途。すべてに共通する合格基準は設けていません
指標 わかること 注目するポイント よくある誤解
遅延 測定リクエストの往復時間、またはツールが定義する応答時間 ウェブページの応答や操作に遅さを感じないか 測定先や測定方法の違いを無視する
ジッター 連続して測定した遅延のばらつき 会議、音声、継続的な操作の応答が不安定にならないか 平均遅延だけを見て、ばらつきを確認しない
パケットロス 指定した測定方法で応答が返ってこなかった状態 継続的な通信が途切れたり、再試行が発生したりしないか ICMPの応答制限を、すべての通信でのパケットロスと誤認する
ダウンロード・アップロード 測定中に各方向で得られた実効スループット ダウンロード、同期、添付ファイル送信の継続的な通信状況 複数接続による測定の最高値を、単一ファイルの速度とみなす
負荷時の遅延 ネットワークが混雑しているときの応答時間 ダウンロード中にウェブ閲覧や会議が目立って遅くならないか ネットワークが空いているときだけ測り、通信待ちの影響を無視する

MbpsとMB/sは単位が異なるため、数値をそのまま比べないでください。複数接続を使う速度測定は、単一接続のダウンロードより高いスループットが出やすい場合があります。実際のファイルのダウンロード速度には、配布元の速度制限、ディスクへの書き込み速度、接続数も影響します。速度測定の結果が良くても特定のサイトが遅いことは、矛盾ではありません。

パケットロスの解釈には特に注意が必要です。ルーターが測定用パケットへの応答を低い優先度で処理する場合があります。一部の測定地点から応答がなくても、最終的な接続先やアプリが正常なら、それだけで経路全体に実通信のパケットロスがあるとは言えません。接続先の結果と実際のアプリの動作をあわせて判断してください。

普段の時間帯と夜間の混雑時に測定する

実際にネットワークを使う時間帯を選び、普段比較的空いている時間と、よく利用する夜間の混雑時を分けて測定します。夜間の混雑時間は、場所や利用習慣によって異なるため、一律の時間帯を当てはめないでください。空いているときの見栄えのよいスクリーンショットより、日を変えて繰り返し測定した結果のほうが参考になります。

  1. まず基準値を確認します。ローカルネットワークでウェブサイトを正常に閲覧できるか、接続に問題がないかを確かめ、バックグラウンド通信の有無を記録します。
  2. 比較する回線に接続します。クライアントの接続完了を待ち、出口の地域と現在のモードを確認してから、新しい測定リクエストを実行します。
  3. 測定先を固定して繰り返します。最高値だけを選ばず、結果をすべて残します。異常があれば状況を記録して再測定します。
  4. 実際の用途でも試します。普段使うウェブサイトを開く、自分のファイルを転送する、通常のストリーミング再生を確認するなど、実際のタスクを行います。
  5. 時間帯を変えて再測定します。同じ設定を使い、比較する回線を交互に測定して、測定順による偏りを抑えます。

回線を切り替えても、アプリが以前の長時間接続を再利用する場合があります。新しい結果が新しい回線に対応していることを確かめるには、接続先とのセッションを張り直してください。ただし、大切なアップロードや作業中の接続は途中で切り替えないでください。再測定では「初回の読み込み」と「キャッシュ後の読み込み」も分けて確認します。キャッシュによってネットワークの違いが見えにくくなることがあります。

ファイルを最後までダウンロードして測定すると、プランの通信量を消費します。必要な比較を済ませ、明らかに異常な回線だけを絞って再測定してください。最大速度のテストを続ける必要はありません。4MVPNの月額プランの通信量は利用開始日にリセットされ、追加データパックは使い切るまで有効で期限はありません。測定に使う通信量も、ご自身の利用計画に含めてください。

比較しやすい形で結果を記録する

複雑なスコアを付ける必要はありません。測定日と時間帯、ローカルネットワーク、クライアントのモード、回線名、測定先、各指標の結果、実際のタスクでの状況を記録します。システム更新中だった、無線の電波状況が変わったなどの事情があれば、その場でメモし、後から記憶だけで説明しないようにしましょう。

繰り返し測定したときの代表的な値とばらつきを重視します。測定回数が十分にある場合は、偶然の最高値の影響を抑えるために中央値を参考にできます。ただし、失敗や大幅な速度低下の記録も残してください。失敗が続くこと自体が結果です。集計を良く見せるために削除してはいけません。

用途に合わせて判断し、万能の順位は付けない

  • ウェブ閲覧・開発ツール:ダウンロードの最高速度だけでなく、リクエストの完了、接続の再確立、ストリーミング出力がスムーズかを確認します。
  • オンライン会議:ジッター、音声の途切れ、ネットワーク混雑時の応答を確認し、アプリの通信が想定した経路を通っているかも確かめます。
  • ファイル転送:持続的なスループット、アップロードの状況、長時間の転送が正常に完了するかを確認します。
  • 動画配信:実際の再生、画質の変化、バッファリングを確認します。視聴できるかどうかは、配信サービスの地域制限やアカウントの利用条件にも左右されます。

空いている時間帯には速くても、夜間の混雑時に大きく低下する回線があった場合は、「自分のネットワークでは、この時間帯によって結果に差があった」と記録しましょう。すべての地域や利用者に当てはまる結果として一般化してはいけません。回線選びの参考にはサーバーページを確認し、最終的にはクライアントの一覧と実際の接続状況で判断してください。

結果に異常がある場合は、順番に原因を確認

まずローカルネットワークを確認します。基準値も低下している場合は、無線の電波状況、ルーターの負荷、バックグラウンド通信、接続事業者を優先して確認してください。別の接続ネットワークで試すと原因を特定しやすくなりますが、それは新たな測定条件です。別に記録し、元の比較結果に混ぜないでください。

次に分割トンネルと出口を確認します。測定用ドメインや目的のアプリが想定どおりプロキシを経由しているか確かめてください。システムプロキシを使うアプリもあれば、個別の設定が必要なアプリもあります。ブラウザーで確認した出口アドレスが示すのは、そのブラウザーのリクエストの出口だけです。すべてのアプリの通信が同じ経路を通る証明にはなりません。

続いてDNSと接続先のサービスを確認します。名前解決に時間がかかると、初回の表示が遅くなることがあります。DNSリークテストは名前解決リクエストの露出状況を確認するもので、帯域幅の測定ではありません。ブラウザーの暗号化DNS、システムの名前解決、クライアントのDNS設定は異なる場合があるため、ログやルールも確認してください。測定ページに表示されるリゾルバーの所在地だけで、通信経路全体を判断することはできません。

最後に回線の経路を比較します。直結、中継、IEPL専線は、それぞれ異なる接続方式を表しており、名称自体が速度を保証するものではありません。中継によって経路の一部が改善することもあれば、遠回りになることもあります。専線接続後の出口や接続先のサイトも結果に影響します。実際の回線タイプを記録し、名称だけで優劣を決めないでください。

サポートが必要な場合は、パネルのサポートチケットから、測定した時間帯、クライアントのバージョン、回線名、接続先のサイト、エラーの状況をお知らせください。スクリーンショットを共有する前に、サブスクリプションリンク、アカウント情報などの機密情報を隠してください。サブスクリプションURL全体を公開の速度測定記録に載せないでください。

測定結果のまとめ方

普段のタスクを安定してこなせて、よく使う時間帯にも繰り返し同じような結果が出る回線を選びましょう。条件を固定して差を確認し、実際のアプリで試したうえで、用途に応じた予備の回線も残しておきます。1回の最高値だけで全体を判断しないでください。

信頼できる結論には、測定した場所と時間、使用したツール、接続先、発生した制約を記載します。記録していない挙動については結論を出さず、確認していない安定性を保証しないでください。

端末、接続ネットワーク、クライアント設定を変更したら、同じ手順で再測定してください。速度測定の目的は、ずっと変わらない順位を作ることではありません。再現でき、問題を切り分けられ、自分に合う回線を選ぶための方法を確立することです。