SGP.21/22とは？スマホのeSIMを支えるコンシューマ向けRSPを解説

こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスでプロジェクトマネジメントを担当している比嘉です。本記事では、スマートフォンのeSIMを支えるコンシューマ向けリモートSIMプロビジョニング（Consumer RSP）の仕様である SGP.21 と SGP.22 を取り上げ、SM-DP+・SM-DS・LPA という 3 つの登場人物の役割分担と、「エンドユーザー主導のプル型」という設計思想を整理します。

はじめに

スマートフォンで QR コードを読み取ると、数十秒で新しい回線が使えるようになります。この体験の裏側を規定しているのが、GSMA の Consumer RSP 仕様群です。eSIM のリモートプロビジョニング仕様には M2M・Consumer・IoT の 3 系統があり、全体像は eSIMの3つのアーキテクチャとは？ で整理しています。本稿はそのうち Consumer 方式を扱います。

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

• SGP.21 と SGP.22 の位置づけ（アーキテクチャ仕様と技術仕様の分担）

• SM-DP+・SM-DS・LPA・eUICC の役割分担

• なぜ Consumer RSP は「プル型」なのか｜設計思想の背景

• 主要な ES インタフェースの一覧と、v3 系で加わった拡張の概観

1. まず全体像から｜Consumer RSPをざっくり理解する

Consumer RSP は、ひとことで言うと「エンドユーザーが自分の意思で、通信事業者のプロファイルを端末にダウンロードして使う」ための仕組みです。プロファイル（Profile。加入者情報・鍵・アプリ一式を含む、いわば仮想的な SIM カードの中身）を、サーバーから eUICC（embedded UICC。端末に組み込まれた書き換え可能な SIM チップ）へ安全に届けます。

登場人物は 3 つだけ覚えれば十分です。空港の航空券にたとえると、次のようになります。

• SM-DP+（Subscription Manager - Data Preparation +）は「発券カウンター」。通信事業者の依頼を受けてプロファイルを準備し、本人が取りに来たら渡します。

• SM-DS（Subscription Manager - Discovery Server）は「案内板」。「あなた宛のプロファイルは、あのカウンターにありますよ」と場所だけを教えます。

• LPA（Local Profile Assistant）は「本人の足」。端末の中にいるソフトウェアで、ユーザーの操作を受けてカウンターまで取りに行き、受け取ったプロファイルを eUICC に格納します。

重要なのは、荷物が勝手に送りつけられるのではなく、必ず本人（端末側）が取りに行く点です。これをプル型と呼びます。M2M 方式（SGP.02）ではサーバー側が SIM に書き込みを仕掛けるプッシュ型でしたが、Consumer 方式では起点がユーザー操作に移りました。QR コードの読み取りは「引換券の提示」に相当します。厳密には、SM-DP+ は単なる窓口ではなく、プロファイルの生成・暗号化・eUICC への紐付けまで担う能動的なサーバーです。この点は後述します。

2. SGP.21とSGP.22｜2つの文書の位置づけ

Consumer RSP は、GSMA の 2 つの Official Document のセットで規定されています。

SGP.21 が「何を実現するか」を、SGP.22 が「どう実装するか」を定める分担です。バージョンは v2 系と v3 系が並行して維持されており、市場に流通する端末の多くは v2 系（SGP.22 v2.2.x 以降）で相互接続しています。v3 系は後述する MEP や RPM などの拡張を含む世代です。

周辺には適合性試験を定める SGP.23 などもありますが、この 2 つを押さえれば Consumer RSP の骨格は読めます。

3. 役割分担の詳解｜SM-DP+・SM-DS・LPA・eUICC

3-1. SM-DP+｜プロファイルの生成から配送までを一手に担う

SM-DP+ は、通信事業者（MNO/MVNO）からの発注（ES2+ インタフェース）を受けてプロファイルを生成し、保護し、特定の eUICC に紐付け（バインド）、端末へ配送するサーバーです。配送されるデータは BPP（Bound Profile Package。特定の eUICC の鍵でのみ復号できる形に暗号化されたプロファイルパッケージ）と呼ばれます。

名前の末尾の「+」には歴史的な意味があります。M2M 方式ではプロファイル生成を担う SM-DP と、状態管理・配送を担う SM-SR が別のサーバーでした。Consumer 方式ではこの 2 つの機能を統合したものが SM-DP+ です。SM-SR が消えたことで、M2M 方式で問題になった「SM-SR の切り替えが事実上困難」という課題も構造的に解消されました。

SM-DP+ と eUICC の間では、TLS とは別レイヤで Common Mutual Authentication（GSMA の証明書チェーンに基づく相互認証）が行われ、プロファイルはエンドツーエンドで保護されます。証明書チェーンの信頼の起点は別記事（eSIMのPKIと証明書チェーン）で詳しく扱います。

3-2. SM-DS｜「どこに取りに行くか」だけを教えるディスカバリサーバー

プル型には 1 つ弱点があります。端末は「自分宛のプロファイルがどの SM-DP+ にあるか」を、QR コード（Activation Code）を読まない限り知りようがない点です。これを補うのが SM-DS です。

• SM-DP+ は、プロファイルを準備したら SM-DS に「この EID 宛のイベントがある」と登録します（ES12）

• 端末の LPA は、起動時などに SM-DS へ問い合わせ（ES11）、自分の EID 宛のイベントがあれば該当の SM-DP+ アドレスを受け取ります

SM-DS が扱うのはあくまで「イベント（所在情報）」だけで、プロファイル本体は通過しません。GSMA が運用する Root SM-DS を頂点に、代替 SM-DS をカスケード接続する構成（ES15）も定義されています。Activation Code の構造とあわせた詳細は、別記事（Activation CodeとSM-DSディスカバリ）で解説します。

3-3. LPA｜端末内の実行役。3つの機能ブロック

LPA は端末側のソフトウェアで、内部は 3 つの機能に分かれます。

LPA が端末 OS 側にある形態を LPAd、eUICC 内に実装する形態を LPAe と呼びます。IoT 方式の IPA も含めた端末側エージェントの整理は、別記事（LPA/IPAの総整理）に譲ります。

3-4. eUICC｜受け皿となるセキュアエレメント

eUICC の内部では、ISD-R がプロファイル管理を、ISD-P が個々のプロファイルの格納を、ECASD が鍵と証明書の保管を担います。内部構造は別記事（eUICCのアーキテクチャ）で詳解しているため、本稿では割愛します。

3-5. 全体構成図

4. なぜプル型なのか｜Consumer RSPの設計思想

Consumer RSP の設計は、一貫して「エンドユーザーの意思（End User Intent）」を起点に置いています。SGP.21 は、プロファイルのダウンロードや有効化にユーザーの同意を求めることを要件として定めています。背景には技術面と事業面の理由があります。

• 技術面: スマートフォンは NAT やファイアウォールの内側にあり、サーバーから接続を張るプッシュ型は成立しにくい。端末側から HTTPS で取りに行くプル型が現実的でした。

• 事業面: 消費者向けでは、契約先の事業者を選ぶ主体はユーザーです。サーバー側が一方的にプロファイルを差し替えられる設計は、消費者保護の観点で受け入れられません。

一方でこの設計は「ユーザーが操作できる UI がある」ことを前提とします。画面を持たないセンサーやメーターには適用しづらく、この制約が後の IoT 方式（SGP.31/SGP.32）を生む動機になりました。

5. 主要なESインタフェースとv3系の拡張

5-1. ESインタフェース一覧

各エンティティ間の接続点は「ES」で始まる参照点として定義されています。主要なものを一覧にします。

各関数の中身と「どこを誰と誰が話すか」の一枚図は、次の記事 SM-DP+とESインタフェース詳解 で掘り下げます。

5-2. v3系で加わった主な拡張

SGP.22 v3 系では、v2 系のプル型の枠組みを保ったまま、次の拡張が加わりました。

• RPM（Remote Profile Management）: 認可された事業者が、ユーザー同意の枠組みの中でプロファイルの有効化・無効化・削除などを遠隔から指示できる機能

• MEP（Multiple Enabled Profiles）: 1 つの eUICC で複数プロファイルを同時に有効化し、デュアル SIM 的な利用を 1 チップで実現する機能

• Device Change / Push 通知: 機種変更時のプロファイル移行手順や、ポーリングに頼らないイベント通知の仕組み

これらの v2/v3 差分は SGP.22 v3の新機能｜MEPとDevice Change で個別に整理します。また、Consumer RSP をベースに UI なし機器へ対応させた IoT 方式（SGP.31/SGP.32）は、この v3 世代の枠組みを土台にしています。

まとめ

• Consumer RSP は SGP.21（アーキテクチャ）と SGP.22（技術仕様）のセットで規定される、スマートフォン向け eSIM の主流方式

• 役割分担は「生成から配送まで担う SM-DP+」「所在だけを案内する SM-DS」「端末内で実行する LPA（LUI/LPD/LDS）」の 3 者

• SM-DP+ は M2M 方式の SM-DP と SM-SR の機能を統合したもので、SM-SR スイッチ問題を構造的に解消した

• 設計思想は「エンドユーザーの意思を起点とするプル型」。同意なしにプロファイルは書き込まれない

• 各区間は ES2+/ES8+/ES9+/ES10/ES11/ES12 などの参照点で責務が分離されている

• v3 系では RPM・MEP・Device Change が加わり、この枠組みが IoT 方式（SGP.31/32）の土台にもなった

「誰が起点か」という一点を押さえると、M2M・Consumer・IoT の 3 方式の違いは驚くほど見通しよく整理できます。Consumer RSP の起点は、常にエンドユーザーです。

参考規格

• GSMA SGP.21 v2.7｜RSP Architecture

• GSMA SGP.22 v3.1｜RSP Technical Specification

• GSMA SGP.23｜RSP Test Specification

• GSMA SGP.02 v4.3｜Remote Provisioning Architecture for Embedded UICC Technical Specification（M2M方式との比較として）

おわりに

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

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