Rakuten WiFi Pocket 5GはIPv6で使える？IPv4比較と自動切り替えを実測

広告：本記事にはアフィリエイト広告が含まれます。

2026年10月31日更新：通常通信とIPv4への接続試行を新規38要求で確認。自動切り替えの実測と人工条件の限界へ。従来の転送速度表は10月30日の測定結果です。

実測日：2026年10月30日 15:32〜15:36（日本時間）／楽天最強プラン／Rakuten WiFi Pocket 5G／Windows PC・2.4GHz接続

Rakuten WiFi Pocket 5Gは、PCからIPv4とIPv6の両方で外部へ接続できるのか。今回、ルーターのAPNやWindowsのネットワーク設定を変えず、通信リクエストごとに方式を指定して新しく測定した。GoogleへのHTTPS接続はIPv4・IPv6とも3回すべて成功し、Cloudflareへの0.25MB送信も両方式で3回すべて完了した。一方、2MB受信はIPv4が2/3回、IPv6が2/3回の完了となり、接続の成立と転送の速さは分けて考える必要があった。

2026年10月31日追記：IPv6で接続できないとIPv4へ自動で切り替わる？

通常のIPv4・IPv6通信は両方式とも6/6回成功した。一方、実サービス用ではない文書用IPv6と実際のIPv4を同時に渡した条件では、IPv4への試行が始まってもHTTPSは完了しなかった。接続上限5秒では0/6回、追加の15秒では0/4回の成功だった。同じIPv4宛先だけを渡す追加測定は4/4回成功している。

これは試験プログラム内で宛先候補を置き換えた人工的な条件の結果だ。楽天の通常のIPv6経路に障害が発生した、という測定ではない。APNの変更やPC全体のIPv6無効化を勧める根拠にもならない。

2026年6月17日の楽天モバイルコミュニティの相談では、Pocket 5GのAPNをIPv4へ変更したいが編集できない、という疑問が寄せられている。今回もAPN編集は行わず、リクエスト単位のIPv4・IPv6指定と、片方の接続が成立しない場合の動作を追加確認した。相談者の利用目的やAPN保存エラーを再現・解決した試験ではない。

通常の通信と人工的な宛先条件を分けて測定

2026年10月31日12:30:36〜12:32:42に初回30要求、12:33:09〜12:34:06に追加8要求を実施した（日本時間、秒未満切り捨て）。Windows 11 ProのPCから、楽天最強プラン＋Rakuten WiFi Pocket 5Gへ2.4GHz・802.11nで接続。送受信リンク速度144.4Mbps、信号表示94%、RSSI−30dBmだった。これはWi-Fi区間の値で、携帯基地局の電波強度ではない。携帯回線の4G・5Gは未確認。

測定の前後、追加測定の前後の計4回、SSIDとIPv4・IPv6の既定経路を記録し、対象ルーター経由のままであることを確認した。ルーター、Windows、ブラウザーのネットワーク設定、hostsファイル、証明書の信頼設定は変更していない。

宛先はGoogleの確認用URLと楽天モバイル公式トップで、GoogleはHTTP 204、楽天はHTTP 200を成功条件とした。HTTP/1.1のHEAD要求を毎回新しいcurl 8.21.0（Schannel）プロセスから送り、証明書検証あり、プロキシなし、再試行なし。初回は接続上限5秒・全体10秒、追加はIPv4単独の接続上限5秒、2候補の条件のみ15秒、全体20秒とした。Happy Eyeballsの待ち時間は200msを指定した。

通常の方式を固定しない要求は6/6回成功し、完了時の接続先は全件IPv6だった。IPv4指定・IPv6指定も各6/6回成功。ここでの秒数はDNS、TCP、TLS準備、HTTP応答を含む要求全体の時間で、回線速度のMbpsやページの描画時間ではない。各宛先・方式3回の短い確認で、恒常的な優劣は判断しない。

IPv4の試行を9件で確認したが、HTTPSは未完了

人工条件では、--resolveで各ホストの接続候補を、文書用IPv6アドレス2001:db8::1と、開始時のDNS回答から選んだ実IPv4アドレス1個に限定した。文書用の範囲はIANAで通常の宛先利用・グローバル到達性がいずれもFalseと登録されている。正規のAAAA回答を使う通常試験とは別条件であり、楽天が返した誤ったDNS回答でもない。IANAのIPv6特殊用途アドレス一覧を参照。

2候補を渡した初回6件・追加4件のうち9件で、詳細ログに文書用IPv6への接続試行と、その後のIPv4への接続試行が記録された。両ログ行の間隔は201〜215msだった。追加の楽天向け1件にはIPv4への試行行がなく、IPv6試行後のTLS処理とタイムアウトだけが記録されている。したがって全10件でIPv4切り替えを確認したとは扱わない。ログ行の間隔もHTTPS完了までの時間ではない。

初回6件はすべて約5秒の接続タイムアウト。追加の15秒条件も3件はタイムアウトし、1件はTLS処理中に接続リセットを受けた終了コード35だった。いずれもHTTPステータスを取得していない。対照として同じ実IPv4だけを渡した4件は、証明書検証を維持したまま成功した。

今回の結果では9件で「IPv4も試した」という動きは確認できたが、「IPv6が接続できなくても必ず自動でHTTPSが完了する」とは確認できなかった。curl・Schannel、人工的な候補指定、経路や宛先、時間変動などのどこに原因があるかは特定していない。通常のIPv6指定は成功しており、人工条件の失敗を楽天のIPv6サービス全体の障害へ置き換えて評価しない。

curl公式は、Happy Eyeballsで複数のアドレスへ接続を試し、接続試行のタイムアウトを設定できると説明している。これはHTTP要求やアプリ全体の成功保証ではない。curl公式の接続試行の説明、宛先指定の公式マニュアル。RFC 8305も、TCP接続後のアプリケーション層の問題にはこの方式だけで対応できないと説明している。RFC 8305の制約。

データ量と検証の限界

38要求でcurlが記録した要求は2,024byte、応答ヘッダーは21,813byte、応答本文は0byteだった。HEADなので本文をダウンロードしていない。TLS・TCP/IP、接続できなかった試行のパケット、再送、開始時のDNS問い合わせ、他の背景通信はこの集計に含まれず、楽天の課金データ量ではない。

1地点・1台での逐次試験で、キャッシュ、サーバー、経路、背景通信は統制していない。初回と追加測定は時間が異なり、同時比較ではない。Chrome等のブラウザー、VPN、ゲーム、会議アプリ、通信開始後の切断、APN設定変更は未検証だ。人工条件の結果を、そのまま他のアプリの切り替え動作へ当てはめることはできない。

FAQ：この結果ならIPv6を無効にした方がよい？

今回の通常のIPv6指定は6/6回成功し、IPv6を無効にすべきという結果ではない。特定アプリだけの問題なら、まずそのアプリの症状と、IPv4・IPv6それぞれの通信が成立するかを切り分ける必要がある。本検証の方式指定は各curl要求にだけ作用し、PC全体やルーターのIPタイプを変更していない。

DNSそのものの応答と暗号化DNSは通常DNS・DoHの実測、負荷がある状態の応答は総合レビュー、途中まで受信したファイルの再開はダウンロード再開の実測で検証した。

IPタイプに関するネット上の疑問を実機で確認

楽天モバイルのコミュニティには、Rakuten WiFi Pocket 5GのIPタイプをIPv4にしたいものの、既存APNの編集や同じAPNの追加ができないという相談が投稿されている。これは投稿者の環境に関する質問であり、メーカーの動作保証ではない。楽天モバイルコミュニティの相談

そこで本記事では、APNの編集可否とは切り分け、現状の接続のままでIPv4・IPv6の通信を使い分けられるかを確認した。管理画面でAPNを変更する手順や、相談にある保存エラーを解消する手順を検証したものではない。

IPv4とIPv6で接続できたか

GoogleのHTTPS応答確認と、Cloudflareの測定用エンドポイントへの送受信を、それぞれ3回実施した。

Googleでは、本文を返さない正常応答のHTTP 204を成功条件とした。CloudflareではHTTP 200に加えて、指定したデータ量をすべて転送し、curlが正常終了した場合だけを完了とした。HTTP 200が届いても、本文の受信が途中で止まった試行は成功に数えていない。

2MBダウンロード速度の実測結果

受信データ量はどちらも2,000,000byteとし、1リクエストの上限を35秒に設定した。以下は今回の新しい6試行で、先に公開した総合レビューの測定値は使っていない。

完了した試行の速度と未完了の試行が混在しているため、成功分の平均だけで方式の優劣を決めることはできない。IPv4・IPv6で接続先の経路が異なる可能性があり、同じ測定先でも混雑や無線の状態は時刻ごとに変わる。この試験から「IPv6なら必ず高速」「IPv6が遅さの原因」とは断定しない。

0.25MBアップロード速度も3回ずつ比較

送信には同じ250,000byteのランダムデータを使った。実効速度の中央値はIPv4が0.46Mbps、IPv6が0.27Mbpsだった。

今回の少量の送信は両方式で完了した。送信できることと、大きなファイルを短時間で安定して送れることは別なので、0.25MBの結果を大容量アップロードの保証には使えない。

APNを変更せず、リクエスト単位で方式を確認する方法

今回使用したcurlの-4はIPv4、-6はIPv6で接続する指定だ。指定が作用するのはそのcurlリクエストで、PC全体やルーターの設定をIPv4専用・IPv6専用に切り替える操作ではない。curl公式マニュアル

Windowsのターミナルでは、次のように応答を確認できる。HTTP 204が返れば、この確認先へのHTTPS接続は成功している。

curl.exe -4 --max-time 15 -sS -o NUL -w "HTTP %{http_code}" https://www.google.com/generate_204
curl.exe -6 --max-time 15 -sS -o NUL -w "HTTP %{http_code}" https://www.google.com/generate_204

この結果だけで、すべてのサイトやアプリが同じ方式で通信するとまでは確認できない。今回の検証でも、Googleへの接続確認とCloudflareへのデータ転送を分けて記録した。

測定環境と今回の結果の範囲

PCはWindows 11 Pro、無線LANはIntel Dual Band Wireless-AC 8265。接続は2.4GHz・802.11n・チャネル6、リンク速度は144.4Mbps。開始時のWi-Fi電波表示は99%、RSSIは−28dBmだった。IPv4・IPv6の既定経路がともにWi-Fiであることを確認し、測定リクエストは明示的なプロキシを経由させていない。

Cloudflareの接続情報では、両方式の開始時の拠点表示はKIXだった。送受信はHTTPS・HTTP/1.1で行い、速度は転送データのビット数をリクエスト全体の秒数で割った。1MBは100万byte、1Mbpsは100万bit/秒とした。DNS、TCP・TLSの接続開始、サーバー待ちも含むため、純粋な無線リンクの最大速度を示す数値ではない。

試験順は1回目がIPv4→IPv6、2回目がIPv6→IPv4、3回目がIPv4→IPv6。1か所・1台・単一の時間帯の測定で、バックグラウンド通信や同じルーターの他端末は管理していない。携帯回線側が実際に4G・5Gのどちらを利用していたかは未確認。5GHz Wi-FiやUSB接続との比較も今回の範囲には含めない。

IPv6接続に関するよくある質問

Rakuten WiFi Pocket 5GでIPv6は使えた？

今回の楽天最強プラン・Windows PCの環境では、IPv6指定でGoogleへのHTTPS接続3回とCloudflareへの0.25MB送信3回がすべて成功した。したがって、この測定環境でIPv6による外部通信が成立したことは確認できた。

IPv4を使うにはAPNをIPv4専用にする必要がある？

今回のcurlによるIPv4通信では、APNの変更は行っていない。ただし、特定のアプリや機器をIPv4専用にする設定要件や、ルーターのAPN編集可否は別途確認が必要だ。

IPv6にすれば必ず速くなる？

今回の測定から、そのような結論は出せない。接続先と通信経路、混雑、測定時刻、転送量の影響を受ける。接続成功数と、完了した転送の所要時間を併せて判断したい。

製品名の5GとIPv6は同じ意味？

異なる。5Gは携帯回線の世代、IPv4・IPv6はインターネット通信で用いるIPのバージョン、2.4GHz・5GHzはPCとルーターを結ぶWi-Fiの周波数帯を指す。

関連する実測レビュー

受信・送信速度と転送中のPingについては、Rakuten WiFi Pocket 5GのWindows PC実測レビューに掲載した。本記事とは測定日時・データ量が異なるため、数値の単純な比較はしていない。