VPN速度テストの実測方法：自分で測って宣伝値に惑わされない

VPN速度テストは、測定サイトに表示されるダウンロード速度だけで判断できません。実際の体感は、利用中の回線、無線環境、出口の混雑、経路、プロトコルの実装、クライアント設定、接続先のサービスにも左右されます。一度だけ測定し、その結果を特定の回線の性能だと判断しても、信頼できる結論にはなりにくいでしょう。より有効なのは、環境を固定し、基準値を残し、時間帯を分けて比較することです。スループットは遅延・ジッター・パケットロスと合わせて評価します。

この方法は宣伝ページや専門的な実験室を必要としません。重要なのは目立つ最大値を追うことではなく、ページがすぐ応答するか、動画が安定して再生されるか、音声が途切れないか、ファイル転送が継続するか、そして問題の原因がローカルネットワーク、クライアント、ノード、接続先サービスのどこにあるかを切り分けることです。

まず速度テストの目的を決めてから測定する

「速いかどうか」だけでは、十分に具体的な問いとはいえません。大容量ファイルのダウンロード、ウェブページの表示、動画視聴、音声会議、AIツールの利用では、求められるネットワーク性能が異なります。ファイルのダウンロードでは継続的なスループットが重要です。一方、ウェブやインタラクティブなツールでは最初の応答速度、音声やリモート操作ではジッターとパケットロスがより重要になります。ダウンロード速度が高いノードでも、対話的な用途に適しているとは限りません。

そのため、測定前に用途を書き出しておきましょう。動画のバッファリングが主な問題なら、連続再生とスループットの安定性を優先します。ウェブページの表示が遅いなら、まず遅延、DNS、ルーティングを確認します。音声が途切れるなら、ダウンロード速度だけを見るのではなく、ジッターとパケットロスを重点的に確認してください。

速度テストのツールの選び方：ブラウザの結果だけで判断しない

ブラウザ上の速度テストは手軽な比較に向いていますが、ブラウザの実行環境、スクリプトの処理、測定サービス側のサーバー選択を同時に経由します。測定サイトが異なれば接続先サーバーも異なり、ルートが大きく変わることもあります。結果が一致しないとき、単純にどちらかのツールが間違っていると決めつけるのではなく、同じ経路を測っているかを確認しましょう。

より確実なのは、ブラウザのツールで全体のスループットを確認し、システムのネットワークツールで遅延とパケットロスを調べ、最後に実際のサービスで体感を検証する組み合わせです。実際のサービスとして、キャッシュされていないページの読み込み、普段見るコンテンツの再生、公開テストファイルのダウンロード、日常的なオンライン作業などを使えます。ツールの結果はネットワークを説明し、実サービスでの検証は指標が利用に影響しているかを確認します。

• ✅ 測定サービスと測定ノードを固定し、各回で別の地域へ自動切り替えされないようにする。
• ✅ 1回の比較では同じクライアント、同じプロトコル、同じ回線を使う。
• ✅ まず未接続時の基準値を測り、その後に接続後の回線を測る。
• ✅ クラウド同期、システム更新、動画再生、その他のバックグラウンド転送を一時停止する。
• ✅ 測定時間帯、接続方法、回線名、ルーティングモードを記録する。
• ❌ 1回だけのピーク値を、その回線の固定性能として扱わない。
• ❌ 異なる端末や異なる無線位置で得た結果を、そのまま横並びで比較しない。

システム標準の遅延測定ツールにも限界があります。接続先によっては測定リクエストを制限したり無視したりする一方、通常のウェブ接続は利用できる場合があります。逆に、測定への応答が安定していても、実際のサービスが必ず快適とは限りません。測定対象には、回線の入口、普段使うウェブサイト、安定した公開対象を含め、入口までの経路とその先のルートを切り分けるのが理想です。

再現性のあるVPN速度テスト手順

再現性を高める鍵は、変数を管理することです。各回で変える要素は1つだけにします。たとえば回線だけ、プロトコルだけ、または接続方法だけを変更します。ノード、クライアント、プロトコルを同時に変えると、結果が改善しても何が影響したのか判断できません。

1. ローカル環境を整える。できるだけ安定した有線ネットワークを使います。無線しか使えない場合は端末の位置を固定し、電波状態に大きな変化がないことを確認してください。帯域を消費するバックグラウンド処理も停止します。
2. 未接続時の基準値を記録する。プロキシ接続を有効にしない状態で、ページの応答、遅延、ジッター、パケットロス、継続スループットを確認します。基準値に異常がある場合は、まずルーター、無線干渉、通信事業者側の経路を確認してください。
3. クライアントとモードを固定する。グローバルプロキシとルールベースのルーティングのどちらを使うか決め、測定トラフィックが選択した回線を実際に通っていることを確認します。異なるモードを混在させると、結果を比較できなくなります。
4. 対象回線を固定する。地域、回線タイプ、プロトコルを記録します。測定中は自動選択や自動切り替えを有効にせず、クライアントがバックグラウンドで出口を変更しないようにします。
5. ツールで測定する。応答、安定性、スループットの順に確認し、測定中は高トラフィックの作業を別に開始しません。
6. 実際のサービスで検証する。普段使うウェブページを開き、実際のコンテンツを再生するか作業を行い、バッファリング、タイムアウト、再接続、明らかな遅延が起きないか記録します。
7. 変更する変数は1つだけにする。ほかの条件を変えずに別の回線またはプロトコルへ切り替え、同じ手順を繰り返します。
8. 時間帯を分けて再測定する。混雑時と深夜の結果を別々に保存し、すべての記録を1つの平均的な印象にまとめず、変動の傾向を比較します。

記録には複雑なソフトウェアは必要ありません。テキストファイルや表計算シートで十分です。日付、時間帯、接続方法、クライアント、プロキシモード、回線地域、回線タイプ、プロトコル、DNS設定、測定対象、実際の利用感を保存するとよいでしょう。クライアントで接続ログを確認できる場合は、再接続、ハンドシェイク失敗、ルール未適用の有無も記録できます。ただしログにはサブスクリプションURLや認証情報が含まれる場合があるため、共有前に機密情報を削除してください。

テスト環境：固定端末 / 固定接続方法
プロキシモード：グローバルまたはルールベースのルーティング
回線情報：地域 / タイプ / プロトコル
測定時間帯：混雑時または深夜
基準値：応答 / ジッター / パケットロス / スループット
接続状態：応答 / ジッター / パケットロス / スループット
実サービスでの検証：ウェブ / 動画 / 音声 / ファイル / AIツール
異常記録：タイムアウト / 再接続 / DNS / ルール適用

テンプレートでは、あらかじめ用意した成績ではなく状態を記録します。測定していない数字を記録に書き込まないためです。実際の測定では、ツールに表示された結果を単位付きでそのまま保存してください。特にビットとバイトは同じ単位ではありません。ブラウザの測定ページとダウンロードツールでは表示単位が異なる場合があるため、数字の大きさだけで比較してはいけません。

遅延・ジッター・パケットロス・スループットの読み方

遅延：往復にかかる待ち時間

遅延は、端末から接続先へデータを送り、戻ってくるまでにかかる時間です。物理的な距離、通信事業者間の接続、迂回経路、ノードの負荷、プロトコルのハンドシェイクが遅延に影響します。ウェブ操作、音声通話、リモート操作への影響は大きいものの、遅延が小さいからといってダウンロードが速いとは限りません。スループットは帯域幅や混雑制御にも左右されるためです。

遅延を比較するときは、同じ対象を測定します。日本の回線で日本の対象を測る場合と、欧州の回線で欧州の対象を測る場合では、異なる経路を評価しています。回線そのものを比較するなら対象を固定し、実際の用途を比較するなら普段アクセスするサービスを選びます。

ジッター：遅延が安定しているか

ジッターは、複数回のデータ転送にかかる時間の差が安定しているかを示します。平均遅延が正常でも、応答が速くなったり遅くなったりすると、音声が途切れたりリモート操作の反応が不均一になったりします。無線干渉、キューの混雑、アップロード処理による帯域占有、不安定な中継経路などがジッターの原因になります。

ジッターを判断するときは、集計値だけでなく、サンプルに一時的な大きな跳ね上がりがないかも確認します。継続的に安定している場合と、頻繁にピークが出る場合では体感が異なり、最終的な平均値が近くても同じとはいえません。

パケットロス：データが正常に届いているか

パケットロスが起きると、一部のデータを再送する必要が生じたり、リアルタイムサービスで欠落が発生したりします。ファイルのダウンロードでは通常、再送によって完全性を保ちますが、速度は低下します。音声やリアルタイム操作では再送を無限に待てないため、音割れ、途切れ、操作の切断として現れやすくなります。

測定リクエストが一時的に応答しなかっただけでは、実際のサービス経路でパケットロスが起きているとは限りません。対象が測定トラフィックを制限している可能性があるためです。ウェブリクエスト、接続ログ、複数の対象を組み合わせて判断してください。1つの対象だけに異常があるなら、接続先サービスまたは上流側に問題がある可能性があります。複数の安定した対象で同時に異常が出る場合は、ローカルネットワークと回線を確認します。

スループット：継続的に転送できる有効データ量

スループットは、回線に表示された公称帯域幅をそのまま再現したものではありません。測定サービスの容量、端末性能、暗号化のオーバーヘッド、転送プロトコル、接続先までの距離、並列数などが結果に影響します。短時間だけ速度が上がってすぐ低下する回線より、全体を通して安定する回線のほうが、大容量ファイルや動画には適しています。

アップロードも確認する価値があります。クラウド同期、ビデオ会議、添付ファイルの送信はいずれもアップロード経路に依存します。ほかの処理でアップロード帯域が埋まると、ダウンロードやページの応答もキュー待ちの影響を受け、「帯域は残っているのに操作が遅い」状態になることがあります。

回線とプロトコルで結果が変わる理由

直結、中継、IEPL専線は、それぞれ異なるネットワーク構成を指します。直結は通常、端末からノードへ直接アクセスするため、経路は利用中の通信事業者や国際相互接続の状態に左右されます。中継ではいったん中継入口に入り、そこから出口ノードへ転送することで一部の経路を調整できますが、経由するリンクが増える分、処理が追加されます。IEPL専線は比較的独立した国際伝送経路を重視しますが、実際の体感は入口の接続、出口の品質、接続先サービスにも左右されるため、回線名だけで判断できません。

これらの回線を測定するときは、出口地域と利用するサービスをそろえます。直結と中継で異なる出口都市を使うと、回線構成だけでなく地理的な位置の違いも結果に含まれ、中継の効果だけを判断できません。出口地域をできるだけ固定し、回線タイプだけを変更するのが適切です。

プロトコルも転送特性を変えます。Shadowsocks は比較的シンプルな実装ですが、暗号化方式、クライアントのコア、サーバー設定によって結果が異なります。VMess と VLESS はルーティングや複数の転送方式に対応するクライアントでよく使われますが、名前だけで速度を判断することはできません。Trojan は通常の暗号化接続に近い通信形態を取りますが、性能はトランスポート層と実装に左右されます。Hysteria2 と TUIC は複雑なネットワーク状況に対応しやすい転送設計を採用しており、高遅延または変動の大きい経路で異なる輻輳制御を示す可能性があります。ただし、クライアント、サーバー、ネットワーク側の対応状況にも強く依存します。

プロトコルを比較する際は、同じ地域、近い経路、同じ端末を使います。現在のネットワークで特定のプロトコルがよく動いても、それは今回の測定条件に適していたことを示すだけで、すべてのネットワークで速いとはいえません。学校、家庭、会社、公共Wi-Fiでは制限が異なるため、結論は測定環境の範囲内に限定してください。

混雑時と深夜を比較し、変動の原因を確認する

混雑時の測定は、共有ネットワークが混み合う時間帯の状態を示します。深夜の測定は、混雑が少ない環境に近い状態を示します。どちらも必要ですが、目的は異なります。深夜だけ測ると、普段の利用時間帯の混雑を見落とす可能性があります。混雑時だけ測ると、通信事業者や共有ネットワークの混雑をすべてノードの問題だと判断するおそれがあります。

未接続時の基準値も混雑時に明らかに悪化しているなら、ローカルの接続環境または通信事業者の経路がすでに影響を受けています。基準値が安定しているのに、特定の回線だけが混雑時にジッターやスループット低下を示すなら、回線入口、相互接続、中継、出口に原因がある可能性が高くなります。複数の回線で似た異常が同時に起きる場合は、端末、ルーター、接続環境をさらに確認してください。

比較では瞬間的な結果を完全に一致させようとしないでください。インターネットの経路は動的に変化するため、繰り返し現れる傾向を見るのが現実的です。普段の時間帯に安定する回線、再接続が少ないプロトコル、測定トラフィックを誤って直結に送らないルーティング方式を確認します。傾向は選択に役立ちますが、単一の数値はその時点の状態を示すだけです。

• ✅ 基準値と回線の測定を近い時間帯に行う。
• ✅ 混雑時は安定性、バッファリング、再接続の状況を記録する。
• ✅ 深夜は混雑が少ない環境での回線上限と基本遅延を確認する。
• ✅ 各回で変更するのは回線またはプロトコルのどちらか1項目だけにする。
• ❌ 異なる日付、端末、接続ネットワークの結果を直接混在させない。
• ❌ 1回の異常だけで記録を削除しない。異常そのものが切り分けの手がかりになります。

結果に異常があるときは、ローカル環境、DNS、ルーティング、出口の順に切り分ける

速度テストの異常は、ノードの問題だと誤認されがちです。効率的に調べるには、端末に近い箇所から順番に確認します。まず接続を切ってローカルネットワークを確認し、次にクライアントが正常に接続を確立しているかを確認します。その後、DNS、ルーティングルール、出口を確認し、最後に回線とプロトコルを比較します。

ローカルネットワークと端末

無線信号の混雑、ルーターのキュー滞留、端末の省電力設定、バックグラウンド同期、セキュリティソフトのネットワークスキャンは、測定結果を変える可能性があります。複数の回線が同時に遅くなった場合は、まず安定した接続方法に変え、バックグラウンド転送を停止してください。端末の性能が不足していると、暗号化や仮想NICの処理がボトルネックになることもあります。特に複数の処理を同時に実行している場合は注意が必要です。

DNSリークと名前解決の経路

DNSリークとは通常、ドメイン名の問い合わせが想定したプロキシや指定の名前解決経路を通っていない状態を指します。プライバシーだけでなく、アクセス速度やコンテンツ配信にも影響します。ウェブサイトは名前解決元に応じて異なる配信ノードを返すことがあります。名前解決がローカルネットワークを通り、サービスの通信だけが遠隔の出口を通ると、出口から見て適切でない距離のノードが選ばれる可能性があります。

確認時は、クライアントのDNSモード、システムに残っているほかの名前解決設定、ブラウザ独自の暗号化DNSの有効化状況を調べます。ブラウザとクライアントがそれぞれ名前解決を処理している場合、アプリごとに測定結果が異なる可能性があります。変更後は接続を再確立し、ブラウザキャッシュが変化を隠さないようにしてください。

ルーティングルールが適用されているか

ルールベースのルーティングでは、ドメイン、アドレス、ルールセットに応じて直結とプロキシを切り替えます。速度テストサイトが直結に設定されていると、表示されるのはローカル回線の結果であり、選択した回線の結果ではありません。逆に、本来直結すべきローカルサービスを遠隔の出口へ送ると、不要な迂回が発生します。

まず一時的にグローバルプロキシへ切り替えて回線を比較し、その後ルールベースのルーティングに戻して普段の利用を確認します。これにより「回線性能」と「ルール設定」を分けて考えられます。ルールを確認するときは、メインページのドメイン、速度テストのデータ用ドメイン、アプリが利用するほかの接続先も確認してください。これらが同じアドレスを使うとは限りません。

出口地域と接続先サービス

接続後は、出口地域が選択した回線と一致しているか確認します。一致しない場合は、クライアントが通信を引き受けていない、システムプロキシが有効になっていない、ルールによって直結になっている、サブスクリプション情報が更新されていない、といった可能性があります。出口が正しいのに特定のウェブサイトだけ遅い場合は、別の安定した対象で比較し、接続先サービス自体の混雑を回線の結論に含めないようにします。

異なるプラットフォームで速度を実測するときの注意点

Windows と macOS のクライアントでは、システムプロキシまたは仮想NICモードを使う場合があります。システムプロキシは主にプロキシ設定に従うアプリに影響し、仮想NICモードはより広い範囲の通信を引き受けることが一般的です。測定前に現在のモードを確認してください。ブラウザは回線を通っているのにコマンドラインツールは直結している、といった状態では、2つの結果を関連付けて解釈できません。

iOS と Android は通常、システムが提供するVPNインターフェースを介して接続します。モバイルOSの省電力設定、バックグラウンド制限、ネットワーク切り替えは、長時間の測定に影響します。測定中はアプリの接続状態を安定させ、無線ネットワークとモバイルネットワークを切り替えないでください。また、画面ロック後のバックグラウンド動作と、前面で継続して行った測定を同じ記録グループに混在させないようにします。

サブスクリプションURLは、ノードと設定をクライアントへ渡す入口にすぎず、最終的な性能を決めるものではありません。サブスクリプションを読み込むと、クライアントはサーバー、プロトコル、ルーティング情報を解析します。フィールド、転送方式、DNS設定への対応はクライアントごとに異なる場合があります。読み込み後にノードが不足していたり、プロトコルが利用できなかったりする場合は、不完全な設定で測定する前にクライアントの互換性を確認してください。

デスクトップではさまざまなシステムツールを使い、詳細なログを確認しやすい一方、モバイル端末は普段の外出先ネットワークに近い環境で測定できます。どちらの結果にも価値がありますが、別々に整理してください。同じ回線を異なるプラットフォームで比較する場合は、端末をできるだけ同じローカルネットワークに接続し、クライアント名、コア、プロキシモードを明確に記録します。

速度テストの結論を回線選びに生かす方法

記録が終わっても、すべての指標を1つの総合点にまとめる必要はありません。用途ごとに簡単な順位を作れます。ウェブやAIツールでは、応答が安定し、ルールが正しく適用される回線を優先します。動画では、継続スループットが安定し、混雑時の変動が小さい回線を選びます。音声やリモート操作では、ジッターが小さくパケットロスが少ない回線を重視します。ファイル処理では、長時間の転送が安定するかを確認します。

同じ地域でも、用途ごとに異なる回線を残しておけます。低遅延の回線は対話的な用途に向いていても、混雑時の継続スループットが最良とは限りません。専線や中継回線は経路をより管理しやすい一方、ローカルの入口と接続先サービスを含めた検証が必要です。自動選択は普段のすばやい接続に便利ですが、厳密に比較するときは一時的に無効にし、測定中のノード切り替えを防ぎます。

表示された帯域幅と実測結果が一致しない場合は、まず単位、測定対象、出口地域、ローカルの基準値を確認し、その後にプロトコル、DNS、ルーティングを調べます。宣伝値は通常、特定の回線やポートの性能を示すものであり、すべての地域、通信事業者、接続先で同じ体験が得られることを意味しません。環境条件を明記するほうが、条件から切り離された数字について議論するより有益です。