東京の地下鉄を攻略：2026年版 日本eSIM 地下鉄・メトロ電波完全ガイド

---

地下の電波課題：東京メトロと都営地下鉄のネットワーク構造

東京の地下鉄ネットワークは、東京メトロ（9路線、195.1 km）と都営地下鉄（4路線、109.0 km）という2つの異なる事業者によって運営されている世界有数の交通網です。毎日1,000万人以上の通勤・通学客が利用し、シームレスに相互直通運転が行われていますが、路線の建設時期、トンネルの深度、構造物の密度の違いにより、電波（RF: Radio Frequency）にとっては非常に厳しい環境となっています。

`` +-----------------------------------------------------------------------------------+ | 地上 / ストリートレベル | +-----------------------------------------------------------------------------------+ | [B1-B2] コンコース・改札階 ---> 分散型アンテナシステム (DAS) | | [B3-B4] 東京メトロ線 (銀座線、丸ノ内線など) ---> マイクロセル基地局 | | [B5-B7] 深部 都営線 (大江戸線 六本木駅 -48mなど) ---> 漏洩同軸ケーブル (LCX) | +-----------------------------------------------------------------------------------+ ``

深度の違い：開削工法 vs. シールド工法

地下における電波の伝搬特性は、路線の建設工法や年代によって大きく異なります。

• 浅い開削工法の路線（東京メトロ銀座線・丸ノ内線）： 地表近く（地下約5〜15m）に建設されたこれらの路線では、鉄筋コンクリートスラブや地下埋設物による一般的な電波減衰が発生するものの、地上の大型基地局（マクロセル）からの電波が改札階やコンコースまである程度届きます。
• 深いシールド工法の路線（都営大江戸線・東京メトロ副都心線）： 既存のインフラの下を掘り進めて建設されたため、大深度の岩盤層に位置しています。特に都営大江戸線の六本木駅（1番線ホーム）は地表から地下48メートル（逆さにした14階建てビルに相当）にあります。この深さでは地上のマクロセルからの電波は一切届かず、トンネル内に設置された専用通信インフラに100%依存することになります。

地下の無線通信インフラ：LCXとDAS

地下トンネル内を時速80kmで走行する電車内でもシームレスな通信ハンドオーバー（基地局の切り替え）を維持するため、日本の大手通信キャリア（NTTドコモ、KDDI、ソフトバンク、楽天モバイル）は鉄道事業者と協力し、主に2つの配信方式を採用しています。

1. 漏洩同軸ケーブル（LCX）： 通常の指向性アンテナの代わりに、トンネルの壁面に沿ってスリット（穴）の入った同軸ケーブルを連続して敷設します。このスリットから制御された電波（Sub-6 GHz 5GおよびLTEバンド 1/3/8/18/19/28）を直接電車の窓に向けて照射することで、ステンレス製車両によるファラデーケージ効果（電波遮遮断）を打ち消します。
2. 分散型アンテナシステム（DAS）＆マイクロセル： 新宿（出口数200以上）、東京駅、渋谷などの巨大ターミナル駅には、多層構造の地下街が広がっています。通信事業者は天井にDASノードや超小型マイクロセルを15〜30m間隔で高密度に配置し、音声やデータのトラフィックを均等に分散させて、混雑するホームや乗り換え階段での通信ボトルネックを防いでいます。

---

ネットワークアーキテクチャの比較

---

高速マイクロセルハンドオーバーとローミング遅延の問題

電車が駅を出発して加速する際、乗客のスマートフォンは急速なセルハンドオーバーを実行し、わずか3〜6秒ごとにマイクロセルを切り替えることがあります。一般的な海外キャリアのシングル回線ローミングeSIMでは、ハンドオーバーの認証要求が遠く離れた本国のルーティングサーバーを経由するため、地下でのセル切り替え時にレイテンシの急上昇やパケットロスが発生しがちです。

さらに、データ容量の超過などにより速度制限がかかると、従来の旅行用eSIMは実用性のない128kbpsまで低速化され、乗換案内アプリすら開けなくなります。これに対し、公共交通機関での利用に最適化されたMollySIMなら、低遅延なローカルルーティング経路を確保しつつ、384kbpsのフェアユースポリシー（FUP）基準速度を提供します。この3倍の通信速度により、Googleマップのリアルタイムホーム案内、ジョルダン、Apple WalletのSuica残高更新などの必須ツールが、東京中心部の地下深くでも途切れることなく動作します。

地下キャリア対決：NTTドコモ vs. ソフトバンクの地下リピーター性能

東京の地下鉄ネットワークは、トンネル壁面に敷設された漏洩同軸ケーブル（LCX）とホーム天井に設置された分散型アンテナシステム（DAS）の緻密な組み合わせで成り立っています。しかし、日本の主要通信キャリアであるNTTドコモとソフトバンクが採用している電波アーキテクチャには違いがあり、改札を通って地下へ降りた後の実際の通信パフォーマンスに明確な差が現れます。

`` 地下信号アーキテクチャ（東京メトロ / 都営線） ======================================================================== [ホーム マイクロセル] ──> バンド1 (2.1GHz) / バンド3 (1.8GHz) [大容量] │ (発車時のハンドオーバー) ▼ [トンネル内 LCX] ──> ドコモ: バンド19 (800MHz) / バンド28 (700MHz) ソフトバンク: バンド8 (900MHz「プラチナバンド」) ======================================================================== ``

サブGHz帯の展開：Band 19 vs. Band 8

• NTTドコモ（バンド 1, 3, 19, 28）： ドコモの地下バックボーンは、主力「プラチナバンド」であるバンド19（800 MHz）に大きく依存しており、バンド28（700 MHz）がそれを補完しています。バンド19はコンクリート柱の回り込みや複数階にまたがる階段の吹き抜けなどにおいて優れた電波伝搬特性を発揮します。そのため、国会議事堂前駅の千代田線ホームや大手町駅の深い連絡通路など、地下深く入り組んだコンコースではドコモに分があります。
• ソフトバンク（バンド 1, 3, 8）： ソフトバンクは地下の浸透にバンド8（900 MHz）を活用し、ホーム天井のバンド3（1.8 GHz）スモールセルアレイと組み合わせています。見通しの良い近代的なホームではソフトバンクのピーク帯域幅がドコモを上回ることが多い一方、1960年代に造られた古いコンクリート隔壁の連絡通路などでは、バンド8の電波がわずかに弱くなるスポットが存在します。

---

ラッシュ時の「アンテナピクトはフルなのに通信できない」現象

通勤ラッシュのピーク時間帯（8:00〜9:30および17:30〜19:00）、山手線、丸ノ内線、都営大江戸線などの満員電車内では、スマートフォンの画面上に5GやLTEの電波強度が最大（フルバー）と表示されているにもかかわらず、データ通信がまったく通らないというイライラする現象が起きることがあります。

これは電波の受信不良ではなく、PRB（Physical Resource Block：物理リソースブロック）の枯渇とPDCCH（物理下りリンク制御チャネル）の輻輳（混雑）が原因です。地下のリピーターは強い参照信号（RSRP）を発信し続けているためスマホ側は「強電波」と認識しますが、そのマイクロセルを処理する地下の基地局ベースバンドユニット（BBU）のスケジューリング容量が上限に達してしまっています。その結果、アップリンク要求が順番待ちになるか破棄され、パケットロスが直ちに発生します。

この混雑時に旅行用eSIMが128kbpsに制限されていると、ネットワークタイムアウトが頻発します。これによりApple WalletでのSuicaエクスプレスチャージが失敗したり、乗り換え途中に地図がフリーズしたりします。MollySIMのようなチューニングされた通信サービスを利用すれば、このボトルネックを回避できます。低遅延なルーティングを維持し、一般的な旅行用eSIMの3倍にあたる384kbpsの最低FUP速度を保証しているため、ラッシュ時の混雑したセルハンドオーバー中であっても、Apple Payの残高同期、リアルタイム遅延情報、NAVITIMEの乗換案内などの重要データがしっかりと処理されます。

---

インフラ＆ハードウェア詳細比較

電波途切れがもたらすトラブル：Suicaチャージ失敗、ナビの不具合、改札での立ち往生

地下鉄網は電波環境として非常に過酷です。東京のような過密都市の地下でネットワークハンドオーバーが失敗したりパケットロスが跳ね上がったりすると、SNSの読み込みが遅れるだけでなく、はるかに深刻な問題を引き起こします。コンマ数秒単位のデジタル処理で人の流れを維持している東京では、通信の途切れが即座にトラブルへと繋がります。

`` +-----------------------------------------------------------------------------------+ | 地下鉄改札で立ち往生するメカニズム | +-----------------------------------------------------------------------------------+ | 1. ICカードチャージ開始 2. 地下でのパケット喪失 3. 改札の扉が閉まる | | [ Apple / Google Wallet ] -> [ TLSハンドシェイク切断 ] -> [ FeliCaタイムアウトエラー ]| | (約15KBのデータ通信) (高ローミング遅延) (改札口の渋滞発生) | +-----------------------------------------------------------------------------------+ ``

---

1. モバイルSuica/PASMOチャージの失敗：TLSハンドシェイクの中断

SonyのFeliCa（NFC-F）技術を採用し、Apple WalletやGoogle Walletに登録されたデジタル交通系ICカードは、改札機へのタッチ自体は200ミリ秒未満の完全オフラインで処理されます。しかし、残高のチャージ処理は完全にオンラインで行われます。

改札に向かいながらスマホでチャージを行う際、端末はJR東日本のモバイルSuica決済ゲートウェイまたはPASMOの処理バックエンドと暗号化されたTLS 1.3セッションを開始します。このやり取りでは、端末、クレジットカード決済ネットワーク（トークン化サーバー）、鉄道事業者の残高元帳の間で、複数回の迅速な往復データ通信（パケット送受信）が必要です。

• 失敗のメカニズム： 地下の電波の死角に入ったり、LCXのセル切り替え中にパケットロスが発生すると、認証の途中でTLSハンドシェイクが切断されます。
• その結果： クレジットカード側には請求予定が表示されるものの、FeliCaチップには残高が書き込まれず、交通系ICカードが「カード残高更新中...」などのロック状態に陥ります。
• 改札での影響： ロックされたカードや残高不足のカードをタッチすると、即座に改札の赤いフラップ扉が閉まり警告音が鳴り響いて、後ろに続く利用客の流れを完全に止めてしまいます。

---

2. 深い地下階での位置特定とナビゲーションの不具合

渋谷駅（東急東横線・副都心線が位置する地下5階への移動など）や、複数の事業者が入り組む大手町駅のような東京の巨大地下ハブでは、衛星からのGNSS/GPS信号は完全に遮断されます。そのため、GoogleマップやAppleマップなどのナビゲーションアプリは、携帯電話基地局による三角測量（Cell-IDおよびTiming Advance）、駅構内Wi-FiのBSSIDフィンガープリント、端末内蔵センサーの自律測位（デッドレコニング）だけに頼ることになります。

`` 地下ナビゲーションの処理フロー [ 基地局タイミング情報 ] + [ 駅Wi-Fi BSSID ] + [ IMU / ジャイロセンサー ] │ (有効なデータ通信が必須) ▼ [ リアルタイム階層解析＆ターンバイターン案内 ] ``

通信が不安定になったり、ローミング経由で大きな遅延が発生すると、以下のような問題が生じます。

• 階層位置のズレ： 地図エンジンが複数フロアの垂直位置を判別できなくなり、地下4階のホームにいるのに地下2階のコンコースにいると誤認します。
• 案内画面のフリーズ： 方向を示すコンパスが固まり、進路案内がダウンロードできなくなり、動的な出口案内（例：渋谷駅のA1出口と14b出口の識別など）が消えてしまいます。
• 駅構内での迷子： 混雑する通路の脇に避けて案内看板を探さざるを得なくなり、電車の乗り換え時間を逃してしまう原因になります。

---

3. 改札口での大混雑と通行トラブル

東京の自動改札機は、朝夕のラッシュ時には1通路あたり毎分40〜60人の乗客を処理しています。たった1人がチャージの失敗やナビのフリーズで改札機を塞ぐだけで、背後に一瞬で人の渋滞が発生します。

このエラーを解消するには、人の波から外れて有人の改札窓口へ行き、駅員にFeliCaの処理ログを手動でリセットしてもらう必要があります。もしeSIMのデータ通信が完全に途切れていると、デジタルカードへの再チャージもできず、乗換案内を見せて入場駅を駅員に説明することも、別のデジタル乗車券を購入することもできなくなってしまいます。

---

4. 安定した通信環境と最低帯域の確保がトラブルを防ぐ

交通機関関連の通信や地下での地図表示には、大きな通信容量（帯域幅）は必要ありませんが、パケット配信の確実性と最低限保証される通信速度に対して極めて敏感です。

一般的な海外旅行用eSIMの多くは、1日のデータ容量を使い切ると128kbpsに速度を制限します。しかしこの速度では、銀行側の認証ゲートウェイにおける厳しいTCPタイムアウト設定により、モバイル決済のハンドシェイクに失敗することが頻繁にあります。

こうしたトラブルを防ぐため、MollySIMはNTTドコモおよびソフトバンクのインフラへの低遅延ルーティングに加え、384kbpsのフェアユースポリシー（FUP）最低速度を採用しています。従来の制限速度の3倍で通信できるため、バックグラウンドでのTLSハンドシェイク、モバイルSuicaの更新、地図のベクターデータ描画が、東京の最も深い地下通路であっても確実に完了します。

日本旅行向けデュアルSIM設定＆APN最適化ガイド

東京の複雑な交通網をスムーズに移動するには、リアルタイムの乗り換え案内、運賃計算、チャージ用のモバイルバンキングアプリへのシームレスなアクセスが欠かせません。一方で、海外旅行中であっても自国の銀行から送られてくる2段階認証（2FA）のSMSコードを受信できる状態を維持する必要があります。デュアルSIM・デュアルスタンバイ（DSDS）を正しく設定することで、主回線で通話とSMSを待受にしつつ、すべてのデータ通信を現地の旅行用eSIMへ割り振ることができます。

---

DSDS設定：2段階認証SMSを受信しつつデータ通信を完全に分離する

自国SIMの高額な国際データローミング料金を回避しながら、無料の認証SMSを確実に受信するため、羽田空港や成田空港に到着する前に以下の設定を行ってください。

`` [自国SMS受信 (認証コード/銀行)] ───► 主回線 物理SIM (データローミング: オフ) ┌─► 東京メトロ / 都営地下鉄 [高速モバイルデータ通信＆地図] ───► MollySIM eSIM (データローミング: オン) ──┼─► Apple/Google Pay └─► Suica / PASMO チャージ ``

Apple iOSの設定手順

1. 「設定」>「モバイル通信」を開きます。
2. 「デフォルトの音声回線」を自国の主回線SIMに設定します。
3. 「モバイルデータ通信」で日本のeSIMプロファイル（例：MollySIM）を選択します。
4. 重要設定： 「モバイルデータ通信の切替を許可」を必ず「オフ」にします。これがオンになっていると、地下鉄のトンネルなどでeSIMの電波が弱まった際に、iOSが自動的に自国SIMの高額なローミングデータ通信へ切り替えてしまいます。
5. 主回線SIMをタップし、「データローミング」が「オフ」になっていることを確認します。
6. 日本のeSIMをタップし、「データローミング」が「オン」になっていることを確認します。

Android（Samsung One UI / Google Pixel）の設定手順

1. 「設定」>「ネットワークとインターネット（または接続）」>「SIMマネージャー」を開きます。
2. 「通話」と「メッセージ」を主回線SIMに設定します。
3. 「モバイルデータ」を日本のeSIMのみに設定します。
4. 「データの自動切替」または「副回線への自動切り替え」を無効（オフ）にします。
5. 日本のeSIMプロファイル設定を開き、「データローミング」を「有効（オン）」にします。

---

APN設定と古いプロファイルの競合解消

ほとんどの高品質なeSIMは、最初の電波接続時にAPN（アクセスポイント名）が自動設定されます。しかし、以前利用したMVNO（Ubigi、Airalo、または自国の格安SIMなど）の古い構成プロファイルが端末内に残っていると、ルーティングテーブルが干渉を起こし通信エラーになる場合があります。

`` トラブルシューティングのヒント：「ゴーストプロファイル」の不具合 地下でNTTドコモやソフトバンクのアンテナがフルに立っているのにWebページが開かない（DNS解決ができない）場合は、古い構成プロファイルが残っていないか確認してください。iOSでは「設定」>「一般」>「VPNとデバイス管理」を開きます。「構成プロファイル」内に古いeSIMや会社の管理プロファイル（MDM）が残っている場合は削除してください。※「すべてのネットワーク設定をリセット」は行わないでください。保存済みの駅Wi-FiパスワードやBluetoothペアリング情報まで消去されてしまいます。 ``

---

ネットワーク選択の仕組み：空港特急から地下鉄へ

成田空港からの京成スカイライナーや羽田空港からの東京モノレールなど、地上の高速列車に乗っている間、スマートフォンは地上の大型基地局（マクロeNB/gNB）に接続しています。その後、電車が上野、新橋、東京駅などの地下ターミナルへ進入すると、端末は地下の分散型アンテナシステム（DAS）へ公衆陸上移動体ネットワーク（PLMN）のハンドオーバーを急速に行う必要があります。

自動選択 vs. 手動PLMN選択

• 自動選択（推奨）： 最新のOSは、電波強度の強いRSRPを定期的に自動スキャンします。地上を歩く際には最適ですが、地上から地下へ一気に潜る際、自動スキャンが追いつかず最大90秒ほど通信が途切れることがあります。
• 手動ネットワーク切り替え： 地下深くの駅（都営大江戸線の六本木駅など）に入り、端末が電波を探し続けて復帰しない場合は以下の操作を試してください。

1. 「設定」>「モバイル通信」>「ネットワーク選択」を開きます。
2. 「自動」をオフにします。
3. スキャン完了後、「NTT DOCOMO（PLMN 440-10）」または「SoftBank（PLMN 440-20）」を手動で選択して固定します。

登録タイマーを即座にリセットしたい場合は、「機内モード」を15秒間オンにしてからオフにしてください。端末を再起動することなく、ベースバンドプロセッサから地下DASノードへ新規のAttach Request（接続要求）を強制送信できます。

手動でのバンド制御に加え、NTTドコモ/ソフトバンクのコアネットワークへ直結し、一般的な制限速度（128kbps）の3倍にあたる384kbpsのフェアユースポリシー速度を提供するMollySIMを組み合わせることで、改札での締め出しを防ぎ、地図をスムーズに表示させ、東京の地下深くにいても安全な認証通信を維持できます。

2026年におけるMollySIMの優位性：デュアルキャリア冗長化と384kbpsの最低速度保証

13の路線と数百もの多層構造の地下駅が交差する東京の複雑な地下鉄網を移動するには、一般的なシングル回線のローミングでは不十分です。地下空間における基地局の負荷状況は地上とは大きく異なります。朝夕の通勤ラッシュ時、大手町、新宿、池袋などの乗り換えハブ駅では、単一キャリアの分散型アンテナシステム（DAS）におけるPRB（物理リソースブロック）使用率が95〜100%に達し、通信が飽和状態に陥ることがあります。

MollySIMは、過密な都市部での利用に特化して設計されたインテリジェント・デュアルキャリアアーキテクチャと、業界トップクラスのフェアユースポリシー（FUP）により、この混雑問題をスマートに解決します。

`` ┌────────────────────────────────────────┐ │ MollySIM インテリジェントコア │ └───────────────────┬────────────────────┘ │ ┌───────────────────────┴───────────────────────┐ ▼ ▼ ┌─────────────────────────┐ ┌─────────────────────────┐ │ NTTドコモ バックボーン │ │ ソフトバンク バックボーン│ │ (PLMN 440-10) │ │ (PLMN 440-20) │ │ 地下主力 Band 19 │ │ 深部浸透 Band 8 │ └────────────┬────────────┘ └────────────┬────────────┘ │ │ └───────────────────────┬───────────────────────┘ ▼ ┌────────────────────────────────────────┐ │ 地下でのリアルタイム自動ハンドオーバー │ │ (地下通路でもパケットロス ゼロを実現) │ └────────────────────────────────────────┘ ``

動的マルチIMSIアーキテクチャ：NTTドコモ＆ソフトバンク相互接続

一般的な旅行用eSIMは、接続先が単一の現地ネットワークに固定されています。もし東京メトロ丸ノ内線や都営三田線の特定のトンネル内でそのキャリアの漏洩同軸ケーブル（LCX）やリピーターが点検中だった場合、端末は「圏外」になるか、反応のない電波を掴み続けてしまいます。

MollySIMは、日本の2大ティア1キャリア間を動的に切り替えるコアスイッチング技術を採用しています。

• NTTドコモ（PLMN 440-10）： バンド19（800 MHz）による圧倒的な地下浸透力と、東京メトロ各駅ホームに張り巡らされた高密度なバンド1/3 DAS設備。
• ソフトバンク（PLMN 440-20）： 深い都営地下鉄の各線や地下街において優れた局所通信容量と低周波バンド8（900 MHz）のカバレッジを発揮。

一方のキャリアで電波の劣化や基地局の混雑が発生した場合でも、MollySIMのプロファイルにより端末側でシームレスにPLMNの切り替えが行われるため、データセッションが切断されたり改札前で立ち往生したりする心配がありません。

---

384kbpsの最低速度保証：なぜ地下では128kbpsだと機能しないのか

1日の高速データ容量を使い切った後、従来の旅行用eSIMは64kbpsまたは128kbpsに速度を制限します。実験室の環境では128kbpsでも通信できるように思えますが、実際の地下空間では、高いパケットジッター、350msを超える高レイテンシ（RTT）、TLS 1.3のハンドシェイクタイムアウトなどが重なり、完全に通信不能に陥ります。

MollySIMは、業界標準である128kbpsの3倍、旧来の64kbpsの6倍にあたる384kbpsの通信速度を常時保証（FUP下限値）しています。

---

技術解説：384kbpsで主要交通アプリが快適に動く理由

384kbps（実測ダウンロードスループット約48 KB/s）が維持されていれば、移動に必須のすべてのアプリで安定したTCP/IPウィンドウ制御が行われ、セッションの強制リセットを防ぐことができます。

`` +-------------------------------------------------------------------------------+ | 下り帯域幅の割り当て挙動 | +-----------------------------------+-------------------------------------------+ | プロトコル / サービス | ペイロードサイズと通信挙動 | +-----------------------------------+-------------------------------------------+ | Googleマップ ベクタータイル (pbf) | 1タイル約20〜35KB、1秒未満で処理完了 | | モバイルIC (Suica/PASMO) JSON同期 | 約3〜8KBの暗号化データ、200msで完了 | | LINE / WhatsApp 通話 (Opusコーデック)| 約6KB/sの固定ビットレート、音飛びなし | | ジョルダン / NAVITIME 乗換API | 約12〜18KBの応答データ、瞬時にレンダリング| +-----------------------------------+-------------------------------------------+ ``

1. ベクターベースの地図描画（Googleマップ / Appleマップ）： 最新の地図アプリは、重い画像データではなく軽量な.pbf（Protocolbuffer）ベクタータイルを読み込みます。タイル1枚のサイズは平均15〜35KBです。384kbpsの速度があれば、周囲の地下コンコース、出口番号、ホーム階層のデータを数秒でダウンロードして描画でき、地図がグレーのグリッドのまま固まることがありません。
2. モバイルSuica＆Apple Payウォレットの認証通信： 交通系ICカードの残高更新やアプリ内チャージには、迅速な往復TLS認証が必要です。Apple WalletとJR東日本サーバー間でやり取りされるJSONデータは非常に軽量（通常10KB未満）です。384kbpsの帯域があれば、サーバー側の5秒タイムアウト制限に引っかかることなく確実に通信が完了します。
3. 低ビットレートVoIP通話： LINE、WhatsApp、FaceTime Audioなどの通話アプリは、16kbps〜24kbpsの高効率ビットレートに動的調整されるOpusなどの適応型コーデックを使用しています。384kbpsのパイプラインがあれば、バックグラウンドのプッシュ通知を処理しながらでも、クリアな双方向音声通話を行うのに十分な余裕があります。
4. リアルタイム乗換案内： NAVITIME、ジョルダン、Tokyo Subway Navigationなどの乗換検索APIが送受信するデータ量は極めてわずか（1回の検索で20KB未満）です。384kbpsの速度があれば、地下ホーム間を移動している最中でも瞬時にルートの再検索が完了します。

東京の地下鉄を快適に乗りこなすプロの技：通信環境とバッテリーを最適化するテクニック

900以上の駅と13の地下鉄路線が複雑に交差する東京都市圏の鉄道網を移動する際は、適切な端末設定を行っておくことが重要です。