広告:本記事にはアフィリエイト広告が含まれます。
測定日:2026年10月31日(日本時間)/楽天最強プラン/Rakuten WiFi Pocket 5G/Windows PC・2.4GHz接続
楽天のポケットWi-Fiは頻繁に途切れるのか。今回はPocket 5GをこのPCで使い、各約5分のPingとHTTPS確認を新しく行った。HTTPSは2宛先・計40要求がすべて完了。一方、Pingの成功応答はルーター299/300回、外部2宛先267/300回・265/300回で、APIのTimedOutも記録された。
この数値を「回線が69回切れた」「常に安定」とは評価しない。PingのTimedOutが指定待機時間より早く返った記録があり、実パケット損失率や停止時間への換算はできない。観測時間を少しずらしてping.exeでも確認し、ルーター20/20回、外部19/20回・20/20回の応答を記録した。以下では方式・時刻・限界を分けて示す。
先に確認:3つの試験は開始時刻が異なる
- HTTPSの定期確認:11:04:57〜11:09:42。2宛先へ各20要求。
- .NETのPing:11:06:48〜11:11:49。3宛先へ各300要求、最初から最後の記録まで約301.8秒。
- ping.exeの追加確認:11:13:11〜11:13:30。3宛先へ各20要求。
すべて2026年10月31日の新規測定だ。HTTPSと.NETのPingは一部の時間で重なるが、同じ約5分を完全に同時観測した試験ではない。Ping側は当初のWindows PowerShellでスクリプト実行が制限され、通常のPowerShell 7.6.5で開始し直した。実行制限の設定は変えておらず、失敗記録も保存した。
Pingの実測:ルーターと外部2宛先を分けて記録
| 宛先 | 成功応答 | APIのTimedOut | 成功分の中央値 | 成功分の95%点 | 成功分の最小〜最大 |
|---|---|---|---|---|---|
| ルーター(既定ゲートウェイ) | 299/300 | 1回 | 5.0ms | 13ms | 2〜26ms |
| Cloudflare(1.1.1.1) | 267/300 | 33回 | 52.0ms | 128ms | 31〜356ms |
| Google(8.8.8.8) | 265/300 | 35回 | 54.0ms | 128ms | 33〜356ms |
PowerShell 7から.NETのSendPingAsyncを使い、3宛先へ並行してICMP Echo要求を送った。1回の指定ペイロードは32byte、タイムアウト引数は900ms。各組をおおむね1秒間隔で開始し、実際の開始間隔の中央値は1.011秒、最小0.988秒・最大1.034秒だった。中央値と95%点は成功応答だけの値で、失敗に0msを割り当てていない。95%点は昇順に並べた成功記録の95%位置を切り上げた値だ。
Microsoftの公式文書では、このAPIはICMP Echo要求と対応する応答を扱い、タイムアウトを指定できる。ここで測っているのはICMPの結果で、Webページの読み込みや会議アプリの動作ではない。Microsoft公式:SendPingAsync
TimedOutの69記録を「69回の切断」と読まない理由
今回の計測には、TimedOutを含む組の処理が8〜252msで戻るという制約がある。900msはAPIに渡した設定値であり、900msを実時間で待ってから失敗したことを独立に確認できていない。この挙動の原因は未特定だ。APIが報告した分類として回数を残し、実際のパケット損失率や停止秒数には変換しない。
ルーターまでの応答と、外部宛ての応答は経路も相手も異なる。外部Pingの失敗だけでは、PCとルーターのWi-Fi接続が切れたこと、携帯回線が切断したこと、相手や途中経路がICMPに応答しなかったことを切り分けきれない。今回、故障箇所や回線側の制御原因を特定したとはしていない。
HTTPSは2宛先へ各20回、合計40回完了
Googleのhttps://www.google.com/generate_204と楽天モバイルのhttps://network.mobile.rakuten.co.jp/へ、約15秒ごとにHEAD要求を送った。1組で2宛先に並行して要求し、各20回実施した。
| 宛先 | 完了数 | HTTPステータス | 要求全体の中央値 | 最大 |
|---|---|---|---|---|
| Google・確認用URL | 20/20 | 204 | 275.4ms | 763.6ms |
| 楽天モバイル公式トップ | 20/20 | 200 | 378.2ms | 882.9ms |
この40要求に、curlのエラーや10秒の上限に達した例はなかった。時間は名前解決、TCP接続、TLS接続、応答取得を含むcurlの要求全体の記録だ。HEAD方式のためページ本文は取得していない。楽天モバイルの200応答も、ページの全画像やスクリプトが表示できた結果とは区別する。
HTTPSが40回完了した一方で、別の時刻・頻度・方式によるPingにはTimedOutが出た。これは「Pingだけで利用全体を評価しない」ための材料になる。ただし、各Ping失敗の瞬間にHTTPSが成功していたとは確認していない。15秒ごとの確認の間や、HTTPS観測終了後の一時的な問題も見逃し得る。
ping.exeでも追加確認:外部1宛先に未応答1回
API側の結果だけに依存しないため、Windows標準のping.exeでも別時刻に各20回確認した。IPv4、32byte、待機時間900msを指定し、3宛先のコマンドを並行実行した。Microsoft公式:pingコマンドと指定値
| 宛先 | 応答数 | Request timed outの表示 | 応答分の最小〜最大 |
|---|---|---|---|
| ルーター(既定ゲートウェイ) | 20/20 | 0回 | 3〜15ms |
| Cloudflare(1.1.1.1) | 19/20 | 1回 | 43〜135ms |
| Google(8.8.8.8) | 20/20 | 0回 | 43〜135ms |
追加確認でもCloudflare宛てに1回の未応答表示があった。ただし、この約19秒の試験は先の約5分間とは時刻と回数が異なる。「コマンドを変えると改善した」「失敗率が低くなった」といった比較は行わない。ping.exeの表示も、Wi-Fiの再接続回数そのものではない。
ネット上の疑問はPlatinumの相談。今回の5Gとは別機種
楽天モバイルコミュニティには、2026年5月31日、Pocket Platinumで電波表示に問題がなくても通信が途切れ、電源の入れ直しを繰り返している、という相談がある。相談の原文:POCKET WIFI 頻繁にきれて復旧しない
この相談はPlatinumについての体験で、今回測ったPocket 5Gとは機種が違う。今回の短時間測定で、相談者の症状を再現したり、その原因を解明したりしたわけではない。「切れる」という表現を、Wi-Fi接続、外部への応答、アプリの動作に分けて確認するための題材として取り上げた。
途切れるときに残したい情報と、公式の案内
現象が起きた時刻、PCのWi-Fi接続状態、ルーター画面の表示、困っているアプリを記録すると、どの段階の問題かを相談しやすい。MicrosoftもWi-Fi切断の調査で時刻、ネットワーク、電波条件等の記録を案内している。今回は接続状態の定期確認までで、WLANイベントログによる再接続履歴の全数調査は行っていない。Microsoft公式:無線接続のトラブル調査
Pocket 5Gの取扱説明書は、ほかの機器に接続されていないときにWi-Fiスリープへ移る時間を設定できると説明している。また、接続できない場合や突然電源が切れる場合などを別の症状として扱っている。今回のように継続して要求を送る試験は、無通信・未接続時のスリープを検証したものではない。Pocket 5G公式取扱説明書:スリープ設定と「よくあるご質問」
今回、再起動、初期化、設置場所の変更、ファームウェア更新や省電力設定の変更は行っていない。温度・バッテリー残量・携帯回線の電波指標も取得していないため、発熱やスリープを原因と断定しない。症状が続く場合の窓口はPocket 5G公式サポートを参照してほしい。
測定条件とデータ量
Windows 11 Pro、Intel Dual Band Wireless-AC 8265、2.4GHz・802.11n・チャネル6。開始時の送受信リンク速度は144.4Mbps、信号表示は98%、RSSIは−32dBmだった。これはPC側のWi-Fi情報であり、携帯回線側の4G・5Gや電波品質を測った値ではない。
開始前、HTTPS観測中の約30秒間隔の9回、追加Ping終了後の計11回、同じ楽天ルーターへの接続とIPv4・IPv6の既定経路がWi-Fiであることを確認した。確認と確認の間の全瞬間を監視したわけではない。携帯回線側の4G・5Gは未確認。PCの背景通信や他の接続機器は統制せず、資料確認等のブラウザー通信もある条件だ。
HTTPSはcurl 8.21.0、IPv4・HTTP/1.1、証明書検証あり。接続待機上限5秒・要求全体上限10秒、再試行・転送先への自動追従なしで、この要求に限りプロキシを通さず実施した。40要求で記録した応答ヘッダーは合計39,657byte、要求は合計3,680byte、取得本文は0byteだった。
.NETの900要求に指定したペイロードは合計28,800byte、成功応答のペイロードは26,592byte。追加のping.exeは60要求・指定ペイロード合計1,920byte、59応答のペイロードは1,888byteだった。送信要求に指定した量と、受信記録の量を区別している。DNS・TLS・ICMP/IP・Wi-Fi等の付加情報、他の通信、実際の無線上の総転送量は含まず、契約のデータ使用量と同じ数値ではない。
最初の接続確認では測定プログラムがnetshの日本語表示を扱えず、通信試験前に停止した。この準備段階の失敗と、Pingの起動制限、APIの時間記録の制約を残している。いずれも回線の障害回数には加算していない。
よくある質問
Pocket 5Gの通信は5分間、一度も切れなかった?
そうは断定できない。HTTPSは40/40要求が完了したが、間欠的な確認であり、PingにはTimedOutもあった。Wi-Fi切断履歴やアプリの連続動作を全数観測した結果ではない。
外部PingのTimedOutは楽天回線の損失率?
そのまま読み替えられない。今回はAPIが指定時間より早くTimedOutを返す記録もあり、原因を特定していない。方式・宛先・待機条件に依存する記録として掲載している。
会議・ゲーム・長時間の動画でも安定して使える?
今回それらのアプリは試していない。小さなPingとHEAD要求の結果から、音声・映像品質、対戦、長時間の安定性は判断できない。
関連する実測レビュー
送受信速度と負荷時の記録はPocket 5G総合レビュー、Windowsの接続判定はNCSI確認の実測、UDPの要求と返信はSTUN通信の実測にまとめた。各記事は測定日時と方式が異なり、過去の値を今回の実測として使っていない。


コメント