Microsoft 365 にサインインしようとしたとき、MFA（多要素認証）で 本人確認ができませんでした。もう一度お試しください や Sorry, we're having trouble verifying your account. Please try again. と表示され、Authenticator アプリも SMS も使えない状況になると、多くの人が「完全に詰んだ」と感じてしまいます。本記事では、このようなケースの具体例をもとに、ユーザー・管理者双方の視点から、実務で使える復旧手順と再発防止策を詳しく解説します。
Microsoft 365 で「MFA でログインできない」状況とは？
まず、今回のようなエラーが発生したときに何が起きているのかを整理します。対象は以下のようなケースです。
- Microsoft 365（旧 Office 365）のアカウントにサインインしようとした
- スマホの故障・紛失で Microsoft Authenticator（認証アプリ） が使えなくなった
- 代わりに SMS 認証コード を選択した
- 電話番号（下 4 桁のみ表示）の SMS を選ぶと、毎回
本人確認ができませんでした。もう一度お試しください（View details）
と表示され、先へ進めない - 他の選択肢もなく、アカウントに完全に入れない
つまり、「パスワードは合っているが、MFA ステップが通らないためサインインが完了しない」という状態です。特に、SMS/音声通話などのテレフォニー（電話経由）の認証がうまく働かず、かつ Authenticator も失っていると、ユーザー側には何も打つ手がないように見えます。
実際に起きた事例：バックエンド解除と電話番号レピュテーションのクリアで復旧
今回ベースになっている実例では、以下のような流れで問題が解決しました。
- ユーザーが Authenticator アプリを失い、代替として SMS 認証を選択
- SMS 認証を選ぶと毎回エラーになり、MFA が完了できない
- 管理者がサインインログやポリシーを確認するも、設定上は大きな問題が見当たらない
- Microsoft サポートへエスカレーション
- マイクロソフト側で
- 対象アカウントの バックエンド側ブロック解除
- 電話番号の 不正レピュテーション（悪性評価）のクリア
- その後、同じ電話番号宛の SMS による MFA が正常に通るようになった
ここでポイントとなるのが、電話番号の「レピュテーション（評判）」です。Microsoft やキャリア側では、IRSF（国際収益共有詐欺）などのテレフォニー詐欺対策として、疑わしい電話番号や経路からの SMS・音声通話をブロックする仕組みを持っています。この判定に誤って巻き込まれると、正しいユーザーでも SMS 認証が通らない、という状況が発生します。
そのため、設定をいくら見直しても解決しない場合、Microsoft サポート側での内部解除（バックエンド解除）や電話番号レピュテーションのクリアが必要になることがあります。
ユーザー側で最初にやるべきこと：情報を揃えて管理者へ
MFA のエラーが出たとき、ユーザー単独でできることには限りがあります。しかし、「正しい情報を揃えて管理者へ渡す」ことで、復旧までの時間を大きく短縮できます。
エラー画面の詳細情報を控える
エラー画面に 「詳細を表示（View details）」 のリンクがある場合、必ずそこを開き、次の情報をコピーします。
- Correlation ID
- Request ID
- Timestamp（UTC 時刻）
- サインインに使用したメールアドレス（UPN）
- 国／地域（例：Japan）
- 利用した回線種別（例：モバイル回線、会社の Wi-Fi など）
- 選択した認証方法（例：SMS / 音声通話 / Authenticator）
| 項目 | 例 | 確認場所 |
|---|---|---|
| UPN（サインイン ID） | [email protected] | サインイン画面 |
| エラーメッセージ | Sorry, we're having trouble verifying your account. Please try again. | ブラウザ画面 |
| Correlation ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | 「View details」内 |
| Request ID | yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy | 「View details」内 |
| Timestamp（UTC） | 2025-08-28 05:06:53 | 「View details」内 |
| 認証方法 | SMS（下 4 桁 0055） | 認証方法選択画面 |
管理者またはサポートへ、必要情報を添えて連絡する
Microsoft 365 のアカウントは、多くの場合 組織（会社・学校など）のテナント管理者によって運用されています。ユーザー自身でテナント設定を変えることはできません。したがって、
- 自分で闇雲に何度も試すのではなく
- 必要な情報を整理して、すぐに管理者へ連絡する
ことが重要です。後述の「連絡テンプレート」を使えば、情報漏れを防ぎつつスムーズに依頼できます。
復旧後すぐに複数の認証方法を登録する
一度アクセスが復旧したら、次に備えた「多経路化」が必須です。以下のような順番で、2〜3 経路以上の認証方法を登録しておきましょう。
- Microsoft Authenticator アプリ（推奨）
- プッシュ通知による承認
- アプリ内の 6 桁コード（ワンタイムパスコード）
- パスキー / FIDO2 セキュリティキー / Windows Hello
- 生体認証や PIN と組み合わせた、フィッシング耐性の高い認証
- 予備の電話番号（音声通話用）
- メインのスマホとは別回線
- 職場の固定電話など、SMS 以外の経路も一部検討
- Authenticator のクラウドバックアップ を有効化
- 機種変更や紛失時に、アプリの登録情報を復元しやすくなる
設定は、サインイン後に https://myaccount.microsoft.com →「セキュリティ情報」から変更できます。
管理者向け：実務で使える対処フロー
ここからは、テナント管理者（Microsoft Entra ID / Azure AD 管理者）向けに、実際の切り分け・対処手順を整理します。
事象の採取と一次切り分け
まずは、ユーザーから以下の情報を受け取ります。
- UPN（ユーザーのサインイン ID）
- 発生日時（UTC、ローカル時刻両方あると望ましい）
- エラーメッセージ本文
- Correlation ID / Request ID / Tenant ID
- 選択した認証方法（SMS / 音声 / Authenticator）
- 端末・OS・ブラウザ・ネットワーク（モバイル回線／企業内ネットワーク など）
その上で、Microsoft Entra 管理センター（旧 Azure AD 管理センター）からサインインログを確認します。
- Entra 管理センターに管理者アカウントでサインイン
- 「サインイン」ログを開く
- ユーザー名または Correlation ID / Request ID で該当ログを検索
- 該当イベントの「詳細」から
- MFA ステップの結果
- ブロック・リスク判定の有無
- 条件付きアクセス ポリシーの評価結果
併せて、ユーザー オブジェクトに対して 「サインインがブロックされています」 の設定が有効になっていないか確認します。
| 確認ポイント | チェック場所 | 補足 |
|---|---|---|
| ユーザーのサインイン許可 | ユーザー設定 > サインインの状態 | 「ブロック」になっていないか |
| MFA の結果 | サインインログ > 詳細 > その他の詳細 | MFA で拒否・ブロック・タイムアウトの有無 |
| 条件付きアクセス | サインインログ > 条件付きアクセス | 特定のポリシーにより拒否されていないか |
認証方法ポリシーと電話番号登録の確認
ユーザーが SMS を選択している場合、そもそも組織のポリシーで SMS が許可されているか、ユーザーの電話番号が正しく登録されているかを確認します。
- Microsoft Entra ID の 認証方法ポリシー
- SMS/音声通話が組織レベルで許可されているか
- 特定のグループ・条件付きで制限していないか
- ユーザー プロファイルの電話番号
- 電話番号が E.164 形式（例：+81 90 1234 5678） で登録されているか
- SMS 非対応の番号（固定電話など）ではないか
| 項目 | 正しい状態 | 誤設定の例 |
|---|---|---|
| 国番号 | +81 90 1234 5678 | 090-1234-5678（+81 なし） |
| 番号種別 | SMS 対応の携帯番号 | 会社の代表固定電話、内線番号 |
| ポリシー | SMS が対象ユーザーに許可 | SMS 無効、Authenticator のみ許可 |
暫定的な復旧手段：一時アクセス パス（TAP）の活用
設定やログの確認で大きな問題が見当たらない場合でも、ユーザーは「今、業務に入れない」状態です。そのため、恒久対策とは別に、暫定的な復旧手段を提供することが求められます。
代表的なのが、一時アクセス パス（Temporary Access Pass / TAP）です。
- 管理者がユーザーごとに発行できる、時限付き・使い切りのコード
- MFA が使えないユーザーに対して、一時的にサインインを許可する用途に最適
- TAP でサインインしてもらい、そのセッション中に
- Microsoft Authenticator の再登録
- パスキー / FIDO2 キーの登録
- 予備の電話番号の追加
併せて、以下の操作も有効です。
- 対象ユーザーに対する MFA 再登録の要求
- 既存の MFA セッションやリフレッシュトークンの 取り消し（Revoke）
ただし、MFA を完全に無効化したり、条件付きアクセスを大きく緩和する対応は、原則として避けるべきです。どうしても必要な場合は、 「対象ユーザー限定」「期間を区切る」「作業ログを残す」といった安全策を必ずセットで行ってください。
電話番号レピュテーション・IRSF 対策によるブロックの可能性
テレフォニー（SMS/音声通話）を利用した MFA は、IRSF（International Revenue Share Fraud：国際収益共有詐欺）などに悪用されるリスクが高く、Microsoft やキャリア側で厳しめの監視・ブロックが行われています。
その結果として、以下のような状況が起こり得ます。
- 短時間に大量の SMS 認証を試行した
- 通常とは異なる地域・経路からのアクセスが続いた
- キャリア側や中継事業者のレピュテーション判定により、特定番号が “怪しい” と評価された
このようなとき、サインインログ上は「SMS を送信しようとしているが、実際にはユーザーに届かない」あるいは「送信前にブロックされている」といった挙動として見えることがあります。
| 想定される原因 | 典型的な症状 | 対処の方向性 |
|---|---|---|
| IRSF 対策の誤検知 | 正しい操作でも SMS が届かない／エラー | Microsoft サポートで番号レピュテーションのクリアを依頼 |
| キャリア側の障害・ルーティング不具合 | 同じ時間帯に他サービスの SMS も届きにくい | キャリアの障害情報確認、時間を空けて再試行 |
| 過剰リトライによるロック・レート制限 | 短時間に何度もコード要求 → 失敗 | 一定時間待機、ポリシー／制限値を再確認 |
こうした要因が疑われる場合は、管理者の判断で Microsoft サポートへエスカレーションし、 「バックエンド側のブロック解除」「電話番号のレピュテーションリセット」が可能かどうかを確認する必要があります。
Microsoft サポートにエスカレーションするときのポイント
Microsoft サポートに問い合わせる際は、やり取りの回数を減らし、1 回目で必要情報を渡すのがコツです。そのまま使えるテンプレート例を以下に示します。
連絡テンプレート（ユーザー → 管理者 / 管理者 → Microsoft サポート）
件名：MFA 失敗（本人確認エラー）対応依頼／エスカレーション 影響ユーザー（UPN）：[email protected] 発生日時（UTC）：2025-08-28 05:06:53 画面メッセージ：Sorry, we're having trouble verifying your account. Please try again. Correlation ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Request ID：yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy テナント ID（わかれば）：zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz 認証方法の選択：SMS（下4桁 0055） 端末/ブラウザ/回線（例）：iPhone / Edge / NTTドコモ 希望対応： ・バックエンド側のブロック解除／電話番号レピュテーションのクリアの可否確認 ・暫定として 一時アクセス パス（TAP）発行 または MFA 再登録の許可
上記のように、「いつ」「だれが」「どんな画面で」「どの認証方法を使おうとして」「どんなメッセージが出たのか」をセットで伝えると、原因特定までがスムーズになります。
恒久的な対策：SMS 依存から Authenticator / パスキー中心へ
今回の事例では、マイクロソフト側での解除により復旧しましたが、根本的な教訓は 「MFA を SMS に頼りすぎない」という点です。テレフォニーは構造的にリスクやトラブル要因が多く、IRSF をはじめとした攻撃にも弱い経路です。
組織ポリシーとしてのベストプラクティス
- 第一選択を Authenticator / パスキーにする
- SMS/音声はあくまで予備・バックアップ手段に位置付ける
- ユーザーに 2〜3 経路以上の認証方法登録を義務化
- Authenticator + パスキー + 予備電話番号、といった組み合わせ
- 数値一致・アプリ内位置情報などの強化設定を有効化
- プッシュ爆撃攻撃への耐性が向上
- 機種変更時の手順をガイドとして整備
- Authenticator のバックアップ・復元方法
- 旧端末から新端末への移行チェックリスト
- 条件付きアクセスやリスクベース制御を定期レビュー
- 古い例外設定が残っていないか
- 新たな攻撃パターンに対応できているか
利用者向けの教育・周知のポイント
どれだけポリシーを整えても、利用者側が仕組みを理解していないと、トラブル時の混乱は避けられません。組織としては、以下のような観点で教育・周知コンテンツを用意しておくとよいでしょう。
- 「スマホを失ったときにやること」ガイド
- まず何を連絡すべきか（情報システム部門、上長など）
- Authenticator／パスキーの扱いと、再登録の流れ
- 「MFA エラー時の連絡テンプレ」
- Correlation ID 等をどこから取得するか
- 誰にどの情報を送ればよいか
- 「SMS を第一手段にしない」啓発
- 「SMS は便利だが、届かないこともある」「セキュリティ上の弱点もある」
- Authenticator やパスキーのメリットをわかりやすく説明
用語解説（簡易メモ）
- Microsoft Entra ID（旧 Azure AD）
- Microsoft 365 のユーザーや認証を管理する ID 基盤
- Microsoft Authenticator
- スマホでプッシュ承認や 6 桁コードを発行する認証アプリ
- IRSF（International Revenue Share Fraud）
- 国際電話や SMS 経路を悪用し、不当に通話料を発生させるテレフォニー詐欺
- 一時アクセス パス（Temporary Access Pass / TAP）
- 管理者が発行する有効期限付きのサインインコード。MFA が使えないユーザーの復旧に有用。
まとめ：ログインできない「今」と、再発させない「これから」
Microsoft 365 で MFA が通らず、本人確認ができませんでした。もう一度お試しください や Sorry, we're having trouble verifying your account. と表示されると、ユーザーからはどうにもできない「詰み」の状態に見えます。しかし、
- ユーザーが エラーの詳細情報を正確に管理者へ渡す
- 管理者が サインインログ・認証方法ポリシー・電話番号設定 を確認し
- 必要に応じて 一時アクセス パス（TAP）で暫定復旧 を行い
- 疑わしい場合は Microsoft サポートにバックエンド解除／レピュテーションリセットを依頼する
というフローを踏めば、多くのケースでアカウント復旧は可能です。
そして、復旧後にこそ重要なのが、Authenticator やパスキー中心の多経路化です。SMS/音声だけに頼らない構成にしておけば、端末紛失やキャリア障害、IRSF 対策の誤検知といったトラブルに巻き込まれても、「まったくログインできない」リスクを大きく下げられます。
「今、ログインできない」状況を解決するための実務的な手順と、「次に同じ問題を起こさない」ための設計・運用を、ぜひこの機会に見直してみてください。
コメント