VPN速度測定はどれが正確？2026年版、自分で実測する方法とツール

VPNの速度測定で正確なのは？答えは、特定の測定サイトではなく、繰り返し実行できる測定方法です。一度だけ高いダウンロード速度が出ても、その時点で端末から測定ノードまでの経路が良好だったことしか示しません。動画再生、ファイル転送、ウェブ閲覧、AIツールの長時間接続まで安定すると直接証明するものではありません。実用的な結論を得るには、まず自宅ネットワークの基準値を測り、回線、プロトコル、端末、測定ノードを固定して、普段使う時間帯に再測定します。

速度測定で見落とされやすいのは、何を測っているのかが明確でないことです。ブラウザの測定結果は、ブラウザの通信がプロキシを経由した場合の値です。システム全体のプロキシなら、より多くのアプリが対象になる可能性があります。一方、クライアントのルールによっては、測定サイトへ直接接続されることもあります。3つのケースでは表示される数字が正常でも、測っている経路は同じではありません。開始前に、通信が実際に対象回線を通っているか確認することが、測定サイトを何度も変えるより重要です。

一度の速度測定で誤った結論になりやすい理由

端末からリクエストを送信して測定ノードがデータを返すまでに、家庭内の無線ネットワーク、接続先の通信事業者、プロキシの入口、中継経路、出口ノード、測定サービス側のネットワークを通過します。どこか一箇所でも混雑すれば、最終結果は低下します。反対に、測定ノードが出口と同じデータセンターの近くにあると、実際のアクセス経路より大幅に良い結果が出ることもあります。

測定サイトは通常、近そうな、または応答の速いノードを自動選択します。これは自宅のブロードバンドが正常か確認するには便利ですが、国際経路の評価には必ずしも適していません。出口が日本にある場合、自動選択されたノードも日本国内にある可能性があります。一方、実際に利用するコンテンツサービスは別の地域にあるかもしれません。この場合に測っているのは、出口から近隣ノードまでの性能であり、出口から目的のサービスまでの全経路ではありません。

端末の状態も結果を変えます。不安定な無線信号、バックグラウンド同期、ブラウザ拡張機能、省電力設定、クライアントの暗号化処理がボトルネックになることがあります。モバイル端末とデスクトップ端末では、処理性能、ネットワークインターフェース、システムプロキシの仕組みが異なります。同じサブスクリプションを読み込み、同じノードを選んでも、結果が完全に一致するとは限りません。

速度測定ツールの選び方：問題ごとに使い分ける

「この回線は使いやすいか」という問いに、1つのツールだけで完全に答えることはできません。より確実なのは、ツールごとに役割を分ける方法です。ブラウザの測定でスループットを確認し、継続的なリクエストで遅延の変化を観察し、実際のファイルや動画で長時間転送を検証し、クライアントのログで通信経路を確認します。ツールは互いに代替するものではなく、結果を照合するために使います。

ブラウザの速度測定は簡易チェックに向いています。ただし事前に、ネットワークリクエストを書き換える拡張機能を一時停止し、ブラウザがクライアントのプロキシ設定に従っているか確認してください。クライアントが接続記録に対応しているなら、測定開始時に該当する接続が出ているか確認します。記録がなければ、ルールで測定ドメインが直接接続になっているか、ブラウザがシステムプロキシを回避している可能性があります。

実ファイルで試す場合は、提供元が安定していて、一時的な速度制限をかけないコンテンツを選び、回線を比較するときは同じ提供元を使います。異なるサイトのダウンロード速度を直接比較してはいけません。サーバー負荷、キャッシュ状態、復路のネットワークが異なるためです。動画用途では、短時間のピーク値だけでなく、画質が頻繁に下がるか、バッファリングが起きるかを確認するほうが実際の使用感に近い判断になります。

本当に確認すべき3つの指標

スループット：最高ダウンロード速度だけを見ない

スループットは、単位時間あたりに転送できるデータ量を示し、通常はダウンロードとアップロードに分けて考えます。ダウンロードは動画、ウェブリソース、ファイル取得に影響し、アップロードはクラウド同期、添付ファイルの送信、リモート共同作業に影響します。判断では、メーターに一瞬表示された最高値ではなく、測定中に安定して出ていた値を確認します。ピークが高くてもその後ずっと低下するなら、輻輳制御、ノード負荷、経路品質が転送を制限している可能性があります。

遅延とジッター：操作感を左右する要素

遅延はリクエストの往復にかかる時間で、ジッターは連続したリクエスト間で遅延が変化する度合いです。ウェブのクリック操作、ターミナル操作、音声通信、AIとの会話はいずれもこの2つの影響を受けます。平均遅延が特別に低くなくても、変化が穏やかな回線のほうが、時々速い一方で時々止まる回線より実際には安定することがあります。長時間接続では、突然の遅延スパイクがアプリの再試行を引き起こす場合もあります。

パケットロス：経路が無理なく維持されているかを見る指標

パケットロスが起きると再送が発生し、高遅延の経路では待ち時間も大きくなります。測定ページは複数の接続を使って総スループットを保てる一方、個々の接続で頻繁に再送が起きている問題を隠すことがあります。実際には、ウェブリソースの読み込みが時々止まる、動画の画質が何度も変わる、リモートセッションが突然固まる、明確な切断がないのにクライアントが再接続するといった症状として現れます。

• ✅ スループットが安定し、連続した区間で大きく落ち込んでいない。
• ✅ 遅延の変化が穏やかで、実際の操作に周期的な停止がない。
• ✅ 長時間接続を維持でき、クライアントが何度も再接続していない。
• ❌ 最高ダウンロード速度だけを記録し、回線、時間帯、測定ノードを記録していない。
• ❌ 一度低い値が出ただけでプロトコルを変更し、比較条件を増やしてしまう。

30分でできる実測手順

以下の手順は実験室レベルの精度を目指すものではなく、一般ユーザーが再現可能で、回線選びに役立つ結果を得るためのものです。実行時は一度に1つの条件だけを変更してください。回線を切り替えたら接続が安定するまで待ってから次のラウンドを始めます。クライアント、プロトコル、測定ノードを同時に変えると、何が変化の原因か判断できません。

1. ローカルの基準値を記録する。プロキシを切断し、同じ端末、同じ接続方法でブラウザの速度測定を行い、普段使うウェブサイトも開いてみます。基準値は、ボトルネックがすでにローカルネットワークにあるか判断するために使います。
2. 測定環境を固定する。バックグラウンドのダウンロードとクラウド同期を停止し、無線または有線の接続方法を固定します。クライアント名、回線名、プロトコル、プロキシモードを記録してください。
3. プロキシ経路を確認する。対象回線に接続し、クライアントの接続状態とログを確認して、測定ページのリクエストが選択したノードを通っていることを確かめます。必要に応じて、測定中だけグローバルプロキシを使い、終了後に元のルールへ戻します。
4. 短時間のスクリーニングを行う。同じ測定ノードでダウンロード、アップロード、遅延を確認します。結果が異常でも、いきなりすべての設定を変更せず、まず現在の測定を繰り返してください。
5. 継続的なリクエストを観察する。安定した対象に対して遅延を継続測定し、周期的なスパイク、タイムアウト、大きな変動がないか確認します。1つの対象が応答しない場合は、別の安定した対象に変えて照合してください。
6. 実際の用途を試す。よく使うウェブページを開き、普段見るコンテンツを再生するか、ファイルを一定時間転送します。バッファリング、中断、速度低下、再接続の発生を記録してください。
7. 同じ形式で記録を残す。日付、時間帯、回線、プロトコル、測定ノード、主観的な使用感を書き留めます。再測定でも同じ項目を使うことで、変化の傾向を把握できます。

基準値の測定は重要です。プロキシを切断した時点でローカルネットワークに大きなジッターや継続的なパケットロスがあるなら、どの国際回線に接続しても安定した結果は得にくくなります。その場合は、無線アクセスポイントに近づく、バックグラウンド処理を停止する、より安定した接続方法に切り替えるなどの対処を先に行います。プロキシで端末からローカルネットワークまでの物理的な経路の問題を解決することはできません。

夜間の再測定が必要な理由

日中に快適でも、普段使う時間帯も同じとは限りません。接続ネットワーク、ネットワーク間接続、中継入口、出口は、混雑する時間帯により大きな負荷を受けることがあります。多くのユーザーが気にするのは夜間の動画、ダウンロード、リモート操作です。そのため空いている時間帯だけ測ると、回線性能を体系的に過大評価してしまいます。

再測定では、速度が下がったかだけでなく、どこで低下したかも確認します。ローカルの基準値も同時に悪化しているなら、主な原因は接続ネットワークかもしれません。基準値が安定しているのに、プロキシ回線のジッター、パケットロス、再接続が明らかに増えているなら、入口、中継、出口の混雑が原因である可能性が高くなります。同じ測定ノードと同じプロトコルを使うことで、誤った原因判定を減らせます。

夜間の混雑時は、回線の切り替え動作も表面化しやすくなります。クライアントによってはノード障害時に自動で切り替えるため、ページで測定を続けられても、測定対象は変わっている可能性があります。再測定中は現在のノード名と接続記録を確認してください。自動選択でノードが変わる場合、回線を比較するときだけ手動固定にし、完了後に普段の設定へ戻すとよいでしょう。

信頼できる回線とは、ある一度の測定で最高値を出す回線ではなく、実際に使う時間帯でも予測しやすい遅延、継続的な接続、十分なスループットを保てる回線です。

プロトコル、直接接続、中継が結果に与える影響

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、カプセル化の方式、伝送メカニズム、クライアント実装がそれぞれ異なります。ただし、プロトコル名だけで速度の優劣を決めることはできません。最終的な性能は、サーバー設定、経路品質、輻輳制御、端末性能、ネットワークがTCP・UDP通信を処理する方法にも左右されます。

Shadowsocksは比較的シンプルな構成で、VMessとVLESSは異なる伝送方式と組み合わせて運用されることが多く、Trojanは一般的な暗号化通信の形で接続を運ぶことが多いプロトコルです。Hysteria2とTUICはUDPベースの伝送を重視し、遅延やパケットロスがあるネットワークでは従来のTCP経路とは異なる挙動を示す可能性があります。ただし、接続ネットワークがUDPに適していない場合、ジッター、ハンドシェイク失敗、フォールバックが起きることもあります。プロトコルを比較するときは、ノードと用途を固定し、名称だけで結論を決めないでください。

直接接続の回線は通常、ユーザーの接続ネットワークから出口へ直接向かうため経路がシンプルですが、ネットワーク間接続や国際経路の変動による影響を受けやすくなります。中継回線は近い入口に接続してから、通信事業者の最適化された経路などを経由して出口へ到達するため、入口とネットワーク間の経路を管理しやすい傾向があります。IEPL専用線は企業間接続向けの専用伝送という概念であり、通常の公衆網中継と同一視してはいけません。実際に該当するリソースを利用しているかは、サービス提供元の回線説明を確認してください。

これらの回線タイプを測定するときは、遅延だけを比べてはいけません。中継経路は区間が1つ増えるため、基礎遅延が最小とは限りませんが、混雑時にはより安定することがあります。直接接続は経路が短く見えても、ネットワーク間の混雑を受ける可能性があります。日常利用では、たまに出る最低遅延より、安定してジッターの少ない状態のほうが価値があります。

ルーティング、DNS、クライアントの違いが速度測定に与える影響

ルーティングルールは、どのリクエストをプロキシ経由にし、どれを直接接続するかを決めます。速度測定のドメインが直接接続ルールに一致すれば、表示されるのはローカルブロードバンドの結果です。ページ自体はプロキシ経由でも、測定リソースのドメインだけが直接接続になると、経路が混在することもあります。確認するにはクライアントの接続ログを見て、測定中だけ明確なプロキシモードを使います。診断後は、普段の利用に適したルーティング設定へ戻してください。

DNSの名前解決も、測定ノードの選択やコンテンツ配信を変えることがあります。名前解決のリクエストがローカルネットワークから送信され、実際の接続は遠隔の出口から行われると、サービスが名前解決の場所に基づいて適切でないノードを返す可能性があります。DNSリークテストは、名前解決のリクエストが想定した経路で送信されているかを確認するもので、速度測定と同じではありません。経路に異常がある場合は、出口だけを変えるのではなく、クライアントのDNSモード、システムプロキシ対応、ルーティングルールを確認してください。

WindowsとmacOSのクライアントは通常、システムプロキシを引き継げますが、独自のネットワーク設定を使うアプリもあります。AndroidとiOSのクライアントは、システムが提供するVPNインターフェースで通信を処理することが多く、省電力設定、バックグラウンド制限、アプリごとのプロキシ機能が測定に影響します。TUNモード、システムプロキシ、LANアクセス、DNSの引き継ぎ方もプラットフォームによって異なります。そのため、パソコンの結果だけでモバイル端末の確認を代用することはできません。

サブスクリプションリンクは、ノードと設定の更新情報をクライアントへ渡す入口にすぎません。読み込み後は、選択したノード、プロトコルの対応状況、更新状態を確認してください。クライアントがサブスクリプション内のプロトコルに対応していない場合、ノードを読み飛ばしたり、利用不可と表示したり、接続を確立できないことがあります。測定前にサブスクリプションを更新し、クライアントが実際に選択している設定を確認して、古いノードや誤ったプロトコルを比較しないようにします。

結果を整理して最終判断する方法

速度測定の記録は複雑にする必要はありません。端末、接続方法、時間帯、回線、プロトコル、プロキシモード、測定ノード、スループット、遅延の変化、パケットロスの有無、実際のアプリでの使用感を毎回残せば十分です。重要なのは見栄えのよいグラフを作ることではなく、次回も同じ条件で再現できる記録にすることです。

ブラウザの速度測定では普通の結果でも、実際のウェブ閲覧、動画、長時間接続が安定しているなら、日常用として適した回線かもしれません。反対に、短時間のスループットが高くても、名前解決の異常、遅延スパイク、接続中断が頻発するなら優先すべきではありません。用途に応じて選択肢を分けてもよいでしょう。操作性を重視するなら安定した低遅延、継続的な転送なら安定したスループットを優先します。

• ✅ プロキシ切断時のローカルネットワーク基準値を記録した。
• ✅ 速度測定のリクエストが直接接続ルールではなく、対象回線を通っていることを確認した。
• ✅ 実際に利用する時間帯に再測定を行った。
• ✅ 実際のアプリで速度測定の結論を検証した。
• ❌ 測定ノードを固定せず、2回の結果を直接比較した。
• ❌ 回線、プロトコル、クライアントを同時に変更し、差の原因を判断できなくなった。

最終的な選び方はシンプルです。継続的なパケットロス、明らかなジッター、頻繁な再接続がある回線を先に除外し、残った回線で遅延と持続的なスループットを比較します。測定記録を残し、ネットワーク環境やクライアントのバージョンが変わったら同じ手順で再確認してください。そうすれば、宣伝ページの数字や一度だけのピーク値より、日常の実際の使用感に近い結論を得られます。