グループポリシーからIntuneへ ── 中小企業のデバイス管理移行ガイド

「ADサーバーの保守期限が来た。このまま更改して、グループポリシーをもう5年続けるべきだろうか」「在宅勤務のPCには、VPNにつないだときしか設定が届かない」。中小企業では、こうした相談が増えています。

この記事の軸は、ADサーバーを買い直すかどうかではなく、これからの5年、社外にあるPCを何で管理するかです。移行は「全部か無か」ではありません。ADを残しながら、新しいPCからEntra join+Intuneへ切り替える進め方があります。¹

最初に、いま判断したいことから読む場所を選んでください。

この記事の前提

対象は、中小企業の情シス担当者と経営者です。GPOとMDMの違い、必要な構成とライセンス、棚卸し、段階移行、つまずきどころを、2026年8月時点のMicrosoft Learn等の一次情報にもとづいて整理します。特にプラン構成は変わるため、契約前には公式情報で最新の内容を確認してください。

オンプレミスのActive Directory(AD)とグループポリシー(GPO)は、「PCが社内LANにあり、ドメインコントローラーにいつでも届く」ことを前提にした仕組みです。持ち出しPCや在宅勤務の常態化で、その前提が崩れました。更新管理の定番だったWSUSも2024年9月に非推奨となり、Microsoftのデバイス管理の重心はEntra ID+Intune(MDM)へ移っています。²

flowchart TB
    accTitle: 前提の崩れと管理の重心移動
    accDescr: ADとGPOはPCが社内LANにありドメインコントローラーにいつでも届くことを前提にした仕組みだが、持ち出しPCと在宅勤務の常態化でその前提が崩れ、WSUSの非推奨もあって管理の重心はEntra IDとIntuneへ移っている
    adgpo["オンプレのADとGPO"] -.-> premise["前提はDCにいつでも届くこと"]
    work["持ち出しPCと在宅の常態化"] --> broken["前提のほうが崩れた"]
    premise --> broken
    wsus["WSUSが非推奨に"] --> shift["重心はEntra ID+Intuneへ"]
    broken --> shift

図1: AD+GPOの「PCは社内LANにある」という前提が働き方の変化で崩れ、管理の重心はEntra ID+Intuneへ移った。

1. まず結論

移行方針は、次の3点から組み立てます。

1. 社外PCへ管理を届ける方法を変える。GPOはドメインコントローラーへの接続が必要ですが、Intuneはインターネット経由で同期します。ただし、定常同期はおおよそ8時間ごとで、即時反映を保証する仕組みではありません。ポリシー変更時の通知による同期もあります。³
2. 新規PCから切り替え、既存環境とは共存する。新規・入替機はEntra join+Intune、既存のドメイン参加機はhybrid joinのままリプレースサイクルで置き換えるのが現実的です。ADの即時廃止は移行の条件ではありません。¹
3. GPOを丸ごと再現せず、設定ごとに仕分ける。Group Policy analyticsで棚卸しし、不要な設定は捨て、必要な設定はIntuneへ移すか代替策を設計します。同じ設定をGPOとMDMの両方から配らないことが原則です。⁴⁵

管理用テンプレート、更新管理、BitLocker、LAPS、アプリ配布といった主要業務にはIntune側の対応物があります。一方、ログオンスクリプト、ドライブマップ、プリンター配布は、そのまま移せない代表例です。5〜6章で移し先を整理します。

中小企業では、Intune Plan 1とEntra ID P1を含むMicrosoft 365 Business Premiumが現実的な出発点になります。ただし、すべてのIntune機能が含まれるわけではありません。ライセンスと費用は4章で確認します。⁶⁷

問いを「ADサーバーをもう一周更改するか」から、「これからの5年、社外にあるPCを何で管理するか」へ置き換えると、比較すべきものが見えてきます。

flowchart LR
    accTitle: 判断すべき問いの置き換え
    accDescr: ADサーバーをもう一周更改するかという問いは、これからの5年に社外にあるPCを何で管理するかという問いに置き換えて判断する
    q1["ADサーバーをもう一周更改?"] -->|置き換え| q2["次の5年 社外PCを何で管理?"]

図2: サーバー更改の問いは「これからの5年、社外にあるPCを何で管理するか」に置き換えて判断する。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全20件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. GPOとMDMは何が違うか ── 適用の仕組みを比べる

違うのは、設定の内容だけでなく届け方

GPOとIntuneを、まず同じ観点で比較します。GPOのLSDOU適用順序やgpupdate / gpresultでの確認方法は「グループポリシー(GPO)実務入門」で扱っているため、ここでは移行判断に効く違いに絞ります。

移行判断で最も重要なのは、取得元と社外PCへの到達方法です。GPOが在宅PCに届かないのは、「PCはドメインコントローラーに届く場所にある」という設計前提が、今の働き方と合わなくなったためです。

VPNの常時接続を全社員に求めてGPOを延命する道もあります。ただし、それはVPN基盤という別のインフラ維持も抱え込む選択です。

flowchart TB
    accTitle: GPO延命かMDM移行かの選択
    accDescr: GPOが在宅PCに届かないのは設計前提が現代の働き方と合わなくなったためで、VPNの常時接続を強制してGPOを延命する道はVPN基盤という別のインフラ維持を抱え込む選択になる
    gap["設計前提が働き方と合わない"] --> sel{"どう対処する?"}
    sel -->|VPN常時接続で延命| vpn["GPOを継続"]
    sel -->|MDMへ移行| mdm["インターネット経由で管理"]
    vpn --> cost["別のインフラ維持を抱え込む"]

図3: VPN常時接続でGPOを延命する道は、VPN基盤という別のインフラ維持を抱え込む選択でもある。

「社外に届く」と「すぐ反映される」は別

Intuneなら、インターネットにつながるPCへ場所を問わず管理を届けられます。一方、定常状態の同期は約8時間ごとで、GPOの定期更新である約90分より粗くなります。「配ったらすぐ反映」という感覚のまま移行しないことが重要です。

ポリシーの割り当てや変更時には端末へ通知が送られ、比較的すみやかに同期されます。管理センターや端末からの手動同期もできますが、緊急のブロックなど即時性を要する統制は、同期間隔を前提に設計する必要があります。³

flowchart TB
    accTitle: GPOとMDMのポリシー適用経路
    accDescr: GPOは社内のドメインコントローラーに接続できたときだけ適用されるため在宅PCはVPN頼みになるが、Intuneはインターネット経由でおよそ8時間ごとに同期しポリシー変更時には通知でも同期するため場所を問わず届く
    officepc["社内のPC"] -->|起動・サインイン時と定期更新| dc["ドメインコントローラー"]
    homepc["在宅のPC"] --> vpn{"VPNでDCに届く?"}
    vpn -->|はい| dc
    vpn -->|いいえ| miss["最新ポリシーが届かない"]
    anypc["どこにあるPC"] -->|約8時間ごとの同期| intune["Intuneサービス"]
    intune -.-> notify["ポリシー変更時は通知で同期"]

図4: GPOはドメインコントローラーに届くときだけ適用され、Intuneはインターネット経由で場所を問わず同期する。

3. 前提の整理 ── ドメイン参加・hybrid join・Entra joinの3形態

PCの参加形態で、使える管理手段が変わる

Windows PCの「会社への参加のしかた」には、次の3形態があります。¹

hybrid joinは、既存のドメイン参加PCをEntra IDにも登録する形態です。既存資産を活かしながらIntuneや条件付きアクセスを使い始められます。ただしMicrosoftは、hybrid joinを最終ゴールにせず、新規・リプレースのPCはEntra joinにすることを推奨しています。¹

既存PCにはワイプが必要。だから入替時に切り替える

ドメイン参加PC(hybrid joinを含む)をEntra joinへ変換する、Microsoftサポート対象の手段は存在しません。Windowsのリセット(ワイプ)が必要です。このため、ハードウェア更新やOS入れ替えに合わせてEntra joinへ移すことが勧められています。¹

flowchart TB
    accTitle: 3つの参加形態と移行の経路
    accDescr: ADドメイン参加のみのPCはEntra IDにも登録してhybrid joinにできるが、Entra joinへ直接変換する手段はなくワイプが必要なため、新規・入替のPCをEntra joinにすることが推奨される
    adonly["ADドメイン参加のみ（GPO）"] -->|Entra IDにも登録| hybrid["hybrid join（GPOとIntune）"]
    hybrid -.->|直接変換の手段なし| wipe["ワイプ（リセット）が必要"]
    wipe --> entra["Entra join（Intune）"]
    newpc["新規・入替のPC"] -->|推奨| entra

図5: 既存のドメイン参加機をEntra joinへ変換する正式な手段はなく、新規・入替のPCから切り替えるのが定石。

中小企業の移行方針は、PCとADを分けると整理しやすくなります。

Entra join機とドメイン参加機は、同じ社内環境で共存できます。新しい管理方式を始めるために、既存PCやADを一度に廃止する必要はありません。¹

flowchart TB
    accTitle: 段階移行中の共存構成
    accDescr: Entra join機とドメイン参加機は同じ社内環境で共存でき、前者はIntune、後者はGPOで管理しつつ、ADは残存する役割のために当面残してGPOの中身だけを段階的に空にしていく
    env["同じ社内環境"] --> ejoin["Entra join機"]
    env --> djoin["ドメイン参加機"]
    ejoin --> intune["Intuneで管理"]
    djoin --> gpo["GPOで管理"]
    gpo -.-> shrink["中身を段階的に空にする"]
    env -.-> ad["ADは残存役割のため残す"]

図6: Entra join機とドメイン参加機は同じ社内環境で共存でき、ADは残存する役割のために当面残す。

オンプレ資産へのSSOには、別に2つの前提がある

Entra join機からオンプレのファイルサーバーなどへアクセスすることも可能です。ただし、Entra joinであることだけでは、オンプレ資産へのシングルサインオン(SSO)の前提は揃いません。次の2点を確認します。¹⁸

移行計画では、この2点を満たさないユーザーや利用場面がないかを先に洗い出します。Intuneによる社外PCの管理と、社内資産への接続は分けて確認する、ということです。

flowchart TB
    accTitle: Entra join機からオンプレ資産へのSSOの前提
    accDescr: Entra join機からオンプレのファイルサーバーへアクセスするには、Entra Connect等で同期されたハイブリッドIDであることと、ドメインコントローラーへ到達できることの2つの前提を満たす必要がある
    pc["Entra join機"] --> cond1{"ハイブリッドID?"}
    cond1 -->|はい| cond2{"DCへ到達できる?"}
    cond1 -->|いいえ| ng1["AD資格情報を得られない"]
    cond2 -->|はい| ok["ファイルサーバーへSSO"]
    cond2 -->|いいえ| ng2["社外ではVPN等が必要"]

図7: Entra join機からオンプレ資産へのSSOには、ハイブリッドIDとドメインコントローラーへの到達という2つの前提がある。

4. ライセンスと費用 ── Intuneはどのプランに含まれるか(2026年8月時点)

Business Premiumで始められる範囲を確認する

基本ライセンスはMicrosoft Intune Plan 1です。単体のサブスクリプションとしても、各種Microsoft 365プランへの同梱としても提供されます。⁶

中小企業では、300ユーザーまでのMicrosoft 365 Business PremiumにIntune Plan 1が含まれる点が重要です。Business PremiumにはMicrosoft Entra ID P1とMicrosoft Defender for Businessも含まれるため、コンプライアンスポリシー+条件付きアクセスまで構成できます。⁷

Business Standard / BasicにはIntuneが含まれません。メールとOfficeだけの契約からデバイス管理へ進む場合は、Business Premiumへのアップグレード差額が実質的なIntune導入費用になります。

flowchart TB
    accTitle: 中小企業向けプランとIntuneの関係
    accDescr: 300ユーザーまでのBusiness PremiumにはIntune Plan 1とEntra ID P1とDefender for Businessが含まれ条件付きアクセスまで完結するが、Business Standard/BasicにIntuneは含まれない
    bp["Business Premium"] -.-> cap["300ユーザーまで"]
    bp --> intune["Intune Plan 1"]
    bp --> p1["Entra ID P1"]
    bp --> dfb["Defender for Business"]
    p1 --> ca["条件付きアクセスまで完結"]
    dfb ~~~ std["Business Standard/Basic"]
    std --> noint["Intuneを含まない"]

図8: Business PremiumはIntune Plan 1とEntra ID P1を含み、Business Standard/BasicにIntuneは含まれない。

画面にある機能でも、別ライセンスが必要な場合がある

特に注意したいのは、次の2点です。

プラン構成は固定ではありません。2026年に入ってからも、Intune Suiteの機能をMicrosoft 365上位プラン(E3/E5等)へ再配分する変更など、同梱内容の見直しが進んでいます。本節は2026年8月時点の情報として扱い、契約前に公式のライセンスページと価格ページを確認してください。⁶

Intuneの管理画面から使えることと、契約上使えることは別です。代表例がRemediationsです。Windows Enterprise E3/E5系(Microsoft 365 E3/E5等に同梱)のライセンスが必要で、Business Premiumの範囲では利用できません。代替方法は5章で整理します。⁹

比較するのは「サブスク対ゼロ円」ではなく、5年分の費用

GPO側にも、ADサーバーのハードウェア更改、Windows ServerライセンスとCAL、構築、5年分の保守、バックアップ、障害対応の費用がかかります。

サーバー更改の見積書と、Business Premiumの5年分の差額を並べる。そのうえで、社外PCに管理が届くかという能力差を加味する。これが費用比較の軸です。

flowchart TB
    accTitle: 費用比較の正しい考え方
    accDescr: GPO側にもADサーバーの更改やライセンス、5年分の保守などの費用がかかるため、サーバー更改の見積りとBusiness Premiumの5年分の差額を並べたうえで、社外PCに管理が届くかという能力差を加味して判断する
    gpocost["GPO継続の費用"] --> hw["サーバー更改・ライセンス・CAL"]
    gpocost --> ops["構築・保守・バックアップ"]
    bpcost["Intune移行の費用"] --> sub["Business Premium 5年分"]
    hw --> diff["5年分の差額を並べる"]
    ops --> diff
    sub --> diff
    diff --> ability["社外PCに管理が届くかを加味"]

図9: サーバー更改の見積りとBusiness Premiumの5年分を並べ、社外PCへの管理という能力差を加味して判断する。

5. GPOでやってきたことをIntuneでどうやるか

主要業務には、Intune側の対応物がある

GPOの名前や設定をそのまま持ち込む前に、実現していた仕事と移し先を対応づけます。

設定カタログは、管理用テンプレートの移し先

設定カタログは「GPOエディターのクラウド版」に相当する画面です。Microsoftも、オンプレミスGPOと同様に細かく構成したい場合の自然な移行先と位置づけています。

ADMXで定義された設定のMDM版であるADMXバックドポリシーも含まれ、サードパーティ製ADMXの取り込み機能(プレビュー)もあります。¹⁰

スクリプトは「いつ実行したいか」で選ぶ

Remediationsは旧称Proactive remediationsから改名された機能で、検知スクリプトと修復スクリプトのペアを定期実行します。「ログオンのたびに何かを直す」系の運用の代替になりますが、4章で述べたWindows Enterprise E3/E5系ライセンスが必要です。⁹

Business Premiumの範囲では、プラットフォームスクリプトとWin32アプリの検出ルールを組み合わせる方法が現実的です。プラットフォームスクリプトは割り当て後に実行され、スクリプトや割り当ての変更時に再実行、失敗時に再試行されるもので、定期実行するRemediationsとは区別します。¹⁶

「準拠を判定する」と「アクセスを止める」を分ける

コンプライアンスポリシー+条件付きアクセスは、GPOにはなかった発想です。「BitLocker有効・OS最新・Defender稼働」といった準拠条件を定義し、満たさないデバイスからのMicrosoft 365へのアクセスをブロックできます。¹¹

役割は二つに分かれます。コンプライアンスポリシーは準拠状態の判定、条件付きアクセスはアクセスの制御です。条件付きアクセスポリシーが準拠デバイスを要求することで、初めてブロックが効きます。条件付きアクセスはEntra ID P1の機能で、Business Premiumに含まれます。¹¹

flowchart TB
    accTitle: コンプライアンスポリシーと条件付きアクセスの流れ
    accDescr: コンプライアンスポリシーは準拠条件にもとづいてデバイスの準拠状態を判定するだけで、条件付きアクセスポリシーが準拠デバイスを要求することで初めて、準拠デバイスは許可され非準拠デバイスはブロックされる
    policy["準拠条件を定義"] -.-> cond["BitLocker有効やOS最新など"]
    policy --> state["デバイスの準拠状態を判定"]
    state --> ca["条件付きアクセスが準拠を要求"]
    ca -->|準拠| allow["Microsoft 365へアクセス可"]
    ca -->|非準拠| block["アクセスをブロック"]

図10: 準拠状態の判定はコンプライアンスポリシー、遮断は条件付きアクセスの役割。組み合わせて初めてブロックが効く。

更新管理の選択肢(WUfB・Autopatch・WSUS継続の判断)は「WSUS非推奨後のWindows Update管理」、BitLockerとLAPSの設計は「BitLocker実務ガイド」「Windows LAPS実務ガイド」で詳しく扱っています。

6. 現行GPOの棚卸し ── Group Policy analyticsで仕分ける

最初の実作業は、GPOを設定単位で分析すること

移行計画の最初の実作業は、現行GPOの棚卸しです。Intune標準のGroup Policy analyticsを使うと、手作業でGPOを読み解かなくても、設定単位でMDMへの移行可否を仕分けできます。⁴

この流れで、対応済みの設定をIntune側へ移せます。⁴

flowchart TB
    accTitle: Group Policy analyticsでの棚卸しの流れ
    accDescr: GPMCでGPOをXMLエクスポートしてIntuneへインポートするとMDMサポート率と設定ごとの移行可否が表示され、Ready for migrationの設定は設定カタログのポリシーへ変換できる
    export["GPMCでGPOをXMLエクスポート"] --> import["Intuneへインポート"]
    import --> rate["MDMサポート率の表示"]
    rate --> report["移行準備状況レポート"]
    report --> ready["Ready for migration"]
    report --> notsup["Not supported"]
    report --> dep["Deprecated"]
    ready --> convert["設定カタログのポリシーへ変換"]

図11: XMLエクスポートからインポート・設定単位の仕分け・設定カタログへの変換までがGroup Policy analyticsの流れ。

日本語GPOでは、サポート率だけで決めない

非ADMX設定の分析は英語のみの対応です。英語以外の言語の設定を含むGPOをインポートすると、MDMサポート率が不正確になり得ます。日本語環境では特に注意してください。⁴

サポート率は概算の参考値です。最終判断は、設定単位の一覧で行います。

flowchart TB
    accTitle: 日本語GPOを分析するときの注意
    accDescr: Group Policy analyticsの非ADMX設定の分析は英語のみの対応で、日本語の設定を含むGPOではMDMサポート率が不正確になり得るため、率は概算の参考にとどめて最終判断は設定単位の一覧で行う
    jgpo["日本語の設定を含むGPO"] --> limit["非ADMX分析は英語のみ対応"]
    limit --> rate["サポート率が不正確になり得る"]
    rate --> use1["率は概算の参考にとどめる"]
    rate --> use2["最終判断は設定単位の一覧で"]

図12: 日本語のGPOではMDMサポート率が不正確になり得るため、最終判断は設定単位の一覧で行う。

分析結果を「捨てる・移す・代替する」に分ける

ツールの移行可否と、その設定を今後も必要とするかは、分けて判断します。

10年運用したGPOには、相当量の古い設定が残っています。不要な設定を捨てられること自体が、棚卸しの大きな成果です。移せる設定をすべて移す必要はありません。

対応設定がない代表例と、代替の方向性は次のとおりです。

flowchart TB
    accTitle: 棚卸し結果の3つの仕分け
    accDescr: 棚卸しの結果は、捨てる設定、Intuneへ移して検証する設定、対応設定がなく代替策を設計する設定の3つの山に分けて扱う
    result["仕分け結果"] --> discard["捨てる設定"]
    result --> move["Intuneへ移す設定"]
    result --> alt["代替策を設計する設定"]
    discard -.-> legacy["堆積した遺産を処分"]
    move --> pilot["設定カタログへ変換し検証"]
    alt --> design["スクリプト配布やアプリ化"]

図13: 棚卸し結果は「捨てる」「Intuneへ移す」「代替策を設計する」の3つの山に仕分ける。

7. 段階的な移行シナリオ ── 5段階と完了条件

「何をするか」と「いつ完了か」を先に揃える

展開は5段階に分け、各段階に完了条件を置きます。1人情シスでも移行を頓挫させないために、作業を始める前に「いつ終わったと言えるか」を決めます。

flowchart TB
    accTitle: 5段階の移行シナリオ
    accDescr: パイロットから基本ポリシー、アプリ配布、既存PCのリプレースサイクルでの置換、ADの役割縮小へと段階的に進め、最終的にGPOで配る設定をゼロにする
    s1["① パイロット"] --> s2["② 基本ポリシー"]
    s2 --> s3["③ アプリ配布"]
    s3 --> s4["④ 既存PCの自然置換"]
    s4 --> s5["⑤ ADの役割縮小"]
    s5 -.-> goal["GPOで配る設定がゼロ"]

図14: 移行はパイロットからADの役割縮小まで5段階で進め、各段階の完了条件を先に決めておく。

① パイロット: どうせ買うPCから始める

次の新入社員用PCや故障交換機など、新規調達するPCで始めます。追加のPC購入なしに試せ、失敗してもワイプしてやり直せることが利点です。

台数が増えてきたら、OOBE(初期セットアップ)からEntra join+Intune登録までを自動化するWindows Autopilotを検討します。最初から必須ではありません。¹

② 基本ポリシー: 最初は5点に絞る

GPOの全設定を再現しようとせず、更新・暗号化・Defender・画面ロック・LAPSの5点から始めます。コンプライアンスポリシーで準拠状態を可視化してください。

条件付きアクセスの「準拠デバイスのみアクセス可」を有効にするのは、パイロットで誤検知がないことを確認した後です。¹¹

③ アプリ配布: キッティングの手作業を減らす

アプリ配布はキッティングの自動化につながります。すでにwingetベースの手順を整備していれば、その資産はStoreアプリ(新)やWin32アプリのラッパーとしてほぼそのまま活かせます。¹⁵

手順書から自動化を進める方法は「winget + PowerShellでPCキッティングを自動化する」を参照してください。

④ 既存PC: リプレースサイクルに合わせる

3章のとおり、既存のドメイン参加PCには、ワイプなしでEntra joinへ変換する正式な経路がありません。原則はリプレースサイクルでの置換とし、前倒しするPCだけをワイプして切り替えます。

Windows 10からの入れ替え計画が残る組織は、その計画と同時に進めると二度手間を避けられます。選択肢は「Windows 10サポート終了後の現実解」で整理しています。

⑤ ADの役割縮小: GPOが空でも、認証の役割は残り得る

GPOが空になったことと、ADが不要になったことは同じではありません。ファイルサーバーの認証やレガシーアプリのLDAP参照が残れば、ADは認証サーバーとして縮小継続します。

残存する役割を棚卸しし、期限を設定するところまでが、この段階の仕事です。役割がなくなった場合に、AD自体の廃止を検討します。

flowchart TB
    accTitle: GPOが空になった後のADの扱い
    accDescr: GPOが空になってもファイルサーバーの認証やレガシーアプリのLDAP参照が残っていればADは認証サーバーとして縮小継続し、残存役割の棚卸しと期限設定までが最終段階の仕事になる
    gpoempty["GPOが空になった"] --> remain{"残存する役割は?"}
    remain -->|ファイルサーバー認証| keep["認証サーバーとして縮小継続"]
    remain -->|レガシーのLDAP参照| keep
    remain -->|役割なし| retire["AD自体の廃止を検討"]
    keep --> task["棚卸しと期限設定まで行う"]

図15: GPOが空になっても残存する役割があれば、ADは認証サーバーとして縮小継続する。

8. つまずきどころ

8.1. GPOとMDMの二重適用 ── 既定ではGPOが勝つ

移行期間中は、hybrid join機にGPOとIntuneの両方から設定を配る場面が生じます。ここで同じ設定が競合すると、既定ではGPO側が優先されます。

Policy CSPのMDMWinsOverGPを1にすると、MDM側の設定が優先され、対応するGPO設定はブロックされます。ただし、対象はPolicy CSP配下の設定だけです。Defender CSPなど、他のCSPで定義される設定には適用されません。管理下にない設定をGPOとMDMの両方で構成すると、どちらが勝つか保証されないことをMicrosoftも明記しています。⁵

flowchart TB
    accTitle: GPOとMDMが競合したときの優先関係
    accDescr: 同じ設定をGPOとMDMの両方から配ると既定ではGPOが優先され、MDMWinsOverGPを1にするとPolicy CSP配下の設定に限りMDMが優先されるが、それ以外のCSPの設定では勝敗が保証されない
    both["同じ設定をGPOとMDMの両方から配布"] --> flag{"MDMWinsOverGP=1?"}
    flag -->|いいえ| gpowin["GPOが優先（既定）"]
    flag -->|はい| csp{"Policy CSP配下の設定?"}
    csp -->|はい| mdmwin["MDMが優先"]
    csp -->|いいえ| unknown["どちらが勝つか保証されない"]
    both -.-> avoid["原則は両方から配らない"]

図16: 既定ではGPOが勝ち、MDMWinsOverGPが効くのはPolicy CSP配下のみ。原則は二重配布を避ける。

実務の原則は、優先制御に頼らず、同じ設定を両方から配らないことです。Intuneへ移した設定は、対応するGPO側を「未構成」に戻すか、GPOごとリンクを外します。棚卸しした設定を7章②の移行済みリストに記録するのは、二重管理を避けるためでもあります。

8.2. オンプレ資産への依存 ── ネットワークドライブとプリンター

詰まりどころの多くは、Intuneの機能ではなくオンプレ資産との接続です。Entra join機からファイルサーバーへアクセスできても、ドライブマップやプリンター配布をGPOのログオンスクリプトに頼っていれば、その配布手段だけが先に消えます。¹

共有をOneDrive / SharePointへ移すか、Universal Printへ置き換えるか、当面はスクリプト配布でつなぐかを、パイロット中に決めます。置き換える場合は7章③のアプリ配布段階に織り込んでください。¹⁶

flowchart TB
    accTitle: オンプレ資産に依存する配布の置き換え
    accDescr: ドライブマップやプリンター配布をGPOのログオンスクリプトに依存していると移行でその配布手段が先に消えるため、OneDriveやSharePointへの共有移行、Universal Printへの置き換え、当面のスクリプト配布のどれで対応するかをパイロット中に決める
    dep["ログオンスクリプト依存"] --> lost["移行で配布手段が消える"]
    lost --> share["OneDrive/SharePoint移行"]
    lost --> print["Universal Print等へ置換"]
    lost --> script["スクリプト配布でつなぐ"]
    share --> decide["パイロット中に方針を決定"]
    print --> decide
    script --> decide

図17: ログオンスクリプト依存の配布は移行で手段が先に消えるため、置き換え先をパイロット中に決めておく。

8.3. キッティングの再設計 ── Autopilotは「必須」ではない

Intune移行とセットでAutopilotを勧められることがありますが、年に数台〜十数台の調達なら、OOBEで職場アカウントにサインインし、手動でEntra joinする運用でも実害はありません。

Autopilotが効くのは、調達台数が増えて開梱からの無人セットアップに価値が出るときや、販売店側のデバイス登録を使えるときです。7章②③が整ってから足せばよく、移行の前提条件ではありません。

flowchart TB
    accTitle: Autopilot導入の判断
    accDescr: 年に数台から十数台の調達規模ならOOBEで手動でEntra joinする運用で実害はなく、調達台数が増えて無人セットアップに価値が出てきたときにAutopilotを後から足せばよい
    scale{"年間の調達規模は?"} -->|数台〜十数台| manual["OOBEで手動Entra join"]
    scale -->|台数が増えたら| ap["Autopilotで無人化"]
    ap -.-> later["②③が整ってから足す"]

図18: 調達規模が小さいうちは手動のEntra joinで足り、Autopilotは後から足せばよい。

8.4. 「全部Intuneにしないと駄目」という誤解

Entra join機とドメイン参加機の共存は正式にサポートされた構成です。ADが残っていることは、移行失敗を意味しません。¹

GPOに数個の設定が残ったまま、数年併走する会社も珍しくありません。それでも、新しいPCをすべてクラウドで管理し、社外でも統制できる状態には大きな価値があります。完全移行の形にこだわるより、後戻りできる小さな前進を優先してください。

flowchart TB
    accTitle: 完全移行にこだわらない併走の価値
    accDescr: ADが残っていれば移行失敗というわけではなく、GPOに設定が残ったまま数年併走しても、新しいPCがすべてクラウド管理で社外でも統制が効く状態には大きな価値がある
    miscon["ADが残れば移行失敗?"] -->|そうではない| run["GPOが残ったまま数年併走"]
    run --> value["新規PCは社外でも統制が効く"]
    value -.-> forward["小さな前進を優先"]

図19: ADが残ったままの併走でも、新しいPCがすべてクラウド管理になる状態には大きな価値がある。

9. 情シス1人体制での現実解

担当者が1人、または兼任の会社では、導入後に維持できる範囲を先に決めます。

管理項目と標準PC像を絞る

最初の管理項目は、7章②の5点(更新・暗号化・Defender・画面ロック・LAPS)に絞ります。必要が生じた設定だけを足す考え方です。設定カタログに数千の設定があっても、全部を使う義務はありません。¹⁰

標準PC像も、「この会社のPCはこのポリシー群とこのアプリ群」という1セットに決めます。部署別の例外はグループやフィルターで表現できますが、例外が増えるほど1人では維持しにくくなります。

外部には設計を頼み、日常運用は自分で回せるようにする

外部パートナーには、初期設計、ポリシーのテンプレート作成、移行判断の相談を求めます。日々のPC追加やポリシーの微調整は、自分でできる状態をゴールにしてください。

構築を丸投げして「管理画面の意味が誰も分からない」状態にしないことが重要です。日常運用まで引き継いでくれるパートナーを選びます。

変更は1件ずつ、レポートで確認してから次へ

ポリシー変更は一度に1件だけ行い、Intuneのレポートで適用状態や割り当ての失敗を確認してから次に進みます。

MDMの定常同期は約8時間周期です。「反映されない」の大半は故障ではなく時間の問題なので、同期間隔を踏まえて結果を確認します。³

flowchart TB
    accTitle: ポリシー変更の運用サイクル
    accDescr: ポリシー変更は1件ずつ行い、Intuneのレポートで適用状態を確認してから次の変更に進む。反映されない場合の大半は約8時間周期の同期を待てば解決する
    change["ポリシー変更を1件だけ行う"] --> report["レポートで適用状態を確認"]
    report --> next["問題なければ次の変更へ"]
    next --> change
    report -.-> wait["未反映の大半は同期待ち"]

図20: ポリシー変更は1件ずつ行い、レポートで結果を確認してから次に進む。

10. まとめ

GPOからIntuneへの移行は、社外PCへ管理を届ける方法を変え、不要な設定を減らしていく取り組みです。GPOはドメインコントローラーへの到達が前提ですが、Intuneはインターネット経由で同期します。ただし、約8時間の定常同期間隔と変更時の通知を踏まえて運用する必要があります。

進め方は、新規PCをEntra join+Intuneへ切り替え、既存PCはリプレースサイクルで置き換える段階移行が基本です。オンプレ資産へのSSOの前提を確認し、ADに認証などの役割が残るなら共存を続けます。

現行GPOはGroup Policy analyticsで棚卸しし、「捨てる・移す・代替する」に仕分けます。日本語GPOのサポート率は参考値とし、設定単位で判断してください。そのうえで、パイロット→基本ポリシー→アプリ配布→既存PCの置換→ADの役割縮小の5段階を、完了条件つきで進めます。

移行中は同じ設定をGPOとMDMの両方から配らないことが原則です。MDMWinsOverGPでMDMを優先できるのはPolicy CSP配下に限られるため、優先制御に依存しない構成にします。

ライセンスはBusiness Premiumを出発点にできますが、Remediationsなどの対象範囲と最新の契約内容は公式情報で確認します。費用はサーバー更改と5年分の差額を比較し、社外PCへの管理という能力差も含めて判断してください。

サーバー更改の見積りが出たときは、この移行を検討するよいタイミングです。「ADをもう一周」の前に、次の5年のPCがどこで使われるかを考えるところから始めてください。

関連記事

• グループポリシー(GPO)実務入門 ── 仕組み・反映確認・Intuneとの使い分け
• WSUS非推奨後のWindows Update管理 ── WUfB・Autopatch・Intuneをどう選ぶか
• Windows 10サポート終了後の現実解 ── ESU・LTSC・買い替えの判断表
• winget + PowerShellでPCキッティングを自動化する ── 手順書を実行可能にする
• BitLocker実務ガイド ── 回復キーの管理から始めるドライブ暗号化
• Windows LAPS実務ガイド ── 全PC共通のローカル管理者パスワードをやめる

関連する相談領域

合同会社小村ソフトでは、AD+GPO環境からEntra ID+Intuneへの段階移行の設計(現行GPOの棚卸し、ポリシーの再現方針、パイロット計画)、サーバー更改とクラウド移行の比較検討、既存の業務アプリ・キッティング資産を活かした移行の相談を扱っています。「ADサーバーをもう一度買うべきか」を一緒に検討するところからで構いません。

• 技術相談・設計レビュー
• 既存資産活用・移行支援
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

GPOからIntuneへ移行すると、いま使っているグループポリシーの設定はすべて再現できますか？

すべては再現できません。Intuneの設定カタログにはADMX由来を含む数千のWindows設定があり、大半のセキュリティ設定や制限は移せますが、ログオンスクリプトによるドライブマップやプリンター一括配布のように、MDMに対応する設定が存在しないものもあります。IntuneのGroup Policy analyticsに現行GPOのXMLエクスポートを取り込むと、設定ごとに移行可否(Ready for migration / Not supported / Deprecated)を仕分けできます。代替がない設定は、PowerShellスクリプトの配布やアプリ化、あるいは「その設定をやめる」ことで対応します。

Intuneを使うにはどのライセンスが必要ですか？

基本となるのはMicrosoft Intune Plan 1で、単体でも契約できますが、中小企業ではMicrosoft 365 Business Premium(300ユーザーまで)に含まれる形で使うのが一般的です。Business PremiumにはEntra ID P1も含まれるため、コンプライアンスポリシーと条件付きアクセスの組み合わせまで利用できます。一方、Remediationsのように、Windows Enterprise E3/E5系のライセンスを別途要求する機能もあります。プラン構成は頻繁に変わるため、契約前にMicrosoftの公式ライセンスページで最新の内容を確認してください(本記事は2026年8月時点)。

ADサーバーはすぐに廃止しなければいけませんか？

いいえ。Entra join+Intuneで管理するPCと、ADドメイン参加+GPOで管理するPCは同じ社内ネットワークで共存できます。ファイルサーバーの認証や既存業務システムのためにADを残したまま、新規PCだけをEntra joinにする段階移行が現実的です。逆に、既存のドメイン参加PCをEntra joinへ「変換」する正式な手段はなくワイプ(初期化)が必要になるため、既存機はリプレースサイクルで置き換えるのが定石です。ADの廃止はGPOが空になり、残存する役割を洗い出せてから検討すれば十分です。

在宅勤務のPCにグループポリシーが適用されないのはなぜですか？

GPOはドメインコントローラーに接続できるときに取得・適用される仕組みだからです。社外のPCはVPNなどでドメインコントローラーに到達できた時にしか最新のポリシーを受け取れず、VPNを使わない在宅PCには実質的に届きません。Intune(MDM)はインターネット経由でポリシーを同期するため、PCがどこにあっても管理でき、社外PCの管理という課題はMDM側の構造で解消します。おおよそ8時間ごとの定期同期に加え、ポリシー変更時には通知による同期も行われます。

GPOとIntuneの両方から同じ設定を配ったらどちらが優先されますか？

既定では、競合する設定はグループポリシー側が優先されます。MDMWinsOverGPポリシーを1に設定するとMDM(Intune)側が優先されるようになりますが、この仕組みが効くのはPolicy CSP配下の設定に限られ、Defender CSPなど他のCSPで定義される設定には適用されません。優先制御に頼ると挙動の予測が難しくなるため、実務では「同じ設定を両方のチャネルから配らない」ことを原則にし、Intuneへ移した設定は元のGPOから削除して二重管理を避けるのが安全です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。