Rakuten WiFi Pocket 5Gレビュー｜楽天最強プランで速度と遅延を実測

10月31日追試：10MB送信中のHTTPS要求を新規測定

新規実測：2026年10月31日11:52:55〜11:54:59（日本時間）。ここからは、以前の送受信速度やPingとは別の試験だ。

10MBのデータを送信しながら、別サイトへの小さなHTTPS要求を確認した。10,000,000byteの送信はHTTP 200で完了し、所要26.82秒・実効約2.98Mbpsだった。送信要求中に開始・終了した確認は、Googleと楽天モバイルの各2/4回が成功し、各2回がタイムアウトした。

ただし、送信前から数秒かかる応答があり、終了後も成功分の中央値は元に戻っていない。単回の時系列観測なので、遅れや失敗の原因をアップロードだけに特定したり、送信を止めれば必ず改善すると結論したりはしない。

上りが遅いという相談から、同時利用中の応答も確認

価格.comには、2021年4月13日、Rakuten Handで下りと比べて上りが極端に遅い、という相談がある。今回のPocket 5Gとは別機種・別時点の報告で、投稿者の環境を再現した試験ではない。上りのMbpsだけでなく、送信要求が動いている間の別の通信も見るための題材とした。相談の原文：「なぜ？Uploadが遅すぎる」

送信先はCloudflareの公開測定用https://speed.cloudflare.com/__upで、測定用に生成したランダムデータをPOSTした。Cloudflareの公式モジュールにはアップロード用APIや、送信中の遅延を測る機能がある。今回はそのAPIを利用した独自の確認で、同社のブラウザー版スコアや測定手順をそのまま再現したものではない。Cloudflare公式：speedtestのAPI資料

確認結果：50要求のうちHTTP応答45件、タイムアウト5件

Googleにはhttps://www.google.com/generate_204、楽天モバイルにはhttps://network.mobile.rakuten.co.jp/へHEAD要求を送った。成功時はそれぞれ204と200。ページ本文は取得しておらず、この表はWebページ全体の描画時間ではない。中央値は成功した要求だけで計算し、失敗を0秒にしたり平均に混ぜたりしていない。特に送信中は各2件の成功分しかない。

送信は11:53:40.597〜11:54:07.543に実行した。要求の開始・終了が両方ともこの窓に収まった各4件を「進行中」に集計した。最後の各1要求は送信終了をまたいだため別集計とし、Googleは1/1成功・5.793秒、楽天モバイルは0/1・タイムアウトだった。送信要求を開始したというフラグだけで区間を決めていない。

失敗5件はすべてcurl終了コード28で、約5.00〜5.02秒でHTTP応答を取得できずに終了した。接続段階の上限を5秒、要求全体を10秒としている。curlの接続段階には名前解決とTCP・TLS等の確立が含まれるため、「本文が5秒止まった」とは同じ意味ではない。HTTPステータス0のサーバー応答としても扱っていない。curl公式：connect-timeoutとtime_total

送信前から遅れがあり、終了後にも所要時間が残った

成功分の中央値は、Googleが前2.706秒・中3.141秒・後3.413秒、楽天モバイルが前3.081秒・中3.793秒・後4.020秒だった。今回の送信前後も、以前の別日時のHTTPS確認と同じ状態ではない。過去の速い応答を今回の「送信前」として使わず、この直前・直後に実際に測った値を掲載した。

これは、送信中に未応答が出たという観測と、送信だけが原因だという診断を分けるための結果だ。帯域を使い切ったことやルーター内部のキューは調べていない。送信要求の窓には接続確立や応答待ちも含まれ、全期間を一定速度で送信し続けたと確認したものではない。

送信量・測定条件・この追試の限界

送信本文は10,000,000byte（10MB、10進表記）。この1要求の完了までのcurl所要時間26.822548秒を使い、byte×8÷秒から約2.98Mbpsを算出した。接続確立も含む実効値で、携帯回線の物理リンク速度ではない。写真、バックアップサービス、会議、ゲーム等を実際に動かした試験でもない。

送信1件とHEAD50件で、curlが記録した要求は合計10,004,337byte。この値には10MBの送信本文も含まれるため、さらに10MBを足してはいない。受信ヘッダーは合計44,917byte、取得した応答本文は0byteだった。DNS・TLS・IP・Wi-Fi等の付加情報や、PCの他の通信を含む総使用量は計測していない。

Windows 11 Pro、Intel Dual Band Wireless-AC 8265、2.4GHz・802.11n・チャネル6、開始時の送受信リンク速度144.4Mbps、信号表示98%、RSSI−30dBmで実施した。開始時、送信直前、送信終了後、全確認終了時の4回、同じ楽天ルーターとIPv4・IPv6の既定経路がWi-Fiであることを確認した。携帯回線側の4G・5Gは未確認だ。

curl 8.21.0、IPv4・HTTP/1.1、証明書検証有効。送信上限90秒、HEAD上限10秒、いずれも接続待機上限5秒、再試行と自動転送追従なし、この要求に限りプロキシを通さず実施した。各組では2宛先を並行確認し、両方の終了後に約1秒空けた。送信前・後は各10組、送信要求中のループは5組だったため、固定の1秒周期ではない。

相談資料のブラウザー表示などの背景通信や、他の接続機器、配信CDN、基地局の状態を統制していない。無線設定やルーターの再起動・設置場所は変更していない。1回の送信で、区間ごとの標本数も異なる。会議アプリの品質、写真のクラウド保存、長時間の安定性、QoS設定の効果は未検証だ。

送信中でもWebや会議を快適に使えると分かった？

そこまでは確認していない。今回は小さなHEAD要求にも失敗があり、ページ本文の表示や会議アプリは試していない。約2.98Mbpsという送信の完了速度だけで、同時利用の快適さを保証することはできない。

10月31日午前の追試：20MB受信・1MB送信を各3回

新規実測：2026年10月31日10:37:55〜10:39:56（日本時間）。同じPCとRakuten WiFi Pocket 5Gの2.4GHz接続で、20MB受信と1MB送信を各3回測り直した。6回とも完了し、受信は4.59〜6.60Mbps、中央値6.49Mbps。送信は1.90〜3.85Mbps、中央値3.58Mbpsだった。

楽天コミュニティには、時間帯によって通信速度が違うという相談がある。今回も「遅い・速い」という一度の数値で評価せず、別の日時で同じ転送量を試した。相談者と同じ場所・端末での再現試験ではない。相談の原文（楽天モバイルコミュニティ）

前日14時台との違い：受信と送信は同じ方向に変化しなかった

前日の完了した受信2回より、今回の受信3回は低い数値だった。一方、1MB送信は前日より高い。前日の受信の時間切れを速度0Mbpsに置き換えたり、完了した試行だけで全3回の平均を表したりはしていない。前日の値は既報の記録で、今回の新しい実測ではない。

楽天モバイルの公式解説も、実測値は回線種別、場所、時間帯、電波、混雑等の条件で変化すると説明している。今回の2日分は、曜日や時間帯のほかの条件も統制していない。したがって「土曜の午前だから送信が改善した」「午前はいつも速い」といった因果関係や、地域全体の傾向は判断できない。楽天モバイル公式：通信速度の実測値が変わる条件

今回の通信量・手順・比較の限界

Cloudflareの受信・送信測定用エンドポイントを使い、IPv4・HTTPS・HTTP/1.1の単一接続を要求ごとに新しく開始した。各組で20MBを受信し、5秒空けて1MBを送信し、さらに5秒空けた。3組を順番に実施し、開始時・各組終了後・最終終了時に同じルーターとWi-Fiの既定経路を確認した。Cloudflare公式：測定用エンドポイント

受信本文は計60,000,000byte、送信本文は計3,000,000byteで、合計63MB（1MB＝1,000,000byte）。全6要求がHTTP 200、curl終了コード0で、要求した転送量に一致した。1要求の上限は90秒、接続確立の上限は10秒、再試行なし、転送速度の上限指定なし。通信方式・転送量・90秒上限は初回とそろえたが、送受信の実行順序と間隔は異なる。Mbpsは本文byte数×8÷curlの総所要秒÷1,000,000で算出し、接続確立や応答待ちの時間も含む。Cloudflare公式画面の自動テストと同一の採点方式ではない。

PC側は2.4GHz・802.11n・チャネル6、リンク速度144.4Mbps。開始時の信号表示96%、RSSI −31dBm、応答ヘッダーの拠点表示は6回ともKIXだった。PC・ルーターの設置位置の固定、他の接続機器、背景通信、基地局やインターネット経路は統制していない。携帯回線側の4G・5Gは未確認だ。本文の63MBにDNS、HTTPやTCP/IP等のヘッダー、PCの他の通信は含めておらず、回線全体の使用量とは同じではない。

今回は転送速度と完了の有無を追試し、負荷時Pingや実際の会議・動画アプリは測っていない。新しい送信速度の結果から、前日に測った送信中のPingやアプリの快適さも改善したとは判断していない。

追試：ダウンロード要求中のPingを新規測定

追試日時：2026年10月30日17:35〜17:36（日本時間）。ここからは上の14時台の試験とは別の新規実測で、同じWindows PC・2.4GHz接続を使った。

楽天モバイルコミュニティには、別機種Aterm MR05LNで測った通信速度とPingの結果が妥当かを問う相談がある。速度と応答の遅れは別々に確認したい。本追試は投稿者の不具合の再現ではなく、Rakuten WiFi Pocket 5Gで受信要求の前・中・後を比べた。楽天モバイルコミュニティの相談

外部2宛先とも、受信要求中の44回で正常なEcho応答は1回、900ms以内の応答なしは43回だった。ただし、受信前にも31回中11回の応答待ち切れがあり、ダウンロードだけが原因だとは断定できない。応答が返った1件の中央値だけでは、この区間の状態を表せないため、成功数を併記している。

P95と中央値は正常に返ったEcho応答だけで算出した。成功1件の区間はP95を掲載せず「—」とした。900ms以内に返らなかった記録は、永久に失われたパケットやアプリの切断回数を示すものではない。ICMPの扱い、経路、Wi-Fi、回線、測定先などのどこが原因だったかは今回の記録からは特定できない。Pingと待機時間の意味はMicrosoftの公式資料で確認できる。

×は900ms以内の応答なしを示し、RTTが900msだったという測定点ではない。図の時系列はCloudflare宛て。Google宛ての成功数は各区間で同じだった。

受信量と未完了の扱い

Cloudflareの公開測定用エンドポイントへ10,000,000byteを要求した。HTTP 200で本文の受信が始まったが、45.01秒の上限で1,380,608byte（約1.38MB）までとなり、転送は完了していない。したがって、これを10MBの完了速度として掲載していない。受信側には2MiB/秒の上限を設定しており、最大帯域を使い切る試験でも、一定速度の負荷を保証する試験でもない。接続開始や受信が止まっていた可能性のある時間も「受信要求中」に含む。

先に行った100MB要求はHTTP 403で本文1byteとなり、持続した受信負荷が成立しなかったため、上の区間比較には使わなかった。この失敗も記録に残しているが、403の原因は特定していない。Cloudflareの測定用API資料を参照した独自試験で、公式ブラウザー版のスコアと同じ集計ではない。

追試の条件と評価の限界

ルーター、1.1.1.1、8.8.8.8へIPv4のICMP Echoを約1秒ごとに並行して実行した。データ長32byte、待機上限900ms、計315回。受信要求前は各31回、要求中は各44回、終了後は各30回になった。開始時のWi-Fi電波表示は97%、RSSIは-23dBm、リンク速度は144.4Mbps。開始・受信要求直前・終了時に同じルーターとWi-Fiの既定経路を確認した。

事前にも外部宛ての応答なしがあり、終了後も各5/30回で待機上限を超えた。今回の単回試験から、受信を止めれば必ず解消する、ルーターが故障している、楽天回線の混雑が原因だ、といった診断はできない。PCのバックグラウンド通信と他端末は統制しておらず、携帯回線側の4G・5Gも未確認。ゲームや会議アプリの実動作、IPv6、キューの状態やパケットキャプチャは調べていない。

この追試で確認できたのは、電波表示が強い接続でも外部の小さな応答がそろわない時間があったことだ。大容量転送と同時に使う用途では、Mbpsだけでなく成功数や応答待ち切れも見る必要がある。動画そのものの確認は、別の新規測定によるYouTube1080pの実再生レビューに掲載した。