Microsoft Authenticatorに確認番号が表示されないでサインインできない対処法｜Microsoft 365 MFA・テナントロックアウト復旧ガイド

Microsoft Authenticatorに確認番号（番号一致）が表示されず、Microsoft 365の職場／学校アカウントへサインインできないと、OutlookやOneDrive、SharePoint、Power BI、Power Automateまで止まり業務が完全に詰まります。特に自分が唯一のグローバル管理者の場合は「テナント ロックアウト」に発展しやすいため、原因の切り分けと復旧ルートを最短で確認しましょう。

まず結論：状況別の「最短ルート」

同じ「Authenticatorに確認番号が出ない」でも、取るべき手順は状況で変わります。下の表で、自分がどこに当てはまるかを最初に確認してください。

状況	最短の対処	ポイント
サインイン画面に「別の方法でサインイン」が出る（SMS/電話/コード等が選べる）	まず代替手段でサインイン → サインイン後に認証方法を追加・更新	自力復旧できる可能性が高い
Authenticatorにアカウントはあるが、通知もアプリ内の承認要求も一切出ない	通知・省電力・ネットワーク・アプリ更新を集中チェック（後述）	端末側要因が多い
Authenticatorから該当アカウントが消えている／機種変更・再インストール後	バックアップ復元（可能なら）→ だめなら管理者にMFAリセット依頼	登録情報が失われている可能性
組織に他のグローバル管理者がいる	管理者に「認証方法（MFA設定）のリセット」を依頼	最短で復旧しやすい
自分が唯一のグローバル管理者でサインイン不能	テナント ロックアウト（管理者ロックアウト）としてMicrosoftサポートへエスカレーション	多くの場合、本人確認のうえでData Protection（データ保護）担当へ回される

「Authenticatorに確認番号が出ない」ときに起きていること

Microsoft 365（職場／学校アカウント）の多要素認証（MFA）では、Authenticatorにプッシュ通知が届き、承認操作を行う方式がよく使われます。近年はセキュリティ強化の一環として「番号一致（Number Matching）」が有効な場合、サインイン画面に表示された番号をAuthenticator側で入力して承認する流れになります。

ところが、サインイン画面では「Authenticatorアプリで表示される番号を確認して承認してください」と出ているのに、Authenticator側で承認要求自体が出ないと、MFAを完了できずにロックアウト状態になります。原因は大きく分けて次の5系統です。

• 通知・バックグラウンド動作の阻害（通知OFF、省電力、集中モード、データセーバー、アプリのバックグラウンド制限）
• ネットワーク要因（VPN、プロキシ、社内Wi‑Fi制限、端末の通信不調）
• アプリ／OSの不整合（Authenticatorの古い版、OSの更新不足、端末時刻のズレ）
• アカウントの取り違え（同じ端末に個人Microsoftアカウントと職場アカウントが混在、別テナントのアカウントを見ている）
• 登録情報が失われた／無効化された（機種変更、アプリ再インストール、バックアップ未設定、認証方法がリセットされた）

ポイントは、「番号が出ない」= Microsoft側が必ず悪いとは限らないことです。端末の通知・電池・ネットワークで止まっているケースが非常に多く、そこを潰すだけで復旧することがあります。

今すぐ試す：Authenticator側で承認要求が出ないときのセルフチェック

まずは「短時間で効果が出やすい順」に確認します。サインイン画面は開いたままにし、Authenticatorアプリも開いた状態で試してください（通知が出なくても、アプリ内に承認要求が表示されることがあります）。

最優先チェック（5分でやる）

1. Authenticatorアプリを最新版に更新（ストアでアップデート）
2. スマホを再起動（通知キューが詰まっているだけのことがあります）
3. 通信を切り替える（Wi‑Fi→モバイルデータ、またはその逆。VPNは一旦OFF）
4. Authenticatorを開いて待つ（通知が来ないだけでアプリ内に表示される場合あり）
5. 「正しいアカウント」を見ているか確認（職場／学校アカウントが選択されているか）

よくある見落とし：別アカウントを見ている

Microsoft Authenticatorは、個人Microsoftアカウントと職場／学校アカウントを同じアプリで管理できます。複数アカウントを登録していると、承認要求は「正しいアカウントのほう」にだけ届きます。

• サインインしているメールアドレスと、Authenticatorに登録されているメールアドレスが一致しているか
• 同じメールに見えても、別テナント（別の会社・別のonmicrosoft.com）のアカウントを見ていないか
• Authenticator内でアカウントを切り替え、承認要求が別のアカウント側に出ていないか

iPhone（iOS）で詰まりやすいポイント

• 設定 → 通知 → Microsoft Authenticatorで「通知を許可」をON
• 集中モード（おやすみモード）で通知が抑制されていないか
• 設定 → 一般 → Appのバックグラウンド更新がON
• 設定 → 一般 → 日付と時刻で「自動設定」をON（コード方式を使う場合に重要）

Androidで詰まりやすいポイント

• 通知設定でAuthenticatorの通知を許可
• 電池の最適化（省電力/最適化）からAuthenticatorを除外、または「制限なし」へ
• データセーバーや「バックグラウンドデータ制限」で止めていないか
• メーカー独自の最適化（自動起動OFF等）が強い端末は、アプリの常駐許可も確認

チェック項目まとめ表（見落とし防止）

カテゴリ	確認ポイント	よくある落とし穴
通知	OS側で通知許可、ロック画面表示、サウンド	集中モード／通知のまとめ表示で気づけない
省電力	Authenticatorを最適化対象から外す	省電力がONだとプッシュが遅延・欠落
ネットワーク	VPN/プロキシOFF、Wi‑Fiとモバイルの切替	社内Wi‑Fiがプッシュ系通信を制限することがある
アカウント	職場／学校アカウントがAuthenticatorに登録されている	個人Microsoftアカウント側を見ていて「来ない」と勘違い
アプリ更新	AuthenticatorとOSを更新	古いアプリは番号一致の画面に対応できないことがある

サインイン画面で必ず確認：「別の方法でサインイン」が出るか

サインイン画面のどこかに「別の方法でサインイン」「別の方法を使用する」が出る場合、代替手段で突破できる可能性があります。ここで選べる代表例は次のとおりです（組織のポリシーで表示されないこともあります）。

• SMS（テキスト）
• 電話（音声通話）
• Authenticatorの6桁コード（ワンタイムパスコード）
• セキュリティキー（FIDO2）
• バックアップコード（運用している場合）

もし「6桁コード」が選べる、またはAuthenticatorにコードが表示されている場合は、プッシュ通知が死んでいるだけかもしれません。コードでサインインできたら、復旧後に次のどれかを必ず実施します。

• Authenticatorのプッシュ通知を復旧（通知・省電力設定の見直し）
• 認証方法に別系統（SMS/電話/別端末/セキュリティキー）を追加
• 「既定のサインイン方法」をプッシュ以外に切り替える（組織方針に従う）

サインイン済みの端末が残っているなら、そこから応急処置できることがある

完全に締め出されたと思っていても、次のような端末が残っている場合は「救命ボート」になります。

• 以前からサインインしたままのPCブラウザ（セッションが切れていない）
• OutlookモバイルやTeamsなど、まだ開けるアプリ
• 別端末に登録済みのAuthenticator（タブレット等）

どこか1つでもサインインできるなら、認証方法の追加や管理者の追加で一気に状況が改善することがあります。たとえば次のような動きです。

• 自分のアカウントに別の認証方法（電話/SMS/セキュリティキー）を追加する
• 緊急用の追加グローバル管理者（後述のブレークグラス）を作成・有効化する

ただし、すでに条件付きアクセスやセキュリティ既定値で「再認証」や「MFA必須」がかかっていると、サインイン済みでも途中で弾かれることがあります。その場合は次章のルート（管理者リセット／Microsoftサポート）へ進みます。

他に管理者がいる場合：Entra IDでMFA（認証方法）をリセットしてもらう

組織内に別のグローバル管理者（または認証方法を管理できる権限者）がいるなら、解決は比較的シンプルです。管理者に「Authenticatorが反応しないので、認証方法をリセットして再登録させてほしい」と伝えます。

管理者側で行う操作は環境で表記が多少違いますが、よくある流れは次のイメージです。

1. Microsoft Entra 管理センターにサインイン（旧Azure AD）
2. 対象ユーザーを開き、「認証方法」や「多要素認証」の管理画面へ
3. Authenticatorの登録を削除／再登録要求（必要に応じて別の方法を一時的に有効化）
4. ユーザーが再サインインしてAuthenticatorを再セットアップ

「どこを触ればいいか」が組織で分かれていることがあるため、管理者向けに整理すると次の通りです。

組織の設定パターン	確認・調整する場所の例	補足
条件付きアクセスでMFA必須	条件付きアクセスのポリシー	一時緩和は最小限に。復旧後は必ず戻す
セキュリティ既定値（Security Defaults）	セキュリティ既定値の設定	組織全体に影響するため慎重に
認証方法ポリシー（SMS/電話/アプリ等）	認証方法のポリシー	「別の方法でサインイン」が出ない原因になる
ユーザー単位のMFA（旧方式）	ユーザー単位のMFA設定（環境による）	古いテナントで残っていることがある

今回のケース：唯一の管理者がサインイン不能（テナント ロックアウト）

組織に管理者が自分しかおらず、そのアカウントがMFAで詰まると、社内でMFAリセットすらできません。一般にこの状態は「テナント ロックアウト（管理者ロックアウト）」と呼ばれ、Microsoft側で本人確認を行ったうえで対応する領域になります。

この種の案件は、窓口担当がその場で解除するというより、本人確認・契約照合を扱うData Protection（データ保護）系の担当チームへエスカレーションされることが多いです。つまり、こちらがやるべきことは「正しく状況を伝え、必要な情報を揃え、エスカレーションを確実に通す」ことになります。

サポートに伝えるべき要点（テンプレ）

電話やチャットでつながったら、最初に次をまとめて伝えます（読み上げ用）。

• 「Microsoft 365の職場アカウントで、Authenticatorの番号一致（確認番号）が表示されずMFAが完了できません」
• 「当組織はグローバル管理者が私1名のみで、現在誰も管理者としてサインインできません」
• 「管理センターからチケット作成ができないため、テナント ロックアウトとしてData Protection担当へエスカレーションして、MFAリセット（または管理者復旧）を希望します」
• 「テナントは xxxx.onmicrosoft.com（または独自ドメイン）です」

本人確認で求められやすい情報（事前準備チェックリスト）

ロックアウト案件は、なりすまし防止のため確認事項が多くなります。手元に揃えてから連絡すると、往復が減って復旧が早まります。

準備するもの	具体例	なぜ必要か
テナント情報	xxxx.onmicrosoft.com、独自ドメイン、組織名	対象テナントの特定
管理者アカウント情報	管理者メール、表示名、連絡先電話	本人性確認
課金・請求情報	請求先住所、請求担当者、直近の請求書/領収書情報	契約者照合に使われることが多い
支払い情報（可能な範囲）	支払い方法種別、カードの下4桁など	追加の照合材料
契約形態	Microsoft直契約／CSP（販売パートナー経由）	問い合わせ先・経路が変わる
独自ドメインの管理権限	DNSにTXTレコードを追加できる等	所有確認を求められることがある

サポートに到達する現実的な経路

サインインできないと、Webフォームや管理センターの「サポート」から進めないことがあります。その場合は次の順であたり、“エスカレーションしてもらう”前提で動きます。

• 販売パートナー（CSP/リセラー）経由で起票してもらう：購入元がパートナーなら最優先。パートナーはサポートチャネルを持っているため、テナントロックアウトのエスカレーションが通りやすいです。
• Microsoftのビジネスサポート（電話）：自動応答に「管理者ロックアウト」「サインインできない」「多要素認証」などのキーワードを入れ、オペレーターに接続されたら上のテンプレを読み上げます。
• 請求（Billing）窓口から入る：サインイン不能でも、契約・請求の相談は入口が別のことがあります。最終的に技術側へ回してもらう狙いです。

すでに電話が「無音で止まる」「AIから先に進まない」場合は、次の工夫も有効です。

• 別回線でかける（携帯→固定、VoIP→携帯など）
• 別の時間帯にかけ直す（混雑で転送が詰まっていることがあります）
• 日本語が難しければ英語窓口も試す（“tenant lockout” “global admin can’t sign in due to MFA” と伝える）
• 通話が切れないなら、無音でも数分は待ちつつ、反応がなければかけ直してケースを切り替える

なお、テナントロックアウトは本人確認が前提のため、外部の第三者が「裏技」で解除できる類のものではありません。正規サポートでの復旧が最短で安全です。

「解約して新規契約し直す」は基本おすすめできない

「いっそ解約して契約し直せば早いのでは？」と考えがちですが、Microsoft 365のデータ（メール、OneDrive、SharePoint、Power BI、Power Automateのフロー等）は“テナント”に紐づくため、サブスクリプションを新しく契約しても自動的に移行されません。

さらに、アクセスを失った状態だと、エクスポートや移行の準備（メールのエクスポート、SharePointのバックアップ、Power Automateのフロー移植など）もできません。結果として「新テナントは作れたが、旧テナントの重要データが取り出せない」という最悪のシナリオになりやすいです。

よほどの事情がない限り、優先順位は次の順が現実的です。

1. 既存テナントの管理者アクセスを復旧（まずここ）
2. 必要ならデータ保全・バックアップを実施
3. そのうえで、契約変更やテナント移行を検討

復旧後に必ずやる：再発防止（管理者アカウント運用のベストプラクティス）

今回のような事故を繰り返さないために、復旧できたら「その日のうちに」最低限の対策を入れてください。特にグローバル管理者が1人は、運用リスクが高すぎます。

最低限のルール

• グローバル管理者を2名以上にする（常用用と予備用）
• Authenticatorだけに依存せず、複数の認証方法を登録（電話/SMS/別端末/セキュリティキー）
• 機種変更・再インストール前に、バックアップの有効化と代替手段の動作確認をする
• 緊急用（ブレークグラス）アカウントを用意し、保管・監視ルールまで決める

ブレークグラス（緊急用管理者）の考え方

ブレークグラスとは「普段は使わないが、いざという時に必ず入れる管理者」のことです。ポイントは“強固に保管し、使う機会を最小化する”ことです。

• 強力で長いパスワード（ランダム）を設定し、パスワードマネージャや金庫に保管
• 日常業務では使用しない（サインイン履歴があれば即調査できる）
• 条件付きアクセスの例外にする場合は、例外化する理由・範囲・監視（アラート）をセットで運用
• 可能ならセキュリティキーなど、端末変更に強い認証も検討

再発防止チェックリスト（印刷して残す）

項目	OKの基準	備考
グローバル管理者が2名以上	予備を含めて複数名がサインイン可能	少人数組織でも必須
管理者の認証方法が複数	Authenticator＋電話/SMS/キー等	“同じ種類”を複数より“別種類”を混ぜる
Authenticatorバックアップ	復元手順を実際にテスト済み	テストなしのバックアップは信用しない
緊急連絡ルート	購入元パートナー／サポート窓口を記録	夜間・休日の動きも決める
手順書（ランブック）	「誰が」「何を」「どこに」連絡するか明文化	ロックアウト時は判断力が落ちる

よくある質問

Authenticatorに6桁コードは出るのに、番号一致の承認要求が来ません

端末側の通知・省電力・ネットワークでプッシュだけ止まっている可能性があります。まずは本記事の「セルフチェック」を実施し、当面は「別の方法でサインイン」から6桁コードが選べるならコードで復旧→サインイン後に認証方法を整理するのが最短です。

機種変更してAuthenticatorを入れ直しました。復旧できますか？

バックアップを有効にしていた場合は、復元で戻ることがあります。一方、バックアップなしで端末を替えた場合、Authenticator登録が失われ、管理者によるMFAリセットが必要になることがあります。管理者が自分だけの場合は、テナントロックアウトとしてサポート対応が必要です。

「サポートに問い合わせたいのにサインインが必要」で詰んでいます

まさにロックアウト案件の典型です。購入元がパートナーならパートナー経由で起票を依頼し、直契約なら電話・請求窓口から入り、最初に「唯一のグローバル管理者がMFAでサインインできない」と明確に伝えてエスカレーションを求めてください。

二度と同じことを起こさない最重要ポイントは？

「グローバル管理者を複数にする」ことと、「認証方法を複数種類で持つ」ことです。どちらか一方だけだと、端末故障や設定変更で簡単に詰みます。

まとめ

• Authenticatorに確認番号（番号一致）が出ない場合、まずは通知・省電力・ネットワーク・アプリ更新・アカウント取り違えを短時間で潰す
• 「別の方法でサインイン」が出るなら、代替手段で復旧してから認証方法を整備する
• 他の管理者がいるなら、管理者にMFA（認証方法）リセットを依頼するのが最短
• 唯一のグローバル管理者がロックアウトした場合は社内では解決できないため、テナントロックアウトとしてMicrosoftサポートへエスカレーションし、Data Protection担当の手続きに乗せる
• 復旧後は、管理者複数化・複数MFA・バックアップ・緊急手順書で再発を防ぐ