VPN速度測定実測比較：自分で測るためのツール・時間帯・指標

VPNの速度を比較するときは、まず測定対象の通信経路を確認し、そのうえで速度を見ましょう。クライアントに接続中と表示されても、速度測定サイトの通信が選択した経路を通っているとは限りません。この記事では実践しやすい測定手順を紹介します。実在しない回線ランキングを作ったり、一度の最高速度を長期的な性能として扱ったりはしません。

役立つのは見栄えのよいスクリーンショットではなく、同じ端末・同じネットワーク・同じ測定先で、普段使う時間帯に回線がどう動くかを示す結果です。ダウンロードの安定性、Webページの応答、通話の途切れをそれぞれ記録しましょう。異なる指標をひとつの総合スコアで置き換えることはできません。

速度測定の前に通信経路を確認

端末、クライアント、接続中のネットワーク、選択したノード、ルーティングモードを記録します。クラウドストレージの同期、システム更新、ほかのダウンロードは停止し、端末の場所や電源の状態もできるだけそろえましょう。Wi-Fiでは電波状況や同じネットワークを使う端末の影響も受けるため、その変動を回線の問題と決めつけないでください。

次に、測定ツールの通信がプロキシを経由しているか確認します。ブラウザーの速度測定はシステムプロキシに従う場合もあれば、クライアントのルールで直接接続になる場合もあります。コマンドラインのツールがシステムプロキシの設定を参照するとも限りません。TUNモードはより多くのアプリの通信を扱える傾向がありますが、ルーティングや除外ルール、クライアントの実装にも左右されます。モード名だけで経路を判断しないようにしましょう。

まず外部から見えるIPアドレスを確認し、続けてクライアントの接続ログを開いて、測定サイトのドメインにどのルールと出力先が適用されたかを調べます。IPアドレスの確認で分かるのは、その確認リクエストの経路だけです。速度測定サービスが別のドメインを使う場合もあるため、測定中の接続ログも確認してください。ログに測定リクエストがなければ、結果を比べる前に経路の問題を解消しましょう。

速度測定ツールで分かること

ツールは数を増やすのではなく、目的に合わせて組み合わせましょう。Speedtestは指定した測定サーバーまでのスループット、Fast.comは同サービスのコンテンツ配信ネットワークを経由したダウンロード速度の確認に向いています。ブラウザーの開発者ツールでは実際のWebリクエストを調べられます。サーバーや接続方法、負荷条件が異なるため、各ツールのスコアをひとつのランキングのように並べてはいけません。

クライアントのノード一覧に表示される「遅延」も、測定方法を確認しましょう。サーバーのポートを調べているだけのものもあれば、プロキシ経由で指定URLにアクセスするものもあります。完全な通信経路を反映しているとは限りません。測定方法と対象が同じ場合に限り、ノード一覧の数値を横並びで参考にできます。

測定前に単位も確認しましょう。帯域測定ではMbps、ダウンロードソフトではMB/sが使われることがあります。単位が異なる数値をそのまま比べることはできません。見栄えのために換算して単位を省略せず、元の単位を記録してください。

遅延・ジッター・帯域幅を分けて見る

操作の快適さは応答速度と変動で確認

遅延は通信の往復にかかる時間、ジッターは遅延が時間とともにどれだけ変化するかを示します。Webページの操作、リモート操作、音声通話では応答の安定性が重要です。平均遅延が安定して見えても、途中で長く待たされることがあれば実際の使い心地はよくない場合があります。変動と通信の失敗もあわせて確認しましょう。

通信していないときの遅延と、ダウンロード中の遅延も同じではありません。アップロードやダウンロードで回線を使い切ると、通信の待ち行列によって応答が遅くなることがあります。「ダウンロード中にWebページの表示が明らかに遅い」ときは、負荷時の遅延を測れるツールを確認し、手元のルーターやアクセス回線、経路上の待ち行列も検討しましょう。ダウンロードの最高速度だけを見て判断しないでください。

連続した通信では転送速度と中断を確認

帯域幅の測定結果が示すのは、特定の測定先・時点における実効的な転送能力です。手元のアクセス回線、国際経路、出口、測定先のサーバー、端末の処理能力など、複数の要因に左右されます。複数接続の測定では回線を使い切りやすく、単一接続でのファイルダウンロードが同じ速度に達しないこともあります。どちらかの結果が必ず不正確というわけではありません。

パケットロスの解釈にも注意が必要です。ICMPの応答がない場合、実際にパケットが失われた可能性だけでなく、宛先による速度制限やフィルタリングの可能性もあります。Web閲覧やダウンロード、通話に問題がなく、特定の測定先だけが応答しないのであれば、実際の通信でも同程度のパケットロスが起きているとは限りません。アプリの再試行、通信の中断、接続失敗もあわせて確認しましょう。

同じ時間帯に繰り返して比較する

普段ネットワークを使う時間帯に合わせて測定しましょう。比較的空いている時間と、動画視聴や仕事、通話をよく行う混雑時間の両方を含めます。深夜の結果を夜間の使用感の代わりにしたり、別の日・別のネットワークで撮った画面をそのまま比較したりしないでください。複数の回線を測る場合は近い時間帯に順番に試し、次回は順番を入れ替えて時間帯の変化による偏りを抑えましょう。

1. ローカル環境の基準値を記録。国際経路を使わずに、手元のアクセス回線が正常かを測ります。この基準値はローカル環境の問題を見つけるためのもので、異なる遠隔地の測定先との比較や回線の損失計算には使いません。
2. 共通の条件を固定。端末、ネットワーク、クライアントのバージョン、ルーティングモード、測定先をそろえ、実際に使う候補ノードを選びます。
3. 出力先を確認してから測定。ノードを切り替えるたびに外部から見えるIPアドレスと接続ログを確認し、自動選択や障害時の切り替えで測定対象が意図せず変わっていないか確かめます。
4. 測定項目を分けて実施。まず通信していない状態の応答を測り、その後ダウンロードとアップロードを測定します。帯域を奪い合わないよう、複数の測定ページを同時に動かさないでください。
5. 実際の使い方でも確認。よく使うWebサイトを開く、コンテンツを再生する、通話やダウンロードを行うなど、読み込み時間や画質の変化、中断の有無を記録します。
6. 繰り返し測定し、異常値も残す。最高の結果だけを残さないでください。通常時の状態と明らかな低下を記録し、失敗した測定も原因や状況とともに残します。

速度測定では通信量を消費し、とくに長時間のダウンロードは多くの通信量を使います。通信量に上限のあるプランを利用している場合は、残量を確認してから測定範囲を決めましょう。より高い速度を出すために何度も回線を使い切る必要はありません。通信量のルールはプラン・料金ページで確認できます。

記録表には、測定日と時間帯、ローカルネットワーク、クライアントとモード、ノード名、出口の地域、ツールと測定サーバー、指標の元の単位、実際の用途での状況を記載しましょう。「ダウンロードが安定して続く」「負荷時に応答が遅くなる」のように記録すれば十分です。測っていない数値を無理に補う必要はありません。

回線の種類やプロトコルだけでは速度を比較できない

直結は通常、クライアントから海外のサーバーへ直接接続する方式です。中継では経路上に転送ポイントが加わります。IEPL専用線は専用の回線リソースを指しますが、端末から接続先のWebサイトまでの全経路が専有されるという意味ではありません。専用線でも、手元のアクセス回線や出口の容量、接続先のサービスがボトルネックになることがあります。中継で迂回を改善できる場合もあれば、経路の負荷が増す場合もあります。同じ条件で測定して判断しましょう。

Shadowsocks、VMess、Trojan、VLESSはそれぞれ異なるプロキシプロトコルまたはプロトコル体系です。Hysteria2とTUICはQUICをベースにした通信方式を採用しています。実際の性能は通信設定や実装、ネットワーク側のUDP処理、混雑状況にも左右されます。プロトコル名だけで「速い」と判断することはできず、クライアントとの互換性も確認が必要です。

サブスクリプションリンクは、ノード情報や設定をクライアントに取り込むためのもので、速度測定用のアドレスではありません。リンクを取り込んだ後は、クライアントが対応する形式・プロトコル・通信設定を確認しましょう。同じ名前のノードでも、クライアントによって設定が異なれば厳密に同じ条件での比較にはなりません。初期設定は初心者ガイド、回線情報はノード情報をご覧ください。

複数のプラットフォームを比べるときは、OSごとの違いも考慮しましょう。デスクトップのシステムプロキシは、プロキシ設定に従うアプリにだけ影響することが一般的です。モバイル端末ではOSのVPNインターフェースを使って通信を扱うことが多いものの、アプリごとの設定、省電力制限、バックグラウンド動作の制御で結果が変わる場合があります。回線を比較するときはクライアントを固定し、クライアントを比較するときは回線と測定先を固定しましょう。

速度測定に問題があるときは、近い要因から確認

• ✅ すべてのノードが遅い：まずローカルネットワーク、バックグラウンド通信、端末の負荷を確認し、別のアクセス回線でも再測定します。ノード設定を何度も変更するのは避けましょう。
• ✅ 特定の測定ツールだけ遅い：測定サーバーを固定し、別のツールと実際のアプリでも確認して、配布元やコンテンツ配信経路の違いに注意します。
• ✅ ダウンロードは速いのにWebページの表示が遅い：ドメインの名前解決、接続確立、最初の応答までの時間を確認し、名前解決の問題、経路の応答、サイト側の処理時間を切り分けます。
• ✅ Webページは表示できるのに特定のアプリが使えない：直接接続のルール、アプリごとの設定、未対応の通信方式が影響していないか確認します。
• ✅ ノードを切り替えても結果が変わらない：接続ログと外部から見えるIPアドレスを確認し、自動選択、障害時の切り替え、既存接続の再利用を調べます。

DNSの結果も通信経路とあわせて解釈しましょう。DNSリゾルバーの地域と出口の地域が異なるだけで、DNS漏えいとは限りません。DNSサービスが分散配置されている場合もあります。確認すべきなのは、本来クライアントが処理するはずの問い合わせが想定したルールを迂回してローカルネットワークのDNSリゾルバーに送られていないか、そして接続先への通信が意図した出口を通っているかです。

DNS、ルーティング、モードを変更するときは、一度にひとつだけ変更し、同じ条件で測定し直しましょう。複数の設定を一度に変えると、正常に戻ってもどれが有効だったのか分からなくなります。サポートに問い合わせる際は、日時、ノード、クライアントのバージョン、対象ドメイン、エラーの状況を、認証情報を伏せて添付できます。認証情報を含むデータはアップロードしないでください。

測定結果から普段使いの回線を選ぶ

総合ランキングを作るより、用途別に結果を整理するほうが実用的です。仕事や通話では混雑時の応答、変動、切断の有無、大容量ファイルの転送では持続的な速度、動画では再生中にバッファリングが繰り返されないかを確認しましょう。ダウンロードに向く回線が、操作や通話にも最適とは限りません。

最後に、日常使いに適した回線と予備の選択肢を残し、それぞれの用途を明記しましょう。その後使い心地が悪くなったら、以前と同じツール・測定先・記録方法で再確認してから、実際に状況が変わったか判断します。こうすれば、異なる測定ページの最高スコアを追い続けるのではなく、後から検証できる根拠が得られます。