eSIM管理システム開発の発注/外注/依頼/委託方法について

eSIM管理システムの発注・外注では、販売画面だけでなく、プロファイルの発行・配信、加入者情報、キャリア連携、端末検証、監査ログまで含めて設計することが重要です。発注形態は、認定済みRSPのSaaS/APIを使う方式、パッケージをカスタマイズする方式、専用環境やスクラッチで構築する方式から、事業モデルと運用体制に合わせて選びます。

この記事では、eSIM管理システムを外注・委託する際の進め方を、発注形態の選択、RFPと要件整理、契約形態、2026年時点の費用目安、委託先の選定、見積書の比較方法まで実務目線で解説します。コンシューマ向け、企業端末向け、車載・産業IoT向けで何が変わるのかも整理しますので、開発会社への相談前にご活用ください。

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

eSIM管理システムを発注する前に知っておきたい全体像

eSIM管理システムは、端末に通信プロファイルを安全にダウンロードし、契約・回線・端末のライフサイクルを遠隔で管理する業務基盤です。eSIMを販売するEC画面だけを作っても、プロファイルの発行元、キャリアとの接続、端末の適合性、失敗時の再送処理は解決しません。最初に「どの業務を自社で持ち、どの機能を認定済み事業者に任せるか」を決めることが、発注の出発点です。

最低限、加入者・契約・料金プランと、EID、ICCID、IMSI、MSISDNなどの識別情報を管理します。さらに、eSIMプロファイルの予約、割当、ダウンロード、アクティベーション、切替、停止、削除といった状態遷移を扱います。QRコードやアクティベーションコードによる配布に加え、APIやMDMを通じたゼロタッチ配布が必要になる場合もあります。

業務側では、キャリア、BSS、課金、CRM、本人確認、サポート窓口との連携が発生します。管理者権限、承認ワークフロー、操作履歴、証明書と鍵の管理、バックアップ、障害通知、失敗したインストールの再試行も見積もりに含めます。特に鍵管理と監査ログを「将来対応」として後回しにすると、本番運用の直前に設計をやり直す可能性があります。

スマートフォン、タブレット、ウェアラブルを利用者が自分で開通する場合は、コンシューマ向けのSGP.21・SGP.22を軸に、LPA、QRコード、アプリ、本人確認、サポートを整理します。自動車や産業機器など、現地に人が行けない場所の端末を管理する場合は、端末側のIPAとサーバ側のeIMを用いるSGP.31・SGP.32が候補になります。従来型の大規模M2Mでは、SGP.01・SGP.02とSM-DP、SM-SRを前提にした構成が残る場合もあります。

GSMAは2026年5月にSGP.32 v1.3を公開し、ネットワークやユーザーインターフェースに制約があるIoT端末のeUICCを遠隔管理する仕様として整理しています（出典: GSMA「SGP.32 v1.3」、2026年）。したがってRFPには「eSIM対応」とだけ書かず、対象仕様、eIM・IPAの責任範囲、対応端末、キャリア、同時配信数を明記します。

eSIM管理システムの発注形態はどれを選ぶべきですか？

結論から言うと、初回の発注では認定済みRSPのSaaS/APIを中核にし、自社固有の販売、契約、課金、顧客サポートを開発会社へ連携してもらう方式が有力です。SM-DP+やeIM、証明書、認定、24時間運用まで自社で持つ必要がある企業だけが、専用環境やスクラッチを本格的に検討します。事業規模だけでなく、通信基盤を自社の競争力にするかどうかで判断します。

旅行者向けデータeSIM、MVNOの販売サイト、企業向けの回線申込など、短期間でサービスを始めたい場合に向きます。プロファイルの生成・保管・配信や認定済みのセキュリティ基盤をベンダーから借り、自社側は商品画面、決済、契約管理、顧客通知、分析ダッシュボードに集中します。初期費用を抑えやすい反面、月額、プロファイル発行・ダウンロード従量、API利用、キャリア接続の料金が発生します。

契約前には、データの保存場所、APIのバージョン、障害時の再送、失敗プロファイルの扱い、解約時のデータエクスポートを確認します。SaaS事業者がGSMAのどの仕様と認定範囲をカバーし、認証・鍵管理の責任をどこまで負うのかも、RFPと契約書の両方に残します。

加入者管理、課金、MDM、本人確認、CRM、監査ログなど、既存業務との連携が多い場合は、RSP基盤をベンダーに任せて業務部分をカスタマイズする方式が現実的です。SaaSよりもデータ分離や専用SLAを設計しやすく、スクラッチよりも認定やセキュリティ運用の負担を抑えられます。通信キャリアやSIerが窓口となり、RSP事業者と連携して構築するケースもあります。

一方で、ベンダー独自のワークフローやAPIに業務を合わせる必要があります。見積もりでは、標準機能と追加開発を分け、将来のキャリア追加、料金プラン追加、国追加、端末追加をどの単位で費用化するか確認します。標準仕様の範囲を超えるほど、納期と保守費が増えやすくなります。

複数国・複数キャリアをまたぐ大規模IoT、通信事業そのものが競争力になるサービス、細かなデータ主権や独自のオーケストレーションが必要な企業では、専用環境やスクラッチが候補になります。ただし、画面を自社仕様にすることと、SM-DP+、SM-DS、eIM、HSM、PKI、SAS-SM対応を自社で運営することは別問題です。

スクラッチを選ぶ場合は、開発会社だけでなく、RSP基盤、セキュリティ認定、キャリア接続、クラウド運用、監視、障害対応の体制を一体で用意します。2026年3月には、IDEMIA、Tele2 IoT、CiscoがSGP.32に対応した商用のエンドツーエンドIoTソリューションを発表しました（出典: IDEMIA「First commercial SGP.32 end-to-end IoT solution」、2026年）。このように、標準対応済みの構成を組み合わせて導入する選択肢が広がっているため、最初から全機能を自社開発する必要性を慎重に検討します。

RFPと要件整理では何を決めておくべきですか？

RFPでは、機能一覧より先に事業モデルと運用条件を書きます。対象がコンシューマ、企業端末、車載・産業IoTのどれか、国内かグローバルか、音声・SMSを扱うか、初年度と3年後の加入者数、月間発行数、ピーク時の同時処理数を具体化します。ここが曖昧なまま相見積もりを取ると、各社が異なる前提で金額を出すため比較できません。

申込、本人確認、契約、プロファイル発行、ダウンロード、開通確認、利用量計測、請求、休止、解約、返金、問い合わせまでを一枚の業務フローにします。そのうえで、既存のBSSやCRMが持つ情報と、eSIM管理システムが持つ情報を分けます。EIDと契約の紐付け、ICCID・IMSIの払い出し、料金プラン変更、キャリア切替の主担当を決めることが重要です。

機能要件には、プロファイル状態の一覧、非同期APIの再試行、重複リクエストの冪等性、失敗時のロールバック、通知、管理者承認を含めます。非機能要件には、稼働率、復旧時間、バックアップ、監査ログの保存期間、個人情報の保管場所、アクセス制御、証明書更新、障害時の連絡時間を含めます。数字で書けない要件は、検収条件にも落とし込みます。

PoCは、画面が表示されることだけで合格にしません。iOSとAndroid、対応するIoTモジュール、複数のeUICC、異なるキャリアを使い、初回ダウンロード、プロファイル切替、停止、削除、再インストールを検証します。電波が弱い状態、途中の電源断、通信タイムアウト、重複操作、端末交換、ローミング中の切替も試験対象にします。

端末固有のプロファイル記述やOSの差によって、同じeSIMでもインストール結果が変わる場合があります。実機、OSバージョン、eUICC、キャリア、プロファイルの組み合わせを端末適合表に記録し、再現手順とログの取得方法を決めます。大規模IoTでは、量産前に検証環境で数千台規模の同時処理を想定した負荷試験を行うと、本番の一斉配布事故を抑えられます。

eSIM管理システムの契約形態と責任分界をどう決めますか？

契約では、開発費だけでなく、認定基盤、キャリア接続、証明書、監視、障害対応、データ移行、保守の責任分界を明確にします。RSP基盤ベンダー、通信キャリア・MVNO、SIerや受託開発会社、MDM・業務連携会社を一社にまとめるのか、複数社に分けるのかで、費用と障害時の調整方法が変わります。

一社一括なら、窓口が一本化され、要件定義から業務連携、運用設計までをまとめやすくなります。通信に詳しいSIerがRSP事業者やキャリアを束ねる場合は、責任の所在を整理しやすいことも利点です。ただし、一次請けがどこまで自社で対応し、どこから再委託するのかを確認しないと、障害時に「基盤会社へ確認中」という状態が続きます。

再委託先、SAS-SMや関連認定の保持者、証明書更新の担当、キャリア側の障害を含むSLA、プロファイル発行失敗時の再処理を契約書に記載します。RSP事業者を変更するときに、加入者・プロファイル・監査ログをどの形式で移行できるかも、契約前に確認します。

基盤を専門ベンダー、業務アプリをSIer、回線をキャリアやMVNO、端末配布をMDM会社に分けると、専門性を活かしやすく、特定ベンダーへの依存も抑えられます。一方で、API仕様、障害時の切り分け、個人情報の取り扱い、検収の順番を発注者が管理する必要があります。社内にプロジェクト責任者を置けない場合は、複数社分離よりも統合窓口を設ける方が安全です。

分離発注では、システム構成図と責任分界表を契約書の別紙にします。例えば、契約登録は業務アプリ、プロファイル生成はRSP、通信状態はキャリア、端末への配布指示はMDM、顧客通知は業務アプリが担当します。エラーコード、相関ID、ログの保存場所を共通化すると、障害調査の時間を短縮できます。

eSIM管理システムの費用相場はいくらですか？

eSIM管理システム単体の公開見積は少ないため、以下は一般的な業務システムの相場に、RSP、認定、暗号鍵、キャリア接続、端末試験、高可用性運用の負荷を加味した2026年時点の推定です。税別の初期費用として、認定済みRSP SaaS/APIと最小限の画面連携は500万〜2,000万円、パッケージやマネージドRSPの業務カスタマイズは1,500万〜5,000万円が目安です。

専用クラウド環境で複数キャリア・複数国・大規模運用まで対応する場合は、5,000万〜1.5億円、9〜18か月程度を見込みます。SM-DP+、SM-DS、eIM、HSM、認定・審査、災害対策、24時間体制まで含むスクラッチは、1億〜5億円超、18〜36か月以上になる可能性があります。いずれもeSIM固有の公開価格ではなく、要件と責任範囲によって大きく変わる推定です。

近年は、認定済み基盤をクラウドで利用する選択肢が増えています。G+Dは2026年2月、AWSのクラウド基盤と同社のセキュリティ・GSMA準拠を組み合わせたコンシューマ向け・IoT向けのクラウド型RSPを発表しました（出典: Giesecke+Devrient「Cloud-Based eSIM Solution with AWS」、2026年）。これは、標準基盤を購入または利用し、自社の業務差別化へ予算を配分する判断材料になります。

継続費は、RSPプラットフォーム利用料、プロファイル発行・ダウンロード従量、API利用料、キャリア接続料、eSIMチップや回線の費用、クラウド・監視・保守、SAS関連の監査費に分けます。小規模運用では月20万〜100万円、大規模・専用環境では月100万〜500万円以上を仮置きできますが、最低利用量や国別料金が加わるため、必ず発行数と加入者数を入れた3年TCOで比較します。

見積書に「運用保守一式」と書かれている場合は、24時間監視、障害一次対応、キャリアとの調整、証明書更新、脆弱性対応、バックアップ復旧、端末適合表の更新が含まれるか確認します。初期費用が安くても、月額の最低利用料やプロファイル単価が高ければ、加入者数の増加に伴って総額が逆転します。

eSIM管理システムを外注する進め方

外注は、企画、RFP、提案比較、PoC、要件定義、開発、試験、移行、運用開始の順で進めます。いきなり本番システムの開発を依頼するのではなく、仕様と責任分界を確かめる小さな検証を挟むことで、端末相性やキャリアAPIの不確実性を早期に見つけられます。

通信サービスの責任者は、対象顧客、契約、料金、解約、返金、サポートの業務ルールを決めます。技術責任者は、仕様、API、認証、ログ、性能、セキュリティ、移行を決めます。どちらか一方だけで発注すると、技術的には開通しても業務上必要な返金や本人確認が実装されていない、または業務要件は決まっていても端末試験が不足している状態になります。

発注者側で、想定利用者、対象端末、キャリア、国、加入者数、月間発行数、ピーク、既存システム、SLA、予算上限、希望時期を一枚にまとめます。開発会社には、標準機能、追加開発、前提条件、除外事項、第三者費用を分けて提案してもらいます。

最初のPoCでは、代表的な端末とキャリアを少数選び、契約登録からプロファイル配信、開通確認、停止・再開までを通します。次に、複数端末、異常系、負荷、監査、復旧を検証し、パイロット利用へ進みます。パイロットでは対象顧客や端末数を限定し、問い合わせ内容と失敗率を計測します。

本番移行では、既存契約の移行単位、EIDとの紐付け、旧システムとの並行稼働、ロールバック条件、問い合わせ窓口を決めます。新しいキャリアや国を追加するときの審査、端末適合性、料金計算、データ越境、法務確認をチェックリスト化し、初回リリース後も同じ手順で追加できる状態にします。

委託先の選び方と見積比較のポイント

委託先は、一般的なWeb制作会社ではなく、RSP、SIMセキュリティ、キャリア連携、IoT接続、MDM、業務システム連携の実績を確認して選びます。候補にはRSP基盤ベンダー、通信キャリア・MVNO、通信に強いSIer、eSIM APIやMDM連携を提供する会社があります。自社の課題が販売画面なのか、プロファイル運用なのか、複数キャリアの接続管理なのかを整理してから相談先を絞ります。

提案依頼時には、第一に「必要なSGP仕様と認定範囲は何か」を質問します。第二に「SM-DP+、SM-DS、eIM、IPA、LPA、キャリア、MDMのどこを担当するか」を確認します。第三に「対応する国、キャリア、端末、OS、eUICCを証明できるか」を聞きます。第四に「発行失敗、途中切断、重複操作、端末交換をどのように再処理するか」を確認します。

第五に、SAS-SMや関連するGSMAコンプライアンスの保持者と証明範囲を確認します。第六に、データエクスポート、監査ログ、ベンダー変更時の移行方法を質問します。第七に、初期費用、月額、従量、キャリア接続、端末試験、保守、認定、監査の別料金を確認します。第八に、障害時の一次窓口、復旧目標、セキュリティインシデントの通知時間と費用負担を確認します。

比較表では、要件定義、UX・販売画面、RSP基盤、加入者管理、BSS・課金連携、本人確認、CRM・MDM連携、セキュリティ、端末検証、移行、監視、保守を行単位にします。各行について、標準機能か追加開発か、作業量、担当会社、前提、除外事項、検収条件を並べます。最安値だけを選ばず、何が別料金になっているかを確認します。

「eSIM対応」「API連携」「セキュリティ対策」という抽象的な記載だけでは不十分です。プロファイルのライフサイクル、キャリア追加、失敗時の再送、認証・鍵管理、監査ログ、障害時の責任を機能と運用の両方で具体化します。提案書に書かれていない事項は、原則として含まれない前提で質問し、議事録と契約書へ反映します。

eSIM管理システムの発注でよくある質問

eSIM管理システムの発注では、費用だけでなく、仕様、認定、運用、契約終了時のデータ移行まで確認する必要があります。ここでは、相談前によく寄せられる質問へ直接回答します。

認定済みRSPのSaaS/APIを利用し、対象キャリアや画面を絞れば、最小限の連携で500万円前後から検討できる場合があります。ただし、複数キャリア、本人確認、課金、MDM、端末検証、監視まで含めると、500万円を超える可能性が高くなります。見積もりでは基盤利用料と業務アプリ開発費を分けて確認します。

多くの企業では、認定済みRSP基盤を利用し、自社開発は販売、契約、課金、サポート、分析などの業務差別化に集中する方が進めやすいです。自社開発を検討するのは、通信基盤が事業の中核で、複数国・複数キャリアの運用、データ主権、独自の切替ロジック、認定取得、24時間監視を担える体制がある場合です。

対象仕様、顧客、国、キャリア、端末、加入者数、発行数、既存システム、必要な業務フロー、SLA、セキュリティ、移行、予算、希望時期まで書くと比較しやすくなります。細かな画面仕様をすべて決める必要はありませんが、プロファイルの状態遷移、責任分界、成功・失敗の検収条件は明記します。未確定事項は質問事項として分離し、各社が同じ前提で回答できるようにします。

まとめ

eSIM管理システムの発注では、「eSIM対応」という一言で委託先を決めず、RSP基盤、加入者・契約管理、キャリア・課金連携、端末検証、セキュリティ、監査、運用までを分解します。発注形態は、認定済みSaaS/API、パッケージ・マネージドRSP、専用環境・スクラッチの順に、自社の事業上の必要性と運用体制を照らして選びます。

まず、コンシューマ、M2M、IoTのどれを対象にするか、SGP.22やSGP.32などの仕様を決めます。次に、業務フローと既存システムの境界を整理し、RFPで加入者数、発行数、ピーク、キャリア、端末、SLA、認定、移行をそろえます。見積書は初期費用だけでなく、月額、従量、第三者費用、保守、障害対応を含む3年TCOで比較します。

委託先を決める前に、代表的な端末とキャリアで、プロファイルの発行から開通、切替、停止、失敗時の再処理までを検証します。PoCで得たログと端末適合表をもとに本見積もりを取り、契約書へ責任分界と検収条件を落とし込めば、安さだけでは見えない発注リスクを減らせます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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