Microsoft Intuneの「Co-management for Windows devices – Configuration Manager」は、Configuration Managerをすぐに廃止する話ではありません。結論から言うと、既存のConfiguration Manager管理を残しながら、WindowsデバイスをMicrosoft Intuneにも登録し、更新管理・コンプライアンス・アプリ配布などの管理権限をワークロード単位で段階的に移すための仕組みです。公式情報では、Configuration Managerクライアントがあり、Intuneにも登録されたWindowsデバイスに対して、両サービスの利点を使えると説明されています。(Microsoft Learn)
2026年5月19日前後の確認ポイントとして重要なのは、「何かを一括移行する」ことではなく、共同管理の前提条件、クラウド接続、ワークロード移行、監視方法を改めて点検することです。MicrosoftDocsの履歴では、対象ドキュメントに2026年5月18日付でSFI関連のメタデータ追加が確認できますが、管理者が実務で見るべき中心は、本文に記載されている共同管理の設計・展開条件です。(GitHub)
Microsoft IntuneのCo-managementとは
Co-managementは、Configuration ManagerとMicrosoft IntuneでWindowsデバイスを同時に管理する構成です。既存のConfiguration Manager環境をクラウドに接続し、条件付きアクセス、デバイス準拠状態、Intuneのリモート操作、Windows Autopilotなどのクラウド機能を段階的に活用できます。(Microsoft Learn)
ポイントは、すべての管理を一度にIntuneへ移す必要がないことです。Configuration Managerで管理し続けるワークロードと、Intuneへ移すワークロードを分けられます。たとえば、最初はコンプライアンスポリシーだけをIntuneに移し、Windows Updateやアプリ配布はConfiguration Managerに残す、といった移行が可能です。(Microsoft Learn)
一方で、Co-managementは「リモート端末をConfiguration Managerで管理できるようにする魔法の機能」ではありません。社外端末にConfiguration Managerクライアントとして通信させたい場合は、Cloud Management Gateway、いわゆるCMGの利用を検討する必要があります。公式情報でも、CMGはCo-managementに必須ではないものの、リモート接続されたWindowsシステムをConfiguration Managerで管理するにはCMGが必要になる場合があると説明されています。(Microsoft Learn)
今回の公式情報で押さえるべき変更点と実務上の意味
今回の確認で管理者が押さえるべき点は、単なる「更新あり・なし」ではなく、Co-managementを導入・見直しする際の判断軸です。特に、Configuration Manager Current Branchのサポート状況、Microsoft Entra IDへの参加状態、Intune自動登録、ワークロード移行、Tenant attachのデータ送信範囲を確認する必要があります。
| 確認ポイント | 実務上の意味 | 管理者が取るべき行動 |
|---|---|---|
| Co-managementの位置付け | Configuration ManagerとIntuneの併用が前提 | 「Intuneへ全移行」と誤解せず、ワークロード単位で計画する |
| 対象デバイス | Microsoft Entra joinedまたはMicrosoft Entra hybrid joinedが必要 | Microsoft Entra registeredのみの端末を対象にしない |
| Configuration Manager | サポート対象のCurrent Branchが必要 | サイト・クライアント・コンソールのバージョンを確認する |
| Intune自動登録 | MDMユーザースコープ設定が必要 | 対象ユーザーまたはグループを段階的に設定する |
| ワークロード移行 | Intuneへ移したものだけ管理主体が変わる | 先にIntune側のポリシーを作成・検証する |
| Tenant attach | Intune admin centerへデバイスをアップロードできる | データ送信、RBAC、対象コレクションを確認する |
Configuration Manager Current Branchは、Microsoft Learnのサポート表でバージョンごとの提供日とサポート終了日が示されています。2026年5月時点では2603、2509、2503、2409などがサポート対象として掲載されているため、Co-management以前に、まず自社サイトがサポート対象かを確認するのが安全です。(Microsoft Learn)
対象になる管理者・開発者
Co-managementの影響を受けるのは、Intune管理者だけではありません。Configuration Manager担当、ID管理担当、セキュリティ担当、アプリ配布担当、社内アプリ開発チームまで関係します。
| 対象者 | 影響を受ける領域 | 確認すべきこと |
|---|---|---|
| Configuration Manager管理者 | 既存クライアント、コレクション、ソフトウェア更新、配布ポイント | Co-management Eligible Devices、CMG、クライアント正常性 |
| Intune管理者 | デバイス登録、構成プロファイル、準拠ポリシー、アプリ配布 | MDM自動登録、Intuneポリシー、割り当てグループ |
| Microsoft Entra ID管理者 | ハイブリッド参加、自動登録、権限 | Microsoft Entra joined / hybrid joinedの状態 |
| セキュリティ管理者 | 条件付きアクセス、Defender、BitLocker、準拠状態 | どのワークロードをIntuneへ移すか |
| アプリ担当・開発者 | Win32アプリ、PowerShellスクリプト、Company Portal表示 | Intune配布とSoftware Center配布の切り分け |
特に開発者やアプリ配布担当は、「アプリがどこに表示され、どのクライアントがインストールを実行するのか」を確認しておく必要があります。Client appsワークロードをIntuneへ移すと、Intuneから展開された利用可能アプリはCompany Portalに表示され、Configuration Managerから展開されたアプリはSoftware Centerに表示されます。(Microsoft Learn)
Co-managementの2つの導入パス
Co-managementには、大きく2つの導入パスがあります。どちらを選ぶかで、必要な設計と失敗しやすい箇所が変わります。
既存のConfiguration ManagerクライアントをIntuneへ自動登録する
すでに社内PCをConfiguration Managerで管理している場合は、このパスが基本です。オンプレミスActive DirectoryとMicrosoft Entra IDを連携し、デバイスをMicrosoft Entra hybrid joinedにしたうえで、Intuneへの自動登録を構成します。公式チュートリアルでも、既存のConfiguration Managerクライアントをクラウド接続する前提で、ハイブリッドMicrosoft Entra ID、クライアント設定、Intune自動登録、Co-management有効化の流れが示されています。(Microsoft Learn)
このパスが向いているのは、既存PCが多く、すでにOS展開、更新管理、アプリ配布をConfiguration Managerで運用している組織です。最初からIntuneへ全移行するよりも、Pilotコレクションで小さく始められるため、業務影響を抑えやすいのが利点です。
新しいインターネットベース端末から始める
新規端末をMicrosoft Entra joinedとしてIntuneへ登録し、その後Configuration Managerクライアントを導入して共同管理状態にする方法もあります。公式情報では、既存クライアントをIntuneへ登録するパスと、新しいインターネットベースデバイスにConfiguration Managerクライアントを導入するパスが示されています。(Microsoft Learn)
このパスは、Windows Autopilotやクラウドファーストの端末展開と相性がよい一方で、Configuration Managerクライアントが社内サイトと通信する設計が必要です。社外端末が多い場合は、CMG、証明書、境界グループ、コンテンツ配布の設計を先に確認してください。
導入前に必ず確認する前提条件
Co-managementで最初に失敗しやすいのは、Intuneのポリシー設定ではなく前提条件です。次の条件を満たしていないと、自動登録が失敗したり、対象デバイスが共同管理状態にならなかったりします。
ライセンス
公式情報では、Co-managementの前提としてMicrosoft Entra ID P1またはP2、管理者がIntune admin centerへアクセスするためのIntuneライセンスが挙げられています。加えて、Intuneのライセンス情報では、既存のConfiguration Manager管理デバイスをユーザー操作なしでIntuneへ大規模登録するCo-managementのシナリオで、Microsoft Entra ID P1またはP2とIntune Plan 1が必要と説明されています。(Microsoft Learn)
ライセンス確認では、ユーザーにIntuneが割り当たっているかだけでなく、条件付きアクセスや自動登録に必要なMicrosoft Entra IDのプランも確認してください。デバイスのみのライセンスでは、条件付きアクセスなど一部のユーザーベース機能が使えない点にも注意が必要です。(Microsoft Learn)
Microsoft Entra IDの参加状態
Co-management対象のWindowsデバイスは、Microsoft Entra joinedまたはMicrosoft Entra hybrid joinedである必要があります。Microsoft Entra registered、いわゆる職場または学校アカウントの登録だけの状態は、Co-managementではサポートされません。(Microsoft Learn)
実務では、対象PCを抽出する前に、次の状態を棚卸しします。
- Microsoft Entra joinedのクラウド参加端末
- Microsoft Entra hybrid joinedのドメイン参加端末
- Microsoft Entra registeredのみの端末
- Configuration Managerクライアントが正常に動作していない端末
- Windowsのサポート状態に問題がある端末
Windows 10は2025年10月14日にサポート終了となり、Intuneでは「allowed version」として登録や一部機能利用は可能でも、機能動作は保証されない可能性があると公式情報で説明されています。Co-managementの設計では、Windows 11への移行計画も同時に確認するべきです。(Microsoft Learn)
Configuration Managerのバージョン
Co-managementには、サポート対象のConfiguration Manager Current Branchが必要です。新規サイトを構築する場合は最新のベースラインを使い、既存サイトはコンソール内更新で最新バージョンへ更新する流れが公式情報で説明されています。(Microsoft Learn)
確認場所は、Configuration Managerコンソール左上の「About Configuration Manager」です。サイトバージョン、コンソールバージョン、クライアントバージョンを分けて確認してください。サイトだけが更新済みでも、クライアント更新が遅れていると、自動登録やワークロード移行の検証で差が出ます。
ワークロード移行は「小さく始める」が基本
Co-managementで移行できるワークロードには、Compliance policies、Windows Update policies、Resource access policies、Endpoint Protection、Device configuration、Office Click-to-Run apps、Client appsがあります。公式情報では、ワークロードをまったく切り替えないことも、個別に切り替えることも、複数まとめて切り替えることも可能と説明されています。(Microsoft Learn)
| ワークロード | Intuneへ移す判断基準 | 注意点 |
|---|---|---|
| Compliance policies | 条件付きアクセスと準拠状態を使いたい | 先に準拠ポリシーと除外条件を設計する |
| Windows Update policies | Windows Update for BusinessやAutopatchへ寄せたい | Configuration Manager側のソフトウェア更新ワークフローを調整する |
| Resource access policies | VPN、Wi-Fi、証明書などをIntune管理へ寄せたい | Configuration Manager 2203以降では関連機能の非サポートに注意する |
| Endpoint Protection | Defender、Firewall、BitLockerなどをIntune中心にしたい | 移行中は既存ポリシーとIntuneポリシーの上書き関係を確認する |
| Device configuration | 設定カタログや構成プロファイルへ移したい | Resource accessとEndpoint Protectionも含まれる点に注意する |
| Office Click-to-Run apps | Microsoft 365 AppsをIntuneで管理したい | Office更新の反映に時間がかかる場合がある |
| Client apps | Win32アプリやCompany Portal中心にしたい | Software Centerとの表示・配布経路を利用者へ説明する |
Windows Update workloadをIntuneへ移した後は、Configuration Managerのクライアント設定でソフトウェア更新ワークフローを無効化するなど、手動調整が必要です。Autopatchを使う場合も、Windows Update workloadをIntuneへ移し、Configuration Manager側のSoftware Updates設定を「No」にする前提が説明されています。(Microsoft Learn)
Resource access policiesは特に注意が必要です。公式情報では、Configuration Manager 2203以降でこれらの会社リソースアクセス機能とCo-managementワークロードはサポートされなくなったと説明され、2403以降では関連ノードの削除やIntune側への移行前提が示されています。古いVPN、Wi-Fi、証明書プロファイルを残している環境は、移行前に棚卸ししてください。(Microsoft Learn)
展開手順の実務フロー
Co-managementは、ウィザードを進めるだけなら短時間で設定できます。しかし、実運用では「有効化する前の棚卸し」と「ワークロードを移す前のIntune側準備」が成否を分けます。
| 手順 | 作業内容 | 失敗を避ける確認点 |
|---|---|---|
| 事前棚卸し | 対象PC、OS、ConfigMgrクライアント、Entra参加状態を確認 | Microsoft Entra registeredのみの端末を除外 |
| ID連携確認 | Microsoft Entra hybrid joinまたはMicrosoft Entra joinを確認 | ハイブリッド参加の同期遅延を考慮 |
| Intune自動登録 | MDMユーザースコープを設定 | MAMスコープとの競合に注意 |
| Cloud attach設定 | 既定設定またはカスタム設定を選択 | Tenant attachのデータ送信範囲を確認 |
| Co-management有効化 | All、Pilot、Noneから登録範囲を選択 | いきなりAllにしない |
| Pilot展開 | 小規模コレクションで検証 | ワークロードごとにPilotを分ける |
| ワークロード移行 | Intune側のポリシー作成後に切り替え | 移行前後で二重適用を確認 |
| 監視 | ダッシュボードと登録エラーを確認 | Pending user sign inやライセンスエラーを追跡 |
Configuration Manager 2111以降では、Cloud Attach Configuration WizardによりCo-managementや関連クラウド機能を有効化しやすくなっています。ただし、新しいウィザードでは、Co-managementを有効化した時点でワークロードを同時に移すわけではありません。ワークロードを移すには、Cloud AttachノードのCo-management設定を後から編集します。(Microsoft Learn)
Cloud attachとTenant attachの違いを混同しない
Co-managementを調べていると、Cloud attach、Tenant attach、Endpoint analytics、Co-managementが一緒に出てくるため、混乱しやすくなります。
Cloud attachは、Configuration Manager環境をクラウド機能へ接続する大きな枠組みです。既定設定では、対象デバイスのIntune自動登録、Endpoint analytics、Intune admin centerへのデバイスアップロード、Microsoft Defender for Endpointデータのアップロードなどを有効化できます。(Microsoft Learn)
Tenant attachは、Configuration Managerで管理しているデバイスをMicrosoft Intune admin centerへアップロードし、クラウド側のコンソールからデバイス情報確認や一部アクションを行えるようにする機能です。公式情報では、Configuration ManagerサイトをIntuneテナントへ接続すると、追加データがMicrosoftへ送信されると明記されています。(Microsoft Learn)
そのため、セキュリティ部門や監査部門には、次の点を事前に説明しておくとスムーズです。
- どのコレクションのデバイスをアップロードするのか
- Endpoint analyticsを有効化するのか
- Defender for EndpointデータをIntune admin centerでレポートするのか
- Configuration Manager RBACとIntune RBACをどう使い分けるのか
- Microsoft Entraアプリ登録やシークレットを誰が管理するのか
特に、既存のMicrosoft Entraアプリをインポートして使う場合、アプリを複数階層で共有しないこと、シークレット期限を自分たちで管理することが重要です。公式情報では、インポートしたMicrosoft Entraアプリでは有効期限切れの通知を受け取れないと説明されています。(Microsoft Learn)
自動登録で失敗しやすい設定
既存Configuration ManagerクライアントをIntuneへ登録する場合、Microsoft Entra ID側でMDM自動登録を構成します。公式チュートリアルでは、Microsoft Entra IDのMobility設定からMicrosoft IntuneのMDM user scopeをSome、All、Noneのいずれかで設定する流れが示されています。(Microsoft Learn)
注意すべきなのは、MAM user scopeとMDM user scopeの競合です。公式情報では、MAM user scopeと自動MDM登録の両方が同じグループで有効な場合、MAMのみが有効になり、デバイスは自動的にMDM登録されないと説明されています。(Microsoft Learn)
実務では、次の順で確認すると切り分けしやすくなります。
- 対象ユーザーがMDM user scopeに含まれているか
- MAM user scopeが同じグループに重なっていないか
- 対象端末がMicrosoft Entra joinedまたはhybrid joinedか
- Configuration Managerクライアントが正常にポリシーを取得しているか
- IntuneライセンスとMicrosoft Entra ID P1/P2が不足していないか
- デバイス登録制限でWindowsがブロックされていないか
監視はCo-management dashboardから始める
Co-management有効化後は、Configuration ManagerコンソールのMonitoringワークスペースからCloud Attachノードを開き、Co-management dashboardを確認します。公式情報では、このダッシュボードで共同管理された端末を確認でき、注意が必要なデバイスをグラフで特定できると説明されています。(Microsoft Learn)
見るべき項目は、主に次の4つです。
| 監視項目 | 見るべき内容 | 対応例 |
|---|---|---|
| Client OS distribution | 古いWindowsや対象外OSが残っていないか | Windows 11移行計画や除外方針を決める |
| Co-management status | Eligible、Scheduled、Enrollment initiated、Enrolledの推移 | 登録が進まないコレクションを特定 |
| Enrollment status | Success、Failure、Pending user sign inなど | ライセンス、MDM設定、Entra参加状態を確認 |
| Workload transition | 各ワークロードがIntuneへ移行済みか | 想定外のワークロード移行を検知 |
登録エラーには、MDM登録未構成、ユーザーライセンス不備、Microsoft Entra構成の未反映、デバイス非対応などがあります。公式情報では、エラー一覧と説明がCo-management dashboardのEnrollment errorsとして示されています。(Microsoft Learn)
管理者・開発者が移行前に作るべきチェックリスト
Co-managementは、技術的には「有効化」よりも「運用設計」が重要です。以下のチェックリストを埋めてからPilotを開始すると、手戻りを減らせます。
管理者向けチェックリスト
| 項目 | 確認内容 |
|---|---|
| 対象範囲 | 全社、部門、検証端末、IT部門端末のどこから始めるか |
| ID状態 | Microsoft Entra joined / hybrid joinedが成立しているか |
| OS状態 | Windows 11またはIntune対応Windowsか |
| ConfigMgr状態 | サポート対象Current Branchか、クライアント正常性は問題ないか |
| Intune状態 | MDM authority、MDM user scope、ライセンスが正しいか |
| ネットワーク | 社外端末にCMGが必要か |
| RBAC | Configuration Manager RBACとIntune RBACの責任分界があるか |
| データ送信 | Tenant attach、Endpoint analytics、Defenderデータ送信を承認済みか |
| Pilot | ワークロードごとに検証コレクションを用意したか |
| ロールバック | ワークロードを戻した場合の影響を把握しているか |
ワークロードは後からConfiguration Managerへ戻せますが、影響がゼロとは限りません。公式情報でも、IntuneでインストールされたWindowsやOfficeのバージョンは、戻した後も新しい状態のまま残る可能性があると説明されています。(Microsoft Learn)
開発者・アプリ担当向けチェックリスト
| 項目 | 確認内容 |
|---|---|
| アプリ配布経路 | Intune、Configuration Manager、両方のどれで配布するか |
| 表示場所 | Company PortalとSoftware Centerのどちらに表示されるか |
| 検出ルール | Win32アプリの検出条件が正しく動作するか |
| インストール権限 | ユーザーコンテキストかシステムコンテキストか |
| 再起動 | 再起動要求、終了コード、ユーザー通知を整理したか |
| 依存関係 | ランタイム、前提アプリ、VPN接続の有無を確認したか |
| スクリプト | PowerShellスクリプトの実行条件とログ確認方法を用意したか |
| サポート窓口 | 利用者にCompany PortalとSoftware Centerの違いを案内したか |
Client appsワークロードをIntuneへ移しても、Configuration Managerから展開したアプリがすべて消えるわけではありません。どのアプリをどちらで配布するかを明確にしないと、利用者から「同じアプリが複数見える」「Company Portalにない」「Software Centerにはある」といった問い合わせが増えます。(Microsoft Learn)
よくある失敗と回避策
Co-managementを有効化しただけでIntune管理に切り替わったと思い込む
Co-managementを有効化しても、ワークロードは自動的にIntuneへ移りません。Cloud attachの公式情報でも、デバイスを登録してもワークロードはIntuneへ移動せず、準備できた段階でCo-management設定を編集して移すと説明されています。(Microsoft Learn)
回避策は、ワークロードごとに「現状の管理元」「移行後の管理元」「Intune側の準備状況」を表にして管理することです。
PilotなしでAllを選ぶ
Allで自動登録を有効にすると、対象デバイスが広範囲にIntune登録されます。大規模環境では登録が一度に完了するわけではなく、Configuration Managerは登録処理をランダム化し、たとえば10万台規模では数日にわたって登録が進むと説明されています。(Microsoft Learn)
回避策は、IT部門、特定拠点、標準構成PCなど、問題発生時に切り戻しやすいグループから始めることです。
Windows Updateを移したのにConfiguration Manager側の更新設定を残す
Windows Update workloadをIntuneへ移した後も、Configuration Manager側のソフトウェア更新ワークフローが残っていると、管理方針が分かりにくくなります。公式情報では、Windows Update workloadをIntuneへ移した後、Configuration Managerのクライアント設定を手動で調整する必要があると説明されています。(Microsoft Learn)
回避策は、移行前に更新リング、機能更新ポリシー、品質更新ポリシー、再起動猶予、除外端末をIntune側で設計してから、Pilotコレクションで適用することです。
Microsoft Entra registered端末を対象にしてしまう
Microsoft Entra registeredのみの端末はCo-managementの対象としてサポートされません。対象端末がMicrosoft Entra joinedまたはhybrid joinedであることを確認してから進めてください。(Microsoft Learn)
回避策は、登録前の棚卸しでデバイス状態を分け、Microsoft Entra registeredのみの端末は別の登録・管理方式にすることです。
次に取るべき行動
Co-management for Windows devices – Configuration Managerを検討している管理者は、まず「移行」ではなく「棚卸し」から始めるべきです。Configuration Managerのサポートバージョン、Windowsのサポート状態、Microsoft Entra ID参加状態、Intuneライセンス、MDM自動登録、CMGの要否を確認してください。
そのうえで、最初に移すワークロードを1つ選びます。多くの組織では、条件付きアクセスと連携しやすいCompliance policies、またはクラウド更新管理へつなげやすいWindows Update policiesが候補になります。ただし、Windows Updateを移す場合はConfiguration Manager側の更新設定調整が必要です。アプリ配布を移す場合は、Company PortalとSoftware Centerの利用者体験を事前に説明してください。
Co-managementは、Configuration Managerを捨てるための機能ではなく、Intuneへ安全に管理範囲を広げるための段階移行の仕組みです。最初の一歩は、Pilotコレクションを作り、Intune側のポリシーを先に用意し、ダッシュボードで登録状態とエラーを確認することです。これを徹底すれば、既存運用を壊さずにWindowsデバイス管理をクラウドへ広げられます。
コメント