VPNの速度測定実測を比較：自分で本当の速度を確かめる方法

VPN速度を実測比較する際に大切なのは、最高のダウンロード速度を探すことではなく、近い条件で回線が自分の用途を安定して満たせるか確かめることです。まず通常のネットワークを測定し、測定先を固定して時間帯を変えながら繰り返し測ります。最後に実際のアプリでも確認します。こうして得た結果をもとに、回線を切り替えるべきか、ルールを調整するべきか、それともまず通常のネットワークを見直すべきか判断できます。

この記事では測定方法を紹介します。回線の成績を示すものではありません。ウェブの速度測定、クライアントの接続確認、ファイルのダウンロードでは、それぞれ異なる部分を測定するため、結果をそのまま並べて比較することはできません。記録には端末、接続ネットワーク、ノード、測定サーバー、プロキシモードを併記し、後から比較できるようにしましょう。

遅延・実効速度・パケットロスの違いを知る

遅延はリクエストを送ってから応答が返るまでの時間で、ウェブ操作やリモート操作、通話の応答性に影響します。実効速度は一定時間内に実際に転送できたデータ量で、大容量ファイルのダウンロード能力の目安になります。ジッターは遅延のばらつきです。平均遅延が低くても、ばらつきが大きいとリアルタイムアプリの使い勝手が悪くなることがあります。

帯域幅は一般に回線の容量を指します。一方、速度測定サイトに表示されるダウンロード速度は、その時点の条件で測った実効速度です。自宅の接続環境、海外への経路、出口のリソース、測定サーバーなど、さまざまな要因に左右されます。一度の測定で出た最高値が、すべてのサイトで常に得られる速度だと考えないようにしましょう。

ブラウザーで測定した遅延は、アプリケーション層のリクエストに由来する場合があり、システムの ping が使う ICMP の往復時間と同じではありません。ジッターやパケットロスの測定方法もツールによって異なります。比較する際はツールと測定方法をそろえ、単位が同じだからといって同じ種類の測定結果だとみなさないようにしましょう。

基準値を測り、通信が本当に回線を通っているか確認する

本測定の前に、プロキシを無効にした状態で通常のネットワークを測定します。可能であれば安定した有線接続を使い、Wi-Fiの場合は端末とアクセスポイントの位置を変えないようにします。クラウドストレージの同期、システム更新、大容量ファイルのダウンロードを一時停止し、同じネットワーク内のほかの端末が上り・下りの通信を継続的に使っていないことも確認してください。

基準値の測定では、目的を分けて考えます。ネットワークに近い測定先は接続環境の確認に使い、同じ海外の測定先は回線の有効・無効を切り替えたときの差を確認するために使います。プロキシを無効にすると測定先に接続できない場合は、「基準値は測定不可」と記録してください。速度をゼロと記入したり、それをもとに速度向上率を計算したりしてはいけません。

クライアントを有効にしたら、まずIPアドレス確認ページでブラウザーの出口を確認し、速度測定サイトのドメインにどのルールが適用されているかを調べます。ブラウザーがプロキシを使っていても、コマンドラインツールも同じ経路を使うとは限りません。システムプロキシですべてのアプリが制御されるわけではなく、TUNモードでもクライアントのルーティング設定を確認する必要があります。スイッチの状態だけで判断しないようにしましょう。

出口IPが変わったことからわかるのは、確認に使ったリクエストの出口が変化したことだけです。測定通信やすべてのアプリが同じ回線を通っている証明にはなりません。クライアントの接続ログを照合し、測定ドメイン、宛先アドレス、出ていくノードを確認してください。直接接続の経路を測りながら、特定の回線の結果として記録してしまうミスを防げます。

速度測定ツールと測定サーバーの選び方

ウェブの速度測定は手軽に比較できますが、測定サーバーを手動で固定することが大切です。自動選択では近距離で応答の速いサーバーが選ばれやすく、回線を切り替えると別のサーバーに変わり、比較できなくなることがあります。測定先を固定できないツールを使う場合は、サーバー名を記録し、測定先ごとに分けて分析しましょう。

測定サーバーは実際の用途に合わせて選びます。出口に近いサーバーを測れば、出口周辺までの回線性能を把握しやすくなります。実際に利用するサービスがある地域のサーバーを測れば、アクセス経路全体の性能に近い結果が得られます。前者が速く後者が遅くても矛盾ではありません。地域間の接続、コンテンツ配信サーバー、接続先サイト側の制限などが影響している可能性があります。

コマンドラインツールは繰り返し測定するのに便利ですが、必ず公式の配布元から入手し、プロキシへの対応方法を確認してください。プロキシ環境変数を参照するツールもあれば、専用の引数が必要なもの、システムプロキシの制御を受けないものもあります。信頼できる配布元からのファイル転送で継続速度を確認する場合も、ファイルのキャッシュ、サーバー側の速度制限、ディスク書き込みのボトルネックを考慮しましょう。

複数接続を使う速度測定では、複数の転送接続を同時に確立するため、回線をより活用できることがあります。単一接続の測定は、一部のファイルダウンロードの挙動に近い結果になります。両方を補完的に使うことはできますが、同じ測定グループの平均値に混ぜてはいけません。ツールのバージョン、接続モード、単位、測定先を統一し、スクリーンショットに残った最高値だけでなく、測定結果全体を保存してください。

時間帯を変えて実測し、記録を残す

海外への通信経路は、時間帯や混雑状況によって変わります。ネットワークがたまたま快適だったときに一度だけ測るより、普段使う仕事中、夜間、空いている時間帯に測るほうが参考になります。各時間帯で複数回測定し、端末、ネットワーク、測定先、クライアント設定はできるだけ同じにしてください。同じ端末で複数の速度測定を同時に実行しないようにしましょう。

1. 測定環境を記録する。日付、時間帯、接続方法、クライアントのバージョン、ノード名、プロトコル、プロキシモードを書き留めます。ノード名は識別用の情報であり、実際の出口確認の代わりにはなりません。
2. 基準値を測る。プロキシを無効にし、ネットワークから接続できる測定先と比較用の測定先を確認します。接続環境に異常がある場合は、回線を比較する前に問題を解消してください。
3. 接続して経路を確認する。出口と速度測定の接続ログを確認し、接続が安定するまで待ちます。ノードの切り替え中に測定を始めないでください。
4. 測定先を固定して繰り返し測る。遅延、ダウンロード、アップロードに加え、ツールが表示する場合はジッターとパケットロスも記録します。測定できない項目は「未測定」と記載し、ゼロで代用しないでください。
5. 比較する回線を交互に測る。一方の回線をすべて測り終えてから、時間を空けてもう一方を測る方法は避けましょう。交互に測ることで、短時間のネットワーク変化による偏りを抑えやすくなります。
6. 実際の用途で確認する。普段使うウェブサイト、会議、ダウンロードなどを試し、途切れや切断、再接続の有無とタスクの完了状況を記録します。

速度測定では通信量を消費します。特に実効速度を継続して測る場合は注意が必要です。まず接続と経路を確認し、必要な範囲で転送テストを行いましょう。長時間にわたって繰り返し測定する必要はありません。VPNOCの月額プランの通信量は利用開始日を基準に毎月リセットされます。追加通信量は使い切るまで期限なく利用できます。測定で消費する通信量も自分の利用計画に含めてください。

平均値だけでなくばらつきや失敗も確認する

同じ条件で得られた有効な結果について、遅延、ダウンロード、アップロードの算術平均をそれぞれ計算できます。各測定値の合計を有効な測定回数で割って求めます。あわせて中央値、最小値、最大値も記録しましょう。平均値は全体像をつかむのに便利で、中央値は極端な値の影響を抑え、測定範囲からは速度の変動を把握できます。

異なるサーバー、プロトコル、ネットワークの結果をひとまとめにして平均してはいけません。失敗した測定も記録から消さないでください。接続が切れて転送結果が得られなかった場合は、スループットを適当に記入せず、失敗として個別に記録します。接続の安定性と、接続できた後の速度は分けて評価しましょう。

異常値は、見栄えをよくするために削除するのではなく、理由を確認してください。システム更新、Wi-Fiの再接続、測定サーバーの選択ミスがあったと確認できた場合は、環境要因として印を付け、除外した理由も残します。原因がわからない低速の記録も、実際の利用で起こりうる状況を示しています。

速度測定は速いのにアプリが遅いときの確認方法

まず通信ルールを確認します。速度測定サイトのドメインは海外回線を通っていても、対象アプリはルールによって直接接続されている場合があります。その逆も考えられます。アプリが別のドメインや独自のプロキシ設定、異なる通信方式を使うこともあります。すべてのスイッチを何度も切り替えるより、接続ログを一つずつ確認するほうが原因を特定しやすくなります。ルールを変更した後は接続し直してください。既存の通信がすぐに新しい経路へ切り替わるとは限りません。

次にDNSを確認します。名前解決に時間がかかると、ページを最初に開くまでの時間が延びることがあります。また、名前解決の結果によってコンテンツ配信サーバーの選択が変わる場合もあります。DNSの確認は、名前解決のリクエストが想定した経路を通っているか調べるのに役立ちます。ただし、DNSリゾルバーの所在地と出口の所在地が異なるだけで、情報漏えいと判断することはできません。クライアントのDNS設定、暗号化DNSの設定、実際のリクエスト経路をあわせて確認しましょう。

速度測定中の長時間接続による転送は正常なのに、ウェブページがなかなか開かない場合は、接続先サイトの状態、ブラウザー拡張機能、接続確立の過程、端末のリソース使用状況も確認してください。ダウンロードは速くてもアップロードが遅いと、会議や同期、応答の送信に影響することがあります。アイドル時と負荷時の遅延を比較すると、通信で回線を使い切った際の待ち行列の問題を発見しやすくなります。

回線の種類やプロトコルは、原因を調べる手がかりにはなります。直接接続、中継、IEPL専用線は異なる経路構成を指しますが、専用線だからといって接続先サイトまでの速度が常に一定とは限りません。プロトコルによって通信上の特性も異なります。たとえばHysteria2とTUICはQUICをベースとしており、UDP経路の状態に影響されます。プロトコル名だけで判断せず、同じ条件で測定してください。プロトコルを比較する際も、経路と出口をできるだけ統一しましょう。

後から確認できる比較結果を残す

最後に記録を整理し、自分の用途に合わせた結論をまとめます。どの回線が対話型の操作に向くか、どれが継続的なデータ転送に向くか、どの時間帯に予備の回線が必要かを確認しましょう。接続ネットワーク、クライアント設定、接続先の地域を変えた場合は、以前の結果を再確認する必要があります。測定レポートには適用条件を明記し、一部の結果を長期的な保証として扱わないでください。

• ✅ 通常のネットワークの基準値に問題がなく、測定中にほかの継続的な通信もありませんでした。
• ✅ 出口と通信ルールの記録を確認し、測定リクエストが通った経路を把握しています。
• ✅ 同じグループの測定では、測定先、ツール、接続モード、単位を統一しています。
• ✅ 普段使う時間帯をカバーし、平均値、ばらつき、失敗の記録を残しています。
• ✅ ダウンロードの最高値だけで回線を選ばず、実際のアプリでも確認しています。
• ❌ 異なる測定条件を混ぜて計算せず、未測定の項目や失敗をゼロと記録していません。

クライアントの接続画面や基本設定を確認するには、使い方ガイドをご覧ください。回線とプロトコルの違いについては、プロトコルガイドで解説しています。まず経路を確認し、次に指標を比較し、最後に実際のタスクで判断する。この手順なら再現性があり、トラブルの原因調査にも役立つ測定記録を作成できます。