Xiaomi Redmi Note 14 Pro+／Redmi Note 14（HyperOS）をMicrosoft IntuneでAndroid Enterprise登録しようとすると、「デバイスを設定しています」の直後に「アカウントを選択」へ戻り続け、登録が完了しないことがあります。この記事では、原因の切り分けから、OS更新→初期化→再登録の実践手順、どうしても解決しない場合のMAM（アプリ保護）運用まで、現場で役立つ対処法をまとめます。
起きている症状：登録ウィザードが同じ画面を行ったり来たりする
現象は、端末側のセットアップ（初期設定）や、Intuneの登録フローの途中で発生します。典型的には次の流れです。
- 「デバイスを設定しています（Setting up device）」が表示される
- しばらく待つと、「アカウントを選択（Pick an account）」に戻る
- 再度アカウントを選ぶと、また「デバイスを設定しています」→「アカウントを選択」に戻る
このループが続くと、管理者側（Intune管理センター）にも端末が正常に登録されず、利用者としては「いつまで待っても進まない」「何を選んでも同じ画面に戻る」状態になります。
前提知識：IntuneのAndroid管理はAndroid Enterpriseが本命
Microsoft IntuneでAndroid端末を「端末として」管理する場合、現在の主流はAndroid Enterprise（以下AE）です。AEはGoogleが提供する企業向け管理基盤で、Work Profile（仕事用プロファイル）や、完全管理（Fully managed）、COPE（会社所有・個人利用）などの方式を使い、端末と業務領域を分けて制御します。
一方で、端末メーカーの独自UI（HyperOSなど）や地域向けビルド差、Google関連コンポーネントの実装差によって、同じ「Android」でもAEの挙動が端末によって大きく変わることがあります。今回の「アカウントを選択」無限ループも、まさにこの領域で起きやすいトラブルです。
| 登録方式（例） | 主な用途 | 現場でのポイント |
|---|---|---|
| 個人所有（BYOD）＋仕事用プロファイル | 個人端末に業務領域だけを作る | 「仕事用」と「個人用」を分けられる。最も導入しやすい |
| 完全管理（会社所有） | 社用端末を強く統制する | 初期セットアップ時の登録が必須。トラブル時は初期化が現実的 |
| COPE（会社所有・個人利用） | 社給端末だが私用も許可 | セキュリティ要件と利用者体験のバランスを取りやすい |
| 専用デバイス（Dedicated） | キオスク／業務専用端末 | 用途限定で安定するが、端末選定が重要 |
結論の見立て：非互換・未認定・OSビルドが絡む“相性問題”になりやすい
質問のケースでは、当初Redmi Note 14 Pro+がAndroid Enterpriseの対応デバイス一覧に存在しないことが確認された、という整理になっています。これは実務的に大きな意味があります。
- AEの認定や推奨に含まれない端末では、登録が途中で失敗したり、UIがループしたりしても「端末側の非互換・未対応」と解釈されやすい
- 同一機種でも、OSビルド（HyperOSのバージョン）によって挙動が変わることがある
- 登録フローで必要なコンポーネント（Google Play開発者サービス、Android System WebView等）の更新状態や、初期セットアップ時のアカウント追加順序が影響する場合がある
| 疑うポイント | 起きがちな兆候 | まず取るアクション |
|---|---|---|
| Android Enterprise非対応／認定が不完全 | 登録が最後まで進まない、同じ画面に戻る | 公式デバイス一覧でモデル名・地域差を確認し、対応機種か判断する |
| HyperOSのビルドが古い | 初期出荷状態では失敗するが、アップデート後に改善する例がある | まず通常起動してOSを手動で最新化→初期化→再登録を試す |
| 初期設定時のアカウント追加順序が悪い | Googleアカウントを追加済みだとループする／Work Profile生成に失敗 | 「何も入れない素の状態」から更新→初期化→登録する |
| Intune設定側の制限 | 特定方式のみ失敗、ユーザーのみ失敗、端末台数制限に引っかかる | 登録制限・コンプライアンスポリシー・条件付きアクセスを点検する |
最初に必ず確認したい：Android Enterprise対応デバイス一覧（認定状況）
「端末がAEの対象かどうか」は、トラブルシュートの最短ルートです。現場では、端末名だけでなく、モデル表記・地域コード・OSビルドまで揃えて確認します。
| 確認項目 | どこで見る | メモ |
|---|---|---|
| 端末の正式モデル名 | 設定 → 端末情報 | 「Redmi Note 14 Pro+」のような通称と、型番表記が異なることがある |
| HyperOSのビルド番号 | 設定 → 端末情報 → HyperOSバージョン | 同じ機種でもビルド差でAE挙動が変わり得る |
| 地域コード（例：EUXM等） | ビルド番号の末尾等 | 地域別ビルドは配信時期や修正内容がズレることがある |
| AE認定（Recommended/Certifiedなど） | Android Enterprise公式のデバイス一覧 | 「載っていない＝絶対不可」とは限らないが、安定運用の指標になる |
もし一覧に存在しない、または企業管理の方式（完全管理・仕事用プロファイル等）が想定どおりにサポートされていない場合、端末登録（MDM）ではなくMAM運用へ切り替える判断も早めに検討したほうが、運用コストを抑えられます。
最有力の回避策：OSを特定ビルドまで手動アップデート→初期化→再登録
同じRedmi Note 14 Pro+で、手順を工夫すると登録に成功したという報告があります。ポイントは「先にOSを徹底的に最新化し、その後に工場出荷状態へ戻してから登録する」ことです。
成功例として共有された流れ
- 端末を初期セットアップする際、Intune関連の操作をしない（登録画面へ進めない）
- Googleアカウントも追加しないで、とにかく通常起動してホーム画面まで到達する
- 設定 → 端末情報（About phone）からシステムアップデートを手動で何度も実行し、最新まで上げる
- 報告例では、OSビルドを2.0.1.0.VOPEUXMまで更新した後に改善した
- 更新が完了したら、端末を工場出荷状態にリセットする
- 再度初期セットアップを開始し、今度はIntuneの手順に従ってAE登録を実施する
この流れで、「アカウントを選択」画面への無限ループが解消され、登録が完了したとされています。
| 手順 | 狙い | よくある落とし穴 |
|---|---|---|
| 先に素の状態で起動 | 登録前に必要コンポーネントを整える | 途中でGoogleアカウントを追加すると、後の登録で相性が出る場合がある |
| アップデートを“何度も”手動実行 | 段階的配信を取り切る | 1回の更新で最新にならない。複数回の更新が必要なことがある |
| 工場出荷状態にリセット | 最新ビルドの状態で初期セットアップからやり直す | データが消えるため、業務端末運用なら導入手順として組み込む |
| リセット後にAE登録 | 端末オーナー／プロファイルを正しく作る | ネットワーク不安定や条件付きアクセスで、別の失敗要因が混ざることがある |
なぜ「アップデート→初期化」が効くのか（実務的な説明）
AE登録では、端末側で管理領域の作成（Work Profile作成やDevice Owner設定）が行われます。HyperOSの初期ビルドでここに不具合があると、端末は「続行できない」ため前の画面に戻り、結果として無限ループのように見えることがあります。
いっぽうで、OS更新により、メーカー側がAE周り（端末オーナー設定、Googleコンポーネント連携、セットアップウィザード）の修正を取り込むと、同じ端末でも登録が通るケースがあります。さらに、いったん登録を試した状態が残っていると復旧が難しいため、最新化した上で初期化し、最初から正しい登録フローを踏むのが最も現実的です。
Redmi Note 14（無印）でまだ改善しないケースがある理由
Redmi Note 14（無印）については「デバイス一覧上は認定済みになったのを確認したが、同様の手順でもまだうまくいかない」という声もあります。ここから言えるのは、認定表示だけで“必ず安定する”とは限らないということです。
- 認定や推奨はモデル単位でも、実運用では地域ビルド差・配信時期差が影響する
- Intune側の登録方式（仕事用プロファイル／完全管理など）によって、端末が要求する前提が変わる
- 条件付きアクセス、端末台数制限、アカウント状態など、管理側要因が混ざると再現が難しくなる
そのため、成功報告がある手順は「最初に試すべき強力な候補」ではあるものの、全端末での万能薬ではないと理解したうえで運用フローに落とし込むのが安全です。
無限ループが続くときの追加チェック（端末側）
アップデート→初期化→再登録をしても改善しない場合、端末側で次の点を確認します。管理者が遠隔で把握しにくい箇所もあるため、端末利用者向けのチェックリストとしても有効です。
| チェック項目 | 確認方法（例） | 改善の方向性 |
|---|---|---|
| Wi-Fi/通信が安定しているか | 別アプリのログインやストア更新ができるか | キャプティブポータル、プロキシ、フィルタリングがあると登録が途中で戻ることがある |
| 日時の自動設定 | 設定 → 日付と時刻 → 自動設定 | 時刻ズレは認証失敗の原因になりやすい。自動設定をONにする |
| Google Play開発者サービスの更新 | Playストアで更新が残っていないか | 古いままだとAE関連処理が不安定になることがある |
| Android System WebView／Chromeの更新 | Playストアで更新確認 | サインイン画面が正しく開かず、同じ画面へ戻る事象が起きることがある |
| 既存の仕事用プロファイルの残骸 | 設定 → アカウント/仕事用プロファイル | 残っている場合は削除し、必要なら初期化でクリーンにする |
| Miアカウントの状態 | 設定 → Miアカウント | 端末保護・アクティベーション関連の制限が強いと初期化後の進行に影響することがある |
無限ループが続くときの追加チェック（Intune管理側）
端末側の問題に見えても、管理側設定が原因で「途中で戻る」ことがあります。特に次の項目は、現場で見落とされがちです。
| チェック項目 | 何が起きるか | 確認ポイント |
|---|---|---|
| 登録制限（Enrollment restrictions） | 特定の登録方式がブロックされ、途中でやり直しになる | Android Enterpriseの方式（個人所有/会社所有）や、ユーザーグループ対象を確認 |
| ユーザーの端末登録台数上限 | 上限超過で登録が失敗する | 同一ユーザーが既に複数台登録していないか、不要端末を整理する |
| 条件付きアクセス（Conditional Access） | サインインはできても、デバイス準拠が満たせず先へ進めない | 登録途中に適用されるポリシーがないか、例外設定を検討する |
| 準拠ポリシーの要求が厳しすぎる | OSバージョン要件などで即不合格になり、ユーザー体験がループに見える | 新機種導入時は段階的に要件を上げる運用が安全 |
| 登録方式の取り違え | 完全管理を想定しているのにWork Profile手順を踏むなど | QRコード、トークン、Zero-touchなど、導入方式を統一する |
どうしても端末登録が不安定なら：MAM（アプリ保護ポリシー）に切り替える
端末がAE非対応、もしくはAE登録が安定しない状況では、現場の落としどころとしてMAM（モバイル アプリケーション管理）が有効です。いわゆる「デバイス登録なしのアプリ保護」で、Outlook、Teams、OneDriveなど対象アプリに対して、業務データの持ち出し制御やPIN要求、暗号化などを適用できます。
MAMでできること（代表例）
- 業務アプリへのアクセスにPIN/生体認証を要求
- コピー＆ペーストや「他アプリへ共有」の制限
- 端末紛失時に、業務アプリ内のデータだけをワイプ
- スクリーンショットやバックアップの制御（アプリ仕様に依存）
MDM（端末登録）とMAM（登録なし）を比較
| 観点 | MDM（Android Enterprise登録） | MAM（デバイス登録なし） |
|---|---|---|
| 管理対象 | 端末全体（または仕事用プロファイル） | 対象アプリとその業務データ |
| できること | Wi-Fi/VPN/証明書配布、デバイスポリシー強制、準拠判定など幅広い | アプリ内データ保護に集中。導入が軽い |
| できないこと | ― | 端末全体の設定強制、端末準拠（デバイスコンプライアンス）を前提とする制御は難しい |
| ユーザー体験 | 登録手順が必要。機種によってトラブルが起きる | アプリ導入とサインイン中心。端末相性の影響を受けにくい |
| 向くケース | 社給端末、強い統制、監査要件が厳しい | BYOD、暫定運用、端末選定が難しい現場 |
つまり、「完全にIntune管理された社用端末」としては扱えない場合でも、アプリ単位でセキュリティを確保する運用に切り替えることで、業務継続とリスク低減の両立ができます。端末登録に固執して現場を止めるより、MAMで守れる範囲を先に固めるほうが、実務では成功率が高いことも多いです。
メーカー・ベンダーへ問い合わせるなら、最初から情報を揃える
この種の問題は「端末固有の実装」「OSビルドの不具合」「管理側ポリシー」が絡むため、問い合わせ時に情報が不足すると往復が増えます。次の情報をテンプレとして揃えておくと、解決が早くなります。
| 項目 | 具体例 | 備考 |
|---|---|---|
| 機種名・型番 | Redmi Note 14 Pro+ など | 通称だけでなく型番があると確実 |
| HyperOSビルド | 2.0.1.0.VOPEUXM など | 地域コード込みで伝える |
| 登録方式 | 仕事用プロファイル／完全管理／COPE | QRコード、トークン等の手順も添える |
| 発生タイミング | 「Setting up device」後に「Pick an account」に戻る | 可能なら画面名を英語のまま記載すると伝わりやすい |
| 管理側設定の有無 | 登録制限、条件付きアクセス、準拠ポリシー | 適用対象グループも含めると切り分けが進む |
問い合わせ先は、基本的にMicrosoft（Intune）、端末メーカー（Xiaomi）、そしてAE認定や端末側要件の観点ではGoogle（Android Enterprise）が絡みます。特に「AE対応デバイス一覧への追加」「特定ビルドでの不具合修正」はメーカー側の対応になることが多いため、機種名・ビルド名を明確にして依頼するのが重要です。
他機種（Redmi Pad Proなど）へ応用する場合の考え方
同じ手順が別端末で必ず通るとは限りませんが、Xiaomi製端末でAE登録トラブルが出たときの基本形として、次の順序は汎用性があります。
- Android Enterpriseの公式デバイス一覧で、対象機種が企業管理をサポートしているか確認
- 素の状態で一度起動し、OSを最新まで手動更新（複数回）
- 工場出荷状態にリセットし、初期セットアップからAE登録
特にタブレットは、スマホと同じHyperOSでもコンポーネント構成が異なり、Work Profileの生成や専用デバイスモードでの要件が変わることがあります。まずは「対応機種かどうか」「想定する登録方式がサポートされているか」を確認してから、導入台数を増やすのが安全です。
現場向け：標準トラブルシュートフロー（決め打ちで迷わない）
最後に、現場で運用しやすいように「まず何をするか」をフローとしてまとめます。問い合わせ前の一次対応としても、そのまま使えます。
| ステップ | やること | 判断基準 |
|---|---|---|
| 1 | Android Enterpriseのデバイス一覧で認定状況を確認 | 載っていない／方式が合わないなら、MDM運用は慎重に |
| 2 | 素の状態で起動→OSを最新まで手動更新（複数回） | 最新化できないなら、配信時期・地域ビルド差を疑う |
| 3 | 最新ビルド確認後に工場出荷状態へリセット | 登録途中の残骸を消し、初期セットアップからやり直す |
| 4 | Intuneの手順どおりにAE登録（QR/トークン等） | 同じ画面ループが再現するかを確認 |
| 5 | 改善しない場合は、管理側の登録制限・条件付きアクセスを点検 | 特定ユーザーだけ失敗するなら管理側要因の可能性が高い |
| 6 | MDMが不安定ならMAM（アプリ保護）へ切り替え | 業務継続を優先し、端末選定・ベンダー回答を待つ |
まとめ：まずは「最新化→初期化→再登録」、ダメならMAMで現実解を取る
Redmi Note 14 Pro+／Redmi Note 14で発生する「アカウントを選択」無限ループは、HyperOSのビルド差やAE対応状況が絡む“相性問題”として出やすい現象です。実務では、次の二段構えが最も現実的です。
- まずはOSを最新ビルドまで手動アップデート→工場出荷状態にリセット→再登録を試す（成功報告あり）
- それでも改善しない場合は、端末登録をいったん諦め、MAM（アプリ保護ポリシー）だけで運用して業務継続とリスク低減を両立する
社給端末としての安定運用が必須なら、AE認定状況を前提に端末を選定し、導入前に同一ビルドでの登録検証をしてから展開するのが確実です。逆に、端末が多様な現場では、MAMを標準化して「端末に依存しない守り方」を用意しておくと、今回のような相性問題に強い運用になります。
コメント