Speedtestでは5Gbpsなのにダウンロードが遅い理由｜CDN・CPU・SSD・単一通信の上限

PRが含まれています

最終更新日：2026年9月4日

Speedtestでは下り5Gbps。ところがゲームや大容量ファイルは100MB/s前後しか出ず、100GBのダウンロードに十数分かかる。この2つの結果は、必ずしも矛盾しません。

Speedtestが測るのは、選ばれた測定サーバーまでの「その条件で使えた通信能力」です。実際のダウンロードには、配信元のCDN、1本の通信が伸びる限界、CPUによる復号・検査・展開、SSDへの書き込みまで加わります。どこか1か所が625MB/sを処理できなければ、5Gbpsには届きません。

本記事では「サーバーが混んでいる」「PCが遅い」といった一般論で終わらせず、5Gbpsを基準に必要な処理量を計算します。最後に、測定結果の組み合わせから原因を絞る診断表も用意しました。

結論：5Gbpsは回線の合格通知ではなく、特定経路で出た集約速度

Speedtestの5Gbpsは「その時点で、PCから選択された測定サーバーまで、測定方式が合計5Gbpsを引き出せた」ことを示します。

その数値だけでは、別会社のCDN、海外サーバー、SteamやEpic Games Launcher、ブラウザーの1ファイル転送でも5Gbps出るとは判断できません。実ダウンロードの上限は、概念的には次の最小値で決まります。

実効速度 ≦ min（配信側の割当帯域、経路の空き帯域、単一通信の上限、CPU処理能力、保存先の書き込み能力÷展開倍率）

これは診断用に単純化した式です。実際には各処理が並行し、メモリーキャッシュや待ち行列も挟まります。それでも「回線だけを見ても答えが出ない」理由を整理するには役立ちます。

複数通信を合計したSpeedtestは5Gbpsでも、1本の通信は1Gbps前後で止まることがある
CDNや配信サービスが、利用者・接続・地域ごとに速度を制御することがある
CPU全体は低負荷に見えても、1つの論理プロセッサーだけ100％になることがある
625MB/sで受信しても、解凍後に1,000MB/s超を書き込めなければ途中で待たされる
「ダウンロード完了」と「展開・検証・インストール完了」は別の時刻になる

検索上位記事との差：本記事で追加した5つの独自分析

検索上位で見つかった自サイト以外の解説記事10ページを確認し、一般的な原因一覧では不足しやすい「5Gbps環境の定量診断」を追加しました。

2026年9月4日に「回線速度は速いのにダウンロードが遅い」などの語句で見つかった解説記事を確認しました。検索順位は地域、履歴、更新時期によって変わるため、ここでの比較は固定順位の主張ではなく、当日の内容調査です。

比較項目	上位記事で多かった説明	本記事で加えた独自要素
サーバー・端末・回線	混雑、端末性能、ルーター、Wi-Fiなどの原因一覧	Multi・Single・実ダウンロードの組み合わせで原因を分ける診断表
単一通信	サーバー側が遅い、同時利用で遅いという説明	5Gbpsを維持するために必要な帯域遅延積をRTT別に独自計算
CPU	CPUスペック不足という説明	16論理プロセッサー中1つの飽和が全体表示では約6.25％に見える点を計算
SSD・HDD	HDDはSSDより遅いという比較	圧縮データの展開倍率を入れ、「書き込み速度÷展開倍率」で受信上限を算出
症状の読み方	設定変更や再起動などの対処法	平らな頭打ち、急落、周期的な0MB/sなど、速度推移の形から原因候補を読む
10ギガ回線の価値	1回のダウンロード速度で評価	異なる配信元を同時利用したときの合計速度で「1件の速さ」と「回線容量」を分離

調査対象には、NTT東日本、NURO 光、TOKAIケーブルネットワーク、Baycom、povo、NTTドコモビジネス、ひかりハック、セキュアSAMBA、THE PORT、プラネックスの公開記事を含めました。少なくとも確認時点では、上表の「帯域遅延積の数値表」「CPU全体表示の逆算」「展開倍率を含む保存上限」の3点を一体で計算した記事は見当たりませんでした。

Speedtestの5Gbpsが証明すること、証明しないこと

5Gbpsという結果は有力な手掛かりですが、インターネット上の全サービスへ5Gbpsで接続できる保証ではありません。

Ooklaの公開説明では、Speedtestは主にTCPを使い、ダウンロード時に複数の接続を確立し、測定中の速度に応じてチャンクやバッファーを調整します。また、近隣候補へ応答時間を測り、ネットワーク上で近いサーバーを選ぶ仕組みも説明されています。

ただし、この説明ページは2012年付です。現行の全アプリ、全OS、全測定モードの実装が当時の記述と同一だと決めつけるべきではありません。ここで重要なのは、高い数値を出す測定と、普段使う1件のダウンロードでは、接続先とデータの流し方が異なり得るという点です。

複数通信の合計値は、1本の通信より伸びやすい

複数の通信を同時に使えば、1本ごとの上限を足し合わせて回線全体を埋めやすくなります。

例えば、1本あたり1Gbps付近で止まる条件でも、独立した通信を5本使えれば、単純合計は5Gbpsに近づきます。一方、ダウンロードアプリが1本または少数の接続しか使わなければ、Speedtestの合計値には届きません。

ESnetのiperf3公式文書でも、-Pは並列ストリーム数を指定する機能とされ、バージョン3.16以降はストリームごとに別スレッドを使います。CPUが上限になっている環境では、複数ストリームにより合計速度が上がる場合があると説明されています。

測定方法が違えば、正しい結果が2つ存在する

最大帯域を測るテストと、実用時の品質を測るテストは、目的が違うため同じ数値でなくても正常です。

測定方法	主に分かること	分からないこと・注意点
SpeedtestのMulti	近い測定先へ複数通信で出せる集約速度	特定サービスの1ファイル速度、保存・展開時間
SpeedtestのSingle（選べる場合）	1接続に近い条件での伸び方	実際のCDNやアプリ固有の制御
Cloudflare Speed Test	Cloudflare網への転送品質、遅延、ジッター、損失	回線を必ず最大まで飽和させるテストではない
実際のサービスからの大容量ダウンロード	利用したいサービスでの待ち時間	回線、CDN、アプリ、CPU、保存先のどれが原因かは単独では分からない
宅内iperf3	LAN、NIC、OS、PC間の通信能力	インターネット回線や外部CDNの性能

Cloudflareは2025年の技術解説で、サーバーの場所、ストリーム数、輻輳制御、結果の集計方法によって速度テストの値が変わると説明しています。同社のテストは最大帯域の飽和を狙わず、複数サイズのデータブロックで現実的な品質を調べる設計です。OoklaとCloudflareの数値が違っても、片方が故障しているとは限りません。

5Gbpsをダウンロード表示へ換算すると625MB/s

下り5Gbpsを使い切るには、ダウンロードアプリ、CPU、保存先が毎秒625MBを途切れず処理する必要があります。

通信速度はbit、アプリの転送速度はByteで表示されることが多く、1Byteは8bitです。したがって、10進表記なら次の計算になります。

5,000Mbps ÷ 8 ＝ 625MB/s

2進表記へ直すと約596MiB/sです。アプリが「MB/s」と表示しながら内部ではMiB/s相当を使う場合もあるため、数％の差だけで異常と判断しないでください。

独自計算：100GBの理想時間と5Gbps利用率

100GBを20分で受信した場合の平均は約667Mbpsで、5Gbpsに対する利用率は約13.3％です。

次の表は100GB＝100,000MBとして、通信以外の待ち時間とプロトコルのオーバーヘッドを除いた理想値です。

アプリの平均表示	通信速度換算	5Gbps利用率	100GBの理想時間
50MB/s	400Mbps	8％	33分20秒
100MB/s	800Mbps	16％	16分40秒
200MB/s	1.6Gbps	32％	8分20秒
300MB/s	2.4Gbps	48％	5分33秒
500MB/s	4.0Gbps	80％	3分20秒
625MB/s	5.0Gbps	100％	2分40秒

実測値は、アプリの瞬間表示より「転送されたバイト数÷経過秒数」で求めるほうが比較しやすくなります。

実効Mbps ＝転送バイト数 × 8 ÷ 経過秒数 ÷ 1,000,000
5Gbps利用率（％）＝実効Mbps ÷ 5,000 × 100

ゲーム更新では、進捗表示が圧縮後の受信量ではなく展開後のサイズやインストール工程を含むことがあります。可能ならOSのネットワークカウンターと、アプリのディスク読み書き表示も一緒に記録してください。

CDNが違えば、同じ自宅回線でも速度は変わる

Speedtestの相手と実際の配信元は別なので、通る経路、距離、混雑、サーバーの割当帯域も別です。

CDNはコンテンツを利用者に近い拠点から配信する仕組みです。しかし、「同じサービスなら常に同じCDN拠点へつながる」「近い拠点なら必ず高速」という意味ではありません。DNSやAnycastによる振り分け、ISPとの接続、拠点の混雑、コンテンツの配置状況によって経路は変わります。

また、配信事業者は公平性、コスト、障害対策のため、1接続、1利用者、1IPアドレス、1地域などの単位で速度を制御できます。具体的な制御方法はサービスごとに異なり、公開されない場合もあります。

キャッシュヒットとキャッシュミスでは、裏側の経路が違う

近くのCDN拠点に目的のデータがなければ、オリジンサーバーからの取得が加わり、遠い区間やオリジン側の上限が表面化することがあります。

CDNにデータがあるキャッシュヒットでは、利用者に近い拠点から返せます。キャッシュミスでは、CDNがオリジンへ取りに行く処理が必要です。必ず遅くなるとは限りませんが、オリジンまでのRTT、オリジンの送信能力、CDNとオリジンの間の混雑が追加の候補になります。

この違いは、同じURLでも時間帯や初回・再試行で速度が変わる理由の一つです。ただし、再ダウンロードで速くなっただけではキャッシュヒットを証明できません。混雑の変化やOS側のキャッシュもあるためです。

過去事例：5Gbps回線でも配信元を変えると結果が変わった

プラネックスの公開検証では、同じ約2GBファイルでも、さくらインターネットの「コンテンツブースト」利用時にダウンロード速度が大きく改善しました。

同社はauひかりホーム5ギガを使い、1GbE、2.5GbE、実質5GbE、Wi-Fi 5を比較しています。Speedtestでは1GbEが約940Mbps、2.5GbEは2Gbps超でしたが、通常のさくらインターネット上のファイルでは1GbE・2.5GbE・5GbEの差が小さい結果でした。

一方、CDN系の「コンテンツブースト」を有効にすると、1GbEでは約3倍、Wi-Fi 5・2.5GbE・5GbEでは約4倍へ改善したと報告されています。さらにギガファイル便、Dropbox、OneDriveでは、2.5GbEから実質5GbEへ上げても目立つ優位が出ないケースがありました。

これは「5Gbps回線は無意味」という証明ではありません。送り手が変われば、宅内LANを高速化したときの伸び方も変わるという事例です。測定地点、時間、サービス仕様が異なれば再現結果も変わるため、現在の全サービスへ一般化はできません。

単一通信にはRTT・ウィンドウ・損失による上限がある

5Gbpsの1本通信では、相手から確認応答が戻るまでの間に、数MBから数十MBのデータを飛行中に保つ必要があります。

TCPで高速かつ遠距離の通信を考えるときは、帯域遅延積（Bandwidth-Delay Product、BDP）が役立ちます。RFC 7323も、帯域と遅延の積が大きい経路では、受信ウィンドウがTCP接続の最大スループットを制限し得ると説明しています。

独自計算：5Gbpsを維持するための飛行中データ量

RTTが50msなら、5Gbpsを埋めるために必要な飛行中データ量は約31.25MBです。

必要な飛行中データ量＝ 5,000,000,000bit/s ÷ 8 × RTT（秒）

RTT	5Gbpsを埋めるBDP	16MBの有効ウィンドウしか使えない場合の理論上限
5ms	3.125MB	25.6Gbps
10ms	6.25MB	12.8Gbps
20ms	12.5MB	6.4Gbps
50ms	31.25MB	2.56Gbps
100ms	62.5MB	1.28Gbps

表の右列は、16MBを10進表記として16MB × 8 ÷ RTTで求めた単純なウィンドウ上限です。実環境の速度保証ではありません。現在のOSはウィンドウスケーリングや自動調整を備え、送信側の輻輳ウィンドウ、アプリ側の読み出し、フロー制御なども影響します。

それでも、近距離の測定サーバーへ複数通信を張るSpeedtestは5Gbps、RTTが大きい遠方CDNへの単一通信は1～2Gbps、という差が起こる仕組みを理解できます。

パケット損失とスロースタートはHTTP/3でも消えない

HTTP/3を使っていても輻輳制御は残るため、「QUICなら単一通信の上限がなくなる」という理解は誤りです。

TCPもQUICも、通信開始直後から無制限に送るわけではありません。確認応答を得ながら送信量を増やし、損失やECNによる混雑通知を受けると回復処理へ移ります。RFC 9002で示されるQUICのNewRenoも、スロースタートから始まり、損失時に輻輳ウィンドウを減らします。

HTTP/3には接続確立やストリーム間干渉の改善が期待できますが、配信側の速度制限、CPU、SSD、遠距離経路の物理的なRTTを消す機能ではありません。小さなファイルは速度が上がり切る前に終わるため、100MB程度のファイルで5Gbps回線を判定するのも不向きです。

CPU全体が30％でも、一部のコアは上限に達している

CPU使用率の全体表示が低いことは、通信処理に使われるコアに余裕がある証拠にはなりません。

ダウンロード中のPCでは、TLSの復号、整合性検証、セキュリティ検査、解凍、ファイルシステム処理、アプリの画面更新が動きます。これらが均等に全コアへ分散するとは限りません。

独自計算：16論理プロセッサー中1つの飽和は全体で約6.25％

16論理プロセッサーのPCで1つだけ100％になっても、ほかが休んでいれば全体表示への寄与は約6.25％です。

100％ ÷ 16 ＝ 6.25％

4つが100％なら寄与は約25％です。したがって、タスクマネージャーのCPU全体が30％でも、通信や展開に使う4スレッドが限界という状況はあり得ます。Windowsでは、タスクマネージャーのCPUグラフを「論理プロセッサ」に切り替え、ダウンロード中に張り付くコアがないか確認します。

MicrosoftのSMB Multichannel文書にも、単一接続ではRSSが助けにならず、単一CPUコアがボトルネックになり得るという説明があります。これはSMBの資料ですが、「複数接続ならCPUコアへ分散できても、単一接続は分散しにくい」という診断原理は高速通信全般を考える手掛かりになります。

暗号化・セキュリティ検査・展開は別々に確認する

CPUが原因か調べるときは、CPU全体ではなく、コア別使用率とダウンロードアプリ、セキュリティ製品の各プロセスを同時に見ます。

HTTPS通信では暗号処理が発生し、セキュリティ製品がWeb通信や保存ファイルを検査することもあります。ゲーム配信ではさらに復号、展開、差分適用、検証が続きます。どの処理が重いかはアプリと製品設定で変わります。

原因調査のためでも、セキュリティ機能を恒常的に無効化するのは避けてください。まずOSとアプリを更新し、プロセス別CPU、ディスクI/O、セキュリティ製品のログや公式診断機能を確認します。検証上どうしても設定を一時変更する場合は、対象と時間を限定し、終了後に元へ戻します。

SSDの公称速度より、実際の書き込み工程が重要

「NVMe SSDだから問題ない」「SATA SSDだから必ず遅い」とは決められず、保存先、キャッシュ、空き容量、書き込み単位、展開処理まで見る必要があります。

単純な大容量ファイル保存ならシーケンシャル書き込みに近づきますが、ゲーム更新では小さなファイル、既存データの読み出し、差分適用、別ファイルへの再構築、ウイルス検査が混在します。メーカーの「最大○MB/s」は、指定条件で測った上限であり、すべての作業で維持される値ではありません。

比較データ：5Gbpsの625MB/sとストレージ公称値

公称最大530MB/sのSATA SSDは、単純比較でも5Gbps相当の625MB/sを下回ります。

製品例	メーカー公表の最大書き込み	通信速度換算	5Gbps受信との単純比較
Seagate IronWolf 16TB（HDD）	最大持続240MB/s	1.92Gbps	単純保存でも先に上限候補
Samsung 870 EVO（SATA SSD）	最大530MB/s	4.24Gbps	625MB/sを下回る
Samsung 990 PRO（NVMe SSD）	最大6,900MB/s	55.2Gbps	公称値上は十分だが、実作業の保証ではない

比較はメーカー公表値を8倍して通信速度へ換算しただけで、製品の実測比較ではありません。IronWolfは容量・型番で180～240MB/s、870 EVOの250GB・500GBモデルはTurboWrite領域後のシーケンシャル書き込みが300MB/sと記載されています。使用モデルのデータシートを確認してください。

独自計算：圧縮データは「展開倍率」だけ書き込み量が増える

5Gbpsで受け取るデータを1.5倍へ展開するなら937.5MB/s、2倍なら1,250MB/sの出力処理が必要です。

受信中に展開して保存する単純モデルでは、持続可能な受信速度は次の式で考えられます。

持続可能な受信MB/s ≦ 実効書き込みMB/s ÷ 展開倍率

保存側の書き込み能力	展開倍率1.0倍	展開倍率1.5倍	展開倍率2.0倍
530MB/s（870 EVO公称最大を例示）	受信上限4.24Gbps	受信上限約2.83Gbps	受信上限約2.12Gbps
240MB/s（IronWolf公称最大例）	受信上限1.92Gbps	受信上限1.28Gbps	受信上限0.96Gbps

展開倍率1.5倍、2倍は計算例であり、特定ゲームの実測値ではありません。実際にはCPUの展開能力、読み出し、ランダムI/O、メモリーキャッシュ、書き込みキャッシュの枯渇、SSD温度、空き容量、同時検査も影響します。

この計算から分かるのは、ネットワーク上は625MB/sでも、保存工程が同じ625MB/sで済むとは限らないということです。

過去事例：EpicとSteamの公式説明にもディスク待ちがある

ネットワーク表示が0になっても、ディスクが忙しければ「通信障害」ではなくインストール工程の待ち時間かもしれません。

Epic Gamesの公式サポートは、ダウンロード済みファイルをディスクへインストールしている間、ディスク速度に応じてLauncherが受信を停止し、表示が0になることがあると説明しています。読み書きグラフを確認し、書き込み終了後にダウンロードが再開するという案内です。

ValveのSteamworks文書では、SteamPipeがファイルを約1MBのチャンクへ分けて圧縮・暗号化し、クライアント側で復号・展開して配置すると説明されています。packファイルの作りによっては、ダウンロード自体は速くても大量のローカルディスクI/Oで更新処理が遅くなる事例も記載されています。

つまり、ユーザーが待つ時間は「ネットから届く時間」だけではありません。ゲームを起動できるまでを短くしたいなら、CDNだけでなくCPUと保存処理も改善対象です。

原因を最短で絞る測定手順

設定を次々に変える前に、SpeedtestのMulti、Single、実ダウンロード、CPU、ディスクの5項目を同じ時間帯に記録します。

比較では一度に変える条件を1つにします。有線接続、同じPC、同じ保存先を基本にし、各測定は3回行って中央値を使います。短時間に連続で負荷をかけると発熱や混雑が次の測定へ残るため、間隔もそろえてください。

手順1：まず実ダウンロードの平均速度を出す

瞬間的な最高値ではなく、実際に転送した容量と経過時間から平均速度を計算します。

ダウンロード開始時刻と完了時刻を記録する
転送されたデータ量を確認する。インストール後サイズと混同しない
OSのネットワーク使用量、アプリの表示、保存先の書き込みMB/sを記録する
CPUグラフを論理プロセッサー別にし、張り付いたコアと対象プロセスを見る
ネットワーク完了時刻と、展開・検証・インストール完了時刻を分けて記録する

手順2：近距離・単一通信・別サービスを順番に比較する

測定先を変えるテストは、家庭内機器を交換する前に「遅い範囲」を特定するために行います。

Speedtestアプリで同じ近距離サーバーを選び、Multiを3回測る
Singleを選べる環境なら、同じサーバーで3回測る
Cloudflare Speed Testで遅延、負荷時遅延、ジッター、パケット損失を見る
利用規約の範囲で、別会社の信頼できる大容量配信を1つ比較する
同じデータを別のSSDへ保存できるなら、保存先だけを変えて比較する
宅内にiperf3サーバーを用意できる場合は、LAN内で-P 1と-P 4を比べる

宅内iperf3の例はiperf3 -c <LAN内サーバーIP> -R -P 1とiperf3 -c <LAN内サーバーIP> -R -P 4です。これはLAN・NIC・PCの切り分けであり、外部CDNや光回線の速度を直接測るものではありません。

独自診断：結果の組み合わせでボトルネックを読む

1つの数値では断定せず、「どのテストだけ遅いか」を見ると原因候補が急に少なくなります。

観測結果	有力な候補	次の確認
Multiは約5Gbps、Singleも4～5Gbps、特定サービスだけ遅い	そのサービスのCDN、地域拠点、利用者単位の制御、アプリ	別時間帯・別配信元と比較。CPU・ディスクが低負荷か確認
Multiは約5Gbps、Singleと実ダウンロードは1Gbps前後	1接続のRTT・損失・ウィンドウ、1接続ごとの制限、単一コア	RTTの近い／遠い相手、コア別CPU、複数通信時の合計を比較
アプリ版Speedtestは約5Gbps、ブラウザーと実ダウンロードは低い	ブラウザー、拡張機能、HTTPS検査、CPU	同じサーバー、同じ接続モードで比較し、プロセス別負荷を見る
最初だけ速く、その後大きく低下する	SSDの書き込みキャッシュ枯渇、温度、メモリーキャッシュ、配信側バースト	数十GBの長時間推移、SSD温度、書き込みMB/s、ディスク待ち時間を記録
ネットワークが周期的に0になり、同時にディスクが忙しい	解凍、差分適用、検証、インストール工程	ネットワーク完了とインストール完了を分け、CPUコアとディスクを確認
複数サービスを同時に使うと合計だけ2～5Gbpsへ伸びる	1サービス・1通信ごとの上限	個別速度ではなく合計帯域を記録。サービスへ過剰な負荷をかけない
Speedtestを含め、すべて同じ時間帯に低下する	宅内LAN、ONU・ルーター、ISP、共有区間の混雑	別端末、有線直結、リンク速度、朝夜、別サーバーで再測定

独自分析：速度推移の「形」も証拠になる

平均値が同じ100MB/sでも、平らな100MB/sと、500MB/s・0MB/sを繰り返す状態では疑う場所が違います。

速度推移の形	読み取れること	断定前の注意
一定値で平らに頭打ち	配信側やアプリのレート制御、1接続上限の可能性	SSDの持続書き込みが同じ値で止まっている場合もある
開始後に徐々に上がる	スロースタートやキャッシュの立ち上がり	小容量ファイルでは上がり切る前に終了する
高速で始まり、数GB後に急落	書き込みキャッシュ、温度、配信側バーストの終了	ネットワークとディスクの時系列を重ねて確認する
高速と0を周期的に繰り返す	受信と展開・書き込みを交互に行うアプリ設計	パケット損失でも変動するためディスク負荷と照合する
夜だけ全体に低下	共有区間、ISP間接続、CDN拠点の時間帯混雑	1日だけで決めず、同条件を数日記録する

反証：よくある説明だけでは原因を断定できない

「Speedtestが速いから回線は完全に正常」「ダウンロードが遅いからCDNが悪い」のどちらも、単独の測定だけでは証明できません。

原因調査では、もっともらしい説明を集めるだけでなく、その説明と矛盾する観測がないか確かめます。

「CDNが遅い」への反証

保存先を変えただけで速度が上がるなら、CDNだけを原因とする仮説は弱くなります。

反対に、同じPC・同じ保存先で配信元Aだけ遅く、配信元BとSpeedtestは速い状態が複数時間帯で続けば、A側のCDNや経路という仮説は強まります。さらに別端末でもAだけ同じ上限なら、PC固有原因の可能性は下がります。

「NVMeならSSDは無関係」への反証

NVMeの公称シーケンシャル速度が高くても、実際の保存先、作業用フォルダー、空き容量、混在I/Oが別ならボトルネックは残ります。

ゲーム本体はNVMeでも、一時フォルダーが別ドライブ、既存packファイルの読み出しと新規ファイルの書き込みが同時、セキュリティ検査が割り込む、といった構成があります。ドライブ名ではなく、処理中の実効MB/s、アクティブ時間、応答時間を確認してください。

「HTTP/3・ダウンロード支援ソフト・DNS変更で必ず直る」への反証

これらは条件が合えば改善しますが、配信側の制限やCPU・SSDの上限を自動的に解除する方法ではありません。

HTTP/3：QUICにも輻輳制御があり、損失時の送信調整は残ります。
ダウンロード支援ソフト：分割取得にはサーバー側のRange対応と利用規約が必要です。RFC 9110ではサーバーがRangeを無視でき、多数の小範囲を拒否できるとされています。
DNS変更：DNSベースのCDN割当が変わる場合はありますが、オリジンの能力や利用者単位の上限は増えません。遠い拠点へ変わり、悪化する可能性もあります。

設定変更を試す場合は、変更前後で同じ配信元、同じファイル、同じ時間帯に近い条件をそろえます。「一度速くなった」だけでは、変更の効果と混雑の偶然を分けられません。

読者への影響：買い替える前に「1件の速さ」と「家全体の容量」を分ける

1つのダウンロードが1Gbpsで止まっても、10ギガ回線の残り帯域が無駄とは限りません。

例えば、PCのゲーム取得が1.2Gbps、別PCのクラウド同期が800Mbps、NASのバックアップが500Mbpsなら、合計は2.5Gbpsです。1件ずつは5Gbpsに届かなくても、複数人・複数端末が同時に使う家庭では1Gbps回線より余裕があります。

一方、利用目的が「1台のPCで、1つの配信サービスから、1本の大容量ファイルを最短で取る」だけで、そのサービスが常に800Mbps前後なら、回線を5Gbpsから10Gbpsへ上げても待ち時間はほぼ変わりません。改善対象はCDNの選択、アプリの接続方式、CPU、保存先です。

利用状況	優先して投資する場所	理由
Singleも実ダウンロードも低く、1コアが張り付く	CPU・アプリ・セキュリティ処理の見直し	回線を増速してもクライアント処理が先に止まる
ネットワーク0MB/s中にディスクが100％	保存先・空き容量・温度・更新方式の確認	待ち時間の中心が受信ではなく保存処理
1件は遅いが複数同時の合計は伸びる	現状維持、または利用目的に応じて宅内10GbEを整備	太い回線が同時利用の余裕として機能している
すべての配信・Speedtestが夜だけ低下	ISP・接続方式・混雑状況の確認	特定アプリより共通経路が疑わしい
特定サービスだけ常に同じ値で止まる	サービス設定・配信地域・時間帯の比較	宅内機器の高額な交換で直らない可能性が高い

この切り分けをせずにルーター、LANカード、SSDを順番に買うと、原因ではない部品へ費用を使いかねません。反対に、保存処理が原因なのに回線事業者へ問い合わせ続けると、解決までの時間が延びます。記録を残せば、サービス提供者やISPへ相談するときも再現条件を伝えやすくなります。

よくある質問

5Gbpsという1つの結果より、Multi・Single・実ダウンロード・CPU・ディスクの対応関係が重要です。

Speedtestで5Gbpsなら、ONUやルーターは正常ですか？

少なくとも測定時に、その経路で合計5Gbpsを処理できた有力な証拠ですが、全機能が常に正常という保証ではありません。

別ポート、Wi-Fi、特定プロトコル、長時間負荷、発熱時の挙動までは分かりません。ただし、同じPC・同じ有線経路で安定して5Gbps出るなら、単純な1GbEリンクや常時1Gbps以下の宅内上限は考えにくくなります。

100MB/sしか出ないのは遅すぎますか？

5Gbpsに対しては16％ですが、配信サービスの仕様と用途を確認するまでは異常と断定できません。

100MB/sは800Mbpsで、100GBの理想時間は16分40秒です。同じサービスを別端末・別時間帯で試し、Singleテスト、CPUコア、保存先の実効書き込みと比較してください。

複数ダウンロードで合計5Gbps出れば問題ありませんか？

回線容量を使えることは確認できますが、1件の待ち時間を短くする課題は残ります。

家庭全体の同時利用が目的なら良好な結果です。1ファイルを最短で取得したいなら、1サービス・1通信の上限を別に調べる必要があります。

SSDをNVMeへ交換すれば必ず速くなりますか？

現在のディスクが実際に上限へ達していると確認できた場合に限り、交換の効果を期待できます。

ディスクが低負荷で、Singleテストと実ダウンロードが同じ値なら、CDNや単一通信の上限が先かもしれません。交換前に、ネットワークが落ちる時刻とディスク負荷が上がる時刻が一致するか確認してください。

まとめ：5Gbpsと遅いダウンロードは、測っている範囲が違う

Speedtestの5Gbpsを否定せず、実ダウンロードの遅さも否定せず、両者の間に追加された処理を一つずつ測るのが最短の解決方法です。

まず5Gbpsを625MB/sへ換算し、実ダウンロードの平均と利用率を出します。次にMultiとSingleを比べ、CDN・単一通信の候補を分けます。同時にCPUを論理プロセッサー別で見て、ディスクのMB/sとアクティブ時間も記録します。

RTTが50msなら5GbpsのBDPは31.25MB、16論理プロセッサー中1つの飽和は全体で約6.25％、展開倍率2倍なら625MB/sの受信に1,250MB/sの出力処理が必要です。こうした数値を使えば、「たぶんCDN」「たぶんSSD」という推測から、再現できる診断へ進めます。

一次情報・比較事例

仕様や数値は、測定事業者、標準化団体、OSベンダー、配信事業者、ストレージメーカーの公開資料で確認しています。

注：製品仕様、アプリの実装、CDN構成、検索結果は更新されます。表の独自計算は条件を明記した理論値または単純換算であり、特定環境の実効速度を保証するものではありません。