Microsoft Intune の「Third-party device compliance partners support in Microsoft Intune」は、Jamf Pro や Omnissa Workspace ONE UEM などのサードパーティ MDM／デバイスコンプライアンス製品が収集した準拠状態を Intune 経由で Microsoft Entra ID に連携し、条件付きアクセスの判定に使うための公式ガイドです。今回確認すべき結論は、すぐに全管理者が設定変更を迫られる更新ではないものの、対応パートナー、対象プラットフォーム、割り当てグループ、移行時のクリーンアップ手順を見直す価値が高いという点です。特に、macOS を Jamf Pro や Addigy、Mosyle、Fleet などで管理している組織、iOS／Android を Workspace ONE UEM や SOTI などで管理している組織は、条件付きアクセスで「準拠済みデバイス」を要求している場合に影響を受けます。
Microsoft Learn の該当ページは、本文上の最終更新日として 2026年6月24日が表示されています。一方、GitHub の履歴では 2026年7月1日にメタデータ更新、2026年6月30日に本文更新が確認できます。つまり、2026年7月1日時点での確認では、機能の全面刷新というより、サポート対象やドキュメント整理を含む運用確認ポイントの更新として読むのが実務上は適切です。(Microsoft Learn)
Microsoft Intune の Third-party device compliance partners とは
Third-party device compliance partners は、サードパーティのデバイス管理製品が判定したコンプライアンス状態を Microsoft Intune と Microsoft Entra ID に連携する仕組みです。
通常、Intune で管理している端末は Intune のコンプライアンスポリシーによって「準拠」「非準拠」が評価されます。一方で、すでに別の MDM 製品で端末を管理している企業では、端末の実態をサードパーティ側が持っているケースがあります。
たとえば、次のような環境です。
- macOS は Jamf Pro、Addigy、Mosyle で管理している
- iOS／Android は Omnissa Workspace ONE UEM や SOTI MobiControl で管理している
- グローバル拠点ごとに MDM 製品が異なる
- Intune へ全面移行中だが、一定期間は既存 MDM と併用する必要がある
- 条件付きアクセスでは「準拠済みデバイスのみ許可」を使いたい
この場合、サードパーティ製品が収集した端末状態を Intune に送り、Intune がその情報を Microsoft Entra ID に追加します。Microsoft Entra ID 側のデバイスレコードに準拠状態が反映されることで、条件付きアクセスの判定材料として利用できます。Microsoft Learn でも、パートナーが収集したコンプライアンス状態を Microsoft Entra ID に追加し、Intune が収集した準拠結果とあわせて条件付きアクセスに使えると説明されています。(Microsoft Learn)
今回の更新で管理者が最初に見るべきポイント
今回のドキュメント確認で重要なのは、「新しいボタンが増えたか」よりも、自社の条件付きアクセス設計が、現在サポートされている連携方式と一致しているかです。
| 確認項目 | 管理者が見るべきポイント | 見落とした場合のリスク |
|---|---|---|
| 対応パートナー | 自社利用中の MDM／コンプライアンス製品が一覧にあるか | 非対応製品の状態を条件付きアクセスに使えない |
| 対象プラットフォーム | Android、iOS/iPadOS、macOS のどれで利用するか | パートナーが未対応の OS に設定してしまう |
| 1プラットフォーム1パートナー | 同一プラットフォームに複数パートナーを割り当てていないか | 想定外の MDM authority 変更や評価不一致 |
| 割り当てグループ | 対象ユーザーグループが正しいか | 対象外ユーザーがブロック、または未評価になる |
| Intune ライセンス | 対象ユーザーに Intune ライセンスがあるか | 準拠状態の連携・評価が期待どおり動かない |
| 移行手順 | 旧 MDM から Intune MDM へ移す際に退役処理をしているか | Intune 側のクリーンアップが不完全になる |
特に注意したいのは、サードパーティコンプライアンスパートナーを追加すると、対象グループ内の該当デバイスでは、そのパートナーが MDM authority になります。これは単なるレポート連携ではなく、対象ユーザーの端末管理主体を切り替える設計要素として扱う必要があります。(Microsoft Learn)
影響範囲：どの組織が確認すべきか
今回の Microsoft Intune の更新ポイントは、すべての Intune 管理者に同じ重みで影響するわけではありません。影響が大きいのは、すでにサードパーティ MDM を使っている組織、または Intune への移行途中の組織です。
影響が大きい組織
次のいずれかに該当する場合は、早めに設定を確認してください。
- Jamf Pro、Addigy、Mosyle、Fleet などで macOS を管理している
- Omnissa Workspace ONE UEM、SOTI、Scalefusion、BlackBerry UEM などでモバイル端末を管理している
- 条件付きアクセスで「Require device to be marked as compliant」を使っている
- MDM を Intune に統合するプロジェクトを進めている
- グローバル拠点で複数の MDM 製品を併用している
- 合併・統合により、テナント内に複数の端末管理方式が混在している
条件付きアクセスでは、デバイスの準拠状態をもとにメール、Teams、SharePoint、業務アプリへのアクセスを許可またはブロックできます。Intune のコンプライアンス概要でも、Microsoft Entra Conditional Access はデバイスの現在のコンプライアンス状態に基づいてアクセス制御を適用すると説明されています。(Microsoft Learn)
影響が限定的な組織
次のような組織では、直ちに大きな設定変更は不要な可能性があります。
- すべての端末を Intune MDM だけで管理している
- 条件付きアクセスでデバイス準拠状態を使っていない
- サードパーティ MDM を利用していない
- BYOD 端末にはアプリ保護ポリシーのみを適用している
ただし、将来的に macOS 管理を Jamf Pro から Intune に移す、または買収先の MDM と統合する予定がある場合は、移行時のクリーンアップ手順を把握しておくべきです。
サポート対象のサードパーティコンプライアンスパートナー
Microsoft Learn の該当ページでは、一般提供としてサポートされるコンプライアンスパートナーが一覧化されています。2026年7月1日時点で確認した現在の主な一覧には、42Gears SureMDM、7P、Addigy、BlackBerry UEM、Citrix Workspace device compliance、CLOMO MDM、Fleet、IBM MaaS360、Jamf Pro、Iru、Ivanti Neurons for MDM、Ivanti EPMM、mobiconnect、Mosyle Fuse、Mosyle Onek12、Omnissa Workspace ONE UEM、Scalefusion、SOTI MobiControl が含まれています。(Microsoft Learn)
ここで重要なのは、一覧に名前があるだけで安心しないことです。Microsoft 公式ドキュメントにも、すべてのパートナーがすべてのプラットフォームをサポートするわけではないため、各パートナーのドキュメントを確認するよう記載されています。(Microsoft Learn)
たとえば、次のように確認します。
| 利用シーン | 確認すべきこと |
|---|---|
| macOS を Jamf Pro で管理 | Jamf 側の条件付きアクセス連携手順、ユーザー登録、準拠ポリシーの作成方法 |
| iOS／Android を Workspace ONE UEM で管理 | Intune 側の割り当て変更後に Workspace ONE UEM 側で手動同期が必要か |
| Fleet を利用 | Entra Conditional Access integration の対応範囲と対象 OS |
| 自社独自または新興 MDM を利用 | Self-service onboarding 済みか、Entra Application ID を取得できるか |
| 複数 MDM を併用 | 同じプラットフォームに複数パートナーを割り当てていないか |
特にグローバル企業では、日本本社では Intune、欧州拠点では Workspace ONE、米国拠点では Jamf Pro のように、拠点ごとに管理製品が異なることがあります。この場合、単純に全社一括で条件付きアクセスを強化すると、想定外のアクセスブロックが発生する可能性があります。
設定の基本フロー
サードパーティコンプライアンスパートナーを Microsoft Intune と連携する流れは、大きく分けて3段階です。
| 手順 | 作業内容 | 主な管理画面 |
|---|---|---|
| 1 | Intune 側でコンプライアンスパートナーを追加する | Microsoft Intune admin center |
| 2 | パートナー製品側で Intune／Entra 連携を構成する | 各 MDM 製品の管理コンソール |
| 3 | 対象デバイスをパートナー製品に登録し、準拠状態を送信する | 各 MDM 製品、Microsoft Entra admin center |
Intune 側では、Microsoft Intune admin center にサインインし、Tenant Administration > Connectors and Tokens > Partner Compliance management > Add Compliance Partner の順に進みます。その後、コンプライアンスパートナー、プラットフォーム、割り当てるユーザーグループを選択します。(Microsoft Learn)
Intune 側で設定する内容
Intune 側で特に重要なのは、次の3つです。
コンプライアンスパートナーの選択
一覧から利用するパートナーを選びます。Self-service onboarding 済みのパートナーを使う場合は、Custom MDM Compliance Partner を選択し、パートナーから提供される Microsoft Entra Application ID を入力します。Application ID が有効なオンボード済みパートナーに紐づいていない場合、構成は完了できません。(Microsoft Learn)
プラットフォームの選択
Android、iOS/iPadOS、macOS など、対象プラットフォームを選びます。Microsoft Learn では、複数のコンプライアンスパートナーを Microsoft Entra ID に追加していても、1つのプラットフォームに使えるパートナーは1つだけとされています。(Microsoft Learn)
この制約は実務上かなり重要です。たとえば、macOS の一部を Jamf Pro、一部を Addigy で管理している場合、同一テナント・同一プラットフォームでどのように整理するかを事前に決める必要があります。
割り当てグループの選択
Assignments では、対象パートナーが管理するデバイスを持つユーザーグループを選びます。この割り当てによって、該当ユーザーの対象デバイスでは MDM authority がパートナー側に変わります。対象ユーザーには Intune ライセンスも必要です。(Microsoft Learn)
グループ設計を誤ると、条件付きアクセスの結果が大きく変わります。たとえば、Jamf Pro 管理対象ではないユーザーを誤って Jamf 用グループに含めると、デバイス状態が期待どおり報告されず、アクセスがブロックされる可能性があります。
Omnissa Workspace ONE UEM 利用時の注意点
Omnissa Workspace ONE UEM を利用している場合は、Intune 側の割り当て変更だけで完了と考えないようにしてください。
Microsoft Learn では、Workspace ONE UEM を利用する場合、Intune admin center で保存した変更を Workspace ONE UEM コンソール側で手動同期する必要があると説明されています。手動同期するまで Workspace ONE UEM は構成変更を認識せず、新たに割り当てたグループのユーザーが正常にコンプライアンスを報告できない可能性があります。(Microsoft Learn)
実務では、次のような手順にしておくと安全です。
| タイミング | 作業 |
|---|---|
| 変更前 | 対象グループ、条件付きアクセス、除外用ブレークグラスアカウントを確認 |
| Intune 側変更 | Partner Compliance management で割り当てを変更 |
| Workspace ONE 側 | Azure Services の同期を手動実行 |
| 変更後 | Entra ID の Devices > All devices で準拠状態を確認 |
| 本番展開前 | 少数ユーザーで Teams、Outlook、SharePoint へのアクセスをテスト |
条件付きアクセスと連動している場合、同期漏れは単なる管理画面の表示遅延ではなく、実ユーザーの業務アプリ利用に影響する可能性があります。
移行期限はあるのか
今回の公式情報から読み取れる範囲では、特定の日付までにサードパーティコンプライアンスパートナー設定を変更しなければならない、という移行期限は示されていません。
ただし、移行期限がないことと、確認が不要であることは別です。特に次のような組織では、期限がなくても計画的に棚卸しを進めるべきです。
- 旧 MDM から Intune MDM へ段階移行している
- 条件付きアクセスの対象を拡大する予定がある
- サポート対象パートナー一覧に変更があった場合の影響を受けやすい
- macOS 管理を Jamf Pro から Intune に寄せるか検討している
- MDM 製品の契約更新時期が近い
特に契約更新やゼロトラスト施策のタイミングでは、「どの製品が準拠状態の正本になるのか」を明確にしておくことが重要です。
サードパーティ MDM から Intune MDM へ移行する場合の注意点
今回のドキュメントで実務上見落とせないのが、サードパーティ MDM から Intune MDM へ移行する際のクリーンアップ手順です。
Microsoft Learn では、サードパーティ MDM から Intune のフルスタックへ移行する場合、まずサードパーティ MDM サービス側から退役処理を開始し、その後 Microsoft Entra ID の MDM 列が None になっていることを確認してから Intune MDM に登録する流れが示されています。端末上で MDM プロファイルをローカル削除するだけでは、Intune 側のクリーンアップタスクが十分に実行されないとされています。(Microsoft Learn)
安全な移行手順は次のとおりです。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | サードパーティ MDM 側で対象デバイスの退役処理を実行 | ローカルでプロファイルを削除するだけにしない |
| 2 | Microsoft Entra ID でデバイスの MDM 列を確認 | None になっているか |
| 3 | Intune MDM にデバイスを登録 | Autopilot、Company Portal、ADE など移行方式に合わせる |
| 4 | Intune のコンプライアンスポリシーを割り当て | 対象ユーザー／デバイスグループを確認 |
| 5 | サードパーティ接続を無効化 | 全端末の移行完了後に実施 |
移行途中でありがちな失敗は、「端末の見た目上は旧 MDM が外れているが、Entra ID 側ではまだ旧連携の状態が残っている」ケースです。この状態で Intune に再登録すると、準拠状態の評価が期待どおりにならず、条件付きアクセスで予期しないブロックが発生することがあります。
条件付きアクセスとの関係を整理する
Third-party device compliance partners を理解するうえで、条件付きアクセスとの関係は避けて通れません。
Intune のコンプライアンスポリシーは「その端末が組織の要件を満たしているか」を判定します。一方、条件付きアクセスは「その判定結果を使って、Microsoft 365 や業務アプリへのアクセスを許可するか」を決めます。
| レイヤー | 役割 | 例 |
|---|---|---|
| サードパーティ MDM | 端末の状態を収集・管理 | OS バージョン、暗号化、脱獄／root 化、管理状態 |
| Intune | パートナーからの準拠状態を受け取り Entra ID へ反映 | 非準拠デバイスを Entra ID 上で not compliant とする |
| Microsoft Entra ID | デバイス ID と準拠状態を保持 | Devices > All devices で確認 |
| 条件付きアクセス | 準拠状態に基づきアクセスを許可・拒否 | 準拠済みデバイスのみ Exchange Online を許可 |
Intune のコンプライアンス概要でも、条件付きアクセスで Require device to be marked as compliant を使う場合、Microsoft Entra ID に報告されたコンプライアンス状態がアクセス許可やブロックの判断に使われると説明されています。(Microsoft Learn)
このため、サードパーティコンプライアンス連携を変更する際は、Intune 管理者だけでなく、Entra ID／条件付きアクセスを管理する ID 管理チームとも連携すべきです。
管理者が確認すべきチェックリスト
本番環境で作業する前に、次のチェックリストを使って確認してください。
| 確認項目 | 推奨アクション |
|---|---|
| 利用中の MDM 製品 | Microsoft Learn のサポート対象一覧に含まれるか確認する |
| 対象 OS | Android、iOS/iPadOS、macOS のどれを対象にするか整理する |
| パートナー側の前提条件 | 各ベンダーの連携ドキュメントを確認する |
| Entra Application ID | Custom MDM Compliance Partner 利用時は事前に取得する |
| Intune ライセンス | 対象ユーザーにライセンスが割り当てられているか確認する |
| ユーザーグループ | 対象者だけを含む専用グループを作る |
| 条件付きアクセス | いきなり全社適用せず、テストグループで検証する |
| 監視方法 | Microsoft Entra admin center の Devices > All devices で状態を確認する |
| 移行計画 | 旧 MDM の退役処理、Entra ID の MDM 列確認、Intune 登録の順で進める |
| 緊急回避策 | ブレークグラスアカウントや除外条件を事前に用意する |
特に条件付きアクセスの変更は、設定ミスがそのままサインイン障害につながります。最初は少数のテストユーザーに限定し、端末登録、準拠状態の反映、Microsoft 365 へのアクセス確認まで一連の流れを検証してから展開するのが安全です。
実務での判断基準
サードパーティコンプライアンスパートナーを使うべきか、Intune MDM に統一すべきかは、単純に「Microsoft 製品で統一したほうがよい」とは言い切れません。判断基準は、端末の種類、既存運用、管理者スキル、ベンダー依存度によって変わります。
| 判断軸 | サードパーティ連携が向いているケース | Intune MDM 統一が向いているケース |
|---|---|---|
| macOS 管理 | Jamf Pro などで成熟した運用がある | macOS 管理を Microsoft 365 管理に寄せたい |
| グローバル運用 | 拠点ごとに既存 MDM が強く根付いている | 全社共通の運用標準を作りたい |
| 条件付きアクセス | 既存 MDM の準拠判定を活かしたい | Intune のコンプライアンスポリシーで一元管理したい |
| コスト | 既存契約を維持する理由がある | MDM ライセンスを整理したい |
| 運用負荷 | 専任チームが各 MDM を管理できる | 管理画面や問い合わせ窓口を集約したい |
独自の観点として重要なのは、「どちらが高機能か」ではなく、「準拠状態の責任者を誰が持つか」です。条件付きアクセスで業務アプリを守る以上、準拠判定の誤りはセキュリティリスクにも業務停止リスクにもなります。サードパーティ側のポリシー担当者、Intune 管理者、Entra ID 管理者が分断されている場合は、運用設計を先に整えるべきです。
よくある失敗と対策
サポート対象に名前があるだけで設定を進める
パートナー一覧に製品名があることと、自社が使いたい OS・構成でサポートされることは同じではありません。必ずパートナー側のドキュメントも確認してください。
条件付きアクセスを先に強化してしまう
準拠状態が正しく Entra ID に反映される前に「準拠済みデバイスのみ許可」を広げると、正常なユーザーまでブロックされる可能性があります。先にレポート確認、次に小規模テスト、最後に本番適用の順に進めます。
割り当てグループが広すぎる
「全社員」などの大きなグループを最初から割り当てると、対象外の端末まで影響を受けます。最初は専用の検証グループを作成し、対象デバイスを持つユーザーだけを含めます。
MDM プロファイルを端末から削除して移行完了と判断する
公式ドキュメントでは、端末上でサードパーティ MDM プロファイルをローカル削除するだけでは Intune 側のクリーンアップタスクが十分に実行されないとされています。移行時は、旧 MDM 側の退役処理と Entra ID の MDM 列確認を必ず行います。(Microsoft Learn)
Omnissa Workspace ONE UEM の同期を忘れる
Workspace ONE UEM を使う場合、Intune 側の変更後に UEM コンソール側で手動同期が必要なケースがあります。割り当て変更後に新しいユーザーが準拠状態を報告しない場合は、同期状態を確認してください。
まず管理者が取るべき次のアクション
今回の更新ポイントを踏まえると、Microsoft Intune 管理者が最初に行うべきことは、新機能の有効化ではなく、現在の端末コンプライアンス連携の棚卸しです。
具体的には、次の順で確認してください。
- Microsoft Intune admin center で Tenant Administration > Connectors and Tokens > Partner Compliance management を開く
- 登録済みのコンプライアンスパートナーと対象プラットフォームを確認する
- 割り当てグループに意図しないユーザーが含まれていないか確認する
- Microsoft Entra admin center の Devices > All devices で MDM と準拠状態を確認する
- 条件付きアクセスで「準拠済みデバイス」を要求しているポリシーの対象範囲を確認する
- サードパーティ MDM から Intune MDM へ移行中の場合は、退役処理と MDM 列の確認手順を標準作業書に入れる
今回の「Third-party device compliance partners support in Microsoft Intune」は、派手な新機能というより、サードパーティ MDM と Intune、Microsoft Entra ID、条件付きアクセスをつなぐ重要な運用ドキュメントです。管理者は、サポート対象パートナー、1プラットフォーム1パートナーの制約、割り当てグループ、移行時のクリーンアップを確認し、条件付きアクセスの本番影響を抑えながら段階的に見直すことが重要です。
コメント