SGP.31/32とは？2023年に策定されたIoTデバイス向けeSIM規格を解説

無料ウェビナーのご案内

SIM・eSIMの基本を、動画でも学んでみませんか？

本ウェビナーでは、SIMカードとeSIMの違い、eUICC・プロファイル・SM-DP+の関係、プロファイルを遠隔で書き込む仕組みなどを、図を交えて約15分で解説します。

記事とあわせて全体像を整理したい方や、業務でeSIMを扱い始めた方におすすめです。学び直しや社内での情報共有にもご活用ください。

今すぐ申し込む（無料）

こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスの事業責任者をしている山本です。本記事では、IoT機器向けのリモートSIMプロビジョニング仕様である SGP.31／SGP.32(IoTモデル、IoT RSP)の全体像を解説します。

はじめに

eSIMのリモートSIMプロビジョニング(RSP)には、M2Mモデル(SGP.02)、コンシューマモデル(SGP.22)、そしてIoTモデル(SGP.31/32)の3つのアーキテクチャがあります。IoTモデルはこの中で最も新しく、無人のIoT機器でもクラウドからプロファイルを管理できるように設計された仕様です。3モデルの比較はeSIMの3つのアーキテクチャとは?で扱っているため、本稿はIoTモデルそのものを掘り下げます。

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

なぜM2M・コンシューマに続く3つ目の仕様が必要だったのか
コンシューマモデルをベースにした設計と、eIM・IPAという新しい構成要素
PSMO・eUICC PackageなどIoTモデル固有の仕組み
v1.0からv1.3までの進化と、2026年時点の現在地

1. まず全体像から｜IoTモデルをざっくり理解する

スマートフォンのeSIMは、持ち主が画面を操作して回線を追加したり切り替えたりします。この「持ち主による操作」を前提にしたのがコンシューマモデル(SGP.22)です。ところが、電力メーター、車載機、貨物トラッカーといったIoT機器には画面もボタンもなく、そばに人もいません。この前提の違いを解決するのがIoTモデルです。

発想はシンプルで、コンシューマモデルで端末内にあった LPA(Local Profile Assistant。プロファイル操作を担う端末内エージェント)の仕事を2つに分けました。

「どのプロファイルをいつ切り替えるか」を判断し指示する役割は、クラウド上のサーバー eIM(eSIM IoT Remote Manager)へ
指示を受けてダウンロードや切り替えを実行する役割は、機器側の軽量なエージェント IPA(IoT Profile Assistant)へ

たとえるなら、各部屋のスイッチ(端末のUI)でしか操作できなかった照明を、中央の管理盤(eIM)からまとめて操作できるように配線し直した、という関係です。部屋側に残るのは指示どおりに動く小さな受け口(IPA)だけです。

重要なのは、プロファイルを配信する SM-DP+ や、どこにプロファイルがあるかを教える SM-DS は、コンシューマモデルのものをほぼそのまま使い回せる点です。IoTモデルは「ゼロから作った第3の仕様」ではなく、「コンシューマモデルの端末側を無人運用向けに組み替えた仕様」と理解するのが正確です。

2. なぜ3つ目の仕様が必要だったのか

先行する2つのモデルには、それぞれIoTに不向きな点がありました。

M2Mモデル(SGP.02)はサーバー主導のプッシュ型で無人運用はできますが、SMSを前提とした配送や、eUICCをSM-SRという特定サーバーに紐付ける設計のため、契約先の切り替え(SM-SRスイッチ)が事実上困難でした。詳細はSGP.01/02とは?M2M向けeSIM規格の仕組みと限界で解説しています。

コンシューマモデル(SGP.22)はエンドユーザー主導のプル型で、事業者間の乗り換えは自由になりましたが、プロファイルのダウンロードや切り替えにユーザーのUI操作が必要です。無人のIoT機器にはこの前提が成り立ちません。

さらにIoT機器には、次のような機器側の制約があります。SGP.31はこれらを明示的に定義しています。

UICD(User Interface Constrained Device): 画面やボタンなどのUIが乏しい、またはない機器
NCD(Network Constrained Device): NB-IoTなど帯域やプロトコルが制約されたネットワークにつながる機器

「無人でも動き、特定サーバーに縛られず、制約の強い機器でも動く」｜この3つを同時に満たすため、GSMAはコンシューマモデルを土台に新仕様を策定しました。それが次の2文書です。

文書	正式名称	役割	初版
SGP.31	eSIM IoT Architecture and Requirements	アーキテクチャ・要件定義	2022 年
SGP.32	eSIM IoT Technical Specification	技術仕様(手順・データ形式)	2023 年

3. アーキテクチャ｜コンシューマモデルの部品をどう組み替えたか

3-1. 構成要素とインタフェース

SGP.32 v1.3の機能アーキテクチャ(SGP.32 §2のFunctional Architecture図)を簡略化すると、次のようになります。

eIM(eSIM IoT Remote Manager): 多数のIoT機器のプロファイル状態を遠隔管理するサーバーです。MNOやIoTサービス事業者、あるいは第三者が運用します。
IPA(IoT Profile Assistant): 機器側でダウンロードや状態変更を実行するエージェントです。機器(デバイス)上に置く IPAd と、eUICC上に置く IPAe の2形態があります。
ESipa: eIMとIPAの間の論理インタフェースです。コンシューマモデルのES9+/ES11に相当する機能を、eIM経由で使えるように再構成したものです。

SM-DP+とSM-DSはコンシューマモデル(SGP.22 v3.1)のものを流用し、eIMを経由するための拡張インタフェース ES9+'・ES11' が追加されています。

3-2. 直接接続と間接接続

SGP.32では、プロファイルダウンロードの経路を2通り定義しています。

直接接続(Direct): IPAがES9+でSM-DP+と直接通信し、BPP(Bound Profile Package)を取得する
間接接続(Indirect): IPAはeIMとだけ通信し、eIMがES9+'でSM-DP+との間を中継する

NCDのようにHTTPSを直接話せない機器でも、間接接続なら軽量プロトコルでeIMとだけつながればプロファイルを取得できます。ESipaのトランスポートとしてはHTTPSに加えてCoAP(制約デバイス向けの軽量プロトコル)が規定されています。

4. IoTモデル固有の仕組み｜PSMOとeUICC Package

4-1. 固有の語彙

IoTモデルを読むうえで押さえるべき用語を整理します。

用語	正式名称・意味
PSMO	Profile State Management Operation。プロファイルの有効化・無効化・削除・一覧取得などの状態管理操作
eCO	eIM Configuration Operation。eUICCに登録されたeIM情報(鍵など)の追加・削除・更新操作
eUICC Package	eIMが作成する署名付きの指示パッケージ。PSMOまたはeCOを格納する
Fallback	切り替え後に接続を失った場合、Fallback属性を持つプロファイルへ切り戻す仕組み

4-2. eUICC Packageによる安全な遠隔操作

コンシューマモデルでは「有効化してよいか」を最終判断するのはエンドユーザーでした。IoTモデルでは人がいないため、代わりに「この指示は正当なeIMから来たか」をeUICC自身が検証します。

eUICCには、管理を許可するeIMの公開鍵などの情報(eIM Configuration Data)が登録される
eIMはPSMOを含むeUICC Packageに署名して送る
eUICCは署名を検証し、登録済みのeIMからの指示のみを実行する

「コンシューマモデルの『ユーザーの同意』を、IoTモデルは『eIMの署名検証』に置き換えた」

これがIoTモデルのセキュリティ設計の核心です。またIoTモデルには、切り替えた先のプロファイルで接続できなくなった機器が文鎮化しないよう、Fallback機構が用意されています。

なお、PSMOとして定義される操作は、有効化(enable)・無効化(disable)・削除(delete)・一覧取得(listProfileInfo)・RAT取得(getRAT)・Immediate Profile Enabling設定(configureImmediateEnable)・Fallback属性の設定/解除・デフォルトSM-DP+アドレス設定であり、eUICC Packageの構造とあわせてSGP.32 §2.11に規定されています。

5. IPAdとIPAe｜実装負担をどこに置くか

IPAを機器側に実装するIPAdでは、機器ベンダーがeUICCへのアクセス(APDU送受信)やESipaクライアントを自前で実装する必要があり、ハードルは低くありません。そこでSGP.32は、IPAをeUICC内のアプリケーションとして搭載する IPAe も認めています。IPAeを使えば、機器側の追加実装を抑えつつIoTモデルに対応できます。

どちらの形態を選ぶかは、機器の性能、eUICCの調達条件、通信モジュールの対応状況で決まります。LPAd/LPAe/IPAd/IPAeの4形態の比較はLPAとIPAとは?端末側エージェント総整理にまとめています。

6. v1.0からv1.3までの進化と現在地

SGP.31 v1.0(2022年4月): アーキテクチャと要件を定義。eIM・IPA・ESipaという骨格はここで確定
SGP.32 v1.0(2023年5月): 技術仕様の初版。手順・データ形式・プロトコルバインディングを規定
v1.1〜v1.2(2023年〜2024年4月): 明確化・修正が中心。SGP.31 v1.2ではEmergency Profileや制約デバイス向けConnectivity Parametersなどの要件追加も行われた。テスト仕様SGP.33の整備も並行して進行
SGP.31/32 v1.3(2026年5月): 2026年8月時点の最新版

エコシステム面では、eUICCのセキュリティ認証制度 eSA(eUICC Security Assurance)を取得したSGP.32対応eUICCや、eIMサービスが市場に出始めており、M2Mモデルからの移行が現実の検討課題になっています。