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

2026.06.16
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条件付きアクセスまでの4ステップ連携フロー図
Intuneが端末の準拠性を評価し、その結果を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種類に分けて考えると理解しやすいです。

インストールアプリはIntune、Webアプリは主に条件付きアクセス(Entra ID)側で制御する分担図
アプリの「種類」によって制御の担当が変わります。端末にインストールするアプリはIntuneが、Webブラウザ経由のアプリはEntra IDの条件付きアクセスが主に制御します。

詰まったのはここです。「準拠端末のみアクセスを許可する」という設定を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部へ進む

 ↓ ガイドのトップを見る

この記事は役に立ちましたか?
もし参考になりましたら、下記のボタンで教えてください。

製造業での現場経験を経てIT業界へ転身した異色のキャリアを持ちます。製造の現場で培った「工程管理」や「業務の流れを俯瞰する視点」は、IT領域においても大きな強みです。現場を知るからこそ見えてくる無駄や非効率に対して、クラウドツールやシステムを活用した実践的な改善提案が得意です。時間とコストを削減し、現場の方が本来の仕事に集中できる環境づくりを支援します。

おすすめの記事

目次