LibeSIM

山本 真基

2026/10/18 01:00

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

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等行っておりますので、ぜひお問い合わせください。

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

山本 真基

山本 真基

コモン・クリエーション株式会社

執行役員 LibeSIM事業責任者

当社にて、eSIM Tech Partner「LibeSIM」の立ち上げ・事業推進を主導。SM-DP+・eIM・MVNOをワンストップで提供し、eSIMの運用に必要なすべてをオープンに選択できる環境の実現を目指す。国内唯一のeIMプロバイダーとして、SGP.32時代のIoT接続管理の最前線に立つ。