eSIM転送とは？機種変更で移せない理由と転送の仕組みを解説

こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスでプロジェクトマネジメントを担当している比嘉です。 本記事では、機種変更のときに話題になる「eSIMの転送(移行)」を取り上げます。なぜ物理SIMのように差し替えられないのか、Apple/Googleのクイック転送とGSMA標準のDevice Changeがどう関係するのかを整理します。

はじめに

物理SIMカードの機種変更は、カードを抜いて新しい端末に挿すだけで完了します。ところがeSIMでは、旧端末から新端末へプロファイルを「移す」操作が必要になり、手順は事業者やOSによってまちまちです。ここが、eSIMがユーザー体験の面で物理SIMに劣ると言われてきた最大の理由です。

本稿では、以下の項目をSGP.22 v3.1に基づいて整理します。

• eSIMプロファイルが端末間でコピーできない理由

• SGP.22 v3で標準化されたDevice Change手続きの流れ

• Apple/Googleが先行して実装した独自クイック転送との関係

• 転送時の制約と、サービス提供側が押さえるべき実務ポイント

1. まず全体像から — eSIM転送をざっくり理解する

最初に押さえるべき事実は1つです。

「eSIM転送 ＝ プロファイルの移動ではなく、旧端末での削除と新端末への再ダウンロード」

eSIMのプロファイルは、音楽ファイルのように端末から端末へコピーできるデータではありません。プロファイルは配送の時点で宛先のeUICC(eSIM用の耐タンパチップ)専用に暗号化されており、別のチップに入れることはそもそも暗号的に不可能です。銀行の貸金庫にたとえると、プロファイルは「特定の金庫の中でしか開封できない封筒」で届きます。金庫ごと交換するなら、封筒を取り出して持ち運ぶのではなく、発行元に「新しい金庫宛にもう一度送ってください」と依頼するしかありません。

したがって、世の中のあらゆる「eSIM転送」機能は、見た目がどれだけシームレスでも、内部では次の3ステップを実行しています。

違いが出るのは「(1)の依頼をどう伝えるか」「(4)のきっかけ(Activation Code)をどう新端末に渡すか」の部分です。ここを標準化したのがSGP.22 v3のDevice Changeであり、OSベンダーが独自に作り込んだのがAppleやGoogleのクイック転送です。

2. なぜプロファイルはコピーできないのか

もう一段だけ仕組みに踏み込みます。プロファイルはSM-DP+からBPP(Bound Profile Package。特定のeUICCに紐付けられた配送用パッケージ)として届きます。BPPの生成では、ダウンロードセッション中にeUICCが生成する一時鍵ペアとSM-DP+の鍵から共有セッション鍵を導出し、その鍵でプロファイルを暗号化します。つまり、暗号化の時点で「そのセッションのそのeUICC」だけが復号できる形になっています。詳細はプロファイルダウンロードフロー詳解で解説しています。

また、インストール後のプロファイルをeUICCの外へ取り出すインターフェースは仕様上存在しません。プロファイルには加入者認証の鍵(K/Ki)が含まれるため、取り出せてしまうとSIMの複製(クローン)が成立してしまいます。「コピーできない」ことは不便の原因であると同時に、eSIMのセキュリティモデルの根幹でもあります。

この前提から、機種変更を支援する仕組みに求められる仕事は「安全に削除と再ダウンロードを段取りすること」に集約されます。

3. SGP.22 v3のDevice Change — 標準化された転送手続き

Device Changeは、SGP.22 v3で追加された、旧端末のプロファイルと同じサブスクリプションのプロファイルを新端末に導入するためのエンドユーザー主導の手続きです(SGP.22 v3.1 §3.11.1、Figure 29m)。v2までは各社が独自に作るしかなかった転送フローに、初めて標準の型が与えられました。v3の新機能全体の位置づけはSGP.22 v3の新機能(MEP・Device Change・Push通知)を参照してください。

3-1. 事前条件 — DeviceChangeConfiguration

Device Changeが使えるのは、プロファイルのメタデータにDeviceChangeConfiguration(サービスプロバイダが設定する転送方法の指定)が含まれている場合だけです。設定値は大きく2通りあります。

このほか、Profile Policy Rulesが設定されたプロファイルはDevice Changeの対象外である、旧端末のeUICCとLPAの双方がDevice Changeをサポートしている、といった開始条件がSGP.22 v3.1 §3.11.1に列挙されています。

3-2. requestToDpの場合の流れ

代表的なrequestToDpのフローを簡略化すると次の通りです。

ポイントを補足します。

• 旧端末のLPAは、必要に応じて新端末のEIDやTAC(端末の型式を示すIMEIの先頭8桁)を取得してSM-DP+に渡します。取得方法(QRコード読み取りなど)は仕様のスコープ外です。

• SM-DP+はES2+経由でサービスプロバイダに問い合わせ、転送可否の判断や新プロファイルの準備(Download Preparation)を委ねます。SM-DP+がDevice Change未対応の場合は「Device Change – Unsupported」エラーで手続きが止まります。

• 旧プロファイルの削除が要求される場合、eUICCは削除と同時にDelete Notificationを生成します。この通知をSM-DP+へ届けられないときは手続きを停止する、あるいはActivation CodeにDelete Notification for Device Changeを埋め込んで新端末経由で届ける、という手当てまで規定されています。

• 最後は通常のプロファイルダウンロード手続き(§3.1.3)がそのまま走ります。Device Changeは「ダウンロードの新しい方式」ではなく「ダウンロードの段取りの標準化」だと分かります。

3-3. 補助的な仕組み — 複数プロファイル・待機・リカバリ

実運用を意識した補助手続きも用意されています。

• Multiple Profiles Device Change(§3.11.1.1): 複数プロファイルをまとめて転送対象に選択でき、Activation Codeは一括で新端末へ渡すことが推奨されています。

• SM-DP+ polling(§3.11.1.2): 事業者側のプロファイル準備に時間がかかる場合、LPAがES9+.CheckProgressで完了を待機します。

• Profile Recovery(§3.11.2): 旧プロファイルを削除した後で新端末へのインストールが恒久エラーで失敗した場合に、旧端末へプロファイルを復旧させる手続きです。旧端末のLPAはICCIDやSM-DP+アドレスを復旧有効期間(profileRecoveryValidityPeriod)のあいだ保持します。「削除が先、ダウンロードが後」という構造ゆえに起こり得る「両端末とも圏外」という最悪ケースへの備えです。

4. Apple/Googleのクイック転送と標準の関係

標準化に先行して、OSベンダーは独自の転送機能を実装してきました。AppleはiOS 16以降の「eSIMクイック転送」で、旧iPhoneの近くに新iPhoneを置くだけの転送を実現しています。GoogleもAndroid 13でeSIM転送機能を発表し、Pixel 8世代以降の端末から順次利用できるようになっています。

これらの内部でも、行われているのは「削除と再ダウンロードの段取り」です。ただし段取りの伝達には、SGP.22のDevice ChangeではなくOSベンダーと通信事業者間の仕組み(GSMA TS.43ベースのエンタイトルメントサーバー連携など)が使われます。そのため対応可否は事業者ごとに異なり、対応事業者のリストをOSベンダー側が管理する構図になっています。

現時点の実態としては「クイック転送が使えれば快適、使えなければ手動再発行」という状況で、Device Changeはこのギャップを標準で埋めていく位置づけです。なお、名前の似たIFPP(In-Factory Profile Provisioning。SGP.41/42)は製造ラインでの一括書き込みに関する別の仕様群であり、機種変更時の転送とは対象が異なります。

5. 転送時の制約と実務ポイント

最後に、eSIMサービスを提供する側の視点で制約を整理します。

• SM-DP+とeUICC双方のv3対応が前提: Device ChangeはSM-DP+、LPA、eUICCのすべてが対応して初めて機能します。v2のSM-DP+に対しては互換性のためエラーで安全に停止する設計です。

• サービスプロバイダ側の設定が必要: 転送可否、旧プロファイル削除の要否、Confirmation Codeの要求などは、事前にSM-DP+へ設定しておく事業者側のポリシーです(SGP.22 v3.1 Annex O)。「eSIMを発行すれば自動的に転送できる」わけではありません。

• 削除と再発行の順序設計: 旧プロファイルを先に削除する設計では、失敗時にProfile Recoveryまで含めた導線が必要です。逆に削除を後回しにすると、一時的に新旧2つのプロファイルが存在する状態の扱い(課金・認証)を決めておく必要があります。

• クイック転送への対応は別途の取り組み: Apple/Googleのクイック転送に載るには、標準対応とは別にOSベンダーとの連携が必要です。MVNOにとっては負担が大きく、当面は「LPA経由の再ダウンロード+分かりやすい再発行導線」が現実解になる場面が多いはずです。

まとめ

• eSIMのプロファイルは配送時点で特定のeUICC専用に暗号化されており、端末間でコピーする手段は仕様上存在しない

• したがってあらゆる「eSIM転送」は、内部的には「旧端末での削除+新端末への再ダウンロード」の段取りである

• SGP.22 v3のDevice Change(§3.11)は、この段取りをDeviceChangeConfiguration(requestToDp/usingStoredAc)に基づいて標準化した手続きである

• 削除先行の失敗に備えたProfile Recovery、複数プロファイル一括転送、SM-DP+側の準備待機など、実運用向けの補助手続きも規定されている

• Apple/Googleのクイック転送は同じ目的を独自の事業者連携で先行実装したもので、Device Changeはそのギャップを標準で埋める位置づけにある

eSIM転送を理解する鍵は、機能の名前ではなく「削除と再ダウンロードをどう段取るか」という一点に着目することです。この軸で見れば、独自実装と標準手続きの関係も、事業者側で準備すべきことも整理できます。

参考規格

• GSMA SGP.22 v3.1 — RSP Technical Specification(§3.11 Device Change and Profile Recovery、Annex O)

• GSMA SGP.21 v2.7 — RSP Architecture

• GSMA TS.43 — Service Entitlement Configuration

おわりに

弊社では「LibeSIM」として、SM-DP+やMVNO回線、eIM(eSIM IoT Remote Manager)、eUICC、IPA/LPAのご提供を行っております。 ご興味がございましたら、デモやPoC等行っておりますので、ぜひお問い合わせください。

https://common-creation.com/service/libesim