Azureポータルにサインインすると Microsoft Authenticator の承認が求められるのに、通知が届かず先へ進めない。さらに「自分しか管理者がいない」と思い込んでいると、MFA設定を直せず実質ロックアウトになります。本記事では原因の切り分けと復旧手順、予防策を具体的に解説します。
症状の特徴：Microsoft 365には入れるのにAzureポータルだけ失敗する
今回のようなトラブルは、次の条件が重なると起きやすいです。
- 個人用 Microsoft アカウントで
https://portal.azure.comにサインインすると、Microsoft Authenticator アプリでの承認を求められる - ところがスマホ側にプッシュ通知が来ない／承認画面が出ないため、サインインが完了しない
- 同じアカウントで Microsoft 365（Office 365）などには入れる。そこでの Authenticator 通知は正常
https://portal.azure.com/?l=en.en-us#settings/directoryのような「ディレクトリ一覧」には入れるが、ディレクトリ切り替え時に再度 MFA を要求され、やはり通知が来ない- MFA を直したくても、
https://mysignins.microsoft.com/security-infoにアクセスすると「個人用アカウントではサインインできません。職場または学校アカウントを使用してください」と表示される
ポイントは「同じ Authenticator を使っているように見えても、サービスによって求められる認証の種類が違うことがある」という点です。結果として、Azure側のMFA設定と、実際のAuthenticator（端末・登録状態）が食い違うと、Azureポータルだけサインインが完了しなくなります。
まず押さえる：MicrosoftアカウントとMicrosoft Entra IDアカウントは“別物”
ロックアウト解消の最短ルートは「どの種類のアカウントで、どこにサインインしようとしているか」を整理することです。見た目が似ている画面でも、裏側が違うと管理画面（MFAのリセット手段）も変わります。
| 区分 | 呼び方（よくある表現） | 主な用途 | サインイン先の例 | MFA設定の考え方 |
|---|---|---|---|---|
| 個人用 | Microsoft アカウント / MSA | 個人の Microsoft 365、OneDrive、Xbox など | account.microsoft.com 系 | 個人アカウント側の2段階認証やAuthenticator設定が中心 |
| 組織用 | 職場または学校アカウント / Microsoft Entra ID | 企業・学校のMicrosoft 365、Azure、Entra、Intune など | entra.microsoft.com、mysignins.microsoft.com など | テナント（ディレクトリ）管理者がポリシーと認証方法を管理 |
今回のケースでは、mysignins.microsoft.com に「個人用アカウントではサインインできない」と出ているため、次のどちらか（または両方）が起きている可能性が高いです。
- 個人用 Microsoft アカウントをAzureのテナントに管理者として紐付けて運用している
- 個人用と組織用を同じメールアドレスで使っていて、本人の認識が混同している
どちらにせよ重要なのは、Azureポータル側で要求されるMFAが、スマホのAuthenticator側の状態と一致していないこと。これが「Azureだけ通らない」典型パターンです。
状況整理：テナント ロックアウトに近い状態とは
Azure（正確にはディレクトリ/テナント）では、管理者権限の操作にも強い認証が求められます。ところが、管理者自身がMFAを通せなくなると次の悪循環に入ります。
- Azureポータルに入れない → 管理画面でMFAを修正できない
- MFAを修正できない → 何度試してもサインイン完了できない
- 自分しか管理者がいないと思い込む → 依頼先がなく詰む
この状態は一般に「テナント ロックアウト（管理者が閉め出される）」に近いパターンとして扱われます。完全に詰んでいるように見えますが、実務上は“もう一人のグローバル管理者がいるかどうか”で難易度が大きく変わります。
自分でできる切り分け：通知が来ない原因を潰すチェックリスト
最終的に管理者リセットが必要なケースでも、まずは「単なる端末側の通知問題」ではないことを短時間で確認しておくと、復旧までの時間を縮められます。以下は現場で効果が高いチェックです。
| チェック項目 | 具体的な確認ポイント | よくある落とし穴 | 次の一手 |
|---|---|---|---|
| Authenticatorの通知権限 | OS設定で「通知が許可」されているか、サイレント/集中モードになっていないか | OS更新後に通知がオフ、バッテリー最適化で遅延 | 通知・省電力の例外設定を追加 |
| ネットワーク | Wi‑Fi/モバイル回線で受信できるか、VPNで遮断されていないか | 社内VPN・広告ブロッカー系の通信制限 | 一時的に回線を切替、VPNを停止 |
| 時刻のズレ | スマホの自動時刻設定、タイムゾーンが正しいか | 時刻ズレでトークン不一致になり、承認が出ない/通らない | 自動設定ON→再起動 |
| 同名アカウントの混同 | Authenticator内に同じメールっぽいアカウントが複数ないか | 「個人用」と「職場/学校」が並び、どれがAzureの要求先か分からない | サインイン画面の“アカウント種別”表示を確認 |
| 端末変更・再インストール歴 | スマホ機種変更、Authenticator再インストール、復元の有無 | 旧端末に認証が紐付いたまま／バックアップ復元が不完全 | 管理者による再登録要求が近道 |
| 別のMFA方法の有無 | SMS/電話/FIDO2など代替手段が登録されているか | Authenticator一択だと詰みやすい | サインイン後に必ず複数手段を追加 |
上のチェックで「端末側の問題ではなさそう」「Azureだけ再現する」「MFAの管理画面にも入れない」となった場合は、MFA設定とAuthenticatorの紐付け不整合が疑わしく、本人だけで直すのは難しくなります。
結論：別のグローバル管理者にMFAをリセットしてもらうのが最短
今回の実例では「自分が唯一の管理者だと思っていたが、同じテナント内にもう1つグローバル管理者が存在していた」ことで解決できました。ここが最重要ポイントです。
Azure/Entraの世界では、管理者は“人”ではなく“アカウント”です。過去に作った非常用アカウント、委託先が作った管理者、初期セットアップ時に作った管理用アカウントが残っていることは珍しくありません。思い込みを捨てて、別管理者がいないか探す価値があります。
管理者がやること：MFA設定をクリアし、再登録を要求する
別のグローバル管理者がサインインできるなら、次の流れで復旧します（画面の名称は更新されることがありますが、考え方は同じです）。
| 作業者 | 場所（例） | 操作 | 目的 |
|---|---|---|---|
| 別のグローバル管理者 | Azure ポータル / Entra 管理センター | 対象ユーザーを検索して開く | ロックアウト本人を特定 |
| 別のグローバル管理者 | ユーザーの認証方法（Authentication methods） | 「MFAの再登録を要求」「認証方法のリセット」等を実施 | Authenticator紐付けを初期化 |
| ロックアウトされていた管理者本人 | Azure ポータル サインイン | 表示される手順に従ってAuthenticatorを再登録 | 新しいQRコードで登録し直す |
実務上は、管理者側で次のどれか（または複数）を行うイメージです。
- 「Microsoft Authenticator」を一度削除（または無効化）して、再追加を促す
- 「多要素認証の再登録を要求」して、次回サインイン時に強制セットアップさせる
- サインインセッション/トークンを失効させ、古い状態を引きずらないようにする
本人がやること：再登録後に“二度と詰まない”形に整える
MFAをリセットしてサインインできるようになったら、同じ事故を繰り返さないために「復旧直後の5分」が重要です。おすすめの流れは次の通りです。
- Authenticator を新規登録し、サインインが完了することを確認する
- 予備の認証方法（SMS、電話、FIDO2セキュリティキー等）を追加する
- 管理者アカウントの復旧用メールアドレス/電話番号を最新化する
- “もう一人の管理者”の存在と連絡手段をドキュメント化する
「直った！」で終わりにすると、次の機種変更や端末故障で同じロックアウトが再発します。復旧直後に“保険”を増やしておくのが一番コスパが高いです。
どうしても他に管理者がいない場合：Microsoftサポートでロックアウト解除を依頼する
もし本当に自分しかグローバル管理者がいない、かつその自分がMFAを通せない場合は、ユーザー側だけでの復旧は難しくなります。この場合は、Microsoftサポートに「唯一のグローバル管理者がMFAでロックアウトしている」ことを明確に伝え、本人確認・所有者確認の手続きのうえで対処してもらうのが正攻法です。
サポートに伝えるべき要点
- Azureポータルにサインインできないこと（どのURLで、どの画面まで進み、どこで止まるか）
- 唯一のグローバル管理者がMFAで詰んでいること
- ディレクトリ一覧には入れるが、ディレクトリ切り替えや管理操作でMFAが要求されて進めないこと
mysignins.microsoft.com/security-infoでは個人用アカウントが弾かれ、自己解決できないこと
事前に準備しておくとスムーズな情報
| 項目 | 例 | なぜ必要か |
|---|---|---|
| 連絡先メール | 普段使っている別メール | ロックアウト中のアドレスに連絡できない場合がある |
| 国際電話番号 | +国番号を含む番号 | 本人確認や折り返し連絡の手段として求められることがある |
| 対象の管理者アカウント | 管理者として使っていたメール | どのユーザーのMFAを解除/リセットするか特定するため |
| テナント情報 | 国/地域、タイムゾーン、組織名の表記 | 所有者確認・照合の材料になる |
| ドメイン関連 | カスタムドメインの有無、DNSの管理者が誰か | テナントの所有者であることの裏取りに使われる場合がある |
サポート経由の解除は手続きが必要ですが、焦って手当たり次第に試すより、状況を整理して正面から依頼した方が結果的に早いことが多いです。
再発防止：グローバル管理者とMFAを“詰まない設計”にする
最後に、同じ事故を未然に防ぐための運用ポイントをまとめます。Azure/Entraは「セキュリティを上げるほど、運用が雑だと自分が閉め出される」という性質があります。ここは仕組みで回避しましょう。
| 対策 | 具体例 | 狙い | 現場のコツ |
|---|---|---|---|
| グローバル管理者を複数用意 | 最低2アカウントに付与 | 片方が詰んでももう片方で救出できる | 普段使い用と非常用を分ける |
| 非常用（緊急）アカウントを作る | 緊急時のみ使う管理者を別管理 | 災害復旧の最後の砦を残す | ログ監視・アラートを必ず設定 |
| MFA手段を複数登録 | Authenticator + SMS + FIDO2 | 端末故障や通知不達でも回避 | 「追加しただけ」で放置せず、年1回テスト |
| 管理者の連絡先を最新化 | 回復用メール/電話を更新 | 本人確認・復旧連絡が滞らない | 退職・番号変更の棚卸しをルール化 |
| アカウント種別を明確化 | 個人用/組織用を用途で分離 | 設定画面の迷子・混同を防ぐ | 管理者は“組織用”に寄せる方が事故りにくい |
よくある質問
Microsoft 365では通知が来るのに、Azureポータルだけ来ないのはなぜ？
同じメールアドレスに見えても、背後で「個人用アカウント」と「職場または学校アカウント」が分かれていたり、Azure側が別のテナント（ディレクトリ）への再認証を要求したりすると、求められるMFAの種類や紐付け先が変わることがあります。結果として、Azureだけ通知が出ない・承認できない状態が起きます。
mysignins.microsoft.com に入れない。Authenticatorを削除して再登録する方法はない？
自己操作での再登録ができないパターンです。別のグローバル管理者に「認証方法のリセット」や「再登録を要求」をしてもらうのが最短です。管理者がいない場合はサポート手続きを検討してください。
「自分しか管理者がいない」と思っていたが、探す方法は？
サインイン可能な別アカウントがあるなら、Entra管理センターのロール割り当て（グローバル管理者）から一覧できます。過去の引き継ぎ資料、委託先、初期セットアップ時のメール、請求関連の連絡先も手掛かりになります。管理者アカウントは“作ったことを忘れがち”なので、思い込みを外して洗い出すのがコツです。
まとめ：復旧の近道は「別管理者でMFAリセット」、最悪時はサポート手続き
AzureポータルにサインインできないMFAトラブルは、端末の通知問題に見えて、実際は「テナント側のMFA設定とAuthenticatorの紐付け不整合」であることが少なくありません。自力で直せないと感じたら、別のグローバル管理者にMFAをリセットしてもらうのが最短ルートです。本当に他に管理者がいない場合は、サポート経由でロックアウト解除を進め、復旧後は管理者の冗長化と認証方法の複線化で再発を防ぎましょう。
コメント