eSIM管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

eSIM管理システム開発は、対象端末と業務範囲を定め、仕様と提供方式を選び、実機で検証してから段階導入する流れで進みます。この順番で進めると、作り直しや予算超過を防げます。全体像から費用の目安、見積もりの確認点まで、順に説明します。

▼全体ガイドの記事
・eSIM管理システム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

eSIM管理システムの全体像

eSIM管理システムは、端末内のeUICCへ通信事業者のプロファイルを安全に配信する仕組みです。契約、回線、端末のライフサイクルを遠隔で管理します。

eSIM管理システムには、管理画面のほかに、RSP（Remote SIM Provisioning）基盤や加入者・契約の管理も含まれます。さらに、キャリアや課金との連携、障害対応、監査も一体で考える必要があります。

eSIM管理システムで管理する情報と機能

基本となるのは、加入者・契約・料金プランを、MSISDN・IMSI・EID・ICCIDといった番号と紐付ける機能です。そのうえで、プロファイルの発行から削除まで、状態を追跡します。

• 販売型サービス：QRコードやアクティベーションコードの発行から、決済、本人確認、メール通知までを扱います。
• 法人・IoT向け：MDMやデバイス管理と連携し、在庫や利用量、接続状態を扱います。ローミング条件や保守履歴も対象になります。

状態管理では、予約や端末への割り当てから、ダウンロードとアクティベーションを経て、切替、停止、削除まで追います。加えて、配信に失敗したときの再試行と、同じ要求を二重に実行しない仕組み（冪等性）も設計します。

管理者の権限分離や承認ワークフロー、操作履歴の記録も必要です。証明書の更新やバックアップも欠かせません。配信は非同期処理が多いため、画面表示後も端末側で未完了の場合があります。

コンシューマ・M2M・IoTごとの仕様の違い

スマートフォンやウェアラブルなどの端末では、GSMAのコンシューマ向け仕様であるSGP.21・SGP.22が対象になります。サーバ側のSM-DP+と、端末側のLPAが連携します。端末タイプごとの仕様と配信方式を確かめると、設計で押さえる点が見えてきます。

• コンシューマ端末：QRコードで開通させる場合は、OSや機種との組み合わせで、プロファイル記述とアクティベーション方式を検証します。
• IoT端末：画面や常時接続のない車載機器、スマートメーター、監視機器では、SGP.31・SGP.32が検討の対象です。
• 遠隔操作：eIM（eSIM IoT Remote Manager）は、eUICC上のプロファイルを遠隔でダウンロードし、切り替え、無効化し、削除します。
• 仕様の公開：SGP.32 v1.3の公開内容を確かめます。
• 対象機器：SGP.32は、ネットワークやUIに制約のあるIoT機器向けの仕様です。

QRコードで開通するサービスは仕組みが分かりやすい一方で、OS・機種・プロファイル記述・方式の組み合わせによって、失敗することがあります。また、IoT機器にスマートフォン向けの設計を流用すると、配布や障害対応のやり直しにつながります。

GSMAの仕様一覧では、SGP.32 v1.3が2026年5月に公開されています（出典: GSMA「eSIM Consumer and IoT Specifications」、2026年確認）。

eSIM管理システム開発の進め方・流れ

開発は、通信サービスの目的と、どこまでを誰が受け持つかを決めてから進めます。認定済みRSPベンダーに任せる部分と、自社で作る販売・契約・サポートの部分を分けると、納期と予算を安定させやすくなります。

企画から本番運用までは、6つの工程に分かれます。

1. 事業目的と対象デバイスの定義

最初に、利用者、端末台数、利用地域を決めておきます。たとえば旅行者向けのデータeSIMでは、購入、本人確認、決済が中心になります。また、QRコード発行、利用量表示、再発行も中心になります。

企業のスマートフォンを一括で配布する場合は、従業員、部署、端末の管理が基本です。そのうえで、MDM連携や退職時の停止、管理者承認は特に重要です。

車載や産業IoTでは、数年から十数年の機器ライフサイクルを定義します。さらに、複数キャリアの利用や国境を越えた接続切替、通信不能時の復旧も決めます。

2. 現行業務とシステム境界の整理

まず、既存のBSSや課金、CRMを確認します。ほかにも、本人確認や決済、MDM、サポート窓口を含めて洗い出します。そのうえで、どの機能を既存の仕組みに残し、どれをeSIM管理システムに持たせるかを決めます。

構成の例として、契約作成は既存のBSSで行い、プロファイル発行だけをRSPに依頼する形があります。一方で、加入者管理から請求までを新しいシステムにまとめる形もあります。

業務フロー図には、契約開始から開通、プロファイル再発行までを含めます。加えて、端末変更や休止、解約を描きます。返金や障害問い合わせの流れも、同じ図に入れます。

3. 仕様と提供方式の選定

対象仕様とRSPの提供方式は、事業の方針や運用の責任に合わせて選びます。

• 比較方式：RSPの提供方式を、SaaSやマネージド、専用クラウド、スクラッチの中から比べて選びます。
• 標準構成：認定済みRSPを使い、販売体験や契約業務、既存連携は自社が担います。
• 自社運用の条件：独自接続や大量配信のほか、データ分離や特殊運用のどれかが競争力になる場合です。

SM-DP+、SM-DS、eIMのどこまでを自社が受け持つかは、提供方式によって変わります。そのため、周辺の構成要素を含めて、担当の境目を図で確かめておく必要があります。

• LPA：端末側で、サーバ側のSM-DP+と連携します。
• eUICC：端末内にあり、プロファイルの配信先になります。
• IPA：IoT端末側でeIMと連携し、プロファイル操作を受け持つ構成要素です。
• HSM：自社で構築する場合は、鍵管理とあわせて担います。
• SAS-SM：法律とは別に、RSPのセキュリティ運用を評価する重要な業界要件です。

認定済みのサービスを使うか、自社で認定や審査を受けるかを先に決めます。この前提が曖昧なまま見積もると、費用と期間が大きく変わります。

Giesecke+Devrient（G+D）は2026年2月、AWSと連携したクラウド型のeSIMリモートプロビジョニングを発表しました。コンシューマとIoTの両方で、複数地域に展開できる構成です。

同社は、Amazonのeero Signal向けにSGP.32技術を商用展開していると公表しました（出典: G+D「G+D and AWS collaborate on new cloud-based Remote eSIM Provisioning」、2026年2月）。この事例から、今後はRSPを、認定済みクラウドの拡張性や地域分散、低遅延や運用責任まで含めて選ぶ必要があるといえます。

4. PoCによる実機と異常系の検証

本開発の前に、代表的なiOSやAndroid、Windows、IoTモジュール、eUICCを使って試します。プロファイルの発行から、インストール、開通を経て、切替と削除まで確かめます。

正常系に加えて、異常系も試験します。弱い電波や電源断、通信切断のほか、QRコードの再利用や端末変更も試します。期限切れやキャリアの応答遅延も、対象に含めます。

プロファイル記述と端末の相性によって失敗する場合があります。そのため、端末適合表とエラーコード別の対応手順を作っておくと有効です。

5. 業務画面・API・連携機能の開発

PoCで方式が固まったら、次の4点を実装と設計の対象にします。

• 画面・API：管理画面や利用者画面、APIを実装します。バッチや通知、監視も、あわせて作ります。
• プロファイルの状態：予約や発行中、ダウンロード待ちなどに分けます。有効、停止、削除済みも、状態として区別します。
• 例外処理：状態の遷移は一貫させ、非同期APIではタイムアウト後の再試行や重複要求の扱いを設計します。部分成功や手動復旧も、あらかじめ考えておきます。
• 連携の紐付け：課金やCRMとの連携では、契約IDとEID・ICCIDを追跡する共通キーを定めておきます。そうしておくと、問い合わせや返金の調査が速くなります。

6. 段階リリースと運用設計

本番運用は小さく始め、品質を確かめながら進めます。運用準備では、セキュリティ管理と障害対応を、その段階に合わせて整えます。

• 初期リリース：1キャリア、限られた端末、少数の加入者で始めます。成功率や失敗理由を確認します。問い合わせ件数と発行時間も見ます。
• 段階拡大：端末やキャリア、国、利用者数を広げ、API稼働や開通時間を監視します。失敗率や再試行、状態の滞留も見ます。
• セキュリティ運用：鍵や証明書の更新と、権限の見直しを行います。監査ログの保管や再発行の承認も、運用に含めます。
• 障害への備え：連絡先やキャリア変更への対応を、運用設計に含めます。バックアップや災害復旧も入れておきます。

国内で加入者情報や利用履歴を扱う場合は、個人情報保護法と、個人情報保護委員会の「電気通信事業における個人情報等の保護に関するガイドライン」を確認します（出典: 個人情報保護委員会、2026年確認）。

eSIM管理システム開発の費用相場とコストの内訳

eSIM管理システム単体の公開見積は少ないため、ここでの金額は、一般的な業務システムの相場にeSIM固有の要件を加えた推定です。対象には、認定や暗号鍵のほか、キャリア連携、端末検証、高可用性運用が含まれます。

2026年版の一般的な相場では、小規模が100万〜300万円、中規模が500万〜1,000万円、大規模が1,000万円〜数千万円以上です。人月単価は60万〜200万円程度です（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。

eSIM案件では、RSPや通信関連の費用が加わります。したがって、一般的なWebシステムの相場をそのまま当てはめないことが大切です。

方式別の初期開発費と期間の目安

初期費用と期間は、RSPの提供方式や連携の範囲によって変わります。そこで、構成ごとの費用感を比べます。

• 認定済みRSPのSaaS・API：最小限の管理画面と1〜2キャリアとの連携であれば、500万〜2,000万円、2〜6か月程度が目安です。
• マネージドRSP・パッケージ：課金・CRM・MDM等と連携する場合は、1,500万〜5,000万円、4〜10か月程度が目安です。
• 複数国・専用環境：5,000万〜1.5億円、9〜18か月程度となる可能性があります。
• RSPのスクラッチ開発：1億〜5億円超、18〜36か月以上です。

SaaS・API構成では、プロファイルの発行と配信の中核を購入します。契約や販売、課金は自社で構築し、本人確認やサポートも自社で用意します。

この方式は、短期で市場投入しやすい一方、月額の利用料と発行・ダウンロードの従量費がかかります。マネージド構成では、本人確認や監査ログまでが連携の範囲に入ります。

複数国・専用環境の構成は、複数国や複数キャリアに加えて、専用クラウドや冗長化、データ移行を含む場合に当たります。

自社でSM-DP+やSM-DS、eIMなどを作るスクラッチでは、HSMや鍵管理も担います。さらに、審査や24時間運用も引き受けます。

ここまでの金額は、ソフトウェアの初期費用の推定です。自社で認定や監査を行う場合は、審査対応やセキュリティ設備、証明書も予算化します。加えて、冗長化や災害対策、運用担当者の採用と教育も見込みます。

認定済みサービスは初期費用を抑えやすい反面、月額と従量課金がかかります。このため、総保有コストで比べます。

初期費用以外に必要なランニングコスト

運用費は、月額や従量料金だけでなく、どの支出がいつかかるかを含めて見る必要があります。

• 利用・接続費：RSPの月額と、発行・ダウンロードの従量料金、キャリア接続料を確認します。
• 運用費：クラウドや監視、保守が含まれるかを確かめます。端末検証、SLA、セキュリティ監査も対象に入るかを見ます。
• 予算の目安：小規模は月20万〜100万円、大規模専用環境は月100万〜500万円以上という初期仮説です。
• 有人対応：24時間監視や即時対応を求めると、新規開通が少なくても費用は下がりません。発行の自動化と既存窓口への問合せ統合で、工数を抑えられます。
• 複数年の総額：3年分の固定・従量・変更・更新費を合算します。

実額は、RSPやキャリアによって変わります。国や加入者数、ピーク時の配信数によっても変わります。ここに挙げた金額は、予算を作るための初期仮説で、eSIM共通の公開料金ではありません。

eSIM管理システムの見積もりを取る際のポイント

「eSIM対応一式」のような大きな項目のままでは、各社の提案を比べにくくなります。仕様やキャリア、端末、運用時間の前提に分けて確認します。初期費用と継続費も、別々に見ます。

RFPや要件定義書に観点を入れておくと、複数社の提案を比べる手がかりになります。

対象範囲と前提条件の仕様書への記載

仕様書では、デバイスや配布、連携の前提をそろえ、見積もりに必要な条件を明記します。

• 対象と仕様：デバイスやOS、eUICCのほか、国やキャリアを記します。料金プランや音声・SMSの有無も書きます。
• 想定規模：加入者数や新規開通数、ピーク時の同時配信数を記載します。
• 配布方法：QRコードのほか、アプリやMDMによるゼロタッチ配布、オペレーター承認のどれで配るかを決めます。
• 国ごとの条件：データ保管場所や越境移転を確かめます。現地の本人確認や、永続ローミングの可否も見ます。

既存の連携では、APIとデータの正を決めておく必要があります。たとえば、契約はBSS、プロファイルの状態はRSP、端末情報はMDMを正とする場合は、更新の順序と不整合時の復旧手順も必要です。

RFPには、EID・ICCID・契約IDの紐付けやAPI認証を含めます。さらに、タイムアウトや再送の扱い、監査ログ、データ出力の項目を入れます。解約時のエクスポートも忘れずに加えます。

開発会社・RSPベンダーの担当範囲

提案各社の専門性と、発注体制、認定の範囲を並べて比べます。

• 発注先の候補：RSPのほか、キャリアやMVNO、SIer・開発会社、MDM等の専門会社が考えられます。
• 1社に集約：責任の所在は明確になりやすい一方で、RSPやキャリアの選択肢が狭まる場合があります。
• 複数社に分担：専門性を活かせますが、障害時にAPIや画面、端末を切り分ける体制が必要です。
• 技術・認定：GSMA仕様やSAS-SMの認定範囲・サイト、接続先、端末、標準APIを質問します。
• 移行と責任：データの持ち出しやPoC・移行支援、障害時の分け方を確認します。認定対象は、証明資料で確かめます。

見積もりに含まれないリスクの洗い出し

見積もりの対象範囲と、将来の切り替え条件を項目ごとに洗い出します。

• 別料金の確認：RSPやキャリア接続の料金のほか、再発行や端末検証、データ移行の費用が別になるかを見ます。
• 運用費の確認：監視や夜間対応のほか、証明書更新やセキュリティ監査が含まれるかを確かめます。
• 発行機能の範囲：在庫の予約や承認、開通確認、失敗時の再送まで含まれるかを確認します。
• 移行可能性：加入者データやEID・ICCIDの対応表、監査ログ、契約履歴を取り出せるかを見ます。
• 契約時の条件：復旧目標やデータ保持期間、解約時の返却範囲を定めておき、将来の変更に備えます。

移行できないプロファイルや閉じたAPIがあると、後の変更費用につながります。そのため、キャリア変更やサービス統合も見据えておきます。

eSIM管理システム開発でよくある質問（FAQ）

eSIM管理システムは自社開発できますか？

販売画面や契約管理、課金連携、顧客サポートなどの業務機能は、自社で開発できます。一方で、SM-DP+やeIMを含むRSPの中核を運用するには、暗号鍵やHSM、認定、監査が必要です。さらに、冗長化や24時間対応も求められます。

そのため、認定済みRSPの利用から検討するのが現実的です。通信事業そのものが競争力で、長期にわたって認定や運用体制に投資できる企業でなければ、全面スクラッチは慎重に判断します。

eSIM管理システム開発の費用はどのくらいですか？

認定済みRSPのSaaS・APIを使う小規模構成では、初期費用が500万〜2,000万円、期間は2〜6か月程度が目安です。課金・CRM・MDM・複数キャリアの連携を含む場合は、1,500万〜5,000万円程度です。

専用環境や複数国対応では、5,000万〜1.5億円程度を見込む場合があります。この金額は、一般的な開発費とeSIM固有の要件から推定したものです。

月額や従量料金、キャリア接続、運用費を含めたRFPで、各社に個別の見積もりを取ります。

PoCでは何をテストすればよいですか？

代表的な端末で、発行やダウンロード、開通を確かめます。切替や停止、削除も確認します。さらに、弱い電波や電源断、通信切断の場面を試します。再試行や重複要求、期限切れ、端末変更も検証します。

コンシューマでは、iOSやAndroidといったOSの違いを確認します。一方、IoTでは、画面や常時接続がない状態、複数キャリアへの切り替え、長期間の再接続を確かめます。

成功率に加えて、失敗理由を記録し、運用担当者が復旧できるかまで検証します。

まとめ

開発前に最初に決める事項

eSIM管理システムは、販売画面だけでなく、プロファイルや加入者、端末を結ぶ業務基盤です。そのため、契約や課金、認証、監査までを含めて要件を定義します。

対象をコンシューマ、M2M、IoTのどれにするかで、SGP.22やSGP.32、LPAやeIMなどの構成が変わります。まず、対象デバイスと通信サービスの目的を決めておきます。

発注前の最終確認事項

認定済みRSPのSaaS・API連携は500万〜2,000万円程度で、業務連携を広げた構成は1,500万〜5,000万円程度です。一方、専用クラウドや自社認定を含む大規模構成は、5,000万円から数億円まで幅があります。

金額に幅があるため、発注前の確認では、金額の中身まで見ておく必要があります。

• 費用比較：初期費用と月額、従量費を分けて比べます。接続や検証、監視も切り分けて見ます。認定や移行、変更時の可搬性は、別の項目として扱います。
• 実機PoC：正常な開通に加えて、通信切断や電源断、重複要求を試します。再発行や端末変更、キャリア切替も対象です。
• 発注・展開条件：GSMA仕様や認定、個人情報・通信ルール、障害時の分け方を確認します。段階リリースで、作り直しと予算超過を防ぎます。

▼全体ガイドの記事
・eSIM管理システム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。