5Gパラドックス:電波がフルバーでも海外で通信速度が保証されない理由
渋谷のスクランブル交差点のネオン看板の下に立っているとき、ロンドン・ヒースロー空港の到着ロビーを歩いているとき、あるいはタイムズスクエアでUberを呼ぼうとしているとき、スマートフォンの画面には「5G」とアンテナピクトが5本フルに表示されているにもかかわらず、ブラウザはタイムアウトし、メッセージアプリの読み込みアイコンが延々と回り続ける——海外旅行でこれほどストレスを感じる瞬間は滅多にありません。
この「画面上の電波強度」と「実際の通信速度」の乖離は、通信業界では5Gパラドックスとして知られています。なぜこのような事態が起こるのかを理解するには、スマホのステータスバーが実際に測定している数値と、国境を越えてデータが転送される実際の仕組みを切り離して考える必要があります。
+-----------------------------------------------------------------------------+
| スマートフォンが実際に測定しているもの |
+-----------------------------------------------------------------------------+
| [端末] <===== 無線周波数リンク(レイヤー1) =====> [現地の基地局] |
| * 測定対象: RSRP、RSSI、SINR(アンテナピクト本数) |
| * ステータス: 5/5本(無線RF接続としては極めて良好) |
+-----------------------------------------------------------------------------+
|
| バックホール / トランジット
v
+-----------------------------------------------------------------------------+
| 実際にボトルネックが発生している場所 |
+-----------------------------------------------------------------------------+
| [現地の基地局] ---> [IPX交換網] ---> [ホームパケットゲートウェイ] ---> インターネット |
| * レイヤー3 IPルーティングおよびパケット転送 |
| * 帯域制限、QCI優先度、中継回線のボトルネック |
+-----------------------------------------------------------------------------+レイヤー1(物理RF)対 レイヤー3(パケットルーティング)
デバイスに表示される4本または5本のアンテナピクトは、レイヤー1(物理無線アクセスネットワーク / RAN)の接続性を示しています。スマホは以下の無線周波数指標に基づいてこのアイコンを算出します。
- RSRP(基準信号受信電力): 近くの基地局(5GのgNodeB、LTEのeNodeB)から受信した生の信号電力。
- RSSI(受信信号強度インジケーター): ノイズや干渉を含む、受信した広帯域電力の合計。
- SINR(信号対干渉雑音比): 無線チャネルの品質。
アンテナがフルに立っている状態は、単に端末と現地の基地局アンテナとの間に障害物がなく、減衰の少ない無線リンクが確立されていることを意味するに過ぎません。基地局のバックホール回線に十分な容量があることや、ネットワークがユーザーに帯域を割り当てていることを保証するものではないのです。
+--------------------------+-----------------------------------------------------------+
| 指標 / レイヤー | 制御内容 |
+--------------------------+-----------------------------------------------------------+
| レイヤー1(RAN / RF) | アンテナピクト、現地の基地局アンテナへの生の接続安定性。 |
| レイヤー2(データリンク) | フレーム伝送、ローカル無線スケジューリングの優先順位。 |
| レイヤー3(ネットワーク/IP)| 実際のスループット、IPパケットの転送およびルーティング。 |
+--------------------------+-----------------------------------------------------------+端末が現地の通信事業者(日本のNTTドコモや英国のEEなど)と完璧なレイヤー1の接続を維持していても、データパケットはレイヤー3(ネットワークルーティング)を通過しなければなりません。現地のセルセクターが2万人もの現地契約者で混雑している場合や、基地局とコアネットワークを結ぶバックホール回線が飽和している場合、旅行者のパケットはスケジューリングキューの最下位に回されてしまいます。
ローミング中継のボトルネック:IPXとホームルーティング
海外旅行用eSIMには、もう一つの複雑な要素が加わります。それがローミングアーキテクチャです。海外用プロファイルで接続する場合、データは現地のインターネットに直接流れるわけではありません。通常、以下のような国際ローミング経路を経由します。
- ローカルアクセス: 端末がレイヤー1経由で渡航先キャリアのRANに接続。
- IPXカプセル化: 渡航先キャリアがパケットをカプセル化し、IPX(IP eXchange)キャリアネットワーク(Syniverse、BICS、Tata Communicationsなどのトランジット事業者)経由で転送。
- ホームルーティングコア(S8HR): 標準的な「ホームルーティング」構成では、パケットが公衆インターネットに接続する前に、元のMVNOコアネットワーク(多くは香港、ポーランド、フランス、イスラエルなどに所在)まで長距離転送される。
- リターンパス: リクエストされたデータは、端末に戻るために同じ大陸間ルートを逆方向に通過する必要がある。
この複数のホップを経由する国際回線のどこかでパケットロス、レイテンシ(遅延)の急増、あるいは帯域制限が発生すると、端末の画面に「5Gフルバー」が表示されていても、スループットは完全にゼロまで落ち込んでしまいます。
混雑エリアでスマートな速度制限基準が重要となる理由
ネットワークがピーク時の混雑に見舞われたり、公平使用制限(FUP)が発動されたりすると、一般的な旅行用eSIMは通信速度を128kbpsまで絞り込むか、優先度を極端に下げてパケットロス率が80%以上に達することがあります。128kbpsまで落ちると、現代の暗号化されたTLSハンドシェイクすら失敗し、Googleマップ、Uberの配車確定、電子決済ゲートウェイなどの重要なサービスが完全に停止してしまいます。
これに対処するため、最適化されたローミングプロバイダーであるMollySIMは、ダイレクトルーティング経路を採用し、業界標準を大きく上回る384kbpsのフェアユースポリシー(FUP)基準値を設定しています。業界標準の3倍にあたる384kbpsのスループットを維持することで、必要不可欠なデータパケット(ベクターマップのレンダリング、Apple Payのトークン化、WhatsAppのテキスト送受信など)が滞りなく処理され、現地の回線混雑による通信の完全フリーズを回避できます。
QCIの構造解剖:キャリアのネットワーク優先度低下(デプライオリタイゼーション)の仕組み
🇯🇵 Japan High-Speed Travel eSIM & SIM Plans
Instant QR code activation, hotspot enabled, with guaranteed 384kbps fallback speed to keep Maps & Digital Wallets active.
隣にいる現地住民がスムーズに4K動画をストリーミング再生している横で、なぜ旅行用eSIMの通信は完全にストップしてしまうのでしょうか。その理由を理解するには、アンテナピクトの向こう側にある無線リソース割り当てレイヤーに目を向ける必要があります。セルラーネットワークはすべてのデータパケットを平等に扱っているわけではありません。3GPP(Third Generation Partnership Project)の標準仕様では、4G LTEにおけるQoS Class Identifier(QCI)、5G SA(スタンドアローン)ネットワークにおける5G QoS Identifier(5QI)によってトラフィックの分類が厳格に管理されています。
端末が現地の基地局(LTEのeNodeBまたは5GのgNodeB)に接続すると、渡航先キャリアのPCRF(ポリシー・課金ルール機能)が特定の優先順位数値を設定したEPSベアラーを割り当てます。この数値によって、物理的な無線スペクトラム上でパケットが送信される正確な順序が決まります。
QCI/5QIの階層:ローミングユーザーの位置づけ
すべてのネットワーク接続は、ミッションクリティカルな音声チャネルから最下位のバックグラウンドデータに至るまで、運用階層に基づいて順位付けされています。商用旅行用eSIMのほぼすべてを含むインバウンドローミングトラフィックは、原則としてこのピラミッドの最下層に位置づけられます。
| QoS識別子 | リソースタイプ | 優先度レベル | パケット遅延バジェット | 目標パケット損失率 | 代表的なサービス内容 |
|---|---|---|---|---|---|
| QCI 1 | GBR(帯域保証) | 2 | 100 ms | $10^{-2}$ | ミッションクリティカルな会話型音声(VoLTE / VoNR)。 |
| QCI 5 | Non-GBR(非保証) | 1 | 100 ms | $10^{-6}$ | IMSコアシグナリング(発呼制御、ネットワークハンドシェイク)。 |
| QCI 6 | Non-GBR(非保証) | 6 | 300 ms | $10^{-6}$ | 自社Tier-1のプレミアムポストペイドデータ(現地の主要プラン)。 |
| QCI 7 | Non-GBR(非保証) | 7 | 100 ms | $10^{-3}$ | 現地の中位ポストペイドデータ、モバイルゲーム、インタラクティブ動画。 |
| QCI 8 | Non-GBR(非保証) | 8 | 300 ms | $10^{-6}$ | 標準的な現地プリペイドプランおよび大手国内MVNOデータ。 |
| QCI 9 | Non-GBR(非保証) | 9 | 300 ms | $10^{-6}$ | インバウンド国際ローミング、一般的な旅行用eSIM、優先度の低いバルクデータ。 |
プロポーショナルフェアスケジューリング:基地局がパケットを破棄する仕組み
基地局は利用可能な周波数帯を物理リソースブロック(PRB)と呼ばれる時間と周波数の微小な単位に分割します。基地局内のスケジューラーはプロポーショナルフェア(PF)アルゴリズムを1秒間に数百回実行し、接続されている各デバイスにPRBを割り当てます。
ネットワーク負荷が中小規模の場合、スケジューラーはすべてのリクエストを容易に処理できます。しかし、国際空港の到着ゲート、ラッシュ時の混雑した駅、満員のスタジアムなど、混雑したセルセクターに入ると、PRBの利用率は100%に達し飽和状態に陥ります。
飽和に達すると、プロポーショナルフェアスケジューラーは通常の均等制御から積極的なリソース選別(トリアージ)へと切り替わります。
- キューバッファの割り当て: スケジューラーはQCI 6および7に割り当てられたキューを最優先で処理します。旅行用eSIMなどのQCI 9が付与された端末は、バッファの最後尾に追いやられます。
- バッファブロートとTCP遅延: QCI 9のパケットは送信スロットの割り当て待ち時間が長くなるため、往復時間(RTT)が急増します。通常40ms程度のPing値が瞬時に1,500ms以上に跳ね上がります。
- テールドロップ(Tail Drop): 基地局の受信バッファが完全に満杯になると、スケジューラーは「テールドロップ」を実行し、無線リンクに送られる前に低優先度パケットを直接破棄します。
- TCPバックオフの悪循環: スマホはパケット破棄をネットワーク障害と認識し、自動的にTCP送信ウィンドウサイズを縮小させるため、スループットはほぼゼロまで崩壊します。
旅行中の優先度低下によるボトルネックを克服する方法
接続先キャリアはピーク時、一時的なローミングユーザーよりも高額な料金を支払っている自社の正規契約者を常に優先するため、旅行用eSIMユーザーは深刻な速度低下に直面しがちです。一般的なeSIMでは、最下位のQCI 9割り当てに加えて128kbpsの厳しい速度制限が重なり問題が深刻化しますが、最適化されたソリューションはパケットオーバーヘッドを削減し、トラフィック基準値を引き上げることで影響を最小限に抑えています。
MollySIMのようなプロバイダーは、マルチキャリア間のレイテンシペナルティを最小限に抑えるルーティングを構築し、従来の旅行用eSIMの3倍となる384kbpsのフェアユースポリシー(FUP)最低速度を確保しています。優先度が下げられた128kbpsの接続では安全な暗号化ハンドシェイクすら維持できませんが、384kbpsのベースラインがあれば、Googleマップによるナビゲーション、Uberでの配車依頼、Apple Payによるトークン化決済などがタイムアウトすることなくスムーズに機能します。
「無制限」プランの落とし穴:フェアユースポリシー(FUP)と速度制限の実態
国際ローミング業界において、「無制限(Unlimited)」という言葉ほど乱用されているマーケティング用語はありません。格安eSIMプロバイダーが高速データ無制限を謳う場合、その多くは利用規約の奥深くに厳しいフェアユースポリシー(FUP)を潜ませています。現実には、接続先通信会社から請求される高額なホールセール中継コストがあるため、海外のセルラー網で本当に無制限・無減速のデータ通信を提供できる一般向け旅行用eSIMはほぼ存在しません。
実際には、日々の所定容量(通常500MB〜2GB程度)を超えた瞬間に、システムによって厳しい人為的帯域制限が課されることになります。
速度制限のアーキテクチャ:PCRFとセッションAMBR
現地の基地局の混雑状況に応じて動的に変動する「優先度低下」とは異なり、意図的な速度制限はパケットコアで直接適用される確定的かつソフトウェア強制的な速度上限です。
- トラフィック課金管理: データ通信を行うと、オンライン課金システム(OCS)が割り当てられたプロファイルに対して累積バイト数を監視します。
- ポリシー適用: 1日の上限に達した瞬間、PCRF(ポリシー・課金ルール機能)(5G SAコアではPCF)が動的ポリシー変更シグナルをPGW(パケットデータネットワークゲートウェイ)またはUPF(ユーザープレーン機能)に送信します。
- 帯域の強制絞り込み: コアネットワークがユーザーのAPN-AMBR(アクセスポイント名・集約最大ビットレート)を更新します。これにより、上り・下りのスループットは即座に本来の速度から大幅に絞り込まれ、一般的には128kbps、最悪の場合は64kbpsという壊滅的な速度に固定されます。
128kbpsおよび64kbpsが現代のWeb環境で使い物にならない理由
従来のローミングプロバイダーは、「128kbpsでもテキストメッセージのやり取りや緊急時のブラウジングには十分」と主張して制限を正当化してきました。しかし、現代のWebアーキテクチャにおいて、この主張は技術的に破綻しています。
現代のモバイルアプリは、もはや軽量なプレーンテキストだけを送受信しているわけではありません。すべての通信は強固な暗号化オーバーヘッドと複雑なクライアント側フレームワークで保護されています。
- TLS/SSLハンドシェイクの失敗: 安全なセッションを確立するには、暗号化証明書と公開鍵の交換(多くの場合6KB〜12KBのデータ量)が必要です。64kbpsや128kbpsに絞られた高遅延の国際ローミング回線では、この初期ハンドシェイクだけで数秒を要します。モバイルOSやアプリは厳格な接続タイムアウト(通常5〜10秒)を設定しているため、ユーザーデータが1バイトも表示されないうちに接続が強制終了されます。
- ベクタータイルの描画遅延: GoogleマップやApple Mapsなどのアプリは、静止画像ではなくMapboxベクタータイル(MVT)をストリーミング配信しています。128kbpsの制限回線では必要なベクターデータを素早くダウンロードできず、車での移動中や街中を歩いているときに地図が完全に真っ白になってしまいます。
- APIポーリングとトークンの失効: 配車アプリ(Uber、Grab)やモバイル決済ゲートウェイ(Apple Pay、Googleウォレット)は、位置情報の同期や暗号化トークンの交換のために、クライアントとサーバー間で高速なAPIポーリングを実行します。速度制限された回線ではこれらのAPIリクエストがキューから脱落し、「ネットワーク接続エラー」が頻発します。
速度制限時における実用性の比較
| アプリ / モバイルタスク | 64 kbps(極度の制限) | 128 kbps(従来の制限) | 384 kbps(MollySIM 最適化FUP) |
|---|---|---|---|
| テキストメッセージ(WhatsApp、Signal) | 使用可能(若干の遅延あり) | 問題なく利用可能 | 問題なく利用可能 |
| セキュアなTLS/SSLハンドシェイク | ❌ 失敗 / タイムアウト | ⚠️ 不安定(高い切断率) | ✅ 完全に安定して動作 |
| 地図・ベクタータイル(Googleマップ等) | ❌ 完全に使用不可 | ❌ タイル読み込みタイムアウト | ✅ スムーズな描画・ルート更新 |
| 配車サービス(Uber、Grab、Bolt) | ❌ APIタイムアウト | ⚠️ 不安定 / 配車確定失敗 | ✅ 問題なく利用可能 |
| スマホ決済(Apple Pay / Google Pay) | ❌ トークン認証失敗 | ⚠️ 断続的にエラー発生 | ✅ 即時認証 |
| VoIP音声通話(LINE / FaceTime通話) | ❌ 激しいパケットロス/ロボット声 | ⚠️ パケット欠落(15-25%) | ✅ クリアな音声(Opusコーデック安定) |
実用的なFUPアーキテクチャによる通信環境の維持
完全に通信が途絶える状態と、頼れるバックアップ回線として機能する状態の決定的な差は、現実的なポリシー制限を設計できているかどうかにあります。従来の「無制限」プランがユーザーを実用に耐えない64kbpsや128kbpsの状態に縛り付けるのに対し、先進的なプロバイダーは高速容量を使い切った後でも重要なデータ通信が維持できるようにPCRFエンジンを構成しています。
384kbpsのフェアユースポリシー最低速度を確立することで、MollySIMは一般的な市場水準の3倍のスループットを実現しています。この384kbpsという速度基準によって、SSL/TLS証明書のスムーズな交換、地図データの読み込み、決済APIの即時処理が保証され、1日の上限を超えてしまった場合でも旅先で立ち往生する心配がありません。
通信制限(Throttling)対 ネットワーク優先度低下(Deprioritization)の比較
どちらもスマートフォン上では「深刻な通信ラグ」として体感されますが、通信速度制限(ハードスロットリング)と動的な優先度低下(デプライオリタイゼーション)は、セルラーネットワークの全く異なる階層で動作しています。
通信速度制限は、PCRFおよびUPFレベルで適用される確定的かつソフトウェア制御の帯域上限です。あらかじめ設定された高速データ容量を使い切ると、現地の基地局の空き容量に関係なく、最大通信速度が厳格に制限されます。
一方、ネットワーク優先度低下は動的かつ一時的なものであり、無線アクセスネットワーク(RAN)のリソース割り当てによって引き起こされます。ローミングeSIMは通常、現地の正規ポストペイド契約者(QCI 6または7)に比べて低い優先度(QCI 8または9)が設定されています。現地のセルセクターが混雑すると、基地局のスケジューラーはまず現地の主要ユーザーに無線リソースブロック(RRB)を割り当てるため、低優先度のローミングプロファイルのパケットは順番待ちに回されるか破棄されます。
| 比較項目 | 通信速度制限(FUP / 容量超過) | 動的優先度低下(QCIによる選別) |
|---|---|---|
| 主な発生要因 | プラン規定のデータ通信量の上限到達 | 基地局の混雑、過密なユーザー密度、低いQCI階層 |
| 制御ポイント | コアネットワーク(PCRF / PGW / UPF による帯域制御) | 無線アクセスネットワーク(eNodeB / gNodeB スケジューラー) |
| スループット挙動 | 一定の固定上限(例: 64kbps、128kbps、384kbps) | 不安定:高速通信とゼロ付近を激しく行き来する |
| 遅延・RTTへの影響 | 通常のRTTだが、パケット滞留によるアプリ遅延が発生 | 極端なRTT急増(500ms〜2500ms)、バッファブロート |
| パケット損失率 | 低(パケットは遅延・シェーピングされ、破棄はされない) | 高(無線インターフェース上で突発的なパケット破棄が発生) |
| 解消方法 | プランの更新、データ追加購入、日付更新によるリセット | 混雑していない基地局への移動、混雑時間帯の経過待ち |
通信制限・混雑時における主要アプリのパフォーマンステスト
これらのネットワーク制約が実際の旅行にどのような影響を与えるかを検証するため、主要な旅行関連アプリを用いて一般的な市場制限(128kbps)、MollySIMの最適化FUP(384kbps)、および深刻な優先度低下(混雑エリア)の3つの状態でベンチマークテストを実施しました。
+---------------------------------------------------------------------------------------+
| アプリケーション挙動ベンチマークテスト |
+----------------------+--------------------+--------------------+----------------------+
| サービス / アプリ | 128kbps 制限時 | 384kbps 制限時 | 動的優先度低下(混雑時) |
+----------------------+--------------------+--------------------+----------------------+
| Googleマップ(描画) | タイル読込に18〜35秒 | 2〜4秒でスムーズ描画| 断続的なタイムアウト |
| LINE/WhatsApp通話 | 音声途切れ / 切断 | クリア(Opus採用) | 激しいジッター/ロボット声|
| Uber(配車・API) | 認証タイムアウト/失敗| 迅速な配車確定 | ドライバー位置更新の失敗 |
| 1080p動画ストリーミング| 完全再生不可(ABR) | 音声のみ / 240p | 激しい停止・バッファリング|
+----------------------+--------------------+--------------------+----------------------+1. Googleマップのベクターナビゲーションとルート検索
- 128kbps制限下: ベクタータイル(Protobuf形式)の並列読み込みに失敗します。新しいエリアにスクロールすると灰色のグリッドが表示されたままになり、HTTP/2の多重通信が滞るため、ルートの再検索に25〜40秒以上かかります。
- 384kbps制限下: 画面あたりのベクターデータ量は平均20〜50KBであるため、MollySIMの384kbpsベースラインなら1.5〜3秒で読み込みが完了します。TLSセッションが維持され、衛星写真などの重いデータを省きながら、音声ナビやルート案内が体感遅延なしで更新されます。
- 動的優先度低下時: 地図データのリクエストで無線リンク制御(RLC)の再送が頻発します。名目上の帯域幅が十分に見えても、激しいパケットロスによってTCPウィンドウが縮小し、ナビゲーションの途中で地図の更新が止まります。
2. WhatsApp、LINE、FaceTimeオーディオ(VoIP通話)
- 128kbps制限下: VoIP通話では6kbpsから32kbps程度で可変するOpusなどの音声コーデックが使われます。理論上は帯域が足りているように見えますが、OSのバックグラウンド通信が128kbpsの細い帯域を埋めてしまい、バッファブロートが発生して声がロボットのように歪んで途切れます。
- 384kbps制限下: 帯域に余裕があるため、バックグラウンドのデータ通信からVoIPストリームが保護されます。ジッターバッファが40ms未満で安定し、クリアな双方向通話が可能です。
- 動的優先度低下時: RANの混雑時にUDPトラフィックが容赦なく破棄されるため、通話の無音化が頻発し、最終的に強制切断されます。
3. 配車アプリと位置トラッキング(Uber、Grab、Bolt)
- 128kbps制限下: 配車アプリはドライバーの位置追跡、料金確認、決済トークンの送受信に常時WebSocket接続と頻繁なREST API呼び出しを使用します。128kbpsの環境では暗号化ハンドシェイク(TLS 1.3)がサーバー側のタイムアウト(通常10〜15秒)を超過し、配車リクエストが失敗します。
- 384kbps制限下: トークンの交換とドライバーのGPS座標の更新がスムーズに行われ、決済認証エラーや画面のフリーズを防ぎます。
- 動的優先度低下時: 断続的なパケットロスによって確立されたWebSocketセッションが切断され、ドライバーのアイコンがワープしたり、すでに到着しているのに画面上では止まったまま表示されたりします。
4. 動画ストリーミングとSNS(Instagram、YouTube、TikTok)
- 通信制限下(128kbpsおよび384kbps共通): アダプティブビットレート(ABR)アルゴリズムが帯域幅の上限を即座に検知します。1080pや4Kの再生は完全に不可能です。384kbpsであれば低画質プレビューやテキスト主体のフィードの閲覧は可能ですが、リールやショート動画はバッファリングが頻発します。
- 動的優先度低下時: 一時的なスループット向上時に動画プレイヤーが高ビットレートの動画セグメントを取得しようとしますが、優先度の高い一般ユーザーに無線ブロックが回収された瞬間に再生がフリーズします。
MollySIMのアーキテクチャ:高優先度ルーティングと実用的な384kbps最低速度
通信パフォーマンスの低下を防ぐには、コアネットワークのルーティングレベルと卸売ローミングプロファイルの設計の両面で技術的なアプローチが必要です。格安eSIM事業者の多くは単なるリセラーであり、最も安価な卸売データ回線を取りまとめて転売しています。このモデルは深刻なルーティング遅延を引き起こし、海外ユーザーを最下位のQCI(サービス品質クラス)に追いやることになります。
これに対し、MollySIMはエッジ分散型の中継回線、最適化されたローミングQoSプロファイル、そして現代のアプリケーション要件を満たす確固たる通信基準値をベースとしたインフラモデルを構築しています。
+-------------------------------------------------------------------------+
| 従来の格安eSIM(ホームルーティング) |
| ユーザー(東京) ---> 現地基地局 ---> 欧州/香港へのトンネル ---> ネット |
| 遅延: 350ms以上 | 低QCI(優先度最下位) | 容量超過後: 128kbps(通信不可) |
+-------------------------------------------------------------------------+
+-------------------------------------------------------------------------+
| MOLLYSIMのアーキテクチャ(ローカルブレイクアウト) |
| ユーザー(東京) ---> 現地基地局 ---> 現地エッジPGW/UPF ---> ネット |
| 遅延: 40ms未満 | 高QCI優先設定 | 容量超過後: 384kbps(実用可能) |
+-------------------------------------------------------------------------+1. ダイレクト・ローカルブレイクアウト(LBO)ゲートウェイ対 高遅延ホームトンネリング
ユーザーが海外のセルラー基地局に接続した際、パケットデータネットワークゲートウェイ(PGW)またはユーザープレ
🇯🇵 Japan High-Speed Travel eSIM & SIM Plans
Instant QR code activation, hotspot enabled, with guaranteed 384kbps fallback speed to keep Maps & Digital Wallets active.