Japan Microsoft Intune Support Team Hexo https://jpintune.github.io/blog/ All rights reserved 2026, Japan Microsoft Intune Support Team 日本マイクロソフトの Microsoft Intune に関するサポート情報のブログです。 Japan Microsoft Intune Support Team Blog 2026-11-02T00:39:51.247Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

Intune で管理するデバイスの OS は、Windows、iOS/iPadOS、macOS、Android と、それぞれ新しいバージョンが定期的にリリースされます。そのため、「この OS バージョンは Intune でサポートされているのか」「新しい OS がリリースされたら、すぐに Intune で管理できるのか」といったご質問をいただくことがよくあります。

本記事では、Intune で管理する主要な種類のデバイス (Windows、Apple、Android) について、Intune におけるサポート ライフサイクルの一般的な考え方と、最新の情報を確認できる場所をご紹介します。なお、Intune では新しい OS バージョンについて、主要な OS は基本的にゼロデイ サポート (OS のリリース日から利用できる状態) を目指して対応を進めています。

最新の情報を確認できる場所

サポート対象の OS は定期的に更新されるため、本記事の内容だけでなく、必ず最新の公開情報をご確認ください。次のページが基本となります。

サポート対象の OS バージョン

💡 NOTE
日本語版は英語版の翻訳であるため、更新が反映されるまで時間差が生じる場合があります。最新の情報を確認したい場合は、英語版もあわせてご参照ください。

サポートの変更に関する案内

新しいバージョンのサポート開始や、古いバージョンのサポート終了・変更は、下記の公開情報にて事前に通知を行うことがあります。

加えてメッセージ センターにも、事前に通知する場合があります。メッセージ センターの通知内容については、Intune 管理センターの [テナント管理] - [テナントの状態] にある [サービス正常性とメッセージ センター] からも確認できます。

また、開発部門が公開している下記のブログにおいても、通知が行われることがあるため、こちらも併せてご確認ください。

Windows

Windows については、上記のサポート対象 OS のページに「Windows 11 Home、S、Pro、Pro Education、Education、Enterprise、IoT Enterprise エディション」や「Windows 10 LTSC 2019/2021 および Windows 11 LTSC 2024 (Enterprise および IoT Enterprise エディション)」が記載されており、基本的に Windows のサポート期間内の OS であれば Intune からも問題なく管理していただけます。

Windows 自体のサポート期間 (サービス ライフサイクル) は、次の Windows リリース情報で確認できます。

Apple (iOS / iPadOS / macOS)

Apple デバイスについては、「最新の 3 つのメジャー バージョン」を目安にサポートされます。毎年秋ごろに新しいバージョンが Apple よりリリースされると、サポート対象の範囲も 1 つ新しいバージョンへ移動していく形になります。

なお、上記の公開情報では、「サポートされるバージョン」と「登録が許可されるバージョン」が次のように区別されています。

区分内容
サポートされるバージョン最新の 3 つの OS バージョンを実行しているデバイスです。適用可能なすべての Intune の機能を登録して利用でき、新しい機能もこれらのデバイスで動作します。
登録が許可されるバージョンサポートされるバージョンより古い OS バージョンのデバイスです。登録して Intune の機能を利用することはできますが、期待どおりに動作する保証はありません。

💡 NOTE
「登録が許可されるバージョン」は、ユーザー アフィニティのないデバイス (ADE や Apple Configurator で登録するデバイス) に対して案内されています。登録の種類ごとの具体的な対象バージョンについては、必ず上記の公開情報をご確認ください。

Android

Android では、機種ごとに利用可能なバージョンの範囲も大きく異なることから、現在は Windows や Apple のように「最新の○バージョン」といった厳密なサポート ライフサイクルが定められているわけではありません。代わりに、必要に応じて、サポート対象とする最小の Android バージョンが引き上げられていきます。

また、Android は登録方法 (ユーザー ベース / ユーザーレス等) によってサポートされるバージョンが異なります。具体的なバージョンは、上記の公開情報の「Android」の項目で登録方法ごとに案内されていますので、ご利用の登録方法に該当する部分をご確認ください。

ユーザー ベースの管理方法で Android 10 以降が対象になった際の変更は、公開情報上の通知だけではなく、次の Tech Community ブログやメッセージ センターでも事前に案内されました。

今後も同様に、Android の新しいバージョンのリリース等に伴って、サポート対象の最小バージョンが引き上げられる場合があります。Android を運用されている場合は、上記の Intune Customer Success ブログやメッセージ センターで、事前の案内を確認していただくことをお勧めします。

注意点

ここまでご紹介したのは、あくまでも Intune 観点でのサポート ポリシー です。

実環境でデバイスを運用する際には、Intune だけでなく、デバイス上で利用する様々なアプリ等の要件も踏まえて、適切な OS バージョンで運用していただく必要があります。たとえば Office 関連のアプリでは、Intune とは別に次のようなシステム要件が定められており、ブログの執筆時点では iOS や Android については Intune の要件よりも厳しい条件が設けられています。

OSMicrosoft 365 アプリのシステム要件 (概要)
WindowsWindows 11、Windows Server 2025、または Windows Server 2022
macOS最新の 3 つのバージョンのうちの 1 つ
Android直近 4 つのメジャー バージョン
iOS最新バージョン 2 つ

実際にお問い合わせの中でも、調査を進めたところ、問題が発生していた iOS のバージョンは Intune 観点では問題ないものの、Office アプリの観点からはサポートされないバージョンであったといったケースも、よくあります。

OS のバージョンを選定したり、アップグレードの計画を立てたりする際には、Intune のサポート対象に加えて、利用するアプリの要件も確認したうえで進めていただければと思います。

まとめ

  • Intune のサポート対象 OS は、公開情報 (「Intune でサポートされるオペレーティング システムとブラウザー」) で確認できます。
  • Windows は OS 自体のサポート期間、Apple は最新の 3 つのバージョンが目安となり、Android は登録方法ごとにサポート対象の最小バージョンが定められ、必要に応じて引き上げられていきます。
  • 変更の案内は、メッセージ センターや Intune Customer Success ブログで事前に確認できます。
  • Intune のサポートに加えて、デバイス上で利用するアプリ (Microsoft 365 アプリ等) の要件も確認してください。

本記事が、デバイスの OS バージョンを検討する際の参考になりましたら幸いです。

]]> https://jpintune.github.io/blog/intune/20261102_01/ 2026-11-01T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

Intune で管理するデバイスの OS は、Windows、iOS/iPadOS、macOS、Android と、それぞれ新しいバージョンが定期的にリリースされます。そのため、「この OS]]>

Intune のサポート対象 OS とライフサイクルの考え方 (Windows / Apple / Android) 2026-11-02T00:39:51.247Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

Android デバイスの管理を始める際に、最初に迷われるポイントが「登録方法の選択」です。Android には登録方法が複数あり、さらに Google 社独自の用語 (仕事用プロファイル、フル マネージド 等々) も登場するため、「自社の運用にはどの方法が合うのか」が分かりにくいという声をよくいただきます。

本記事では、Intune で利用できる Android の登録方法を、個人所有 (BYOD) のデバイス と 企業所有のデバイス に分けて整理し、それぞれどのようなケースで利用する方法なのかをご紹介します。あわせて、企業所有のデバイスで、iOS の ADE や Windows の Autopilot のようにキッティングを効率化する方法についてもご紹介します。

なお、Android 固有の仕様については、下記の記事でも紹介していますので、あわせて参考にしてみてください。

登録方法の全体像

Intune で Android デバイスを管理する登録方法は、大きく下表のとおりです。

所有形態登録方法略称主な用途
個人所有Android Enterprise 個人所有の仕事用プロファイルBYOD個人所有のスマートフォンで会社のメールやアプリを利用する
企業所有Android Enterprise フル マネージドCOBO社給のスマートフォンを 1 人 1 台で業務専用として利用する
企業所有Android Enterprise 会社所有の仕事用プロファイルCOPE社給のスマートフォンで業務と個人利用の領域を分けて利用する
企業所有Android Enterprise 専用デバイスCOSUキオスク端末など、特定の用途に特化した端末として利用する
企業所有Android Open Source Project (AOSP)-Android Enterprise に対応していない特殊なデバイス (AR/VR デバイス等) を管理する
個人所有 / 企業所有Android デバイス管理者 (非推奨)DAGoogle モバイル サービス (GMS) が利用できないデバイス等

まずは、「個人所有か、企業所有か」 で絞り込み、次に「そのデバイスをどのような使い方で運用したいか」で選んでいただくと整理しやすくなります。

個人所有のデバイスの登録 (BYOD)

Android Enterprise 個人所有の仕事用プロファイル

基本的に BYOD の Android を Intune に登録する場合には、この登録方法を利用していただくことになります。デバイス上に会社用の領域 (仕事用プロファイル) が作成され、会社のデータやアプリは仕事用プロファイルの中で管理されます。個人用の領域は Intune から管理されないため、ユーザーのプライバシーが保たれます。

Android Enterprise 個人所有の仕事用プロファイル (BYOD)

なお、個人所有の仕事用プロファイルは、Intune が Google 社の Android Management API を利用する方式への移行を進めており、新しいデバイスでは Web ベースの登録フローが利用されるようになります。詳細については、下記の公開情報もあわせてご確認ください。

特定のデバイスのみの登録を許可できる？

運用によっては、BYOD のデバイスであっても、事前に社内で申請を行ったデバイスのみ登録を許可したいというご要望もあると思います。

Android 11 以前では、iOS 等と同様に、下記の公開情報の方法で企業向けデバイスの識別子としてシリアル番号や IMEI を事前に Intune に登録しておくことで、BYOD のデバイスであっても企業所有のデバイスとして認識させることができていました。しかし、Android 12 以降のバージョンでは、Google 社のセキュリティの強化に伴い、この方法は利用できなくなっています。

Android 12 以降のバージョンでも、事前にユーザーから申請があったデバイスのみを利用させたい場合は、登録自体をブロックすることはできません。そのため、次のように「登録はできるが、社内リソースにはアクセスさせない」という構成を取ることをご検討ください。

  1. ユーザーから申請があったデバイスのみ、手動でグループに追加し、そのグループにコンプライアンス ポリシーを割り当てる (デバイスは登録後にグループへ追加するため、追加されるまでは一時的に非準拠となります)
  2. コンプライアンス ポリシーが割り当てられていないデバイスは「非準拠」として扱われるよう、テナント全体の設定 (コンプライアンス ポリシーが割り当てられていないデバイスをマークする) を 非準拠 に構成する
  3. 条件付きアクセスで「準拠しているデバイス」を要求する

この構成により、申請なしで登録されたデバイスは非準拠となり、条件付きアクセスによってブロックされるため、社内のリソースにはアクセスできなくなります。

非推奨 : Android デバイス管理者登録

この方法は古い登録方法であり、現在は基本的に利用しない非推奨の登録方法です。Google モバイル サービス (GMS) が利用できるデバイスでは、既にサポートされていない登録方法となっています。 ただし、GMS が利用できない国や、GMS に対応していないデバイスでは、引き続きこの方法を利用して Intune から管理することが可能です。

日本国内でご利用いただく場合には、特に問題になることはありませんが、グローバルにデバイスを展開する場合には、一部の国で Android Enterprise や GMS の利用が制限されている可能性があります。Android Enterprise を利用できる国については、下記の Google 社の公開情報で紹介されていますので、参考にしてみてください。

また、一般的に販売されている Android であれば、通常は Android Enterprise や GMS に対応していますが、Android をベースに独自のカスタマイズが行われている OS を搭載した機種では、Android Enterprise や GMS が利用できない可能性があります。対応状況の確認が必要な場合は、端末の開発元に確認するのが確実です。

企業所有のデバイスの登録

企業所有のデバイスを登録する方法は、デバイスの使い方によって下記から選択します。いずれの方法も、デバイスの初期状態 (工場出荷時の状態) から登録を開始する必要があります。 すでに利用中のデバイスを登録する場合は、工場出荷時の状態にリセットする必要がある点にご注意ください。

Android Enterprise フル マネージド (COBO)

一般的に Android の社給デバイスを各ユーザーに配って、スマートフォンとして利用させたい場合は、この登録方法がイメージに近いと思います。デバイス全体が会社の管理下に置かれ、1 人のユーザーが業務専用で利用する形となります。個人用の領域は存在しないため、Intune でデバイス全体を管理できます。

フル マネージド デバイス (COBO)

Android Enterprise の会社所有の仕事用プロファイル (COPE)

この登録方法は、あまり利用されることが多くない方法ですが、企業所有の端末として管理しつつ、端末上で個人利用のための領域も確保するような方法となります。ユーザーの利用イメージ自体は、前述の「Android Enterprise 個人所有の仕事用プロファイル」に近い形となります。

仕事用プロファイルがある会社所有デバイス (COPE)

Android Enterprise 専用デバイス (COSU)

この登録方法は、キオスク端末等、特定の用途や業務に特化した端末を管理する場合に利用します。特定のユーザーには紐づかず、在庫管理、バーコードのスキャン、チケットの印刷など、共有で利用するデバイスに適しています。

専用デバイス (COSU)

Android Open Source Project (AOSP)

AOSP は、Android Enterprise に対応していない特殊なデバイス (AR/VR デバイス等) を管理する場合に利用する登録方法です。具体的に登録可能なデバイスの一覧については、下記で紹介していますので、参考としてください。

Android Open Source Project (AOSP)

どの登録方法を選べばよい？

企業所有のデバイスについては、下記を目安にご検討ください。

デバイスの使い方一般的な登録方法
1 人 1 台、業務専用で利用するフル マネージド (COBO)
1 人 1 台、業務と個人利用を 1 台で両立させる会社所有の仕事用プロファイル (COPE)
ユーザーに紐づかない共有端末、キオスク端末専用デバイス (COSU)
AR/VR デバイスなど、Android Enterprise 非対応のデバイスAOSP

なお、BYOD のデバイスを企業所有の登録方法で登録することや、企業所有のデバイスを BYOD の登録方法で登録することは一般的ではありません。デバイスの所有形態に合った登録方法を選択してください。

キッティング方法

すでに iOS (ADE) や Windows (Autopilot) を管理しているお客様の中には、Android でも同じように、デバイスを開封して電源を入れるだけで自動的に Intune へ登録される仕組みや、管理者の手間を減らす仕組みを利用したいというご要望があるかと思います。

Android の企業所有のデバイスには、下記のようなキッティング方法が用意されています。

ゼロタッチ

Google 社のゼロタッチ登録を利用すると、デバイスを初めて起動したときに、自動的に Intune への登録が開始されるようになります。iOS の ADE や Windows の Autopilot に近い仕組みとなります。次の登録方法で利用できます。

  • Android Enterprise フル マネージド (COBO)
  • Android Enterprise の会社所有の仕事用プロファイル (COPE)
  • Android Enterprise 専用デバイス (COSU)

ゼロタッチ登録を利用するには、ゼロタッチ登録に対応したデバイスを、Google 社が認定したゼロタッチの販売店から購入する必要があります。そのため、すでに購入済みのデバイスや、販売店以外から購入したデバイスでは利用できません。購入先や必要な準備については、下記の公開情報を参考にしてください。

Samsung 製のデバイスであれば、Samsung 社の Knox Mobile Enrollment (KME) を利用して、同様にデバイスの登録を自動化することも可能です。

QR コード / トークンによる登録

ゼロタッチ登録が利用できないデバイスでは、デバイスを工場出荷時の状態にしたうえで、初期セットアップ画面で QR コードをスキャンする、またはトークンを入力することで、Intune に登録できます。管理者が事前にデバイスの登録を行ってからユーザーに配布することも、ユーザーが自分で登録することも可能です。

なお、Android 11 以降の Android Enterprise の会社所有の仕事用プロファイル (COPE) では、トークンの手動入力による登録はサポートされていません。この場合は、QR コードのスキャンで登録してください。

デバイスのステージング

ゼロタッチを利用できない環境でも、管理者や委託先のベンダーが事前にデバイスの準備を行い、ユーザーが行う操作を最小限に抑えたいという場合には、デバイスのステージングを利用できます。ステージング用のトークンを使うことで、次のような流れで登録を行います。

  1. 管理者が、Intune 管理センターでステージング用のトークンを含む登録プロファイルを作成する
  2. 管理者またはベンダーが、デバイスでトークンの QR コードをスキャン (またはトークンを入力。ただし、Android 11 以降の COPE ではトークンの手動入力は不可) し、セットアップ ウィザードを完了させる。この時点では、デバイスはユーザーに紐づいていない
  3. デバイスの電源を切り、ユーザーに配布する
  4. ユーザーは、デバイスの電源を入れて Microsoft Intune アプリに職場または学校アカウントでサインインするだけで、登録が完了する

デバイスのステージングは、次の登録方法で利用できます。

  • Android Enterprise フル マネージド (COBO)
  • Android Enterprise の会社所有の仕事用プロファイル (COPE)

専用デバイス (COSU) では利用できませんので、ご注意ください。

キッティング方法の比較

キッティング方法COBOCOPECOSU特徴
ゼロタッチ○○○対応デバイスを認定販売店から購入する必要がある。電源を入れるだけで登録が開始される
デバイスのステージング○○-管理者やベンダーが事前に準備し、ユーザーはサインインするだけで登録できる
QR コード / トークン○○○特別な購入手続きが不要。初期セットアップ時に QR コードのスキャンやトークンの入力が必要 (Android 11 以降の COPE ではトークンの手動入力は不可)

まとめ

  • Android の登録方法は、まず 「個人所有か、企業所有か」 で絞り込み、次に利用イメージで選択する
  • BYOD は Android Enterprise 個人所有の仕事用プロファイル を利用する。Android 12 以降は、企業向けデバイスの識別子を使って登録を制限することはできない
  • Android デバイス管理者は非推奨であり、GMS が利用できるデバイスではサポートされていない
  • 企業所有は、利用形態に合わせて COBO / COPE / COSU / AOSP から選択する
  • キッティングを効率化したい場合は、ゼロタッチ や デバイスのステージング の利用を検討する。ゼロタッチは認定販売店からの購入が必要となるため、デバイスの調達方法とあわせて検討する

登録方法を決めた後の運用で押さえておきたい Android 固有の仕様については、下記の記事もあわせてご確認ください。

本記事が、Android デバイスの管理を始める際の参考となれば幸いです。

]]> https://jpintune.github.io/blog/intune/20261023_01/ 2026-10-22T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

Android デバイスの管理を始める際に、最初に迷われるポイントが「登録方法の選択」です。Android には登録方法が複数あり、さらに Google 社独自の用語 (仕事用プロファイル、フル マネ]]>

Intune で Android デバイスを管理する時の登録方法の選び方 2026-11-02T00:39:51.240Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

Intune は近年、大規模なお客様にもご利用いただく機会が増えてきました。複数の関連会社や複数の拠点の管理者が、1 つの Intune テナントを共同で管理するような環境も、めずらしくありません。

このような環境でよくいただくのが、「管理者が、別の拠点のデバイスまで操作出来てしまうのが心配」「関連会社の管理者には、自社のポリシーだけを見せたい」「他の管理者が勝手に設定変更を行えないようにしたい」といったご相談です。

大規模な環境でどのように権限を振り分けるのが正解か、というのは組織の体制や運用方針によっても変わってくるため、一概に答えがあるわけではありません。ただ、Intune にはこうした「権限の分け方」を支える機能がいくつか用意されており、それぞれの役割を押さえておくと、ご自身の環境に合った設計を考えやすくなります。

そこで今回は、大規模な環境で管理者の権限を適切に管理するための次の 4 つの機能を、順番にご紹介します。

  1. Intune の組み込みのロールとカスタム ロール
  2. スコープ タグ
  3. スコープ グループ
  4. 複数の管理者による承認 (Multi Admin Approval)

なお、大規模な環境で Intune を運用する際の考え方については、下記の公開情報にもまとまっていますので、あわせてご覧ください。

1. Intune の組み込みのロールとカスタム ロール

まず最初に考えたいのが、「管理者に何をさせるか (= どの操作を許可するか)」を決めるロールです。

Intune の管理者というと、Microsoft Entra ID の「Intune 管理者」や「グローバル管理者」といったロールを割り当てているケースも多いかと思います。ただ、これらの Entra ID のロールは Intune 全体に対するフル アクセスを持つ非常に強い権限で、スコープ タグによる制限も受けません。日常的な運用を行う管理者 1 人 1 人に割り当てるには、少し強すぎる場合があります。

「ヘルプデスクの担当者にはデバイスの確認と同期だけ」「ポリシー担当者にはプロファイルの作成と割り当てまで」といったように、必要な操作だけを許可したい場合は、Intune 側に用意されている RBAC (ロールベースのアクセス制御) のロールを利用しましょう。

Intune には、次の公開情報で紹介しているような組み込みのロールがあらかじめ用意されています。

組み込みのロールでは「ちょっと権限が多い」「この操作だけ追加したい」というときは、カスタム ロールを作成して、リソースごとに「読み取り / 作成 / 更新 / 削除 / 割り当て」といったアクセス許可を細かく選ぶことができます。

今のアカウントにどんな権限が割り当たっているかを確認する

ロールを設計していると、「このアカウントには、結局どの権限が割り当たっているんだっけ？」と確認したくなる場面がよくあります。

現在サインインしているアカウントに割り当てられているアクセス許可は、Intune 管理センターの下記の画面から一覧で確認できます。

  • [テナント管理] - [ロール] - [アクセス許可]

Intune の役割 - アクセス許可 の画面

また、下記の画面から他の管理者に割り振られているアクセス許可も確認することが出来ます。

  • [テナント管理] - [ロール] - [管理者のアクセス許可]

これらの画面では、リソース (DeviceConfigurations など) ごとに、どのアクセス許可 (Read / Create / Assign など) が付与されているかが表示されます。権限の変更後、実際に反映されるまでには時間が掛かることもあります。権限を変更して検証を行っているときにも、変更した権限が実際にユーザーに割り当たっているかをすぐに確認できるので、ぜひ活用してください。

管理者に Intune のライセンスは必要？

ライセンス未付与の管理者のアクセスが有効になっていれば、Intune の管理者は、Intune ライセンスが割り当てられていなくても、Intune 管理センターにサインインして管理を行うことができます。2021 年 7 月以降に作成されたテナントでは既定で有効になっており、2021 年 7 月より前に作成されたテナントは [テナント管理] - [ロール] - [設定] から手動で有効にする必要があります。ロールを割り当てたにも関わらず、思った通り動かないなと思ったら、まずはこの点を確認してみてください。

また、デメリットがあるような機能ではありませんが、一度有効にすると元に戻せないため、念のため、ご注意ください。

2. スコープ タグ

ロールが「何をさせるか」を決めるのに対して、スコープ タグは「どのオブジェクトを見せるか」を決める仕組みです。

たとえば、東京と大阪の拠点にそれぞれ管理者がいて、「大阪の管理者には大阪向けのポリシーやデバイスだけを見せたい」という場合、次のように設定します。

  1. 「大阪」というスコープ タグを作成する
  2. 大阪向けの構成プロファイルやアプリ、デバイスに「大阪」のスコープ タグを付ける
  3. 大阪の管理者グループに対するロールの割り当てで、スコープ タグに「大阪」を指定する

こうしておくと、大阪の管理者は「大阪」タグが付いたオブジェクトだけを表示・操作できるようになり、東京向けのポリシーは一覧にも表示されなくなります。

スコープ タグを利用するうえで、押さえておきたいポイントをいくつか挙げておきます。

  • スコープ タグが付いていないオブジェクトには、自動的に「既定 (Default)」のスコープ タグが付与されます
  • ロールの割り当てにスコープ タグを 1 つも指定していない管理者は、実質的にすべてのスコープ タグを持っているのと同じ扱いになり、ロールのアクセス許可の範囲ですべてのオブジェクトを表示できます
  • 管理者が新しくオブジェクトを作成すると、その管理者に割り当てられているスコープ タグが自動的に付与されます
  • Intune の RBAC とスコープ タグは、Entra ID のロール (Intune 管理者など) には適用されません

別々のロールから、それぞれ異なるスコープ タグを割り当てたときの動作

スコープ タグを使い始めると、「本社向けには読み取り専用、地域拠点向けにはフル アクセス」といったように、同じ管理者グループに対して、異なるスコープ タグを持つ複数のロールを割り当てたくなることがあります。

ただ、複数のロールの割り当てを組み合わせると、どうしても管理が複雑になりがちです。上記のような例の場合、読み取り専用の管理者アカウントを別に作ってしまうのも一つの手法です。また、ロールの割り当ては運用中も都度更新を行っていくことが想定されるため、可能な限り、ロールの割り当てはシンプルに保つのがおすすめですが、どうしても必要な場合は、次の動作を知っておいてください。

既定の動作 (アクセス許可のマージ)

既定では、同じアクセス許可カテゴリ (例: モバイル アプリ) を含む複数のロールの割り当てが 1 つの管理者グループにある場合、Intune はそれらのアクセス許可をマージして評価します。

たとえば、「アプリ管理者」グループに対して、

  • スコープ タグ「東京」で、モバイル アプリの「読み取り」のみを許可するロール
  • スコープ タグ「大阪」で、モバイル アプリの「作成 / 読み取り / 更新 / 削除」を許可するロール

の 2 つを割り当てた場合、アクセス許可がマージされる結果、「東京」のアプリに対してもフル アクセスが可能になってしまいます。「本社は読み取り専用にしたかったのに…」という、意図しない権限の広がりが起きてしまうのです。

スコープ付きアクセス許可 (オプトインのパブリック プレビュー)

この動作を変更するものとして、2026 年 3 月に「スコープ付きアクセス許可」がオプトインのパブリック プレビューとして導入されました。この設定を有効にすると、各ロールの割り当てのアクセス許可は、そのスコープ タグの範囲内でのみ適用されるようになります。先ほどの例でいえば、「東京」は読み取り専用、「大阪」はフル アクセス、といった動作になります。

設定は [テナント管理] - [ロール] - [設定] にあり、同じ画面から「アクセス許可評価レポート」を生成して、有効化した場合に各管理者グループの権限がどのように変わるかを事前に確認できます。

ただし、この変更は一度有効にすると元に戻すことができません。 また、現時点ではプレビューではあるため、機能が完全ではない可能性があります。 ご利用いただく場合には、必ずアクセス許可評価レポートで影響を確認し、プレビューの機能であることを考慮した上で有効化してください。

3. スコープ グループ

さて、ロールの割り当てを作成していると、「管理者グループ」の次に「スコープ グループ」という画面が出てきます。このスコープ グループという概念は、最初は非常にわかりづらい概念です。

ロールの割り当ての追加 - スコープ グループ の画面

ポイントは、ロールの割り当てには「2 種類のグループ」が登場するという点です。

画面役割例
管理者グループ誰が 管理するか (管理者が所属するグループ)「大阪 IT 管理者」グループ
スコープ グループどのグループを 管理できるか (管理対象のユーザー / デバイスが所属するグループ)「大阪のユーザー」「大阪のデバイス」グループ

スコープ グループに指定したグループだけが、その管理者にとっての「管理対象」になります。具体的には、管理者がポリシーやアプリを割り当てられるグループが、スコープ グループに指定したグループに限られます。すでに別のグループに割り当て済みのポリシーやアプリを更新・削除する場合も、その割り当て先がスコープ グループに含まれている必要があります。また、リモート アクション (同期やワイプなど) を実行したりできるのは、デバイス自身、またはそのデバイスのユーザーがスコープ グループに含まれている場合に限られます。

スコープ タグとの違いを整理すると、次のようになります。

  • スコープ タグ: 管理者が どのオブジェクト (ポリシー、アプリ、デバイスなど) を表示・操作できるか を決める
  • スコープ グループ: 管理者が どのグループに対してポリシーやアプリを割り当てたり操作したりできるか を決める

ちょっとイメージしづらいと思いますので、実際にスコープ グループで制御を行った時の例を紹介していきます。

スコープ グループでの制御の一例

例えば、大阪拠点の管理者がポリシーの割り当てを行うシナリオを想定してください。

この場合、スコープ タグで制御を行えば、「大阪」というスコープ タグがついたポリシーだけを、大阪拠点の管理者に見せることが出来ます。このため、スコープ タグを使えば、間違えて東京拠点向けのポリシーを大阪拠点の管理者が変更してしまうといった操作は防ぐことが可能です。

しかし、スコープ タグのみで制御している場合には、大阪拠点の管理者は、大阪拠点向けのポリシーは自由に変更出来てしまうため、誤って 大阪拠点向けポリシーを東京のデバイス グループへ割り当ててしまう といった操作は出来てしまいます。

こういった操作を防ぐために存在するのが、スコープ グループでの制御になります。具体的には、スコープ グループで指定していないグループを割り当てようとした時は、下記のようなエラーが発生します。逆にロールの設定を正しくしたつもりにも関わらず、下記のエラーが出てしまう場合には、スコープ グループの設定を疑ってみてください。

スコープ グループで指定してないグループを割り当てようとした時のエラーの例

スコープ グループで制限する必要がない場合

「スコープ タグだけで十分で、スコープ グループによる制限は使わない」という運用の場合もあるかと思います。その場合は、スコープ グループとして 「すべてのユーザー」と「すべてのデバイス」の両方 を必ず指定しておいてください。

こうしておくと、すべてのグループに対する割り当てや操作が許可されるため、スコープ グループの設定の影響を受けずに運用できます。

4. 複数の管理者による承認 (Multi Admin Approval)

最後にご紹介するのは、少し観点の異なる機能です。ここまでの 3 つは「管理者の権限をどう分けるか」の話でしたが、複数管理者承認 (MAA) は「権限を持つ管理者が操作をするときに、もう 1 人の承認を必須にする」仕組みです。

管理者アカウントが万が一侵害された場合、攻撃者がそのアカウントでスクリプトやアプリを全デバイスに配布してしまう…というのは、大規模な環境ほど影響が大きいリスクです。また、大きな環境ほど小さな一つの設定ミスが、大きな問題へつながってしまいます。MAA を使うと、「アクセス ポリシー」で保護対象のリソースと承認者グループを指定し、保護対象への変更は別の管理者が明示的に承認するまで適用されないようにできます。

保護できるリソースの種類には、次のようなものがあります。

  • アプリ
  • コンプライアンス ポリシー
  • 構成ポリシー
  • デバイス アクション (ワイプ、削除、廃止)
  • ロール
  • スクリプト
  • テナント構成

利用にあたっての主なポイントは次のとおりです。

  • テナントに少なくとも 2 つの管理者アカウントが必要です (自分の要求を自分で承認することはできません)
  • 承認者グループは セキュリティ グループ である必要があり、かつメンバー グループとして Intune の RBAC ロールの割り当てに直接追加されている必要があります
  • 承認者には、承認対象のリソースに対する読み取りアクセス許可が必要です
  • 要求は 3 日以内に処理されないと期限切れになります。また、新しい要求が作成されても Intune から通知は送られないため、承認者への連絡は運用でカバーする必要があります
  • 「ロール」の種類のアクセス ポリシーを有効にすると、MAA 自体に必要な RBAC の割り当てを変更する際にも承認が必要になります。設定の順番によってはデッドロックが起こりうるため、ロールのアクセス ポリシーは他の設定が整った最後に有効化することをおすすめします

おわりに

今回は、大規模な Intune 環境で管理者の権限を適切に管理するための 4 つの機能をご紹介しました。

  • ロール: 管理者に「何をさせるか」を決める。Entra ID のロールが強すぎる場合は Intune の組み込みロール / カスタム ロールを利用する
  • スコープ タグ: 管理者に「どのオブジェクトを見せるか」を決める。複数ロールの組み合わせはアクセス許可がマージされる点に注意
  • スコープ グループ: 管理者が「どのグループを」管理できるかを決める。使わない場合は「すべてのユーザー」と「すべてのデバイス」を指定する
  • 複数管理者承認: 重要な変更に 2 人目の管理者の承認を必須にして、アカウント侵害時や設定ミスの際の被害を抑える

権限設計はいったん作り込むと後から変えるのが大変なので、はじめはシンプルな構成から始めて、必要に応じてスコープ タグやスコープ グループを足していくのがおすすめです。設計に迷った際は、[テナント管理] - [ロール] - [アクセス許可] の画面で、実際に割り当たっている権限を確認しながら進めてみてください。

この記事が、みなさまの Intune 環境の権限設計のお役に立てばうれしいです。それでは、また次回の記事でお会いしましょう！

]]> https://jpintune.github.io/blog/intune/20261006_01/ 2026-10-05T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

Intune は近年、大規模なお客様にもご利用いただく機会が増えてきました。複数の関連会社や複数の拠点の管理者が、1 つの Intune テナントを共同で管理するような環境も、めずらしくありません。<]]>

大規模な Intune 環境で管理者の権限を適切に分ける。ロール・スコープ タグ・スコープ グループ・複数管理者承認の使いどころ 2026-11-02T00:39:51.239Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

オンプレミスの Active Directory で長く運用してきた Windows デバイスを、Intune でも管理していきたい。そんなときに多くのお客様が選ばれるのが、Hybrid Entra Join (Microsoft Entra ハイブリッド参加) と グループ ポリシーによる自動登録 の組み合わせです。既存のドメイン参加の仕組みを活かしたまま、ポリシーを 1 つ配布するだけで Intune への登録が進んでいく。とても便利な仕組みです。

一方で、いざ展開してみると「グループ ポリシーは配ったはずなのに、いつまで経っても Intune にデバイスが出てこない…」という状況に遭遇することがあります。しかもエラー ダイアログが出るわけでもなく、ただ静かに何も起きない。これが、この構成のトラブルシューティングを少し難しくしているところです。

実はこの事象、どこを見ればよいかを押さえておけば、多くのケースでご自身で原因までたどり着ける ものです。今回はその「見るべき場所」と「確認する順番」を整理してご紹介します。

なお、内容が多岐にわたるため、本記事は前編・後編の 2 回に分けてお届けします。

  • 前編 (本記事) … 登録が動く仕組みと、確認すべき 3 つのステップ
  • 後編 … ステップ ③ で得られた エラー コード別のトラブルシューティング

後編は下記からご覧いただけます。

まずは全体像 ― 「2 つの条件」がそろって登録が動く

トラブルシューティングに入る前に、この構成でデバイスが Intune に登録されるまでの流れを押さえておきましょう。ポイントは、登録処理が動くには 2 つの条件がそろう必要がある ということです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
flowchart LR
    STEP1["① Hybrid Entra Join の完了<br/>ドメイン参加 + Entra ID への参加<br/>＋ PRT の取得"]
    STEP2["② グループ ポリシー適用<br/>自動登録のポリシーが<br/>デバイスに届く"]
    STEP3["③ 登録タスクの実行<br/>EnterpriseMgmt 配下の<br/>タスクが 5 分おきに登録を試行"]
    GOAL["🎉 Intune への登録完了"]

    STEP1 --> STEP3
    STEP2 --> STEP3
    STEP3 --> GOAL

    style STEP1 fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style STEP2 fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style STEP3 fill:#fff4e6,stroke:#d83b01,stroke-width:2px
    style GOAL fill:#eaf7ea,stroke:#107c10,stroke-width:2px

ちなみに ① と ② に順番の決まりはありません。「先に Hybrid Entra Join を済ませてからポリシーを配る」でも、「先にポリシーを配っておいて、あとからドメイン参加させる」でも構いません。

というのも、② のポリシーが適用された時点で登録タスクが作成され、そのタスクが 5 分おきに登録を試行し続ける ためです。仮に ② が先でも、タスクはリトライを続けながら ① の完了を待ち、条件がそろったところで登録が成功します。

裏を返すと、「どちらか一方でも欠けていると、③ は成功しない」 ということでもあります。ですので、うまくいかないときは「処理がどこまで進んだか」ではなく 「① と ②、欠けているのはどちらか」 を探しにいくのが、この構成の切り分けのコツです。

ありがちなのが、「Intune に登録されない」という症状から、いきなり Intune 管理センターの設定を疑って調べ始めてしまうケースです。しかし実際には、① や ② が欠けたままになっていることが少なくありません。

なお、確認する順番としては ① からをおすすめします。 ① が欠けている場合、それは Intune ではなく Microsoft Entra ID 観点から確認を進める必要がある事象であり、先に見極めておくと調査の方向性そのものが変わってくるためです。

本記事は、この ① ② ③ をそのままステップ ①〜③ として順に確認していき、最後にステップ ③ の結果に応じた掘り下げ (症状別のトラブルシューティング) を行う という構成でご紹介します。

それでは、順番に見ていきましょう。

ステップ ①：Hybrid Entra Join と MDM 構成の状態を確認する

最初に確認したいのがここです。自動登録は Hybrid Entra Join が完了していることを前提に動作するため、ここが満たされていなければ、ほかをいくら整えても登録は成功しません。しかも、この 1 つのコマンドだけで 「テナントの MDM 構成がデバイスに届いているか」まで一緒に確認できます。

ここで確認する内容は、いずれも Microsoft Entra ID の観点から調査が必要な領域 です。裏を返すと、このステップでつまずいている場合は Intune 管理センターを調べても原因は見つかりません。最初に確認する価値が高いのは、そのためです。

確認には dsregcmd /status コマンドを使用します。

1
dsregcmd /status

⚠️ 実行するコンテキストにご注意ください

ここで 1 つ、とても重要な注意点があります。

dsregcmd /status の出力のうち、SSO State セクション (PRT の情報) は「コマンドを実行したユーザー」の状態を示します。そのため、トラブルシューティングの癖で「管理者として実行」でコマンド プロンプトを開いてしまうと、実際にサインインして業務をしているユーザーではなく、その管理者アカウントの状態が表示されてしまいます。

必ず、事象が発生しているユーザーでサインインした状態で、通常のコマンド プロンプト (管理者昇格なし) から実行してください。 ここを取り違えると誤った判断をしてしまい、切り分けが振り出しに戻ってしまいます。

見るべきは 4 つのフィールド

出力は情報量が多いのですが、まず確認いただきたいのは次の 4 つです。いずれも同じ dsregcmd /status の出力内にあります。

セクションフィールド期待値意味
Device StateDomainJoinedYESオンプレミス AD にドメイン参加できている
Device StateAzureAdJoinedYESMicrosoft Entra ID にも参加できている
SSO StateAzureAdPrtYESサインイン中のユーザーが PRT を取得できている
Tenant DetailsMdmUrlURL が入っているテナントの MDM 構成がこのデバイスまで届いている

順に見ていきましょう。

DomainJoined / AzureAdJoined ― そもそも参加できているか

DomainJoined と AzureAdJoined が 両方とも YES になっていて、はじめて「Hybrid Entra Join が完了している」と言えます。どちらか一方でも NO であれば、この時点で自動登録の条件は満たされていません。

AzureAdPrt ― 意外と見落とされやすい落とし穴

PRT (Primary Refresh Token) は、ユーザーがそのデバイス上で Microsoft Entra ID に対して認証済みであることを示すトークンです。自動登録はこの PRT を使ってサイレントに (ユーザーに何も聞かずに) 処理を進める ため、AzureAdPrt: NO の状態では登録は成功しません。

「参加は済んでいるのに登録されない」というケースでは、ここが NO になっていることがよくあります。

💡 DomainJoined / AzureAdJoined / AzureAdPrt に問題があった場合
これらは Intune ではなく Microsoft Entra ID 側で対処すべき事象 です。デバイス側で Hybrid Entra Join をやり直すことで解決するケースも多く、その具体的な手順は Azure & Identity サポート チームのブログで公開されています。

なお、この手順は Microsoft Entra ID でデバイスを認証する構成 (Sync Join / マネージド) が対象です。AD FS のクレーム ルールを使用したフェデレーション構成では利用できません。

MdmUrl ― テナントの設定がデバイスに届いているか

3 つめまでとは少し性質が異なるのがこの MdmUrl です。出力の Tenant Details セクションに含まれています。

1
2
3
4
5
6
7
8
9
10
11
+----------------------------------------------------------------------+
| Tenant Details                                                       |
+----------------------------------------------------------------------+

                TenantName : Contoso
                  TenantId : aaaabbbb-0000-cccc-1111-dddd2222eeee
               AuthCodeUrl : https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/oauth2/authorize
            AccessTokenUrl : https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/oauth2/token
                    MdmUrl : https://enrollment.manage.microsoft.com/EnrollmentServer/Discovery.svc
                 MdmTouUrl : https://portal.manage.microsoft.com/TermsOfUse.aspx
          MdmComplianceUrl : https://portal.manage.microsoft.com/?portalAction=Compliance

MdmUrl には、デバイスが Microsoft Entra ID から受け取った 「どの MDM サービスに登録すればよいか」 という情報が入ります。

つまりこの値は、Microsoft Entra 管理センターで設定した MDM の構成が、実際にこのデバイスまで届いているかを、デバイス側から検証できる指標 になっています。管理センターの設定画面とデバイス側の実態を突き合わせられるため、ここが空欄かどうかが分かるだけで切り分けが一気に進みます。

MdmUrl が空欄・表示されない場合、MDM が構成されていないか、サインイン中のユーザーが MDM 登録のスコープ外 であることを示します。空欄だった場合は Microsoft Entra 管理センター上から次の 3 項目をご確認ください。

[Entra ID] - [モビリティ] - [Microsoft Intune]

#確認項目期待値・注意点
1MDM ユーザー スコープすべて、または対象ユーザーが含まれるグループ。空欄の原因として最も多いのがここ
2Windows 情報保護 (WIP) ユーザー スコープなし を推奨。MAM が優先されると MDM 自動登録が行われません
3MDM の探索 URL既定値 https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc。この値がそのまま MdmUrl に現れます

管理センター上は正しく設定されているように見えるのに MdmUrl が空欄、というときは、対象ユーザーが実際にスコープに含まれているか (グループ指定の場合はそのグループのメンバーになっているか) をあらためてご確認ください。設定画面とデバイス側の実態を突き合わせられるのが、この MdmUrl チェックの価値です。

💡 MdmUrl があっても「登録済み」という意味ではありません
MdmUrl はあくまで「テナントに自動登録の構成がある」ことを示すもので、そのデバイス自体が MDM で管理されているかどうかを表すものではありません。 値が入っていても未登録ということは普通にありますので、登録の成否はステップ ③ のイベント ログでご確認ください。

なお、Tenant Details セクションは、デバイスが Microsoft Entra 参加済みまたは Microsoft Entra ハイブリッド参加済みの場合に表示されます。セクション自体が見当たらない場合は、そもそも参加が完了していない可能性がありますので、DomainJoined / AzureAdJoined をあらためてご確認ください。

結果ごとの次のアクション

状態判断次にすること
4 つとも期待値どおりステップ ① は問題なしステップ ② へ進む
AzureAdJoined: NOHybrid Entra Join 自体が未完了Entra ID 観点で調査
AzureAdPrt: NOPRT を取得できていないEntra ID 観点で調査
MdmUrl が空欄テナントの MDM 構成がデバイスに届いていないEntra ID 観点で調査 (モビリティ設定の MDM ユーザー スコープ を最優先で確認)

4 つのいずれかが期待値どおりでない場合、いずれも Microsoft Entra ID 観点で調査を進める必要がある事象です。 ただし、その理由は次の 2 つに分かれます。

  • DomainJoined / AzureAdJoined / AzureAdPrt — Hybrid Entra Join (デバイス登録) 自体が正常に完了していない
  • MdmUrl — Join は完了しているが、Microsoft Entra ID 側のモビリティ設定 (MDM ユーザー スコープなど) がデバイスに反映されていない

理由は異なりますが、どちらも Microsoft Entra ID の観点から調査を行う必要があります。 この切り分けができているだけで調査の方向性が大きく変わりますし、サポートへお問い合わせいただく際にも適切な窓口へスムーズにおつなぎできます。

なお、ドメイン参加済みで Hybrid Entra Join が未完了の場合は、dsregcmd /status の出力に Pre-Join Diagnostics というセクションが表示され、SCP (Service Connection Point) の構成やデバイス登録サービスへの疎通確認の結果を確認できます。各フィールドの詳しい読み方とあわせて、下記もご参照ください。

ステップ ②：グループ ポリシーがデバイスに届いているかを確認する

ステップ ① が問題なければ、もう一方の条件である「自動登録のポリシーがデバイスに届いているか」を確認します。

ポリシーの設定内容を確認する

まず、自動登録のポリシーそのものです。設定場所は次のとおりです。

1
2
[コンピューターの構成] - [ポリシー] - [管理用テンプレート] - [Windows コンポーネント] - [MDM]
  - [既定の Azure AD 資格情報を使用して MDM の自動登録を有効にする] : "有効" かつ "ユーザー資格情報"

このポリシーがグループ ポリシー エディターに見当たらない場合は、ドメイン コントローラーの Central Store に配置されている ADMX ファイル (MDM.admx) が古い可能性があります。最新の ADMX をご配置ください。

「資格情報の種類」の選択にご注意ください

このポリシーを有効にすると、[使用する資格情報の種類を選択する] という設定項目が現れ、ユーザー資格情報 と デバイスの資格情報 を選択できます。ここは、通常の Hybrid Entra Join 環境では ユーザー資格情報 を選択します。

デバイスの資格情報 は一見よさそうに見えるのですが、Intune のサブスクリプションがユーザー中心の仕組みであるため、共同管理 (Co-management) または Azure Virtual Desktop のマルチセッション ホスト プールのシナリオでのみサポートされる 選択肢です。該当しない環境で選択すると、登録が想定どおりに進まない原因になります。

「よかれと思って デバイスの資格情報 を選んでいた」というのは実際にあるパターンですので、うまくいかない場合はこの設定もあわせてご確認ください。

ポリシーが実際にデバイスへ適用されているかを確認する

設定内容が正しくても、そのポリシーが対象デバイスに届いていなければ意味がありません。デバイス側で適用状況を確認します。

おすすめは rsop.msc (ポリシーの結果セット) です。管理者権限で実行すると、グループ ポリシー エディターと同じツリー構造で 「最終的にこのデバイスに適用された設定」 を確認できます。

1
rsop.msc

起動したら、次の場所を開いてください。

1
[コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [MDM]

ここに [既定の Azure AD 資格情報を使用して MDM の自動登録を有効にする] が 有効 として表示されていれば、ポリシーは確かにデバイスへ届いています。rsop.msc の利点は、設定が適用されているかどうかに加えて「どの値で適用されたか」まで一目で分かる ことです。前述の「資格情報の種類」が意図したとおりに設定されているかも、ここで確認できます。

rsop.msc に該当の設定が出てこない場合は、Intune 以前に グループ ポリシーの配布そのもの に問題があります。リンク先の OU、セキュリティ フィルター、対象デバイスがフィルター用グループに含まれているか、といった点をご確認ください。「Intune の問題だと思っていたら、実は GPO が当たっていなかった」というのは、実際によくあるパターンです。

ポリシーの適用を急ぎたい場合は、次のコマンドで更新を試みます。

1
gpupdate /force

切り分けのコツ ― ローカル グループ ポリシーで試してみる

「GPO は配布しているはずなのに、どうも届いているか自信がない」というときに有効なのが、対象デバイス上でローカル グループ ポリシーとして同じ設定を入れてしまう という方法です。

ローカル グループ ポリシー エディター (gpedit.msc) を管理者権限で起動し、ドメインの GPO と同じ場所に同じ設定を行います。

1
2
3
gpedit.msc
  [コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [MDM]
    - [既定の Azure AD 資格情報を使用して MDM の自動登録を有効にする] : "有効" かつ "ユーザー資格情報"

こうすると、ドメインの GPO 配布経路を完全に迂回して、自動登録そのものを試せます。 結果の解釈はシンプルです。

ローカル GPO で試した結果判断次にすること
登録が成功した自動登録の仕組み自体は正常。問題はドメイン GPO の配布経路OU のリンク、セキュリティ フィルター、GPO の適用範囲を見直す
やはり登録されないGPO の配布は原因ではないステップ ③ 以降 (タスク・イベント ログ・レジストリ) へ進む

ステップ ② と ③ のどちらに原因があるのかを一手で切り分けられるため、調査が長引きそうなときほど効果的です。また、Intune 登録を急いで行う必要があるデバイスが存在する場合には、一旦ローカル グループ ポリシーで登録を進めてしまうというのも一つの手法です。

ステップ ③：自動登録タスクの状態を確認する

グループ ポリシーが適用されると、デバイス上に 自動登録用のタスクが作成 され、そのタスクが実際の登録処理を実行します。ここでは「タスクが作られているか」「動いているか」「結果はどうだったか」を確認していきます。ステップ ① と ② の結果が実際にどう出たかが、ここに現れます。

タスク スケジューラーで確認する

管理者権限でタスク スケジューラーを起動し、次の場所をご確認ください。

1
[タスク スケジューラ ライブラリ] - [Microsoft] - [Windows] - [EnterpriseMgmt]

ここに 「Schedule created by enrollment client for automatically enrolling in MDM from AAD」 という名前のタスクがあれば、グループ ポリシーは正しく処理されています。このタスクが 5 分おきに 登録を試行します。

タスクの 前回の実行結果 列もあわせてご確認ください。ここには前回の実行時に返されたコードが表示され、後編での切り分けで重要な手がかり になります。

ここでの分岐は次のとおりです。

  • タスクが存在しない → グループ ポリシーが適用されていない可能性のほか、登録の残骸によってタスクの作成自体がスキップされている 場合もあります。ステップ ② (rsop.msc での確認) とあわせて、後編の「症状 ②：レジストリの残骸」もご確認ください
  • タスクは存在するが実行された形跡がない → 後編の「症状 ②：レジストリの残骸」を確認
  • タスクは実行されているが失敗している → 次のイベント ログでエラー コードを確認

イベント ログで登録の成否を確認する

自動登録の結果は、次のイベント ログに記録されます。

1
2
[アプリケーションとサービス ログ] - [Microsoft] - [Windows]
  - [DeviceManagement-Enterprise-Diagnostics-Provider] - [Enrollment]

💡 ビルドによっては [Admin] の下にあります
このプロバイダーのログは、2025 年初頭の更新プログラムを境に Admin から Enrollment / Sync / Admin の 3 つに分割 されました。それ以前のビルドでは、以降でご紹介するイベントは [Admin] に記録されます。Enrollment が見当たらない場合は Admin を、Admin に何もない場合は Enrollment を ご確認ください。

ここで確認するイベント ID は 2 つです。

イベント IDメッセージ意味
75Auto MDM Enroll: Device Credential (0x0), Succeeded自動登録に成功
76Auto MDM Enroll: Device Credential (0x0), Failed (Unknown Win32 Error code: 0x____)自動登録に失敗。末尾のカッコ内のエラー コードが原因特定の最大の手がかり

💡 Device Credential (0x0) と出ていても異常ではありません
このメッセージは ユーザー資格情報 を使った場合でも、常に Device Credential という表記で記録されます。 カッコ内の値が「デバイスの資格情報を使ったかどうか」を表しており、次のように読み分けます。

  • (0x0) … ユーザー資格情報 を使用 (通常の Hybrid Entra Join 環境ではこちら)
  • (0x1) … デバイスの資格情報 を使用

つまり ユーザー資格情報 で正しく構成できている場合、表示されるのは Device Credential (0x0) です。「デバイスの資格情報になってしまっているのでは」と誤解されやすいポイントですので、ご注意ください。

イベント ID 76 が記録されていれば、そのエラー コードから原因を絞り込めます。

また、イベント ID 75 も 76 もまったく記録されていない というケースもあります。これは「登録に失敗した」のではなく 「登録処理がそもそも起動していない」 ことを意味します。

いずれの場合も、ここから先は エラー コードごとに確認すべき場所が変わります。 その内容は長くなりますので、後編としてあらためてご紹介します。

おわりに

今回は、Hybrid Entra Join 環境で Intune 登録が行われないときに 「どこを、どの順番で確認するか」 をご紹介しました。あらためて要点を整理します。

  • 自動登録は 「Hybrid Entra Join」と「グループ ポリシーの適用」の 2 つがそろって動く。この 2 つに順番の決まりはなく、欠けているのがどちらかを探すのが切り分けのコツ
  • ステップ ① の dsregcmd /status では 4 つのフィールド (DomainJoined / AzureAdJoined / AzureAdPrt / MdmUrl) を確認する。事象が発生しているユーザーのコンテキストで実行すること
    • 4 つのいずれかが期待値どおりでなければ、いずれも Microsoft Entra ID 観点での調査が必要。Intune 管理センターを調べても原因は見つからない
    • AzureAdPrt: NO → Hybrid Entra Join (デバイス登録) 自体の問題
    • MdmUrl が空欄 → Entra ID のモビリティ設定、特に MDM ユーザー スコープの設定漏れが濃厚
  • グループ ポリシーの [使用する資格情報の種類を選択する] は、通常の Hybrid Entra Join 環境では ユーザー資格情報 を選択する
  • ポリシーの適用状況は rsop.msc で確認する。「適用されたか」だけでなく「どの値で適用されたか」まで分かる
  • 配布経路が疑わしいときは ローカル グループ ポリシーで同じ設定を入れて試す。成功すれば原因は GPO の配布経路、失敗すればそれ以外と一手で切り分けられる
  • ステップ ③ の イベント ID 75 / 76 が、ステップ ① と ② の結果が最終的に現れる場所。76 のエラー コードが原因特定の最大の手がかり

この構成のトラブルシューティングは、一見すると手がかりが少なく難しく感じられるかもしれません。しかし「そろうべき条件のうち、欠けているのはどれか」という視点で見ていけば、確認すべき場所は自ずと絞り込まれていきます。

後編では、ここで得られたエラー コードをもとに、具体的な原因の特定と対処をご紹介します。あわせてご活用ください。

次回以降も、皆さまの運用に役立つ情報をお届けしていきます。最後までお読みいただき、ありがとうございました。

]]> https://jpintune.github.io/blog/intune/20261001_01/ 2026-09-30T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

オンプレミスの Active Directory で長く運用してきた Windows デバイスを、Intune でも管理していきたい。そんなときに多くのお客様が選ばれるのが、Hybri]]>

Hybrid Entra Join 環境で Intune 登録が行われないときの確認ポイント 2026-11-02T00:39:51.239Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

前回は、Hybrid Entra Join (Microsoft Entra ハイブリッド参加) 環境でグループ ポリシーによる自動登録がうまくいかないときに、「どこを、どの順番で確認するか」 を 3 つのステップに整理してご紹介しました。

おさらいすると、この構成で登録が動くには ① Hybrid Entra Join の完了 と ② グループ ポリシーの適用 の 2 つがそろう必要があり、その結果は ③ 自動登録タスク の実行を経て、最終的に次のイベント ログに現れます。

1
2
[アプリケーションとサービス ログ] - [Microsoft] - [Windows]
  - [DeviceManagement-Enterprise-Diagnostics-Provider] - [Enrollment]
イベント ID意味
75自動登録に成功
76自動登録に失敗。末尾のカッコ内のエラー コードが原因特定の最大の手がかり

今回はその続きとして、イベント ID 76 で得られたエラー コードから原因を絞り込み、対処するまで をご紹介します。「エラー コードは取れたものの、そこから先をどう調べればよいか分からない」というときに、お手元でご活用いただければ幸いです。

なお、イベント ID 75 も 76 もまったく記録されない というケースもあります。こちらも本記事で扱いますので、あわせてご確認ください。

エラー コードから原因を絞り込む

ここからは、イベント ID 76 で得られた結果に応じて確認していく内容です。順番に実施するものではなく、症状に応じて該当する項目をご覧ください。

主だったエラーについて下記にまとめました。まずは次の早見表から、お手元で確認できた症状に該当する行をお探しください。

症状 / エラー コード内部名原因と次に確認すること
0x80180014MENROLL_E_DEVICENOTSUPPORTED登録の制限でブロックされている。Intune 管理センター - [デバイス] - [登録] - [Windows] - [デバイス プラットフォームの制限] で登録が制限されるような設定が行われていないかを確認
0x80180018MENROLL_E_USERLICENSEIntune ライセンスが未割り当て。Microsoft 365 管理センター で対象ユーザーへの割り当てを確認
0x8018002AMENROLL_E_USER_CANCELEDサイレントなトークン取得が完了できなかった → 症状 ①
イベント ID 75 も 76 も記録されていない (タスクが作成されない場合も含む)―過去の登録情報の残骸 → 症状 ②
0x8018000AMENROLL_E_DEVICE_ALREADY_ENROLLEDデバイスが既に登録済みと判定されている → 症状 ②
0x80180026MENROLL_E_DEVICE_MANAGEMENT_BLOCKED外部管理フラグなどで登録がブロックされている → 症状 ③
0x83750005 (イベント ID 56 も記録される)WEB_E_UNEXPECTED_CONTENT構成の検証に使う ValidNodePaths が欠損・破損している → 症状 ④
0x80190190 (メッセージは Bad request (400).)HTTP_E_STATUS_BAD_REQUEST過去の登録処理のフラグが残っている → 症状 ⑤

0x80180014 / 0x80180018 は、テナント側の設定不備がそのまま現れたもの です。「デバイス側は正しく動いているが、テナント側で弾かれている」状態ですので、表に記載の管理センターをご確認ください。

その他にも一般的なエラーについて、下記の公開情報で紹介をしておりますので、上記に該当するものがない場合、こちらも参考にしてみてください。

症状 ①：エラー コード 0x8018002A ― 多要素認証 (MFA) の要求

イベント ID 76 のエラー コードが 0x8018002A だった場合、まず疑っていただきたいのが 多要素認証 (MFA) の要求 です。条件付きアクセス (Conditional Access) によるものと、ユーザー単位で設定する従来型のものと、どちらでも発生します。

Hybrid Entra Join 環境の自動登録がうまくいかない原因として、実際によく遭遇するパターンです。

なぜ MFA が問題になるのか

グループ ポリシーによる自動登録は、PRT (Primary Refresh Token) を使ってサイレントに (ユーザーに何も聞かずに) トークンを取得 して処理を進めます。このとき、対象ユーザーに対して MFA が要求されていると、追加の認証操作が必要になるため、サイレントなトークン取得を完了できません。

その結果、デバイス上には「管理者による変更が必要です」といった趣旨のトースト通知が表示され、ユーザーがそれに気づかず放置されるとタイムアウトし、最終的に 0x8018002A (MENROLL_E_USER_CANCELED) というエラーで失敗します。

エラー名に “USER_CANCELED” と入っているため「ユーザーが操作をキャンセルした」と読めてしまうのですが、実際にはユーザーが意図的にキャンセルしたとは限らない、という点が切り分けを難しくしています。

見分け方のヒント

この事象には、次のような分かりやすい特徴があります。

  • 失敗するデバイスで、イベント ID 76 のエラー コードが 0x8018002A になっている
  • デバイス上にサインインを促すトースト通知が表示された形跡がある

決め手になるのが、Microsoft Entra ID 側のログとの突き合わせ です。次のログをあわせてご確認ください。

1
2
[アプリケーションとサービス ログ] - [Microsoft] - [Windows]
  - [AAD] - [Operational]

Intune 登録が失敗したタイミングで、次のようなエラーが記録されていれば、MFA の要求が原因であることがほぼ確定します。

1
2
3
4
エラー: 0xCAA2000C 要求にはユーザーの操作が必要です。
コード: interaction_required
説明: AADSTS50076: 管理者によって行われた構成の変更、または新しい場所に移動したために、
      多要素認証を使用してアクセスする必要があります。

interaction_required (ユーザーの操作が必要) というコードが、「サイレントに処理を完了できなかった」 という状況をそのまま表しています。デバイス側の 0x8018002A と、この AADSTS50076 が同じタイミングで記録されていれば、まず間違いありません。

「特定のユーザーだけ登録できない」という状況であれば、ユーザーに適用されている条件付きアクセス ポリシーの差 を確認してみてください。確認の際は、Microsoft Entra 管理センターのサインイン ログで、対象ユーザーの認証が MFA 要求によって中断されていないかをご確認いただくのが確実です。

この症状については、下記の公開情報でも紹介をしています。

💡 共同管理向けの公開情報ですが、原因は同じです
上記は Configuration Manager との共同管理環境を対象とした情報ですが、「PRT を使ったサイレントな登録が MFA 要求で中断される」という原因そのものは、グループ ポリシーによる自動登録でも共通 です。記載されている現象・エラー コード・回避策は、本記事の構成でもそのまま参考にしていただけます。

症状 ②：イベント ID 75 / 76 が記録されない ― 登録をブロックする「レジストリの残骸」

「グループ ポリシーは適用されている」「なのにイベント ID 75 も 76 も記録されず、何も起こらない」。この、いちばんもどかしいパターンの正体が 過去の MDM 登録情報の残骸 であることが少なくありません。

一見すると「エラーすら出ていない」ように見えますが、実際には内部でエラーが発生しています。 ただしそれがイベント ID 75 / 76 には現れないため、「何も起きていない」と判断してしまいがちです。

なぜ 75 / 76 が記録されないのか

Windows は自動登録を実行する前に「このデバイスは既に MDM に登録済みか？」を確認します。ここで 既に登録済みと判定されると、その時点で処理を打ち切ります。

このとき重要なのが、打ち切りが「エラー コードを返して即座に抜ける」形で行われる という点です。その結果、イベント ID 75 / 76 を書き出す処理まで到達しません。「エラーが起きていないから何も出ない」のではなく、エラー自体は発生しているが、75 / 76 には現れない というのが実態です。

具体的には、次のエラー コードが返されています。

1
2149056522 (0x8018000A)  =  デバイスが既に MDM に登録済み

この判定に使われるのが HKLM\SOFTWARE\Microsoft\Enrollments 配下のレジストリです。通常、登録解除時にこれらのエントリは削除されますが、何らかの理由でキーが残ってしまうことがあります。過去に別の MDM 製品をご利用だった場合や、登録解除が正常に完了しなかった場合などが該当します。

確認は「レジストリを直接見る」のが確実です

この事象に該当するかどうかは、判定に使われているレジストリそのものを確認するのが最短 です。後述の「登録情報の『残骸』を確認する」で、具体的な確認方法をご紹介します。

そのうえで、エラー コードが実際に出ていることを裏付けたい場合 は、タスク スケジューラーの 前回の実行結果 列をご確認ください。タスクが作成されている場合、ここに 2149056522 (0x8018000A) と表示されます。追加の設定なしで確認できます。

なお、この判定が起きるとタスク自体が削除される場合もあるため、「一度は動いた形跡があるのにタスクが消えている」 という状態になることがあります。

また、グループ ポリシーが適用された時点で既に残骸があると、そもそも登録タスクが作成されない場合があります。 この場合はタスク スケジューラー側に手がかりが残りませんので、タスクの有無にかかわらず、レジストリをご確認ください。

登録情報の「残骸」を確認する

HKLM\SOFTWARE\Microsoft\Enrollments 配下には GUID 名のキーが複数並んでいることが多く、どれが現在有効な登録で、どれが残骸なのか判断に迷うところです。

見分ける鍵は DiscoveryServiceFullURL という値の有無 です。この値を持つキーは、実際に MDM サービスと通信するための情報を保持している「生きている登録」を示します。

次の PowerShell コマンドで、DiscoveryServiceFullURL を持つ Enrollment ID を抽出できます。

1
2
3
4
Get-ChildItem HKLM:\Software\Microsoft\Enrollments |
    ForEach-Object { Get-ItemProperty $_.PSPath } |
    Where-Object { $_.DiscoveryServiceFullURL } |
    ForEach-Object { $_.PSChildName }

実行結果の例：

1
17ABFAA0-BE06-422E-AB1C-DBDCCBA8D4B6

このコマンドで GUID が出力された場合、Windows はそのデバイスを「MDM に登録済み」と認識している ということです。Intune 管理センターに該当のデバイスが存在しないにもかかわらず GUID が出力される場合、それが自動登録をブロックしている残骸である可能性があります。

特に確認したい「ダミーの登録情報」

残骸のなかでも特徴的なのが、FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF という、すべて F で構成された GUID のキーです。

このキーは自然に発生したものではなく、ドメインに参加していないデバイスに対して一部のポリシーを適用させる目的で、意図的に構成されることがある ものです。Windows からは「MDM に登録済み」と認識されるため、当然ながら Intune への自動登録もスキップされてしまいます。

⚠️ 削除する前に必ずご確認ください
このキーは、過去に何らかの意図をもって構成された可能性があります。削除するとそれまで適用されていた設定が効かなくなる場合がありますので、削除の前に、そのような構成を行っていないか社内の運用担当の方にご確認ください。

残骸を削除する場合 ― 公開されている手順をご利用ください

意図的な構成でないことが確認でき、残骸として削除する場合は、Azure & Identity サポート チームが公開している次の記事の手順をご利用ください。

この記事の 「2. 事前準備: Intune の登録解除」 に、削除対象のレジストリを PowerShell でまとめて処理する手順 が掲載されています。前述の DiscoveryServiceFullURL で Enrollment ID を特定するコマンドから、関連するレジストリ (Enrollments / EnterpriseResourceManager / PolicyManager / Provisioning\OMADM など) の削除、さらに 登録タスクの削除 までが一連の流れとして整理されています。

手作業でレジストリ エディターから 1 つずつ削除するよりも、確実で、削除漏れも起きにくい 手順です。残骸の削除だけが目的であれば、この「2.」の手順のみを実施いただければ十分です。

⚠️ 作業前に必ずレジストリのバックアップを取得してください。
レジストリの編集は、誤るとシステムが正常に動作しなくなるおそれがあります。まずは 1 台のデバイスで動作を確認したうえで、展開されることをおすすめします。

削除後にデバイスを再起動し、あらためて gpupdate /force を実行すると、自動登録タスクが起動するようになります。

💡 Hybrid Entra Join 自体の再構成が必要な場合も
上記の記事は本来、Hybrid Entra Join (MEHJ) をデバイス上で再構成するための手順 です。前編のステップ ① で AzureAdJoined や AzureAdPrt に問題が見つかっていた場合など、登録の土台からやり直したいケースでは、記事の手順を最後まで通して実施 いただくことで解決できることがあります。

なお、残骸が広範に残っている場合や、削除後も改善しない場合は、デバイスを初期化して再展開するほうが結果的に確実で早い ケースもあります。対象デバイスの台数や重要度に応じて、ご判断ください。

症状 ③：エラー コード 0x80180026 ― 「外部管理」フラグが残っている

症状 ② と同じく レジストリが登録をブロックしている パターンですが、こちらは イベント ID 76 にエラー コードが記録される 点が異なります。

イベント ID 76 のエラー コードが 0x80180026 (MENROLL_E_DEVICE_MANAGEMENT_BLOCKED) だった場合、Windows が 「このデバイスは別の仕組みで管理されている」と判断している 可能性があります。

確認するレジストリ

Windows は登録処理の前に「そもそも MDM 登録が許可されているか」を確認しており、次の 2 つの値のどちらかが 0 以外 だと、その時点で登録を拒否します。

キー値意味
HKLM\SOFTWARE\Microsoft\EnrollmentsExternallyManagedデバイスが外部の仕組みで管理されているとマークされている
HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDMDisableRegistrationポリシーで MDM 登録そのものが無効化されている

いずれも 値が存在しない、または 0 であることが正常な状態です。

なぜ ExternallyManaged が残るのか

この値は、サード パーティ製の MDM やデバイス管理エージェントが「このデバイスは自分が管理している」と宣言するために設定する ものです。Windows 側にはこの値を設定するための API が用意されており、外部の管理製品から呼び出せるようになっています。

そのため、過去に別の管理製品を導入していたデバイス で、アンインストール時にこの値が戻されないまま残ってしまう、というケースが起こり得ます。症状 ② の「登録情報の残骸」と発生要因はよく似ています。

対処

意図的に設定されたものでないことを確認したうえで、値を 0 に変更する (または値自体を削除する) ことで登録が可能になります。

⚠️ 削除前に「本当に不要か」をご確認ください
現在も稼働中のサード パーティ製 MDM がこの値を設定している場合、削除するとその製品の動作に影響する可能性があります。その管理製品を既に利用していないこと を確認したうえで実施してください。判断がつかない場合は、当該製品の提供元へご確認いただくことをおすすめします。

変更後に gpupdate /force を実行すると、確実に登録タスクの実行を試行することが出来ます。

症状 ④：エラー コード 0x83750005 ― ValidNodePaths の欠損・破損

こちらもレジストリに起因する問題で、HKLM\SOFTWARE\Microsoft\Enrollments\ValidNodePaths 配下のレジストリが欠損していたり、破損している場合に発生します。

このキーの配下には NodePath1、NodePath2… という値が並んでおり、それぞれに certificatestore、application、registry といった 構成項目の名前 が格納されています。

ここの構成項目の情報が欠損していたり、破損していると Windows は「想定外の内容が含まれている」と判断し、0x83750005 (WEB_E_UNEXPECTED_CONTENT) エラーで登録処理を中止してしまいます。

該当するイベント ログ

このケースでは、イベント ID 76 に加えて イベント ID 56 が記録されます。

1
2
3
4
5
[イベント ID 56]
MDM Enroll: Failed to parse server provisioning XML. Result: (CertificateStore:0x83750005).

[イベント ID 76]
Auto MDM Enroll: Device Credential (0x0), Failed (Unexpected content.) (0x83750005)

確認方法

OS ビルド番号や更新プログラムの適用状況が同じ正常なデバイス と、症状が発生しているデバイスの HKLM\SOFTWARE\Microsoft\Enrollments\ValidNodePaths 配下を比較して、不足している値がないかを確認してください。

キー自体が存在しない、または 値の数が明らかに少ない 場合は、この事象に該当する可能性があります。

対処 ― 正常なデバイスから移植する

このレジストリは、比較元としたデバイスからエクスポートして取り込むことで復旧できます。

  1. 正常に Intune 登録できているデバイスで、上記のキーをエクスポートする
  2. 出力した .reg ファイルを対象デバイスにコピーして取り込む
  3. gpupdate /force を実行し、登録が進むことを確認する

⚠️ エクスポート元のデバイスは慎重にお選びください
この値の内容は OS のビルドによって異なる可能性があります。新しい機能が追加されると項目も増えていくため、異なるビルドから持ち込むと、今度は別の構成項目が弾かれる という事態になりかねません。エクスポート元は、必ず対象デバイスと OS ビルド番号や更新プログラムの適用状況をそろえて ください。

なお、このレジストリが失われている場合、他のレジストリもあわせて破損している可能性 があります。移植しても改善しない場合や、複数の箇所に異常が見られる場合は、OS の再インストール (リセットまたはクリーン インストール) をご検討ください。

どのようなときに起こるのか

このレジストリは、通常の運用で失われるものではありません。実際にご相談いただくのは、カスタム イメージを使って展開されたデバイス や、デバイスのリセット・再イメージングの過程で処理が中断したデバイス といったケースが中心です。

同じイメージから展開したデバイスで同様の事象が複数台発生している場合は、イメージそのものに起因していないか をあわせてご確認いただくとよいでしょう。

症状 ⑤：エラー コード 0x80190190 ― 過去の登録のフラグが残っている

イベント ID 76 に Bad request (400). というメッセージが記録されている場合 (エラー コードは 0x80190190) に疑っていただきたいのが、過去の登録処理で使われたフラグの消し忘れ です。

これも症状 ②・③ と同じ「レジストリの残骸」の一種ですが、残っているのが登録情報そのものではなく、登録処理の途中経過を示すフラグ である点が異なります。

該当するイベント ログ

1
Auto MDM Enroll: Device Credential (0x0), Failed (Bad request (400).)

確認するレジストリ

次の値が 2 になっていないかをご確認ください。

1
2
キー : HKLM\SOFTWARE\Microsoft\Enrollments
値   : MmpcEnrollmentFlag

値が存在しない、または 0 であれば正常です。

この値は、Intune への登録処理の途中経過を示すために使われるもので、本来は処理の完了時に 0 に戻される 想定になっています。

ところが、サーバー側のエラーなどで処理が途中で終わってしまうと、2 のまま残ってしまう ことがあります。その結果、通常の Intune 登録として処理されるはずのリクエストが不正な状態となってしまい、サーバーから「不正なリクエスト (400)」として拒否される という流れになります。

過去に Intune 登録していたデバイスを登録解除し、あらためて Hybrid Entra Join や自動登録を試みた、といったケースで発生することがあります。

対処

値を 0 に変更する (または値自体を削除する) ことで登録が可能になります。変更後に gpupdate /force を実行すると、次回のタスク実行時に登録が試行されます。

ログの採取 ― いざというときのために

ご自身での切り分けが難しい場合や、サポートへお問い合わせいただく場合に備えて、次の情報をあわせてご採取いただけると、調査をスムーズに進められます。

  • dsregcmd /status の出力 (事象が発生しているユーザーのコンテキストで実行。Device State / SSO State に加え、Tenant Details の MdmUrl も含まれます)
  • TSS で採取した診断ログ (次の手順をご参照ください)

TSS で診断ログをまとめて採取する

TSS (TroubleShootingScript) は、マイクロソフトが提供している診断情報の採取ツールです。本記事でご紹介したイベント ログやレジストリのほか、前編でご紹介した情報も含めて、調査に必要な情報をまとめて取得できます。

対象デバイスに管理者権限を持つアカウントでサインインし、次の手順で実行してください。

1. TSS を入手して配置する

下記から TSS.zip をダウンロードし、任意の場所に展開します。以降の手順は、C ドライブ直下 (C:\TSS) に展開した場合の例です。

2. PowerShell を管理者として実行し、ファイルのブロックを解除する

インターネットから入手したファイルはブロックされた状態のため、次のコマンドで解除します。

1
Get-ChildItem -Recurse -Path C:\TSS\*.ps* | Unblock-File -Confirm:$false

3. スクリプトの実行ポリシーを設定する

1
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned -Force

-Scope Process を指定しているため、変更の影響は現在の PowerShell セッションのみ です。ウィンドウを閉じれば元の設定に戻ります。

4. 情報の採取を開始する

1
2
cd C:\TSS
.\TSS.ps1 -CollectLog ITN_Report

使用許諾 (Microsoft Diagnostic Tools End User License Agreement) が表示された場合は、内容をご確認のうえ [Accept] をクリックしてください。

5. 出力されたファイルを確認する

採取が完了すると、C:\MS_DATA 配下に TSS_<コンピューター名>_YYMMDD-hhmmss から始まる名前の zip ファイルが出力されます。

「正常に登録できているデバイス」と「登録できないデバイス」の両方から同じ情報をご採取いただけると、差分から原因を絞り込みやすくなります。可能であれば、ぜひ両方の情報をご用意ください。

おわりに

今回は、Hybrid Entra Join 環境で Intune 登録が失敗したときに、エラー コードから原因を特定して対処する方法をご紹介しました。あらためて要点を整理します。

  • 特定のユーザーだけ失敗する場合は、MFA の要求 (0x8018002A) を疑う。条件付きアクセスだけでなく、従来型のユーザーごとの MFA が 強制 (Enforced) になっているケースもある。AAD の Operational ログに AADSTS50076 が出ていれば確定。よく遭遇するパターン
  • イベント ID 75 / 76 が出ない ときは、HKLM\SOFTWARE\Microsoft\Enrollments 配下の 登録情報の残骸 を疑う。「エラーが出ていない」のではなく 2149056522 (0x8018000A = 既に登録済み) が返っており、75 / 76 に到達していないだけ。レジストリを直接確認するのが最短で、タスクの 前回の実行結果 列でも裏付けが取れる
  • イベント ID 76 が 0x80180026 のときは、Enrollments の ExternallyManaged と MDM ポリシーの DisableRegistration を確認する。過去に導入したサード パーティ製 MDM のフラグが残っていることがある
  • イベント ID 76 が 0x83750005 (またはイベント ID 56) のときは、Enrollments\ValidNodePaths の欠損・破損を疑う。OS ビルドがそろった正常なデバイスからレジストリを移植して復旧する
  • イベント ID 76 が Bad request (400). (0x80190190) のときは、Enrollments の MmpcEnrollmentFlag が 2 のまま残っていないかを確認する。
  • 残骸の削除は、意図的な構成でないことを確認し、バックアップを取得したうえで慎重に実施する。手順は Azure & Identity サポート チームの公開ブログ (Microsoft Entra ハイブリッド参加デバイスを再構成する) をご利用いただくのが確実

前編とあわせてご覧いただくと、「① と ②、欠けているのはどちらか」を切り分け、③ で得られたエラー コードから原因までたどり着く という一連の流れになります。

この構成のトラブルシューティングは、一見すると手がかりが少なく難しく感じられるかもしれません。しかし「そろうべき条件のうち、欠けているのはどれか」という視点で見ていけば、確認すべき場所は自ずと絞り込まれていきます。ぜひ、本記事をお手元のチェックリストとしてご活用ください。

次回以降も、皆さまの運用に役立つ情報をお届けしていきます。最後までお読みいただき、ありがとうございました。

]]> https://jpintune.github.io/blog/intune/20261001_02/ 2026-09-30T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

前回は、Hybrid Entra Join (Microsoft Entra ハイブリッド参加) 環境でグループ ポリシーによる自動登録がうまくいかないときに、「どこを、どの順番で確認]]>

Hybrid Entra Join 環境で Intune 登録が行われないとき ― エラー コード別のトラブルシューティング 2026-11-02T00:39:51.239Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

Intune はもともとモバイル デバイスの管理 (MDM) を出発点としたサービスですが、近年ではこれまでオンプレミスの仕組みで管理されてきた Windows デバイスを、Intune へ移行して運用されるお客様がぐんと増えてきました。

そこで一度は考えておきたいのが、アプリのコンテンツがどこから、どのくらいの量、どのタイミングで流れてくるのか という点です。オンプレミスの管理製品では、拠点ごとに配布サーバーを置き、そこからクライアントへ配布する構成が一般的でした。一方 Intune は、その名のとおりクラウド サービスです。数百台のデバイスに一斉にアプリを割り当てると、その分のコンテンツがインターネット回線を通ってダウンロードされることになります。

「アプリを割り当てた直後から、拠点の回線が重くなってしまった」「大きなアプリを全社に配布したいが、業務への影響が心配」。こうしたお悩みは、事前にいくつかのポイントを押さえておくだけ軽くすることができます。

そこで今回は、Intune から Win32 アプリを配布する際に、ネットワークへの負荷を抑えるための考え方と、具体的な設定 をご紹介していきます。

なお、Win32 アプリの配布そのものについては、下記の記事でもご紹介しています。あわせてご覧いただくと、より効果的に運用いただけます。

はじめに ― Win32 アプリの配信には「配信の最適化」が使えます

具体的な設定に入る前に、ぜひ知っておいていただきたい、心強いポイントがあります。それは、Intune から配布する Win32 アプリのコンテンツのダウンロードには、Windows の「配信の最適化 (Delivery Optimization)」が使われている という点です。

配信の最適化は、Windows Update や Microsoft 365 Apps の配信でも使われている、Windows に標準で備わっている仕組みです。同じ拠点にいるデバイス同士でコンテンツを分け合ったり (ピア共有)、使用する帯域に上限を設けたり、拠点内のキャッシュ サーバーから取得したりと、ネットワーク負荷を抑えるための機能がひととおり揃っています。

Intune から Win32 アプリを配布すると、デバイス上の Intune Management Extension (以下、IME) がコンテンツのダウンロードを依頼し、それを受けて配信の最適化が実際の取得を行います。つまり、Windows Update の配信で培ってきた配信の最適化のノウハウや設定を、そのまま Win32 アプリの配布にも活かせる ということです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
flowchart TB
    subgraph CLOUD[" "]
        INTUNE["☁️ Microsoft Intune<br/>アプリの割り当て・配布の指示"]
        CDN["☁️ コンテンツ配信ネットワーク (CDN)<br/>Win32 アプリのコンテンツ"]
    end

    subgraph DEVICE["💻 デバイス上で連携して動作"]
        direction TB
        IME["🔷 Intune Management Extension<br/>アプリの配布を管理"]
        DO["🔶 配信の最適化<br/>(Delivery Optimization)<br/>コンテンツの取得を担当"]
        IME == "ダウンロードを依頼" ==> DO
    end

    INTUNE -- "配布の指示" --> IME
    DO -- "コンテンツを取得" --> CDN

    style CLOUD fill:transparent,stroke:transparent
    style DEVICE fill:#f3f3f3,stroke:#5f5f5f,stroke-width:2px
    style INTUNE fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style CDN fill:#eaf7ea,stroke:#107c10,stroke-width:2px
    style IME fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style DO fill:#eaf7ea,stroke:#107c10,stroke-width:2px

このことが分かると、打てる手も自然と見えてきます。ネットワーク負荷への対策は、大きく次の 2 つの方向から考えていくことになります。

  • 割り当ての設定: 「いつ」「どのデバイスに」ダウンロードさせるかを調整する
  • 配信の最適化の設定: 「どこから」「どのくらいの帯域で」取得するかを調整する

どちらも Intune 管理センターから設定できますので、順に見ていきましょう。

事前準備 ― ネットワーク管理者の方と相談しておく

具体的な設定の前に、最も効果が大きく、そして見落とされがちなのがこのステップです。

率直に申し上げると、Intune や Windows の設定だけでできることには限界があります。回線そのものの帯域や、拠点とインターネットの間にあるプロキシ・ファイアウォールの構成は、Intune からは変えられません。だからこそ、配布を始める前に、ネットワークを管理されている方と一度会話をしておく ことが、結果的にいちばんの近道になります。

相談の際は、次のような情報を持っていくと話がスムーズです。

  • 配布するアプリのサイズ
  • 配布対象のデバイス台数 と、その 拠点ごとの内訳
  • 配布したいタイミング (業務時間内か、夜間か)
  • 拠点の 回線の帯域 と、通常時の使用状況
  • プロキシや VPN を経由するか、経由する場合はその構成

ここで一度、ざっくりとで構いませんので総量を試算してみてください。たとえば 1 GB のアプリを 500 台へ配布する場合、単純計算で約 500 GB のトラフィックが発生します。これが同じ拠点に集中するのか、全国に分散するのかで、必要な対策はまったく変わってきます。

この試算をお持ちいただくと、「その時間帯なら問題ない」「この拠点だけは分けてほしい」といった具体的なアドバイスをネットワーク管理者の方からいただけることも多く、後の設定検討がとても進めやすくなります。

割り当ての設定でできる工夫

まずは、アプリの割り当ての設定でできる工夫を見ていきます。

① グループを分けて、段階的に割り当てる

いちばんシンプルで、それでいて確実に効くのがこの方法です。

「全ユーザー」「全デバイス」への割り当ては手軽ですが、その瞬間にすべてのデバイスが一斉にダウンロードを始める ことになります。まずは配布対象をグループに分け、段階的に広げていく形を検討してみてください。

グループの分け方としては、たとえば次のような切り口があります。

  • 拠点・オフィス単位で分ける … 同じ回線を共有しているデバイスをまとめて把握できるため、ネットワーク負荷の観点ではもっとも効果的です
  • 部署・業務単位で分ける … 業務への影響が少ない部署から順に展開できます
  • パイロット → 本展開の 2 段階に分ける … まず数十台で検証してから全社展開へ進みます

この方法には、ネットワーク負荷を分散できること以外にも、うれしい効果があります。万が一アプリのインストールに問題があった場合でも、影響範囲を最小限に抑えられる という点です。全社に配布した後で問題に気付くのと、パイロット グループの段階で気付けるのとでは、対応の負担がまったく違ってきます。

なお、デバイスのグループ分けには、Microsoft Entra ID の動的グループや、Intune の割り当てフィルターも活用できます。

② 割り当ての「可用性」と「インストール期限」を活用する

グループを分けたら、次は タイミング です。ここで活躍するのが、割り当て時に設定できる「アプリの可用性」と「インストール期限」です。

Intune の割り当て画面で「必須」の可用性とインストールの期限が「直ちに」に設定されている例

この 2 つの設定を理解するうえで大切なのが、「必須」として割り当てた場合、コンテンツのダウンロードは “可用性” の時刻に始まる という動作です。

  • 可用性 (Availability) … この時刻に IME がコンテンツのダウンロードを開始し、デバイス上にキャッシュします
  • インストール期限 (Installation deadline) … この時刻にインストールが実行されます

つまり、可用性を夜間や休日に設定しておくことで、常時起動しているようなデバイスであれば 重いダウンロードは業務時間外に済ませておき、インストールだけを任意のタイミングで行う、という運用ができるわけです。「業務時間中に回線が重くなる」というお悩みには、まさにこの設定がぴったりです。

さらに、①のグループ分けと組み合わせるとより効果的です。グループごとに可用性の日時を 1 日ずつ、あるいは数時間ずつずらしておけば、ダウンロードの山が自然に平準化され、特定の時間帯にトラフィックが集中することを避けられます。

一方、「利用可能」として割り当てた場合は動作が少し異なります。この場合の可用性の時刻は ポータル サイトにアプリが表示され始めるタイミング を指し、コンテンツのダウンロードはユーザーがポータル サイトからインストールを要求した時点で行われます。ユーザーの操作に依存する分、トラフィックは自然に分散されやすいという特徴があります。

設定は、アプリの割り当てを追加する際に表示される編集画面から行えます。

[アプリ] - [すべてのアプリ] - [<対象のアプリ>] - [プロパティ] - [割り当て]

なお、指定した時刻にダウンロードが始まるのは、当然ながら デバイスが起動していて、ネットワークに接続されている場合 です。夜間に設定される場合は、対象のデバイスが電源オフやスリープになっていないか、あわせてご確認ください。

③ 割り当ての「配信の最適化の優先度」を確認する

もう一つ、割り当ての画面で見ておきたいのが [アプリの設定] にある 配信の最適化の優先度 です。

Intune の割り当て画面で配信の最適化の優先度が「バックグラウンドでのコンテンツ ダウンロード」に設定されている例

ここでは、コンテンツをバックグラウンドとフォアグラウンドのどちらのモードでダウンロードするかを、割り当てごとに選択できます。

  • バックグラウンドでダウンロード (既定) … 急いでいない配信向けのモードです
  • フォアグラウンドでダウンロード … ユーザーが待っている前提のモードです

配信の最適化では、帯域の上限や、ピア・キャッシュ サーバーを待つ時間といった設定が、バックグラウンド用とフォアグラウンド用にそれぞれ分かれて用意されています。 ここでどちらのモードを選ぶかによって、そのダウンロードにどちらの設定が適用されるかが決まる、というのがこの項目の役割です。

急いでインストールする必要がない必須アプリであれば、バックグラウンドを選んでおくことで、後述の帯域の設定を業務通信に配慮した値にしておけます。逆に、ユーザーがポータル サイトから要求してその場で待っているようなアプリでは、フォアグラウンドのほうが体感は良くなります。「ユーザーが待っているか、待っていないか」 を基準に選んでいただくと、迷わず決められます。

配信の最適化の設定でできる工夫

ここからが、冒頭でご紹介した配信の最適化の出番です。「どこから取得するか」「どのくらいの帯域を使うか」は、この機能の設定で細かく調整でき、しかもその設定は Intune からそのまま配布できます。

配信の最適化は、コンテンツを次のような複数のソースから並行して取得できるように作られています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
flowchart TB
    subgraph CLOUD[" "]
        CDN["☁️ コンテンツ配信ネットワーク (CDN)<br/>いつでも利用できる取得元"]
    end

    subgraph LAN["🏢 拠点内のネットワーク"]
        direction TB
        PEER["💻 ほかのデバイス (ピア)<br/>ダウンロード済みのコンテンツを保持"]
        MCC["🟢 Microsoft Connected Cache<br/>（配置している場合のみ）"]
        DEV["💻 配布対象のデバイス<br/>🔶 配信の最適化"]
        PEER == "ピア共有" ==> DEV
        MCC -. "拠点内のキャッシュから" .-> DEV
    end

    CDN -- "インターネット経由で取得" --> DEV

    style CLOUD fill:transparent,stroke:transparent
    style LAN fill:#f3f3f3,stroke:#5f5f5f,stroke-width:2px
    style CDN fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style PEER fill:#eaf7ea,stroke:#107c10,stroke-width:2px
    style MCC fill:#ffffff,stroke:#107c10,stroke-width:2px,stroke-dasharray: 4 4
    style DEV fill:#eaf7ea,stroke:#107c10,stroke-width:2px

うれしいことに、この機能は既定で有効になっています。 Windows の既定のダウンロード モードは「同一 NAT 配下でのピア共有」となっており、同じ拠点にいるデバイス同士でコンテンツを分け合う動作が、特に設定をしなくても働くようになっています。

とはいえ、環境によっては既定のままでは十分に効果が出ないこともあります。ここからは、Intune から調整できる代表的なポイントをご紹介します。

設定は、Intune 管理センターの 設定カタログ から構成できます。

[デバイス] - [デバイスの管理] - [構成] - [作成] - [新しいポリシー] - プラットフォーム: Windows 10 以降 - プロファイルの種類: 設定カタログ

ポリシーの [構成設定] で [設定の追加] を選び、配信の最適化 の配下を確認すると、構成できる設定の一覧が表示されます。各設定の情報アイコン ⓘ からは説明を確認でき、[詳細情報] のリンクからその設定の公開情報を直接開けるのも便利なところです。

Intune の設定カタログでポリシーを作成し、「配信の最適化」カテゴリの設定一覧を表示した例

なお、[テンプレート] にも [配信の最適化] が用意されていますが、こちらも設定カタログと同じ設定形式へ置き換わっています。これから新しく作成される場合は、ほかの設定とまとめて管理しやすい設定カタログをご利用いただくのがおすすめです。

調整できる主なポイント

配信の最適化には多くの設定がありますが、ネットワーク負荷という観点でよく検討されるのは、次のようなものです (括弧内は CSP 名)。

  • ピア共有の範囲を広げる / 狭める

    • ダウンロード モード (DODownloadMode)
    • グループ ID とそのソース (DOGroupId / DOGroupIdSource)
    • ピアの選択を制限する条件 (DORestrictPeerSelectionBy)

  • 使用する帯域そのものを抑える

    • 最大ダウンロード帯域幅の絶対値 (DOMaxBackgroundDownloadBandwidth / DOMaxForegroundDownloadBandwidth) と割合 (DOPercentageMaxBackgroundBandwidth / DOPercentageMaxForegroundBandwidth)
    • 帯域幅を制限する時間帯 (DOSetHoursToLimitBackgroundDownloadBandwidth / DOSetHoursToLimitForegroundDownloadBandwidth)

  • ピアから取得できる機会を増やす

    • キャッシュの最大有効期間 (DOMaxCacheAge) ・ 最大サイズ (DOMaxCacheSize / DOAbsoluteMaxCacheSize)
    • ピア キャッシュの最小ファイル サイズ (DOMinFileSizeToCache)

  • ピアやキャッシュ サーバーを探す時間を確保する

    • HTTP からのダウンロードの遅延 (DODelayBackgroundDownloadFromHttp / DODelayForegroundDownloadFromHttp)
    • キャッシュ サーバーへのフォールバックの遅延 (DODelayCacheServerFallbackBackground / DODelayCacheServerFallbackForeground)

  • 拠点内のキャッシュ サーバーを使う

    • キャッシュ サーバーのホスト名 (DOCacheHost)
    • そのソース (DOCacheHostSource)

このうち 帯域に関する設定と、ピア・キャッシュ サーバーを待つ時間の設定は、バックグラウンド用とフォアグラウンド用がそれぞれ別の設定として用意されています。 設定の一覧で バックグラウンド フォアグラウンド という言葉が並んでいるのはこのためです。先ほどの割り当ての「配信の最適化の優先度」とセットで、どちらのモードで配信するアプリなのかを踏まえて、必要な側 (あるいは両方) を構成する ようにしてください。

ひとつ例を挙げると、先ほどの既定のダウンロード モード (同一 NAT 配下でのピア共有) では、同じ拠点であっても、インターネットへの出口 (パブリック IP アドレス) が分かれている環境では、デバイス同士がピアとして認識されない ことがあります。このようなケースでは、グループ ID を使ったダウンロード モードが選択肢になります。

どの設定をどう組み合わせるとよいかは、拠点のネットワーク構成やデバイスの台数によって変わってきます。Windows の公開情報には、ネットワーク トポロジーや組織の規模ごとの考え方と、推奨値の一覧 がまとめられていますので、具体的な値を検討される際は、まずはこちらをご覧いただくのが近道です。ネットワーク管理者の方と相談される際の材料としてもご活用いただけます。

なお、配信の最適化そのものの動作 (ピアとして選ばれる条件や、帯域制御の実際の挙動など) は Windows OS の機能によるもの です。そのため、配信の最適化自体の動作を掘り下げる場合は、Windows の観点での調査が必要となりますので、ご注意ください。

拠点内にキャッシュを置く ― Microsoft Connected Cache

ピア共有だけでは足りない、あるいは「もっと確実に拠点内で配信を完結させたい」という場合の選択肢が、Microsoft Connected Cache です。拠点内に置いたキャッシュ ノードが一度取得したコンテンツを保持し、2 台目以降のデバイスへは拠点内から配信する、という仕組みです。ピア共有との併用もできます。

Intune で管理しているデバイスから利用する場合は、配信の最適化の キャッシュ サーバーのホスト名 (DOCacheHost) の設定でキャッシュ ノードを指定します。この設定も、先ほどの設定カタログのポリシーから配布できます。キャッシュ ノードが利用できないときは CDN へフォールバックするため、「キャッシュ ノードが止まったらアプリが配布できなくなる」という心配は不要です。

小規模な拠点であれば Windows 11 のクライアント デバイスへ、大規模な拠点であればサーバーへと、規模に応じて展開できます。すでに Configuration Manager をご利用の場合は、既存の配布ポイント上で有効化する形も選べます。

おわりに

今回は、Intune から Win32 アプリを配布する際のネットワーク負荷を抑える方法について、割り当ての設定と配信の最適化の両面からご紹介しました。最後に、要点をまとめておきます。

  • Win32 アプリのコンテンツのダウンロードには Windows の配信の最適化 が使われており、その機能をそのまま活用できる
  • 割り当ての設定 では、グループを分けて段階的に割り当て、可用性の時刻をずらす ことでダウンロードのタイミングを分散できる
  • 配信の最適化の設定 では、ダウンロード モード・帯域幅・キャッシュ によって「どこから」「どのくらいの帯域で」取得するかを制御できる (帯域の上限は既定では設定されていないため、抑えたい場合は明示的な構成が必要)
  • 拠点内での配信を確実にしたい場合は、Microsoft Connected Cache も選択肢になる
  • そして何より、配布を始める前にネットワーク管理者の方と相談しておく こと

大きなアプリの一斉配布は、ちょっと身構えてしまう作業かもしれません。ですが、「いつ」「どのデバイスが」「どこから」コンテンツを取得するのかを整理して考えれば、打てる手は意外とたくさんあります。ぜひ、次の配布計画に取り入れてみてください。

次回以降も、みなさまの運用に役立つ情報をお届けしていきます。最後までお読みいただき、ありがとうございました。

]]> https://jpintune.github.io/blog/intune/20260904_01/ 2026-09-03T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

Intune はもともとモバイル デバイスの管理 (MDM) を出発点としたサービスですが、近年ではこれまでオンプレミスの仕組みで管理されてきた Windows デバイスを、Intune へ移行して運]]>

回線の逼迫を防ぐために。Intune から Win32 アプリを配布するときのネットワーク負荷を抑えるコツ 2026-11-02T00:39:51.238Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

日々 Intune を活用してデバイス管理を進めていただき、ありがとうございます。今回は、以前ご紹介した「Intune と Windows の役割分担」の iOS/iPadOS 版として、Intune を運用されている皆さまにぜひ知っておいていただきたい「Intune と iOS/iPadOS の役割分担」についてご紹介します。

一見すると地味なテーマに思えるかもしれませんが、この “境界” を理解しておくと、いざ問題が起きたときに「どこを確認すればよいか」がすぐに分かるようになり、原因の特定や解決までの時間を大きく短縮できます。運用のストレスを減らし、より快適に Intune をお使いいただくための第一歩として、ぜひ最後までお読みください。

はじめに ― なぜ「切り分け」が大切なのか

Intune の様々な機能は、その裏側で Apple が提供する MDM の仕組み (Apple の MDM プロトコルと APNs) と、iOS/iPadOS が持つ機能を利用して動作しています。そのため、何か想定通りに動かない事象が起きたとき、その原因が Intune 側にあるのか、それとも iOS/iPadOS (Apple) 側にあるのか をあらかじめ切り分けておくことがとても重要です。

事前に切り分けができていると、次のようなメリットがあります。

  • 確認すべきログや設定のポイントを最初から絞り込めるため、調査がスムーズに進む
  • ご自身での解決につながるケースも多く、待ち時間なく対処できる
  • 万一サポートへお問い合わせいただく場合でも、最初から的確な情報をもとに調査を開始できる

切り分けを進めるにあたって、あわせて確認しておくとよい点が 2 つあります。

1 つは、サポート契約とサポート範囲です。ここは Windows と大きく異なる、特にご注意いただきたいポイントです。

Windows の場合は OS そのものもマイクロソフトが提供しているため、事象が Windows 側にあると分かった場合でも、ご契約の内容によっては引き続きマイクロソフトのサポートでお受けできることがあります。

一方 iOS/iPadOS の場合、OS そのものはもちろん、Apple Business Manager (ABM) / Apple School Manager (ASM)、App Store、APNs (Apple Push Notification service) といった仕組みは、すべて Apple 社が提供するプラットフォームです。そのため、これらに起因する事象については、お客様から Apple 社へお問い合わせいただく必要が生じる場合があります。

たとえば、次のような事象は Apple 社へのお問い合わせが必要となる場合があります。

  • 設定がデバイスに正しく届いているにもかかわらず、iOS/iPadOS 側で期待どおりに動作しない
  • ABM / ASM 上でのデバイスの登録状況や、MDM サーバーへの割り当てに関する問題
  • App Store や VPP (Apps and Books) でのアプリ・ライセンスの購入に関する問題
  • 特定の iOS/iPadOS バージョンへのアップデート後にのみ発生する事象

問題が Apple 側にあると分かってから窓口を探し始めると、その分だけ解決までの時間が延びてしまいます。Apple 社側のお問い合わせ窓口と、ご利用中のサポート契約の内容を、あらかじめ把握しておくことをおすすめします。私もこの仕事を始めるまでは、あまり意識したことはなかったのですが、エンタープライズ環境でモバイル デバイスを利用する場合は、エンタープライズ向けのサポート契約を持っていないと、スムーズに問題が解決出来ない場合があります。これは iOS/iPadOS では見落としがちな準備事項です。

もう 1 つは、ライセンスに関するお問い合わせの窓口です。ライセンスに関するご相談は技術サポートではお受けできませんので、担当の営業担当者やライセンスの購入元へお問い合わせください。

iOS/iPadOS における MDM 管理の仕組み

まずは、Intune がどのように iOS/iPadOS デバイスを管理しているのか、その全体像を押さえておきましょう。

ここで Windows との一番大きな違いをお伝えしておきます。Windows には Intune Management Extension という Intune 専用のエージェントが存在し、Win32 アプリや PowerShell スクリプトを配布・実行できますが、iOS/iPadOS にはこれに相当する Intune 専用エージェントは存在しません。iOS/iPadOS の管理は、Apple が定めた MDM プロトコルの範囲内 で行われます。

つまり、iOS/iPadOS における Intune の役割は「Apple の MDM プロトコルで定められたコマンドや設定 (ペイロード) をデバイスに届けること」であり、それを受け取って実際に反映・動作させるのは iOS/iPadOS 側、という整理になります。

なお、この Apple の MDM の仕組みそのものについては、Apple 社が「Apple プラットフォーム導入」というガイドで日本語の公開情報を提供しています。デバイスの登録の流れ、構成プロファイルとペイロード、監視対象 (Supervised) といった基本的な考え方が分かりやすくまとまっていますので、あわせてご一読いただくと本記事の内容もより理解しやすくなります。

それでは、Intune と iOS/iPadOS がそれぞれカバーする範囲を、順番に図で見ていきましょう。

パターン 1：構成プロファイル (設定) の配布

1 つ目は、構成プロファイルなどで設定を配布するパターンです。

Intune はまず Apple の APNs (Apple Push Notification service) を経由して「サーバーにチェックインしてください」という通知だけをデバイスに送ります。その通知を受け取ったデバイス側の MDM クライアントが Intune へ接続 (チェックイン) し、その応答として設定 (ペイロード) を受け取る、という流れです。つまり Intune がデバイスへ一方的に設定を押し込んでいるのではなく、デバイスからの接続がなければ設定は渡せない、という点がポイントになります。受け取った設定を実際に反映・動作させるのは、iOS/iPadOS に標準で組み込まれている MDM クライアントと各 OS 機能です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
sequenceDiagram
    autonumber
    participant INTUNE as ☁️ Microsoft Intune
    box rgb(234,247,234) 🍎 Apple が提供する仕組み
    participant APNS as ☁️ Apple APNs
    participant MDM as 🔶 MDM クライアント<br/>(iOS/iPadOS に組み込み)
    participant OS as 🔶 iOS/iPadOS の各機能
    end

    INTUNE->>APNS: チェックインを促す通知を依頼
    APNS->>MDM: プッシュ通知
    MDM->>INTUNE: チェックイン (デバイスから接続)
    INTUNE-->>MDM: 応答として設定 (ペイロード) を返す
    MDM->>OS: 設定を反映
    MDM->>INTUNE: 適用結果を返却

図の緑色の枠で囲まれた部分は、Apple が提供する仕組みが担当する範囲です。Intune が直接関与できるのは、①の通知の依頼と、③のチェックインを受けて④で応答を返すところまで、という点をイメージしていただくと分かりやすいかと思います。

つまり、Intune は設定を届ける役割であり、その設定が適用された後にどう振る舞うかは iOS/iPadOS 側が担当している、というのが基本的な考え方です。「設定が届くまで」が Intune、「届いた設定の動作」が iOS/iPadOS という線引きになります。

なお、APNs を経由するという仕組み上、デバイスが APNs と通信できない環境では、設定の配信が遅延したり届かなかったりします。社内ネットワークでのフィルタリングを行っている場合は、Apple の公開情報を参照のうえ、APNs 向けの通信が許可されているかもあわせてご確認ください。

パターン 2：アプリの配布

2 つ目は、アプリを配布するパターンです。この場合も基本的な考え方は同じで、Intune が担当するのは 「このアプリをインストールしてください」というコマンドをデバイスへ届けるところまで です。

実際のアプリのダウンロードとインストールは、App Store (Apple Business Manager で購入したアプリの場合はそのライセンス) と iOS/iPadOS が担当します。そして、インストールされたアプリが起動した後の動作は、そのアプリ自身が担います。

こちらもパターン 1 と同じく、デバイス側の MDM クライアントからのチェックインに対する応答として、インストール コマンドが渡されるという流れになります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
sequenceDiagram
    autonumber
    participant INTUNE as ☁️ Microsoft Intune
    box rgb(234,247,234) 🍎 Apple が提供する仕組み
    participant APNS as ☁️ Apple APNs
    participant MDM as 🔶 MDM クライアント<br/>(iOS/iPadOS に組み込み)
    participant STORE as 🔶 App Store /<br/>iOS のインストール処理
    end
    participant APP as 🔷 アプリ<br/>(インストール後の動作)

    INTUNE->>APNS: チェックインを促す通知を依頼
    APNS->>MDM: プッシュ通知
    MDM->>INTUNE: チェックイン (デバイスから接続)
    INTUNE-->>MDM: 応答としてインストール コマンドを返す
    MDM->>STORE: アプリのインストールを指示
    STORE->>APP: インストール・起動
    MDM->>INTUNE: 結果を返却

こちらの図では、緑色の枠の中が Apple が提供する仕組み、その右側にあるアプリはアプリ提供元の担当範囲になります。

アプリがインストールされた後の処理は、それぞれのアプリ自身が担います。そのため、アプリの動作で問題が起きた場合は、アプリ側の情報の確認が必要になります。特にサードパーティー製のアプリをご利用の場合は、問題発生時に備えて 提供元のサポート窓口 をあらかじめ確認しておくことをおすすめします。

なお、本記事では主に構成プロファイル (設定) の配布に焦点を当てて解説します。

補足：iOS/iPadOS では「できること」が Apple の仕様で決まっています

Windows では、CSP に用意されていない設定でも PowerShell スクリプトや Win32 アプリを配布することで柔軟に対応できる場合があります。一方 iOS/iPadOS では、Apple の MDM プロトコルに任意のコードを実行させる仕組みがない ため、そうした回避策は基本的に利用できません。

そのため iOS/iPadOS では、「Apple の MDM プロトコルで提供されている機能しか実現できない」 という点が大前提になります。「この設定を Intune から配布できないか」というご要望をいただくことがありますが、そもそも Apple 側にその仕組みが用意されていない場合は、残念ながら Intune からも実現することが難しいです。

一見すると制約に思えるかもしれませんが、切り分けの観点では非常に分かりやすい線引きとも言えます。

なお、Intune の管理センターの画面上に設定項目が見当たらない場合でも、カスタム プロファイル を使えば、Apple Configurator などで作成した構成プロファイル (.mobileconfig ファイル) をインポートして配布できます。ただしこれも配布できるのは Apple が用意しているペイロードのみで、Apple がサポートしていない設定を新たに実現できるわけではない点はご留意ください。

そもそも Apple 側にその仕組みが用意されているのかを確認したい場合は、Apple 社が公開している下記のページが手がかりになります。構成プロファイルで指定できるペイロードが一覧化されており、ペイロード名と識別子、対応する OS、デバイス チャンネル／ユーザー チャンネルの別、利用可能な登録方法 まで確認できます。

なお、MDM で送信できるコマンドの一覧など、さらに細かな仕様を確認したい場合は、Apple 社の開発者向けドキュメント (英語) もあわせてご参照ください。

設定が Intune から配布されているかを確認する方法

「設定が思ったように反映されない」というとき、まず確認したいのが Intune からの設定配布自体が完了しているかどうか です。ここが確認できると、問題が「配布まで」なのか「配布後の動作」なのかを切り分けられます。確認方法は大きく 2 つあります。

1. Intune 管理センターからの確認方法

設定が Intune から配布されているかは、基本的に Intune 管理センターの下記の画面から確認できます。「成功」と表示されている構成プロファイルについては、Intune からの設定の配信自体は完了していると判断できます。

[デバイス] - [すべてのデバイス] - [<確認対象のデバイス>] - [デバイスの構成]

デバイスごとの構成プロファイルの配信状況一覧画面

対象のプロファイルを選択すると、各設定の配信状況をより細かく確認できます。

[デバイス] - [すべてのデバイス] - [<確認対象のデバイス>] - [デバイスの構成] - [<確認対象の構成プロファイル>]

構成プロファイルを選択した際の設定ごとの配信状況画面

同様に、コンプライアンス ポリシーについても下記の画面から確認できます。

[デバイス] - [すべてのデバイス] - [<確認対象のデバイス>] - [デバイスのポリシー準拠]

デバイスごとのコンプライアンス ポリシーの準拠状況一覧画面

[デバイス] - [すべてのデバイス] - [<確認対象のデバイス>] - [デバイスのポリシー準拠] - [<確認対象のコンプライアンス ポリシー>]

コンプライアンス ポリシーを選択した際の設定ごとの準拠状況画面

また、構成プロファイルの配信が想定通りに進まない場合には、[デバイス] - [すべてのデバイス] から「最後のチェックイン」の時刻を確認し、Intune とデバイスの同期が実際に行われているかを確認することも大切です。同期が行われていなければ、そもそも設定が届いていない可能性があります。

デバイス一覧の「最後のチェックイン」列で同期状況を確認する画面

ここで 1 点、iOS/iPadOS ならではの注意点があります。前述のとおり Intune は APNs 経由でチェックインを促すことしかできないため、デバイスが機内モードであったり、電源が入っていないなどの理由でチェックインが行われなければ、いつまでも配信が完了しません。想定通りに配信が進まない場合は、まずデバイス側の状態をご確認ください。

補足：NotNow ―「失敗」ではなく「今はできない」

iOS/iPadOS のデバイスにおいて、Intune 管理センター上から「成功」の状態が確認出来ない時、よくあるのが NotNow と呼ばれる応答がデバイスから返されているパターンです。
Apple の MDM プロトコルでは、デバイスがコマンドを受け取っても実行できない状態のとき、NotNow というステータスを返し、後で改めて同期する際にコマンドが再実行されます。公開情報では「デバイスはコマンドを受け取りましたが、現時点ではコマンドに従うことはできません。デバイスは後でサーバーを再度ポーリングします。」と説明されており、エラーではなく一時的な “保留” の返答 です。Apple 社の公開情報でも、デバイスの起動後に一度もロックが解除されていない場合など、特定の条件下ではコマンドが実行されず、後で再試行すれば成功する可能性があることを示すために NotNow が返されると説明されています。

これは主に、デバイスの電源は入っているがロックが解除されていない場合や、アプリや OS のアップデートをインストール中の場合に発生します。このとき Intune 管理センターでは、なかなか「成功」に変わらなかったり、2016341112 -iOS デバイスは現在ビジー状態です というエラーが表示されたりします。iOS プラットフォームの機能であり、Intune に固有の問題ではありません。 設定を作り直す前に、まずはしばらく待ってみることでエラーが解消されることも多いです。

2. iOS/iPadOS デバイス上での確認方法

Intune 管理センターからだけでなく、デバイス上からも確認できます。Windows のレジストリのように配信された設定の “値” をすべて確認できるわけではありませんが、どのようなペイロード (機能制限、証明書、Wi-Fi、VPN など) が届いているか を下記の画面から確認できます。

[設定] - [一般] - [VPN とデバイス管理] - [Management Profile]

iOS/iPadOS デバイス上で管理プロファイルの内容を確認する画面

プロファイルの種類や設定の内容によっても確認箇所は異なる場合があるのですが、一般的な構成プロファイルで配信した設定は下記の画面から確認出来るはずです。

[設定] - [一般] - [VPN とデバイス管理] - [Management Profile] - [機能制限]

管理プロファイルの「機能制限」で配信された設定を確認する画面

ここに該当する項目が表示されていれば、Intune からの設定の配信自体は正常に行われていると判断できます。逆に、Intune 管理センター上は「成功」となっているのにデバイス上の管理プロファイルに該当のペイロードが見当たらない場合は、配信のタイミングやデバイスの状態を疑う手がかりになります。

「これは Intune？ それとも iOS/iPadOS？」― 事象別の考え方

ここまでの内容を踏まえて、実際にどのような事象がどちら側の調査対象になるのかを整理してみましょう。基本的な考え方はシンプルです。

  • Intune からの設定やコマンドの “配信” に関すること → Intune の観点から確認
  • 設定自体の “挙動” や、配布後の “動作” に関すること → iOS/iPadOS の観点から確認

以下に具体的な例を挙げます。ご自身で事象を切り分ける際の参考にしてください。

Intune 側に焦点を当てて確認するとよい事象

  • 構成プロファイルの割り当てをフィルターで行っているが、意図したデバイスが配信対象とならず適用外になってしまう
  • デバイス上の管理プロファイルには設定が届いているものの、Intune 管理センター上では構成プロファイルの配信状況が確認できない
  • デバイスは正常にチェックインしているのに、特定のプロファイルだけが割り当てられていない

iOS/iPadOS 側に焦点を当てて確認するとよい事象

  • Intune 管理センター上ではプロファイルの配信が「成功」と表示され、デバイス上の管理プロファイルにも設定が届いているのに、期待した動作が iOS/iPadOS 側で得られない
  • Intune 管理センター上に 2016341112 -iOS デバイスは現在ビジー状態です のようなエラーが表示され続ける (前述の NotNow の補足をご参照ください)
  • ソフトウェア更新のポリシーを配信したが、Apple 側の更新プログラムの提供状況により、実際のアップデートが開始されない

なお、冒頭でも触れたとおり、こちらに分類される事象は Apple 社が提供するプラットフォーム側の領域となるため、Apple 社へのお問い合わせが必要となることがあります。

ポイントは、「設定やコマンドがデバイスに届いているか」までが Intune の動作、「届いた設定やコマンドがどう動くか」からが iOS/iPadOS の動作 ということです。この線引きを意識するだけで、確認すべき方向が明確になります。

おわりに

今回は、Intune と iOS/iPadOS の “境界” という視点から、デバイス管理のトラブルシューティングを進めるうえでの基本的な考え方をご紹介しました。

  • Intune は「設定やコマンドを APNs 経由で届ける」役割、iOS/iPadOS は「届いた設定やコマンドを動作させる」役割
  • iOS/iPadOS には Intune 専用エージェントが存在せず、実現できることは Apple の MDM プロトコルの範囲内に限られる
  • 「設定が届いているか」は Intune 管理センターとデバイス上の管理プロファイルから確認できる
  • 事象が「配信まで」なのか「配信後の動作」なのかで、確認すべき方向が変わる
  • Apple 側の領域と判明した事象は Apple 社へのお問い合わせが必要となるため、窓口とサポート契約を事前に把握しておく

この考え方を身につけていただくと、問題が起きたときに落ち着いて原因を切り分けられるようになり、より快適に Intune をご活用いただけるはずです。ぜひ日々の運用に取り入れてみてください。

次回以降も、皆さまの運用に役立つ情報をお届けしていきます。最後までお読みいただき、ありがとうございました。

]]> https://jpintune.github.io/blog/intune/20260831_01/ 2026-08-30T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

日々 Intune を活用してデバイス管理を進めていただき、ありがとうございます。今回は、以前ご紹介した「Intune と Windows の役割分担」の iOS/iPadOS 版として、I]]>

Intune のトラブル解決が早くなる。知っておきたい iOS/iPadOS との "役割分担" - 基本編 2026-11-02T00:39:51.236Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

Intune も年々進化を続けており、Windows Update に関連するポリシーもずいぶんと種類が増えてきました。「更新リング」「設定カタログ」「機能更新プログラム ポリシー」「品質更新プログラム ポリシー」…と管理センターに並ぶ選択肢を前にして、「結局、どのポリシーを使えばよいの？」 と迷われた経験はないでしょうか。

実はこれらのポリシーは、それぞれ想定している用途や、内部的な仕組みが少しずつ異なっています。逆に言えば、それぞれの役割と裏側の仕組みを押さえておけば、ご自身の運用に合ったポリシーを自信を持って選べるようになります。設定が思ったように反映されない、期待した更新プログラムが降ってこない、といったモヤモヤの多くも、この理解があるだけでスッと解消できることが少なくありません。

そこで今回は、Intune で Windows Update を管理する際の各ポリシーについて、どのような目的で使うものなのか、そしてどう使い分けるとよいのかを、ひと通りご紹介していきます。

はじめに ― 押さえておきたい 3 つの前提

具体的な各ポリシーの説明に入る前に、知っておいていただくと理解が進む前提を、いくつかご紹介します。

① Intune は Windows Update の “配信基盤” を持っているわけではない

まず一つ目、これが最も大切なポイントかもしれません。それは、Intune 自体は Windows Update 専用の配信基盤や仕組みを持っているわけではない、という点です。

Intune で Windows Update の設定を管理することはできますが、更新プログラムの適用の動作や、更新プログラムそのものの配信基盤は、通常の Windows OS とまったく同じ仕組みが用いられています。Intune が独自の Windows Update 管理エージェントを常駐させていたり、更新プログラムを配信するための専用のサイトを持っていたり、というわけではないのです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
flowchart TB
    subgraph CLOUD[" "]
        INTUNE["☁️ Microsoft Intune<br/>Windows Update の設定を管理"]
        WU["☁️ Windows Update<br/>更新プログラムの配信基盤"]
    end

    subgraph DEVICE["💻 デバイス上で動作"]
        direction TB
        CSP["🔶 CSP<br/>(Configuration Service Provider)"]
        WUCLIENT["🔶 Windows OS の機能<br/>（Windows Update クライアント）"]
        CSP == "設定を反映" ==> WUCLIENT
    end

    INTUNE -- "設定を配布" --> CSP
    WUCLIENT -- "更新プログラムを取得" --> WU

    style CLOUD fill:transparent,stroke:transparent
    style DEVICE fill:#f3f3f3,stroke:#5f5f5f,stroke-width:2px
    style INTUNE fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style WU fill:#eaf7ea,stroke:#107c10,stroke-width:2px
    style CSP fill:#eaf7ea,stroke:#107c10,stroke-width:2px
    style WUCLIENT fill:#eaf7ea,stroke:#107c10,stroke-width:2px

つまり Intune が担当するのは「どのように更新するか、という設定をデバイスに届けるところまで」であり、実際に更新プログラムをダウンロードして適用するのは Windows OS 側の役目、という役割分担になっています。この視点は、Intune と Windows の “役割分担” として下記の記事でもご紹介していますので、あわせてご覧いただくとより理解が深まります。

この役割分担が頭に入っていると、「更新プログラムが適用されない」という事象に出会ったときにも、設定が正しく配布されているかを確認するフェーズと、配布された設定に沿って Windows Update が動作しているかを確認するフェーズとを分けて考えられるようになり、切り分けが一気にスムーズになります。

② ポリシーは大きく 2 種類に分けられる

二つ目のポイントです。Intune で Windows Update を設定できる主なプロファイルはいくつもありますが、内部的な仕組みで整理すると、実は次の 2 種類に分けられます。

  • Windows Update クライアント ポリシー (CSP) によって管理される設定

    • 更新リング
    • 設定カタログ

  • クラウド上の Windows Autopatch によって管理される設定

    • 機能更新プログラム ポリシー
    • 品質更新プログラム ポリシー
    • 品質更新プログラムの迅速化 (Expedite) ポリシー
    • ドライバー更新プログラム ポリシー

このどちらに属するポリシーなのかを意識しておくと、設定の確認方法や、反映されるまでの考え方が整理しやすくなります。順に見ていきましょう。

Windows Update クライアント ポリシー (CSP) によって管理される設定

こちらは、これまでオンプレミスでグループ ポリシーを使って Windows Update を管理されてきたお客様には、比較的馴染みやすい仕組みです。

Intune は、グループ ポリシーに相当する CSP (Configuration Service Provider) と呼ばれる設定をデバイスへ配信します。デバイス上に設定が反映された後は、Windows OS がその設定に沿って Windows Update を実施する、というシンプルな流れになります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
flowchart TB
    subgraph CLOUD[" "]
        INTUNE["☁️ Microsoft Intune<br/>CSP で設定を配布"]
    end

    subgraph DEVICE["💻 デバイス上で動作"]
        direction TB
        CSP["🔶 CSP <br/>(Configuration service provider)"]
        OSFUNC["🔶 Windows OS の機能<br/>（Windows Update）"]
        CSP == "反映" ==> OSFUNC
    end

    INTUNE -- "配布" --> CSP

    style CLOUD fill:transparent,stroke:transparent
    style DEVICE fill:#f3f3f3,stroke:#5f5f5f,stroke-width:2px
    style INTUNE fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style CSP fill:#eaf7ea,stroke:#107c10,stroke-width:2px
    style OSFUNC fill:#eaf7ea,stroke:#107c10,stroke-width:2px

設定はデバイス上のレジストリに反映されるため、「意図した設定が本当にデバイスへ届いているか」を、デバイス上で直接確認できるのが大きな特徴です。

クラウド上の Windows Autopatch によって管理される設定

一方、こちらは従来の管理の仕組みとは少し毛色が異なります。特に、これまでオンプレミスでデバイスを管理されてきたお客様にとっては、最初は少し捉えにくいかもしれません。

この仕組みでは、設定がデバイス上に直接反映されるわけではありません。Intune で作成したポリシーの内容は、まずクラウド上の別のサービスである Windows Autopatch (以前は Windows Update for Business deployment service と呼ばれていました) に反映されます。そして、デバイスが Windows Update に更新プログラムを問い合わせた際に、Windows Autopatch 側で保持している設定に沿って更新プログラムが提供される、という流れになります。

Windows Autopatch を介した更新プログラム配信の流れ

ここで押さえておきたいのが、クラウド側での制御になるため、これまでのようにデバイス上のレジストリから設定の反映状況を確認できない場合が多い、という点です。「設定したはずなのに、デバイス上のレジストリに何も書かれていない」と驚かれることがありますが、こうした仕組みによるものですのでご安心ください。

逆に言えば、従来どおりレジストリで反映状況を確実に確認したいというご要望がある場合には、後ほどご紹介するように、CSP によって管理する設定を選ぶ、という方針を取ることもできます。どちらが優れているかではなく、運用スタイルに合った方を選んでいただくのも一つの手法です。

補足: Windows Autopatch について

本記事では Windows Autopatch そのものについては深くは触れません。ただ、Windows Autopatch も内部的には更新リングをはじめとする Intune の機能に依存している部分が多いため、Windows Autopatch をご利用のお客様にとっても、本記事の内容は参考にしていただけるかと思います。

なお、Windows Autopatch は、現時点 (2026 年 8 月現在) では日本語でのサポート サービスは提供されておらず、お問い合わせは英語もしくは機械翻訳での対応となります、ご注意ください。

③ 割り当ては「デバイス グループ」が基本

三つ目は、割り当て先のグループについてです。

「機能更新プログラム ポリシー」「品質更新プログラム ポリシー」以外のポリシーについては、ユーザー グループへ割り当てること自体は可能です。しかし、Windows Update はそもそもデバイス単位で実行されるものですので、多くの場合はデバイス グループへ割り当てていただいた方が、意図した効果を得やすくなります。

ユーザー グループに割り当てた場合、ユーザーがサインインするまで設定が適用されなかったり、共有デバイスなどで意図しない動作につながってしまう可能性があります。特別な理由がない限りは、デバイス グループへの割り当てをご検討ください。

各ポリシーの紹介

それでは、ここからは各ポリシーについて具体的に見ていきましょう。

更新リング

更新リングは、Windows Update の設定を行う際に一般的に利用する CSP を、まとめて管理できるプロファイルです。配信される具体的な設定の一覧については、下記の公開情報でご紹介しています。

更新リングでは、これらの設定に加えて、更新プログラムの一時停止といった機能も備えています。「Intune で Windows Update の構成を管理するなら、まずはこれ！」 という基本のプロファイルとお考えいただくとよいでしょう。

そもそも「リング」とは？

ちなみに「リング」という概念自体は Intune 独自のものではなく、Windows Update において提唱されている考え方です。具体的なイメージは、下記の公開情報の図が分かりやすいかと思います。

Windows Update のリングの考え方を示す図

Windows 10 以降、OS の更新プログラムは累積形式で提供されるようになりました。そのため、個別の更新プログラムを一つひとつ選んで配信を制御するというより、デバイスを「リング」という単位にグループ化し、更新プログラムを適用するタイミングをずらしていく、という考え方が基本になります。

たとえば、まずは検証用のリングで少数のデバイスに早めに適用して問題がないことを確認し、その後、一般ユーザー向けのリング、最後に業務影響の大きい重要な部門のリング、といった具合に段階的に展開していきます。こうすることで、万が一問題が生じた場合でも影響範囲を最小限に抑えつつ、全社的にはきちんと更新プログラムを適用していくことができます。

Intune の更新リングも、こうした Windows Update の考え方に沿って構成を管理できるように用意されているポリシーです。ですので、まずは「どのようなリング構成にするか」を設計し、それを更新リングのポリシーとして表現していく、という進め方をしていただくと、無理なく運用に乗せていくことができます。

設定カタログ

設定カタログでは、更新リングのプロファイルには用意されていない CSP についても、個別に配信することができます。具体的には、設定カタログの [Windows Update for Business] 配下にある設定が、主な Windows Update 関連の設定となります。

設定カタログの Windows Update for Business カテゴリの設定一覧

更新リングだけでは設定が不足する場合に、更新リングを補う形で設定カタログを併用する、という使い方が一般的です。

Windows Update 関連で OS 側に用意されている CSP については、下記の公開情報でご紹介していますので、こちらもぜひ参考にしてみてください。

なお、あるグループ ポリシーに対応する Intune の設定を探す方法については、下記の記事でご紹介しています。「オンプレミスで設定していたあの項目を Intune でも設定したい」という場合には、こちらもあわせてご覧ください。

機能更新プログラム ポリシー

機能更新プログラム ポリシーを利用することで、Windows OS に特定のバージョンの機能更新プログラムを配信したり、特定のバージョンより先にアップグレードが行われないよう制御したりすることが可能です。

更新リングの設定でも「機能更新プログラムが配信されるまでの日数」を指定することはできますが、これはあくまで適用を先延ばしにする設定であり、期間が過ぎれば新しいバージョンが提供されます。特定のバージョンに固定し続けたいという場合には、機能更新プログラム ポリシーをご利用ください。

機能更新プログラム ポリシーを使わずに Windows OS のバージョンを制御できる？

記事の冒頭でご紹介したとおり、機能更新プログラム ポリシーは内部的にはクラウド上の Autopatch で設定が管理されます。そのため、これまでグループ ポリシーや CSP を利用して管理されてきたお客様にとっては、デバイス上のレジストリから設定内容を確認できないなど、従来とは勝手が異なる部分が出てきます。

「これまでどおり、レジストリで反映状況を確実に確認しながら運用したい」ということであれば、設定カタログから下記の CSP を配信することでも、バージョンの管理は可能です。従来に近い管理の仕方を続けたい場合には、機能更新プログラム ポリシーではなく、設定カタログでこれらの設定を配信することを検討してみてもよいでしょう。

設定カタログでターゲット リリース バージョンと製品バージョンを設定する画面

品質更新プログラム ポリシー

品質更新プログラム ポリシーは、ホットパッチを有効にするためのポリシーです。

ホットパッチは、再起動を伴わずに品質更新プログラムを適用できる仕組みで、ユーザーの再起動の頻度を減らしつつ、セキュリティ更新を適用していくことができます。名前から「品質更新プログラム全般を管理するポリシー」と受け取られることがありますが、用途はホットパッチの有効化ですので、その点はご注意ください。

利用にあたっては、対象となる Windows のエディションやバージョン、プロセッサ アーキテクチャなどの前提条件がありますので、下記の公開情報をご確認のうえでご検討ください。

なお、ホットパッチについて、品質更新プログラム ポリシーを利用しなくとも、現在は Autopatch のテナント設定で、テナント全体で既定で有効にすることも可能となっています。

品質更新プログラムの迅速化 (Expedite) ポリシー

品質更新プログラムの迅速化 (Expedite) ポリシーは、これまでのポリシーとは少し異なる使い方を想定しており、緊急で新しい品質更新プログラムを配信する必要がある場合に利用するポリシーです。

たとえば、通常は更新リングで「リリースから数日経過してから配信する」という運用にしているものの、今月のセキュリティ更新は緊急性が高いため、待たずに適用したい、といった状況で活躍します。

ここで一点、押さえておきたいのが、このポリシーは「特定のバージョンに固定する」ためのものではないという点です。機能更新プログラム ポリシーと混同されやすいのですが、あくまで適用を前倒しするための、スポット的に利用するポリシーとお考えください。緊急対応が終わった後は、通常どおり更新リングの設定に沿った運用に戻ります。

ドライバー更新プログラム ポリシー

ドライバー更新プログラム ポリシーでは、Windows Update から提供されるドライバーを自動または手動で承認し、どのドライバーを配信するかを選択することができます。

正直に申し上げますと、これはかなり上級者向けの機能です。ドライバーの管理については OEM ごとに独自の管理ツールが用意されていることも多く、「これが正解」と一概に言える手法がないのが現状です。

また、下記の公開情報の Note でも触れられているとおり、このポリシーでは OEM が定義したコンピューター ハードウェア ID (CHID) によるターゲット設定が考慮されません。そのため、OEM がそのモデル向けに想定しているものとは異なる、より新しいドライバーが配信される可能性があります。

Note
Windows ドライバー更新ポリシーでは、OEM によって定義されたコンピューター ハードウェア ID (CHID) ターゲット設定は適用されません。これらのドライバーが推奨どおりに表示されている場合でも、その結果、マネージド デバイスは、CHID ターゲット ドライバーではなく、新しい推奨ドライバー バージョンを受け取ることができます。

一方で、単純に Windows Update からのドライバー配信を止めたい、もしくは Windows Update に公開された最新のドライバーをそのまま適用したいということであれば、更新リングの [Windows ドライバー] の設定で制御することが可能です。

個々のドライバーを深く理解したうえで、隅から隅まで管理を行いたい、という明確なご要望がない限りは、更新リングの設定で十分なケースも多いかと思います。まずは更新リングでの制御から始めていただくというのも一つの方法です。

まとめ ― ポリシーの使い分け早見表

最後に、ここまでの内容を表に整理しておきます。

ポリシー主な用途管理される場所
更新リングWindows Update の基本的な構成 (延期日数、再起動、一時停止、アンインストールなど)デバイス (CSP)
設定カタログCSP を選択して配信デバイス (CSP)
機能更新プログラム ポリシーOS バージョンの固定・段階的なアップグレードクラウド (Autopatch)
品質更新プログラム ポリシーホットパッチの有効化クラウド (Autopatch)
品質更新プログラムの迅速化 (Expedite)緊急時に品質更新プログラムを前倒しで適用クラウド (Autopatch)
ドライバー更新プログラム ポリシードライバーの承認・配信制御クラウド (Autopatch)

まずは 更新リングで全体の土台を作り、足りない設定があれば設定カタログで補う。そのうえで、OS バージョンの固定が必要なら機能更新プログラム ポリシー、緊急対応が必要なら迅速化ポリシー、というように、目的に応じて必要なものを足していくという進め方をしていただくと、構成がシンプルに保たれ、運用も安定しやすくなります。

Windows Update の管理は、デバイスを安全に保つうえで欠かせない、とても大切な運用です。本記事が、皆さまが自信を持ってポリシーを選び、快適に運用を進めていただくための一助となれば幸いです。

それでは、また次回の記事でお会いしましょう。

]]> https://jpintune.github.io/blog/intune/20260821_01/ 2026-08-20T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

Intune も年々進化を続けており、Windows Update に関連するポリシーもずいぶんと種類が増えてきました。「更新リング」「設定カタログ」「機能更新プログラム ポリシー」「品質更新プログラ]]>

Intune で Windows Update を管理するポリシーの使い分け 2026-11-02T00:39:51.233Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

以前の記事では、Intune と Windows の “役割分担” という視点から、設定 (CSP) の配布を例にトラブルシューティングの基本的な考え方をご紹介しました。今回はその Win32 アプリ編として、Intune から Win32 アプリを配布した “後” に、どこをどう確認していけばよいか を掘り下げてご紹介します。

なお、配布を始める “前” に押さえておきたいポイントについては、下記の記事にまとめています。あわせてご覧いただくと、より効果的に運用いただけます。

上記の記事でも紹介している通り、配布後の切り分けに入る前に、まずは Intune が実際にインストール コマンドを実行するのと同じ条件で動作を確認しておく ことで、多くの問題は未然に防げます。システム コンテキスト / ユーザー コンテキストのどちらで実行されるか、32 ビット / 64 ビットのどちらのプロセスになるか。この条件がずれていると、手元では成功するのに Intune から配布すると失敗する、といったすれ違いが起きてしまいます。システム コンテキストで確認したい場合に便利な PsExec の使い方も上記の記事でご紹介していますので、本記事を読み進める前に、ご自身のアプリがどちらの条件で実行されるのかを把握しておくとスムーズです。

はじめに ― どこまで調べるかを決めておく

トラブルシューティングを始める前に、ぜひ一度立ち止まって考えていただきたいことがあります。それは、どの程度の規模の問題に対して、詳細な調査を行うか をあらかじめ決めておく、という点です。

Win32 アプリの配布では、クライアントごとに少しずつ環境が異なることから、一部のデバイスでのみ問題が発生することがあります。ログ調査は相応の時間と手間がかかるため、ごく少数のデバイスで起きる事象に対して、いきなり本格的な調査に踏み込むのは必ずしも得策ではありません。

小規模な事象であれば、次のような対処で解決してしまうことも少なくありません。

  • 対象のデバイス上で、アプリのインストーラーを手動で実行してみる
  • 「必須」として割り当てているアプリであれば、24 時間に一度リトライが行われるため、少し時間を置いて状況を確認する

Intune はクライアント デバイスを管理するという性質上、どうしても管理対象の台数が多くなります。だからこそ「そもそも細かくトラブルシューティングを行うべき事象なのか」という視点を持っておくと、運用全体の負荷をぐっと抑えられます。

なぜ「切り分け」が大切なのか

そのうえで、実際に調査が必要となった場合に大きな武器になるのが「切り分け」です。

Win32 アプリの配布は、Intune だけで完結しているわけではありません。Intune はアプリを 「デバイスに届けて、インストール コマンドを起動する」 ところまでを担当し、そこから先の実際のインストール処理は、アプリのインストーラー自身 にバトンタッチされます。

この役割分担を理解しておくと、次のようなメリットがあります。

  • 確認すべきログやポイントを最初から絞り込めるため、調査がスムーズに進む
  • 原因がアプリ側にあると早い段階で分かれば、アプリの提供元へ的確に相談できる
  • ご自身で解決できるケースも多く、待ち時間なく対処できる

「Intune の問題なのか、それともアプリのインストーラーの問題なのか」。この一点を見極められるようになるだけで、解決までの時間は大きく変わってきます。

Win32 アプリの配布の仕組み

まずは全体像を押さえておきましょう。Intune から Win32 アプリを配布したときの流れは、次の図のようになります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
flowchart TB
    subgraph CLOUD[" "]
        INTUNE["☁️ Microsoft Intune<br/>Win32 アプリ・スクリプトの配布"]
    end

    subgraph DEVICE["💻 デバイス上で動作"]
        direction TB
        IME["🔷 Intune の機能<br/>（配布・起動まで）<br/>Intune Management Extension"]
        APPS["🔶 アプリ・スクリプト側<br/>（起動後の動作）<br/>Win32 アプリ / PowerShell スクリプト"]
        IME == "起動" ==> APPS
    end

    INTUNE -- "配布" --> IME

    style CLOUD fill:transparent,stroke:transparent
    style DEVICE fill:#f3f3f3,stroke:#5f5f5f,stroke-width:2px
    style INTUNE fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style IME fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style APPS fill:#eaf7ea,stroke:#107c10,stroke-width:2px

Intune がクラウドからアプリのコンテンツと設定を配布し、デバイス上の Intune Management Extension (以下、IME) がそれを受け取ってインストール コマンドを起動します。そして、起動された後のインストール処理そのものは、アプリのインストーラー側の担当範囲です。

この IME は、Win32 アプリや PowerShell スクリプトの配布を担う Intune 専用のエージェントで、対象のデバイスへ自動的にインストールされます。インストールされる条件や前提となる要件については、下記の公開情報にまとめられていますので、一度目を通しておくと切り分けの際に役立ちます。

したがって、IME のログから分かるのは、おおむね次の 2 点になります。

  • インストール コマンドのプロセスを 起動できたかどうか
  • そのプロセスが どのような終了コードを返したか、そして 検出規則を満たしたかどうか

逆に言えば、「インストーラーが内部で何をして、なぜ失敗したのか」は Intune 側のログからは見えません。ここが、切り分けの大きな分岐点になります。

Win32 アプリが配布されているかを確認する方法

それでは、実際の確認方法を見ていきましょう。確認の入り口は大きく 2 つあります。

1. Intune 管理センターからの確認方法

まずは Intune 管理センターです。下記の画面から、デバイスごとのアプリのインストール状況を確認できます。

[デバイス] - [すべてのデバイス] - [<確認対象のデバイス>] - [すべてのアプリ]

デバイスごとの Win32 アプリのインストール状況一覧画面

ここで一点、注意していただきたいのが画面右上の [ユーザーの選択] です。アプリのインストール状況は ユーザーごとに評価 が行われます。そのため、対象のデバイスに最近ログインしておらず、そのユーザーで評価が行われていないアプリを選択すると、次のように [インストールの待機中] と表示されることがあります。

選択したユーザーで評価が行われておらず「インストールの待機中」と表示される例

「エラーは出ていないのに、いつまでも待機中のまま」という場合は、まず選択しているユーザーが適切かどうかを確認してみてください。

2. デバイス上のログからの確認方法

管理センター上でエラーが確認できた場合や、より詳しい状況を知りたい場合は、デバイス上のログを確認します。

IME のログは、下記のフォルダー配下に出力されます。Win32 アプリの配布においては、特に AppWorkload.log が重要です。

1
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

これらのログは、Intune 管理センターからリモートで収集できる診断情報にも含まれています。手元にデバイスがない場合でも、デバイスと Intune の通信ができていれば、下記の方法で収集が可能です。

ここからは、切り分けに重要なポイントをログから確認する方法をご紹介します。

事前準備 : Win32 アプリの ID を確認する

ログを見るときは、あらかじめ対象の Win32 アプリの ID を控えておくと格段に効率が上がります。AppWorkload.log には複数のアプリの処理が混在して出力されるため、この ID で絞り込むことで、目的のアプリのログだけを追えるようになります。

Win32 アプリの ID は、Intune 管理センターで下記の画面を開いたときの URL から確認できます。

[アプリ] - [すべてのアプリ] - [<確認対象のアプリ>]

URL の末尾に GUID 形式で表示されているものが、対象の Win32 アプリの ID です。

URL の例

1
https://intune.microsoft.com/#view/Microsoft_Intune_Apps/SettingsMenu/~/0/appId/<Win32 アプリの ID>

インストール コマンドが実際に IME から実行されているか確認する

まず確認したいのが、インストール コマンドのプロセスが IME から正しく起動されているかどうかです。AppWorkload.log には、次のようなログが出力されます。

ログの出力例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<![LOG[[Win32App] ===Step=== InstallBehavior RegularWin32App, Intent 3, UninstallCommandLine <アンインストール コマンド>]LOG]!><time="09:20:57.1814617" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[<インストール コマンド>]LOG]!><time="09:20:57.2014614" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] SetCurrentDirectory: C:\WINDOWS\IMECache\<Win32 アプリの ID>_1]LOG]!><time="09:20:57.2024637" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] Launch Win32AppInstaller in machine session]LOG]!><time="09:20:57.2034684" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] lastWin32Error 0 after CreateProcess]LOG]!><time="09:21:31.2586296" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] lastHResult -2147024896 after CreateProcess]LOG]!><time="09:21:31.2596312" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] Create installer process successfully.]LOG]!><time="09:21:31.2596312" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] process id = 8673]LOG]!><time="09:21:31.2596312" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
...
<![LOG[[Win32App] Installation is done, collecting result]LOG]!><time="09:22:13.4593834" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] lpExitCode 0]LOG]!><time="09:22:13.4603777" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] hResultFromWin32 0]LOG]!><time="09:22:13.4613821" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] Set EnforcementStateMessage.ErrorCode 0]LOG]!><time="09:22:13.4613821" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] lpExitCode is defined as Success]LOG]!><time="09:22:13.4633813" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">

ここでの確認ポイントは 2 つです。

1 つ目は、インストール コマンドのプロセスが IME から正常に起動されているか。 上記の例では Create installer process successfully. が出力されていることから、インストール コマンドのプロセスが IME から問題なく起動されたことが分かります。あわせて、その少し前に出力されているインストール コマンドの内容も確認しておくと、意図したコマンドが実行されているかを確かめられます。

2 つ目は、インストール コマンドが想定どおりの終了コード (lpExitCode) を返しているか。 上記の例では lpExitCode 0 と出力されており、インストール コマンドから終了コードとして 0 が返されたことが分かります。続く lpExitCode is defined as Success から、その終了コードが成功として扱われたことも読み取れます。

なお、lpExitCode に想定されない値 (1 など) が返されている場合、Intune 側のログからこれ以上の詳細を確認することはできません。 これは、Intune の役割がインストール コマンドを起動して結果を受け取るところまでであり、「なぜその終了コードになったのか」はインストーラー自身しか知り得ないためです。

このようなときは、インストール コマンドの実行時に出力されるアプリのインストーラーのログを確認したり、アプリの提供元のサポート窓口へ、その終了コードの意味を確認してみるとよいでしょう。多くのインストーラーは、終了コードごとの意味をドキュメントで公開しています。

検出規則の判定状況を確認する

もう 1 つの重要な確認ポイントが、検出規則の判定状況です。検出規則の評価についても、次のようなログが出力されます。

ログの出力例

1
2
3
4
5
6
7
8
9
<![LOG[[Win32App][DetectionActionHandler] Detection running for policy with id: <Win32 アプリの ID>.]LOG]!><time="09:22:28.6546377" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
...
<![LOG[[Win32App] Start detectionManager SideCarRegistryDetectionManager]LOG]!><time="09:22:28.6576382" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App]  Got reg value path: HKEY_LOCAL_MACHINE\SOFTWARE\Test\Agent, name: Installversion, value: 1.0.0]LOG]!><time="09:22:28.6596374" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] Equal: actualValue: 1.0.0, DetectionValue: 1.0.0, applicationDetected: True]LOG]!><time="09:22:28.6596374" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] Checked reg path: HKEY_LOCAL_MACHINE\SOFTWARE\Test\Agent, name: Installversion, operator: 1, type: 3, value: 1.0.0 , result of applicationDetected: True]LOG]!><time="09:22:28.6610302" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] detectionManager SideCarRegistryDetectionManager got applicationDetectedByCurrentRule: True as system]LOG]!><time="09:22:28.6615404" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App] Completed detectionManager SideCarRegistryDetectionManager, applicationDetectedByCurrentRule: True]LOG]!><time="09:22:28.6615404" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">
<![LOG[[Win32App][ReportingManager] Detection state for app with id: <Win32 アプリの ID> has been updated. Report delta: {"DetectionState":{"OldValue":"NotInstalled","NewValue":"Installed"}}]LOG]!><time="09:22:28.6645546" date="7-20-2026" component="AppWorkload" context="" type="1" thread="94" file="">

上記の例では、レジストリを利用した検出規則が評価されています。Got reg value path: の行で、IME が実際に読み取ったレジストリのパス・名前・値が出力され、続く Equal: actualValue: 1.0.0, DetectionValue: 1.0.0, applicationDetected: True の行で、検出規則に指定した値 (DetectionValue) と、デバイス上の実際の値 (actualValue) を比較した結果が確認できます。そして最後に、検出状態が NotInstalled から Installed に更新されたことが記録されています。

このように、指定した検出規則によってアプリが検出されたのかどうか を、ログから追うことができます。

検出規則が満たされなかった場合、Intune はインストール コマンドが正常に完了しなかったものとして、エラー 0x87D1041C (-2016345060) と判定します。ここで大切なのは、終了コードが成功でも、検出規則が満たされなければアプリは「失敗」として扱われる という点です。

検出規則が満たされていないことが分かった場合は、デバイス上で実際に検出規則に指定したレジストリやファイルなどを確認してみてください。現時点で検出規則が満たされているかを直接確かめられます。ログ上の判定結果と食い違う場合は、次のような点を疑ってみるとよいでしょう。

  • パスや値の指定がわずかに間違っている (余分な空白、WOW6432Node 配下との取り違え など)
  • タイミングの問題で、判定時点ではまだ目印が作られていない

とくに後者は見落としがちなポイントです。検出規則の評価はインストール コマンドの 完了直後 に行われるため、「インストール完了からしばらく経たないと作成されないファイル」や「一度アプリを起動しないと現れない値」を目印にしていると、実際にはインストールが成功していても 0x87D1041C (-2016345060) と判定されてしまいます。このような場合は、より適切な検出規則がないか、アプリの提供元に相談してみるのがおすすめです。提供元は、インストール完了時にどのファイルやレジストリ値が確実に作成されるかを最もよく把握しています。

なお、インストール コマンドが実行されていない場合にも、検出規則の処理を確認してみるとヒントが隠れている ことがあります。Intune は、検出規則が既に満たされている環境に対してはアプリの配布を行いません。「いつまでもインストールが始まらない」という場合、実は既に検出規則が満たされていた、というのもよくあるパターンです。

Intune から Win32 アプリの配布が確認できないときの簡単な切り分け手順

ログを確認しても、そもそも対象のアプリに関する処理がまったく記録されていない。そんなときに試していただきたい、簡単な切り分け手順をご紹介します。

ネットワーク環境の確認

Intune および IME は、いくつかのエンドポイントと通信できることを前提に動作します。まずは、必要なエンドポイントとの通信が許可されているかを確認してみてください。

プロキシや VPN をご利用の場合は、一時的にそれらを経由しないネットワークに接続して事象が変わるかを確認したり、別のネットワークにつないで比較してみたりするのも有効な切り分けです。

Microsoft Intune Management Extension サービスの再起動

IME は、サービスの起動タイミングで新しい Win32 アプリが存在しないかを Intune へ確認しに行きます。そのため、すぐに配布を始めたい場合は、サービスの再起動が有効な切り分けになります。

管理者権限を持つユーザーであれば、スタート メニューから services.msc を起動し、Microsoft Intune Management Extension を右クリックして再起動できます。再起動後に AppWorkload.log に新しいログが出力され始めるかを確認してみてください。

Entra ID ユーザーで Windows 上にログインする

これは、ユーザー グループに割り当てているアプリや、インストール コンテキストとして「ユーザー」を選択しているアプリの場合の確認ポイントです。

Intune 上でユーザー グループに割り当てているアプリや、インストール コンテキストとしてユーザーを選択しているアプリは、そのユーザーがデバイス上にログインしていないと配布が行われません。

「割り当てているのに一向に配布が始まらない」という場合は、対象のユーザーで実際にログインできているかもあわせて確認してみましょう。

「これは Intune？ それともアプリのインストーラー？」― 事象別の考え方

ここまでの内容を踏まえて、どのような事象がどちら側の調査対象になるのかを整理してみましょう。考え方はシンプルです。

  • アプリがデバイスに “届く” までに関すること → Intune の観点から確認
  • インストール コマンドが起動された “後” の動作に関すること → アプリのインストーラーの観点から確認

Intune 側に焦点を当てて確認するとよい事象

  • Win32 アプリのインストール処理や、検出規則による判定が行われている形跡がログから確認できない
  • Intune 上では割り当てをしているにもかかわらず、なかなか配布が進まない
  • Win32 アプリの実際の配布状況と、Intune 管理センター上のレポートに差異がある

アプリのインストーラーに焦点を当てて確認するとよい事象

  • lpExitCode が想定している値ではない
  • lpExitCode は 0 であるにもかかわらず、検出規則が満たされず 0x87D1041C (-2016345060) エラーが発生する
  • Intune から配布した後に、配布したアプリが起動しない、または期待どおりに動作しない

後者に該当する場合は、アプリのインストーラーが出力するログを確認し、必要に応じてアプリの提供元のサポート窓口へ相談してみると良いでしょう。インストーラーの内部の動作を最もよく把握しているのは提供元です。「Intune から配布した際に、終了コード <値> が返り、インストールが完了しなかった」といった形で、IME のログから読み取った事実をあわせてお伝えいただくと、スムーズにご相談いただけます。

おわりに

今回は、Win32 アプリを配布した後のトラブルシューティングについて、”役割分担” という視点からご紹介しました。

  • Intune (IME) の担当範囲は、アプリを配布し、インストール コマンドを 起動するところまで
  • IME のログから分かるのは、プロセスを起動できたか・終了コードは何か・検出規則を満たしたか の 3 点
  • 終了コードが想定外の値になる理由や、インストール処理そのものの詳細は、アプリのインストーラーのログ から確認する

「どこまでが Intune で、どこからがアプリなのか」。この線引きを意識しておくだけで、問題が起きたときに最初に見るべき場所がはっきりし、解決までの時間はぐっと短くなります。ぜひ日々の運用に取り入れてみてください。

次回以降も、みなさまの運用に役立つ情報をお届けしていきます。最後までお読みいただき、ありがとうございました。

]]> https://jpintune.github.io/blog/intune/20260818_01/ 2026-08-17T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

以前の記事では、Intune と Windows の “役割分担” という視点から、設定 (CSP) の配布を例にトラブルシューティングの基本的な考え方をご紹介しました。今回はその Win32 アプリ]]>

Intune のトラブル解決が早くなる。知っておきたい "役割分担" - Win32 アプリ編 2026-11-02T00:39:51.232Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

オンプレミスの Active Directory を、これまで利用されてきた多くのお客様がまず直面されるのが「グループ ポリシー (GPO) での設定項目を、Intune ではどう設定すればよいのか？」という疑問ではないでしょうか。

グループ ポリシーで慣れ親しんだ設定を Intune でも同じように配布したいと思っても、Intune の管理センターには膨大な数の設定が存在するため、目的の設定を探し出すのは簡単ではありません。設定名の日本語訳が微妙に異なっていたり、そもそも設定カタログ上での呼び名が違っていたりして、なかなか目的の設定にたどり着けないという声もよくいただきます。

まずは「グループ ポリシー分析」もご検討ください

既存のグループ ポリシー (GPO) をまとめて Intune へ移行したい場合には、Intune の 「グループ ポリシー分析 (Group Policy analytics)」 という機能がとても便利です。この機能では、オンプレミスでエクスポートした GPO の XML を Intune にインポートすることで、各設定が Intune (MDM) に対応しているかどうかを自動で分析 してくれます。さらに、対応している設定については、そのまま設定カタログのプロファイルとして移行することも可能です。

多数のグループ ポリシーを一括で棚卸し・移行したい場合には、まずはこのグループ ポリシー分析を試していただくのがおすすめです。

移行の進め方全体を考えるうえで参考になる記事

また、グループ ポリシーから Intune への移行を「どういう順序・考え方で進めるか」という点については、下記の記事がとても参考になります。

この記事では、移行を 「Discover (洗い出し)」→「Assess (評価)」→「Migrate (移行)」 の 3 つのフェーズに整理して考えることが提案されています。中でも特に重要なのが「Assess (評価)」のフェーズで、記事内では次のような問いかけが紹介されています。

  • そもそも、その グループ ポリシー設定は今でも必要か？
  • 必要だとして、それを実現するためのよりモダンな (クラウド向けの) 手段が別に用意されていないか？

グループ ポリシーは長年にわたって設定が積み重なっているケースが多く、中には設定された当時の背景がすでに失われているものや、現在では別の仕組みで実現した方が適切なものも含まれています。すべてのグループ ポリシーをそのまま Intune へ移行する必要はない という視点は、移行作業を進めるうえでとても大切なポイントです。移行の検討を始める前に、一度目を通しておくことをお勧めします。

今回の記事で扱う内容

一方で、上記のような評価を経て「この設定は Intune へ移行する」と判断した場合や、特定のグループ ポリシー設定だけをピンポイントで Intune に置き換えたい という場合には、対応する Intune 上の設定を手作業で特定する必要があります。

そこで今回は、特定のグループ ポリシーに対応する Intune 上の設定を、ご自身で探し出すための手順をご紹介します。この流れを一度覚えていただくと、多くのグループ ポリシー設定について、対応する Intune の設定をご自分で特定できるようになりますので、ぜひ参考にしてみてください。

全体の流れ

グループ ポリシーに対応する Intune の設定は、大きく次の 3 つのステップで特定していきます。

  1. グループ ポリシーの 英語名 を特定する
  2. 英語名を元に、対応する CSP を特定する
  3. CSP を元に、設定カタログ 上で対応する設定を見つける

今回は例として、下記のグループ ポリシー設定を Intune で配布したい場合を考えてみます。

[コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [配信の最適化] - [絶対最大キャッシュ サイズ (GB)]

対象のグループ ポリシー設定のパス例

それでは、順を追って見ていきましょう。

ステップ 1. グループ ポリシーの英語名を特定する

まずは、対象となるグループ ポリシーの 英語名 を特定します。

「なぜわざわざ英語名を調べるの？」と思われるかもしれませんが、これには理由があります。日本語の設定名は翻訳のブレがあり、Intune の設定カタログ上の日本語名と、グループ ポリシー上の日本語名が微妙に異なっていることが少なくありません。そのため、英語名を基準に探した方が、確実に対応する設定を見つけることができます。

グループ ポリシーの英語名を調べるには、下記の Group Policy Search (GPS) というサイトが便利です。設定のパスを辿っていく方法や、グループ ポリシーで設定されるレジストリ値で検索を行うことで、対応する英語名を確認することができます。

Group Policy Search (GPS) でグループ ポリシーの英語名を確認する画面

今回の例では [Windows Components (Windows コンポーネント)] - [Delivery Optimization (配信の最適化)] のパスを辿っていくと、[絶対最大キャッシュ サイズ (GB)] に対応する英語名が Absolute Max Cache Size (in GB) であることが確認出来ます。

ステップ 2. 英語名を元に対応する CSP を特定する

次に、特定した英語名を元に、対応する CSP (Configuration Service Provider) を探します。CSP とは、Windows OS に対して設定を反映するための仕組みで、Intune はこの CSP を通じて各種設定を配布しています。グループ ポリシーと Intune の設定を結びつける「橋渡し役」とイメージしていただくと分かりやすいかと思います。

対応する CSP を探すには、「グループ ポリシーの英語名」と「CSP」 をあわせて検索エンジンで検索してみてください。多くの場合、Microsoft の公式ドキュメントである Policy CSP のページが見つかります。

このページには 「Group policy mapping」 という項目があり、その CSP がどのグループ ポリシーに対応しているかが記載されています。ここを確認することで、目的のグループ ポリシーに対応する CSP を正確に特定することができます。

Policy CSP ページの Group policy mapping 欄

今回の例では、「絶対最大キャッシュ サイズ (GB)」に対応する CSP が DeliveryOptimization / DOAbsoluteMaxCacheSize であることが分かります。

ステップ 3. CSP を元に設定カタログ上で対応する設定を見つける

最後に、特定した CSP を元に、Intune の 設定カタログ 上で対応する設定を見つけます。

基本的には、CSP の名前がそのまま設定カタログ上の設定名として使われている ため、設定カタログ上でカテゴリとして “Delivery Optimization” を選択すると、目的の設定 “DO Absolute Max Cache Size” を見つけることができます。

設定カタログで DO Absolute Max Cache Size を検索した画面

同じ名前の設定が 2 つ表示される場合

なお、下記のように同じ設定が 2 つ表示されることがあります。これは、その設定を ユーザー単位 で反映するか、デバイス単位 で反映するかの違いによるものです。

設定カタログで同名の設定が (User) 付きとなしで 2 つ表示される例

設定名の後ろに “(User)” と付いているものは、ユーザー単位で反映される設定です。グループ ポリシーを触ったことのある方であれば、「ユーザーの構成」と「コンピューターの構成」の違い と理解していただければ分かりやすいかと思います。「コンピューターの構成」配下のグループ ポリシーであれば、”(User)” の付いていないデバイス単位の設定を選択します。

対応する設定が見つからないときは

上記の手順で多くの設定は見つけられますが、中には対応する設定がなかなか見つからないケースもあります。そのような場合に試していただきたいポイントを、いくつかご紹介します。

グループ ポリシーの英語名で設定カタログを検索してみる

一部の設定は、CSP 名ではなく グループ ポリシーの英語名そのまま の名前で設定カタログ上に存在することがあります。CSP 名で見つからない場合は、ステップ 1 で特定した英語名で設定カタログを検索してみると、見つかることがあります。

古いグループ ポリシーでないか確認してみる

グループ ポリシーには、過去のバージョンとの互換性を保つために、かなり古い設定が残されている場合があります。そうした古い設定は、CSP としては対応する設定が用意されていないこともあります。

グループ ポリシーの 「サポートされるバージョン」 を確認し、そもそも現在ご利用の Windows のバージョンでサポートされている設定かどうかを確認してみてください。

グループ ポリシーの「サポートされるバージョン」を確認する画面

レジストリで代替できないか確認してみる

どうしても対応する設定が見つからない場合は、スクリプトを利用してグループ ポリシーに対応するレジストリ値を直接設定する ことで代替できる場合があります。

グループ ポリシーが実際に書き込むレジストリ値は、ステップ 1 でご紹介した Group Policy Search (GPS) で確認することができます。ここで確認したレジストリ値を、Intune の PowerShell スクリプトや Win32 アプリなどを利用して直接設定することで、グループ ポリシーと同等の設定を実現できる場合があります。

レジストリ値を配布する具体的な手段としては、PowerShell スクリプト、修復スクリプト (Proactive Remediation)、Win32 アプリなどが挙げられます。それぞれの使い分けや実装例については、冒頭でご紹介した下記の記事の後半でも触れられていますので、あわせてご覧ください。

なお、レジストリを直接設定する方法は、グループ ポリシーによる設定とは反映のされ方が異なる場合があります。適用前に、テスト環境で意図した通りに動作するかを十分にご確認いただくことをお勧めします。

おわりに

今回は、グループ ポリシーに対応する Intune 上の設定を見つける方法として、次の 3 ステップをご紹介しました。

  1. グループ ポリシーの 英語名 を特定する
  2. 英語名を元に、対応する CSP を特定する
  3. CSP を元に、設定カタログ 上で対応する設定を見つける

この流れを覚えていただくと、多くのグループ ポリシー設定について、対応する Intune の設定をご自身で特定できるようになります。オンプレミスから Intune への移行を進める際や、既存のグループ ポリシーを Intune へ置き換える際に、ぜひ活用してみてください。

それでは、また次回の記事でお会いしましょう。

]]> https://jpintune.github.io/blog/intune/20260803_01/ 2026-08-02T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

オンプレミスの Active Directory を、これまで利用されてきた多くのお客様がまず直面されるのが「グループ ポリシー (GPO) での設定項目を、Intune ではどう設定すればよいのか？]]>

グループ ポリシーに対応する Intune の設定を見つける方法 2026-11-02T00:39:51.229Z Japan Microsoft Intune Support Team Microsoft Intune サポート チームです。本記事では、Android デバイスを Intune（MDM）で管理する際に、あらかじめご理解いただきたい Android プラットフォーム固有の仕様についてご案内します。

これらのポイントを事前にご理解いただくことで、お問い合わせ時の状況共有がスムーズになり、原因の切り分けや問題解決までの時間を短縮できます。「Intune 側の問題なのか」「Android／ベンダー側の仕様なのか」「GMS（Google Mobile Services）経由の遅延なのか」を切り分ける観点をあらかじめ共有することが、早期解決の鍵となります。

なぜ事前理解が重要なのか（本記事の目的）

Android の MDM 管理は、iOS/iPadOS や Windows と異なり、Google のサービス（GMS）やデバイス ベンダーの実装に強く依存するという特徴があります。そのため、同じ操作でも動作結果がデバイスやメーカーによって変わることがあります。

Intune はクラウド サービスとして「構成プロファイル（ポリシー）をデバイスへ配信し、適用状況を受け取る」までを担いますが、その先の実際の適用処理は Android OS／GMS 側で行われます。 この役割分担を理解しておくと、以下のようなメリットがあります。

  • お問い合わせ時に、切り分けに必要な情報（デバイス メーカー、モデル、Android バージョン、登録方式など）を最初から共有いただける
  • 「Intune 側で確認できる範囲」と「Android／ベンダー側の要因」を切り分けやすくなる
  • 不要な調査ステップを省け、結果として解決までの時間が短縮される

1. Android の MDM 登録は「Android Enterprise」が前提

現在、Android デバイスを Intune で MDM 管理する場合、原則として Android Enterprise に対応したデバイスであることが前提となります。従来の Device Administrator（デバイス管理者）方式は Google により非推奨・機能縮小が進んでおり、新規の管理方式としては推奨されません。

Android Enterprise では、主に以下の管理方式があります。

  • 個人所有の仕事用プロファイル（Work Profile / BYOD）
  • 完全管理対象デバイス（Fully Managed / COBO）
  • 業務専用デバイス（Dedicated / COSU、キオスク用途など）
  • 企業所有の仕事用プロファイル（COPE）

そのため、管理対象とする Android デバイスが Android Enterprise に対応しているかを、導入前に必ずご確認ください。

対応デバイスの公開情報

Android Enterprise の対応デバイスは、Google が公式に公開している以下のリストからご確認いただけます。お問い合わせ前に、対象デバイスがこのリストに含まれているかをご確認いただくと、切り分けがスムーズになります。

※ Android Enterprise Recommended に掲載されているデバイスは、Google が定める品質・アップデート要件を満たしており、企業利用に適したデバイスとして推奨されます。

2. ベンダー（メーカー）ごとに仕様が異なる点にご注意ください

Android デバイスは Google が提供する OS をベースに、各デバイス メーカーが独自のカスタマイズを加えて出荷しています。このため、同じ Android バージョン・同じ Intune ポリシーであっても、メーカーによって MDM 制御の挙動が異なる場合があります。
特に、ソフトウェア アップデートに関しては、各メーカーごとに配布ポイントを保持しているため、設定アプリ経由ではなく、独自の管理アプリ経由で、配布される可能性があるため、メーカごとで挙動が変わる可能性が高い設定といえます。

上記のソフトウェア アップデートに関わらず、特定メーカー・特定モデルでのみ発生する事象については、デバイス メーカー（ベンダー）へのご確認が必要となる場合があります。
このため、お問い合わせの際は、メーカー名・モデル名・Android バージョンをあわせてお知らせいただくと、この切り分けを迅速に行えます。

3. Intune は「アプリ／設定を直接配布」しているわけではありません（GMS 経由）

Android Enterprise デバイスでは、基本的には、Intune から直接的にアプリや設定をデバイスへ配布しているわけではなく、GMS（Google Mobile Services）を経由して処理が行われる仕組みになっています。

そのため、Intune 側で確認できるのは、あくまで 「構成プロファイル（ポリシー）の配信・適用が成功したこと」までです。その後の実際のアプリ インストールや設定反映は、Google 側のサービスを通じて行われます。

この仕組みを踏まえると、次の点をご理解いただくことが重要です。

  • Intune の管理コンソール上で「適用成功」と表示されていても、それはポリシーがデバイスへ正しく届き、適用処理が受理されたことを示します。
  • 実際のアプリ配布や設定の最終的な反映は GMS 側の処理に委ねられます。

図：Intune から Android へアプリ／設定が届くまでの流れ（GMS 経由）

Intune から Android へアプリ／設定が届くまでの流れ（GMS 経由）

図のポイント

  • ①：Intune が確認できる範囲 — Intune は「ポリシー／アプリ配布を Google Management Service（GMS）へ引き渡し、受理された」ことまでを管理します。コンソール上の「適用成功」表示は、この段階までを示します。
  • ②〜③：GMS／デバイス側で実処理が行われる範囲 — GMS がデバイス上の Android Device Policy App へポリシー・アプリ配布をプッシュし、実際の適用が行われます。ここはネットワーク状況、電源・バッテリー最適化、GMS との同期タイミングなどの影響を受けます。
  • ④：結果の連携 — デバイス（Android Device Policy App）での処理結果が GMS を経由して Intune に返され、最終的なステータスが反映されます。

4. アプリやポリシー適用遅延について

上記の仕組みにより、構成プロファイルの適用が Intune 上で正常に完了していても、GMS 経由の処理により、実際のデバイスへの反映にタイムラグ（遅延）が生じることがあります。

そのため、適用直後に反映が確認できない場合でも、しばらく時間をおいてから再度ご確認いただくことで解消する可能性がございます。「Intune 上は成功しているのに反映されない」という事象は、この GMS 経由の遅延が原因であるケースが少なくありません。

5. アプリを Intune から配布するには「Managed Google Play」への登録が必要

Android Enterprise デバイスへ Intune 経由でアプリを配布するには、Managed Google Play（マネージド Google Play） の利用が前提となります。テナントを Managed Google Play に接続（バインド）することで、Intune の管理コンソールから承認済みアプリを配布・管理できるようになります。

Android Enterprise では、アプリはすべて Managed Google Play を通じて配布されます。Intune 上で扱えるアプリの種類と、それぞれの配布方法は以下のとおりです。

アプリの種類概要配布の仕組み
ストア アプリ（Managed Google Play アプリ）Google Play 上の一般公開アプリを承認して配布Managed Google Play で承認 → Intune で割り当て
ライン オブ ビジネス（LOB）／プライベート アプリ自社開発などの独自 APK を、社内限定で配布Managed Google Play に非公開アプリとして登録 → Intune で割り当て
Web アプリ（Web リンク）Web サイトへのショートカットManaged Google Play の Web アプリとして配信
システム アプリ（OEM プリインストール）デバイスに組み込み済みのアプリを有効化Managed Google Play 経由で有効化

ポイント：LOB（社内アプリ）であっても、Android Enterprise では Managed Google Play への登録（非公開アプリとしての公開）が必要です。iOS のように APK を Intune へ直接アップロードして配布する方式ではありません。

参考：Intune の公開情報（Microsoft Learn）

※ URL は掲載時点での代表的な参照先です。公開前に各ページが最新の掲載先を指しているか最終確認をおすすめします。

Managed Google Play への接続が完了していない場合、上記いずれのアプリ配布機能もご利用いただけません。アプリ配布に関するお問い合わせの際は、Managed Google Play への接続が完了しているかを事前にご確認ください。

まとめ：スムーズなサポートのために

Android の MDM 管理は、Intune・Android OS・GMS・デバイス ベンダーという複数の要素が関わる仕組みです。以下の点をあらかじめご理解・ご確認いただくことで、切り分けが迅速になり、問題解決までの時間を短縮できます。

ポイント事前にご確認いただきたいこと
登録方式対象デバイスが Android Enterprise 対応か
ベンダー依存メーカー名・モデル名・Android バージョン
配布の仕組み事象が Intune 側か、GMS／ベンダー側か
反映遅延適用成功後、時間をおいて再確認したか
アプリ配布Managed Google Play に接続済みか

お問い合わせの際は、上記の情報をあわせてお知らせいただけますと、より迅速で的確なサポートを提供可能となるため、ご協力のほど、よろしくお願いいたします。

この度は、最後までお読みくださりまして、誠にありがとうございました。次回の記事でもお会いできれば嬉しいです。

]]> https://jpintune.github.io/blog/intune/20260731_03/ 2026-07-30T15:00:00.000Z Microsoft Intune サポート チームです。本記事では、Android デバイスを Intune（MDM）で管理する際に、あらかじめご理解いただきたい Android プラットフォーム固有の仕様についてご案内します。

これらのポイントを事前にご理解]]>

Android デバイスを Intune で管理する際に押さえておきたいポイント 2026-11-02T00:39:51.229Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

Intune を使うことで、社内の業務アプリや作成したスクリプト等を Win32 アプリとして、各デバイスへ配信することが出来ます。一方で、いざ配布を始めてみると「手元では問題なくインストールできたのに、Intune から配布するとなぜかうまくいかない…」なんてこともありますよね。実はちょっとしたコツを知っているだけで、このような問題をすんなり解決できてしまうケースが多いのです。

そこで今回は、Win32 アプリを本格的に展開する前に「これだけ押さえておけば安心！」という 3 つのポイントを、ご紹介していきます。事前にサクッと確認しておくことで、配布後の問題を減らし、気持ちよくアプリ展開を進めていきましょう。

そのカギとなるのが、Intune からの Win32 アプリの配信の流れを知っておくことです。Intune はアプリを「配布して起動する」ところまでを担当し、起動された後のインストール処理そのものはアプリのインストーラーにバトンタッチされます。このバトンの受け渡しをイメージしておくと、後の内容もスッと入ってきますので、ぜひ頭の片隅に置いておいてください。

① インストール コマンドの動作を事前に確認しておく

「そんなの当たり前でしょ？」と思われるかもしれませんが、Intune ならではの動作の特性を知らずに進めると、意外なところでつまずくことがあります。逆に言えば、ここさえ押さえておけば安心。特に見落とされやすい 3 つの観点を見ていきましょう。

32 ビット / 64 ビットのどちらで実行されるか意識しておく

まず知っておきたいのが、Intune は既定では 32 ビット プロセスとしてインストール コマンドを実行するという点です。ですので、事前に動作を確認するときは、32 ビット版のコマンド プロンプト (C:\Windows\SysWOW64\cmd.exe) から実行して、無事に完了するか見ておくのが良いです。

ここでちょっとした落とし穴が一つあります。スタート メニューから起動するコマンド プロンプトは、実は 64 ビット版 (C:\Windows\System32\cmd.exe) なんです。何気なく開いたコマンド プロンプトで確認すると、Intune が実際に動く環境とは違う条件でテストしてしまうことになります。ここを合わせておくだけで、確認の精度が上がります。

一方で、Intune から 64 ビット プロセスとしてインストール コマンドを実行させたい場合には、インストール コマンドを記載したバッチ ファイル等を用意しておき、Win32 アプリのインストール コマンドを設定する際に、次のように Sysnative 配下のコマンド プロンプトからバッチ ファイルを起動するようにすると、64 ビット プロセスとしてインストール コマンドを実行させることが可能です。

インストール コマンドの例

1
%systemroot%\Sysnative\cmd.exe /c <インストールに利用するバッチ ファイル>

Sysnative は、32 ビット プロセスから 64 ビット プロセスを呼び出すための特別なエイリアスです。エクスプローラー等で %systemroot%\Sysnative\ を参照しても見つかりませんが、これは問題ありませんのでご安心ください。Sysnative 配下のコマンド プロンプトから起動したバッチ ファイルの動作を確認したい場合は、64 ビット版のコマンド プロンプトを利用して確認していただければ問題ありません。

補足: なぜ System32 ではなく Sysnative を使う必要があるの？

32 ビット プロセスが C:\Windows\System32 を参照しようとしても、WOW64 のファイル システム リダイレクトによって C:\Windows\SysWOW64 (32 ビット側) に自動的に飛ばされてしまいます。そのため、インストール コマンドで C:\Windows\System32 配下の cmd.exe を指定しても、実際には C:\Windows\SysWOW64 配下の cmd.exe が起動されてしまいます。32 ビット プロセスから本来の 64 ビット側の System32 を指し示すには、リダイレクトされない特別なエイリアスである Sysnative を利用する必要があります。

さらに、32 ビットと 64 ビットのどちらのプロセスで実行するかによって、コマンド内で参照されるパスやレジストリの解決先も変わる点に注意が必要です。Sysnative 経由で 64 ビット プロセスとして実行した場合は、%ProgramFiles% は C:\Program Files (64 ビット側) を指し、レジストリも WOW6432Node を経由しない native 側を参照します。一方、既定の 32 ビット プロセスのまま実行した場合は、%ProgramFiles% は C:\Program Files (x86) にリダイレクトされ、レジストリも WOW6432Node 配下を参照することになります。そのため、レジストリを設定するだけのちょっとしたスクリプトであっても、こういった点は注意しないと、意図した場所にレジストリが設定されなくなってしまいます。

インストール コマンドが特定のパスやレジストリ キーを参照している場合、32 ビット / 64 ビットのどちらで動くかで結果が変わってきます。この違いをちょっと意識しておくと、後で「あれ？」となることをうまく避けられます。

ユーザー コンテキスト / システム コンテキスト、どちらで実行するか事前に決めておく

次のポイントは、インストール コマンドをユーザー コンテキストとシステム コンテキストのどちらで実行するか、という点です。

ユーザー コンテキストで確認するなら、cmd.exe をダブル クリックして立ち上げれば OK です。一方、システム コンテキストで配布する予定なら、確認もシステム コンテキストで行うのがコツです。同じ条件でテストしておくことで、本番でも安心して展開できます。

システム コンテキストでコマンド プロンプトを立ち上げる際は、PsExec というツールを利用すると便利です。PsExec を利用して次のようなコマンドを実行することで、システム権限でコマンド プロンプトを立ち上げ、システム コンテキストでのインストール コマンドの動作確認を行うことができます。

1
2
3
4
5
# 32 ビット版のコマンド プロンプトをシステム コンテキストで立ち上げ
psexec -s -i C:\Windows\SysWOW64\cmd.exe

# 64 ビット版のコマンド プロンプトをシステム コンテキストで立ち上げ
psexec -s -i C:\Windows\System32\cmd.exe

※ 立ち上げたコマンド プロンプトで whoami コマンドを打つと、実際にシステム コンテキストで動作していることを確認できます。

というのも、アプリによってはシステム コンテキストでのインストールを想定していないものもあるからです。「ユーザーに管理者権限がないから、とりあえずシステム コンテキストで」と選びたくなる場面もありますが、そんなときこそ事前の一手間が効いてきます。システム コンテキストで配布するなら、同じ条件でひと通り動かしておくと、より確実です。

サイレント インストールが成功するか事前に確認しておく

3 つめは、ユーザーの操作なしで、サイレントにインストールが完了するかどうかです。

Intune から配布する Win32 アプリは、基本的に「ユーザーは何もしなくてもインストールが進む」ことを前提にしています。もしインストール中にウィザードが立ち上がって入力を求められるようなら、サイレント インストール用のオプションが用意されていることが多いので、アプリの提供元のドキュメントやサポート窓口を利用してみてください。オプションの指定方法はインストーラーごとに個性があるので、ここはアプリの提供元を頼るのが確実です。

② Win32 アプリの検出規則を決めておく

動作確認と並んで、確実に押さえておきたいのが「検出規則」です。ここを上手に設定できると、配布がぐっとスムーズになります。

そもそも検出規則とは？

検出規則とは、Intune が「このアプリ、デバイス上にインストール完了してるかな？」を判定するための目印のようなものです。ファイルやレジストリ、あるいは PowerShell スクリプト等を使って、「この条件を満たしていたらインストール完了」と細かく指定できます。

この目印がうまく合っていないと、インストール自体は成功していても、Intune 側は「まだ完了していない？」と受け取ってしまうことがあります。実際、インストール コマンドが正常に終わっているのに検出規則が満たされていないと、Intune はエラー 0x87D1041C (-2016345060) として扱います。逆に言えば、検出規則さえピタッと合わせておけば、こうしたすれ違いはしっかり防げます。

検出規則はいつ評価されるのか？

検出規則は、次のようなタイミングで評価されます。

  • Win32 アプリの配信が開始される前
  • Win32 アプリのインストール コマンドが実行された直後
  • 必須として割り当てている場合は、その後も定期的に

ここでちょっと面白いのが、検出規則は配信の「前」にも評価されるという点。つまり、既に条件を満たしている（＝もうインストール済みの）デバイスには、Intune はわざわざ再配信をしません。

もう一つのポイントは、判定がインストール完了の「直後」に行われること。ですので、「完了してからしばらく経たないと作られないファイル」や「一度アプリを起動しないと現れない値」や「利用中に変更されてしまう可能性がある値」を検出規則に選ぶのは避けるのがおすすめです。すぐに現れる、確実な検出規則を選んでおくと、判定がスムーズに決まります。

また、インストール コマンドとしてバッチ ファイルやスクリプトを指定している場合には、インストール コマンド (バッチ ファイルやスクリプト) が終了したタイミングで検出規則の評価が行われるというのも注意が必要なポイントです。スクリプト内で呼び出した別のプロセスが完了する前に、スクリプト自体が先に終了してしまうと、実際のインストールがまだ途中であっても、その時点で検出規則が評価されてしまいます。すると、まだ目印となるファイルやレジストリ値が作られていないため、Intune は「インストールに失敗した」と判断してしまうことがあるのです。

たとえば、バッチ ファイルの中から別のインストーラーを起動して、そのまますぐにバッチ ファイルが終了するようなケースが該当します。この場合、起動したインストーラーの処理が裏で続いていても、バッチ ファイルはその完了を待たずに終わってしまいます。このようなときは、start /wait を使って呼び出したプロセスの終了を待つようにしたり、PowerShell であれば Start-Process -Wait を利用したりして、実際のインストール処理が終わるまでスクリプトが終了しないように制御してあげると安心です。「スクリプトが終わる ＝ インストールが本当に終わっている」という状態をきちんと作っておくことが、すれ違いを防ぐコツです。

検出規則として何を設定すべきか迷った場合は、アプリの提供元に、インストール完了時に作成されるファイルやレジストリ値を確認してみるとよいでしょう。提供元はそのアプリの内部の動作を最もよく把握しているため、適切な検出規則を選ぶうえで頼りになります。

③ いざというときのために、インストーラーのログの出どころを知っておく

最後は、もしもの時に慌てないための「ログ」のお話です。Intune から Win32 アプリを配布すると、Intune Management Extension がインストール コマンドを起動した後の処理は、次の図のように、インストーラーへ処理がバトンタッチされます。そのため、Intune Management Extension のログからわかるのは、プロセスのリターン コードまで、ということになります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
flowchart TB
    subgraph CLOUD[" "]
        INTUNE["☁️ Microsoft Intune<br/>Win32 アプリ・スクリプトの配布"]
    end

    subgraph DEVICE["💻 デバイス上で動作"]
        direction TB
        IME["🔷 Intune の機能<br/>（配布・起動まで）<br/>Intune Management Extension"]
        APPS["🔶 アプリ・スクリプト側<br/>（起動後の動作）<br/>Win32 アプリ / PowerShell スクリプト"]
        IME == "起動" ==> APPS
    end

    INTUNE -- "配布" --> IME

    style CLOUD fill:transparent,stroke:transparent
    style DEVICE fill:#f3f3f3,stroke:#5f5f5f,stroke-width:2px
    style INTUNE fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style IME fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style APPS fill:#eaf7ea,stroke:#107c10,stroke-width:2px

ちなみに、このリターン コードは Intune が成否を見分ける手がかりにもなっています。既定では 0 と 1707 が成功、3010・1641 は再起動をともなう成功として扱われます。また、リターン コードが成功でも、それだけで「完了」にはなりません。② のとおり最終判定は検出規則の役目なので、「成功コードは返っているのに検出規則が満たされず失敗扱い」というすれ違いも起こります。

運用が始まると、時には想定外のできごとに出会うこともあります。そんなときに頼りになるのがアプリのインストーラーのログです。ログがどこに出力されるのか、またインストーラーのログの解析はどこにすればよいのかを配布前に確認しておくだけで、いざというときの安心感が大きく変わってきます。想定外のリターン コードが発生する場合や、検出規則が満たされない場合は、アプリのインストーラーのログから状況を見る必要があります。特にサードパーティー製のアプリの場合、インストール処理の内部の動作を最もよく把握しているのは提供元ですので、サポート窓口をあらかじめ確認しておくと良いでしょう。

また、PowerShell スクリプト等を使う場合は、スクリプトの中にログ出力を組み込んでおくことをお勧めします。どの処理まで進んで、どこで問題が発生したかを把握しやすくなり、後々の調査に役立ちます。自作のスクリプトを利用する際は、ぜひ取り入れてみてください。

おわりに

今回は、Win32 アプリを配布する前に押さえておきたい 3 つのポイント――インストール コマンドの動作確認、検出規則の設計、そしてインストーラーのログの出どころ――をご紹介しました。

どれも、配布前のちょっとしたひと手間で、その後の展開がぐっとラクになるものばかりです。なかでも「Intune はアプリを起動するところまで、その先はアプリにバトンタッチ」という流れをイメージしておくと、いざというときも「まずはどこを見ればいいか」がスッとわかるようになります。

この記事が、みなさまの Win32 アプリ展開を後押しできたらうれしいです。それでは、また次回の記事でお会いしましょう！

]]> https://jpintune.github.io/blog/intune/20260728_01/ 2026-07-27T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

Intune を使うことで、社内の業務アプリや作成したスクリプト等を Win32 アプリとして、各デバイスへ配信することが出来ます。一方で、いざ配布を始めてみると「手元では問題なくインストールできたの]]>

意外と見落としがち？Intune で Win32 アプリを配布する前に確認しておきたいポイント 2026-11-02T00:39:51.229Z Japan Microsoft Intune Support Team みなさま、こんにちは。Intune サポート チームです。

日々 Intune を活用してデバイス管理を進めていただき、ありがとうございます。今回は、Intune を運用されている皆さまにぜひ知っておいていただきたい「Intune と Windows の役割分担」についてご紹介します。

一見すると地味なテーマに思えるかもしれませんが、この “境界” を理解しておくと、いざ問題が起きたときに「どこを確認すればよいか」がすぐに分かるようになり、原因の特定や解決までの時間を大きく短縮できます。運用のストレスを減らし、より快適に Intune をお使いいただくための第一歩として、ぜひ最後までお読みください。

はじめに ― なぜ「切り分け」が大切なのか

Intune の様々な機能は、その裏側で Windows OS が持つ多彩な機能を利用して動作しています。そのため、何か想定通りに動かない事象が起きたとき、その原因が Intune 側にあるのか、それとも Windows 側にあるのか をあらかじめ切り分けておくことがとても重要です。

事前に切り分けができていると、次のようなメリットがあります。

  • 確認すべきログや設定のポイントを最初から絞り込めるため、調査がスムーズに進む
  • ご自身での解決につながるケースも多く、待ち時間なく対処できる
  • 万一サポートへお問い合わせいただく場合でも、最初から的確な情報をもとに調査を開始できる

切り分けを進めるにあたって、あわせて確認しておくとよい点が 2 つあります。

1 つは、サポート契約の範囲です。お持ちの契約内容によっては、Windows OS に関するサポートが Intune とは別の扱いになる場合があります。問題が Windows 側にあると分かった際にスムーズに動けるよう、ご自身の契約でどこまでカバーされるかをあらかじめ把握しておくと安心です。

もう 1 つは、ライセンスに関するお問い合わせの窓口です。ライセンスに関するご相談は技術サポートではお受けできませんので、担当の営業担当者やライセンスの購入元へお問い合わせください。

Windows OS における MDM 管理の仕組み

まずは、Intune がどのように Windows デバイスを管理しているのか、その全体像を押さえておきましょう。Intune には大きく分けて「設定 (CSP) の配布」と「Win32 アプリ・スクリプトの配布」という 2 つの経路があります。それぞれカバーする範囲が少し異なるため、順番に図で見ていきましょう。

パターン 1：設定 (CSP) の配布

1 つ目は、構成プロファイルなどで設定を配布するパターンです。Intune は MDM チャネルを通じて設定を届け、その設定を受け取って実際に反映・動作させるのは Windows OS 側（CSP/Configuration service provider と各 OS 機能）です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
flowchart TB
    subgraph CLOUD[" "]
        INTUNE["☁️ Microsoft Intune<br/>構成プロファイル等で<br/>設定を配布"]
    end

    subgraph DEVICE["💻 デバイス上で動作"]
        direction TB
        CSP["🔶 CSP <br/>(Configuration service provider)"]
        OSFUNC["🔶 Windows OS の各機能<br/>（Bitlocker / Firewall /<br/> ワイプ 等）"]
        CSP == "反映" ==> OSFUNC
    end

    INTUNE -- "配布" --> CSP

    style CLOUD fill:transparent,stroke:transparent
    style DEVICE fill:#f3f3f3,stroke:#5f5f5f,stroke-width:2px
    style INTUNE fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style CSP fill:#eaf7ea,stroke:#107c10,stroke-width:2px
    style OSFUNC fill:#eaf7ea,stroke:#107c10,stroke-width:2px

つまり、Intune はあくまで設定を届ける役割であり、その設定が適用された後にどう振る舞うかは Windows OS 側が担当している、というのが基本的な考え方です。「設定が届くまで」が Intune、「届いた設定の動作」が Windows という線引きになります。

パターン 2：Win32 アプリ・スクリプトの配布

2 つ目は、Win32 アプリや PowerShell スクリプトを配布するパターンです。この場合は、Intune Management Extension と呼ばれる Intune 専用のエージェントが配布・起動を担当します。この Intune Management Extension までが Intune の機能が提供する範囲 です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
flowchart TB
    subgraph CLOUD[" "]
        INTUNE["☁️ Microsoft Intune<br/>Win32 アプリ・スクリプトの配布"]
    end

    subgraph DEVICE["💻 デバイス上で動作"]
        direction TB
        IME["🔷 Intune の機能<br/>（配布・起動まで）<br/>Intune Management Extension"]
        APPS["🔶 アプリ・スクリプト側<br/>（起動後の動作）<br/>Win32 アプリ / PowerShell スクリプト"]
        IME == "起動" ==> APPS
    end

    INTUNE -- "配布" --> IME

    style CLOUD fill:transparent,stroke:transparent
    style DEVICE fill:#f3f3f3,stroke:#5f5f5f,stroke-width:2px
    style INTUNE fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style IME fill:#e6f2ff,stroke:#0078d4,stroke-width:2px
    style APPS fill:#eaf7ea,stroke:#107c10,stroke-width:2px

Intune Management Extension がアプリのインストーラーやスクリプトを起動した後の処理は、それぞれのインストーラーやスクリプト自身が担います。そのため、アプリやスクリプトの動作で問題が起きた場合は、それらが出力するログの確認が必要になります。特にサードパーティー製のアプリをご利用の場合は、問題発生時に備えて 提供元のサポート窓口 をあらかじめ確認しておくことをおすすめします。

なお、本記事では主に設定 (CSP) の配布に焦点を当てて解説します。アプリやスクリプトの配布については、今後のブログであらためて詳しくご紹介する予定です。

設定 (CSP) が Intune から配布されているかを確認する方法

「設定が思ったように反映されない」というとき、まず確認したいのが Intune からの設定配布自体が完了しているかどうか です。ここが確認できると、問題が「配布まで」なのか「配布後の動作」なのかを切り分けられます。確認方法は大きく 3 つあります。

1. Intune 管理センターからの確認方法

設定 (CSP) が Intune から配布されているかは、基本的に Intune 管理センターの下記の画面から確認できます。「成功」と表示されている構成プロファイルについては、Intune からの設定 (CSP) の配信自体は完了していると判断できます。

[デバイス] - [すべてのデバイス] - [<確認対象のデバイス>] - [デバイスの構成]

デバイスごとの構成プロファイルの配信状況一覧画面

対象のプロファイルを選択すると、各設定の配信状況をより細かく確認できます。

[デバイス] - [すべてのデバイス] - [<確認対象のデバイス>] - [デバイスの構成] - [<確認対象の構成プロファイル>]

構成プロファイルを選択した際の各設定の配信状況画面

同様に、コンプライアンス ポリシーについても下記の画面から確認できます。

[デバイス] - [すべてのデバイス] - [<確認対象のデバイス>] - [デバイスのポリシー準拠]

デバイスごとのコンプライアンス ポリシーの準拠状況一覧画面

[デバイス] - [すべてのデバイス] - [<確認対象のデバイス>] - [デバイスのポリシー準拠] - [<確認対象のコンプライアンス ポリシー>]

コンプライアンス ポリシーを選択した際の各設定の準拠状況画面

また、構成プロファイルの配信が想定通りに進まない場合には、[デバイス] - [すべてのデバイス] から「最後のチェックイン」の時刻を確認し、Intune とデバイスの同期が実際に行われているかを確認することも大切です。同期が行われていなければ、そもそも設定が届いていない可能性があります。

デバイス一覧の「最後のチェックイン」列で同期状況を確認する画面

2. Windows 上でのレジストリからの確認方法

Intune 管理センターからだけでなく、Windows のレジストリからも確認できます。Intune で配布されている Policy CSP の設定の多くは、下記の配下のレジストリに反映されます。ここに値が反映されていれば、Intune からの設定配信自体は正常に行われていると判断できます。

1
2
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\<ユーザーの SID>

例えば、DeliveryOptimization の DODownloadMode という Policy CSP が配信されている場合には、下記の図のように HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeliveryOptimization にその値が反映されます。

設定が配信されている場合の例

3. Windows 上でのイベント ログからの確認方法

注意点として、エラーで Intune からの Policy CSP の配信が失敗している場合や、Policy CSP 以外の通常の CSP の場合は、上記のレジストリに反映されないものも多くあります。このようなときは、イベント ログで CSP の配信状況やエラーの内容を確認できることがあります。

CSP に関する多くのエラーは、イベント ビューアー内の [アプリケーションとサービス ログ] - [Microsoft] - [Windows] - [DeviceManagement-Enterprise-Diagnostics-Provider] - [Admin] から確認できるイベント ログに記録されます。

例えば、ワイプの CSP の実行に失敗した場合には、下記の公開情報に記載されているようなイベントが記録されます。

1
2
3
4
5
6
ログ名: Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin
ソース: DeviceManagement-Enterprise-Diagnostics-Provider
イベント ID: 400
コンピューター: デスクトップ PC
ユーザー: システム
詳細: MDM ConfigurationManager: コマンドエラーの状態。 構成ソース ID: (9B5DC01F-D64E-488A-BB24-F0E9DA4FBF47)、登録名: (MDMFull)、プロバイダー名: (RemoteWipe)、コマンドの種類: (CmdType_Execute)、CSP URI: (./Vendor/MSFT/RemoteWipe/doWipe)、結果: (要求はサポートされていません。)。

このように、イベント ログにはエラーの原因を示す具体的な情報が記録されるため、切り分けの大きな手がかりになります。

「これは Intune？ それとも Windows？」― 事象別の考え方

ここまでの内容を踏まえて、実際にどのような事象がどちら側の調査対象になるのかを整理してみましょう。基本的な考え方はシンプルです。

  • Intune からの設定の “配信” に関すること → Intune の観点から確認
  • 設定自体の “挙動” や、配布後の “動作” に関すること → Windows の観点から確認

以下に具体的な例を挙げます。ご自身で事象を切り分ける際の参考にしてください。

Intune 側に焦点を当てて確認するとよい事象

  • Intune とデバイスの同期ができておらず、構成プロファイルの配信が行われない
  • Windows のレジストリ上では設定の反映が確認できるものの、Intune 管理センター上では構成プロファイルの配信状況が確認できない
  • 構成プロファイルの割り当てをフィルターで行っているが、意図したデバイスが配信対象とならず適用外になってしまう

Windows 側に焦点を当てて確認するとよい事象

  • Windows 上で特定の設定変更などをブロックしたいが、どのような設定を Intune から配信すればよいかを知りたい
  • Intune 管理センター上ではプロファイルの配信が「成功」と表示され、Windows のレジストリ上も設定の反映が確認できているのに、期待した動作が Windows 側で得られない
  • Intune 管理センター上ではプロファイルの配信が「エラー」と表示され、イベント ログを確認すると Windows 側からエラーが返されている
  • Intune からワイプを実行したところ、Windows 上でワイプは開始されるものの、途中で処理が失敗してしまう

ポイントは、「設定がデバイスに届いているか」までが Intune の領域、「届いた設定がどう動くか」からが Windows の領域 ということです。この線引きを意識するだけで、確認すべき方向がぐっと明確になります。

ログの採取 ― いざというときのために

上述したレジストリやイベント ログは、下記の手順で Intune 管理センターから取得できる診断情報の中にも含まれています。事象を切り分ける際はもちろん、サポートへお問い合わせいただく際にも、これらのデータをあわせてご提供いただけると調査をスムーズに進められます。

日頃から取得方法を把握しておくと、いざというときに慌てずに対応できます。

おわりに

今回は、Intune と Windows の “境界” という視点から、デバイス管理のトラブルシューティングを進めるうえでの基本的な考え方をご紹介しました。

  • Intune は「設定を配布する」役割、Windows は「配布された設定を動作させる」役割
  • 「設定が届いているか」は Intune 管理センター・レジストリ・イベント ログで確認できる
  • 事象が「配信まで」なのか「配信後の動作」なのかで、確認すべき方向が変わる

この考え方を身につけていただくと、問題が起きたときに落ち着いて原因を切り分けられるようになり、より快適に Intune をご活用いただけるはずです。ぜひ日々の運用に取り入れてみてください。

次回以降も、皆さまの運用に役立つ情報をお届けしていきます。最後までお読みいただき、ありがとうございました。

]]> https://jpintune.github.io/blog/intune/20260722_02/ 2026-07-21T15:00:00.000Z みなさま、こんにちは。Intune サポート チームです。

日々 Intune を活用してデバイス管理を進めていただき、ありがとうございます。今回は、Intune を運用されている皆さまにぜひ知っておいていただきたい「Intune と Windows の役割分]]>

Intune のトラブル解決が早くなる。知っておきたい Windows との "役割分担" - 基本編 2026-11-02T00:39:51.227Z