VPN速度測定の方法｜速度比較に使うツール・時間帯・指標

VPNの速度を正確に測るには、見栄えのよい最高値ではなく、端末・ネットワーク・測定先・ルーティングモードを固定し、遅延、ジッター、パケットロス、スループットをそれぞれ確認します。まず通信が測定対象の回線を通っていることを確かめてから比較しましょう。

ここで紹介するのは再現可能な測定方法であり、VPNXMや他サービスの速度ランキングではありません。同じ条件で取得した元データがなければ、特定の回線が速いとは言えず、一度のダウンロード結果から長期的な安定性を判断することもできません。

速度測定の指標：ピーク値以外に見るポイント

「速度が遅い」と感じる原因は、接続確立に時間がかかる、ページのリソース読み込みが遅い、動画の再生にダウンロードが追いつかないなどさまざまです。それぞれボトルネックが異なります。すべてをひとつのダウンロード速度で判断すると、回線選びを誤るおそれがあります。

主な指標の意味と判断時の注意点
指標	主にわかること	読み取る際の注意点
遅延	リクエストの往復にかかる時間。操作への応答に影響	アイドル時の遅延は、帯域を使い切るダウンロード中の遅延とは異なる
ジッター	時間の経過に伴う遅延の変動幅	ツールによって算出方法が異なるため、同じツール内で比較する
パケットロス	測定や通信の途中で正常に届かなかったデータの割合	測定用パケットが制限されている場合、アプリのデータも同じように失われるとは限らない
ダウンロード・アップロードのスループット	継続的にデータを転送する能力	ローカル回線、出口、接続先サーバーのすべてに左右される
接続確立・最初の応答までの時間	アクセスを開始してから応答を受信し始めるまでの過程	DNS、ハンドシェイク、Webサイト側の処理時間にも左右される

動画視聴では安定したスループットと変動の少なさが重要です。リモートワーク、音声通話、操作が多いWebページでは遅延やジッターが重視され、ファイルのアップロードでは上り速度を個別に確認します。ダウンロードが速くてもアップロードが不安定なら、あらゆる用途に適しているとは言えません。

まず単位をそろえましょう。速度測定ツールではMbps、ダウンロードアプリではMB/sがよく使われます。前者はビット単位、後者はバイト単位の速度を示すため、数値をそのまま比較できません。また、一時的な最高値、全体の平均値、アプリが実際に利用できる速度も区別しましょう。

測定ツールで分かること

ブラウザーの速度測定と実際のダウンロード

Speedtestのようなツールはスループットや遅延の確認に便利ですが、自動選択されるサーバーは出口によって変わることがあります。回線を比較する場合は、できるだけ測定サーバーを固定し、サーバー名と場所を記録しましょう。測定先を固定できない場合は、その変化も記録に残し、厳密な順位付けには使わないでください。

特定のコンテンツ配信ネットワークを対象とするFastのような測定は、そのネットワークまでの経路を確認する参考になりますが、すべてのWebサイトを代表するものではありません。ブラウザーの測定では複数の接続を同時に使う場合があり、単一ファイルのダウンロードとは結果が異なることもあります。信頼できる配布元の大きなファイルを継続してダウンロードし、ファイルサーバー側の速度制限も考慮しましょう。

コマンドラインとブラウザーの開発者ツール

pingはICMPによる応答を確認できますが、システムプロキシを経由するとは限りません。Shadowsocks、VMess、Trojan、VLESSなどのプロキシ設定では、クライアントに表示される「遅延」がTCP接続やHTTPリクエストの所要時間を示す場合もあり、同じ測定ではありません。クライアントの説明を確認してから、数値を比較できるか判断しましょう。

ブラウザーの開発者ツールにあるネットワークパネルは、リクエストの待ち時間とリソースのダウンロード時間を分けて確認するのに便利です。コマンドラインのHTTPツールは、同じ接続先へのアクセスを繰り返すのに適しています。コマンドラインを使う前に、ツールが現在のプロキシ方式に対応し、正しく設定されていることを確認してください。ブラウザーがプロキシ経由でも、ターミナルのリクエストが同じ経路を通るとは限りません。

サブスクリプションURLをオンライン速度測定サイトに貼り付けないでください。サブスクリプションURLはクライアントに設定を取得させるためのもので、アクセス情報が含まれる場合があります。第三者の測定サイトに送信するためのURLではありません。

実測の手順：比較条件をそろえる

測定は一連の比較実験として行いましょう。比較する回線やサービスだけを切り替え、それ以外の条件はそろえます。次の手順は、初めて回線を選ぶときにも、急に接続が遅くなったときの確認にも役立ちます。

利用環境を整える。端末、接続方法、場所を固定し、クラウドストレージの同期、システム更新、ほかの大容量通信を一時停止します。Wi-Fiの電波が不安定な場合は、まず接続環境を改善しましょう。そうしないと、ボトルネックが外部回線にあるか判断できません。
直接接続時の基準値を記録する。測定対象のサービスを経由せず、通常アクセスできる固定の接続先にアクセスして、ローカルネットワークの状態を確認します。接続先に直接アクセスできない場合は「測定不可」とし、直接接続時の速度をゼロとして計算に含めないでください。
クライアント設定を固定する。クライアントのバージョン、ノード名、プロトコル、プロキシモード、DNS設定、測定先を記録します。サブスクリプションを読み込んだ後は更新が完了していることを確認し、自動選択をオフにして、測定中に出口が切り替わらないようにします。
実際の通信経路を確認する。接続後、出口アドレスとルールの適用状況を確認します。ネットワーク診断も出口の確認に使えますが、診断ページがプロキシを経由していても、ほかのアプリもプロキシを使っているとは限りません。
交互に切り替えて繰り返し測定する。近い時間帯に測定対象の回線を切り替え、同じ作業を繰り返します。一方の回線をすべて測り終えてから時間を空けてもう一方を測ると、時間帯によるネットワークの違いが結果に混ざるため避けましょう。
実際のアプリでも確認する。普段使うWebサイトを開き、ファイルをアップロードしたり日常的なコンテンツを視聴したりして、途切れ、再接続、失敗などを記録します。最後に普段使うルーティングルールに戻し、使い勝手が変わらないことを確認しましょう。

スループット測定では通信量を消費します。大きなファイルのダウンロードや帯域を使い切る測定の繰り返しは、プランの通信量に含まれる場合があります。事前に残量を確認し、自動で測定を繰り返す設定をオフにしてください。作業に支障をきたしたり、不要な通信量を消費したりしないよう注意しましょう。

時間帯と記録：単発の結果に惑わされない

普段実際にネットを使う時間帯を優先して測定しましょう。たとえば勤務中、夜間に利用が集中する時間帯、比較的空いている時間帯です。空いているときだけでは夜間の安定性はわかりません。反対に混雑時だけ測ると、通常時の性能を低く見積もる可能性があります。

時間帯ごとに同じ手順を使い、日を変えて再確認します。記録を重ねたら、中央値、変動幅、失敗の有無を見て、最良の結果だけを残さないようにしましょう。異常があった場合は元の記録を残して当時の状況を記し、削除するのではなく再測定して確認します。

✅ 端末、OS、クライアント、接続ネットワーク、測定時刻を記録し、後から再現できるようにする。
✅ ノード、プロトコル、接続先サーバー、プロキシモードを記録し、比較対象が変わっていないことを確認する。
✅ アイドル時と継続ダウンロード中の応答を記録し、通常時の遅延と負荷の影響を分けて見る。
✅ 失敗、切断、大きな変動もメモに残し、平均値で利用上の問題が隠れないようにする。
❌ 異なるツール、接続先、単位の結果をそのまま並べて速度ランキングにしない。

記録は一般的な表計算ソフトで十分です。複雑なダッシュボードを用意する必要はありません。個人で回線を選ぶなら、「どの条件で、どんな現象が繰り返し起きたか」を説明できる記録のほうが、背景のない測定画面のスクリーンショットより役立ちます。

接続経路とプロトコル：名称だけでは速度は分からない

直接接続、中継、IEPL専線は、それぞれ異なる経路構成を指します。直接接続は通常、ローカルネットワークから海外サービスの入口へ直接つなぐ方式です。中継では中間の接続拠点や転送ノードを経由します。IEPLはイーサネット専用線による伝送方式ですが、実際のサービスでは一部の区間だけで使われることもあり、端末から接続先サイトまでの全経路が専用線とは限りません。

中継によって経路が改善することもあれば、遠回りになることもあります。専用線を使うと公衆網の変動を抑えられる区間があっても、最終的な使い勝手はローカル回線、サービスの負荷、出口、接続先サイトに左右されます。そのため、回線の種別は記録項目として扱い、速度の結論には使わないでください。

プロトコルだけで速度が決まるわけでもありません。Shadowsocks、VMess、Trojan、VLESSの実際の性能は、伝送設定やクライアントの実装によって変わります。Hysteria2とTUICはQUICベースの伝送を使うため、UDPで通信できる環境も必要です。あるネットワークで良好なプロトコルが、別のネットワークでも同じように動くとは限りません。

複数のプラットフォームを比べるときは、プロキシの適用範囲にも注意が必要です。Windows、macOS、Linuxのシステムプロキシは、プロキシ設定に従うアプリにしか影響しない場合があります。iOSやAndroidのVPN設定にも、ルーティングや対象アプリの制限があることがあります。TUNモードは通常、より広い範囲をカバーしますが、ルールの確認は必要です。接続アイコンだけで、すべての通信の経路を判断しないでください。

トラブルの切り分け：出口・DNS・アプリを確認

速度測定は速いのに、Webページの表示が遅い

まず、どの段階で遅いのか確認します。ドメインの名前解決、接続時のハンドシェイク、サイトの応答開始後のダウンロードのどこで時間がかかっているでしょうか。DNSに問題があるとページの読み込みが始まるまで時間がかかる一方、大きなファイルの速度測定ではすでに接続が確立しているため、速く見えることがあります。ブラウザーのキャッシュや拡張機能、Webサイト側の負荷も似た症状の原因になります。

クライアントのDNS設定とブラウザーの暗号化DNS設定が、想定どおりか確認してください。DNSリークは、DNSリクエストが想定したトンネル以外の経路を通ることを指し、「名前解決が遅い」という意味ではありません。ブラウザーの暗号化DNSが別の経路を使う場合もあるため、出口アドレスだけを見てもDNS通信の経路は確認できません。

何もしていないときは問題ないのに、ダウンロード中は操作の反応が明らかに遅くなる

回線のキュー、上り帯域の使い切り、ローカルルーターの負荷などが原因として考えられます。バックグラウンドのアップロードを一時停止し、ダウンロード中の遅延を確認してから、同じ端末で別の接続ネットワークを使って再測定します。回線を切り替えても同じ症状が続くなら、サブスクリプションを何度も更新するのではなく、まずローカルネットワークを調べましょう。

特定のアプリだけ遅く、ほかのアプリは正常

そのアプリに想定したルールが適用されているか、UDPを使っているか、接続先サービスが独自に速度制限を設けているかを確認します。適用範囲が明確なモードに一時的に切り替えると、原因の切り分けに役立つことがありますが、変更内容を記録し、確認後は元に戻してください。公開の場で相談する際は、サブスクリプションURL、アクセストークン、アカウント情報を隠しましょう。ログは原因調査に必要な部分だけ共有してください。

まとめ：ピーク値ではなく用途で選ぶ

信頼できるVPNの速度比較には、測定条件、繰り返した結果、適した用途の明記が欠かせません。ある回線で継続ダウンロードが速くても、よく使うアプリの応答が不安定なら、最高値だけを理由に優先する必要はありません。反対に、スループットが最速でなくても操作が安定していれば、日常の作業に向いていることがあります。

確認の順序：経路が正しい → 条件をそろえる → 複数回確認する → アプリで試す。

ダウンロードの最高速度からわかるのは、特定の時点で特定の接続先へデータを転送する能力だけです。長期的に使うなら、遅延の変動、失敗の記録、普段の作業での使い勝手も確認しましょう。こうした背景がないデータだけでは、特定のサービスが長期的に速いとは証明できません。

VPNXMを評価する場合も、同じ方法で測定し、カバー範囲を速度の保証と取り違えないようにしましょう。VPNXMは100+か国 / 250+回線に対応し、同時接続台数に制限はありません。実際に選ぶ際は、利用するネットワークと目的も考慮してください。料金プランと通信量のルールはプランページで確認できます。測定前に自分の利用量に合ったプランか確かめましょう。