Microsoft が Intune 移行計画ガイドを更新した今、Intune 移行計画で最初にやるべきことは、管理コンソールを触ることではありません。先に決めるべきなのは、どの端末を MAM（アプリ単位）で守るのか、どの端末を MDM（端末全体）で管理するのか、既存の GPO や Configuration Manager をどう残すのか、そしてどの順番で展開するのかです。公式の Intune planning guide は、その順番で「目的」「端末棚卸し」「ライセンス」「既存ポリシー」「ロールアウト」を整理しており、Microsoft も Intune セットアップ前に確認する前提資料として案内しています。(GitHub)
今回の「更新」は、MicrosoftDocs の GitHub 履歴では 2026年4月9日に IA alignment と fix broken links のコミットが確認でき、3月2日には licensing、3月5日には updates といった履歴も見えます。一方で、公開中ファイルの ms.date と Learn ページの最終更新表示は 2025-08-21 のままです。そのため、4月の更新は大規模な本文刷新というより、2026年春の情報設計や導線整備を含む継続メンテナンスと見るのが安全です。(GitHub)
この記事では、この Intune 移行計画ガイドをどう読むべきか、エンドポイント管理を統合する組織にとってなぜ今タイムリーなのか、そして読んだ直後に何から着手すべきかを、実務ベースで整理します。
今回の更新が軽く見えない理由
4月9日の履歴だけを見ると、更新内容は「情報設計の調整」や「リンク修正」が中心に見えます。ですが、だから重要度が低いわけではありません。Microsoft は 2026年3月更新の Intune セットアップ記事でも planning guide を前提資料として参照させており、Windows の cloud-native endpoints 向け計画ガイドでも Intune planning guide を中核リソースの一つとして案内しています。つまり、このガイドは今も「移行前に読むべき土台」の位置づけを維持しています。(Microsoft Learn)
さらに Microsoft の公式整理では、Intune ファミリーには Intune サービスだけでなく、Configuration Manager と co-management、Endpoint Analytics、Windows Autopilot、Intune admin center が含まれます。これは Intune が単独製品ではなく、オンプレ・クラウド・モバイル・デスクトップをまたぐ統合エンドポイント管理の中心に置かれていることを示しています。(Microsoft Learn)
なぜ今の Intune 移行計画に効くのか
今この Intune 計画ガイドがタイムリーなのは、Microsoft のメッセージがかなり明確になっているからです。Configuration Manager は version 2609 から年1回リリースへ移行し、Microsoft は「新しいイノベーションは Intune で進む」と説明しています。Configuration Manager をすぐ捨てる必要はありませんが、少なくとも「どこまで共存し、どこから Intune に寄せるか」を計画しないまま先送りしにくい状況です。(TECHCOMMUNITY.MICROSOFT.COM)
加えて、Intune の “What’s new” では 2026年3月に guided scenarios がほぼ削除され、代わりにドキュメントや prescriptive guides が案内されています。要するに、ウィザード任せで進めるより、設計ドキュメントを読んで自社方針を決める重要性が高まっています。planning guide の再確認が価値を持つのは、この流れとも噛み合っているためです。(Microsoft Learn)
Microsoft の cloud-native endpoints 向けガイドも、Windows 端末のクラウド移行は一夜にして終わるものではなく、計画不足は問題や停止、ユーザー影響を招くと明言しています。統合プロジェクトで本当に不足しやすいのは製品知識よりも、順番と線引きです。(Microsoft Learn)
公式ガイドで最初に決めるべき5項目
公式ガイドの Step 1〜5 を、実務で判断しやすい形に整理すると次の通りです。(GitHub)
| 論点 | 先に決めること | 実務上の判断基準 |
|---|---|---|
| 管理目的 | アプリ利用だけを守るのか、端末全体を管理するのか | メール・Teams・文書中心なら MAM を優先。端末設定やワイプまで必要なら MDM を優先 |
| 端末区分 | BYOD、社給端末、既存 ConfigMgr 管理端末、共有端末をどう分けるか | 端末種別ごとに別設計にする。1本化より「分けて統合」のほうが失敗しにくい |
| ライセンス | Intune だけで足りるか、Entra ID P1/P2 や Microsoft 365 Apps が要るか | Conditional Access や準拠判定を使うなら Entra ID P1/P2 まで確認する |
| 既存ポリシー | GPO や古い MDM 設定を何%残すか | 1:1 移植ではなく「目的が残るものだけ残す」で判断する |
| 展開順序 | 誰から入れるか、どう拡大するか | 小規模パイロット→拡張→本番。役員先行は避ける |
管理目的を先に決める
planning guide は最初に「組織アプリとメールへのアクセス」「全端末での安全なアクセス」「Distributed IT」「組織データの持ち出し防止」といった目的から考える構成です。ここを飛ばしていきなりポリシー作成に入ると、必要以上に厳しい管理か、逆に抜け漏れだらけの管理になりがちです。(Microsoft Learn)
実務では、たとえば営業部門がスマホで必要なのが Outlook、Teams、SharePoint だけなら、最初から端末全体を MDM 登録する必要がないことがあります。公式ガイドも、個人端末で必要なのが会社メールやドキュメント中心なら、Microsoft 365 アプリに app protection policies を適用する方法を示しており、端末自体を Intune に登録しない選択肢を認めています。BYOD を全部フル管理前提で考えないことが、移行計画ではかなり重要です。(Microsoft Learn)
端末を棚卸しして MAM・MDM・共存方針を分ける
Step 2 では、まず端末の棚卸しが求められます。Intune は複数プラットフォームを支援していますが、古い OS や未サポート端末はアップグレードか置き換えが前提になります。ここを曖昧にすると、移行プロジェクト後半で「この端末だけ登録できない」「このモデルだけポリシーが当たらない」という典型的な詰まり方をします。(Microsoft Learn)
端末区分の考え方も、planning guide はかなり実務的です。BYOD は MAM 寄り、社給端末は MDM 寄り、既存の Windows 端末で Configuration Manager を使っているなら co-management や tenant attach を検討、新規端末や未管理端末は Intune 直行が候補になります。さらに、共有タブレットやスキャナーのような frontline worker 端末は別シナリオで設計すべきだと示しています。1つの正解に寄せるより、端末タイプごとに管理方式を分けるほうが現実的です。(Microsoft Learn)
ライセンスを運用シナリオで見る
ライセンスは「何が買えるか」ではなく、「何を運用したいか」で見るべきです。公式ガイドでは、ポリシーやプロファイルの作成だけなら最低限 Intune、準拠判定やパスワードルールの強制まで行うなら Intune に加えて Microsoft Entra ID P1 または P2、Microsoft 365 アプリ配布まで含めるなら Microsoft 365 apps も必要、という整理になっています。Defender for Endpoint や Intune Suite は高度な保護や管理を広げる選択肢です。(Microsoft Learn)
見落としやすいのが Configuration Manager 併用時です。公式ガイドでは、co-management を使うだけなら Configuration Manager ライセンスに含まれる Intune を使える一方、Intune で新規端末や既存の co-managed 端末をフル管理したいなら別途 Intune ライセンスが必要と説明しています。「いま動いているから足りている」と判断すると、移行後の本番拡大で止まりやすいポイントです。(Microsoft Learn)
GPO をそのまま持ち込まない
Step 4 の価値はここです。planning guide は、長年メンテだけされてきた GPO や古い管理基盤を前提に考えるのではなく、「その設定の目的は何か」を起点に見直すよう勧めています。これは Intune 移行計画で最も重要な視点のひとつです。(Microsoft Learn)
オンプレの AD GPO には LSDOU の階層がありますが、Intune はユーザーやグループへの割り当てベースで、同じ設定がぶつかると競合として見えます。つまり、GPO の構造をそのままクラウドへ移せば再現できるわけではありません。公式ガイドは、Intune settings catalog を GPO/ADMX に近い選択肢として案内し、group policy analytics で既存 GPO を取り込んで MDM 互換性を確認する流れを示しています。GPO の「設定名」ではなく「意図」を移す、これが正攻法です。(Microsoft Learn)
最低限のベースラインを決める考え方も参考になります。ガイドでは、Outlook の app protection、Conditional Access、6文字 PIN、個人クラウドへのバックアップ制限、Wi‑Fi/VPN/メールプロファイル、Microsoft 365 アプリや LOB アプリの配布などを例示しています。全部を一度に移すのではなく、「最初に守るべき最小集合」を作る発想が、統合プロジェクトでは効きます。(Microsoft Learn)
パイロットとサポート体制まで設計する
Step 5 では、技術設計だけでなく、展開順序と運用体制まで含めて考えるようになっています。目標は SMART に置き、ロールアウトはフェーズ分割し、まずはパイロットやテストグループから始めるのが基本です。しかも公式ガイドは、最初のパイロットに executives や VIP を入れないよう明言しています。ここはそのまま従ったほうが安全です。(Microsoft Learn)
さらに見落としやすいのがサポートです。ガイドは、Tier 1〜3 の支援体制、問い合わせのエスカレーション、初期段階での障害パターン共有、ヘルプデスク教育まで設計に含めています。特に「ヘルプデスクやサポートチーム自身をパイロット候補にする」という考え方は実務向きです。ユーザー展開前に、支援側が実際に enroll とトラブル対応を経験しておくと、本番での混乱が大きく減ります。(Microsoft Learn)
統合で失敗しやすいポイント
- BYOD をすべて MDM 登録前提で設計すると、社内合意もユーザー体験も重くなりがちです。メールと文書保護が主目的なら、まず MAM と app protection で足りる範囲を見極めたほうがスムーズです。(Microsoft Learn)
- GPO を 1:1 で Intune に移そうとすると、競合と不要設定が増えます。LSDOU 前提の設計と Intune の割り当てモデルは違うため、設定名ではなく意図で整理し直すべきです。(Microsoft Learn)
- 「Intune があれば十分」と考えて Conditional Access や準拠判定の前提ライセンスを詰めないのも危険です。実際には Entra ID P1/P2 や Microsoft 365 apps の有無で設計できる範囲が変わります。(Microsoft Learn)
- パイロットを単なる技術確認で終わらせると、本番でサポート負荷が爆発します。役員を最初に入れない、問い合わせフローを先に決める、ヘルプデスクを先に慣らす、この3つは軽視しないほうがいいです。(Microsoft Learn)
読んだら最初の1週間でやること
公式の Intune 移行計画ガイドを、現場の初動に落とし込むと次の順番が動きやすいです。(GitHub)
- 管理対象を4つに分ける
BYOD、社給端末、ConfigMgr 併用端末、共有端末の4区分だけでも先に決めます。 - 使うアプリを洗い出す
Outlook、Teams、SharePoint、Win32、LOB アプリを部門単位で並べます。
「誰が、どの端末で、どのアプリを使うか」が曖昧なままではポリシーを設計できません。 - 既存ポリシーを「残す・捨てる・作り直す」に分類する
GPO、証明書、VPN、Wi‑Fi、メール設定、旧 MDM ポリシーを対象にします。 - ライセンスをシナリオ別に表にする
Intune だけでよいか、Entra ID P1/P2 が必要か、Microsoft 365 apps や Defender for Endpoint、Intune Suite が必要かを列で持つと判断が早くなります。 - 小さなパイロットを決める
IT 部門やヘルプデスク中心で始め、役員や重要ユーザーは初回から外します。 - 問い合わせフローを先に作る
Tier 1 が何を切り分け、Tier 2/3 に何を渡すかを先に決めておくと、本番展開後の混乱が減ります。
まとめ
Microsoft が Intune 移行計画ガイドを更新したという今回の動きは、派手な新機能リリースというより、Intune を中心にした統合管理の前提資料が改めて重要になっているサインとして捉えるのが実務的です。Microsoft は Intune を unified endpoint management の中心に置き、Configuration Manager は安定運用寄りへ整理しつつあります。だからこそ、移行の成否は「いつ Intune を入れるか」より、「どの端末をどう分類し、何をどこまで移し、どの順番で広げるか」を先に決められるかでほぼ決まります。まずは公式 planning guide を開き、自社の判断を 1 枚の設計メモに書き出すところから始めるのが最短です。(Microsoft Learn)
コメント