Microsoft IntuneでAndroid Enterprise fully managed devicesを登録する場合、最初に確認すべき結論は「会社所有・業務専用のAndroid端末を、登録プロファイルと登録トークンでIntuneに登録し、配布前にポリシー・アプリ・グループ割り当てまで設計しておくこと」です。特に2026年5月時点の公式情報では、トークン種別、登録時グループ化、条件付きアクセス、デバイスステージングの扱いを誤ると、初期セットアップの失敗や配布後のポリシー遅延につながります。(Microsoft Learn)
Android Enterprise fully managedは、個人利用を前提にしない会社所有端末向けの管理方式です。Microsoft Intune管理者は、Managed Google Play以外からのアプリインストール制限、管理アプリのアンインストール防止、ユーザーによる工場出荷状態へのリセット抑止など、Android Enterprise work profileより強いデバイス全体の制御を行えます。(Microsoft Learn)
Microsoft IntuneのAndroid Enterprise fully managed登録で何が変わるのか
今回の公式情報は、単に「登録手順を案内するページ」ではなく、Android Enterprise fully managed devicesをIntuneで安全に展開するための設計ポイントを整理した内容として読むべきです。
大きな見方としては、次の4点が重要です。
| 確認ポイント | 管理者への影響 |
|---|---|
| 登録プロファイルと登録トークンの作成手順 | 端末配布前に、登録方式と対象グループを明確にする必要がある |
| デフォルトトークンとステージングトークンの使い分け | キッティングを管理者・ベンダー側でどこまで済ませるかを決める必要がある |
| 登録時グループ化と動的グループの扱い | アプリやポリシーの適用遅延を減らす設計が求められる |
| 条件付きアクセスの除外設定 | 登録途中の認証失敗を防ぐため、Microsoft Intuneクラウドアプリの扱いを確認する必要がある |
特に注意したいのは、Intuneが自動生成する「Default Fully Managed Profile」だけで運用を始めると、後から部署別・用途別の動的グループや命名規則を整理しにくくなる点です。小規模な検証では問題が見えにくくても、数十台以上を展開する段階で、端末名、割り当て、サポート対応が複雑になります。
対象になるデバイスと管理方式
Android Enterprise fully managed devicesは、会社が所有し、1人のユーザーに紐づけて業務利用させる端末に向いています。たとえば、営業担当者に貸与するスマートフォン、現場社員に配布する業務端末、個人利用を認めない社給Android端末などです。
一方で、複数人が共有する受付端末や店舗端末、単一アプリ専用のキオスク端末であれば、fully managedではなくAndroid Enterprise dedicated devicesのほうが適している場合があります。BYODや個人利用との分離が必要な端末では、work profileやcorporate-owned work profileも比較対象になります。
| 管理方式 | 向いている用途 | 判断基準 |
|---|---|---|
| Fully managed | 会社所有・1ユーザー利用・業務専用 | 端末全体を会社が管理したい |
| Corporate-owned work profile | 会社所有だが個人利用も一定許可 | 業務領域と個人領域を分けたい |
| Dedicated | 共有端末、キオスク、店舗端末 | 特定業務・特定アプリ中心で使う |
| Personally owned work profile | 個人所有端末の業務利用 | 個人端末に会社データを分離して入れたい |
fully managedを選ぶべきか迷う場合は、「会社が端末全体を管理してよいか」「個人利用を許可するか」「端末は1人に割り当てるか」を先に決めると判断しやすくなります。
登録前に確認すべき前提条件
IntuneでAndroid Enterprise fully managed devicesを登録するには、端末・テナント・Android Enterprise連携の条件を満たしている必要があります。公式情報では、対象端末はAndroid 10.0以降、Google Mobile Servicesへの接続性、Google Mobile Servicesの利用可能性が前提とされています。テナント側では、MDM authorityをMicrosoft Intuneに設定し、IntuneテナントをAndroid Enterpriseアカウントへ接続しておく必要があります。(Microsoft Learn)
| 確認項目 | 確認内容 | よくある失敗 |
|---|---|---|
| Android OS | Android 10.0以降か | 古い在庫端末を流用して登録できない |
| GMS対応 | Google Mobile Servicesが使えるか | GMS非搭載端末で通常のAndroid Enterprise登録を想定してしまう |
| Android Enterprise対応地域 | 利用地域でAndroid Enterpriseがサポートされているか | 海外拠点展開時に地域差を確認していない |
| Intuneテナント | MDM authorityがMicrosoft Intuneか | 旧構成や別MDM前提のまま進めてしまう |
| Android Enterprise連携 | IntuneとAndroid Enterpriseアカウントが接続済みか | Managed Google Play連携前に登録を始める |
| ネットワーク | 初期セットアップ時にGoogle・Microsoftへ到達できるか | プロキシや閉域網で登録画面が進まない |
端末メーカーに大きな制限があるわけではありませんが、Android 10以降でGMSに接続できることが前提です。国内で調達する端末でも、業務用モデル、海外モデル、特殊用途端末ではGMSやPlay Protect認定の有無を事前に確認してください。
登録プロファイル作成で確認する設定
Microsoft Intune管理センターでは、Devices > Enrollment > Android > Android Enterprise > Enrollment Profiles > Corporate-owned, fully managed user devicesから登録プロファイルを作成します。プロファイル作成時は、名前、説明、トークン種別、トークン有効期限、デバイス名テンプレート、登録時グループ、スコープタグなどを設定します。(Microsoft Learn)
プロファイル名は運用単位で分ける
プロファイル名は、後で動的グループの条件にも使えます。公式情報では、enrollmentProfileNameプロパティを使って、同じ登録プロファイルで登録された端末を動的Microsoft Entraグループにまとめる例が示されています。ただし、既定の登録プロファイルでは動的グループを使用できないため、展開規模が大きい場合は用途別に新しいプロファイルを作成するのが安全です。(Microsoft Learn)
おすすめは、プロファイル名に「用途」「拠点」「管理方式」を含めることです。
| 例 | 向いているケース |
|---|---|
| AE-FM-Sales-JP | 日本の営業部門向けfully managed端末 |
| AE-FM-Field-Tokyo | 東京拠点の現場端末 |
| AE-FM-SharedTest | 検証用のfully managed登録 |
| AE-FM-KittingVendor | 外部キッティングベンダー向け |
AndroidProfile1のような名前は、検証後に本番環境へ流用されると管理しづらくなります。登録プロファイル名は、後から見た管理者が「何のためのプロファイルか」を判断できる形式にしておきましょう。
トークン種別は通常登録かステージングで選ぶ
Android Enterprise fully managedの登録では、登録プロファイル作成時にトークン種別を選択します。公式情報では、通常のCorporate-owned, fully managedと、ステージング用のCorporate-owned, fully managed, via stagingが示されています。(Microsoft Learn)
| トークン種別 | 向いている展開 | 注意点 |
|---|---|---|
| Corporate-owned, fully managed | ユーザーが初回サインインして残りのセットアップを進める通常配布 | 登録時グループ化を使う場合はこちらを選ぶ |
| Corporate-owned, fully managed, via staging | 管理者またはキッティングベンダーが事前準備を多く済ませる配布 | 登録時グループ化はサポートされない |
ステージングトークンは、端末をユーザーに渡す前に管理者や外部ベンダーが事前構成を進めたい場合に有効です。エンドユーザーは最後にMicrosoft Intuneアプリへ職場または学校アカウントでサインインし、端末が利用可能になります。公式のデバイスステージング説明では、ステージング中はユーザーに紐づかない状態で進み、最終段階でユーザー関連付けされる流れが説明されています。(Microsoft Learn)
一方で、登録時グループ化を使って初回セットアップ直後からアプリやポリシーを早く適用したい場合は、ステージングトークンではなく通常のfully managedトークンを選ぶ必要があります。ここを誤ると、「展開後すぐにアプリが入るはずだったのに反映が遅い」という問題が起きやすくなります。(Microsoft Learn)
デバイス名テンプレートはサポートしやすさを優先する
Intuneでは、登録時にデバイス名テンプレートを適用できます。利用できる文字列には、シリアル番号、シリアル番号下4桁、デバイスタイプ、登録日時、ユーザー名、ランダム数字などがあります。テンプレート変更は新規登録にのみ適用され、既存登録済み端末にはさかのぼって反映されません。(Microsoft Learn)
実務では、次のような形式が扱いやすいです。
| テンプレート例 | 使いどころ |
|---|---|
FM-JP-{{SERIALLAST4DIGITS}}-{{RAND:3}} | 個人名を入れず、端末識別を優先したい |
FM-{{USERNAME}}-{{RAND:3}} | ユーザー紐づけをサポート時に見やすくしたい |
FM-{{DEVICETYPE}}-{{ENROLLMENTDATETIME}} | 検証や短期展開で登録時期を追いたい |
個人名やユーザー名を含める場合は、台帳、ログ、サポート画面に表示されることを前提に、社内の個人情報取り扱いルールと整合させてください。店舗端末や共有に近い端末では、ユーザー名よりも拠点コードや端末番号を優先したほうが運用しやすい場合があります。
登録時グループ化と動的グループの使い分け
Android Enterprise fully managed devicesの展開で重要なのが、登録時グループ化、動的Microsoft Entraグループ、Intuneの割り当てフィルターの使い分けです。
登録時グループ化は、登録ポリシーに静的なMicrosoft Entraセキュリティグループを指定し、登録中に端末をそのグループへ追加する仕組みです。これにより、登録後にグループ処理を待ってからアプリやポリシーを受け取るのではなく、登録時点から必要な構成を受け取りやすくなります。公式情報では、登録時グループ化を構成しない場合、すべてのアプリやポリシーを受け取るまで最大8時間かかる可能性があると説明されています。(Microsoft Learn)
| 方式 | 使うべき場面 | 注意点 |
|---|---|---|
| 登録時グループ化 | 初回セットアップ直後から必須アプリ・ポリシーを適用したい | 静的デバイスグループを使う。ステージングトークンでは使えない |
| 動的Microsoft Entraグループ | 条件付きアクセスやライセンスなど、Intune以外でもグループを使いたい | 既定の登録プロファイルでは使えない |
| Intune割り当てフィルター | Intuneのアプリ・ポリシー割り当てを端末属性で絞りたい | グループメンバーシップ処理に依存しない |
公式情報では、enrollmentProfileNameに基づく動的グループは、条件付きアクセスやグループベースライセンスなどクロスワークロードでグループメンバーシップが必要な場合に有効とされています。一方、Intuneのポリシーやアプリを端末プロパティで絞るだけなら、チェックイン時に評価される割り当てフィルターの利用が推奨される場面があります。(Microsoft Learn)
展開直後の体験を重視するなら、まず登録時グループ化で必須構成を配布します。そのうえで、部署別・機種別・OS別の細かな適用制御には割り当てフィルターを組み合わせると、グループ設計が肥大化しにくくなります。
登録方法は展開規模と調達ルートで選ぶ
登録プロファイル、トークン、グループを準備したら、端末をfully managedとして登録します。公式情報では、QRコード、トークン文字列、Google Zero Touch、Samsung Knox Mobile Enrollment、NFCなどの方法が示されています。QRコード登録は多くの一般的なシナリオで推奨されています。(Microsoft Learn)
| 登録方法 | 向いているケース | 実務上の注意点 |
|---|---|---|
| QRコード | 少数から中規模の手動キッティング | 画面拡大率や端末カメラの読み取りで失敗することがある |
| トークン入力 | QRやNFCが使えない場合 | 入力ミス、トークンの共有範囲に注意 |
| Google Zero Touch | 大量展開、未開封状態から自動登録したい場合 | 対応端末を認定リセラーから購入する必要がある |
| Samsung Knox Mobile Enrollment | Samsung端末を組織的に展開する場合 | 対応KnoxバージョンやKME側の設定確認が必要 |
| NFC | 特殊なキッティングフローやNFC対応端末 | タグ作成や運用手順の整備が必要 |
大量展開では、登録方法よりも「端末調達ルート」「キッティング担当者」「ネットワーク環境」「ユーザーへの受け渡し手順」のほうが成否を左右します。たとえば、Zero Touchを使いたい場合は、あとから既存在庫を対象にするのではなく、購入時点で対応リセラー経由にする設計が必要です。
条件付きアクセスで失敗しやすいポイント
Android Enterprise fully managedの登録では、Androidセットアップ中のユーザー認証にChromeタブが使われます。そのため、Microsoft Entra Conditional Accessで「準拠済みデバイスを要求する」設定やブロックポリシーを使い、さらに対象がAll Cloud apps、Android、Browsersに及ぶ場合、Microsoft Intuneクラウドアプリを除外する必要があります。(Microsoft Learn)
これは非常に重要です。まだIntuneに登録されていない端末に対して「準拠済みであること」を要求すると、端末は準拠状態になる前に認証を求められ、登録処理が進まない可能性があります。
確認すべき設定は次の通りです。
| 確認場所 | 見るべき内容 |
|---|---|
| Microsoft Entra Conditional Access | Androidとブラウザーを対象にしたポリシーがあるか |
| Grant control | 準拠済みデバイス要求やブロックが設定されているか |
| Cloud apps | All Cloud appsを対象にしていないか |
| 除外設定 | Microsoft Intuneクラウドアプリが除外されているか |
| 検証方法 | 新規または初期化済み端末で登録完了まで通るか |
本番展開前には、少なくとも1台の初期化済み端末で、Wi-Fi接続、Googleセットアップ、Intune登録、ユーザーサインイン、アプリ配布、準拠状態の反映までを通しで確認してください。
Microsoft Authenticatorの自動インストールにも注意
fully managed devicesでは、登録中にMicrosoft Authenticatorアプリが自動的にインストールされます。このアプリはこの登録方式に必要で、アンインストールできません。(Microsoft Learn)
そのため、ユーザー向けの配布資料には「なぜAuthenticatorが入っているのか」「削除できないのは正常動作であること」を明記しておくと、問い合わせを減らせます。多要素認証やパスワードレス認証の運用がある組織では、Authenticatorの役割をセキュリティ教育と合わせて説明すると効果的です。
トークンの置き換え・失効・エクスポートの運用
登録トークンは作成して終わりではありません。Intune管理センターでは、トークンの置き換え、失効、エクスポートが可能です。トークンを誤って関係者以外に共有した場合や、予定していた登録作業が完了して不要になった場合は、失効を検討します。トークンを置き換え・失効・エクスポートしても、すでに登録済みのデバイスには影響しません。(Microsoft Learn)
| 操作 | 使う場面 | 注意点 |
|---|---|---|
| Replace token | 期限が近い、または新しい登録用に更新したい | 新しい登録手順書への差し替えが必要 |
| Revoke token | 誤共有、展開完了、セキュリティリスクがある | 以後そのトークンでは登録できない |
| Export token | Zero TouchやKnox Mobile Enrollment用にJSONを使う | JSONの保管場所とアクセス権を制限する |
トークンやQRコードは、実質的に端末登録の入口です。社内Wikiに広く掲載するより、対象プロジェクトの管理者、キッティング担当者、委託先ベンダーに限定して共有するほうが安全です。
Android device administratorからの移行時に見るべき点
古いAndroid device administrator管理を使っている組織は、Android Enterpriseへの移行計画も合わせて確認してください。Microsoft Learnでは、Android device administrator管理はGMSにアクセスできるデバイスでは非推奨であり、別のAndroid管理方式への切り替えが推奨されています。(Microsoft Learn)
ただし、device administratorからfully managedへ「そのまま上書き移行」できると考えるのは危険です。会社所有・業務専用端末としてfully managedに移行する場合、多くのケースでは端末の初期化、再登録、アプリ再配布、ユーザーデータ退避、利用者への案内が必要になります。
移行計画では、次の順番で整理すると失敗しにくくなります。
| 手順 | やること |
|---|---|
| 現状把握 | device administrator管理の端末台数、OS、GMS有無、利用部門を棚卸しする |
| 管理方式の再選定 | fully managed、corporate-owned work profile、personally owned work profile、dedicatedのどれに移すか決める |
| 登録制限の見直し | 新規端末が旧方式で登録されないようにする |
| パイロット | 少数端末で初期化、登録、ポリシー、アプリ、条件付きアクセスを検証する |
| ユーザー案内 | 初期化の影響、バックアップ、再サインイン、利用開始手順を通知する |
| 本番展開 | 部署や拠点単位で段階的に移行する |
個人所有端末をdevice administratorから移行する場合は、Microsoft Learnでpersonally owned work profileへの移行フローも案内されています。たとえば、コンプライアンスポリシーでdevice administrator管理の端末を非準拠にし、ユーザーに解除とwork profile登録を促す流れが説明されています。(Microsoft Learn)
開発者・社内アプリ担当者が確認すべきこと
Android Enterprise fully managedの展開は、Intune管理者だけの作業ではありません。社内アプリ、業務アプリ、認証、ネットワーク、ヘルプデスクの担当者も影響を受けます。
社内アプリ担当者は、Managed Google Play経由で配布するアプリ、必須アプリ、アンインストール禁止にするアプリ、初回起動時に権限許可が必要なアプリを整理してください。fully managedではユーザーの自由度を下げられる一方、初期設定で必要な権限やアプリ構成が不足すると、現場では「端末は配られたが業務アプリが使えない」という状態になります。
開発者が特に確認すべき点は次の通りです。
| 確認項目 | 理由 |
|---|---|
| アプリ配布方式 | Managed Google Play、社内アプリ、LOBアプリのどれで配布するか決めるため |
| 初回起動時の権限 | カメラ、位置情報、ストレージなどの権限が業務に必要か確認するため |
| ユーザー関連付け | ステージング中はユーザー情報が確定していないため、ユーザー名依存処理に注意するため |
| 条件付きアクセス | アプリ側の認証が登録直後の端末状態で失敗しないか確認するため |
| ネットワーク要件 | 初期セットアップとアプリ通信で必要な宛先が許可されているか確認するため |
特にステージング展開では、端末が最終ユーザーに関連付けられる前の段階と、ユーザーがIntuneアプリにサインインした後の段階で状態が変わります。ユーザー名、部署、ライセンス、グループメンバーシップを前提にするアプリや構成は、最終サインイン後に正しく適用されるかを検証してください。
展開前チェックリスト
本番展開前には、次の項目を確認しておくと、登録失敗や配布後の問い合わせを減らせます。
| 分類 | チェック内容 |
|---|---|
| 端末 | Android 10以降、GMS利用可能、Play Protect認定、必要な通信経路を確認した |
| Intune | MDM authority、Android Enterprise接続、登録プロファイル、スコープタグを確認した |
| トークン | 通常トークンかステージングトークンかを決め、共有範囲を制限した |
| グループ | 登録時グループ化、動的グループ、割り当てフィルターの役割を分けた |
| 条件付きアクセス | Microsoft Intuneクラウドアプリの除外要否を確認した |
| アプリ | 必須アプリ、Managed Google Play、社内アプリ、アプリ構成を検証した |
| 命名規則 | サポート時に識別しやすいデバイス名テンプレートを決めた |
| 登録方法 | QR、Zero Touch、Knox Mobile Enrollment、NFC、トークン入力から選定した |
| ユーザー案内 | 初期サインイン、Authenticator、問い合わせ先、利用開始手順を用意した |
| 検証 | 初期化済み端末で登録から準拠状態反映まで通しで確認した |
まとめ：まずは登録方式とグループ設計を固める
Microsoft IntuneでAndroid Enterprise fully managed devicesを展開する際は、登録プロファイルを作るだけでは不十分です。成功のポイントは、端末要件、トークン種別、登録時グループ化、条件付きアクセス、アプリ配布、ユーザー案内を一つの展開フローとして設計することです。
特に確認すべき優先順位は次の通りです。
| 優先度 | やること |
|---|---|
| 高 | Android 10以降・GMS対応・Android Enterprise連携を確認する |
| 高 | 条件付きアクセスで登録を妨げる設定がないか確認する |
| 高 | 通常トークンとステージングトークンのどちらを使うか決める |
| 中 | 登録時グループ化、動的グループ、割り当てフィルターを使い分ける |
| 中 | QR、Zero Touch、Knox Mobile Enrollmentなど展開方法を決める |
| 中 | 端末名テンプレートとトークン管理ルールを整備する |
これから展開する管理者は、まず検証用の登録プロファイルを作成し、1台の初期化済み端末で登録、サインイン、アプリ配布、準拠状態、条件付きアクセスまで確認してください。その結果をもとに、本番用プロファイル、グループ、登録方法、ユーザー向け手順書を整えるのが最短で安全な進め方です。
コメント