VPN速度測定実測比較：ツール・時間帯・指標を押さえ、広告の数値に惑わされない

まず速度測定の目的を決める：ダウンロード、ウェブ閲覧、それとも動画

大きなファイルをダウンロードする場合は、スループットが安定して続くかが重要です。ウェブ閲覧では、接続確立や名前解決、リクエストの応答を待つ時間が体感に影響します。ビデオ会議ではジッターやパケットロス、アップロード速度も確認しましょう。用途を先に書き出しておくと、どの指標を重視すべきか分かります。

よくある誤解は、クライアントのダウンロード速度のピーク値だけで、あらゆる用途の性能を判断することです。速度測定ツールは複数の接続を同時に確立し、利用可能な帯域を使い切ろうとする場合があります。一方、実際のアプリは接続数が少なかったり、サーバー側の速度制限を受けたりします。測定値が高くてもファイルのダウンロードが遅い場合、結果が不正とは限りません。測定時の負荷が異なる可能性もあります。

もう一つの誤解は、ノード名に表示された地域だけで経路全体が分かると思うことです。地域ラベルは通常、出口を識別するためのものですが、入口の場所や事業者間の接続、戻りの経路、混雑状況までは示しません。比較する際は、クライアントに表示された回線名全体と測定先を記録し、「日本の回線」のように地域名だけで済ませないようにしましょう。

ツールと指標：レイテンシはダウンロード速度とは別

測定サーバー、ダウンロード、アップロード、遅延を表示できるツールを選びましょう。測定先を手動で選べる場合は同じサーバーに固定します。自動選択のみの場合は、割り当てられたサーバーを記録してください。測定先ごとの結果は原因の切り分けに役立ちますが、単純にまとめて回線ランキングにするのは適切ではありません。

クライアントの「遅延テスト」も、説明を確認しましょう。入口までを測定する場合、プロキシ経由で特定のウェブサイトにリクエストする場合、接続の確立だけを確認する場合があります。クライアントや測定先が異なる数値を、そのまま横並びで比較することはできません。システムのpingは通常ICMPを使い、アプリのプロキシ経路を通るとは限りません。

測定ツールに表示される単位はそのまま記録しましょう。帯域幅の画面ではMbps、ダウンロードアプリではMB/sが使われることがあり、同じ単位ではありません。数字の見た目だけで比較しないよう、記録にはツールの表示単位をそのまま残してください。ジッターやパケットロスの算出方法が分からない場合は、同じツール内で相対的に比較するのがおすすめです。

測定環境を固定してから、回線を比較する

まずローカルネットワークの状態を測定してから、候補の回線に接続します。サービスに接続していない状態での測定は、アクセス回線の問題を特定する手がかりになります。ただし、これを単純に「回線性能の上限」と呼ぶことはできません。直接接続とプロキシ接続では経路が異なる場合があり、コンテンツ配信サーバーも変わる可能性があります。

1. バックグラウンド通信を止める。クラウドストレージの同期、システム更新、ほかのダウンロードを一時停止し、共有ネットワークで大容量通信が行われていないか確認します。測定のために、システムのセキュリティ機能を長時間無効にしないでください。
2. 接続方法を統一する。可能であれば有線ネットワークを使います。Wi-Fiを使う場合は、端末の位置とアクセスポイントを変えないようにしましょう。有線接続の結果と、電波が不安定なときの無線接続の結果を同じグループで比較しないでください。
3. クライアント環境を記録する。OS、クライアントのバージョン、選択した回線、ルールモード、TUNなどのネットワーク制御機能が有効かどうかを書き留めます。設定は変えず、まず回線だけを切り替えて比較しましょう。
4. 測定先を固定する。同じ速度測定サーバーを選び、測定通信が選択した回線を実際に通っていることを確認します。回線を切り替えたら、接続が安定するまで待ってから測定を始めましょう。
5. 測定を繰り返し、元の結果を残す。候補の回線を測定する順番を入れ替え、測定した時間の違いによる偏りを減らします。低い値や失敗した記録も残し、見栄えのよい結果だけを選ばないようにしましょう。
6. 実際のアプリでも確認する。よく使うウェブサイトを開く、対象のコンテンツを再生する、ファイルを転送するなどして、最初の表示までの待ち時間、転送の安定性、中断の有無を確認します。

速度測定では実際の通信量が発生し、測定中にアクセス回線の帯域を使い切る場合があります。従量課金のサービスを利用している場合は、残量を先に確認してください。自動測定を長時間繰り返したり、重要な通話の最中に最大速度で測定したりするのは避けましょう。

記録を共有する場合は、サブスクリプションURL、アクセストークン、アカウント情報を削除してください。測定のスクリーンショットには条件と結果だけを残せば十分で、クライアントの設定全体を見せる必要はありません。サブスクリプションリンクから設定を取得できることがあるため、公開の表や掲示板に載せないでください。

時間帯と測定先：夜間の混雑時間帯も実測する

実際にサービスを使う時間帯を含めて測定しましょう。昼間に快適でも、夜間も同じとは限りません。ある平日の夜に調子が悪かったからといって、回線が長期的に使えないと決めつけることもできません。記録ごとに日付、現地時刻、タイムゾーンを記入し、時間帯をまたいだ比較の根拠を残しましょう。

候補の回線は、できるだけ近い時間に測定し、別の日にも確認しましょう。測定中にアクセス回線が変わった場合は、記録を分けてください。集計では中央値やばらつきの範囲を確認できますが、平均値が繰り返し発生する切断を隠さないよう、元の測定値も残しておきましょう。

測定先のサーバーによっても結果は変わります。測定サーバー自体が混雑していたり、出口との接続が混み合ったりする可能性があります。また、自動選択では出口の地域に応じて測定先が変わることもあります。条件をそろえた比較には測定先の固定が適しています。自動選択ならツールの標準的な使用感に近づきます。どちらの方法でも構いませんが、記録は分けてください。

実際のウェブサイトでは、出口のIPアドレスやDNSの結果に応じてコンテンツ配信サーバーが割り当てられることもあります。そのため、「同じURL」でも「同じサーバー」とは限りません。詳しく調べる場合は、アプリに表示される接続先ノードや接続情報を記録できます。情報を確認できない場合は、そのときのアクセス体験に結論を限定し、国際経路全体について推測しないようにしましょう。

速度測定の数値は高いのに遅い：ルール設定・DNS・経路を確認

まず、速度測定の通信と実際のアプリの通信が同じ経路を使っているか確認しましょう。ルールモードによっては、速度測定サイトは直接接続、目的のアプリはプロキシ経由になることがあります。反対のケースもあります。システムプロキシの影響を受けるのは、通常、プロキシ設定に従うアプリだけです。すべてのプログラムがプロキシ経由だとは限りません。TUNモードの適用範囲も、クライアントやルーティング、除外ルールによって異なります。

DNSは名前解決とコンテンツ配信サーバーの選択に影響します。想定していない経路でDNS問い合わせが行われると、意図しないDNSリゾルバーに問い合わせが渡ったり、現在の出口に適さないサーバーが選ばれたりする可能性があります。調べる際は、クライアントのDNS設定やルールログに加えて、ブラウザーの暗号化DNSが別途設定されていないか確認しましょう。DNSの変更が必ず速度向上につながるわけではありません。

パブリックDNSの確認ページは手がかりになりますが、表示されたリゾルバーの地域だけで漏えいと判断することはできません。DNSサービスが分散ノードを使っている場合があり、IPアドレスの位置情報が不正確なこともあります。想定した設定をもとに問い合わせ先を確認し、自分のプライバシー要件に合っているか判断しましょう。変更後は、IPv4とIPv6の通信経路に漏れがないことも確認してください。

プロトコル名だけで性能を判断することもできません。Shadowsocks、VMess、Trojan、VLESSの実際の動作は、トランスポート方式や暗号化設定、クライアントの実装、通信経路によって変わります。Hysteria2とTUICはQUICをベースとしており、UDPが制限されている場合やネットワークポリシーが変わった場合には、動作が異なることがあります。プロトコルを比較するなら、出口と測定先をできるだけ統一しましょう。統一できない場合、評価できるのは設定全体です。

IEPL専用線、中継、直接接続は、経路の構成を示すものであり、速度測定の結果そのものではありません。専用線区間の先にはローカルのアクセス回線や、出口から測定先までの経路があります。また、中継だからといって必ず遅くなるわけではありません。VPNGotの各回線の詳細は、サーバーページと管理パネルの表示をご確認ください。回線ラベルから、公開されていない帯域幅の保証を推測しないでください。

記録テンプレートと回線選びの結論

回線を比較するために、複雑なシステムを用意する必要はありません。通常のテキストやローカルの表計算シートで十分です。大切なのは、記録を見る人が測定条件の違いを確認できることです。以下のテンプレートには測定結果を記入していません。例の数値をサービスの性能と誤解しないためです。

測定日、現地時刻、タイムゾーン：
端末のOS、クライアント名とバージョン：
アクセス回線、接続方法：
回線名（省略せず記載）：
ルールモード、DNS、TUNの状態：
速度測定ツール、測定サーバー：
アイドル時の遅延、負荷時の遅延、ジッター：
パケットロスの結果、測定方法：
ダウンロード、アップロード、表示単位：
実際のアプリでの使用感：
異常、失敗、環境の変化：

• ✅ 同じグループで比較するには、ツール、測定先、接続環境をそろえましょう。
• ✅ よく使う時間帯の結果を残し、ピーク値より安定性とばらつきを重視しましょう。
• ✅ 速度測定も実際のアプリも想定した回線を通っているか確認し、ルールやモードの変更を記録しましょう。
• ❌ 1回のタイムアウトだけで回線が使えないと判断せず、クライアントの遅延測定をすべてのアプリの遅延とみなさないでください。
• ❌ サブスクリプションリンクを公開せず、認証情報を含む設定全体を速度測定の証拠として共有しないでください。

回線の使用感は、アクセス回線や接続先サービス、時間帯によって変わります。測定結果のスクリーンショットを保存するより、測定方法を記録しておく方が役立ちます。サポートが必要な場合は、匿名化した測定条件、問題が発生した時刻、クライアントログの一部を管理パネルのチケットからお送りください。再現できる問題から調査を進められます。