VPN速度測定実測比較｜ツール・時間帯・指標の選び方

VPNの速度を実測比較する際に大切なのは、最速のダウンロード値を探すことではなく、同じ端末・接続先・近い時間帯で、用途に必要な性能を安定して得られるか確認することです。測定ツールの結果は特定の経路を示すもので、サービス全体に共通する速度ではありません。この記事では、架空の回線データを使わずに比較する方法を紹介します。

速度測定の指標：ダウンロード速度以外に見るべき項目

ネットワークのリクエストは、端末、ルーター、アクセス回線、サービスの回線、接続先サーバーを経由します。どの段階もボトルネックになる可能性があります。ダウンロードの実効速度が高くても、Webページの表示が速いとは限りません。アイドル時の遅延が小さくても、ファイルのアップロード中に会議が快適とは限りません。まず指標と用途を対応させて判断しましょう。

速度の単位もそろえて確認しましょう。速度測定ツールではMbps、ダウンロードソフトではMB/sと表示されることがあります。それぞれビットとバイトの速度を表すため、数値をそのまま比較できません。プロトコルのオーバーヘッドや再送、アプリの処理もファイルのダウンロード結果に影響します。記録には元の単位を使い、ダウンロードソフトの数値を測定ページの帯域幅として扱わないようにしましょう。

Webページの表示速度には、DNSの検索、接続の確立、TLSハンドシェイク、サーバーの処理時間も関係します。回線の実効速度が十分でも、名前解決に失敗したり接続先の応答が遅かったりすれば、表示に時間がかかります。「速度測定は速いのにWebページが遅い」場合は、測定サイトを何度も変えるのではなく、接続の各段階を調べましょう。

ツールの選び方：総合測定と実際のアプリ利用を分けて確認

Speedtestのようなツールでは、複数接続時のダウンロード・アップロード速度や遅延を確認できます。サーバーの自動選択は日常的な確認に便利ですが、出口の異なる回線を直接比較する用途には向きません。回線を切り替えると、別の都市や通信事業者の測定サーバーが選ばれる場合があります。可能であれば測定サーバーを手動で固定し、サーバー名と所在地を記録しましょう。

Fast.comはNetflix関連のネットワーク転送を測るため、動画視聴時の参考情報として利用できます。ただし、特定地域の作品ライブラリにアカウントでアクセスできることや、特定の作品を再生中に速度が維持されることを示すものではありません。動画配信の利用状況は、地域の判定、実際の再生、画質の変化、バッファリングも確認しましょう。

OS標準のpingコマンドでは、接続先からのICMP応答時間を確認できます。mtrや経路追跡ツールは、経路上の異常を調べる際に役立ちます。ただし、端末からの測定がプロキシクライアントを経由するとは限りません。特にシステムプロキシのみを有効にしている場合は注意が必要です。結果を判断する前に、測定リクエストの経路が直接接続かプロキシ経由かを確認しましょう。

実際のアプリを使った確認も欠かせません。会議では音声の途切れや映像の停止、ファイル転送では継続中の中断、Web閲覧では初回表示と次回以降の違いを確認します。普段使うアプリで総合測定を補うことで、特定の測定サーバーでの好成績を、すべてのWebサイトでの使い心地と取り違えずに済みます。

測定環境：通信が対象の回線を通っているか確認

まず端末と接続方法を固定します。有線ネットワークを使える場合は、有線接続で基準値を測定しましょう。Wi-Fiの場合は端末の位置を変えずに測ります。クラウドストレージの同期、OSの更新、ほかのダウンロードを一時停止し、同じネットワーク上の別端末が帯域幅を継続的に使っていないことも確認します。端末の発熱、省電力設定、クライアントの処理能力も実効速度を下げる要因になります。

クライアントの「システムプロキシ」「ルールモード」「TUNモード」は、それぞれ動作が異なります。システムプロキシは通常、プロキシ設定に従うアプリにのみ影響します。ルールモードでは、ドメインやアドレスに応じて直接接続かプロキシ経由かが決まります。TUNモードが通信を取り込む範囲は、実装や設定によって異なります。TUNを有効にしていても、除外設定や経路を確認しましょう。モード名だけでは、すべての通信が対象回線を通っている証拠にはなりません。

クライアントの接続ログを開き、速度測定のドメインがテスト対象の回線に割り当てられていることを確認します。次に同じブラウザーでIPアドレス確認ページを開き、出口が想定どおりか参考情報として確認しましょう。出口アドレスが変わったことから分かるのは、そのリクエストの経路が変わったことだけです。ほかのアプリも同じ経路を通るとは限りません。

サブスクリプションURLは、ノードや関連設定をクライアントに提供するものであり、それ自体が接続プロトコルではありません。更新すると、ノードの内容、ルール、選択結果が変わる場合があります。測定前に更新を済ませ、ノードを固定し、クライアントのバージョン、プロキシモード、プロトコル名を記録しましょう。比較の途中で設定を更新しないでください。

DNSも個別に確認しましょう。名前解決は、端末のOS、クライアント、またはブラウザーの暗号化DNS機能が行う場合があります。DNSリークとは、DNSの通信が想定するプライバシー境界と異なる経路を通る状態です。異なる地域のDNSサーバーが表示されたという理由だけで、リークとは断定できません。クライアントのDNS設定、ブラウザー設定、実際のリクエスト記録をあわせて確認しましょう。

再現可能な実測手順と時間帯の選び方

公平に比較するには、主要な条件を一度に一つだけ変えます。回線を比較する場合は、端末、ネットワーク、ツール、接続先を固定します。プロトコルを比較する場合も、出口と回線条件をできるだけそろえましょう。固定できない条件は記録に明記し、差を特定のブランドやプロトコルだけの影響と決めつけないようにします。

1. 用途を決める。会議、リモートデスクトップ、ダウンロード、動画視聴のどれに使うかを先に書き出し、用途に合った指標を選びましょう。測定後に特定の回線に有利な結果だけを選ぶのは避けてください。
2. 直接接続時の基準値を記録する。プロキシを無効にし、経路が元に戻ったことを確認してからローカルネットワークを測定します。国際的な接続先に直接つながらない場合は、そのまま失敗として記録しましょう。アクセス回線の調査用に国内の接続先を測ることはできますが、接続先が異なる結果をそのまま比較してはいけません。
3. ノードを固定して接続する。ノード名、プロトコル、プロキシモード、出口を確認します。接続ログで速度測定のリクエストがそのノードに割り当てられていることを確かめ、接続状態が安定してから測定を始めましょう。
4. 同じツールで測定する。測定サーバーを固定し、ダウンロード、アップロード、アイドル時の遅延、ツールが提供するほかの指標を記録します。最高値だけを保存せず、失敗、中断、異常も残しましょう。
5. 繰り返し、順番を入れ替えて測定する。測定の間にネットワークが落ち着く時間を設け、候補回線の測定順を入れ替えます。バックグラウンド処理や時間経過に伴うネットワークの変化による偏りを抑えられます。
6. 実際の用途でも確認する。同じ接続先のWebページを開く、同じファイルを転送する、または同じ動画を再生します。初回アクセスとキャッシュ後のアクセスを区別し、キャッシュ済みのデータを回線の高速化と取り違えないようにしましょう。
7. 普段使う時間帯にも再測定する。勤務時間、現地の夜間ピーク、その他の実際の利用時間帯ごとに記録します。日付、現地時間、タイムゾーンを残しましょう。地域をまたいで比較する場合は特に重要です。

夜間ピークの時刻は、どのネットワークでも共通ではありません。アクセス事業者、回線の出口、接続先サービスによって混雑する時間帯は異なります。高い数値が出やすい空いている時間だけでなく、普段使う時間帯も測定しましょう。特定の回線でピーク時に異常が出た場合は、直接接続時の基準値も再測定すると、ローカルネットワークでも同時に混雑しているか判断しやすくなります。

結果をまとめる際は、最大値だけでなく、典型的な性能と変動幅に注目しましょう。各回の結果を残し、中央値に近い値、継続転送の状態、失敗の有無をあわせて判断します。ジッター、パケットロス、負荷時遅延の算出方法はツールごとに異なる場合があります。同じ名前の指標でも、異なるツール間の数値をそのまま合算・比較するのは避けましょう。

回線とプロトコル：名称だけでは測定条件は分からない

直接接続は一般に、クライアントが海外のサーバーへ直接接続する方式を指します。中継では入口や転送の段階が追加されます。IEPL専線は専用線による通信方式の一種を表しますが、実際の接続方法や出口はサービスの構成によって異なります。経路が短ければ必ず速いとは限らず、中継が一段増えれば必ず遅くなるとも限りません。混雑状況、相互接続の品質、接続先の場所などが結果を左右します。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルまたはプロトコル体系であり、速度のランクではありません。実際の性能は、伝送方式、実装、暗号化処理、ネットワーク環境にも左右されます。VLESSの安全性は、利用する伝送方式とセキュリティ層を含めて判断する必要があります。QUICをベースにした方式も、UDPの到達性やネットワークのポリシーに影響されます。

異なる地域、回線、クライアントで得た結果を根拠に、特定のプロトコルが常に最速だと結論づけることはできません。Windows、macOS、iOS、Android、Linuxでは、通信を取り込む方法やバックグラウンド処理の制限が異なります。モバイル端末での性能は実際にその端末で確認しましょう。デスクトップでの測定だけでは、完全に代用できません。

結果の見方：問題が起きている段階を特定する

• ✅ 直接接続とプロキシの両方が遅い：まずローカルネットワーク、バックグラウンド通信、Wi-Fi、端末の負荷を確認してから、回線を調べます。
• ✅ 総合測定は正常なのに特定のWebサイトだけ遅い：接続先サービス、DNS、ルールの適用状況、出口までの経路を確認し、サイト側の問題をサービス全体の問題と混同しないようにします。
• ✅ ダウンロードは速いのに会議が途切れる：ジッター、パケットロス、負荷時遅延を重点的に確認し、会議アプリがプロキシ経由かどうかも調べます。
• ✅ 特定の時間帯だけ遅くなる：同じ条件で再測定した記録を保存し、ローカルまたは国際経路の混雑と関係があるか確認します。
• ❌ 最高スコアだけを保存する：変動や失敗を見落としやすく、普段の使い心地を示す結果にはなりません。
• ❌ 端末、ノード、ツールを同時に変える：どの要因で変化したか分からず、順位付けにも適した結果になりません。

トラブル調査の記録を送る際は、測定日時、接続ネットワーク、クライアントのバージョン、ノード名、プロキシモード、接続先サーバー、発生した現象を記載してください。スクリーンショットにサブスクリプションURL、アカウントのパスワード、アクセストークンが写らないようにしましょう。VPNUGへの問い合わせはユーザーパネルのチケット窓口から行えます。記録を添えて状況を説明してください。