Intuneの導入を考えるときは、まず端末そのものを管理したいのか、業務アプリ内のデータを保護したいのかを整理します。さらに、端末の状態に応じて業務サービスへのアクセスを制御するなら、準拠ポリシーとMicrosoft Entraの条件付きアクセスを組み合わせる設計が必要です。
この記事では、情報システム担当者向けに管理方式の違いと導入前の確認事項を整理します。製品仕様はMicrosoftの公開資料に基づき、判断表と試行手順は編集上の提案として示します。
Intuneで管理するもの
Microsoft Intuneは、組織の端末とアプリを管理するクラウドサービスです。端末の登録、設定、アプリの配布や保護などを扱います。端末管理のMDMと、アプリ管理のMAMという二つの管理方式があり、目的に応じて単独または組み合わせて使います。Microsoft公式のIntune概要
導入要件を「Intuneを入れる」とだけ書くと、対象と完了条件が曖昧になります。「会社PCに指定の設定を配る」「私物スマートフォンで業務データの扱いを制限する」のように、端末・アプリ・データと実現したい操作を対にして整理すると、担当者間で確認しやすくなります。
MDMとアプリ保護をどう選ぶか
以下は管理範囲を決めるための検討案です。所有者だけで方式を決めず、必要な制御と対象OS・アプリの対応状況を照合してください。
| 導入目的 | 検討する方式 | 導入前に決めること |
|---|---|---|
| 会社端末に組織の設定を配布したい | Intuneへの端末登録を伴うMDM | 対象OS、登録方法、配布する設定、利用者への案内 |
| 私物スマートフォンの業務アプリ内データを保護したい | 登録なしのアプリ保護を検討 | 対応アプリ、対象ユーザー、許可するデータ移動 |
| 会社端末で設定管理とアプリ内データの保護を行いたい | MDMとアプリ保護の併用を検討 | 両方が必要な理由、対象OS・アプリでの対応可否 |
| 基準を満たした端末だけ業務サービスに接続させたい | 準拠ポリシーと条件付きアクセス | 判定基準、対象サービス、利用できない場合の復旧手順 |
MDM・MAMの基本的な役割はIntune概要、アプリ保護の適用範囲はアプリ保護ポリシーの公式資料に基づきます。アクセス制御との関係は準拠ポリシーの公式資料で確認できます。
登録なしのアプリ保護でも前提確認は必要
Intuneのアプリ保護ポリシーは、端末をMDMに登録せずに利用できる場合があります。対応アプリで業務データのコピーなどを制限する仕組みであり、任意のアプリすべてを対象にできるという意味ではありません。
利用者のMicrosoft Entraアカウント、Intuneライセンスの割り当て、ポリシーの対象ユーザーと対象アプリ、業務アカウントでのサインインを確認します。AndroidのMAMではCompany Portalアプリが必要です。また、AndroidのMicrosoft 365アプリではMicrosoft Entra IDへのデバイス登録が必要です。IntuneのMDM登録が不要であることと、認証やデバイス登録の手続きが一切不要であることは別です。アプリ保護の利用者要件とAndroidの注意事項
私物端末を対象にするなら、利用者への案内にも「対象アプリ」「初回に行う操作」「業務データの扱い」を書き分けることをおすすめします。
準拠ポリシーと条件付きアクセスの違い
準拠ポリシーは、管理対象端末が設定したルールや条件を満たすかを評価するものです。Microsoft Entraの条件付きアクセスは、その準拠状態をアクセス制御の判断に利用できます。Intuneの準拠ポリシー
準拠状態を判定する設計と、その結果でアクセスを制御する設計を分けて考えることが重要です。「非準拠になったら対象サービスを使えなくする」という要件では、Intune側の判定条件だけでなく、条件付きアクセス側の対象ユーザー・対象サービス・制御条件も確認します。
たとえば、OSの要件を導入する検討では、次の三つを別の確認項目にします。
- 対象OSで設定できる準拠条件は何か。
- 条件を満たさない端末で、想定した準拠結果になるか。
- その端末から対象サービスへアクセスしたとき、意図した制御になるか。
これは導入試験の組み立て例です。端末を登録できたことだけを導入完了の条件にせず、業務サービスへの接続まで試すために使います。
導入前にそろえる四つの前提
1. 対象端末と業務アプリの一覧
会社所有・私物、OS、利用者、必要なアプリ、既存の管理方法を一覧にします。Intune自体が対応するプラットフォームと、特定の設定やアプリ保護が利用できる範囲は、同じものとして扱わないようにします。機能ごとの要件はIntune概要とアプリ保護の資料から確認できます。
対象が多い場合は、最初から全機種に共通する設定を作るよりも、利用形態ごとに検証対象を選ぶ進め方を提案します。
2. Intuneと条件付きアクセスのライセンス
Intuneのサービスを利用するユーザーまたはデバイスには、適切なIntuneライセンスが必要です。契約中の製品に必要な利用権が含まれるかを確認してください。Intuneのライセンス要件
条件付きアクセスはMicrosoft Entra ID P1が必要な機能です。サインインリスクやユーザーリスクに基づく条件付きアクセスには、P2の機能であるMicrosoft Entra ID Protectionが必要です。Intuneを利用できることだけで、必要な条件付きアクセスの要件まで満たすと判断しないようにします。条件付きアクセスのライセンス要件
見積もりの前に「対象人数・端末」「使う機能」「既存契約で満たす範囲」「追加確認が必要な範囲」を分けると、契約名だけで比較するのを避けられます。
3. ポリシーの対象と例外
検証用の利用者と端末を決め、どの設定を誰に適用するかを表にします。共用端末など通常の利用者と条件が異なるものは、同じ設定で動くと仮定せず、個別の検証項目にします。
例外が必要な場合も、理由・担当者・見直し時期を記録する運用を提案します。「接続できないので対象から外す」だけで終わらせず、業務要件と管理基準のどちらを調整するかを決めます。
4. 問い合わせと復旧の担当
初回登録、端末交換、業務アプリにサインインできない場合、準拠基準を満たさない場合の問い合わせ先を決めます。利用者向けの案内と、管理者向けの調査手順を別に用意すると、誰がどこまで調べるかを共有できます。
小規模な試行で確認すること
以下は編集上の検証案です。実際に使うOS・アプリ・接続先に合わせて、期待結果を事前に記入してください。
| 試験 | 記録する結果 | 次の判断 |
|---|---|---|
| 対象ユーザーで登録・サインインする | 完了可否と利用者が行った操作 | 案内に足りない説明はないか |
| 必要な設定・アプリを利用する | 設定結果と通常業務の操作結果 | 管理要件と業務要件が両立するか |
| 準拠条件を満たす場合・満たさない場合を試す | 準拠状態と対象サービスへの接続結果 | 判定とアクセス制御が意図どおりか |
| 対応アプリで業務データを扱う | 許可・制限したデータ移動の結果 | 制限が業務に与える影響を許容できるか |
| 登録や接続に失敗した場合を調査する | 原因の確認方法と復旧までの操作 | 運用担当が対応できるか |
試行の完了条件は「エラーが出なかった」だけにせず、必要な操作ができること、制限対象の操作が期待どおり扱われること、問題発生時の担当が決まっていることに置くのをおすすめします。
委託する場合も管理範囲を先に決める
外部へ導入作業を委託する際は、「Intuneの設定一式」ではなく、対象整理・登録方式・ポリシー設計・試験・運用引き継ぎを成果物として分けると、依頼内容を具体化できます。
端末全体を管理する範囲、アプリ内のデータを保護する範囲、アクセス制御に使う基準の三点を整理し、検証で確かめる結果まで共有してください。それが、導入後に誰が何を管理するかを決める土台になります。