VPNの速度測定はどう測る?2026年版 実測方法と計測ツール
広告に載っている速度の数字は、そのまま参考にはできません。本記事では、自分で測定するための手順を一通り解説します。使うツール、測る時間帯、見るべき指標、そして加工されたスクリーンショットの見分け方まで扱います。
広告の速度測定値はなぜそのまま使えないのか
VPNの速度測定はどう測れば正確なのか。まず結論から言うと、1回の測定結果は「自宅の回線 → 国内の出口 → 国際回線 → 海外データセンター → 測定サーバー」という経路上で、最も遅い区間の性能を表しているにすぎません。広告の数字は通常、ある日の・ある1本の回線の・ある1台の測定サーバーでの結果を示すもので、サーバーを変えれば桁が変わることも珍しくありません。
最もよくある誤差要因は、測定サーバーの位置です。スピードテストアプリは既定で遅延が最も低いサーバーを選びます。もし同じ都市のノードが選ばれていれば、測っているのは自宅回線の数値であり、国際区間はまったく経路に入っていません。回線を比較したいなら、測定サーバーを目的の地域に手動で固定する必要があります。
2つ目の落とし穴は単位です。スピードテストは Mbps(メガビット毎秒)、ダウンロードツールは MB/s(メガバイト毎秒)を使い、両者は8倍違います。100 Mbps は約 12.5 MB/s です。スクリーンショットに 100 MB/s とあれば 800 Mbps のことですから、まず換算してから、それが自宅回線の桁に収まっているかを判断しましょう。
「Mbps」と「MB/s」は1文字しか違いませんが、数値は8倍違います。あまりにきれいなスクリーンショットを見たら、まず単位を確認し、それから割り算を1回。
- 8× 1 MB/s と Mbps の換算倍率。スクリーンショットの数字を大きく見せる最も一般的な手口
- 3 回 同じ時間帯での最低測定回数。ピーク値ではなく中央値を取る
- 3 区分 昼間・夜のピーク・深夜の少なくとも3つの時間帯をカバーする
- 20–23 北京時間の夜ピークにあたる時間帯。国際回線の速度低下が最も集中する時間窓
速度測定の前に固定すべき5つの変数
速度測定は、Webページを開いてボタンを押すことではなく、条件を管理した比較実験です。以下の5つの変数のうち1つでも変われば、前後の数値をそのまま比べることはできません。
- デバイスと接続方式 —— 同じデバイス、同じブラウザを使います。有線LANが使えるなら Wi-Fi は使いません。Wi-Fi を使う場合はまず電波強度を確認してください。そうしないと、測っているのはデバイスとルーターの距離になってしまいます。
- クライアントとプロトコル —— Shadowsocks、VMess、Trojan、VLESS の一般的な構成は TCP で転送されるため、パケットロスがあると輻輳制御の影響を受けて速度がはっきり落ちます。Hysteria2、TUIC は QUIC/UDP ベースで、ロスの多い回線でもスループットを維持しやすい一方、事業者の UDP ポリシーの影響を受けやすくなります。数値を比較するときは、プロトコルを揃えてください。
- ルーティングモード —— グローバルモードとルールモードでは、通信の経路がまったく異なることがあります。ルールモードでは、測定サーバーのドメインが直接接続ルールに該当することがあり、その場合は自宅回線を測っていることになります。
- 測定サーバー —— 同じ都市、同じ事業者のサーバーに固定します。サーバーを変えることは、ものさしを変えるのと同じです。
- 時間帯 —— 少なくとも昼間・夜のピーク・深夜の3区分をカバーし、数日間連続で記録します。調子の良い瞬間だけを拾うのはやめましょう。
測定の前にマイIPページを開き、出口 IP が目的の地域になっているか確認します。ローカルの IP のまま表示されるなら、通信は直接接続を通っており、以降の数値は回線とは関係ありません。
どのツールで測るか:ブラウザ・コマンドライン・クライアント内蔵
ツールに絶対的な優劣はありません。大切なのは、それぞれのツールが何を測っているのかを知ることです。帯域・遅延・パケットロスは別々の事柄で、3つを同時に正確に測れるツールはほとんどありません。
| ツール | 種類 | 主にわかること | 注意点 |
|---|---|---|---|
| Speedtest(Ookla)Web版 / デスクトップ版 | マルチスレッド帯域 | 下り・上り・遅延・ジッター | 既定では最寄りのサーバーを自動選択するため、目的の地域を手動で指定する必要がある |
| fast.com | マルチスレッド帯域 | 下り帯域(上りに切り替え可能) | ノードは Netflix が指定するもので変更できません。動画視聴シーンの参考値として適しています |
| Cloudflare Speed Test | 遅延と帯域 | アイドル時と負荷時の遅延、ジッター、パケットロス、上りと下り | 帯域を使い切ったときの遅延変化まで見られる。単なるピーク値ではない |
| iperf3 | 生のスループット | 自前のサーバーとクライアント間の上りと下り | 海外サーバーを自分で用意する必要があり、結果はサーバーの位置に強く依存する |
| mtr / WinMTR | 経路品質 | ホップごとの遅延とパケットロス | 経路のみを測り、帯域は測らない。どのホップから劣化するかの特定に使う |
| curl / ブラウザのダウンロード | 単一接続の実測 | 単一の HTTPS 接続における実際のスループットと初回バイト時間 | Webページを開く、ファイルを1つダウンロードするという実際の体験に最も近い |
なお、多くのクライアントに内蔵されている「速度テスト」ボタンは、ノードに対して1回のハンドシェイクか1回の HTTP リクエストを行うだけで、測っているのは遅延であり帯域ではありません。ノード選びの一次選別には使えますが、速度の結論として扱うことはできません。
どの指標を見るか:遅延、ジッター、パケットロス、そして単一スレッド帯域
帯域の数値は最も見やすく、最も誤解を招きやすい指標です。体感への影響が大きい順に並べると、パケットロス、ジッター、遅延、そして最後に帯域の上限となります。
- 遅延(RTT):データが往復するのにかかるミリ秒数で、クリックしてからの反応速度を決めます。値が低く、変動が小さいものほど良好です。
- ジッター(jitter):連続する遅延の振れ幅です。ジッターが大きい回線は、帯域がどれだけ広くても、ビデオ会議やリアルタイム対戦が引っかかります。
- パケットロス:国際回線で最も体感を損なう項目です。TCP 系のプロトコルはロスが起きると速度を落として再送するため、帯域の数値も下がります。UDP 系は再送しませんが、映像が乱れ、音声が途切れます。
- 下り帯域:ダウンロードと動画再生の上限を決めます。
- 上り帯域:通常は下りより小さく、ライブ配信、クラウドストレージの同期、オンライン保存でより重要になります。
- 初回バイト時間(TTFB):リクエストを送ってから最初の1バイトを受け取るまでの時間で、遅延と DNS 解決の両方の影響を受けます。
単一スレッドとマルチスレッドも区別しましょう。マルチスレッドの測定は複数接続の結果を合算するため、帯域の上限まで到達できますが、単一接続の劣化を覆い隠してしまいます。単一スレッドのほうが、動画のバッファリングやファイル1つのダウンロードという実際の感覚に近くなります。両方の数値を記録しておき、差が大きいほど、その回線は並列接続への依存度が高いと言えます。
# 単一接続の実測:実際のスループットと初回バイト時間を見る(Cloudflare の測定エンドポイント)
curl -o /dev/null -s -w 'dns %{time_namelookup}s | connect %{time_connect}s | ttfb %{time_starttransfer}s | speed %{speed_download} B/s\n' \
'https://speed.cloudflare.com/__down?bytes=100000000'
# 経路品質:50 個のプローブパケットを連続送信し、ホップごとの遅延とパケットロスを見る
mtr -rwzc 50 1.1.1.1各回のテストで6列を記録します。時刻、回線と地域、プロトコル、遅延、ジッター、単一スレッドの下りです。マルチスレッドの結果は別の列に記録し、単一スレッドの数値と比べないようにしましょう。
時間帯別・日別に記録する:再現できるテスト手順
以下の手順に追加のツールは不要で、デバイス1台と表1枚があれば最後まで実行できます。ここで測るのは「最大でどこまで出るか」ではなく、「この回線がどの時間帯に、どれほどの変動で、どれだけの帯域を提供するか」です。
- 回線を切断し、まずベースラインを測定します。同じデバイス、同じ測定サーバーで、自宅回線の遅延と下りを記録します。
- 回線に接続し、クライアントをグローバルモードに切り替えるか、ルーティングルールが測定サーバーのドメインを対象に含んでいることを確認します。
- IP 確認ページを開き、出口 IP が目的の地域に変わっていることを確認します。
- 同じ測定サーバーで3回連続して測定し、毎回の遅延、ジッター、下り、上りを記録します。
- curl またはブラウザのダウンロードで単一スレッドのテストを1回行い、実際のスループットと初回バイト時間を記録します。
- mtr で50個のプローブパケットを送り、どのホップからパケットロスが始まるかを確認します。
- 次の時間帯に移り、手順2〜6を繰り返します。少なくとも昼間・夜のピーク・深夜の3区分をカバーします。
- 数日間連続で記録したら、最も見栄えの良い1回ではなく、時間帯ごとの中央値と変動幅を比較します。
加工された速度測定のスクリーンショットを見分ける方法
まず回線の種類をはっきりさせる
直接接続・中継・IEPL 専用線では経路がまったく異なり、数値を並べて比べても意味がありません。
- 直接接続:クライアントが海外データセンターに直接接続し、全区間を公衆網で通ります。コストは低い一方、夜のピークには国際出口の混雑の影響を最も受けやすくなります。
- 中継:まず国内の中継サーバーに接続し、そこから海外へ出ます。経路が制御しやすくホップ数も少ないため、通常は直接接続より安定しますが、ボトルネックが中継ノード自体に現れることがあります。
- IEPL 専用線:端から端までを結ぶ国際イーサネット専用線で、公衆網の国際出口を通りません。遅延とジッターがより安定する一方、コストも高くなります。
スクリーンショットのセルフチェックリスト
- ✅ スクリーンショットに測定サーバーの都市と事業者、そして測定時刻が写っている。
- ✅ 単位が Mbps か MB/s か明記され、前後で統一されている。
- ✅ 下りの数値だけでなく、遅延・ジッター・パケットロス・帯域がまとめて示されている。
- ✅ 単一スレッドとマルチスレッドの結果が分けて示され、どの回線を測ったのかが明記されている。
- ❌ ピークだった1回だけを切り取り、サーバー・時刻・単位が示されていない。
- ❌ 数値が Mbps と MB/s の間で行き来し、実際より大きく見えている。
- ❌ 同じ都市の測定サーバーや LAN 内の iperf3 の結果を、国際回線の速度と偽っている。
- ❌ プロトコルと回線の種類を明記せず、直接接続・中継・IEPL 専用線の結果を1枚の画像に混ぜて比較している。
よくある誤解と結論
- 数値が大きいほど良い —— 帯域は上限を決めるだけで、下限を決めるのは遅延とパケットロスです。
- 1回測れば結論が出る —— 国際回線の状態は時間帯によって変わるため、1回の結果では安定性はわかりません。
- 同じクライアントならどの回線も同じ速度 —— 地域や回線の種類が違えば経路もまったく異なるため、それぞれ個別に測る必要があります。
- 遅延が低ければ速い —— 帯域が足りなければ、遅延が低くてもテキストメッセージが送れる程度で、動画はやはりバッファリングします。
- スピードテストの1つの数値だけを見る —— Webページの表示が遅い、動画がバッファリングするといった現象は、DNS 解決や単一接続の品質に起因することが多く、帯域を合算した測定結果には表れないことがあります。
最初の問いに戻りましょう。正確な速度測定とは、突き詰めれば、変数を固定したうえでの繰り返し比較です。まずデバイス、プロトコル、ルーティングモード、測定サーバーを固定し、次に時間帯ごとに遅延・ジッター・パケットロス・単一スレッド帯域を記録し、最後に最も見栄えの良い1回ではなく、中央値と変動幅を比べます。こうして得た数値なら、その回線を長く使う価値があるかどうかを判断する材料になります。