SGP.22 vs SGP.32 - eSIM標準の変化が旅行の接続性に与える影響

目標: 旅行eSIM購入者と旅行/MVNOオペレーターに、消費者向けとIoTリモートSIMプロビジョニングの標準に精通した地図を提供し、「次のeSIM標準」についての業界の話が2つの異なる道を混同しないようにする。

対象読者: 消費者向け旅行接続を出荷または購入する実務者（および隣接するIoT/旅行ハードウェアを評価する人々）、GSMA委員会のメンバーではありません。

旅行eSIMを購入し、QRコードをスキャンしてデータを取得する場合、GSMAリモートSIMプロビジョニング（RSP）アーキテクチャの中に既にいます - 仕様番号を見たことがなくても。それらの番号は重要です。SGP.22 はスマートフォンと旅行eSIMフローの背後にある消費者向けRSP技術標準です。SGP.32 はヘッドレス、制約された、フリート規模のデバイス向けのIoT RSP技術標準です。いくつかの構成要素を共有していますが、異なる問題を解決します。

その区別はマーケティング資料で混同されやすいです。また、旅行者が電話に一時的なプロファイルをインストールすることと、企業が画面を見ることのない何千ものセンサーに接続性を調整することの違いでもあります。旅行ブランド、MVNO、および消費者向けeSIMスタックを構築する人々にとって、SGP.22が終わり、SGP.32が始まる場所を知ることは基本です - 旅行者がGSMAのPDFを必要とするからではなく、業界の会話がしばしば消費者とIoTの道を混同するからです。

この作品は、SGP.32を消費者向けローミングの代替アップグレードとして扱うことなく、旅行接続のためのアーキテクチャ、アクター、ライフサイクルの違い、実際の影響をマッピングします。

業界が複数のeSIM「標準」を必要とした理由 #

eSIMは単一のプロトコルではありません。これは、オペレータープロファイルがどのように安全に準備され、配信され、インストールされ、有効化され、無効化され、削除されるかを定義するGSMAの仕様ファミリーです。

GSMAの公開仕様インデックスは分割を明示しています：コンシューマーRSPはSGP.21（アーキテクチャ）とSGP.22（技術）に基づき、IoT RSPはSGP.31（アーキテクチャと要件）とSGP.32（技術）に基づいています。アクティブなコンシューマーリリースはSGP.22 v2.xおよびv3.xを通じて続き、IoTリリースはSGP.31/SGP.32 v1.xを通じて続き、GSMAのeSIM仕様ページで2024-2026年の新しい改訂を含みます（GSMA eSIM Consumer and IoT Specifications)。

SGP.32以前は、IoTとM2Mのリモートプロビジョニングは主に以前のマシンツーマシンモデル（SGP.02）に存在し、SM-DP（データ準備）とSM-SR（セキュアルーティング）のデュアルサーバー分割がありました。そのモデルは産業および自動車のユースケースに対するリモートプロファイル管理を可能にしましたが、運用上の摩擦ももたらしました：SMS指向のトリガー、より厳しいSM-SR/SM-DPの商業的結合、そして非常に制約のあるLPWANデバイスには適していませんでした。オペレーターとIoTプラットフォームの説明者は一貫して、GSMAが専用のIoTアーキテクチャを構築した理由としてこれらの制約を挙げています。すべてのモデムにコンシューマーRSPを強制するのではなく（Eseye on SGP.31/32; 1oT on SGP.02 vs SGP.22 vs SGP.32)。

短いバージョン：1つの物理的な形状（eSIM/eUICC）、複数のプロビジョニング哲学。

SGP.22を簡単に言うと：人間が関与するデバイス向けのコンシューマーRSP #

SGP.22は、コンシューマーデバイス向けのリモートSIMプロビジョニングのGSMAの技術的説明です。その目的は明確です：コンシューマーデバイスのeUICCのリモートプロビジョニングと管理のための技術的ソリューションであり、オペレーターの展開間の相互運用性を目指しています - SM-DP+プラットフォームとeUICCベンダーを含む。

コンシューマーモデルの主要な役者 #

役者の役割 #

• eUICC: プロファイル（オペレーターの資格情報と関連コンポーネント）を保存するセキュアプラットフォーム
• LPA (Local Profile Assistant): デバイス上（または部分的にeUICC上）のアシスタントで、ダウンロード、ローカルの有効化/無効化/削除、およびユーザー向けのプロファイル管理を行う
• SM-DP+: サブスクリプションマネージャー - データ準備+: バウンドプロファイルパッケージを準備、保護、配信する
• SM-DS: サブスクリプションマネージャー - ディスカバリーサービス: デバイスがQR/アクティベーションコードなしで適切なSM-DP+を見つける必要がある場合のオプションのディスカバリーパス
• オペレーター / プロファイル発行者: プロファイルの背後にある商業的サブスクリプションを所有する

旅行者が認識する流れの中で：

1. 旅行プランを購入し、アクティベーションコード（多くの場合QRとして）を受け取る。
2. デバイスのLPAがSM-DP+に接続します。
3. 暗号化されたプロファイルパッケージがダウンロードされ、eUICCにインストールされます。
4. ユーザーはプロファイルを有効にします（後で無効化または削除することもできます）。

これはユーザー主導 / プル指向のモデルです。人が存在し、デバイスにはUIがあり、同意は明示的なインストールアクションです。これが旅行eSIMのチェックアウト、航空会社/フィンテックのパートナーシップ、アプリベースのアクティベーションがSGP.22クラスの消費者向けRSPに対応する理由です - IoTフリートのオーケストレーションではありません。

HTTPS/TLSトランスポートはスマートフォンに適しています。多くのIoTのデューティサイクルが負担できるよりも重いですが、すでにIP接続と完全なセキュリティスタックを維持しているハンドセットには合理的です。

SGP.32を簡単に言うと、「eSIMを追加」できないデバイス向けのIoT RSPです。 #

SGP.32はGSMAの技術仕様ですeSIM IoT SGP.31で定義されたアーキテクチャ。GSMAは、IoTデバイスにおけるeUICCのリモートプロビジョニングと管理をカバーすると説明しています。ネットワーク制約がある、またはユーザーインターフェースが制約されている, さらにそのモデルのためのeUICCアーキテクチャ、インターフェース、およびセキュリティ機能。

IoTモデルの主要なアクター #

アクターの役割 #

• eUICC: プロファイルを保存し、IoTリモート管理の関連付けをサポートするIoT対応のeUICC
• IPA (IoT Profile Assistant): コンシューマーUIなしでプロビジョニング/管理作業を実行するデバイスまたはeUICC側のアシスタント; かもしれません IPAd（デバイス上）またはIPAe（eUICC上）
• eIM (eSIM IoT リモートマネージャー): デバイスまたはフリートのプロファイルライフサイクル操作を発行するクラウド/オーケストレーションエンティティ
• SM-DP+: プロファイル準備と保護された配信のために消費者エコシステムから再利用
• SM-DS: 関連する場合に保持されるディスカバリーロール
• オペレーター: 消費者RSPにおけるプロファイルソース

アーキテクチャの意図は、GSMAの資料や業界のウォークスルー全体で一貫しており、消費者RSPで既に機能していたもの（特にSM-DP+）を維持し、人間/LPAの仮定をリモートマネージャーとIoTネイティブアシスタントに置き換えることです（Velocity IoT 標準解説; 1oT 比較)。

なぜIoTには異なるモデルが必要だったのか #

消費者RSPは次を仮定します:

• 画面またはコンパニオンUX、
• ダウンロードを開始できる人、
• TLSセッションのための比較的安定したIP接続、
• デバイスごとのユーザー主導のライフサイクル決定。

IoTフリートはしばしば逆を想定します:

• UIなし、
• 断続的または低帯域幅の接続（LPWANシナリオを含む）、
• 常時接続ではなく非同期チェックイン、
• 多くのEIDを一度にポリシーで有効化/無効化/削除。

したがってSGP.31/32は、フリート指向のプロファイル状態管理と、ダウンロードをトリガーまたはプロキシできるeIMを導入します。業界分析では、軽量プロトコルオプション（例えば、制約されたデバイスの代替パスとしてのCoAP/DTLS）、現代のIoT RSPにおけるSMSのハード依存性の除去、デバイスがSM-DP+と直接対話できるかどうかに応じた直接対間接プロファイル配信のサポートも強調されています。Eseye; 1oT).

重要なのは、SGP.32はではありませんすでにフィールドにあるすべてのSGP.02 eUICCに対する後方互換性のある「ソフトウェアアップグレード」ではないということです。Eseyeや他のIoT専門家は、M2M標準の展開は通常、そのモデルで寿命が尽きるまで続くと指摘しています。SGP.32は、グリーンフィールドのIoTでデフォルトになるように設計されています。

SGP.22対SGP.32: 構造化された比較 #

次元ごとの比較 #

主要なGSMAペア

• SGP.22（消費者向けRSP）: SGP.21 アーキテクチャ + SGP.22 技術
• SGP.32 (IoT RSP): SGP.31 アーキテクチャ/要件 + SGP.32 技術

設計対象

• SGP.22 (コンシューマー RSP): スマートフォン、タブレット、ウェアラブル、UIを持つコンシューマーデバイス
• SGP.32 (IoT RSP): ヘッドレス / UI制約 / ネットワーク制約のあるIoTデバイスとフリート

人間の関与は？

• SGP.22 (コンシューマー RSP): はい - ユーザーがインストール/切り替えを開始または確認
• SGP.32 (IoT RSP): いいえ - eIM/IPAがリモートで操作を調整

ローカルアシスタント

• SGP.22 (コンシューマー RSP): LPA
• SGP.32 (IoT RSP): IPA (IPAd または IPAe)

リモートオーケストレーション

• SGP.22 (コンシューマー RSP): 制限あり / 設計の中心ではない
• SGP.32 (IoT RSP): eIMは一流のリモートマネージャーとして

プロファイルサーバー

• SGP.22 (消費者向けRSP): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (再利用)

ディスカバリー

• SGP.22 (消費者向けRSP): SM-DS (多くのフローでオプション)
• SGP.32 (IoT RSP): SM-DSはアーキテクチャに保持されている

トリガーモデル

• SGP.22 (消費者向けRSP): 主にプル (QR / アクティベーションコード / アプリ)
• SGP.32 (IoT RSP): eIMとデバイスのチェックインパターンを介したプッシュおよび/またはプル

トランスポート姿勢

• SGP.22 (消費者向けRSP): HTTPS/TLS中心の消費者IPスタック
• SGP.32 (IoT RSP): IPベース; 制約されたデバイスオプションが強調されている (例: 仕様の業界要約におけるCoAP/DTLSパス)

解決する前任者の問題

• SGP.22 (消費者向けRSP): 物理的なSIM交換と消費者ハードウェアでのオペレーターのロックイン
• SGP.32 (IoT RSP): SGP.02の運用ロックイン、SMS依存性、および制約されたデバイスへの適合性の低さ

旅行eSIMの関連性

• SGP.22 (消費者向けRSP): 直接的 - これは典型的な電話旅行eSIMインストールの背後にあるスタックです
• SGP.32 (IoT RSP): 間接的 - 電話のQRフローではなく、隣接するIoT/旅行ハードウェアエコシステムを形成します

プロファイルライフサイクル: 同じ動詞、異なる文法 #

両方の世界はダウンロード、インストール、有効化、無効化、削除について話します。文法が異なります:

• SGP.22ライフサイクル はローカルでユーザー中心です。インストールされると、旅行者（またはLPA UI）がローミングデータ用にプロファイルを有効にするタイミング、一時停止するタイミング、削除するタイミングを決定します。
• SGP.32ライフサイクル はリモートでポリシー中心です。eIMは1つのEIDまたは複数にわたってプロファイル状態管理操作を発行でき、デバイスが到達可能なときにIPAがそれを実行します - これは一日の大半をスリープするデバイスにとって重要です。

それが「プロファイル切り替え」が各世界で異なる商業的意味を持つ理由です。消費者旅行では、切り替えはしばしば新しい購入またはユーザーが選択する2番目のインストールされたプロファイルです。IoTでは、切り替えは資産操作です: 接続プロバイダーを変更し、カバレッジに応答し、またはトラックロールなしでプロファイルを回転させます。

以前のIoT仕様の位置付け: SGP.02とSGP.31 #

シンプルなメンタルモデル:

1. SGP.02 - 元のM2M RSPで、SM-DP + SM-SRを使用。基盤的で、長寿命の資産（特に自動車や他の工場向けの展開）にまだ存在しますが、新しい制約のあるIoTプロジェクトではレガシーとして扱われることが増えています（1oT）。
2. SGP.22 - 消費者向けRSPで、SM-DP+とLPAを中心にプロビジョニングを簡素化しました。電話や旅行用eSIMのための大衆市場の道筋です。
3. SGP.31 / SGP.32 - IoT RSPで、SM-DP+を再利用しながら、eIM + IPAを追加してヘッドレスフリート管理を実現します。

SGP.32は消費者向けeSIMが「失敗」したから登場したのではありません。消費者向けeSIMが人間にとって成功したから登場したのです - そしてその成功は、輸送コンテナ内に固定されたセンサーを解決するものではありません。

旅行用eSIM、消費者ローミング、MVNOスタックへの影響 #

旅行の接続性は消費者向けRSPの物語のままです #

電話やほとんどの旅行者デバイスにとって、運用基準はSGP.22クラスの消費者向けRSPのままです。旅行者が気にする製品体験 - 出発前に購入し、QRまたはアプリでインストールし、到着時に接続される - は、LPA ↔ SM-DP+のフローに対応し、eIMフリートコマンドには対応していません。

GSMAの2026年の業界コメントは、旅行の接続性を国際ローミングにおける構造的な変化として位置付けています: アプリベースのeSIM旅行オファーはより透明で柔軟性があり、配布は旅行開始前にエンドユーザーに近づいています（GSMA: eSIMの大衆市場展開が予測から事実へと移行）。その商業的な変化は、IoT eIMの展開ではなく、消費者のRSPの成熟度とハンドセットのサポートに依存しています。

SGP.32が旅行関連のエコシステムに与える変化 #

旅行者がSGP.32に触れることがなくても、この標準は旅行の周辺で重要です。

• 接続された荷物トラッカー、フリート車両、物流センサー、会場のIoTは、QRコードの儀式なしでリモートプロファイル管理をますます必要としています。
• トラベルルーターや一部の「eSIMハードウェア」は、消費者スタイルのアクティベーションを人間の所有者に提供しつつ、規模が大きくなるとフリートのような運用ニーズを持つ、混沌とした中間に位置することがあります。
• オペレーターとMVNOは、両方を運営するかもしれません消費者向けSM-DP+エステートとIoT eIMエステート。SGP.22とSGP.32の間でSM-DP+のDNAを共有することは意図的であり、2つのデバイスクラスが同じUXや認証パスを共有することを意味するわけではありません。

マルチIMSI、MVNOスタック、そして真実の境界 #

マルチIMSI（接続製品内またはその横で選択可能な複数のID）とeUICCプロファイルのダウンロードはしばしば一緒に議論されますが、それらは同じメカニズムではありません。マルチIMSIは商業的なオファリング内でのネットワーク接続動作を改善することができます。eUICC RSP（SGP.22またはSGP.32）は、eUICC上で完全なオペレータープロファイルを安全にインストールし管理することに関するものです。旅行ブランドやMVNOは両方の技術を商業的に組み合わせることができますが、アーキテクチャの明確さは依然として重要です。消費者向けの旅行インストールはSGP.22の相互運用性とアクティベーションUXで評価され、IoTエステートはeIM/IPAの操作性と制約されたネットワークの耐性で評価されます。

IoT側からの有用な注意点は商業的にも適用されます。仕様における技術的な移植性は、契約における商業的な移植性を自動的に意味するわけではありません。SGP.32はSGP.02に関連する特定のアーキテクチャのロックインパターンを減少させますが、プロバイダーの商業条件は、フリートがeIMの関連付けや外部SM-DP+の関係をどれだけ自由に移動できるかを依然として決定します。1oT消費者向け旅行購入者は、より小規模なスケールで類似の教訓に直面します。相互運用可能なRSPは、それ自体でプロバイダー間で同一のカバレッジ品質、公正使用ポリシー、またはサポート体験を保証するものではありません。

市場のタイミングと採用のシグナル（公開、2025-2026） #

2026年の公開GSMA資料は、消費者向けeSIMが概念実証ではなく運用規模に入ることを説明しています。GSMAの2026年5月のGSMAインテリジェンスの数字の要約によれば、2025年末時点での世界のeSIMスマートフォン普及率は約5%であり、約2026年末までに10%、その後もさらなる成長が見込まれています。同じ記事では、約 4分の3 / 73% のモバイルネットワークオペレーターが 商用スマートフォンeSIMを提供している一方で、利用可能性と消費者のアクティブ化の間に残るギャップに言及しています（GSMAのマスマーケットeSIM記事)。

IoT側では、同じGSMAのコメントがSGP.32をグローバル製品バリアントと現場でのプロファイル切り替えの構造的な支援者として強調しています。これは、IoTプラットフォームが標準を位置付ける方法と一致する言葉です。仕様の成熟度もGSMAの公開テーブルで確認できます：SGP.31/SGP.32は2024年から2026年にかけて、アクティブなv1.2と新しいv1.3リストを通じて進化を続けており、関連するテスト仕様も含まれています（GSMA仕様インデックス)。

誇張せずに解釈すると：消費者向け旅行eSIMはすでにSGP.22レール上で商業的に拡大したユースケースです。SGP.32はIoT RSPの並行した産業化です。 これらはお互いを代替することなく、より広範なeSIMストーリーを強化します。

旅行者とブランドが知っておくべきこと #

旅行者向け #

旅行プランを購入する際にSGP.22とSGP.32のどちらかを選ぶ必要はありません。QRコードやアプリを通じて電話にeSIMをインストールする場合、あなたは 消費者RSP の世界にいます。重要なのは実用的なことです：出発前のデバイス互換性、インストールの信頼性、目的地のカバレッジ、透明なフェアユース条件、そしてゲートで何かがうまくいかないときのサポートです。

例えば Roamify は消費者向け旅行層に位置しています - 目的地プラン、デジタルインストール、海外でのオンラインユーティリティ - 産業用eIMフリート管理ではありません。QRの背後にある標準のストーリーは依然としてSGP.22の形をしています。

旅行ブランド、OTA、フィンテック、消費者向けMVNO向け #

• 扱う SGP.22の相互運用性とアクティベーションUX を製品の基盤とする。
• 実際のハードウェアやフリートアーキテクチャがIoT RSPを使用していない限り、「SGP.32」を旅行者向けのアップグレードとしてマーケティングしないでください。
• 接続性を販売またはホワイトラベルで提供する場合、トラッカー、ルーター、またはB2B旅行ハードウェア, デバイスクラスが消費者向けLPAフロー、IoT eIMフロー、または段階的なハイブリッドを必要とするかどうかを個別に評価してください。
• 教育に投資する: GSMA自身の市場コメントは、eSIMの利用可能性と消費者の理解/アクティベーションの間にギャップがあることを示しています。明確なインストールガイダンスは競争上の差別化要因として残ります。

オペレーターと接続プラットフォーム向け #

コンシューマーとIoTのRSPを並行して運用することはますます一般的になっています。共有されたSM-DP+の遺産が助けになりますが、認証、セキュリティ認定、デバイスエージェント（LPA対IPA）、商業運営モデルは依然として異なります。公共のメッセージングで語彙を混ぜると、旅行者と企業の購入者の両方に誤った期待を生むことになります。

結論：2つの標準、1つのeSIMの物語 - レーンを明確に保つ #

SGP.22とSGP.32は、単一のリーダーボードで競争するライバルではありません。これらは2つのデバイスの現実に対する答えです。

• SGP.22 は、人が存在し、コンシューマーデバイスにプロファイルを引き込むことができることを前提としています。これが、現代の旅行用eSIMが電話で動作するためのアーキテクチャです。
• SGP.32 は、デバイスが単独であるか、またはスリープ状態であり、eIMとIPAを通じてリモートでフリート対応の管理が必要であることを前提としていますが、SM-DP+プロファイルの配信を再利用します。これは、SGP.02の限界が明らかになった後にGSMAが制約されたIoTのために構築したアーキテクチャです。

旅行の接続性において、戦略的な教訓は精度です。コンシューマーRSPの道は、すでに人々がローミングを購入する方法を再形成しています。IoT RSPの道は、機械が何年も接続を維持する方法を再形成しています。これらのレーンを明確に保つブランドは、eSIMをより信頼性を持って説明し、実際に出荷している標準に合った製品を構築するでしょう。

ソフトブランドノート：Roamifyは、互換性のある電話でデジタルアクティベーションを提供する多くの目的地でプランを提供する旅行用eSIMプロバイダーです。この記事は標準の教育であり、RoamifyがIoT SGP.32フリート管理を実装しているという主張ではありません。