Azure ポータルや Intune 管理センターで、普段はサインインできるのに管理操作のタイミングで Microsoft Authenticator のコード入力を何度も求められ、しかも QR コードが出ず再登録できない――。端末初期化や機種変更のあとに起きやすい「MFA 登録情報の不整合」と、唯一のグローバル管理者が陥るテナント ロックアウトの復旧手順を、原因整理から再発防止までまとめます。
起きていること：サインインはできるのに「管理系の操作」だけ追加認証がループする
今回のトラブルは、次のような “一見すると矛盾して見える” 症状が特徴です。
- Microsoft 365（Office 365）のメールや Teams など、日常利用は問題なく使える
- Azure クレジット購入、サブスクリプション管理、ユーザーや課金の詳細表示など「管理者向けの画面」に入ると、Authenticator の確認コード（または承認）を何度も要求される
- Microsoft Authenticator アプリを入れ直したら、アプリ内から該当アカウントの登録が消えた
- ところがポータル側は QR コード（セットアップ用のコード）を出さず、ひたすら「コードを入力」だけ求める
- テナント内に自分以外の全体管理者（グローバル管理者）がいない
結論から言うと、これは「ポータル側は MFA 登録済みだと思っているのに、端末側の Authenticator からは登録が消えている」ことで発生する不整合です。さらに、唯一のグローバル管理者だと自分でリセットできず、テナント ロックアウト（自己復旧不能）に陥ります。
この問題が起きやすいタイミング
「突然サインインできなくなった」というより、環境変化の直後に発生することが多いです。心当たりがある場合は、原因がかなり絞れます。
| タイミング | なぜ起きやすいか | 見落としがちな点 |
|---|---|---|
| スマホの初期化・機種変更 | Authenticator の登録情報が端末依存で消えることがある | クラウドバックアップが無効だと復元できない |
| Authenticator アプリの削除→再インストール | アプリ内のアカウントが空になり、コード生成ができない | 「アカウント自体は Entra 側に残っている」ため QR が出ないことがある |
| 管理者権限の付与・条件付きアクセス変更 | 管理ポータルが MFA 必須になり、ステップアップ認証が発動 | 普段の Microsoft 365 利用と、管理操作の認証要件は別物 |
| 新しい PC・新しいブラウザーでの管理作業 | 未知の端末として扱われ、追加認証が要求されやすい | Cookie 削除やシークレットモードでも同様に再要求される |
まずは切り分け：自力で直せるパターンか、サポート必須か
同じ「Authenticator が通らない」でも、状況によって対応が大きく変わります。以下の表で、今の状態を素早く整理してください。
| 状況 | よくある表示・挙動 | 自力復旧の可能性 | まずやること |
|---|---|---|---|
| 別の MFA 手段（SMS、メール、FIDO2 キー等）が残っている | 「別の方法でサインイン」から選べる | 高い | 別手段で突破 → セキュリティ情報から Authenticator を再登録 |
| まだ Authenticator が生きている端末が手元にある | 承認通知が届く / コードが見える | 高い | 旧端末でサインイン → 新端末を追加登録（バックアップ復元も検討） |
| サインインはできるが管理画面で追加認証が無限ループ | 管理操作のたびにコード要求、QR が出ない | 中 | myaccount のセキュリティ情報で「古い Authenticator を削除」できるか確認 |
| 唯一のグローバル管理者で、MFA 手段が全部失われた | 管理系操作に進めない / 登録し直す画面が出ない | 低い（ほぼ不可） | Microsoft サポートに連絡し、本人確認のうえテナント ロックアウト解除を依頼 |
この記事の中心は最後の行、つまり「唯一のグローバル管理者が Authenticator を失ってロックアウト」したケースです。ただし、同様の症状で悩む人の多くは、実は上の表の上段で自力復旧できることもあるため、一般的な復旧フローも先に押さえます。
原因の整理：なぜ QR コードが表示されず、コード入力だけ要求され続けるのか
管理ポータルは “追加認証” が前提になりやすい
Microsoft Entra 管理センター（旧 Azure AD）、Azure ポータル、Intune 管理センターは、一般ユーザー向けアプリよりも権限が強く、誤操作・乗っ取りの被害が大きくなります。そのため、テナントの設定によっては管理者アカウントに MFA を必須化していることがほとんどです。
特に次の要因があると、「普段は使えるが管理操作だけ追加認証が要求される」状態が起きやすくなります。
- セキュリティ既定値（Security Defaults）が有効
- 条件付きアクセスで「管理ポータルへのアクセス時に MFA 必須」などのポリシーがある
- リスクベースのサインイン制御で “ステップアップ認証” が動く
Authenticator を再インストールすると、端末側の登録が消えることがある
端末の初期化・機種変更・アプリ削除は、Authenticator 側の登録情報に影響します。バックアップを使って復元できるケースもありますが、バックアップが無効だったり、復元に失敗したりするとアプリ内からアカウント設定が消えることがあります。
また、実は「Authenticator の登録は残っているのに通知だけ届かない」という別パターンもあります。通知が来ない場合は、MFA そのものの問題ではなく、端末設定に原因があることもあるため、次をチェックすると切り分けができます。
- スマホの日時が自動設定になっているか（時刻ずれは認証失敗の原因になり得ます）
- OS の通知設定で Authenticator の通知が許可されているか
- 省電力設定やバッテリー最適化で通知が抑制されていないか
- ネットワークが社内 Wi-Fi 固定で制限されていないか（モバイル回線でも試す）
ポータル側は「登録済み」と認識しているため、再登録フローに進ませない
ここがハマりポイントです。ポータル側（Entra ID 側）のセキュリティ情報には「このユーザーは Authenticator を登録済み」という状態が残っていることがあります。すると、サインイン時に出るのは“再登録（QR コード表示）” ではなく “既存登録での確認”です。
しかし端末側には登録がないため、ユーザーはコードを出せず、結果としてコード入力要求がループします。これが「QR コードが出ないのにコードだけ求められる」現象の正体です。
自力で復旧できる場合：セキュリティ情報から Authenticator を再登録する
もし少しでも管理画面に入れる、または別の認証手段でサインインできるなら、まずはセキュリティ情報（Security info）の整理で復旧できる可能性があります。
手順の全体像
- ブラウザーで https://myaccount.microsoft.com/ を開く
- 「セキュリティ情報」または「セキュリティの概要」へ進む
- 古い Microsoft Authenticator が残っていれば削除する（削除できない場合は次の章へ）
- 「サインイン方法の追加」で Microsoft Authenticator を追加する
- 画面に出る QR コードを、Authenticator アプリで読み取って登録する
- 登録直後にテスト（承認通知、コード生成）を行い、管理ポータルで再確認する
ここでつまずきやすいポイント
- QR コードが表示されない：古い Authenticator が “既定の方法” になっていて、削除・変更が必要な場合があります
- 同じ端末でブラウザーと Authenticator を操作して混乱する：可能なら PC ブラウザー＋スマホ Authenticator の組み合わせが確実です
- アカウントが複数ある：職場アカウント（Work/School）と個人 Microsoft アカウントを取り違えると、いつまでも解決しません
- 会社のプロキシやフィルタリング：QR 表示ページや認証ページが途中でブロックされると、登録が完了しないことがあります
唯一のグローバル管理者がロックアウトした場合：セルフサービスでは復旧できない
ここからが本題です。テナント内に他の全体管理者がいない状態で、MFA の手段を失うと、管理者が自分で自分の MFA をリセットできません。これがテナント ロックアウト状態です。
この状況では、一般的な「セキュリティ情報から削除して追加」や「別の管理者にリセットしてもらう」が成立しません。最終的な解決は、Microsoft サポートに連絡して本人確認を行い、ロックアウト解除・MFA 再設定をしてもらうことになります。
実際の解決ルート：サポートチケット → Data Protection チームへエスカレーション
今回のケース（Accepted Answer）では、ユーザーが自分でチケットを起票できない状態だったため、モデレーターがオフラインで情報を受け取り、サポート チケットを代理で起票しました。その後、チケットは「データ保護（Data Protection）チーム」へエスカレーションされ、テナント ロックアウトの解除や MFA 再登録に向けた手続きが進む流れとなりました。
ポイントは次の 1 行です。
唯一のグローバル管理者が MFA を失って復旧不能な場合は、Microsoft サポート（Data Protection チームの手続き）でロックアウト解除・MFA 再設定を依頼する必要がある。
サポートへ伝えるときの文例
唯一のグローバル管理者アカウントで Microsoft Authenticator の登録を失い、管理ポータルで MFA が通らずテナント ロックアウト状態です。自力でセキュリティ情報を変更できないため、本人確認のうえ MFA の再登録（リセット）とロックアウト解除をお願いします。
「MFA が壊れた」だけだと一般的な案内に流れやすいため、“唯一のグローバル管理者” と “テナント ロックアウト”を必ずセットで伝えるのがコツです。
サポートに連絡する前に準備しておくとスムーズな情報
Data Protection チームでの対応は、テナントの所有者確認（本人確認）が重要になります。環境により求められる内容は変わりますが、一般に以下を整理しておくとやり取りが早くなります。
| 準備項目 | 例 | 目的 |
|---|---|---|
| テナント情報 | テナント名、初期ドメイン（xxxxx.onmicrosoft.com） | 対象テナントの特定 |
| 影響ユーザー | ロックアウトした管理者 UPN（例：[email protected]） | 対象アカウントの特定 |
| 課金・契約の手がかり | サブスクリプション名、請求先情報、過去の請求書 | 所有者確認の材料 |
| 連絡先 | 連絡可能なメール、電話番号 | 本人確認と連絡経路の確保 |
| 事象の時系列 | 端末初期化日、アプリ再インストール日、発生し始めた操作 | 原因特定・優先度判断 |
「チケットを作れない」場合の考え方
ロックアウト状態だと、管理センターからのサポート起票が難しいことがあります。その場合は、次のような “現実的な入口” を探すのが重要です。
- 組織内に契約担当者や支払い担当者がいるなら、その人のアカウントからサポート起票する
- 購入経路がパートナー（販売店、SIer、CSP）なら、パートナー経由でサポートに繋げてもらう
- どうしても社内で起票できない場合、Microsoft のサポート窓口（契約形態に応じた連絡手段）を利用し、テナント ロックアウトであることを明確に伝える
大切なのは、問題を「Authenticator アプリが壊れた」ではなく、「唯一のグローバル管理者が MFA を失ってテナント ロックアウトした」と伝えることです。これにより、適切なチーム（Data Protection を含む）に回る可能性が上がります。
やってはいけないこと
- 無理に何度も試行し続ける：組織のポリシーによってはアカウントロックや追加の保護が働き、復旧がさらに面倒になることがあります
- 場当たり的に権限を盛る：復旧後の安全性が下がり、監査でも問題になりがちです。必要な範囲で最小権限に戻す前提で動きましょう
- 緊急用アカウントを “とりあえず” 作って放置する：緊急用ほど管理が重要です。保管・監視・定期テストまでセットで設計します
復旧後に必ずやるべきこと：同じ事故を二度起こさないための運用
ロックアウトから復帰できたら、同じテナントで同じ事故が再発しないよう、すぐに運用を整えましょう。特に「唯一のグローバル管理者」という状態は、仕組みの問題ではなく運用設計の問題として扱うのが安全です。
推奨される再発防止策
| 対策 | 狙い | 具体例 | 優先度 |
|---|---|---|---|
| グローバル管理者を複数用意 | 1 人ロックアウトで全停止を防ぐ | 少なくとも 2 名、できれば緊急用を含めて 3 名 | 最優先 |
| MFA 方法を複数登録 | Authenticator 以外の逃げ道を作る | 電話（SMS/音声）、メール、FIDO2 セキュリティキー | 最優先 |
| Authenticator のクラウドバックアップを有効化 | 機種変更・初期化時の復旧を容易に | iOS は iCloud、Android は Google アカウントと連携 | 高 |
| 管理用アカウントを日常利用と分離 | 端末トラブルや乗っ取りの影響範囲を縮小 | メール閲覧用と管理用を別 UPN にする | 高 |
| 緊急用アカウント（ブレークグラス）の設計 | 最後の復旧手段を確保 | 強固なパスワード＋保管ルール＋監視、条件付きアクセス除外の検討 | 高 |
“ブレークグラス” を作るときの注意
緊急用アカウントは便利ですが、雑に作ると逆にリスクになります。最低限、以下の考え方を押さえると安全性が上がります。
- パスワードは十分に長くし、社内の安全な保管ルール（物理金庫、パスワード管理ツールの限定共有など）を決める
- サインインログを監視し、普段使われていないことを前提にアラートを設定する
- 「使わない前提」だからこそ、定期的にテスト（実際にサインインできるか、MFA が有効か）を行う
- 緊急用は “強い権限” を持つため、普段の作業には使わず、必要なときだけ使うルールを徹底する
復旧直後にやる順番（おすすめ）
復旧できた勢いで設定をあちこち触ると、また認証が崩れることがあります。安全に整える順番の一例を示します。
- 別ユーザー（または別アカウント）にグローバル管理者を追加し、単独状態を解消する
- 管理者アカウントに複数の MFA 方法を登録し、Authenticator だけに依存しない
- 緊急用アカウント（ブレークグラス）の方針を決め、保管・監視・テストまで実装する
- 日常利用アカウントと管理用アカウントを分離し、管理用は必要時のみ使う
- 最後に条件付きアクセスやセキュリティ既定値を見直し、意図した設計になっているか確認する
よくある質問：同じ現象で検索している人が気になるポイント
普段の Microsoft 365 は使えるのに、Azure だけ Authenticator を何度も要求されます
管理ポータルに対して、条件付きアクセスやセキュリティ既定値が追加の MFA（ステップアップ認証）を要求している可能性が高いです。「普段のサインイン」と「管理操作」はリスクが異なるため、挙動が変わること自体は珍しくありません。
QR コードが出ないのはなぜですか？
多くの場合、アカウント側は「Authenticator 登録済み」と認識しており、再登録ではなく既存登録での確認を求めているためです。自力で復旧できる状況なら、セキュリティ情報から古い登録を削除して、改めて QR コード表示のフローに戻します。
唯一のグローバル管理者ですが、どうしても急ぎで管理作業が必要です
残念ながら、MFA 手段が失われた “唯一のグローバル管理者” の状態は、自己解決できない前提で動くのが現実的です。急ぎの場合こそ、サポートへテナント ロックアウトとして連絡し、Data Protection チームの手続きを進めてもらう必要があります。
再発防止で「SMS を追加」しておけば十分ですか？
SMS は “追加の逃げ道” として有効ですが、回線変更や海外滞在、端末紛失で詰むこともあります。現実的には、Authenticator＋FIDO2 キー＋電話のように、種類の異なる手段を組み合わせておくと復旧力が上がります。
チェックリスト：この記事どおりに動くための最短手順
- まず「別の方法でサインイン」が残っていないか確認する
- 残っているなら、myaccount のセキュリティ情報で Authenticator を再登録する
- 通知が来ないだけなら、スマホの通知・時刻・省電力設定も確認する
- 残っていない、かつ自分が唯一のグローバル管理者なら “テナント ロックアウト” と判断する
- サポート連絡用にテナント名、onmicrosoft.com、UPN、課金情報、時系列を整理する
- 復旧できたら、グローバル管理者の複数化と MFA 手段の複数登録を最優先で実施する
まとめ：Authenticator コード要求ループは「登録情報の不整合」、唯一の管理者ならサポート復旧が必要
Authenticator のコード入力が何度も求められ、QR コードが表示されない問題は、端末側の登録が消えた一方でアカウント側が「登録済み」と認識している不整合で起きやすいトラブルです。自力で復旧できる余地があるなら、myaccount のセキュリティ情報から古い Authenticator を整理して再登録します。
一方、テナントに他の全体管理者がいない状態で MFA 手段を失った場合は、セルフサービスでは復旧できません。Microsoft サポートにチケットを上げ、Data Protection チームの手続きでテナント ロックアウト解除・MFA 再設定を進めるのが根本解決になります。復旧後は、管理者の複数化と認証手段の分散を徹底し、同じ事故を仕組みで防ぐ運用に切り替えましょう。
コメント