IntuneとEntra IDの違いとは? 設定の迷いをなくす「役割分担」の考え方

「このポリシー設定、Microsoft Intune(以下Intune)でやるべきかMicrosoft Entra ID(以下Entra ID)でやるべきか……」
この記事は、まさにこういう疑問を持ち始めた段階の方に向けて書いています。前回までの記事では、Intuneの管理者ロールや責任範囲・権限設計の考え方を整理しました。ただ、実際に設定作業に入ると、また別の壁にぶつかります。「そもそもIntuneとEntra IDって何が違うの?どちらで設定するの?」という根本の疑問を、今回はじっくり解説します。
この記事を読むと、以下の3つが理解できるようになります。
- IntuneとEntra IDの役割分担が整理できる
- 「どちらで設定するか」の判断基準が持てる
- よく混同される条件付きアクセスとの関係が理解できる
1. 役割分担
– 「端末・アプリ管理」vs「ID・アクセス管理」 –
IntuneとEntra IDは、Microsoftのクラウド管理基盤を構成する独立したサービスです。それぞれが管理する対象は根本的に異なります。
たとえば、社員のスマートフォンにセキュリティポリシーを適用したり、業務アプリを配布したりするのがIntuneの仕事です。一方で、「誰がどのシステムにアクセスできるか」「多要素認証を要求するか」を決めるのがEntra IDの仕事です。
2. よく混同する設定例
– 準拠性評価と条件付きアクセスの連携 –
IntuneとEntra IDの違いを理解するうえで最も混乱しやすいのが、「コンプライアンスポリシー(Intune)」と「条件付きアクセス(Entra ID)」の関係です。
コンプライアンスポリシーとは、端末が「組織のルールを満たしているか」を判定するための基準設定です。例:OSが最新か、暗号化されているか、パスコードが設定されているか。
条件付きアクセス(Conditional Access)とは、Entra IDの機能で、「どんなユーザー・デバイスにどんな条件でアクセスを許可・拒否するか」を制御するポリシーです。

「端末がIntuneのコンプライアンスポリシーを満たしているか」という情報は、Entra IDの条件付きアクセスが参照する判断材料のひとつになります。つまり、IntuneはEntra IDに「判定材料」を渡す役割を担っているのです。
3. 判断フレーム
– 「誰のアクセス」か「端末の状態」か –
実務で迷ったときに使えるシンプルな判断軸を紹介します。
| やりたいこと | 使うべきサービス |
| 端末にポリシーや設定を配布したい | Intune |
| アプリを社員の端末に展開したい | Intune |
| 端末がルールを満たしているか確認したい(コンプライアンス評価) | Intune |
| 誰がどのシステムにアクセスできるかを制御したい | Entra ID |
| MFAを要求する条件を設定したい | Entra ID |
| ユーザーアカウントを管理したい | Entra ID |
| 「準拠デバイスのみアクセス許可」のルールを作りたい | IntuneとEntra IDの連携(両方必要) |
「何をしたいのか」を起点に、それが端末・アプリ側の話なのか、人・アクセス側の話なのかを判断するのが基本的な考え方です。
4. 筆者が最初に詰まったポイント
– アプリの「種類」によって制御の担当が変わる –
「アプリの管理はIntuneでやる」と聞いていたので、最初はすべてのアプリ制御がIntune側の話だと思い込んでいました。ところが実際に設定を進めると、Webブラウザでアクセスするアプリは主に条件付きアクセス(Entra ID)側で制御する場面が多く、当時の自分にはそれがIntuneとは別の話に見えていて、頭の中がぐるぐるしてきました。
整理してみると、アプリは大きく2種類に分けて考えると理解しやすいです。

詰まったのはここです。「準拠端末のみアクセスを許可する」という設定をEntra IDの条件付きアクセスで作ったのに、期待通りに動きませんでした。原因はIntuneのコンプライアンスポリシーが未設定だったことです。条件付きアクセスは「入口のゲート」ですが、そのゲートが参照する「端末が準拠しているかどうか」の判定はIntune側が行います。Intune側の設定がなければ、ゲートは判定材料を持てないため機能しないのです。
「条件付きアクセスはEntra IDで設定する」という理解で止まってしまうと、Intune側のコンプライアンスポリシーを忘れがちです。この設定の場合は両方がそろって初めて「準拠端末のみアクセス許可」が機能します。
5. 運用の分担
– 情シス・セキュリティ・各部門の役割 –
IntuneとEntra IDにまたがる管理体制を設計するとき、「誰が何を担当するか」を事前に整理しておくことが安定運用の鍵です。前回までの記事ではIntune管理者の担当範囲に絞って整理しましたが、ここではIntuneとEntra IDをまたぐ全体像として整理します。以下は中規模組織を想定した例です。
| 業務領域 | 主な担当者 | 使うサービス |
| デバイス登録・ポリシー適用・アプリ展開 | 情シス担当 / Intune管理者 | Intune |
| ユーザーアカウント・グループ管理 | 情シス担当 / ユーザー管理者 | Entra ID |
| コンプライアンスポリシーの設計 | 情シス担当 / セキュリティ担当 | Intune |
| 条件付きアクセスポリシーの設計・管理 | セキュリティ担当 / 条件付きアクセス管理者 | Entra ID |
| ライセンス付与 | 情シス担当 / ライセンス管理者 | Entra ID(M365管理センター) |
ポイントは、IntuneとEntra IDにまたがる設計(特に条件付きアクセスとコンプライアンスの連携)は、Intune管理者とEntra ID側の担当者が協力して設計することです。一方だけで完結しません。
まとめ
IntuneとEntra IDは独立したサービスですが、条件付きアクセスなどの場面で密接に連携します。「端末・アプリの管理はIntune」「人・アクセスの管理はEntra ID」という基本的な役割分担を軸に、設定の判断をすることが混乱を防ぐ第一歩です。
↓ 第2部へ進む
↓ ガイドのトップを見る











