Microsoft Intuneへ移行する際に最初に決めるべきことは、「どの端末を、どこまで管理するか」です。今回確認すべきポイントは、単なる機能追加ではなく、Intune移行を目的設定、端末棚卸し、ライセンス確認、既存ポリシー整理、段階展開、社内周知、サポート体制まで含めたプロジェクトとして設計することです。
Microsoft公式の「Planning guide to move to Microsoft Intune」は、Microsoft Intuneを統合エンドポイント管理の基盤として導入・移行するための計画ガイドです。英語版のMicrosoft Learnでは最終更新日が2026年5月19日と表示されており、この記事では2026年5月21日時点で確認できる公式内容をもとに、日本語圏の管理者・情報システム部門・開発チームが実務で確認すべき点を整理します。 (Microsoft Learn)
Microsoft IntuneのPlanning guideは「移行手順書」ではなく「設計判断のガイド」
Microsoft Intuneの「Planning guide to move to Microsoft Intune」は、画面操作を順番に説明するチュートリアルではありません。公式ガイドの主眼は、Intuneの導入または移行を成功させるために、事前に何を決め、何を棚卸しし、どの順番で展開するかを整理することです。Microsoftは、IntuneをMDMとMAMの両面から利用できる管理基盤として位置付けています。MDMはデバイス全体の管理、MAMは主にアプリ内の業務データ保護に焦点を当てる考え方です。 (Microsoft Learn)
管理者が最初に理解すべき変更点は、「Intuneに移行するかどうか」だけでなく、「どの業務シナリオに対してIntuneをどう使うか」を明確にする必要がある点です。たとえば、同じIntune導入でも、社給Windows PCを完全管理するケースと、個人所有スマートフォンでOutlookだけを安全に使わせるケースでは、必要なポリシー、ライセンス、ユーザー説明、サポート体制が大きく異なります。
| 確認項目 | 重要な理由 | 実務での判断例 |
|---|---|---|
| 管理対象 | 管理範囲を誤ると過剰管理や情報漏えいにつながる | 社給PCはMDM、個人スマホはMAM中心にする |
| 既存環境 | GPOやConfiguration Managerとの重複を防ぐ | 既存PCは共同管理、新規PCはIntune直管理にする |
| ライセンス | 条件付きアクセスや高度機能には追加要件がある | Intune単体で足りるか、Entra ID P1/P2が必要か確認する |
| 展開順序 | 一斉展開は問い合わせ増や業務停止の原因になる | IT部門、パイロット部門、一般部門の順に広げる |
| 社内周知 | ユーザー不安が登録拒否や回避行動につながる | 個人端末で何が見える・見えないかを明文化する |
何が変わるのか：管理者が見るべき主なポイント
今回の公式ガイドで特に注目すべき点は、Intune移行を「端末登録」だけで終わらせず、ゼロトラスト、条件付きアクセス、アプリ保護、既存GPOの見直し、ライセンス階層、サポート設計まで含めて整理している点です。
目的ベースでMDMとMAMを使い分ける考え方が重要になる
Intuneの導入では、すべてのデバイスを同じように管理する必要はありません。公式ガイドでは、組織アプリやメールへのアクセス、全デバイスの安全なアクセス、分散IT、組織データの保護といった目的を先に決める流れが示されています。 (Microsoft Learn)
実務では、次のように分けて考えると設計しやすくなります。
| 利用シーン | 推奨される考え方 | 注意点 |
|---|---|---|
| 社給Windows PC | MDMでデバイス全体を管理 | 更新、暗号化、ウイルス対策、構成プロファイルまで含める |
| 個人所有スマートフォン | MAMでアプリ内データを保護 | 端末全体を管理しようとすると利用者の抵抗が強い |
| 役員・VIP端末 | 事前構成や支援付き登録を検討 | 一般ユーザー向けセルフサービス登録だけにしない |
| 店舗・工場・医療現場の共有端末 | フロントラインワーカー向けの限定用途設計 | キオスク、スキャナー、共有タブレットなど用途別に分ける |
| 開発者端末 | セキュリティ基準と業務自由度のバランスを取る | ローカル管理者権限、証明書、VPN、開発ツール配布を事前確認する |
特に個人所有デバイスでは、「登録させれば安全」という発想は危険です。公式ガイドでも、個人デバイスを登録すると管理者が広い制御権を持つため、ユーザーがリスクを理解しないまま登録するとトラブルになり得ることが示されています。個人デバイスでは、アプリ保護ポリシーやアプリ構成ポリシーを使い、OutlookやTeamsなど業務アプリ内のデータを守る設計が現実的です。 (Microsoft Learn)
条件付きアクセス、Defender、MFAとの連携を前提にする
Microsoft Intuneの移行計画では、端末管理だけでなく、Microsoft Entra ID、条件付きアクセス、MFA、Microsoft Defender for Endpointとの連携も確認が必要です。公式ガイドでは、Defender for Endpointでデバイスの侵害状態を把握し、条件付きアクセスで組織リソースへのアクセスを制御する例が示されています。 (Microsoft Learn)
管理者が確認すべき設定は次のとおりです。
| 確認する設定 | 確認ポイント |
|---|---|
| 条件付きアクセス | 準拠していない端末からExchange Online、SharePoint、Teamsへアクセスできない設計になっているか |
| コンプライアンスポリシー | OSバージョン、パスコード、暗号化、脅威レベルなどを業務リスクに合わせて定義しているか |
| MFA | 個人端末や高リスク操作で多要素認証を求める条件が明確か |
| Defender連携 | 脅威検出時にアクセス制御へ反映できるか |
| 証明書・VPN | Wi-Fi、VPN、Outlookなどで証明書認証を使う場合、PKI設計が整っているか |
失敗しやすいのは、Intune側でポリシーを作っただけで「保護できている」と判断してしまうことです。実際には、条件付きアクセスで「準拠していない端末をどう扱うか」まで決めなければ、ポリシー違反端末から業務アプリへアクセスできる抜け道が残る可能性があります。
Intune SuiteやCopilot in Intuneを含むライセンス確認が必要
公式ガイドでは、Intune単体だけでなく、Microsoft Entra ID P1/P2、Microsoft 365 Apps、Microsoft Defender for Endpoint、Microsoft Purview、Copilot in Intune、Intune Suiteなど、周辺サービスとの関係が整理されています。Copilot in Intuneは、Intuneデータを使ってポリシーや設定の管理、セキュリティ状態の理解、デバイス問題のトラブルシューティングを支援する生成AIセキュリティ分析ツールとして説明されています。 (Microsoft Learn)
また、公式ガイドでは2026年7月以降、Intune Suiteの機能がMicrosoft 365のライセンス階層に配布される予定として、Microsoft 365 E3にはPlan 2、Remote Help、Advanced Analyticsが含まれ、Microsoft 365 E5およびE7にはそれらに加えてEndpoint Privilege Management、Microsoft Cloud PKI、Enterprise Application Managementが含まれると説明されています。その他のプランでは、Suiteを別サブスクリプションとして利用できるとされています。 (Microsoft Learn)
ただし、ライセンス条件は契約形態や時期によって変わる可能性があります。実際の移行計画では、Microsoft 365管理センター、契約中のライセンス明細、販売パートナーの見積もりを必ず照合してください。
影響範囲：誰が何を確認すべきか
Microsoft Intuneへの移行は、情シスだけの作業ではありません。端末、ID、アプリ、ネットワーク、ヘルプデスク、利用部門が関係します。影響範囲を整理せずに進めると、ポリシー競合、アプリ配布漏れ、問い合わせ集中、個人デバイスの反発が起きやすくなります。
| 対象者 | 主な影響 | まず確認すべきこと |
|---|---|---|
| Intune管理者 | ポリシー設計、登録方式、端末準拠状態の管理 | 既存MDM、GPO、Configuration Managerとの役割分担 |
| ID管理者 | Entra ID、条件付きアクセス、グループ設計 | 動的グループ、ユーザー属性、MFA条件 |
| セキュリティ担当 | デバイスリスク、データ持ち出し、監査 | Defender連携、アプリ保護、ログ確認 |
| ヘルプデスク | 登録失敗、アプリ利用不可、端末紛失対応 | エスカレーション手順、FAQ、検証端末 |
| 開発者 | LOBアプリ配布、証明書、VPN、権限管理 | Win32アプリ配布、署名、依存関係、管理者権限 |
| 利用部門 | 登録作業、業務アプリ利用、個人端末ポリシー | いつ何をすればよいか、端末に何が適用されるか |
開発者やアプリ担当者が見落としやすいのは、Intune移行後に「アプリが入るか」だけでなく、「アプリが業務ネットワーク、証明書、条件付きアクセス、アプリ保護ポリシーと矛盾しないか」を確認する必要がある点です。特に社内アプリ、Win32アプリ、VPN接続、証明書認証を使う業務では、パイロット段階で実ユーザーに近い検証が欠かせません。
既存環境からの移行で確認すべきポイント
Configuration Manager利用中なら共同管理か完全移行かを決める
既にConfiguration Managerを使ってWindows端末を管理している組織では、いきなり全面移行する必要はありません。公式ガイドでは、Configuration Managerを利用中の場合、共同管理、テナントアタッチ、Intuneへの完全移行という選択肢が示されています。既存インフラを維持しつつ一部ワークロードをクラウドへ移すなら共同管理、Intune管理センターからオンプレミスデバイスを監視したいならテナントアタッチ、純粋なクラウド管理を目指すならIntune移行を検討する流れです。 (Microsoft Learn)
判断基準は次のように整理できます。
| 現在の状況 | 現実的な選択肢 | 理由 |
|---|---|---|
| Configuration Managerを深く利用している | 共同管理から開始 | 既存の配布・更新運用を残しながら段階移行できる |
| クラウドから可視化したいが運用は変えにくい | テナントアタッチ | 既存管理を維持しつつIntune管理センターを活用できる |
| 新規調達PCが中心 | Intune直管理 | Autopilotやクラウドポリシーへ移行しやすい |
| MDM未導入 | Intune直接導入 | 既存制約が少なく、クラウド前提で設計できる |
ここで重要なのは、移行方式を「技術的に可能か」だけで決めないことです。ヘルプデスクの習熟度、端末更新サイクル、ネットワーク帯域、既存アプリ配布の複雑さも含めて判断してください。
GPOはそのまま移すのではなく目的から見直す
オンプレミスActive Directoryのグループポリシーを使っている組織では、GPOをIntuneへ丸ごと移す発想になりがちです。しかし公式ガイドでは、古いポリシーをそのまま維持するのではなく、クラウド移行時に「そのポリシーの目的」を確認することが重要だとされています。また、オンプレミスGPOにはLSDOUの階層適用がありますが、Intuneではユーザーやグループにポリシーを割り当て、同じ設定に複数ポリシーが当たると競合として表示される点にも注意が必要です。 (Microsoft Learn)
GPO見直しでは、次の順番で棚卸しすると効率的です。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 棚卸し | 現在のGPOを一覧化する | いつ作成されたか、誰が管理しているか |
| 目的確認 | 何のリスクや業務要件を満たす設定か確認する | 現在も必要か、重複していないか |
| 分類 | セキュリティ、ネットワーク、アプリ、UXなどに分ける | Intuneのどの機能で代替できるか |
| 変換可否確認 | Settings catalogやGroup Policy analyticsで確認する | MDMで対応可能か、非推奨設定ではないか |
| パイロット適用 | 小規模グループに適用して競合を見る | 業務影響、サインイン、アプリ動作を確認する |
公式ガイドでは、Settings catalog、Security baselines、Group Policy analyticsなども取り上げられています。Group Policy analyticsはGPOをインポートしてクラウド移行時の対応状況を確認でき、サポートされる設定、非推奨設定、MDMプロバイダーで利用できない設定の把握に役立ちます。 (Microsoft Learn)
展開前に必ず作るべきIntune移行チェックリスト
Intune移行で最も危険なのは、管理画面でポリシーを作り始めてから設計不足に気付くことです。次のチェックリストを使い、展開前に最低限の判断を済ませてください。
| 分野 | チェック項目 |
|---|---|
| 目的 | Intuneで解決したい課題が「端末管理」「アプリ保護」「条件付きアクセス」「更新管理」のどれか明確か |
| 端末 | Windows、macOS、iOS/iPadOS、Android、共有端末、個人端末を台数別に把握しているか |
| 所有区分 | 社給端末と個人端末で管理方針を分けているか |
| アプリ | Microsoft 365 Apps、Win32アプリ、LOBアプリ、ストアアプリの配布方法を決めているか |
| ライセンス | Intune、Entra ID P1/P2、Microsoft 365 Apps、Defender、Intune Suiteの要否を確認したか |
| 既存管理 | GPO、Configuration Manager、既存MDM、スクリプト配布の棚卸しが済んでいるか |
| セキュリティ | コンプライアンス違反時のアクセス制御を条件付きアクセスに反映しているか |
| ロールアウト | パイロット、本番第1段階、本番第2段階の対象者と日程を決めているか |
| サポート | 登録失敗、端末紛失、アプリ未配布、条件付きアクセスブロック時の窓口を決めているか |
| 周知 | ユーザー向けに「何が変わるか」「何をすればよいか」を説明しているか |
このチェックリストの中でも、特に優先度が高いのは「所有区分」「既存管理」「条件付きアクセス」です。ここを曖昧にしたまま展開すると、個人端末の扱いでユーザーと摩擦が起きたり、既存GPOとIntuneポリシーが競合したり、準拠していない端末から業務アプリへアクセスできてしまったりします。
ロールアウトは小さく始め、部門・地域・プラットフォームで分ける
公式ガイドでは、Intuneポリシーを段階的に展開し、最初はパイロットまたはテストグループから始めることが推奨されています。パイロットユーザーからのフィードバックを使い、構成、文書、通知、将来の展開を改善する考え方です。また、展開単位として部門、地域、プラットフォームが例示されています。 (Microsoft Learn)
実務では、次のような順番が扱いやすいです。
| フェーズ | 対象 | 目的 | 注意点 |
|---|---|---|---|
| 限定パイロット | 情シス、セキュリティ担当、ヘルプデスク | 登録手順と基本ポリシーの検証 | VIPや役員を最初に入れない |
| 拡大パイロット | ITリテラシーが高い部門、代表ユーザー | 業務アプリ、VPN、証明書、印刷などの確認 | 実業務に近いシナリオで検証する |
| 本番第1段階 | 影響範囲が限定的な部門 | 問い合わせ量と運用手順を確認 | 登録期限と問い合わせ窓口を明確にする |
| 本番第2段階 | 大規模部門、複数拠点 | 展開手順の標準化 | 地域やネットワーク帯域を考慮する |
| 特別対応 | 役員、共有端末、現場端末 | 個別要件への対応 | セルフサービス登録だけに頼らない |
Microsoft公式ガイドでは、登録方法としてユーザー自身が登録するセルフサービス、IT担当者が支援する登録、IT相談ブースのような形式が挙げられています。セルフサービスは拡張性が高い一方、役員や支援が必要な部門では支援付き登録を検討したほうがトラブルを減らせます。 (Microsoft Learn)
社内周知で伝えるべき内容
Intune移行では、技術設定よりもユーザー説明でつまずくことがあります。特に個人デバイスを扱う場合、「会社に端末内の個人データを見られるのではないか」「端末を初期化されるのではないか」という不安が起きやすくなります。
公式ガイドでは、Intune展開のコミュニケーションを、キックオフ、登録前、登録時、登録後のフェーズに分けて行う考え方が示されています。登録時の案内には、登録手順、問い合わせ先、対象ユーザーに対する具体的な行動を含める必要があります。 (Microsoft Learn)
ユーザー向け案内には、最低限次の内容を入れてください。
| 案内項目 | 書くべき内容 |
|---|---|
| なぜ導入するのか | 情報漏えい対策、端末紛失時の保護、業務アプリの安全な利用 |
| いつ実施するのか | 部門別の登録開始日、期限、影響が出る日 |
| 何をすればよいか | 登録手順、必要なアプリ、所要時間の目安 |
| 何が制御されるか | パスコード、業務アプリ、会社データ、条件付きアクセス |
| 個人端末で何が守られるか | 個人写真、私用メール、個人アプリへの扱いを明確化 |
| 困ったときの連絡先 | ヘルプデスク、Teams窓口、FAQ、対応時間 |
周知文で避けるべき表現は、「セキュリティ強化のため登録してください」だけで終わることです。ユーザーは「登録しないと何が起きるのか」「自分の端末に何が適用されるのか」を知りたいものです。登録期限後にメールやTeamsへアクセスできなくなる可能性があるなら、曖昧にせず具体的に書く必要があります。
ヘルプデスクとサポート体制はパイロット前に整える
公式ガイドでは、Intune展開計画やパイロットの早い段階からITサポートやヘルプデスクを巻き込むことが推奨されています。サポート担当者が早期にIntuneへ触れることで、問題の特定や解決に必要な知識を得やすくなり、本番展開時のユーザー支援にもつながります。 (Microsoft Learn)
サポート設計では、次のように問い合わせを分類しておくと対応が早くなります。
| 問い合わせ内容 | 一次対応 | エスカレーション条件 |
|---|---|---|
| 登録できない | 手順、ライセンス、対象グループ、ネットワークを確認 | 端末登録制限や条件付きアクセスが関係する場合 |
| アプリが配布されない | 割り当てグループ、インストール状態、再同期を確認 | Win32アプリの検出ルールや依存関係が不明な場合 |
| メールにアクセスできない | コンプライアンス状態、条件付きアクセス、MFAを確認 | ポリシー競合やEntra ID側の条件が関係する場合 |
| 個人端末の不安 | 会社が管理する範囲を説明 | 法務・人事・セキュリティ方針に関わる場合 |
| 紛失・退職対応 | リタイア、ワイプ、選択的ワイプの方針を確認 | 全消去と会社データ削除の判断が必要な場合 |
本番展開後に問い合わせを減らすには、ヘルプデスク自身をパイロットユーザーに含めるのが有効です。Windows、iOS/iPadOS、Android、macOSなど実際に社内で使うプラットフォームを一通り登録し、スクリーンショット付きの手順書とFAQを作っておくと、展開時の対応品質が安定します。
管理者・開発者が移行前に見落としやすい注意点
ポリシー競合を「あとで直す」と考えない
Intuneでは、同じ設定に複数のポリシーが適用されると競合が発生します。オンプレミスGPOのような階層適用を前提にしていると、想定外の競合に気付きにくくなります。公式ガイドでも、IntuneにはGPOのような階層がなく、同じ設定を複数ポリシーが更新すると競合として表示されることが説明されています。 (Microsoft Learn)
対策として、まず全社共通の最小ベースラインを作り、部門別・端末種別別の追加ポリシーは後から重ねる設計にしてください。いきなり細かな例外ポリシーを大量に作ると、運用開始後の原因調査が難しくなります。
個人端末にMDMを強制すると反発が起きやすい
個人所有デバイスを完全管理対象にすると、ユーザーは「私物端末を会社に管理される」と感じやすくなります。個人端末では、アプリ保護ポリシーを使って会社データだけを守る設計を優先し、どうしてもMDM登録が必要な場合は、理由と管理範囲を明確に説明してください。
たとえば、営業担当者が私物スマートフォンでOutlookとTeamsだけを使う場合、端末全体を管理するよりも、Outlookのコピー＆ペースト制御、MFA、保存先制限、選択的ワイプを組み合わせるほうが受け入れられやすいケースがあります。
LOBアプリは「配布」だけでなく「更新」と「削除」まで検証する
開発チームやアプリ担当者は、Intuneで社内アプリを配布できるかだけでなく、更新時の挙動、旧バージョンの削除、依存コンポーネント、再起動要否、VPN接続前提の有無まで確認する必要があります。
特にWin32アプリでは、インストールコマンド、検出ルール、依存関係、戻り値、再起動の扱いを誤ると、管理画面上は失敗していないように見えても、ユーザー端末ではアプリが使えないことがあります。パイロットでは、IT部門のクリーンな検証端末だけでなく、実際の業務端末に近い状態で確認してください。
フロントラインワーカー端末は通常PCと同じ設計にしない
店舗、工場、医療、物流などの現場端末は、一般的なオフィスPCとは使い方が異なります。公式ガイドでは、フロントラインワーカー向けの共有タブレットやデバイスが、小売、医療、製造などで使われる例が示されています。これらは1人で使う場合もあれば、複数人で共有する場合もあり、スキャナー、キオスク、患者受付タブレットのように限定用途で使われることがあります。 (Microsoft Learn)
現場端末では、セルフサービス登録、通常のメール利用、一般的なOfficeアプリ配布を前提にしないほうが安全です。共有アカウント、サインアウト手順、紛失時対応、ネットワーク制限、業務アプリの自動起動などを別設計にしてください。
まず管理者が取るべき次のアクション
Microsoft IntuneのPlanning guideを読んだ後、すぐ管理画面でポリシーを作るのではなく、次の順番で準備してください。
| 優先度 | アクション | 成果物 |
|---|---|---|
| 高 | 管理対象デバイスを棚卸しする | OS別、所有区分別、部門別の一覧 |
| 高 | MDMとMAMの使い分けを決める | 社給端末・個人端末の管理方針 |
| 高 | 既存GPOとConfiguration Managerを確認する | 残す設定、移行する設定、廃止する設定の分類 |
| 高 | ライセンスを確認する | 必要なIntune、Entra ID、Microsoft 365、Defender、Suite機能の一覧 |
| 中 | パイロット対象を決める | IT部門、代表部門、除外すべきVIPの整理 |
| 中 | ユーザー通知を作成する | 登録前メール、登録開始メール、FAQ |
| 中 | ヘルプデスク手順を作る | 一次対応表、エスカレーション基準、既知の問題一覧 |
最初の成果物としておすすめなのは、1枚の「Intune移行方針シート」です。そこに、対象端末、所有区分、利用アプリ、管理方式、条件付きアクセス、登録方法、サポート窓口をまとめます。これがないままポリシー作成に進むと、後から「この端末は誰が管理するのか」「個人端末にどこまで制御をかけるのか」という根本的な議論に戻りやすくなります。
Microsoft Intune移行は設定作業ではなく運用設計として進める
Microsoft Intuneの「Planning guide to move to Microsoft Intune」は、Intune移行を単なる端末登録作業ではなく、目的、端末、ライセンス、既存ポリシー、段階展開、社内周知、サポートまで含めて設計するための公式ガイドです。
管理者が最初にやるべきことは、Intuneポリシーを作ることではありません。社給端末と個人端末を分け、MDMとMAMを使い分け、GPOやConfiguration Managerとの関係を整理し、条件付きアクセスまで含めたアクセス制御を設計することです。そのうえで、小さなパイロットから始め、問い合わせ内容を記録し、社内通知とサポート体制を改善しながら本番展開へ広げてください。
コメント