eSIMプロファイルとは？中身の構造をTCA仕様から詳しく解説

こんにちは、コモン・クリエーションでIoT・SIMエンジニアリングサービスでプロジェクトマネジメントを担当している比嘉です。 本記事では、eSIM の説明で必ず登場する「プロファイル」が、データとして具体的にどのような形をしているのかを、その形式を定義する TCA の仕様に基づいて解説します。

はじめに

eSIM の解説記事では「プロファイルをダウンロードする」という表現が当たり前のように使われます。しかし「そのプロファイルとは結局どんなデータなのか」まで踏み込んだ日本語の資料はほとんどありません。答えは GSMA の仕様ではなく、TCA（Trusted Connectivity Alliance、旧 SIMalliance）が発行する仕様 eUICC Profile Package: Interoperable Format Technical Specification に書かれています。

本稿では、以下の項目について整理します。

• プロファイルの中身は何か — まずは全体像

• TCA eUICC Profile Package 仕様の位置づけと歴史（SAIP という呼び名）

• UPP（Unprotected Profile Package）と PE（Profile Element）の構造、ASN.1/DER による表現

• MNO の発注から、プロファイルが BPP（Bound Profile Package）として eUICC に届くまでの流れ

1. まず全体像から — プロファイルの正体をざっくり理解する

プロファイルとは、一言でいえば「SIM カード 1 枚分の中身を、チップの外に持ち出せる形式で記述したデータ一式」です。物理 SIM カードの製造では、カードベンダーがチップにファイルシステムや鍵、アプレットを直接書き込んで出荷します。eSIM では同じ内容をデータとして遠隔配送し、端末に載った eUICC（embedded UICC、eSIM 用のチップ）の中で「仮想的な SIM カード」を組み立てます。

このとき送られるのは、完成品の SIM のメモリイメージではありません。身近な例でいえば、組み立て家具の配送に似ています。完成した家具をそのまま送るのではなく、「部品」と「組み立て手順」を標準化された箱に詰めて送り、届いた先（eUICC）にいる組み立て担当者（Profile Package インタープリタ）が現地で組み立てる方式です。この「箱と部品と手順書の標準フォーマット」を定義しているのが TCA の eUICC Profile Package 仕様です。

プロファイルという「箱」に入っている代表的な部品は次の通りです。

• ファイルシステム（MF/DF/EF の階層と IMSI・ICCID などの初期値）

• 加入者鍵 Ki と認証アルゴリズム（Milenage/TUAK）のパラメータ

• PIN/PUK コード

• セキュリティドメイン（MNO-SD など）と Java Card アプレット

• OTA 用の RFM 設定など

つまりプロファイルは「契約情報のメモ」ではなく、SIM カード 1 枚を丸ごと再現できるだけの構成要素の集合です。ファイルシステムの中身についてはSIMカードの中身とは？MF/DF/EFのファイルシステムを解説も参照してください。

2. TCA eUICC Profile Package 仕様の位置づけ

2-1. TCA と SAIP

この仕様を発行する TCA は、SIM ベンダー各社が加盟する業界団体で、2020 年に SIMalliance から改称しました。仕様の正式名称は eUICC Profile Package: Interoperable Format Technical Specification で、SIMalliance 時代の経緯から SAIP（SIMalliance Interoperable Profile）という略称で呼ばれることも多くあります。2026 年時点の最新版は Version 3.4.1 です。

GSMA の RSP 仕様との関係は明確に分業されています。

GSMA SGP.22 は §2.5.2 で「Unprotected Profile Package は eUICC Profile Package 仕様に従った Profile Element TLV の並びである」と規定し、中身の形式を TCA 仕様に委ねています。

2-2. なぜ標準フォーマットが必要か

物理 SIM の時代は、カード内部のデータ配置はベンダー固有で問題ありませんでした。MNO に納品されるのは完成品のカードだからです。eSIM では、プロファイルを作る事業者と、それを受け取る eUICC の製造者（EUM）が別々の会社になり得ます。どのベンダーの eUICC にも同じプロファイルを正しくインストールするには、ベンダー中立の交換フォーマットが不可欠でした。仕様名の Interoperable Format（相互運用可能な形式）はこの点を指しています。

3. UPP と PE — プロファイルのデータ構造

3-1. UPP は PE の並び

保護（暗号化）される前のプロファイルの生データを UPP（Unprotected Profile Package）と呼びます。UPP の構造は非常にシンプルで、PE（Profile Element）と呼ばれる単位データを順番に並べたものです。各 PE は ASN.1（Abstract Syntax Notation One、データ構造の記述言語）で定義され、DER（Distinguished Encoding Rules）に基づく TLV 形式でバイト列にエンコードされます。

UPP = ProfileHeader | PE | PE | ... | PE | PE-End
      （先頭は必ずProfileHeader、末尾は必ずPE-End）

すべての PE は共通の PE ヘッダを持ちます。定義は次の 2 フィールドだけです（TCA 仕様 §8.1.3）。

PEHeader ::= SEQUENCE {
    mandated       NULL OPTIONAL,  -- この PE の処理が必須なら設定
    identification UInt15          -- Profile 内で一意な PE 番号
}

「mandated」が設定された PE を eUICC が処理できない場合、プロファイルのインストール自体が中止されます。設定されていなければ、未対応の PE は読み飛ばして継続できます。この仕組みにより、新しい機能を使うプロファイルと古い eUICC の共存が制御可能になっています。

3-2. PE の種類

PE は ProfileElement という ASN.1 の CHOICE 型として定義されており、代表的なものは次の通りです（TCA 仕様 §8.1.3）。

このうち PE-MF や PE-USIM などの「テンプレート PE」は、この仕様の効率化の要です。USIM の標準的なファイル構成は 3GPP TS 31.102 でほぼ決まっているため、全ファイルを 1 つずつ定義する代わりに「OID で識別されるテンプレート＋差分」だけを送ります。テンプレートは OID 2.23.143.1.2.x（143 は TCA を示す）の体系で管理され、DF_5GS 用や IoT 用も追加されてきました。テンプレートで表現できない独自ファイルは PE-GenericFileManagement で個別に作成します。

PE の並び順には「依存関係を壊さない」という規則があります。たとえば PE-USIM（ADF_USIM の作成）は MF の作成後、PE-Application はロード先セキュリティドメインの作成後に置く必要があります（TCA 仕様 §8.1.3 の順序規則）。

3-3. ProfileHeader — 「この eUICC にインストールできるか」の宣言

先頭の ProfileHeader は、プロファイルの識別情報と「インストールに必要な eUICC 側の能力」を宣言します（TCA 仕様 §8.2）。

• major-version / minor-version — 準拠する仕様バージョン。eUICC が major-version を未サポートならエラー unsupported-profile-version でインストールを中止する

• iccid — このプロファイルの ICCID（10 バイト）

• eUICC-Mandatory-services — 必要なサービスの一覧（ServicesList）。usim、milenage、javacard のほか 5G 向けの suciCalculatorApi など。未サポートのサービスがあればインストールは中止される

• eUICC-Mandatory-GFSTEList — 必要なファイルシステムテンプレートの OID 一覧

つまり ProfileHeader は「部品リストの表紙」であると同時に、eUICC との適合性チェックリストでもあります。ダウンロード前のエリジビリティチェック用に、eUICC 側の能力を表現する UICCCapability というビット列も同仕様で定義されています。

3-4. 具体例 — Full Profile の典型構成

TCA 仕様 ANNEX C には、USIM と補助 SD・アプレットを含む Full Profile の構成例が示されています。並び順のイメージは次の通りです。

IoT 向けには、これを大幅に簡略化した IoT ミニマルプロファイル（PE-IoT テンプレートを使用し、ProfileHeader・PE-IoT・PE-AKAParameter・PE-SecurityDomain・PE-End 程度で構成）も定義されています。制約の大きい IoT デバイス向けにプロファイルサイズを抑えるための仕組みです。

4. MNO の発注から BPP 化までの流れ

プロファイルの形式が分かったところで、そのデータが実際にどう作られ、どう配送されるかを整理します。登場するのは MNO（またはプロファイルを発注する事業者）と SM-DP+（Subscription Manager Data Preparation +、プロファイルの作成・保護・配送を担うサーバー）です。

4-1. プロファイル仕様の合意と発注

まず MNO と SM-DP+ 事業者（プロファイル作成者）の間で「プロファイル仕様」を取り決めます。ファイル構成、搭載アプレット、認証アルゴリズム、PIN 初期値といった雛形の設計です。その上で MNO は発注ごとに入力データ（ICCID・IMSI・Ki などの個別値）を提供します。SGP.22 はこの工程を「プロファイル仕様と入力データの取得はスコープ外」と明記しており（§2.5.2）、ここは今も事業者間の個別合意の世界です。

4-2. UPP → PPP → BPP — 3 段階の変換

SM-DP+ の中で、プロファイルは 3 つの形態を経て eUICC に届きます（SGP.22 §2.5）。

• UPP（Unprotected Profile Package）: 第 3 章で見た PE の並びそのもの。平文です。

• PPP（Protected Profile Package）: UPP を SCP03t（GlobalPlatform SCP03 の TLV 版セキュアチャネル）で暗号化・MAC 保護し、最大 1020 バイトのセグメントに分割したもの。保護鍵にはセッション鍵のほか、プロファイルごとのランダム鍵（PPK）も選べます。ランダム鍵方式なら、相手の eUICC が決まる前にプロファイルを一括で事前生成・備蓄できます（SGP.22 §2.5.3）。

• BPP（Bound Profile Package）: ダウンロード時に eUICC と SM-DP+ が鍵合意を行い、PPP を特定の 1 つの eUICC に「結び付けた（bind した）」最終形。鍵合意情報、ISD-P の設定、プロファイルメタデータ、（ランダム鍵方式の場合は）鍵置換パッケージ、そして PPP 本体の順で構成されます（SGP.22 §2.5.4）。

BPP を受け取った端末側では、LPA が BPP を APDU サイズに再分割し、ES10b 経由の STORE DATA コマンド列として eUICC に流し込みます。eUICC 内では ISD-R がセキュアチャネルを解き、Profile Package インタープリタが PE を先頭から順に処理して、新設された ISD-P の中に「仮想的な SIM カード」を組み立てます。ISD-R/ISD-P の役割はeUICCアーキテクチャとは？で解説しています。

4-3. インストール結果の報告

PE の処理結果は EUICCResponse として報告されます。PE ごとの状態コード（ok、pe-not-supported、not-enough-memory など）が定義されており、PE-End までの処理後、または途中でインストールが中止された時点で返されます（TCA 仕様 §8.11）。Consumer RSP ではこの結果が Profile Installation Result として eUICC の署名付きで SM-DP+ に届き、ダウンロード注文の完了・失敗が確定します。相互認証を含むダウンロード全体のシーケンスはeSIMプロファイルダウンロードフロー詳解で扱います。

まとめ

• プロファイルは「SIM カード 1 枚分の中身（ファイル・鍵・アプレット・設定）」を標準形式で記述したデータ一式であり、その形式は GSMA ではなく TCA の eUICC Profile Package 仕様（通称 SAIP、最新版 v3.4.1）が定義している

• 保護前のプロファイル（UPP）は、ASN.1/DER でエンコードされた PE（Profile Element）の並びで、先頭が ProfileHeader、末尾が PE-End

• ProfileHeader は ICCID や必要サービス（ServicesList）を宣言し、eUICC との適合性チェックの基準になる。テンプレート PE により標準的なファイル構成は差分だけで表現できる

• プロファイルは SM-DP+ 内で UPP → PPP（SCP03t 保護・分割）→ BPP（特定 eUICC への結び付け）と変換されて配送され、eUICC 内のインタープリタが PE を順に処理してインストールする

• 「中身の形式は TCA、配送と保護は GSMA」という分業構造を押さえると、eSIM の仕様群の全体像が読みやすくなる

プロファイルを「謎のダウンロードデータ」ではなく「PE の並び」として捉えられると、ダウンロードエラーの切り分けやプロファイル発注時の仕様調整が具体的に議論できるようになります。

参考規格

• TCA eUICC Profile Package: Interoperable Format Technical Specification Version 3.4.1 — Trusted Connectivity Alliance

• GSMA SGP.22 — RSP Technical Specification v3.1（プロファイル保護・配送は §2.5）

• GSMA SGP.21 — RSP Architecture v2.7

• GSMA SGP.02 — Remote Provisioning Architecture for Embedded UICC Technical Specification（SCP03t の定義元）

• 3GPP TS 31.102 — Characteristics of the USIM application

おわりに

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

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