MDMとは？モバイルデバイス管理の仕組みとEMM/UEMの違い・選び方【情シス向け】

MDM（Mobile Device Management＝モバイルデバイス管理）は、社内のスマートフォンやPCを管理者が一元的に設定・監視し、紛失時にはリモートでロックやデータ消去まで行う仕組みです。この記事では、MDMの定義と動作の仕組み、構成プロファイルやAndroid Management APIで実際に何を書いて配るのか、混同されやすいMAM・EMM・UEMとの違い、iOS（Apple Business Manager）とAndroid Enterpriseの管理方式、BYODを含む端末の所有形態、そして「どんな企業が導入すべきで、どこからは過剰投資になるのか」までを情シス担当者の判断軸で整理します。製品比較の前に、自社に必要な管理範囲を見極めるための土台を提供します。

まとめ：MDMを導入すべき企業の条件と製品選定の勘所

MDMは、業務端末が十数台を超え、手作業での設定・棚卸しが追いつかなくなる規模から効果を発揮します。私物端末の業務利用（BYOD）や、営業・現場でのモバイル持ち出しがある企業では、紛失・盗難時の情報漏えい対策として実務上は導入必須の水準です。端末が数台で全員が同じオフィスにいる段階なら、MDMより先にパスワード管理や多要素認証を固めるほうが費用対効果は高くなります。

選定では、対応OS（iOS・Android・Windows・macOSの構成比）、BYODか会社支給かという所有形態、既存のID基盤との連携、この3点を先に固めることが出発点です。製品はモバイル単体のMDMからPCも含むUEM（統合エンドポイント管理）へ広がっており、将来PC管理まで統合する見込みがあるなら最初からUEM対応製品を選ぶと乗り換えの手戻りを避けられます。導入後に設定・棚卸し・OSアップデート追随といった運用が回らず放置される失敗も多く、自社運用と外部委託のどちらで回すかを導入前に決めておく必要があります。購入契約やライセンス数の突合まで管理対象に入る場合の線引きは、IT資産管理ツールとMDMの役割分担で条件を示しています。

技術的な中身は、AppleとGoogleが公開している管理仕様に沿って動きます。iOS／iPadOSはAppleが定義する登録方式（Apple Platform Deployment）、AndroidはGoogleのAndroid Management APIのポリシーが実体です。製品カタログの機能名で比べる前に、この仕様のどこまでを製品が使えるようにしているかを見ると、比較の解像度が上がります。

MDMの定義と管理できる項目の範囲・端末を制御する基本の仕組み

まずMDMが「何を」「どうやって」管理するのかを押さえます。ここを曖昧にしたまま製品を比べると、必要のない機能に費用を払うことになります。

MDMの定義と、管理者が遠隔から制御できる代表的な設定項目の範囲

MDMは、企業が配布・許可した端末に対して、設定・アプリ・セキュリティポリシーを管理者側から遠隔で適用するソフトウェアです。管理者が制御できる代表的な項目は次の通りです。

• パスコードの桁数・複雑性の強制と、一定回数の入力ミスでのロック
• 端末の暗号化やOSバージョンの強制、脱獄・root化端末の検知と隔離
• 業務アプリの一括配信・アップデートと、不許可アプリのインストール制限
• 紛失・盗難時のリモートロックとリモートワイプ（データ消去）
• 端末の機種・OS・シリアル番号・インストール状況といった資産情報の収集

端末の暗号化ポリシーを扱う際は、鍵管理や暗号方式そのものの理解が判断の前提になります。仕組みの詳細は暗号化とは何かを解説した記事で補ってください。MDM側では「暗号化を強制する／していない端末を業務から締め出す」という運用設計が主眼です。

MDMサーバーと構成プロファイルで端末を制御する基本の仕組み

MDMは、管理サーバー（多くはクラウド提供）と端末側のエージェント、そしてOS標準の管理機構を組み合わせて動きます。端末を管理下に「登録（エンロールメント）」すると、サーバーが発行した構成プロファイルが端末に配布され、そこに書かれた設定が適用されます。

1. 端末をMDMサーバーに登録し、管理対象として紐づける
2. Wi-Fiやメール、パスコードなどの設定をまとめた構成プロファイルを配布する
3. ポリシー違反や紛失を検知したら、サーバーからロック・ワイプなどの指示を送る

iOSやAndroidはOS自体にMDM連携の仕組みを備えているため、MDM製品は独自の抜け道ではなくOSが公開する管理APIを通じて端末を制御する構造です。つまり「OSが許した範囲」がMDMでできることの上限であり、製品ごとの差は主にコンソールの使い勝手・対応範囲・自動化の作り込みに出ます。Apple側では従来の問い合わせ型プロトコルに加えて宣言型デバイス管理（Declarative Device Management）が用意され、端末が自律的に設定を適用し、状態変化をサーバーへ報告する方式へ広がっています。定期ポーリングに頼らない分、台数が増えたときの反映の速さと負荷で差が出る部分です。

構成プロファイルにパスコードポリシーを書いて端末へ配布する手順

Apple環境の構成プロファイルは、ペイロードと呼ばれる設定の塊をplist（XML）で並べたものです。MDM製品の管理画面では画面上のトグルとして見えますが、実体は次のようなキーと値の集合です。Appleが公開するPasscodeペイロードの仕様には、各キーの型と適用可能なOSが列挙されています。

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>PayloadType</key>
  <string>com.apple.mobiledevice.passwordpolicy</string>
  <key>PayloadIdentifier</key>
  <string>jp.example.mdm.passcode</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
  <key>forcePIN</key>
  <true/>
  <key>allowSimple</key>
  <false/>
  <key>minLength</key>
  <integer>6</integer>
  <key>maxFailedAttempts</key>
  <integer>10</integer>
  <key>maxInactivity</key>
  <integer>5</integer>
</dict>
</plist>

forcePINでパスコードを必須にし、allowSimpleを偽にして単純な並びを禁止、minLengthで桁数、maxFailedAttemptsで失敗回数の上限、maxInactivityで自動ロックまでの分数を決めます。ここで見るべきは値そのものより、キー単位で仕様が公開されているという事実です。製品の管理画面に無い設定でも、仕様上のキーを製品がカスタムペイロードとして受け付けるなら適用できます。逆に、仕様に存在しない制御は、どの製品を買っても実現しません。この線引きを先に知っておくと、要件を製品担当者に投げる前に自分で判断できます。

リモートワイプとポリシー適用を軸にしたMDM主要機能の全体像

MDMの機能は多岐に見えますが、実務で効くのは「守り」と「配る」の2系統に集約できます。

紛失対応で最初に使うのはリモートロックです。位置情報や連絡での回収が見込めないと判断した段階で、リモートワイプに切り替えます。会社支給端末なら端末全体を、私物端末なら業務領域だけを消去する、といった消去範囲の使い分けが後述の所有形態と直結します。なお4つ目の「把握」はMDMだけで完結しません。ライセンスや保守契約まで含めた台帳運用は、IT資産管理の考え方を整理した記事の領域と重なるため、MDMが自動収集する情報をどこまで台帳の正とするかを決めておくと二重管理を避けられます。

MDM・MAM・EMM・UEMの違いとiOS/Androidごとの管理方式

製品ページでは「EMM」「UEM」という言葉が並び、どれを選べばよいか分かりにくくなっています。歴史的な発展の順に整理すると違いが見えます。

MDM・MAM・EMM・UEMへ広がった管理範囲と概念の違い

4つは対立する製品ジャンルではなく、管理対象が「端末」から「アプリ・データ」「PCまで含む全端末」へ広がってきた発展の段階と捉えると整理できます。正式名称は、MDMがMobile Device Management、MAMがMobile Application Management、EMMがEnterprise Mobility Management、UEMがUnified Endpoint Managementです。

実務での選び方はシンプルです。会社支給のモバイル中心ならMDMの範囲で足り、私物端末が主役ならMAMやEMMの考え方が要ります。PCとスマホの両方を1画面で見たいならUEMを選びます。製品カタログ上はMDMもEMM・UEMの一機能として包含されているため、「MDM製品」と「UEM製品のMDM機能」を同じ土俵で比較して構いません。実例として、マイクロソフトはIntuneをクラウドベースのエンドポイント管理サービスと位置づけ、モバイルとPCを同じコンソールで扱う構成を取っています。呼び名がMDMかUEMかではなく、自社の端末構成をその1画面で扱えるかを見てください。

iOSとAndroidで異なる端末の登録方式と管理範囲の設計

MDMの実際の挙動はOSの管理基盤に依存します。iOSはAppleが提供する法人向けの仕組み、AndroidはGoogleのAndroid Enterpriseに沿って管理します。

• iOS／iPadOS：Apple Business Manager（ABM）と自動デバイス登録（Automated Device Enrollment）を使うと、購入時点で端末をMDMに紐づけ、初期設定から管理下に置けます。私物端末向けにはアカウント駆動のユーザー登録が用意され、Appleの説明では組織のアカウント・設定・情報だけを管理し、適用できるペイロードと制限も限定された集合にとどまります。
• Android：仕事用プロファイルで私物端末内に業務領域を分離する方式と、会社所有端末を丸ごと管理するフルマネージド方式を、所有形態に応じて選びます。個人所有端末向けの機能一覧には、どの機能がどのAndroidバージョンから使えるかがバージョン単位で示されています。

この違いは料金や機能ではなく「私物端末で個人データにどこまで踏み込まないか」を決めます。BYODで社員のプライバシーと両立させたいなら、iOSのアカウント駆動ユーザー登録やAndroidの仕事用プロファイルを前提に製品を選ぶのが実務の定石です。ID連携では、Microsoft Entra IDやGoogle Workspaceのアカウントと結びつける方式が広く使われています。Entra ID側の構成が絡む場合は、Microsoft Entra IDの解説記事で用語と権限モデルを先に押さえておくと、MDM側の設定名の意味がつかみやすくなります。

Android Management APIでポリシーを作成して端末へ配布する

Android側で管理の実体になるのは、Android Management APIのpolicyリソースです。Googleのガイドでは、ポリシーは端末とアプリの管理設定をまとめた中核のリソースで、enterprises.policies.patchで作成・更新し、登録トークンにポリシー名を含めることで登録時の端末へ適用される、と説明されています。端末が同時に持てるポリシーは1つで、企業ごとに既定ポリシーを決めることもできます。

curl -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "https://androidmanagement.googleapis.com/v1/enterprises/LC0123abcd/policies/byod_standard" \
  -d '{
    "applications": [
      {
        "packageName": "jp.example.sales",
        "installType": "FORCE_INSTALLED"
      }
    ],
    "advancedSecurityOverrides": {
      "untrustedAppsPolicy": "DISALLOW_INSTALL",
      "developerSettings": "DEVELOPER_SETTINGS_DISABLED"
    },
    "personalUsagePolicies": {
      "personalPlayStoreMode": "BLOCKLIST",
      "maxDaysWithWorkOff": 7
    },
    "maximumTimeToLock": "300000",
    "screenCaptureDisabled": true
  }'

installTypeにFORCE_INSTALLEDを指定すると業務アプリが自動で入り、untrustedAppsPolicyのDISALLOW_INSTALLで提供元不明アプリの導入を止めます。personalUsagePoliciesは会社所有端末の私的利用領域に対する設定で、maxDaysWithWorkOffは業務プロファイルを止めたまま放置できる日数の上限です。パスコード要件を書くときの注意もあります。ポリシーの公式リファレンスでは、単数形のpasswordRequirementsは非推奨とされ、複数形のpasswordPoliciesを使う指定に変わりました。数年前のサンプルをそのまま持ち込むと、非推奨フィールドを踏んだ設定を書いてしまいます。仕様の該当ページを開いて現行のフィールド名を確認する習慣が、MDM運用では地味に効きます。

BYOD・COPE・COBOという端末所有形態ごとの管理設計

MDMの設計は「その端末は誰のものか」で大きく変わります。所有形態は主に3つです。

コストを抑えたい企業ほどBYODに寄りますが、私物端末を丸ごとワイプすると個人データまで消してしまうため、業務領域だけを分離・消去できる方式が前提になります。制度としての持ち込み利用をどう設計するかは、BYODの基本と導入判断をまとめた記事で全体像を確認してください。統制を最優先する現場（店舗端末・専用業務機など）はCOBOで機能を絞り込むほうが運用は安定しやすいでしょう。導入前にこの所有形態を部門ごとに決めておかないと、後からポリシー設計が破綻しかねません。

MDM導入で解決できるセキュリティ課題と運用でつまずくポイント

MDMは入れれば安心という道具ではありません。解決できる課題と、運用で現実に起きる詰まりを対にして把握しておきます。

紛失・退職・シャドーITに効くMDMのセキュリティ面での効果

MDMが直接効くのは、端末を起点にした情報漏えいの経路を塞ぐ場面です。電車内での置き忘れや盗難に対しては、遠隔ロックと、回収不能と判断した際のワイプで、端末内の業務データへの到達を断ちます。退職時には、端末返却を待たずに業務領域を消去して私物化を防げます。さらに、許可していないアプリやクラウドへの持ち出し（シャドーIT）も、アプリ制限とインベントリ収集で可視化・抑制が可能です。

端末側の対策は、ネットワークやアカウントの認証と組み合わせて初めて面になる、という関係です。人の出入り口である認証の全体像は二段階認証の仕組みを整理した記事で、端末の入り口はMDMで、と役割を分けて設計すると穴が減ります。端末上で動くマルウェアや不正操作そのものを検知する層はMDMの守備範囲外なので、EDRの仕組みを解説した記事と読み合わせて、統制（MDM）と検知（EDR）の境界を決めておくと投資の重複を避けられます。

プライバシーへの配慮と運用負荷というMDM導入後に生じる課題

導入後にこじれるのは技術よりも運用と合意形成です。私物端末に管理を入れると、位置情報やアプリ一覧まで会社に見られるのではという不安が現場に生まれるのは自然なことです。実際に管理者が見られる範囲を明示し、私物端末では業務領域に限定することを利用規程で示さないと、登録が進まず形骸化します。Appleのユーザー登録のように、利用者が自分の端末で何が管理されているかを確認できる仕組みを選ぶことも、説明のしやすさにつながります。

もう一つの詰まりは運用の継続です。新入社員のキッティング、退職者の端末回収、OSメジャーアップデートへのポリシー追随、脱獄検知時の対応は、導入時ではなく運用フェーズで毎月発生します。担当者が兼任のまま片手間で回そうとすると、ポリシーが古いまま放置され、監査で指摘を受ける状態に陥りがちです。

NISTと総務省の資料を使って自社のポリシー草案を組み立てる

ポリシーをゼロから書き起こす必要はありません。公開されている指針を土台にすると、抜けの少ない草案が短時間で作れます。NISTはSP 800-124 Rev.2「Guidelines for Managing the Security of Mobile Devices in the Enterprise」で、モバイル端末の脅威と対策を企業の管理プロセスとして整理しています。国内向けには、総務省がテレワークセキュリティガイドライン（第5版・令和3年5月）を公開し、同じページで中小企業向けの手引きや、iOS・Android・各種MDM製品を対象にした設定解説資料も配布しています（設定解説資料は2026年1月に更新）。

草案づくりの手順は次の流れが実務的です。

1. 守る対象を決める。業務データの種類（メール・顧客情報・図面など）と、それが載る端末を洗い出す
2. 所有形態ごとに管理範囲を決める。BYODは業務領域のみ、会社支給は端末全体、と線を引く
3. 指針の項目を自社の設定値へ翻訳する。パスコード桁数、自動ロック、暗号化、アプリ制限を具体値で書く
4. 運用イベントごとの担当と期限を書く。入社・退職・紛失・OS更新の4つは必ず入れる

ここまで書けば、製品への要件提示も、監査での説明も同じ文書で足ります。指針をそのまま社内規程に貼り付けるのではなく、自社の端末構成に合わせて設定値まで落とすことが、形だけの規程との分かれ目になります。

MDMを導入すべき企業の条件と製品選定・運用体制を分ける判断

ここからは製品カタログには書かれない、導入可否と運用体制の判断を言い切ります。ボリュームの大きいキーワードだからと全社導入を急ぐ前に、自社が本当にMDMを必要とする段階かを見極めてください。

MDMを導入すべき企業の条件と、投資を見送ってよい判断の場面

導入を推奨できるのは、次のいずれかに当てはまる企業です。業務端末が十数台以上あり手作業の設定・棚卸しが限界に近い、モバイルを社外へ持ち出す業務がある、私物端末で業務データを扱っている、監査や取引先要件で端末統制の証跡を求められる。このどれかがあれば、MDMは費用に見合います。

一方で、見送ってよい場面もはっきりしています。端末が数台で全員が同じ拠点にいて持ち出しもない段階では、MDMより先に多要素認証やパスワード運用、ディスク暗号化を固めるほうが投資対効果は高くなります。認証側の実装はワンタイムパスワードの仕組みを解説した記事を参照し、まず低コストの土台から着手するのが順序として妥当です。「台数が少なく持ち出しもないのに、要件を詰めずMDMだけ先に契約する」のは、機能を持て余す典型的な失敗パターンなので避けてください。

製品選定で最初に確認する対応OSの構成比とID基盤との連携観点

製品を比べる前に、自社の前提条件を数値で固めます。比較表の機能数ではなく、次の観点で候補を絞ると外しません。

• 対応OSの構成比：iOS・Android・Windows・macOSの台数割合。PCも管理するならUEM対応を選ぶ
• 所有形態：BYODが多いなら業務領域分離（仕事用プロファイル等）の作り込みを確認する
• ID基盤との連携：既存のMicrosoft Entra IDやGoogle Workspaceと接続できるか
• 料金体系：端末単位か利用者単位か、私物端末での二重カウントの有無
• ゼロトラスト方針との整合：端末の健全性を条件にアクセス制御と連動できるか

3番目のID連携と5番目のアクセス制御は、実は同じ設計思想の裏表です。端末の状態を条件に社内リソースへの到達可否を決める考え方はゼロトラストの記事で、IDの束ね方や多要素認証の選択肢は認証・ID管理の記事で整理しています。MDMを単独の道具として選ぶより、この2つの設計に組み込める製品かどうかで絞ると、数年先の構成変更に耐えます。

製品ごとの優劣は導入環境で変わるため、ここで特定ツールを1位と断定はしません。むしろ「対応OSとID基盤で候補を2〜3製品に絞り、無料トライアルで自社の登録・ワイプ・アプリ配信を実際に試す」進め方が、カタログ比較より確実です。試すときは、公式仕様に載っている設定が管理画面から本当に届くか、カスタムペイロードやAPI経由の設定を受け付けるかまで確かめておくと、導入後に「その項目は製品側で未対応」と判明する事故を防げます。

MDM運用を自社内製と外部委託のどちらで回すかを分ける判断基準

MDMの成否は、導入後に運用が回るかで決まります。専任の情シスがいて、キッティングや棚卸し、OS追随を内製で続けられるなら自社運用が最短です。担当者が兼任で、退職者対応やアップデート追随が滞りがちな体制なら、設計と定常運用を外部に委ねたほうが結果的に安く上がります。

判断の分かれ目は「毎月発生する運用イベントに、決められた期日で対応できる人手があるか」です。ここが不確かなまま製品だけ契約すると、ポリシーが古いまま放置される先ほどの失敗に戻ります。MDMの導入設計から運用代行、将来的な内製化までを見据えて体制を組みたい場合は、保守運用・内製化支援のサービスで自社に合った運用モデルを相談できます。ツール選定だけでなく「誰がどの頻度で回すか」まで含めて設計することが、形骸化を防ぐ最大の対策です。

よくある質問

情シス担当者からよく寄せられる、MDMの導入判断や運用に関する疑問に回答します。

MDMとEMM・UEMは何が違い、どれを選べばよいですか？

MDMは端末そのものの管理、EMMは端末に加えアプリ・コンテンツ・IDまで含む管理、UEMはスマホもPCも含む全エンドポイントの統合管理です。会社支給のモバイル中心ならMDMの範囲で足り、私物端末を扱うならEMM、PCとスマホを1つのコンソールで管理したいならUEMを選びます。多くの製品でMDMはEMM・UEMの一機能として含まれるため、将来PC管理まで広げる見込みがあるならUEM対応製品を最初から選ぶと乗り換えを避けられます。カタログの呼称に振り回されず、自社の端末構成をその管理画面で扱えるかを基準にしてください。

私物端末（BYOD）に会社のMDMを入れると個人データも見られますか？

管理者が見られる範囲は、OSの仕組みと設定で制限できます。iOSのアカウント駆動ユーザー登録やAndroidの仕事用プロファイルを使えば、業務領域だけを管理し、個人の写真・連絡先・私的アプリには踏み込まない構成が可能です。Appleの資料でも、ユーザー登録で管理できるのは組織のアカウント・設定・情報に限られ、適用できるペイロードと制限も限定された集合だと明示されています。紛失・退職時のデータ消去についても、対象は業務領域だけです。ただし範囲は製品と設定に依存するため、導入時に「会社が見られる項目」を利用規程で示し、社員の同意を得たうえで登録することが運用定着の前提になります。

スマホを紛失した場合、MDMでどこまで対処できますか？

まず遠隔からのリモートロックで第三者の操作を止め、位置情報で回収可能性を確認します。回収の見込みがないと判断したら、リモートワイプで端末内の業務データを消去する流れです。会社支給端末なら端末全体を、私物端末なら業務領域だけを消すといった消去範囲の使い分けができます。ネットワーク圏外や電源オフの端末には即時に指示が届かないため、パスコード強制や暗号化と組み合わせ、単独機能に頼らない多層の備えにしておくことが必要です。紛失時の連絡先と実行判断者を運用手順書に書いておくと、初動の遅れを防げます。

MDMの導入・運用にはどのくらいの体制が必要ですか？

導入時は対応OSと所有形態、ID基盤連携の設計に工数がかかり、運用フェーズでは新規端末のキッティング、退職者の端末回収、OSアップデートへのポリシー追随、脱獄検知への対応が継続的に発生します。専任の情シスがいれば内製で回せますが、兼任体制で運用が滞る懸念があるなら、設計と定常運用を外部委託して形骸化を防ぐ選択も有効です。台数と体制に見合わない製品を選ぶと運用負荷だけが残るため、体制設計を製品選定と同時に進めてください。

小規模な会社でもMDMは導入すべきですか？

端末が数台で全員が同じ拠点におり持ち出しもない段階では、MDMより先に多要素認証やパスワード運用、端末の暗号化を固めるほうが費用対効果は高くなります。業務端末が十数台を超える、モバイルを社外へ持ち出す、私物端末で業務データを扱う、といった条件のいずれかを満たした時点が、MDM導入を具体的に検討すべきタイミングです。規模が小さいうちは、まず低コストで効果の高い認証・暗号化の土台から着手するのが順序として合理的です。関連する内容として、入退室管理システムもご覧ください。

関連記事

• BYODとは？企業導入の背景とメリット・デメリット：私物端末の業務利用を制度として設計するときの前提を、MDMの管理範囲と合わせて確認できます。
• 二段階認証とは？仕組みと導入方法：端末側をMDMで守るなら、人の出入り口である認証の全体像も併せて設計すると穴が減ります。
• 暗号化とは？仕組みと種類：MDMで強制する端末暗号化の前提となる、暗号方式と鍵管理の基礎を解説しています。
• ワンタイムパスワードとは？仕組みと安全性：小規模段階でまず固めたい多要素認証の実装を、MDM導入前の土台として確認できます。
• IT資産管理とは？目的・ツール機能と選び方：MDMが集める端末情報を台帳運用へつなぐ考え方と、ツールの役割分担を整理しています。
• EDRとは？EPP・XDRとの違いと検知の仕組み：MDMで統制した端末の上で起きる攻撃を検知する層を、実装者向けに扱っています。
• ClickFixとは？攻撃手口と対策：MDMで管理する端末を狙うエンドポイント脅威の実例と、実装者向けの検知・防御を扱っています。