eIMでのIoT eSIM管理とは?導入・有効化・復旧の流れを詳しく解説

無料ウェビナーのご案内
SIM・eSIMの基本を、動画でも学んでみませんか?
本ウェビナーでは、SIMカードとeSIMの違い、eUICC・プロファイル・SM-DP+の関係、プロファイルを遠隔で書き込む仕組みなどを、図を交えて約15分で解説します。
記事とあわせて全体像を整理したい方や、業務でeSIMを扱い始めた方におすすめです。学び直しや社内での情報共有にもご活用ください。
今すぐ申し込む(無料)
こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスの事業責任者をしている山本です。 本記事では、IoT向けeSIM仕様SGP.32が定めるプロファイル管理の手順を、eIM経由のダウンロード、有効化・無効化、切替失敗に備える復旧機構の順に追いかけます。
はじめに
IoT 向け RSP の全体像は SGP.31/SGP.32によるIoT向けeSIMの全体像 で、管理サーバーである eIM の役割は eIMとは?eSIM IoT Remote Managerの詳解 で整理しました。本稿はその続編として、「プロファイルは実際にどういう手順で機器に届き、どう切り替わるのか」というフローそのものを扱います。
本稿では、以下の項目を GSMA Official Document SGP.32 v1.3 の §2〜§3 に基づいて整理します。
eIM と IPA の間でやり取りされる「eIM Package」の仕組み
プロファイルダウンロードの 2 方式(Direct / Indirect)とそのシーケンス
eUICC Package(PSMO)による有効化・無効化・削除
切替失敗時に通信を復旧するRollbackとFallbackの位置づけ
1. まず全体像から — IoTのプロファイル管理をざっくり理解する
スマートフォンの eSIM は、持ち主が画面の QR コードスキャンや設定メニューを操作して開通します。一方、スマートメーターや車載機器のような IoT 機器には、画面もそれを操作する人もいません。そこで SGP.32 では、遠隔の管理サーバーである eIM(eSIM IoT Remote Manager)が人間の代わりに指示を出し、機器内のエージェントである IPA(IoT Profile Assistant)がその指示を実行します。
イメージとしては、eIM が「遠隔の司令塔」、IPA が「現場の作業員」です。司令塔は現場に対して指示書(後述の eIM Package)を渡します。渡し方は 2 通りあり、作業員が定期的に「仕事はありますか」と聞きに行く方式と、司令塔が現場に直接指示を送り込む方式があります。指示書の内容は、大きく次の 3 種類に分かれます。
ダウンロード指示: SM-DP+ から新しいプロファイルを取得させる
状態管理指示: インストール済みプロファイルの有効化・無効化・削除
情報照会: eUICC の状態やプロファイル一覧の報告
そして IoT 特有の課題が「切り替えの失敗」です。新しいプロファイルを有効化した結果、機器が圏外になってしまうと、遠隔からは二度と手が出せなくなります。SGP.32はこの事態に備え、直前の状態へ戻すRollbackと、事前に指定した退避先へ切り替えるFallbackを規定しています。 ただし、障害の検知条件と実行判断はIoT Device側の実装に依存します。
登場する要素とインターフェースは次のとおりです。
要素 | 正式名称 | 役割 |
|---|---|---|
SM-DP+ | Subscription Manager Data Preparation+ | プロファイルの生成・保護・配送 |
eIM | eSIM IoT Remote Manager | プロファイル管理の遠隔指示 |
IPA | IoT Profile Assistant | 機器側でフローを実行するエージェント |
eUICC | embedded UICC | プロファイルを格納・実行するチップ |

IPA には端末実装の IPAd と eUICC 内実装の IPAe があります。この違いは LPA/IPAとは?端末側エージェントの4形態 を参照してください。以降のフローは IPAd を前提に書きますが、IPAe でも ES10 の呼び出しが eUICC 内部に閉じるだけで、流れは同じです。
2. eIMとIPAの通信 — eIM Packageの往復
2-1. RetrievalとInjection
eIM から IPA への指示は eIM Package というデータ構造で運ばれます。SGP.32 §3.1.1 は転送手順を 2 つ定義しています。
手順 | 方向 | 動作 |
|---|---|---|
eIM Package Retrieval(§3.1.1.1) | IPA 主導 | IPA が eIM に問い合わせ、保留中の指示を取得する |
eIM Package Injection(§3.1.1.2) | eIM 主導 | eIM が IPA へ指示を直接送り込む |
eIM と IPA はそれぞれ少なくとも一方をサポートし、双方が同じモードと同じセキュア接続方式を使います。多様な機器を収容する eIM には両対応が推奨されています。トランスポートには HTTPS over TCP のほか、制約デバイス向けに CoAP(Constrained Application Protocol)/DTLS over UDP が使えます。どの方式を使えるかは、IPA が IPA Capabilities(§4.1)で宣言します。
2-2. eIM Packageの中身と結果の返送
eIM Package には次のいずれかが入ります。
eUICC Package — eIM が署名した eUICC 宛の命令列(§3で詳述)
IpaEuiccDataRequest — eUICC 情報(euiccInfo、プロファイル一覧など)の照会
ProfileDownloadTriggerRequest — プロファイルダウンロードの起動指示
IPA は実行結果を eIM Package Result(EuiccPackageResult、ProfileDownloadTriggerResult など)として eIM へ返し、eIM は受領済みのシーケンス番号を EimAcknowledgements で確認応答します。この確認応答があって初めて、IPA は eUICC 側の保留データを削除します。到達性が不安定な IoT 回線でも結果を取りこぼさないための設計です。
3. プロファイルダウンロードフロー(SGP.32 §3.2.3)
3-1. Direct方式とIndirect方式
ダウンロードの起点は、eIM が送る ProfileDownloadTriggerRequest です。この中の profileDownloadData には次の 3 択が入ります。
ProfileDownloadData ::= CHOICE {
activationCode [0] UTF8String (SIZE(0..255)), -- Activation Code
contactDefaultSmdp [1] NULL, -- Default SM-DP+へ接続
contactSmds [2] SEQUENCE { smdsAddress UTF8String OPTIONAL }
}
つまり開始条件は、(a) Activation Code の指定、(b) SM-DS 経由のイベント取得、(c) Default SM-DP+ への接続、の 3 つです。Activation Code の構造そのものは Consumer RSP と共通なので、プロファイルダウンロードフロー詳解 も参考になります。
トリガーを受けた IPA が SM-DP+ とどう通信するかで、2 方式に分かれます。
観点 | Direct(§3.2.3.1) | Indirect(§3.2.3.2) |
|---|---|---|
SM-DP+ との通信 | IPA が ES9+ で直接通信 | eIM がプロキシとなり ES9+' で通信 |
IPA 側の要件 | HTTPS で SM-DP+ に届くこと | eIM に届けばよい(CoAP 可) |
IPA Capability | directRspServerCommunication | indirectRspServerCommunication |
向く機器 | 通信に余裕のある機器 | 制約の強い機器 |
Indirect 方式では、IPA と eIM の間のバイト数を減らす compact なデータ構造(IPA Capability の minimizeEsipaBytes)も使えます。証明書などの既知情報を eIM 側で補完し、細い回線の負担を下げる仕組みです。
3-2. Indirectダウンロードのシーケンス
Indirect 方式の流れを簡略化したシーケンスで示します(SGP.32 v1.3 Figure 10 に対応)。

ポイントは 3 つあります。
相互認証は Consumer RSP の Common Mutual Authentication(SGP.22 §3.1.2)をそのまま流用し、eIM が LPA の役割を代行します。ES9+' の各ファンクションは「eIM が LPA を演じる ES9+」として定義されています(SGP.32 §5.7)。
BPP(Bound Profile Package)の暗号は eUICC と SM-DP+ の間でエンドツーエンドに閉じています。eIM は経路上でプロファイルの中身を復号できません。
インストール結果(ProfileInstallationResult)は ESipa.HandleNotification で eIM に渡り、eIM が ES9+'.HandleNotification で SM-DP+ へ届けます。eIM の受領確認後、IPA は ES10b.RemoveNotificationFromList で eUICC 内の通知を削除します。
Direct 方式でも認証とダウンロードの中身は同じで、IPA が ES9+ を直接呼ぶ点だけが違います。この場合、結果は ProfileDownloadTriggerResult として eIM に報告されます。
3-3. ダウンロード直後の有効化
Default SM-DP+ からのダウンロードでは、事前に即時有効化を許可しておくことで、IPA が ES10b.ImmediateEnable を呼び、ダウンロード直後にそのままプロファイルを有効化できます。工場出荷後の初回接続を短い手順で済ませたい IoT のユースケースに向いています。
4. 有効化・無効化・削除 — eUICC PackageとPSMO
インストール済みプロファイルの状態変更は、eIM が署名した eUICC Package で行います。中身は PSMO(Profile State Management Operation)または eCO(eIM Configuration Operation)の列です。
PSMO: enable(有効化。rollbackFlag を付加可能)、disable(無効化)、delete(削除)、listProfileInfo、getRAT、configureImmediateEnable、setFallbackAttribute / unsetFallbackAttribute、setDefaultDpAddress
eCO: eUICC に登録された Associated eIM の追加・削除・更新(addEim / deleteEim / updateEim / listEim)
重要なのは検証の主体です。eUICC は PSMO を実行する前に、eIM の署名付き eUICC Package を §3.3 および §5.9.1 の規定に従って検証します。検証に使う鍵は、事前に eUICC へ登録された Associated eIM の公開鍵情報です。つまり有効化・削除といった強い操作は、「eUICC 自身が信頼を確認した eIM」からしか実行できません。IPA はあくまで運び役で、改ざんしても eUICC の検証で弾かれます。
検証に成功すると、eUICC は Package 内の PSMO/eCO を先頭から順に実行し、最後まで到達するかエラーが出た時点で停止します。実行結果は eUICC が署名した EuiccPackageResult として eIM へ返送され、あわせて状態変更の Notification が MNO 側の受信者へ届けられます(§3.7)。
5. 切替失敗に備えるRollbackとFallback
Profile切替後に通信できなくなると、eIMから次の指示を届けられない可能性があります。 現地に人を送れないIoT機器では、復旧方法を切替前に用意しておく必要があります。
Rollbackでは、eIMがenable PSMOへrollbackFlagを設定します。 事前許可された切替で接続性を確保できなかった場合、IPAはES10b.ProfileRollbackを呼び、eUICCは最後のeUICC Packageを処理する前に有効だったProfileへ戻します(§5.9.16)。
Fallbackでは、fallbackAllowedが有効なProfileへfallbackAttributeを事前設定します。 IPAがES10b.ExecuteFallbackMechanismを呼ぶと、eUICCは指定済みのFallback Profileへ切り替えます(§5.9.20)。
両者は戻り先も事前条件も異なります。 詳しい比較、ReturnFromFallback、障害判定の設計については、eSIMのFallbackとRollbackとは?で解説しています。
このほか SGP.32 には、緊急通報用の Emergency Profile の優先制御も定義されています。Emergency Profile が有効な間、IPA はダウンロード指示を実行せず、ecallActive エラーを eIM へ返します。
「IoTのプロファイル管理は、指示は署名で守り、失敗はロールバックで守る」
この二段構えが、無人運用を前提にした SGP.32 の設計思想です。
まとめ
SGP.32 のプロファイル管理は、eIM と IPA の間を往復する eIM Package(Retrieval / Injection の 2 方式)で駆動される
ダウンロードには IPA が SM-DP+ と直接話す Direct 方式と、eIM がプロキシになる Indirect 方式があり、機器の通信能力で選ぶ
どちらの方式でも認証は SGP.22 の Common Mutual Authentication を流用し、BPP の暗号は eUICC と SM-DP+ の間で閉じる
有効化・無効化・削除は eIM が署名した eUICC Package(PSMO)で行い、eUICC 自身が署名を検証する
Rollbackは直前のProfileへ戻し、Fallbackは事前指定した退避用Profileへ切り替える
障害検知と実行判断はIoT Device側で設計する
Consumer RSPのフローを土台にしつつ、人がいない、回線が細い、切替に失敗すると遠隔操作できないというIoTの制約へ対応したのがSGP.32のプロファイル管理フローです。
参考規格
GSMA SGP.31 v1.3 — eSIM IoT Architecture and Requirements
GSMA SGP.32 v1.3 — eSIM IoT Technical Specification
GSMA SGP.22 v3.1 — RSP Technical Specification
おわりに
弊社では「LibeSIM」として、SM-DP+やMVNO回線、eIM(eSIM IoT Remote Manager)、eUICC、IPA/LPAのご提供を行っております。 ご興味がございましたら、デモやPoC等行っておりますので、ぜひお問い合わせください。

山本 真基
コモン・クリエーション株式会社
執行役員 LibeSIM事業責任者
当社にて、eSIM Tech Partner「LibeSIM」の立ち上げ・事業推進を主導。SM-DP+・eIM・MVNOをワンストップで提供し、eSIMの運用に必要なすべてをオープンに選択できる環境の実現を目指す。国内唯一のeIMプロバイダーとして、SGP.32時代のIoT接続管理の最前線に立つ。
