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

eSIM管理システムの発注は、まず業務と責任範囲を整理するところから始めます。そのうえで認定済みRSPを使ってPoCを行い、契約と検収条件を固めてから段階的に導入すれば、発注リスクを抑えられます。

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

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

eSIM管理システムの全体像

eSIM管理システムは、通信プロファイルを端末へ安全に配信し、契約・回線・端末を遠隔で管理する業務基盤です。販売用のEC画面に加えて、発行元やキャリアとの接続、端末の適合性、失敗時の再送も扱う必要があります。

発注では、自社で担う業務と認定済み事業者に任せる機能を先に決めます。構成によって設計する機能と運用の責任が変わるため、見積もりの前に切り分けておきます。

eSIM管理システムに含まれる主な機能

見積もりの対象になる主な機能は、識別情報とプロファイルの状態管理、端末への配布、業務システム連携です。

• 加入者情報：契約・料金プランに加え、EID、ICCID、IMSI、MSISDNを管理します。
• プロファイル：予約、割当、ダウンロード、開通、切替、停止、削除までの一連の操作を扱います。
• 端末配布：QRコードやアクティベーションコードのほか、APIやMDMによるゼロタッチ配布にも対応します。
• 業務連携：キャリア、BSS、課金、CRM、本人確認、サポート窓口との連携を扱います。
• 運用管理：権限、承認、操作履歴、証明書・鍵、バックアップ、障害通知、失敗時の再試行を扱います。

鍵管理と監査ログは、後回しにすると本番運用の直前で設計をやり直す可能性があります。そのため、これらも初期見積もりに含めます。

コンシューマ、M2M、IoTの違いと発注条件

対象端末と利用形態によって、選ぶ仕様やシステム構成が変わります。

• コンシューマ：SGP.21・SGP.22を中心に、LPA、QRコード、アプリ、本人確認、サポートを整理します。
• 車載・産業IoT：現地対応が難しい端末では、端末側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時間運用までを自社で持つ必要がある企業です。

判断では、事業規模に加えて、通信基盤を自社の競争力にするかどうかを見ます。

認定済みRSPのSaaS・APIを利用する方式

旅行者向けデータeSIMやMVNOの販売サイト、企業向けの回線申込など、短期間で始めるサービスに向いています。ベンダーのプロファイル生成・保管・配信や認定済みのセキュリティ基盤を、そのまま利用できます。

自社は商品画面や決済に注力できます。契約管理、顧客通知、分析ダッシュボードも、自社の業務として取り組めます。

初期費用を抑えやすい一方で、料金は月額と、発行・ダウンロードの従量で発生します。API利用とキャリア接続にも、料金がかかります。

• データとAPI：保存場所、APIのバージョン、解約時のデータエクスポートを確かめます。
• 障害時の処理：再送と失敗プロファイルの扱いを確認します。
• 認定と責任：対応するGSMA仕様・認定範囲と、認証・鍵管理の責任をRFPと契約書に残します。

パッケージ・マネージドRSPをカスタマイズする方式

加入者管理、課金、MDMなど、既存業務との連携が多い場合に適します。本人確認、CRM、監査ログとの連携も含まれます。

RSP基盤はベンダーに任せ、業務部分をカスタマイズします。SaaSと比べるとデータ分離や専用SLAを設計しやすく、スクラッチと比べると認定・セキュリティ運用の負担を抑えられます。また、通信キャリアやSIerが窓口になり、RSP事業者と構築する場合もあります。

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

専用環境・スクラッチで構築する方式

専用環境・スクラッチは、たとえば次の要件がある場合に候補になります。

• 大規模展開：複数国・複数キャリアにまたがる大規模IoTを運用します。
• 事業上の差別化：通信事業そのものを競争力にします。
• 独自要件：細かなデータ主権や独自オーケストレーションが必要です。

画面を自社仕様にすることと、SM-DP+、SM-DS、eIMを自社で運営することは別問題です。HSMやPKI、SAS-SM対応についても、自社で持つかは別に考えます。

スクラッチを選ぶ場合は、開発会社に加えて、RSP基盤、セキュリティ認定、キャリア接続の体制を用意します。クラウド運用、監視、障害対応も含め、これらを一体で整えます。

IDEMIA、Tele2 IoT、Ciscoは2026年3月、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での実機と失敗パターンの検証

PoCでは、画面が表示されるかだけで合格とせず、端末や回線の組み合わせと異常時の挙動を確かめます。

• 対象環境：iOS、Android、IoTモジュール、複数eUICC、異なるキャリアを使います。
• 通常操作：初回ダウンロード、切替、停止、削除、再インストールを試します。
• 異常系：弱電界、途中の電源断、通信タイムアウト、重複操作、端末交換、ローミング中の切替を検証します。

端末固有のプロファイル記述やOSの差で、同じeSIMでもインストール結果が変わる場合があります。そのため、実機やOSバージョン、eUICCの組み合わせを端末適合表に記録します。キャリアとプロファイルも、組み合わせの一部として残します。

再現手順とログの取得方法を決めます。大規模IoTでは、本番の一斉配布事故を抑えるために、量産前に検証環境で数千台規模の同時処理を想定した負荷試験を行います。

契約形態と責任分界の決め方

契約では、開発費に加えて、認定基盤とキャリア接続の責任を明確にします。また、証明書、監視、障害対応の責任も、同じ契約で定めます。さらに、データ移行と保守の責任も、契約に含めます。

関わる会社を一社にまとめるか、複数社に分けるかを決めます。その違いで、費用と障害時の調整方法が変わります。対象になるのは、RSP基盤ベンダー、通信キャリア・MVNO、SIerです。ほかに、受託開発会社やMDM・業務連携会社も関わることがあります。

一社一括契約のメリットと注意点

一社一括なら窓口が一本になり、要件定義から業務連携、運用設計までをまとめて進められます。通信に詳しいSIerがRSP事業者やキャリアを束ねる場合は、責任の所在も整理できます。

一次請けがどこまで自社で対応し、どこから再委託するかを確認します。確認しないと、障害時に「基盤会社へ確認中」という状態が続きます。

契約書には、再委託先、SAS-SMや関連認定の保持者、証明書更新担当を記載します。

• サービス水準：キャリア障害を含むSLAを定めます。
• 障害対応：プロファイル発行失敗時の再処理を決めます。
• 契約終了：加入者、プロファイル、監査ログの移行形式を事前に確認します。

複数社に分離発注する場合の管理方法

基盤は専門ベンダー、業務アプリはSIer、回線はキャリアやMVNO、端末配布はMDM会社に分けると、専門性を活かせ、特定ベンダーへの依存も抑えられます。

発注者は、API仕様、障害切り分け、個人情報、検収の順に管理します。ただし、社内に責任者を置けない場合は、複数社への分離より統合窓口が安全です。業務アプリ、RSP、キャリア、MDMを別々の会社に任せる場合は、境目で作業が止まりやすいため、担当範囲を発注時に書き出しておきます。

• 業務アプリ：契約登録と顧客通知を担当します。
• 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年）。こうした標準基盤を購入または利用し、自社の業務差別化へ予算を配分するかどうかを判断する材料になります。

月額・従量費・運用費と初期費用の切り分け

継続費は、サービス利用料と運用費に分けます。そのうえで、加入者数と発行数を含む3年TCOで比べます。

• 基盤・通信：RSP利用料、プロファイル発行・ダウンロード従量、API、キャリア接続、eSIMチップ・回線費です。
• 運用：クラウド、監視、保守、SAS関連の監査費です。
• 小規模運用：月20万〜100万円を仮置きできます。
• 大規模・専用環境：月100万〜500万円以上を仮置きできます。

最低利用量や国別料金も加わるため、発行数と加入者数を入れた3年TCOで、必ず比べます。

「運用保守一式」に、24時間監視や障害一次対応が含まれるかを確認します。キャリアとの調整や証明書更新も、含まれるかを確かめます。さらに、脆弱性対応、バックアップからの復旧、端末適合表の更新の扱いも見ます。

初期費用が安くても、月額の最低利用料やプロファイル単価が高ければ、加入者が増えるにつれて総額は逆転します。

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

外注は、企画から運用開始まで段階を踏んで進めます。途中で小さな検証を挟むと、端末との相性やキャリアAPIの不確かな点を、早い段階で把握できます。

1. 企画で対象顧客、事業モデル、運用条件を定めます。
2. RFPを作り、提案を同じ前提で比較します。
3. PoCで仕様、端末、キャリア、責任分界を確認します。
4. 要件定義、開発、試験を経て、移行と運用を始めます。

発注前の業務責任者と技術責任者の配置

発注側の責任者は、業務と技術の両方に置きます。どちらか片方だけで進めると、開通はしても、返金や本人確認が不足することがあります。業務要件は整っていても、端末試験が不足する場合もあります。

• 業務責任者：対象顧客、契約、料金、解約、返金、サポートのルールを定めます。
• 技術責任者：仕様、API、認証、ログ、性能、セキュリティ、移行を決めます。

発注者は、利用者と端末、キャリアの条件を一枚にまとめます。さらに、国、加入者数、月間発行数も記載します。また、ピーク、既存システム、SLAも添えます。

予算上限と希望時期も記載します。開発会社には、標準機能と追加開発を分けて提案してもらいます。前提条件、除外事項、第三者費用も、別に示してもらいます。

PoCから段階リリースへの移行

PoC、パイロット、本番移行の順に進め、対象を広げる前に品質と業務手順を確かめます。

1. 代表的な端末とキャリアを少数選び、契約登録からプロファイル配信、開通確認、停止・再開までを試します。
2. 複数端末、異常系、負荷、監査、復旧を検証します。
3. 対象顧客と端末数を限定したパイロットで、問い合わせ内容と失敗率を計測します。
4. 既存契約の移行単位、EIDとの紐付け、旧システムとの並行稼働、ロールバック条件、問い合わせ窓口を決めて本番へ移します。

新しいキャリアや国を追加するときは、審査、端末適合性、料金計算を、チェックリストにします。データ越境と法務確認も、リストに加えます。そうしておけば、初回リリース後も同じ手順で追加できます。

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

一般的なWeb制作の実績に加え、RSPやSIMセキュリティ、キャリア連携の実績を見ます。IoT接続、MDM、業務システム連携の実績も確認します。まず自社の課題を定め、そのうえで相談先を絞ります。

• 候補先：RSP基盤ベンダー、通信キャリア・MVNO、通信に強いSIer、eSIM API・MDM連携会社です。
• 相談内容：販売画面、プロファイル運用、複数キャリア接続のどこが課題かを整理します。

委託先へ確認する8つの質問

提案依頼では、仕様、責任範囲、運用の8点を確かめ、各社の回答を同じ条件で比べます。

1. 必要なSGP仕様と認定範囲は何か。
2. SM-DP+、SM-DS、eIM、IPA、LPA、キャリア、MDMのどこを担当するか。
3. 対応する国、キャリア、端末、OS、eUICCを証明できるか。
4. 発行失敗、途中切断、重複操作、端末交換を、どう再処理するか。
5. SAS-SMや関連GSMAコンプライアンスの保持者と証明範囲は何か。
6. データエクスポート、監査ログ、ベンダー変更時の移行方法は何か。
7. 初期、月額、従量、キャリア接続、端末試験、保守、認定、監査の別料金は何か。
8. 障害窓口、復旧目標、セキュリティ事故の通知時間と費用負担はどうなるか。

見積書の前提をそろえた比較

機能ごとに、標準機能か追加開発かの区分と作業量をそろえます。担当会社と前提、除外事項もそろえます。検収条件も、同じ表で比べられるようにします。

• 開発範囲：要件定義、UX・販売画面、RSP、加入者管理を区分します。
• 連携と安全性：BSS・課金、本人確認、CRM・MDM、セキュリティを区分します。
• 導入後：端末検証、移行、監視、保守を分けて見ます。

見積もりは、別料金の範囲を確かめたうえで比べます。「eSIM対応」「API連携」「セキュリティ対策」と書かれていても、中身は分かりません。

プロファイルのライフサイクル、キャリア追加、失敗時の再送は、機能と運用の両方で具体化します。さらに、認証・鍵管理、監査ログ、障害時の責任も、具体的に決めます。そのうえで、提案書に書かれていない事項は含まれないものとして質問し、議事録と契約書に反映します。

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

発注では費用のほか、仕様、認定、運用、契約終了時のデータ移行を確認します。よくある質問への回答は、費用、方式、要件の順にまとめます。

eSIM管理システムは500万円以内で開発できますか？

認定済みRSPのSaaS/APIを使い、対象キャリアや画面を絞れば、最小限の連携で500万円前後から検討できる場合があります。

複数キャリアや本人確認、課金まで含めると、500万円を超える可能性が高まります。MDM、端末検証、監視も含める場合は、その分を加えます。基盤利用料と業務アプリ開発費は、分けて見積もります。

eSIMのプロファイル基盤まで自社開発する必要がありますか？

多くの企業では、認定済みRSPを利用します。そのうえで、販売、契約、課金、サポート、分析などの業務差別化に、自社開発を集中させる方が進めやすいです。

通信基盤が事業の中核で、複数国・キャリア運用やデータ主権、独自切替、認定取得、24時間監視を担える体制がある場合は、自社開発を検討します。

RFPにはどこまで細かく書けばよいですか？

まず、対象仕様、顧客、国、キャリアを記載します。端末、加入者・発行数、既存システム、業務フローも書きます。SLA、セキュリティ、移行、予算、希望時期も含めます。

画面仕様のすべてを決めておく必要はありません。ただし、プロファイル状態遷移、責任分界、成功・失敗の検収条件は明記します。未確定の事項は質問として分け、各社が同じ前提で回答できるようにします。

まとめ

委託先は「eSIM対応」の一言で決めず、RSP基盤、加入者・契約管理、キャリア・課金連携まで分けて見ます。端末検証、セキュリティ、監査、運用も、一つずつ確認します。

事業上の必要性と運用体制に合う形を、認定済みSaaS/API、パッケージ・マネージドRSP、専用環境・スクラッチから選びます。

発注前の確認事項

まず、対象がコンシューマ、M2M、IoTのどれかを定めます。そのうえで、SGP.22やSGP.32などの仕様を選びます。さらに、業務フローと既存システムの境界を整理し、RFPの条件をそろえます。

見積もりは、初期費用だけでなく、月額、従量、第三者費用、保守、障害対応を含めた3年TCOで比べます。

最初の一歩となる小規模PoC

代表的な端末とキャリアで、発行から開通、切替、停止、失敗時の再処理までを検証します。そのうえで、委託先を決めます。

PoCのログと端末適合表をもとに本見積もりを取り、契約書に責任分界と検収条件を記載します。これにより、価格だけでは見えない発注リスクを減らせます。

▼全体ガイドの記事
・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を創業。