スピードテストのやり方｜Google・Fast.comの違いと結果の見方を実測で解説

スピードテストは、測定用のサーバーとの間でデータを流し、1秒に何ビット運べたかを数えます。結果は、PC から測定サーバーまでの道のりのうち、いちばん遅い所で決まります。

flowchart TD
    A[PC・スマホ] --> B[Wi-Fi・LANケーブル]
    B --> C[ルーター]
    C --> D[回線・プロバイダー]
    D --> E[測定サーバー]

急いでいる人向けに、よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.4 LTS・Linux カーネル 6.18。ネットワーク名前空間（ip netns。1台の中に独立したネットワークを作る仕組み）で PC・ルーター・測定サーバーの3台分を作り、ルーターとサーバーの間に、速さの上限（100Mbps）・往復の遅延・待ち行列の長さ・パケットロスを付ける Python 3.11.15 の自作の中継を置きました。測定は iperf3 3.16（TCP の輻輳制御は CUBIC）、curl 8.5.0、iputils 20240117 の ping で行い、HTTP のサーバーは Python で書いた Range 対応の小さなサーバーです。外部の速度測定サービスには接続していません。各サービスの仕組みは、Google 検索ヘルプ、Measurement Lab（M-Lab）の公式ドキュメント、FAST.com の公式ページと Netflix の発表資料、Ookla については公開の論文（IEEE、2024年）と Ookla の公式 Homebrew リポジトリ、目安の値は Netflix・YouTube・Zoom・Microsoft Teams・PlayStation の公式ヘルプ、Mac の networkQuality は Apple サポート、iperf3 は ESnet の公式リポジトリで確かめました（確認日 2026年10月23日）。

スピードテストとは（何を測っているのか）

この節では、スピードテストが何をしていて、どの数字が何を表すのかが分かります。

スピードテストは、測定用のサーバーとの間で実際にデータを送り受けし、その量と時間から速さを計算するテストです。 Google 検索ヘルプも、テスト中に今の接続で転送できるデータの量を測り、そこから速さを出すと説明しています。速さの単位は Mbps（メガビット毎秒。1秒に何百万ビット運べるか）です。

速さ（Mbps）は大きいほど、Ping とジッター（ms）は小さいほどよい値です。 向きが逆なので、結果を見るときに取り違えないようにします。Ping とレイテンシの関係、ジッターの詳しい意味は、関連記事「レイテンシとは｜意味・目安・測り方を遅延0〜300msの実測で解説」で扱っています。

Googleのスピードテストのやり方（PC・スマホ）

この節では、Google 検索から速度テストを動かす手順と、そのテストの提供元・使うデータの量が分かります。

Google 検索ヘルプによると、このテストは Google が Measurement Lab（M-Lab）と提携して行っているものです。押してから30秒ほどかかり、使うデータの量は米国外で約 4.4MB（米国内は約 9.4MB）、測れる上限は 700Mbps です。1Gbps 以上の回線でも 700Mbps より上は表示されないので、高速な回線は次の節の別のテストと比べます。テストのために IP アドレスが M-Lab に渡され、M-Lab はその結果を、インターネットの研究のために公開しているデータに加えます。

M-Lab の公式ドキュメントでは、使われているテスト（NDT）は 1本の接続（シングルストリーム）で 上りと下りを測り、それぞれ約10秒間、できるだけ多くのデータを送ろうとします。また、M-Lab のサーバーは利用者のプロバイダーの網の外にあり、テストは必ずプロバイダーの境目をまたぐ、と説明しています。この2点が、ほかのテストと結果が違う大きな理由です（後の節で実測します）。

Google・Fast.com・Speedtest by Ooklaの違い

この節では、よく使われる3つの速度テストが、何を測り、どのサーバーをどう使うのかを1つの表で比べられます。

表の根拠は次のとおりです。

• Google：Google 検索ヘルプ（M-Lab との提携・約30秒・上限 700Mbps）と M-Lab の NDT の説明（1本の接続・約10秒・網の外のサーバー）。
• Fast.com：FAST.com の公式ページは、Netflix のサーバーへのアップロードとダウンロードを複数回行って速さを測る、と説明しています。Netflix の技術者が RIPE 74（2017年5月）で発表した資料では、近くて状態のよい配信用サーバー（Open Connect Appliance）を選び、複数の接続でファイルの一部ずつを取得し、速さが落ち着いたら測定を止め、TCP の立ち上がりの部分は計算から外す、と説明しています。
• Ookla：Ookla の測定のしかたを調べた論文（Zhang ほか、IEEE、2024年）は、IP アドレスの位置から近いサーバーを10台選んで Ping を測り、最も遅延の小さいサーバーを使い、並列の HTTPS/TCP 接続で上りと下りを測る、と説明しています。Ookla は Speedtest CLI というコマンド版も出していて、Ookla の公式 Homebrew リポジトリ（teamookla/homebrew-speedtest）の定義では、コマンド名は speedtest、版は 1.2.0 です。

「どのテストが正しいか」ではなく、「何を測っているか」が違います。 契約した回線の上限に近いかを見るなら複数の接続のテスト、ふだんのダウンロードの体感や経路の問題を見るなら1本の接続のテストが向いています。国内には、利用者の測定結果を集めて回線の種類ごとの平均を公開している「みんなのネット回線速度（みんそく）」のようなサイトもあります。

スピードテストの結果の見方（下り・上り・Ping・ジッター）

この節では、表示された数字が「速いのか遅いのか」を、何と比べて判断するかが分かります。

下りの値は、回線の契約の速さ（最大 1Gbps など）とそのまま比べません。 契約の値は「最大」で、Wi-Fi・ルーター・測定サーバーまでの道のりの影響を受けます。比べる相手は、同じ回線のほかの人の値と、使い方ごとの目安（次の節）です。みんそくが公開している直近3か月の平均（2026年10月23日時点の表示、IPv4 の値）は次のとおりです。

みんそくも、この値は実際の速さを保証するものではないと注記しています。利用者が測った値の平均なので、Wi-Fi で測った値も含まれます。

ロード済みレイテンシとバッファブロート（Fast.com の詳細）

Fast.com の詳細には、「アンロード済み」と「ロード済み」の2つのレイテンシが出ます。 Netflix の発表では、アンロード済みはネットワークにほかの通信が無いときの往復時間、ロード済みは動画やバックアップなどの重い通信が流れているときの往復時間で、2つは近いのが理想としています。FAST.com の公式ページは、この差をバッファブロートと呼ぶと説明しています。ルーターなどが送りきれないデータを大きな待ち行列にため込み、その列に並ぶ時間だけ遅延が増える状態です。

手元の回線のまね（100Mbps・往復20ms）で、ルーターの待ち行列を「20ms 分」と「200ms 分」にして、iperf3 で下りを4本流している間に ping を測りました。

== 待ち行列 20ms 分  負荷なし
rtt min/avg/max/mdev = 20.359/20.670/22.637/0.543 ms
== 待ち行列 20ms 分  下りの負荷中
rtt min/avg/max/mdev = 33.555/37.919/39.951/1.668 ms
== 待ち行列 200ms 分  負荷なし
rtt min/avg/max/mdev = 20.336/20.445/20.738/0.106 ms
== 待ち行列 200ms 分  下りの負荷中
rtt min/avg/max/mdev = 161.101/188.328/220.073/17.419 ms, pipe 2

負荷なしの Ping はどちらも 20ms で、違いが出ませんでした。 違いが出たのは、下りを流している間だけです。ふだんの速度テストの Ping が小さくても、家族が動画を見ている間に通話が途切れるなら、ロード済みレイテンシ（混んでいるときの Ping）を見ます。Apple サポートによると、Mac では macOS Monterey 以降でターミナルに networkQuality と入力すると、複数の機器やアプリが回線を共有しているときの応答性を、RPM（1分あたりの往復の回数）と「低い・中間・高い」の3段階で表示します。

ジッターの見方

ジッターは、Ping が毎回どれだけ変わるかです。 往復20ms に片道 ±3ms のばらつきを足した線で、ping と iperf3 の UDP（音声や映像の通信に近い、確認を待たずに送る方式）を測りました。

$ ping -c 20 -i 0.2 10.83.2.2
20 packets transmitted, 20 received, 0% packet loss, time 3814ms
rtt min/avg/max/mdev = 12.423/20.736/26.970/3.922 ms

$ iperf3 -c 10.83.2.2 -p 38301 -u -b 5M -t 5 -R
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-5.00   sec  2.98 MBytes  5.00 Mbits/sec  2.021 ms  0/2157 (0%)  receiver

平均は 20.7ms でも、最小 12.4ms と最大 27.0ms で約15ms の差がありました。ping の mdev、iperf3 の Jitter が、ばらつきの大きさの目安です。

MbpsとMB/sの違い（8で割る）

この節では、速度テストの Mbps と、ダウンロード画面の MB/s を換算する方法と、実際に出る速さの上限が分かります。

Mbps は「1秒に何メガビット」、MB/s は「1秒に何メガバイト」で、1バイト＝8ビットなので、Mbps を8で割ると MB/s になります。 回線や速度テストは Mbps、ブラウザやゲーム機のダウンロード画面は MB/s で表示されることが多く、同じ速さでも数字が8倍違って見えます。

curl でファイルを取得すると、速さはバイト毎秒で表示されます。100Mbps・往復20ms・ロス 0.1% の線で 50MB を1本の接続で取得した実物です。

curl -s -o /dev/null -w 'HTTP %{http_code}  受信 %{size_download} バイト  時間 %{time_total}s  速さ %{speed_download} バイト/秒\n' http://10.83.2.2:38302/50m

HTTP 200  受信 52428800 バイト  時間 16.853093s  速さ 3110930 バイト/秒

3,110,930 バイト/秒 × 8 ＝ 約 24.9Mbps です。MB/s にすると約 3.1MB/s で、同じ速さを表しています。

契約の速さがそのまま出ない理由（オーバーヘッド）

運べるデータのすべてがファイルの中身ではありません。 パケット1つ（1,500バイト）のうち、IP と TCP の見出し（タイムスタンプ付きで52バイト）を除いた 1,448バイトが中身なので、中身の速さの上限は 1,448÷1,500＝約96.5% です。上限 100Mbps の線で1本の接続を流すと、iperf3 で 96.9Mbps、curl で 96.3Mbps（12.04MB/s）になり、この計算に近い値でした。有線 LAN では、さらに1つのパケットにつき前置き・宛先・誤り検出・すき間の 38バイトが加わるので、1Gbps の LAN の中身の速さは計算上 1,448÷1,538×1,000＝約941Mbps が上限です。

用途別の速度の目安（動画・Web会議・ゲーム・ファイル）

この節では、使い方ごとに何 Mbps あればよいかを、各サービスの公式の推奨値で確かめられます。

目安は、各サービスが公式に出している推奨値で決めるのが確実です。 値は2026年10月23日時点の各社の公式ヘルプのものです。

• YouTube はほかに 720p で 2.5Mbps、480p で 1.1Mbps、360p で 0.7Mbps を、再生を続けるのに推奨される速さとしています。
• Zoom は 1対1 の 720p で上り下り 1.2Mbps、グループの 720p で上り 2.6Mbps・下り 1.8Mbps、音声だけなら 60〜80kbps としています。
• Teams の値は Microsoft Learn の表の「推奨」（会議のビデオ、上り/下り 2,500/4,000kbps）で、帯域が足りないときは映像より音声の品質を優先すると説明しています。
• ゲームは、速さより Ping とジッターが効きます。NTT東日本の解説では、Ping 15ms 以下を「非常に速い」、16〜30ms を「速い」としています（詳しくは関連記事「レイテンシとは｜意味・目安・測り方を遅延0〜300msの実測で解説」）。ゲームの本体や追加データのダウンロードは、次の表のとおり下りの速さで時間が決まります。

大きなファイルにかかる時間（計算）

ゲームのダウンロードやバックアップは、大きさ（GB）×8÷速さ（Mbps）で時間が出ます。1GB を 10億バイトとして計算しました。

実際には前の節のオーバーヘッドと、相手のサーバーの速さで、これより少し長くかかります。家族で同時に使うときは、使う人の推奨値を足した値が目安になります。

スピードテストの結果がサイトごとに違う理由（実測）

この節では、同じ回線でもテストによって結果が変わる理由を、接続の数と遅延を変えた実測で確かめられます。

結果がずれる主な理由は、「接続の数」「測定サーバーまでの遅延」「サーバーの場所」「測る時間」の4つです。 1台の Linux の中に PC・ルーター・測定サーバーを作り、ルーターとサーバーの間を「上限 100Mbps の回線」にして、遅延とパケットロス（途中で消えるパケット）を変えながら、iperf3 で下りの速さを測りました。

flowchart TD
    PC[PC<br>10.83.1.2] --- RT[ルーター<br>10.83.1.1]
    RT ---|上限100Mbps<br>遅延とロスを足す線| SV[測定サーバー<br>iperf3・HTTP]

回線のまねの作り方

このカーネルには遅延を足す tc netem が無いため、ルーターとサーバーにそれぞれ TUN デバイス（パケットをプログラムで受け渡す仮想のネットワーク装置）を作り、その間を Python の中継でつなぎました。中継は、パケットを速さの上限に合わせて送り出し、待ち行列があふれたら捨て、決めた割合でパケットを落とし、片道の遅延の分だけ待ってから渡します。

"""2つの名前空間の TUN をつなぐ回線のまね（要点だけ）。速さの上限・遅延・待ち行列・ロスを付ける"""
def reader():                                   # 片方の TUN から読み、もう片方へ渡す予定を立てる
    while True:
        pkt = os.read(src, 65535); now = time.monotonic()
        if a.loss and random.random() < a.loss / 100:
            continue                            # 決めた割合で落とす（パケットロス）
        if a.rate > 0:
            start = max(now, st["free"])        # 線が空くのを待つ
            if start - now > a.queue / 1000:
                continue                        # 待ち行列があふれたら捨てる
            st["free"] = start + len(pkt) * 8 / (a.rate * 1e6); now = st["free"]
        due = max(now + one_way, st["last"]); st["last"] = due   # 片道の遅延を足す
        with cv:
            q.append((due, pkt)); cv.notify()  # 別のスレッドが due の時刻に書き込む

for n in c r s; do ip netns add s383-$n; ip -n s383-$n link set lo up; done
ip link add c0 netns s383-c type veth peer name r0 netns s383-r          # PC とルーター
ip -n s383-r tuntap add dev tr mode tun; ip -n s383-s tuntap add dev ts mode tun
ip -n s383-r addr add 10.83.2.1/24 dev tr; ip -n s383-s addr add 10.83.2.2/24 dev ts
# アドレス・up・デフォルトゲートウェイの設定は略
ip netns exec s383-r sysctl -qw net.ipv4.ip_forward=1                    # ルーターの中だけ転送を有効に
python3 line.py --rate 100 --rtt 20 --queue 50 --loss 0.1 &
ip netns exec s383-s iperf3 -s -p 38301 -D                               # 測定サーバー
ip netns exec s383-c iperf3 -c 10.83.2.2 -p 38301 -R -t 8 -O 1 -P 4 -C cubic

中継そのものは、上限を付けないときに 668Mbps まで流せたので、100Mbps の線のまねには余裕があります。

接続の数と遅延で速さが変わる（iperf3）

ロスの無い線では、接続1本でも 8本でも、どの遅延でも 96Mbps 前後と変わりませんでした（往復200ms の1本だけ 88.1Mbps）。 そこで、Wi-Fi の電波の乱れや長い道のりで起きるような、0.1%（1,000個に1個）のパケットロスを足しました。各条件を3回測り、中央値を載せます。

• 同じ回線でも、1本の接続のテストと 8本の接続のテストで、22.9Mbps と 96.7Mbps と4倍以上の差が出ました。 Google（1本）と Fast.com・Ookla（複数）で結果が違うのは、この差です。
• 遅延が大きいほど、1本の速さは下がりました。 往復0ms ではロスがあっても 95.7Mbps でしたが、20ms で 22.9Mbps、100ms で 11.5Mbps でした。TCP は、パケットが消えると送る量を減らし、相手からの確認（ACK）が返るたびに少しずつ戻すので、往復が長いほど戻るのに時間がかかります。100ms と 200ms は3回の値のばらつきが大きく（1本で 10.7〜31.8Mbps）、この2つの差ははっきりしませんでした。
• 接続を増やすと、合計は上限に近づきました。 1本が速さを落としている間も、ほかの接続が送り続けるためです。

1回の結果の実物です。1本では1秒ごとの速さが 9〜20Mbps で揺れ、Retr（送り直したパケットの数）が出ています。4本では1本ずつは 18〜27Mbps でも、[SUM]（合計）は 91.4Mbps でした。

$ iperf3 -c 10.83.2.2 -p 38301 -R -t 5 -C cubic
Reverse mode, remote host 10.83.2.2 is sending
[  5] local 10.83.1.2 port 48306 connected to 10.83.2.2 port 38301
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  1.12 MBytes  9.43 Mbits/sec
[  5]   1.00-2.00   sec  1.50 MBytes  12.6 Mbits/sec
[  5]   2.00-3.00   sec  1.12 MBytes  9.44 Mbits/sec
[  5]   3.00-4.00   sec  1.50 MBytes  12.6 Mbits/sec
[  5]   4.00-5.00   sec  2.38 MBytes  19.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-5.02   sec  7.75 MBytes  12.9 Mbits/sec   11             sender
[  5]   0.00-5.00   sec  7.62 MBytes  12.8 Mbits/sec                  receiver

$ iperf3 -c 10.83.2.2 -p 38301 -R -t 5 -P 4 -C cubic
[  5]   0.00-5.00   sec  13.5 MBytes  22.6 Mbits/sec                  receiver
[  7]   0.00-5.00   sec  15.9 MBytes  26.6 Mbits/sec                  receiver
[  9]   0.00-5.00   sec  14.2 MBytes  23.9 Mbits/sec                  receiver
[ 11]   0.00-5.00   sec  10.9 MBytes  18.2 Mbits/sec                  receiver
[SUM]   0.00-5.02   sec  57.1 MBytes  95.4 Mbits/sec   89             sender
[SUM]   0.00-5.00   sec  54.5 MBytes  91.4 Mbits/sec                  receiver

ブラウザのダウンロードに近い形（curl で HTTP を分割して取得）

速度テストのサイトは、ブラウザから HTTP でデータを取得します。Range（ファイルの一部だけを頼む指定）に対応した HTTP サーバーから 50MB のファイルを、1本・4本・8本に分けて同時に取得しました。

#!/bin/bash
# 50MB のファイルを N 本の接続に分けて同時に取得し、合計の速さを出す
N=$1; SIZE=52428800; PART=$((SIZE / N)); URL=http://10.83.2.2:38302/50m
start=$(date +%s.%N)
for i in $(seq 0 $((N - 1))); do
  s=$((i * PART)); e=$((i == N - 1 ? SIZE - 1 : s + PART - 1))
  curl -s -r $s-$e -o /dev/null $URL &
done
wait
end=$(date +%s.%N)
python3 -c "t=$end-$start; print(f'接続 $N 本  時間 {t:.2f}s  速さ {$SIZE*8/t/1e6:.1f} Mbps（{$SIZE/t/1e6:.2f} MB/s）')"

HTTP でも iperf3 と同じ傾向で、分けて取得するほど速くなりました。 往復100ms で 8本でも 33.6Mbps にとどまったのは、50MB を8つに分けると1本が約6.5MB と小さく、TCP が送る量を増やしきる前に取得が終わるためです。Fast.com の資料が、TCP の立ち上がりの部分を計算から外し、速さが落ち着くまで測ると説明しているのは、この影響を除くためです。

受信の窓が小さいと、遅延で上限が決まる

TCP は、相手から確認が返る前に送れる量（ウィンドウ）に上限があります。iperf3 の -w 128K でソケットのバッファを小さくすると、ロスが無くても遅延で速さが決まりました。

1本の速さは、およそ「1往復で送れる量 ÷ 往復の時間」になります。往復が5倍になると、1本の速さは約5分の1になりました。遠い国のサーバーとの速度テストや、遅延の大きい回線で1本の値が低く出るのはこのためです。

輻輳制御の方式でも変わる

ここまでの iperf3 は、TCP の輻輳制御（混雑に合わせて送る量を決める方式）を CUBIC にしていました。同じ「往復100ms・ロス 0.1%」の線で、方式を BBR にすると、1本で 95.3Mbps、4本で 97.0Mbps になりました。BBR は、パケットが消えたことよりも、測った帯域と往復時間をもとに送る量を決める方式です。測定サーバー側の TCP の設定でも結果が変わるので、テストの値はサービスどうしで比べず、同じテストの値どうしで比べます。

スピードテストを正しく測るコツ（有線・時間帯・VPN）

この節では、測り直すたびに値がぶれないようにするための条件のそろえ方が分かります。

• 1ほかの通信を止める動画・クラウドの同期・OS の更新が流れていると、その分だけ下りが減り、Ping も増える（実測で 20ms→38〜188ms）
• 2有線 LAN でも測るWi-Fi と有線の両方で測ると、Wi-Fi の区間が遅いのか、その先が遅いのかを分けられる
• 3VPN を切って測るVPN を通すと、測定サーバーは VPN の出口の場所を基準に選ばれ、暗号化と遠回りの分も加わる
• 4時間帯を変えて何回か測る夜の混む時間と朝で比べる。1回の値ではなく、3回ほどの真ん中の値で見る
• 5同じテストで比べる接続の数とサーバーが違うと、同じ回線でも4倍以上の差が出た。前回と同じテストの値と比べる
• 6上限のあるテストに気をつけるGoogle の速度テストは 700Mbps までしか測れない。1Gbps 以上の回線は別のテストでも測る

VPN については、Ookla が IP アドレスの位置から近いサーバーを選ぶ（前述の論文）ため、VPN の出口が遠いと、遠いサーバーで測ることになります。M-Lab も、経路の変化で、前日より遠いサーバーに向けて測ることがあると説明しています。スマホは、Wi-Fi とモバイル回線のどちらで測っているかを確かめてから測ります。Google 検索ヘルプによると、モバイル回線で測ると通信料がかかることがあります。

遅いときの切り分け（PC・Wi-Fi・ルーター・回線）

この節では、速度テストの結果が遅いときに、原因が PC・Wi-Fi・ルーター・回線のどこにあるかを順に絞り込めます。

flowchart TD
    A[遅い] --> B{ほかの機器も?}
    B -->|いいえ| C[その機器]
    B -->|はい| D{有線なら速い?}
    D -->|はい| E[Wi-Fi]
    D -->|いいえ| F[ルーター・回線]

1. 1ほかの機器でも測る1台だけ遅ければ、その機器（OS の更新中・VPN・セキュリティソフト・以前の Wi-Fi の規格）を疑う
2. 2有線 LAN と Wi-Fi で比べる有線だけ速ければ Wi-Fi の区間。ルーターに近づく、5GHz 帯や 6GHz 帯に切り替える
3. 3ルーターまでの Ping を測る家の中のルーター（デフォルトゲートウェイ）まででもう遅いか、ばらつくかを見る
4. 4機器を再起動して測り直すルーター・ONU（光回線の終端装置）を再起動し、同じテストで比べる
5. 5回線・プロバイダーを確かめる有線でも遅く、時間帯で大きく変わるなら回線側。障害情報を見て、測った値を添えて問い合わせる

家の中が原因か外が原因かは、ルーター（デフォルトゲートウェイ）への ping で分かります。 ルーターまでで既に遅かったりばらついたりすれば、Wi-Fi や LAN の中が原因です。ルーターのアドレスの調べ方は関連記事「デフォルトゲートウェイとは｜調べ方・設定・決め方をLinuxで実演」で、ネットワークの設定を見る ipconfig の使い方は関連記事「ipconfigの使い方とMTUとは｜/all・/flushdnsとMTUの実例」で、ルーターより先のどこで遅れているかは関連記事「traceroute・tracertの使い方｜見方と * ・!Hの意味を実例で」で扱っています。

コマンドで回線速度を測る（iperf3・curl・Speedtest CLI）

この節では、ブラウザを使わずに速さを測る方法と、家の中の区間だけを測る方法が分かります。

iperf3：2台の間の速さを測る

iperf3 は、自分で用意した2台の間で、どれだけの速さが出るかを測るツールです。 ESnet（米国のエネルギー省の研究ネットワーク）が中心に開発していて、公式のリポジトリは、正式に対応するのは Ubuntu Linux・FreeBSD・macOS としています。また、iperf2 と iperf3 は互いに通信できない別のツールです。片方を -s（サーバー）、もう片方を -c（クライアント）で起動します。

# 1台目（例：有線でつないだ PC・NAS）
iperf3 -s -p 5201
# 2台目（例：Wi-Fi のノート PC）から測る
iperf3 -c 192.168.1.10 -p 5201          # 上り：クライアント → サーバー
iperf3 -c 192.168.1.10 -p 5201 -R       # 下り：サーバー → クライアント
iperf3 -c 192.168.1.10 -p 5201 -R -P 4  # 4本の接続で同時に

Wi-Fi の PC と、有線でつないだ機器の間で iperf3 を測ると、インターネットとは関係なく「Wi-Fi の区間の速さ」だけが分かります。 速度テストが遅いとき、この値が速ければ原因はルーターより先、遅ければ Wi-Fi の区間です。iperf3 のサーバーを、インターネットから届く場所で開けたままにしない（測り終えたら止める）ようにします。

curl：あるサーバーからの取得の速さ

curl の -w で %{speed_download}（バイト毎秒）と %{time_total} を出すと、特定のサーバーからの取得の速さが分かります。8を掛けると bps です（前の節の実物を参照）。自分の Web サイトや API の配信の速さを、ブラウザを使わずに繰り返し測れます。curl のオプションの全体は、関連記事「curlコマンドの使い方｜よく使うオプションとAPIの確認方法」で扱っています。

Speedtest CLI（Ookla）と networkQuality（Mac）

Ookla は、Speedtest をコマンドで動かす Speedtest CLI を出しています。Ookla の公式 Homebrew リポジトリ（teamookla/homebrew-speedtest）の定義では、版は 1.2.0、入れると speedtest というコマンドになり、案内先は speedtest.net の CLI のページです。入れ方・オプション・利用条件は、この公式ページで確かめてから使います。Mac では、前の節の networkQuality を標準で使えます（macOS Monterey 以降）。

よくある質問

Q. Google のスピードテストはどこにありますか？ A. Google で「スピードテスト」「internet speed test」などと検索すると、検索結果に速度テストの枠が出ます。「速度テストを実行」を押すと、約30秒で下り・上り・待ち時間が出ます。提供は Google と M-Lab の提携です。

Q. Fast.com とは何ですか？ A. Netflix が出している速度テストです。主に下りの速さを測り、「詳細を表示」で上りとレイテンシ（アンロード済み・ロード済み）が出ます。Netflix の配信用のサーバーとの間で測ります。

Q. スピードテストの結果がサイトごとに違うのはなぜですか？ A. 接続の数（Google は1本、Fast.com・Ookla は複数）、測定サーバーの場所、測る時間が違うためです。実測では、往復20ms・ロス 0.1% の同じ回線で、1本は 22.9Mbps、8本は 96.7Mbps でした。

Q. スピードテストは正確ですか？ A. 「そのテストのサーバーまでの、その時の速さ」としては正確ですが、ほかのサーバー（動画サイトやゲームのサーバー）でも同じ速さが出るとは限りません。同じテストで、条件をそろえて何回か測った値で比べます。

Q. 何 Mbps あれば快適ですか？ A. 公式の推奨値では、Netflix の 4K が 15Mbps 以上、YouTube の 4K が 20Mbps、Zoom のグループ 1080p が上り 3.8Mbps・下り 3.0Mbps です。同時に使う人の分を足して考えます。

Q. 下りと上りの違いは何ですか？ A. 下り（ダウンロード）は受け取る速さ、上り（アップロード）は送る速さです。動画を見るのは下り、Web 会議で自分の映像を送ったり写真を投稿したりするのは上りが効きます。

Q. Ping は何 ms なら速いですか？ A. NTT東日本の解説では、15ms 以下を非常に速い、16〜30ms を速いとしています。みんそくの直近3か月の平均（2026年10月23日時点の表示）は、光回線で 18.9ms でした。

Q. Mbps と MB/s の違いは何ですか？ A. Mbps は1秒に何メガビット、MB/s は1秒に何メガバイトです。8で割ると MB/s になり、100Mbps は 12.5MB/s です。

Q. スピードテストでデータ通信量はどれくらい使いますか？ A. Google 検索ヘルプによると、Google の速度テストは米国外で約 4.4MB を使います。複数の接続で速さが落ち着くまで測るテストは、回線が速いほど多くのデータを使います。

Q. 1Gbps の回線なのに、スピードテストで数百 Mbps しか出ません。 A. 契約の値は最大値で、Wi-Fi・LAN の機器・測定サーバーまでの道のりで下がります。Google の速度テストは 700Mbps までしか測れません。1Gbps の有線 LAN でも、中身の速さは計算上約 941Mbps が上限です。

Q. VPN を使っているとスピードテストはどうなりますか？ A. VPN の出口を基準に測定サーバーが選ばれ、暗号化と遠回りの分も加わるので、下りが下がり Ping が増えることがあります。回線そのものの速さは VPN を切って測ります。

まとめ

• スピードテストは、Google で「スピードテスト」と検索して「速度テストを実行」を押すか、Fast.com を開くと約30秒で測れる。
• 見るのは、下り・上り（Mbps、大きいほどよい）と Ping・ジッター（ms、小さいほどよい）。Mbps を8で割ると MB/s。
• Google（M-Lab）は1本の接続・上限 700Mbps、Fast.com は Netflix のサーバーと複数の接続、Ookla は近い10台から遅延の最も小さいサーバーと並列の接続で測る。
• 往復20ms・ロス 0.1% の同じ回線で、接続1本は 22.9Mbps、8本は 96.7Mbps。遅延が大きいほど1本の速さは下がった。
• 混んでいるときの Ping（ロード済みレイテンシ）は、待ち行列が大きいと 20ms から 188ms に増えた。通話が途切れるときはこの値を見る。
• 目安は各社の公式の推奨値（4K 動画は 15〜20Mbps、Web 会議は数 Mbps）で決める。
• 遅いときは、ほかの機器 → 有線と Wi-Fi → ルーターまでの Ping → 再起動 → 回線、の順に絞り込む。

次に読むとよい記事です。Ping（レイテンシ）が何で決まり、どう下げるかは関連記事「レイテンシとは｜意味・目安・測り方を遅延0〜300msの実測で解説」で、自分の回線の外向きの IP アドレスの確かめ方と、VPN・CGNAT で見え方が変わる理由は関連記事「グローバルIPの確認方法｜コマンド・プライベートIPとの違いとNATを実演」で扱っています。

参考・出典

確認日はいずれも 2026年10月23日です。

• Google 検索ヘルプ「インターネットの速度をテストする」：https://support.google.com/websearch/answer/6283840?hl=ja
• Measurement Lab「NDT (Network Diagnostic Tool)」：https://www.measurementlab.net/tests/ndt/
• Measurement Lab「Why are my M-Lab results different from other speed tests?」：https://support.measurementlab.net/help/en-us/6-measurement-services/11-why-are-my-m-lab-results-different-from-other-speed-tests
• Measurement Lab「How fast is my Internet? Speed Tests, Accuracy, NDT & M-Lab」：https://www.measurementlab.net/blog/speed-tests-accuracy/
• FAST.com：https://fast.com/ja/
• Netflix「FAST.com now measures latency and upload speed」：https://about.netflix.com/en/news/fast-com-now-measures-latency-and-upload-speed
• Sergey Fedorov（Netflix）「FAST.com」RIPE 74 発表資料：https://ripe74.ripe.net/presentations/105-Ripe74-Fast.com-1.pdf
• Zhang・Shen・Mok「Empirical Characterization of Ookla's Speed Test Platform」（IEEE、2024年）：https://par.nsf.gov/servlets/purl/10525582
• Ookla 公式 Homebrew リポジトリ「teamookla/homebrew-speedtest」：https://github.com/teamookla/homebrew-speedtest
• みんなのネット回線速度（みんそく）：https://minsoku.net/
• Netflix ヘルプセンター「Netflix推奨インターネット接続速度」：https://help.netflix.com/ja/node/306
• YouTube ヘルプ「YouTube のシステム要件と対応デバイス」：https://support.google.com/youtube/answer/78358?hl=ja
• Zoom サポート「Zoom system requirements: Windows, macOS, Linux」：https://support.zoom.com/hc/ja/article?id=zm_kb&sysparm_article=KB0060748
• Microsoft Learn「Teams 用に組織のネットワークを準備する」：https://learn.microsoft.com/ja-jp/microsoftteams/prepare-network
• PlayStation「Remote Play」：https://www.playstation.com/en-si/remote-play/
• NTT東日本「レイテンシとは？」：https://business.ntt-east.co.jp/column/service/flets-hikari/latency.html
• Apple サポート「Apple ネットワーク応答性テストで Wi-Fi をテストする」：https://support.apple.com/ja-jp/101942
• ESnet「iperf」（GitHub）：https://github.com/esnet/iperf

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。