MDM・モバイル端末管理開発の進め方/やり方/流れや方法/手法/工程/手順

MDM開発は、要件整理から定着まで6つのフェーズを順に進めると、安全な端末管理につながります。

各段階で決めたことを次へ渡していくのが要点です。管理範囲から費用と見積もりまで順に説明し、全体像はMDM・モバイル端末管理開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・MDM・モバイル端末管理開発の完全ガイド

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

MDM・モバイル端末管理開発の全体像

MDMを導入するときは、管理コンソール、クラウドまたはサーバー、端末の管理機能を、一つの運用としてまとめて設計します。また、AppleやGoogleの登録基盤、IdP、業務アプリ、監査ログも連携対象になります。

端末の制御は、独自に作り込むより、OS公式機能や既製SaaSを活用します。そのため、MDMの追加開発は、自社固有の業務フローや連携部分に集中させるのが現実的です。

MDMで管理する範囲の決め方

管理対象を決めておくと、必要な製品機能の範囲を絞り込めます。MDMの基本機能は、次の5種類の端末管理に分けられます。

• 端末台帳：登録と解除、所有者や部署の管理です。
• セキュリティ設定：パスコード、暗号化、画面ロックを定めます。
• アプリと接続：業務用ソフトの配布、Wi-FiやVPNの構成の配信を行います。
• 更新と事故対応：OSの版を確認し、遠隔ロックや消去を行います。
• 監査：端末の状態や操作のログを取得します。

MAMはアプリや業務データを保護し、EMMはモバイル環境全体を管理します。さらに、UEMはPC・Mac・業務用端末まで横断して管理する考え方です。

スマートフォンの紛失対策だけで足りるか、PCや認証まで含めるかを、先に切り分けます。これにより、過剰な製品選定を避けられます。

会社支給・COPE・BYODによる要件の違い

所有形態によって、会社が設定できる制御やプライバシー上の配慮が変わります。そのため、形態ごとの扱いを先に整理しておく必要があります。

• 会社支給：業務に必要な制御を、比較的強く設定できます。
• COPE：会社所有で個人利用も認める形態であり、私的利用との境界線の決定が必要です。
• BYOD：私物端末を業務に使う形態で、取得する情報と取得しない情報、業務領域だけを消去する方法、退職時の解除方法を利用規程に明記します。

まず、端末の所有形態や利用場所、機密度を洗い出します。あわせて、iPhone・Android・Windows・Macの構成と既存の管理者人数も確認します。

洗い出した5つの項目を押さえると、製品の選定条件を具体的に絞り込めます。

既製SaaSと独自開発の役割分担

既製MDMと独自開発の役割を分けておくと、標準機能の活用範囲と追加開発の対象が明確になります。

• 既製MDM：端末登録、ポリシー配信、ゼロタッチ登録、遠隔ロック、OS更新は、市販の管理製品やMicrosoft Intuneで実現できる場合があります。
• 独自連携：人事、資産管理、ヘルプデスクとのAPI接続と、準拠状態に応じたアプリ制御が中心です。
• 個別機能：現場向けの管理画面やレポートを、必要に応じて追加する領域です。

MDM製品そのものをフルスクラッチで作る場合、OS更新、証明書、プッシュ通知、端末メーカー差分への継続対応が必要になります。そのため、事業上の明確な理由がある場合に限るのが安全です。

自動登録の効果は、機能一覧だけでなく作業時間で評価できます。たとえば、OPTiM Bizの公式事例では、iPhoneのキッティングにAutomated Device Enrollmentを利用しました。同事例では、初回キッティングが約600分から120分になった例が紹介されています（出典：株式会社オプティム「レンタル端末の運用を効率化するMDM」、2026年確認、同社調べ）。

自動登録で同じ効果が出るかは、端末の初期化、アプリ数、証明書、配送、利用者への引き渡しまで含めて、PoCで測ります。

MDM・モバイル端末管理開発の進め方

MDM開発では、誰が、いつ、どの権限で端末を管理するかを決めておくことが欠かせません。製品の契約と設定は、その決定に沿って進めます。

代表端末で検証してから段階的に展開するのが基本です。要件整理から定着まで、6つのフェーズを通して成果物と判断基準を確かめながら進めます。

フェーズ1：要件整理で決める「守る対象」と運用責任

要件整理では、端末の情報と必須機能、紛失時の責任を確認し、成果物としてまとめます。

• 端末台帳：台数・機種・OS・シリアル・所有者・部署・回線・拠点・業務アプリ・保存データ・既存IdPの一覧を作ります。
• 必須要件：台帳、認証・暗号化、アプリ配布、OS更新、紛失対応、監査ログ、退職者の無効化、復旧手順の整理です。
• 紛失対応：利用者の連絡先、本人確認とロックを誰が何分以内に行うか、ワイプの承認条件を決めます。
• 成果物：端末台帳、業務フロー、要件一覧、権限表、紛失対応フロー、BYOD利用規程の草案です。

フェーズ2：要件に照らした製品と方式の選定

選定では、価格に加えて端末との適合や既存環境を比べます。また、運用要件と実機検証も確かめておきます。

• OS・機種：対応範囲と自動登録の方式を確認します。
• 連携と支援：IdP・MFA、証明書、API、ログ保持、サポート体制の差を比べます。
• 既存環境：Microsoft 365利用企業はIntuneのライセンス重複を、店舗や物流現場は共有端末やキオスク、単一アプリ運用を確認します。
• 接続・復旧：閉域接続やオンプレミスでは、データ所在地や接続方式、冗長化、障害時の復旧方法を条件に含めます。
• 実機検証：iPhone、Android、Windows、業務用端末でPoCを行い、自動登録と既存アプリの動きを見ます。

選定では、Windows・Macの管理に加えて、Apple Business ManagerやAndroid Enterpriseによる自動登録も確認します。

フェーズ3：設計・開発での標準設定と追加開発の切り分け

設計では、設定方針と担当を決めたうえで、標準機能と追加開発の境界を定めます。また、端末のライフサイクルも、この段階で組み立てます。

• ポリシー：部署・職種別の設定、登録方式、アプリ承認、OS更新猶予、非準拠通知、管理者権限を決めます。
• ライフサイクル：新入社員への払い出しから、異動、故障交換、紛失、退職、再利用、廃棄までの流れを図にします。
• 担当分担：情報システム部門、総務、人事、現場責任者、ヘルプデスクへ受け持ちを割り振ります。
• 追加開発：人事・IdP・資産管理・業務アプリとのAPI連携を優先し、端末制御はOS公式APIか既存MDMに任せます。
• 設計書：標準機能、設定、個別開発、運用で対応する項目を分けて書きます。

フェーズ4：「登録できる」以外を検証するテスト

受入テストでは、登録できるかどうかに加えて、例外時の動作やワイプの安全性を確かめます。

• 基本機能：端末登録から構成プロファイル、アプリ配布、OS更新、パスコード違反までを確かめます。
• 例外対応：ネットワーク切断、証明書切れ、利用者の変更時に、どう動くかを試します。
• ロックと消去：遠隔ロックや、業務領域または端末全体のワイプを検証します。
• 調達要件：IPAのガイドを確かめ、脅威分析と要求仕様を検討します。
• 運用統制：障害復旧、監査、権限、個人情報の取り扱いまで、計画に含めます。

ワイプ対象を誤ると、業務・個人データを失います。そのため、申請者・承認者・実行者を分け、実行前後のログを残しておきます。

IPAの「IT製品の調達におけるセキュリティ要件リスト 活用ガイドブック 第2.1版」（2026年2月）を参照します。同ガイドは、モバイル端末管理システムを製品分野として扱います。

フェーズ5：段階稼働による現場の混乱の抑制

本番展開では、先行部署で課題を確かめてから全社へ広げます。利用者への案内や外部委託の責任分担も、事前に決めておきます。

• 展開順：情報システム部門、現場の代表部署、全社の順に進めます。
• 先行部署：初期化や交換が多い部署、通信が不安定な現場、共有端末の部署から選びます。
• 展開準備：利用者案内、管理者手順書、問い合わせ窓口、旧方式の停止日、切り戻し条件を決めます。
• 委託範囲：受け渡し、初期パスワード、配送、故障、再設定、廃棄の責任を、契約書と手順書に記します。
• 事例確認：導入時の運用変更や教育内容も見ておきます。

ソフトバンクの掲載例では、メディックスがBYODを廃止しました（出典：ソフトバンク「株式会社メディックス導入事例」、2025年8月掲載）。そのうえで、BCDM搭載の社用スマートフォンへ切り替え、研修とセキュリティ教育も行いました。

導入効果は、ツール単体ではなく、所有形態や教育、問い合わせ窓口を含む業務設計で決まります。

フェーズ6：指標と月次運用による定着の管理

成功の判断には、登録台数に加えて、未登録・非準拠端末数、古いOSの残存数、紛失受付からロックまでの時間を、月次で確認します。

初期設定時間や棚卸しの差異、退職者の権限削除漏れも確認対象です。問い合わせ件数も、あわせて追います。数値が悪化した場合は、ポリシー、教育、端末交換のそれぞれの責任者を見直します。

運用会議では、OSのサポート終了やMDMの仕様変更を確認します。証明書や契約の期限、管理者権限の棚卸しも、同じ場で扱います。その結果を、次の改善計画につなげます。

MDM・モバイル端末管理開発の費用相場と内訳

MDM費用は、ライセンスと初期設定に加えて、端末調達や連携、教育、運用代行の費用に分けて考えます。

公式料金のライセンス基準値と、導入規模から推定する初期費用は、性質が異なる数字です。ここで示すのは、公式料金と類似するエンドポイント管理や連携開発の事例から整理した目安で、正式な平均統計ではありません。

ライセンス費用の月額相場（200〜1,500円程度）

2026年8月時点の公式掲載例では、OPTiM Bizの初期費用は45,000円です。Android・iOS・iPadOSは月額300円、Windows・macOSは月額500円です（出典：株式会社オプティム「OPTiM Biz」公式料金、2026年確認、税抜）。

ソフトバンクのBCDMは、iOS・Androidが月額300円、Windows・Macが月額400円です。紛失時リカバリーや多要素認証などのオプションは別料金です（出典：ソフトバンク「BCDM料金」、2026年確認、税抜）。

Microsoft IntuneのPlan 1は、1ユーザー月額1,199円です。Plan 2は月額599円のアドオンです。Intune Suiteは月額1,499円相当です（出典：日本マイクロソフト「Microsoft Intuneの価格」、年払い・税別表示）。

• 課金単位：端末単位とユーザー単位のどちらが基準かを確認します。
• 既存契約：Microsoft 365に含まれる機能との重なりを確かめます。

Microsoftは2026年7月以降、Microsoft 365 E3・E5へIntuneの一部高度機能を段階的に含めると案内しています。

規模と連携範囲で変わる初期費用（20万〜1,000万円程度）

初期費用の推定レンジは、導入台数と連携・支援の範囲によって分かれます。

• 30台以下：既製SaaSの設定と基本教育を依頼する場合は、0〜30万円程度が起点です。
• 30〜300台：1〜2種類のOSを標準導入する場合は、20〜150万円程度です。
• 300〜1,000台：複数OS、SSO、自動登録、移行や研修を含めると、100〜500万円程度です。
• 連携案件：業務アプリやAPIとの接続で、300〜1,000万円程度です。
• 独自構築：自社向けの管理画面や閉域・オンプレミス環境は、800〜3,000万円程度まで広がります。

これらは公式の一律価格ではなく、台数や拠点、端末の種類などの条件から算出した推定レンジです。既存環境、セキュリティ要件、支援範囲も、この算出に含まれます。

ランニングコストと期間を含めたTCO

100台の場合、ライセンスだけなら月額2万〜15万円、年間24万〜180万円程度が基準になります。この金額には、端末代や通信回線、アプリライセンスは含まれません。キッティングや運用代行、問い合わせ対応に加えて、税と最低契約数も別に見込んでおく必要があります。

標準導入は数週間から2か月、複数OSやSSO、ゼロタッチ登録を含む場合は1〜4か月が目安です。API連携は3〜8か月、独自管理画面やオンプレミス構築は6〜12か月程度かかります。

MDM基盤そのものをフルスクラッチで開発する場合は、3,000万円以上、12〜24か月以上となる可能性があります。OSごとの互換性対応や保守体制も含めて、事業性を判断します。

MDMの見積もりを取る際のポイント

見積書では、初期設定費と月額ライセンスに加えて、端末のライフサイクルをどこまで支援するかを確かめます。

製品ベンダーや通信キャリア、導入SIer、追加開発会社では、担う役割が異なる場合があります。そのため、設計や設定、問い合わせ、障害対応の担当を明確にします。

RFPに明記する台数・OS・所有形態・運用条件

見積もり依頼書は、端末構成、既存環境、運用と接続の条件をそろえて作成します。

• 端末構成：台数と増加予定、OS・端末の内訳、会社支給・COPE・BYODの比率を書き入れます。
• 利用環境：拠点や利用者数、共有端末、業務アプリ、必要なAPIに加え、既存のMicrosoft 365やGoogle Workspace、IdPを記載します。
• 運用条件：遠隔ロックの初動目標、ワイプ承認、ログ保持期間、24時間サポートの要否を明記します。
• 導入条件：データ所在地、オンプレミス・閉域接続、導入希望日、研修対象、キッティング委託範囲を示します。
• 未確定事項：分からない点は分からないと明記し、想定ケースと追加費用の条件を出してもらいます。

複数社の同条件・PoC結果による比較

代表端末を使い、ゼロタッチ登録やアプリ配布、証明書、OS更新を確かめます。紛失時のロックとワイプ、BYODの業務領域消去、ログ出力も、各社で比べます。

提案書では、標準機能と個別開発を分けてもらい、設定作業や運用代行、別途ライセンスも区別して示してもらいます。実機や通信環境で動かない場合に備えて、各社でPoCの端末構成と合否条件をそろえます。

評価軸には、価格30点、要件適合30点、運用性20点、セキュリティ・監査10点、支援体制10点のように、重みを付けられます。そうすると、価格だけで決めてしまうことを避けやすくなります。

セキュリティ・個人情報・責任分界の見積もりへの反映

MDMでは、端末情報や利用者ID、アプリ一覧に加えて、位置情報や操作ログを扱う場合があります。

個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（2026年確認）を参照します。同ガイドラインは、安全管理措置や従業者・委託先の監督、漏えい時対応などを示しています。

発注側は、見積もりの段階で、対策と責任の範囲を整理しておく必要があります。

• 安全管理：アクセス権限や多要素認証、ログ保護、バックアップ、教育、委託先監査を費用に含めます。
• BYODの保護：個人領域は閲覧せず、業務領域だけを消去できるか、退職後に管理を解除できるかを確かめます。
• 作業範囲：端末登録、アプリ再署名、証明書更新、障害切り分け、利用者教育のそれぞれの担当を明記します。

支援範囲が曖昧だと追加請求になりやすいため、作業単位と責任者を見積書に残します。

MDM・モバイル端末管理開発でよくある質問

MDMでは、導入と開発の違いや必要な台数、BYODのプライバシー、フルスクラッチの必要性がよく問われます。それぞれ、社内の端末構成と運用体制に当てはめて判断します。

MDMの導入と独自開発は何が違いますか？

MDMの導入では、既製サービスを契約してテナントとポリシーを設定します。そのうえで、端末登録や利用者教育も行います。

独自開発は、人事・資産管理との連携、独自の管理画面、業務アプリのアクセス制御など、自社固有の機能を作ることです。

端末の基本制御まで自作する必要は通常ありません。そのため、差別化したい業務フローに開発費を配分するのが現実的です。

MDMは何台くらいから導入すべきですか？

明確な最低台数は定められていません。10〜30台でも、紛失時の初動や退職者のアカウント停止、アプリ配布、設定の標準化に課題があれば、効果を得られます。

台数が多くても、用途やOSが単純で既存機能で足りる場合があります。判断にあたっては、手作業の設定時間や端末の入れ替え頻度、機密情報、紛失時の影響から試算します。

BYODで会社が個人データを見過ぎないようにできますか？

可能です。製品機能に加えて、取得する情報や利用目的、管理者権限、ワイプの対象、社内規程を組み合わせて設計します。

業務アプリや業務データだけを管理するコンテナ方式、位置情報を取得しない設定、個人領域を遠隔消去しない運用を確かめます。そのうえで、従業員にも事前に説明します。

退職時には、会社の管理を解除したことを確かめられる手順も必要です。

MDM基盤をフルスクラッチ開発するべきですか？

多くの企業では、既製MDMやUEMを使い、独自開発は業務アプリや人事・資産管理との連携に限るほうが保守しやすいです。

MDM製品自体を提供するとき、特殊端末や閉域環境を標準機能で管理できないとき、既製サービスの契約条件が要件に合わないときは、検討します。

初期開発費に加えて、OSの新バージョンや証明書、通知基盤、端末メーカー差分、脆弱性への継続対応ができる組織と予算が必要です。

MDM・モバイル端末管理開発の進め方まとめ

MDM開発は、端末を登録した時点で終わらず、管理を続けられる状態まで整える取り組みです。要件整理で端末・利用者・データ・運用責任を明確にし、選定で対応OSと既存環境が合うかを確かめます。

設計・開発からテスト、段階稼働、定着まで順に進めると、現場で使い続けられる管理基盤になります。

端末ライフサイクルのチェック

まず、端末台数、OS、所有形態を一枚の資料にまとめます。そこに、拠点と既存IdP、業務アプリ、機密データも書き加えます。さらに、紛失対応時間、ログ保持、データ所在地を運用条件として記し、導入希望日と予算も加えます。

標準SaaSで足りるか、閉域や専用環境が必要か、API連携を追加するかを判断します。導入効果は、価格だけでなく、紛失時の初動時間や初期設定時間で測ります。

非準拠端末数、棚卸し精度、問い合わせ件数も、効果を測る指標にします。

PoCと見積もりの同条件での実施

製品を決める前に、代表端末で動作を確かめ、見積もりの条件と支援会社の役割をそろえます。

• PoC：端末登録やアプリ配布、OS更新、遠隔ロック、ワイプ、BYODの業務領域保護、ログ出力を確かめます。
• 費用比較：ライセンスや初期設定、キッティングなどの導入費と、連携開発、教育、保守、運用代行、追加費用を分けて比べます。
• 役割確認：製品提供者と導入・追加開発会社の受け持ちを分け、導入後の責任分界を確かめます。

▼全体ガイドの記事
・MDM・モバイル端末管理開発の完全ガイド

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