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

SIM管理システム開発は、対象の分類、現行業務の洗い出し、少数回線のPoC、要件定義と連携開発の順に進めると、実運用に合う仕組みにつながります。

まず種類と流れを説明し、費用相場と見積もりの要点へ進みます。全体像は、SIM管理システム開発の完全ガイドもご覧ください。

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

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

SIM管理システムの全体像

SIM管理システムは、回線の識別情報を契約、端末、利用状況と結び、業務の状態を更新する仕組みです。

想定するシステムには複数の種類があります。最初に分類しておくと、必要な機能と費用のぶれを抑えられます。

加入者管理・IoT回線管理・eSIM管理の分け方

対象を分けておくと、必要な管理機能と運用範囲を決めやすくなります。

• 加入者管理：契約者、電話番号、料金プラン、認証、開通・停止、請求を扱う、BSS・OSSに近い仕組みです。
• IoT回線管理：Connectivity Management Platform（CMP）で、回線と端末をまとめて管理します。
• 社内端末管理：スマートフォンや業務端末の契約と端末台帳、資産管理が中心です。
• eSIM管理：eUICCに通信プロファイルを遠隔で配信し、切り替える機能です。

なお、社内端末管理は、見出しの3分類とは別の補足として扱います。

数百から数万台の端末と回線を台帳で管理すると、通信量の確認や利用停止、グループ単位の操作を効率よく行えます。

eSIMの仕組みは、コンシューマ向けならSM-DP+やLPA、IoT向けならeIMやIPAなどで構成されます。

自社でRSP基盤を持つ場合は、証明書や鍵、HSMの管理に加えて、冗長化と試験、GSMAのSAS認定への対応も準備します。

主要機能の構成（台帳・状態遷移・連携・監査ログ）

台帳と状態遷移を設計したうえで、操作履歴やAPI連携も同じルールで管理します。

• SIM台帳：ICCID、IMSI、MSISDN、EID、IMEIを、顧客、契約、端末、拠点、料金プランに結びます。
• 一括管理：CSVでの登録と出力、重複の検出、検索、絞り込みに加え、権限ごとの表示も用意します。
• 状態遷移：申込、在庫、準備完了、開通、利用中断、再開、停止、解約、廃棄、再利用の各状態を定めます。
• 監査と再実行：変更した人、時刻、理由を記録し、APIの冪等性と再実行の方法も決めておきます。

状態を自由に上書きできない設計にしておくと、キャリアAPIが一時的に失敗しても、二重開通を防げます。

2026年時点のSGP.32を含む適合性確認

適合性確認では、仕様版と実機の組み合わせ、商用提供の時期を確かめておく必要があります。

• 実機確認：端末、通信モジュール、eUICC、プロファイルの組み合わせを実機で試します。
• 仕様版：SGP.32 V1.3の採用可否を見極めます。
• RFP記載：SGP.22の設計をそのまま流用できるとは限らないため、採用版、試験仕様、対応事業者を明記します。
• 検証発表：SORACOMとKDDIが、SGP.32対応サービスの検証完了を発表しました。
• 提供時期：SORACOMは7月7日から、KDDIは2026年度下期から順次提供すると公表しました。

GSMAの仕様一覧で有効とされているのは、2026年5月22日に公開されたSGP.32 V1.3です（出典: GSMA「eSIM Consumer and IoT Specifications」、2026年）。

今回の発表対象は、SGP.32対応のIoT SIMとプロファイル管理機能で、発表日は2026年7月1日です（出典: SORACOM・KDDI「SGP.32対応IoT SIMの共同開発」、2026年）。

物理SIMの交換を減らしたい企業には有力な選択肢です。ただし、対応端末と利用できるプロファイルは、導入前に確認しておく必要があります。

SIM管理システム開発の進め方と6段階の流れ

画面から作り始めると、キャリア連携、請求締め、障害復旧の場面で手戻りが起きやすくなります。

発注側と開発会社で、業務の状態と、どこまでを誰が受け持つかを整理し、少数回線のPoCで実機、API、運用を確かめてから本開発に進みます。

1〜2段階目の対象範囲と現行業務の洗い出し

最初に、システムを使う人と管理対象を決めておきます。対象が変わると、必要なデータや可用性も変わるためです。

• 加入者・課金基盤：通信事業者向けに、契約と課金を管理する基盤です。
• IoT回線台帳：IoT機器の回線と通信状況を管理する台帳です。
• 社内端末管理：社内端末の契約と資産を扱います。

回線数とキャリア数は、スコープ表にまとめておきます。国内外の利用地域や、物理SIMとeSIMの比率も、同じ表に入れます。

また、利用者の権限と24時間運用の有無も書いておきます。そのうえで、申込から解約、再利用までの流れを業務フローにまとめます。

業務フローでは、入荷、在庫登録、端末割当の担当を確認します。出荷、開通、通信量確認の担当も決めておきます。停止と故障交換、返却と廃棄の担当も、あわせて確かめます。

各場面では、入力項目、連携先、例外処理も洗い出しておきます。特に、Excelやキャリア管理画面での二重入力、解約漏れ、請求データの手作業加工は、初期リリースで優先して扱う候補です。

3段階目の100〜1,000回線程度のPoCによる実機検証

PoCでは小さな業務シナリオを順に通し、実機と連携の課題を早い段階で見つけます。

• 基本操作：登録、開通、停止、再開、通信量取得の動きを確かめます。
• 通知と出力：アラート、CSV出力、キャリアAPI連携の動作を試します。
• 例外条件：重複操作、API遅延、端末オフライン、日付をまたぐ通信量を検証します。

回線数は本番と同じ規模でなくても構いません。ただし、正常な動きだけでなく、障害時の挙動も確かめておく必要があります。

eSIMでは、対応モジュールとプロファイルのダウンロードを実機で確かめます。さらに、切替後の再接続と、失敗時のロールバックも試します。

特定のプロファイルを前提にした端末は、通信事業者を変えると接続できない場合があります。

PoCでは、成功と失敗の条件、ログの取得方法、復旧手順を成果物に残します。これがあると、ベンダーの提案を同じ基準で比べられます。

4段階目の要件定義による状態・API・権限の確定

要件定義では、機能名を並べるだけでなく、状態遷移とデータの責任者まで具体化します。

• 状態と責任者：SIM、契約、端末の状態と、料金計算の締め日が指す意味を定義します。
• 例外ルール：解約済みSIMの再開、故障交換前の停止担当、停止中の月額請求を決めます。
• API仕様：開通、停止、再開、プラン変更、通信量取得、請求出力の仕様を記載します。
• API運用：認証、タイムアウト、リトライ、冪等キー、エラーコード、監査ログを定めます。
• 権限・非機能：一括操作と承認者、顧客別のデータ分離、RTO・RPO、ログ期間、個人情報の保管場所、委託先権限を、この段階で確定します。

各ルールは文章にしておき、矛盾した更新を防ぎます。

5〜6段階目の連携開発、テスト、移行、運用

本開発では優先順位を付け、接続先の条件を先に確かめておきます。

• 開発順：台帳・権限、キャリアAPI、利用量、料金・請求、通知、監査ログの順で優先度を付けます。
• 接続確認：ERP、CRM、決済、チケット管理ごとに、停止時間とデータ形式を確認します。
• 試験環境：本番と異なる場合は、疑似応答や障害注入を用意します。

テストでは、一括操作と同時操作、通信量の集計に加えて、請求締め、キャリア障害、重複実行も確かめます。

試験では、画面表示に加えて、権限の逸脱やバックアップからの復旧も試します。

移行時は、旧台帳と新台帳をICCID、IMSI、IMEI、契約番号で突き合わせます。そのうえで、重複や欠落、解約済みなのに利用中のレコードを洗い出します。

運用手順には、障害時のRunbookや問い合わせ窓口を含めます。さらに、脆弱性対応や、権限を確認し直す作業も入れます。

契約が終わったときのデータ返却と削除まで、あらかじめ決めておきます。

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

SIM管理に固有の全国統一の価格表や、自社でSM-DP+を構築する場合の公開見積は、ほとんどありません。

以下の金額は、2025〜2026年時点の企画段階での推定です。一般的な業務システムの工数と、公開されているIoT回線料金を参考にしています。

eSIMのセキュリティや認定の要件も、この推定の前提になっています。費用は、キャリア接続やデータ移行の内容、24時間監視、認定取得によって変わります。

対象範囲で変わる初期費用の幅（50万円から数億円まで）

初期費用は、既存サービスの設定から通信基盤の新設まで、対象範囲によって幅があります。

• SaaS・既存CMP設定：50万〜300万円程度です。
• 自社機能の追加：既存基盤にポータルなどを足す場合は、300万〜800万円程度です。
• 中規模業務システム：SIM・加入者管理で、800万〜2,000万円程度です。
• 連携・移行込み：複数キャリア、BSS・ERP、請求を含む場合で、1,500万〜5,000万円の範囲です。
• 通信基盤新設：RSPやSM-DP+を自社保有する場合は、3,000万〜1億円超です。

設定費には、テナントと権限、台帳移行を想定しています。さらに、簡単なAPI連携と操作説明も含みます。

自社ポータルや承認を追加すると、既存基盤でも費用が増えます。加えて、通知やCRM連携も入ると、その分の工数が上積みされます。

MNO・MVNO向けに、プロビジョニングや認証、課金、24時間運用まで新設すると、数億円規模になる可能性があります。

費用を左右する要因（キャリア数・請求・eSIM・非機能要件）

費用の差は、連携や運用の複雑さから生まれます。その複雑さは、回線とキャリア、請求、eSIM、非機能要件のそれぞれに表れます。

• 回線とキャリア：回線数、キャリア数、操作量、既存システムとの連携数で工数が変わります。
• 請求：法人、代理店、顧客ごとの料金や締め日で、ロジックが増えます。
• eSIM：プロファイルの発行と配信、端末適合、証明書、HSM、適合試験を、別項目で見積もります。
• 非機能要件：アクセス制御、監査、冗長化も、費用に含めます。

1社との単純な開通・停止連携であれば、範囲を絞れます。一方で、複数社をまたぐ切替では、仕様の違いや障害時の処理が増えます。

プロファイルや料金を切り替えるには、データの整合性を保つ設計も必要です。また、請求条件が細かい場合も、工数が増えます。

GSMAのSASは、UICC・eUICCやサブスクリプション管理サービスの安全性を確認する制度です（出典: GSMA「Security Accreditation Scheme」、2026年確認）。

自社で構築する場合は、認定の準備や監査対応が別途かかります。これに対し、認定済みの外部サービスを使えば、初期費用と責任範囲を抑えられる場合があります。

回線・クラウド・保守を含めた3年TCOでの比較

開発費だけで方式を選ぶと、月額料金や従量課金で、あとから費用が逆転する場合があります。そのため、出口費用も含めて3年TCOを比べます。

• 回線料金例：SORACOM Airの日本カバレッジは500MB込みで385円/月、IoT SIMは1枚あたり990円の初期費用です。
• 海外向け料金例：グローバル向けplan01sは1.8米ドル/月、カード型SIMの初期費用は5.5米ドルです。
• クラウド費用：計算資源、DB、ログ、監視、通知、APIゲートウェイ、バックアップ、転送、サポートの費用を含めます。
• 試算条件：回線数、月間通信量、日次の状態変更数、ログ保存年数、同時利用者数を前提に試算します。
• 3年総額：初期費用、月額固定費、従量費、保守・監視費、変更費、解約時の返却・移行費を計上します。

料金例の出典は、SORACOM「SORACOM Air」（2026年確認）です。回線やSIMの料金は、ポータルの開発費や保守費とは別に計上します。

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

見積もりの差は、開発会社の単価だけでなく、対象範囲の解釈からも生まれます。

業務フロー、データ、連携先は、どの会社にも同じ内容で示します。非機能要件や成果物、保守範囲もそろえて、提案を依頼します。

RFPに明記する回線数・API・eSIM・セキュリティ

RFPで規模、機能、技術条件をそろえておくと、各社の見積もりを同じ前提で比べられます。

• 規模：SIM種類、キャリア、現行と3年後の回線数、1日あたりの登録と状態変更の件数、同時操作数を記します。
• eSIM：物理SIMとの比率、SGP.02、SGP.22、SGP.32、端末、海外利用を明記します。
• 業務：状態遷移、料金単位、締め日、権限、CSV、通知、監査ログを指定します。
• 技術・運用：API、認証、リトライ、冪等性、SLA、RTO・RPO、障害代替、脆弱性対応を含めます。
• 成果物：設計書、API仕様書、テスト結果、移行計画、操作書、Runbookを求めます。

ローミングやプロファイル切替の条件、バックアップ、データ保持期間も、あらかじめ明らかにしておきます。

業務、技術、成果物を事前に定めておくと、納品後の運用が安定しやすくなります。

発注先の類型（通信基盤型・IoT CMP型・総合SI型）

発注先によって強みは違い、通信基盤、IoT管理、既存システムとの統合のどこに強いかで分かれます。

• 通信事業者・フルMVNO型：IIJ、SORACOM、KDDI、NTTドコモビジネス、ソフトバンクが候補です。
• IoT管理プラットフォーム型：回線管理基盤やIoT向け運用を相談します。
• 総合SI型：NTTデータなどは、ERP・CRM・データ基盤との統合で検討できます。

公開サービスがあるかどうかと、個別開発、キャリア横断、データ移行を請け負えるかどうかは、別々に確かめます。

発注先には、APIの冪等性、障害時の代替操作、SGP.32対応版と試験範囲を質問します。

監査ログの保存期間やデータ返却の形式、最低利用量のほか、月額以外の料金も確認します。

回答があるかどうかだけでなく、仕様書、SLA、サポート、類似運用、再委託先まで確認すると、価格以外の差が見えてきます。

見積書に残すリスク・検収条件・受け持ち範囲

障害や誤操作の影響を抑えるため、どこまでを誰が受け持つかと検収の条件を、見積書と契約書に具体的に書きます。

• 原因の切り分け：通信できない原因が、端末、eUICC、プロファイル、キャリア、API、クラウド、電波環境のどこにあるか分かりにくい場合があります。
• 障害対応：監視対象、一次切り分け、キャリア連絡、復旧目標、ログ提供範囲を決めます。
• 誤操作対策：停止や再開を誤ると多くの端末に影響するため、一括操作の承認と緊急停止の権限を定めます。
• 情報保護：通信の秘密や個人情報を扱う場合は、項目ごとの閲覧権限、暗号化、アクセス記録、委託先管理、削除方法を明確にします。
• ガイドライン確認：電気通信事業向けの指針と解説を、あわせて確認します。

個人情報保護委員会は、電気通信事業における個人情報等の保護に関するガイドラインと解説を公開しています。

2026年には、新旧対照表も更新されています（出典: 個人情報保護委員会「特定分野ガイドライン」、2026年確認）。

法務やセキュリティの確認は、設計と受入条件の段階で、後工程へ送らずに済ませておくと安全な運用につながります。

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

発注前によくある疑問への答えをまとめました。回線数やキャリア構成に応じて、PoCと要件定義で条件を具体化していきます。

SIM管理システムはSaaSとスクラッチ開発のどちらがよいですか？

選択は、必要な回線管理の範囲と自社独自機能の重要度によって決まります。

• SaaS・既存CMP：数百〜数千回線の台帳、開通・停止、利用量確認が中心なら有力です。不足する顧客画面や請求連携だけを、追加で開発できます。
• スクラッチ開発：独自の料金、認証、複数キャリア、プロビジョニングを競争力にしたい通信事業者が検討する方式です。

スクラッチの場合は、SAS、鍵管理、キャリア試験、24時間運用まで含めて、投資を判断します。

SIM管理システムの開発期間はどのくらいですか？

開発期間は、構築範囲や連携・運用の要件によって変わります。

• 既存サービス設定：1〜3か月が目安です。
• 追加開発：3〜6か月が目安です。
• 中規模業務システム：6〜12か月が目安です。
• 連携・運用込み：複数キャリア、BSS・ERP、eSIM RSP、データ移行、24時間運用を含むと、9〜18か月以上の場合があります。
• フル基盤：自社のフルプロビジョニング基盤は、18〜36か月を想定する場合があります。

キャリア試験の日程や端末の調達期間は、開発会社の作業期間とは別に見込んでおく必要があります。

SGP.32対応にすると必ず自社でeSIM基盤を作る必要がありますか？

SGP.32への対応では、必ずしも自社で作る必要はありません。対応と自社でのeSIM基盤の構築は別々に判断でき、外部APIを使う選択肢もあります。

• 外部サービス利用：認定済み事業者やeSIMサービスのAPIを使い、顧客、端末、契約、承認、請求のポータルに集中できます。
• 自社で管理：仕様、eUICC、鍵・証明書、HSM、SAS、適合試験、障害時のロールバックを見積もります。

外部サービスを使う場合は、データの返却と、どこまでを誰が受け持つかを確認します。

セキュリティ要件は何を見積もりに含めますか？

見積もりには、SIMや契約者、端末の識別子を保護する要件を入れます。認証情報、鍵、証明書の保護も、あわせて含めます。

• データ保護：通信・保存データの暗号化と、秘密情報の保管を定めます。
• アクセス管理：最小権限、強固な認証、管理操作の監査ログを設定します。
• 継続運用：バックアップ、脆弱性対応、委託先管理を含めます。
• 復旧と終了：承認、緊急停止、復旧訓練、契約終了時の消去・返却を定めます。

法令やガイドラインがどこまで当てはまるかは、通信事業者、法務、セキュリティ担当者と確認します。

まとめ

SIM管理システム開発では、まず加入者・BSS、IoT CMP、eSIM・RSPのどこまでを対象にするかを決めます。

発注側と開発会社で、業務の状態遷移を整理し、少数回線のPoCで実機、キャリアAPI、障害復旧を確かめてから本開発に進みます。

判断の要点：必要な通信機能だけを自社に持つ方針

台帳や開通・停止、利用量の機能は、自社で持つこともできます。請求、権限、監査ログも、自社で作ることができます。一方で、通信機能は必要な部分だけを自社に持ち、それ以外の通信やeSIM管理はSaaSやキャリアAPIに任せられます。

通信自体を競争力にするなら、認証、課金、プロビジョニングに加えて、SASや24時間運用まで含む基盤事業として考えます。

初期費用だけでなく、回線やクラウドの費用、従量課金まで含めた3年TCOで比べます。保守と変更、解約時の移行も、この中に入れます。

業務フローとPoC条件を1枚にまとめる作業

発注の前に業務フローとPoC条件を整理しておくと、各社の比較の前提がそろいます。

• 対象と業務：回線、キャリア、端末、eSIM規格、状態遷移、API、権限、請求、SLAをまとめます。
• 移行と安全性：移行データ、セキュリティ、契約終了時のデータ返却を決めます。
• PoCと提案：成功条件を具体化し、同じRFPを複数社に示して、技術と運用を比べます。

導入後は、課題に合う方式を選び、機能を段階的に増やして定着を目指します。

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

▼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を創業。