VPN速度を正確に測る方法：ツール・時間帯・指標を実測比較

VPNの速度測定では、まず測定経路を確認

VPNの速度を正確に測るには、まずデバイス、回線、測定サーバー、ルーティング方式を固定し、普段利用する時間帯に繰り返し測定します。ダウンロードの最高速度は結果の一部にすぎません。ウェブページの表示、動画のバッファリング、会議中の途切れは、遅延、ジッター、パケット損失、継続的なスループットを合わせて判断する必要があります。

速度測定の経路は通常、デバイス、ローカルネットワーク、通信事業者のネットワーク、サービスの入口、出口、そして測定サーバーへと続きます。どの区間で混雑しても、測定結果は低下する可能性があります。そのため、測定サイトに表示される速度は特定ノード単体の性能を示すものではなく、その時点での経路全体の状態を表しています。

測定トラフィックが実際にプロキシを経由しているかも確認しましょう。ルールによる振り分けで測定サイトが直接接続になったり、ブラウザーはプロキシ経由でもコマンドラインツールは直接接続になったりする場合があります。クライアントの接続履歴、ルールの適用状況、同じツール環境での出口 IP を照合してください。ブラウザーで IP を確認しただけでは、すべてのアプリが同じ経路を使っているとは限りません。

遅延・ジッター・スループットの見方

「速さ」には、応答の速さとデータ転送のスムーズさという、少なくとも二つの側面があります。低遅延は操作への素早い応答に、大きなスループットはデータ転送に向いています。両者には関係がありますが、互いに置き換えられる指標ではありません。ページの表示には DNS の名前解決、接続の確立、サーバーの応答待ちも必要なため、ダウンロード結果が良くてもページの表示が遅いことがあります。

各指標の説明と主な利用場面。回線性能を保証するものではありません
指標	実際の意味	主な確認場面	誤解しやすい点
遅延	リクエストが指定した接続先との間を往復するのにかかる時間。通常は ms で表記	ウェブ操作、リモート操作、音声通話	クライアントの遅延測定値が、アプリでのアクセス遅延と一致するとは限らない
ジッター	時間の経過に伴う遅延の変動幅	会議、通話、リアルタイムのやり取り	平均遅延が低くても、一時的に大きく変動することがある
パケット損失	測定パケットが届かない、または応答を受信できない状態	途切れ、再送、接続停止の原因調査	測定パケットが制限・フィルタリングされても、実際の通信で同様に損失するとは限らない
ダウンロードスループット	単位時間あたりに実際に受信したデータ量。通常は Mbps で表記	動画のバッファリング、ファイルのダウンロード	短時間の最高速度は、長時間維持できる速度とは異なる
アップロードスループット	単位時間あたりに実際に送信したデータ量	クラウドバックアップ、ファイル送信、ビデオ会議	ダウンロードだけを見ると、上り速度不足による問題を見落とす

アイドル時の遅延と負荷時の遅延も区別しましょう。回線が空いているときは応答が速くても、ダウンロードやアップロードで回線を使い切ると遅くなる場合があります。キューの発生、ルーターのバッファリング、帯域の競合などが原因として考えられます。ネットワークが混雑しているときだけ遅延が増える場合、出口までの距離が原因だとすぐに決めつけないでください。

ジッターの計算方法やサンプリング方法はツールによって異なるため、測定結果をそのまま並べて比較するのは適切ではありません。ダウンロードツールでは MB/s、測定サイトでは Mbps が使われることもあり、数値の大小だけでは判断できません。記録時は元の単位を残し、必要に応じて単位を統一してください。

速度測定ツールの比較：診断とアプリでの確認は分けて行う

ツールを選ぶときは、まず何を調べたいかを考え、そのうえで結果を確認します。大容量ファイルの転送能力を知りたいならスループットを測り、途切れの原因を探すなら遅延や接続の過程を確認します。目的のサービスを快適に使えるかどうかは、最終的にそのアプリ自体で確認する必要があります。

ツールごとに測定経路は異なります。同じランキングのように比較しないでください
ツール・方法	確認に適した内容	利用時の注意点
Speedtest	指定した測定サーバーに対するダウンロード、アップロード、遅延	自動選択で比較条件が変わらないよう、サーバーと測定モードを固定する
Fast.com	Netflix の配信インフラを利用した転送状況	すべての動画プラットフォームでの速度を示すわけではなく、作品へのアクセス可否も確認できない
ping と経路追跡	応答する接続先の遅延変化や、ネットワーク経路の一部の手がかり	一般的なプロキシは ICMP を転送しない場合がある。中継地点が応答しなくても、回線障害とは限らない
ブラウザーの開発者ツール	DNS の名前解決、接続確立、応答待ち、リソース読み込みの過程	キャッシュの状態、ページのリソース取得元、プロキシルールを確認する
対象アプリでの実利用	動画のバッファリング、会議の品質、ダウンロードの安定性	アプリのサーバー、アカウント権限、コンテンツ配信方針にも左右される

自動選択される測定サーバーは、出口の変更に応じて切り替わる場合があります。回線を切り替えた後に測定結果が改善しても、回線全体の性能が上がったのではなく、測定先までの距離が短くなっただけかもしれません。回線を比較する場合は測定先をできるだけ固定し、普段の利用感を知りたい場合はよく使うサービスでも確認してください。

コマンドラインツールは繰り返し記録するのに便利ですが、プロキシに対応しているかを先に確認してください。プロキシ環境変数を読み取るツール、個別設定が必要なツール、システムプロキシを経由しないツールがあります。ブラウザーの測定は正常でもターミナルでは失敗する場合は、回線を評価する前に経路を確認しましょう。

再現性のある実測手順と記録方法

役立つ測定記録とは、後から見たときに「当時どのように測ったか」が分かるものです。複雑なダッシュボードは必要ありません。ネットワーク環境、クライアントのモード、回線、接続先サーバー、時間帯、利用時の感覚を記録しましょう。変更する条件が少ないほど、差を説明しやすくなります。

ローカル環境の基準を作る。クラウドストレージの同期、システム更新など、大量の通信が発生するタスクを一時停止します。まずローカルネットワークが正常に利用できることを確認しましょう。有線接続が使える場合は優先し、無線接続ではデバイスの位置と周波数帯を一定に保ちます。
測定条件を固定する。同じデバイス、クライアントのバージョン、測定ツールを使い、同じ測定サーバーを選びます。システムプロキシ、ルールによる振り分け、仮想ネットワークアダプターのどれを使ったかを記録し、対象リクエストが選択した回線を実際に通っていることを確認してください。
アイドル時と負荷時を確認する。アイドル時の応答を記録した後、ダウンロードとアップロードを測定します。転送中に停止しないか、ネットワークが混雑したときに操作への応答が遅くならないかを確認し、最高速度だけを記録しないようにしましょう。
測定を繰り返し、結果をすべて残す。同じ条件で複数回測り、結果のばらつきを確認します。十分なサンプルがある場合は中央値で典型的な状態を示し、異常値や失敗した結果も残してください。最速の結果だけを選ばないようにしましょう。
対象のアプリで確認する。よく見るコンテンツを再生する、普段使うページを開く、会議を試すなど、実際の利用状況を確認します。バッファリングや長い待ち時間の有無、アプリ独自のエラーメッセージを記録してください。
変更する条件は一つずつにする。それ以外の条件を保ったまま、回線、接続ネットワーク、クライアントモードをそれぞれ比較します。一度に変更する要素を一つにすると、差が生じた原因を特定しやすくなります。

記録項目には、日付と時間帯、接続ネットワーク、デバイスとクライアント、プロキシモード、回線名、測定サーバー、ダウンロードとアップロード、アイドル時と負荷時の遅延、実際のアプリ利用時の状態などを含められます。ツールで測定できない項目は「未測定」と記載し、感覚だけで数値を補わないでください。

測定する時間帯と、夜間の混雑を確認する理由

測定する時間帯は、最も高い結果が出やすい時間ではなく、自分の利用習慣をもとに選びましょう。日中に仕事をして夜に動画を見るなら、それぞれの場面で記録します。地域ごとに通信事業者や接続先サービスの負荷状況は異なるため、誰にでも当てはまる一律の混雑時間はありません。

条件を揃え、普段の混雑時間帯と比較的空いている時間帯を比べてから、別の日にも測定します。夜間にスループットが下がり、遅延の変動が増え、空いている時間帯に回復するなら、経路上で時間帯によるリソース競合が起きている可能性があります。ただし、競合の発生場所は家庭内ネットワーク、地域の通信事業者、サービスの入口、接続先サーバーのいずれかかもしれません。

直結、中継、IEPL 専用線はそれぞれ異なるネットワーク構成を表しており、速度測定の代わりにはなりません。中継では経路の区間が増えますが、適切な入口やルーティングによって利用感が改善する場合もあります。IEPL 専用線も共有リソースや出口の容量の影響を受ける可能性があります。名称から分かるのは経路の仕組みであり、端末から接続先までの性能が保証されるわけではありません。

同様に、プロトコル名は速度の順位を示すものではありません。接続プロトコル、転送方式、デバイスの性能、ネットワーク環境のすべてが通信品質に影響します。クライアントとサーバーが実際に対応している設定で測定することが大切です。提供元が不明な設定を比較目的で有効にしたり、サブスクリプションリンクを公開の測定レポートに貼り付けたりしないでください。

ノードを何度も切り替えるより、症状から原因を調べる

✅ すべての回線が遅い：まずローカルネットワーク、バックグラウンドのアップロード、無線信号、デバイスの負荷を確認します。次に接続ネットワークを切り替えて再測定し、ローカル環境によって結果が変わるかを見ます。
✅ 特定の測定サイトだけ遅い：条件を固定したまま別の測定先を試し、対象アプリでも確認します。測定サーバーの負荷や、出口からそのサーバーまでの経路が異なる可能性があります。
✅ 測定値は高いのにページ表示が遅い：DNS の名前解決、接続確立、最初の応答までの時間を確認します。クライアントのルール適用状況も照合し、ページが利用するリソースの経路が異なっていないかを確認してください。
✅ 動画はスムーズでも会議が途切れる：上り速度、ジッター、負荷時の遅延、アプリのリアルタイム通信を重点的に確認し、ダウンロードの最高速度だけを比較し続けないようにしましょう。
❌ ping が応答しないだけで利用不可と判断する：測定プロトコルがフィルタリングされている、またはプロキシを経由していない可能性があります。実際の接続とアプリのリクエストも確認してください。

DNS についても個別に考える必要があります。DNS リークは、名前解決のリクエストが想定した経路を通らない問題であり、「名前解決が遅い」という意味ではありません。出口 IP だけを見ても、名前解決経路の違いは判断できません。クライアントの DNS 設定、システム設定、検査結果を照合してください。OS やプロキシモードによって処理方法が異なるため、利用中のクライアントの説明に従って調整しましょう。

Windows、macOS、Linux では、システムプロキシと仮想ネットワークアダプターの適用範囲が異なる場合があります。モバイル端末では省電力設定やバックグラウンド動作の制限も影響します。複数のプラットフォームで比較する場合は、こうした違いを記録し、スマートフォンとパソコンの結果をそのまま回線の優劣の根拠にしないでください。

サポートへ問い合わせる際は、個人情報を伏せた測定条件、日時、回線、ツール、エラーの内容を伝えれば十分です。サブスクリプションリンク、アカウント情報、設定の全容は公開しないでください。スクリーンショットにもそれらの情報が含まれていないか確認しましょう。