Microsoft 365 のグローバル管理者で、Microsoft Authenticator に数値コード(または承認通知)が出ずサインインできない――この状況は希に発生し、放置すると全サービスの運用が止まります。本記事では、いま動ける最短手順から恒久対策まで、実務で使える復旧フロー・チェックリスト・失敗しない再登録のコツを網羅的に整理します。社内展開向けテンプレや検証ポイントも付けています。
想定する症状と前提
以下に該当する場合を対象とします。
- 新しいデバイスやブラウザーでサインインを試みると「コードを入力して承認してください」と表示される(=ナンバーマッチング)が、Authenticator アプリ側に番号入力画面や承認通知が出ない。
- 他の Microsoft 365 サービスにもサインインできない。
- アカウントは組織発行(Entra ID / 旧 Azure AD)で、質問者自身がグローバル管理者。
- 予備のメールアドレスと電話にはアクセスできる。
最短で復旧するための優先順位
| 優先 | 状況 | やること | 期待結果 |
|---|---|---|---|
| 高 | 認証方法を複数登録済み | サインイン画面で「別の方法でサインイン」「SMS/電話」を選ぶ | 一時的にログイン成功 → Authenticator を再登録 |
| 中 | 他の管理者がいる | その管理者に「MFA の再登録必須」を実行してもらう | 再サインイン時に QR コードで初期化・再登録 |
| 中 | 管理者を追加できる | 一時ユーザーを作成 → グローバル管理者へ昇格 → 自分の MFA をリセット | 自アカウントを復旧後、臨時アカウントは無効化/削除 |
| 低 | 管理者が自分だけで完全ロックアウト | Microsoft サポート(プライバシー チーム)へ電話、または新テナントからサポート依頼 | 本人確認後に復旧ルートを案内 |
手順1:代替認証方法(SMS/電話/電子メール)で一時的にログイン
まずは「門を開ける」ことを最優先にします。サインイン画面で 「別の方法でサインイン」 が表示される場合、以下の順に試してください。
- SMS でコードを受け取る:本人の登録番号宛に6桁コードが届きます。入力後サインイン。
- 電話で確認:自動音声の案内に従って操作します。
- 予備メール(職場外メール):受信可能であればコードで認証。
ログイン後は、必ず Authenticator の再登録に進みます(後述)。この段階で終わらせると再発します。
手順2:予備のグローバル管理者を作成して自分の MFA をリセット
代替方法が選べない/通知がどうしても来ない場合は、別経路で管理センターに入る必要があります。以下は 自分以外のルートで管理者権限を確保 し、該当アカウントの MFA を初期化する手順です。
- サインインできる 別のユーザー を一時的に作成し、ライセンスは不要のままでも構いません(管理操作専用)。
- そのユーザーを グローバル管理者 に昇格させます。
- プライベート/シークレットウィンドウで office.com に昇格ユーザーとしてサインイン。
- Microsoft Entra 管理センター → ユーザー →(対象ユーザー=元の自分)→ 認証方法 を開きます。
- 「多要素認証の再登録を必須にする」 を実行。必要に応じて、登録済みの 「Microsoft Authenticator」 や古い電話番号/メールの項目を削除します。
この操作により、元のアカウントは次回サインイン時に 初期セットアップ(QR コード読み取り) からやり直せます。
手順3:他の既存管理者に MFA リセットを依頼
既に他の管理者が在籍している場合、上記「認証方法 → 再登録を必須にする」の実行を依頼するのが最短です。操作後、あなたは自分の端末で再サインインし、QR コードから Authenticator を再登録します。
手順4:唯一の管理者で完全ロックアウト時の復旧ルート
管理者が自分一人で、且つ何も入れない場合は、Microsoft サポート(プライバシー チーム) に電話でロックアウト解除の相談を行います。電話がつながりにくい場合は、新規テナントを試用版で作成 し、そのテナントとしてサポートチケットを起票し「該当組織の唯一の管理者がロックアウトした」旨を詳細に記載してください。本人確認では、請求先情報・ドメイン所有証明・組織情報の確認が発生します。準備しておくと審査がスムーズです。
Authenticator を再登録する安全な流れ
- スマートフォンの 日付と時刻を自動設定 にする(数分のズレで通知やナンバーマッチングが失敗することがあります)。
- スマートフォンの 通知を許可(アプリの通知、バックグラウンド通信、省電力の例外設定)。
- PC でサインインを進め、画面に表示される QR コード を Microsoft Authenticator で読み取り。
- アカウント名に 会社名(テナント名) が表示され、「番号を入力」 が求められることを確認。
- 念のため スマホのクラウドバックアップ を有効化(iOS は iCloud、Android はクラウドバックアップ)。
- 電話/SMS/メール も併せて登録・検証しておく(多系統化)。
よくある原因と一次切り分け
| 症状 | 主な原因 | 対処 |
|---|---|---|
| Authenticator に通知が出ない | 通知オフ、バックグラウンド制限、時刻ズレ、機内モード、企業プロファイル制限 | 通知許可・電池最適化の除外・時刻自動設定・機内モード解除・会社ポータルの制御確認 |
| 「コードを入力」だが番号入力画面が出ない | 旧アカウントの残骸、同名アカウントの重複、アプリのキャッシュ不整合 | Authenticator から古いエントリを削除 → 再登録。改善なければアプリ再インストール |
| SMS も受け取れない | 番号変更・海外ローミング・SMS 受信制限 | キャリア設定の見直し、Wi‑Fi Calling や別 SIM の利用、固定電話への音声認証に切替 |
| サインインは通るが再登録に失敗 | 条件付きアクセスで「準拠デバイスのみ」等の制約が先に適用 | 一時的に除外グループへ追加または CA を一時緩和し、登録後に元へ戻す |
条件付きアクセス(CA)/ セキュリティ既定値の注意点
「MFA 登録を必須」にする CA が強すぎると、新規端末や初期化直後に 登録画面へ到達できないループ が発生します。復旧作業時は以下を意識します。
- 緊急用(ブレークグラス)アカウント を CA の対象外にしておく(IP 制限・超長パスワード・無人保管)。
- 対象ユーザーを 一時的に CA 除外グループ へ入れて再登録 → 復旧後に必ず戻す。
- 「セキュリティ既定値」を使う場合は、管理者の登録完了 を確認してから有効化する。
Temporary Access Pass(TAP:一時アクセスパス)の活用
別管理者がいる環境では、TAP を発行してサインイン → Authenticator を再登録するのが安全で確実です。TAP は時限性・一度きり利用などの設定が可能で、紛失時の再登録に強力です。運用としては、管理者2名以上に TAP 発行権限 を持たせ、ブレークグラスと併用すると堅牢になります。
TAP を用いた復旧の概略
- 管理者Aが Entra 管理センターで TAP を有効化(組織ポリシー)。
- 管理者Aが対象ユーザー(あなた)に対して TAP を発行(有効期間・ワンタイム/マルチ使用を指定)。
- あなたは TAP でサインイン → セキュリティ情報で Authenticator を登録 → TAP を無効化。
再発防止のベストプラクティス
- グローバル管理者は常時2名以上(うち1名はブレークグラス)。
- 管理者アカウントには Authenticator + 電話/SMS + 予備メール の複数要素を常に登録。
- Authenticator のバックアップ を有効化し、復元テスト を四半期ごとに実施。
- 条件付きアクセスに 安全な除外グループ を用意し、期限付きでの運用ルールを文書化。
- サインインログと監査ログ を定期レビューして検知を強化。
- 端末の 通知/時刻/省電力設定 を標準化(MDM/Intune での構成推奨)。
復旧後の確認チェックリスト(コピーして使えます)
- 自アカウントでサインイン → ナンバーマッチングが表示される。
- Authenticator のバックアップが有効、復元先テスト端末で承認が通る。
- 電話/SMS/予備メールの動作確認(コード受信可)。
- CA 除外や緩和を 元に戻した(証跡を残す)。
- ブレークグラスのパスワード更新、保管場所の再封印。
- 監査ログに不審操作がないことを確認。
トラブル別の詳解
スマホ側で通知が届かない/番号入力画面が開かない
- アプリの通知を「許可」。ロック画面表示・バナー・サウンドも有効に。
- 省電力・最適化から Authenticator を除外。バックグラウンド制限を解除。
- VPN/ファイアウォール/企業プロファイル(Work Profile)が通知を遮っていないか確認。
- アプリ内のアカウント一覧に同じテナント名が重複していれば古い方を削除。
- 最後の手段としてアプリ再インストール。ただし 再登録の準備(QR コード発行)を先に済ませること。
SMS/電話も詰まった場合の迂回
- 固定電話の音声認証へ切替。
- 海外出張や電波状況が悪い場合は Wi‑Fi 経由で通話できる回線や別 SIM を利用。
- 他の管理者に TAP を発行してもらい、速やかに再登録する。
運用に効く「社内アナウンス」テンプレ
件名:Microsoft 365 管理者向け MFA 再登録ルール
本文:
- Authenticator に通知/コードが表示されない場合は、まず「別の方法でサインイン」→ SMS/電話を使用。
- それでも入れない場合は管理担当に連絡し、対象アカウントの「MFA 再登録必須」実行を依頼。
- 復旧後は Authenticator + 電話/SMS + 予備メールを登録、バックアップを有効化。
- 条件付きアクセスの一時除外は最短・最小範囲で。作業後は必ず原状復帰。
よくある質問(FAQ)
Q. ナンバーマッチングとは?
A. サインイン画面に表示される数字を、Authenticator 側で入力して承認する方式です。プッシュだけより安全で、不正承認のリスクを減らします。数字が出ない場合はアプリ側の設定や登録状態を見直します。
Q. 端末を紛失した場合は?
A. 直ちに別管理者に連絡し、該当端末由来の認証方法を削除のうえ、MFA の再登録を必須化。TAP または SMS/電話でサインインし、新端末へ登録し直し ます。条件付きアクセスのデバイス準拠も更新します。
Q. 電話番号を変えたら入れなくなった
A. 旧番号が無効なら、他の手段(Authenticator/予備メール/TAP)でサインインし、セキュリティ情報 から新番号を登録、旧番号を削除します。番号変更前に複数要素を入れておくことが重要です。
Q. 管理者が複数いるが、全員入れない
A. CA/ネットワーク制限やレジリエンス不足が疑われます。ブレークグラスでのログイン可否、既定ポリシーの影響、ID プロバイダー障害の切り分けを行い、1 アカウントを救出して横展開します。
監査・証跡の残し方
- 誰がいつ「MFA の再登録必須」を実行したかを記録。
- どの認証方法を削除/追加したか(電話番号の下4桁のみ記録)。
- CA の一時緩和/除外の範囲・期間・承認者。
- 復旧後のログイン試験と結果(端末/ブラウザー/場所)。
PowerShell/Graph を使った高度な運用(参考)
自動化や一括復旧を行いたい場合の例です。実行前に検証環境でテストしてください。
例:ユーザーの認証方法を確認・整理
# Microsoft Graph PowerShell の例(要適切な権限付与)
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
# 対象ユーザーの認証方法一覧
Get-MgUserAuthenticationMethod -UserId [user@contoso.com](mailto:user@contoso.com)
# 古い電話/SMS/Authenticator メソッドの削除(ID は上記で確認)
Remove-MgUserAuthenticationPhoneMethod -UserId [user@contoso.com](mailto:user@contoso.com) -PhoneAuthenticationMethodId <ID>
Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId [user@contoso.com](mailto:user@contoso.com) -MicrosoftAuthenticatorAuthenticationMethodId <ID>
# 再登録フラグ(Require re-register MFA 相当の運用)
# ※ポータル操作の方が安全。スクリプトは検証後に限定利用。
例:Temporary Access Pass(TAP)を発行
# TAP を有効化(組織設定)。Beta API を使う場合は十分に検証を。
# New-MgPolicyAuthenticationMethodsPolicy / Update-MgPolicyAuthenticationMethodsPolicy など
# ユーザーに TAP を発行(利用数・有効期間・長さなどを指定)
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId [user@contoso.com](mailto:user@contoso.com) ` -StartDateTime (Get-Date).ToUniversalTime()`
-LifetimeInMinutes 60 `
-IsUsableOnce $true
社内標準手順(SOP)サンプル
- 一次対応者は、当該管理者に SMS/電話/予備メール の案内を実施。
- 入れない場合は 管理者B が「再登録必須」を実行し、古いメソッドを整理。
- 対象者が再登録・バックアップ完了後、CA 除外を原状復帰。
- 対応記録・監査ログ・リスク評価を残し、再発防止策(ブレークグラス/TAP/多要素の複線化)を確認。
スマホ設定の見直しポイント(iOS/Android 共通)
| 項目 | 推奨設定 | 備考 |
|---|---|---|
| 日付と時刻 | 自動設定(ネットワーク時刻) | 数分のズレでも失敗要因に |
| 通知 | 許可(ロック画面/バナー/サウンド) | サイレントだと見落としやすい |
| 省電力/最適化 | Authenticator を除外 | バックグラウンド遮断を回避 |
| モバイル通信/機内モード | 機内モードはオフ、通信を許可 | SMS/音声認証が不可になる |
| MDM/Work Profile | 通知の許可・制限の確認 | 企業プロファイルのポリシー影響 |
ケーススタディ:復旧の実際
ケースA:新端末でのみ承認が出ない
旧端末に承認が飛んでいる可能性。旧端末の Authenticator を開き、承認要求が来ていないか確認。移行前に バックアップ→復元 を行うとスムーズです。移行後は旧端末の登録を削除。
ケースB:PC は入れるがスマホが詰まる
PC でログインできるなら、そのまま管理センターから自分の認証方法を整理し、QR コードで再登録。スマホ側は通知・省電力・時刻を見直し、アプリを最新に更新します。
ケースC:CA が強く登録画面にたどり着けない
一時的に 対象ユーザーを CA 除外 にしてセットアップ完了後に戻します。範囲と時間は最小化し、監査に記録します。
「これだけやれば詰まらない」再登録の要点
- PC とスマホを並べ、プライベートウィンドウ で作業する。
- 二段階目のコードは Authenticator → 番号入力 で応答する。
- 登録後に テストサインイン を2種(PC/モバイル)で実施。
- バックアップの有効化 と他要素(SMS/電話/メール)の動作確認。
- 古いメソッドや旧端末のエントリは 必ず削除。
トラブルシューティング早見表
| エラー/現象 | 一次対応 | 二次対応 |
|---|---|---|
| 承認が届かない | SMS/電話で代替、通知設定確認 | 再登録必須→QR 再設定 |
| 番号入力が出ない | 古いアカウントを削除、アプリ再起動 | アプリ再インストール(要事前にQR用意) |
| 認証ループ | CA 除外/緩和で登録 | 登録後に原状復帰、ログ確認 |
| 唯一管理者が入れない | サポートに電話/新テナントから起票 | 本人確認後の復旧手順に従う |
まとめ:安全に初期化し、二重化で守る
Authenticator にコードが出ずログインできないときは、(1)別手段で入る →(2)MFA を再登録必須にする →(3)QR で再登録 →(4)多系統化とバックアップ の順で対処すれば復旧できます。唯一管理者で詰まったときはサポート経由が最後の砦です。復旧後は、管理者の多重化・TAP とブレークグラスの整備・CA の安全な運用 を徹底し、再発を防ぎましょう。
付録:作業記録テンプレ
【事象】Authenticator にコード/通知が出ずサインイン不可
【対象アカウント】<UPN>(グローバル管理者)
【一次対応】SMS/電話/予備メールの試行(結果)
【管理センター操作】MFA 再登録必須、古い方法削除、CA 除外(範囲/時間)
【再登録】QR 実施(日時/端末)、バックアップ有効化
【検証】PC/モバイルでテストサインイン成功
【原状復帰】CA 除外解除、臨時アカウント無効化/削除
【監査】ログ確認(異常なし/あり)
【所感/改善】TAP 有効化、管理者二重化、通知標準化
付録:社内ナレッジに載せる要点(短縮版)
- 別方法でサインイン(SMS/電話)→ 入れたら即再登録。
- 入れないときは管理者に「再登録必須」を依頼。
- 唯一の管理者ならサポートへ。新テナントからの起票も可。
- 復旧後:Authenticator + 電話/SMS + メール、バックアップ、TAP/ブレークグラス、CA 原状復帰。
運用ポリシー例(抜粋)
- 管理者は四半期ごとに 復元訓練(テスト端末での承認・復元)を実施。
- ブレークグラスの 資格情報は封印保管、年2回ローテーション。
- CA の変更は 変更申請&二名承認、除外は最長24時間。
- サインイン失敗のアラート閾値と通知先(運用チーム)を定義。
この記事の使い方
本記事は、現場の運用担当が「その場で確認→そのまま実行」できるよう、手順と判断材料を横断的にまとめています。印刷版を作ってインシデント対応キットに同梱し、障害時の初動を標準化すると効果的です。

コメント