Microsoft 365 や Azure ポータルにサインインするとき、SMS による多要素認証（MFA）が使えずエラー 399287 が表示されるケースが増えています。端末変更や機種変更直後に起こりやすく、放置すると業務が完全に止まってしまいます。本記事では、このエラーの正体と復旧手順、さらに再発させないための運用・設定のベストプラクティスを分かりやすく解説します。
M365 サインイン時に発生する MFA エラー 399287 とは
今回のケースでは、M365（Microsoft Entra ID）にサインインしようとすると、SMS による本人確認を選んだタイミングで次のエラーが表示されます。
Sorry, we’re having trouble verifying your account. Please try again.
エラーコード：399287
エラーの詳細には Request ID／Correlation ID／Timestamp もセットで表示されます。これは Microsoft Entra 側での認証処理に失敗したことを示す技術情報で、管理者やサポートに調査してもらう際に非常に重要です。
| 項目 | 内容 |
|---|---|
| 発生タイミング | サインイン時、MFA で SMS（または音声通話）を選択した直後 |
| 画面に出るメッセージ | Sorry, we’re having trouble verifying your account. Please try again. |
| エラーコード | 399287 |
| よくある状況 | 端末変更／Authenticator 未設定／SMS が唯一の MFA 手段、など |
エラー 399287 の正体：電話番号の「レピュテーション」とテレフォニー保護
Microsoft の公開情報や Q&A フォーラムでは、エラーコード 399287 は、主に SMS／音声通話などの電話系 MFA が Microsoft Entra ID 側の保護機構によってブロックされているときに発生するケースが多いと説明されています。
特に近年、Microsoft Entra ID はテレフォニー（SMS／音声）を悪用した攻撃から利用者を守るため、「Telephony Fraud Protections」と呼ばれる仕組みを強化しており、以下のような場合に SMS や音声の送信を自動的に制限します。
- 短時間に大量の SMS／音声認証要求が発生している
- 特定の電話番号やキャリア・国番号からのリクエストが不自然に多い
- IRSF（国際通話収益分配詐欺）の疑いがあるパターンに一致している
- 新規テナントや高リスク地域からのトラフィックが集中している
これらの検知に引っかかると、SMS が送信される前の時点でブロックされ、利用者側では「Sorry, we’re having trouble verifying your account.」という汎用的なエラーとして見えるようになっています。
また、Stack Overflow などの技術コミュニティでは、エラー 399287 が「PhoneReputation MFA Block」と関連付けられており、電話番号やテナントに対して「悪いレピュテーション（不正利用の疑いがある番号・経路）」が付与された状態であると解釈されるケースも紹介されています。
今回の結論：バックエンド側のブロック解除で SMS が復旧
質問のケースでは、最終的に Microsoft サポートを通じて以下の対応が行われたことで問題が解消しました。
- 対象の電話番号・テナントに対して付与されていたブロックの解除
- 電話番号の「悪いレピュテーション」のクリア（PhoneReputation のリセット）
これにより、再び SMS による MFA が正常に通るようになりました。
ただし、Microsoft 自身が「テキストメッセージや音声通話による MFA から、Microsoft Authenticator などのモダンな認証方法へ移行すること」を推奨していることもあり、今後の運用としては SMS／音声を「主な認証手段」に使うのではなく、「予備の手段」に降格させることが重要です。
まず利用者側で試すべき確認項目
管理者やサポートにエスカレーションする前に、利用者本人が確認できるポイントをまとめます。とはいえ、399287 はバックエンド側要因であることも多いため、ここで直らなければ速やかに管理者へ連絡してください。
| チェック項目 | 内容 | 目的 |
|---|---|---|
| プライベートウィンドウで再試行 | ブラウザのシークレット／InPrivate モードで Azure ポータルや Microsoft 365 ポータルにアクセスし、再度サインイン～SMS 認証を試す。 | キャッシュやクッキーに起因するセッション不整合を除外する。 |
| 別ブラウザ・別端末での試行 | PC／スマホなど複数の端末・ブラウザから同じアカウントでサインインし、挙動を比較する。 | クライアント固有の問題か、アカウント／バックエンド側の問題かを切り分ける。 |
| SMS 受信の基本確認 | 同じ電話番号で通常の SMS が受信できるか、圏外になっていないか、迷惑メッセージフィルターでブロックされていないかを確認。 | 回線側の単純な到達性問題を排除する。 |
| 複数回試さない | 短時間に何十回も SMS 認証を連打しない。 | 過度な再試行は逆にブロックやスロットリングを悪化させる可能性があるため。 |
ここまで試しても、依然として 399287 が継続する場合は、ほぼ確実に Microsoft 側のテレフォニー保護ロジックに引っかかっていると考えた方がよく、利用者だけでの解決は難しい状態です。
サインインに成功した後に必ず行う「セキュリティ情報」の再設定
何らかのきっかけ（ブロック解除、たまたま通った認証方法、管理者による一時コードなど）で一度サインインできたら、そのタイミングで必ず認証手段を再構成してください。最優先は Microsoft Authenticator と FIDO2／パスキーです。
セキュリティ情報画面への入り方
- サインイン後、ブラウザで
https://aka.ms/mysecurityinfoにアクセスする。 - 「セキュリティ情報」または「追加のセキュリティ情報」画面が表示されるので、ここで MFA 手段を追加・変更する。
推奨構成：Authenticator を既定、SMS は予備
| 役割 | 認証方法 | ポイント |
|---|---|---|
| 第1候補（既定） | Microsoft Authenticator（プッシュ通知＋番号一致 or ワンタイムコード） | 最もバランスの良いモダン MFA。オフライン時もアプリ内コードで認証可能。 |
| 第2候補 | FIDO2 セキュリティキー／パスキー（WebAuthn） | フィッシング耐性が高く、物理キーや OS アカウントに紐付いたパスキーでサインイン。 |
| 予備 | SMS／音声通話による認証 | IRSF や SIM 乗っ取りなどのリスクが高く、あくまで「最後の保険」として利用。 |
具体的な再設定手順（利用者）
- セキュリティ情報画面で「+ 方法を追加」から「Microsoft Authenticator」を選択。
- スマートフォンに Microsoft Authenticator アプリをインストールし、「職場または学校アカウントを追加」。
- 画面に表示された QR コードをスキャンし、プッシュ通知が届くことを確認。
- 同じ画面で「既定のサインイン方法」を「Microsoft Authenticator – 通知」または「Authenticator アプリのコード」に変更。
- 続けて「セキュリティキー」や「パスキー」を追加登録。手元の FIDO2 キーや、OS のパスキー登録ウィザードに従ってセットアップする。
- 最後に SMS／音声も「予備」として追加するが、既定にはしない。
- Authenticator アプリ側でクラウドバックアップ／アカウント移行を有効化しておく（機種変更時の再登録負荷を減らすため）。
管理者向け：ユーザーが完全にサインインできない場合の復旧オプション
利用者側の試行では回復せず、なおかつ Authenticator も登録されていない場合、テナント管理者の出番です。ここでは、Entra ID 管理センターを前提にした代表的な復旧パターンを整理します。
認証方法のリセットと「再登録の必須化」
まず試したいのは、対象ユーザーの MFA 設定を一度リセットし、次回サインイン時に新しい認証方法を登録させる方法です。
- Microsoft Entra 管理センターにグローバル管理者などの権限でサインイン。
- ユーザー > すべてのユーザー から対象ユーザーを選択。
- 認証方法（Authentication methods） を開き、登録済みの電話番号やアプリを削除。
- 必要に応じて「Require re-register MFA（MFA の再登録を必須にする）」を有効化。
この状態でサインインすると、ユーザーには再度 Authenticator や電話番号などの登録ウィザードが表示されるため、電話系を避けて Authenticator／FIDO2 を中心に構成させることができます。
Temporary Access Pass（TAP）の発行
ユーザーがすべての MFA 手段を失ってロックアウトしている場合には、「一時アクセス パス（Temporary Access Pass：TAP）」の利用が非常に有効です。TAP は時限付きの一時コードで、これを使って一度サインインさせ、その中で新しいパスワードレス認証方法（Authenticator／FIDO2／パスキーなど）を登録させることができます。
管理者側の大まかな流れは次の通りです。
- Entra 管理センターで 認証方法 > ポリシー を開き、「Temporary Access Pass」を有効化（対象ユーザー／グループを設定）。
- ユーザー > 対象ユーザー > 認証方法 を開き、「+ 認証方法の追加」から Temporary Access Pass を選択。
- 有効期間や桁数などを設定して TAP を発行し、表示されたコードを安全な経路でユーザーへ連絡。
- ユーザーは TAP を使ってサインインし、そのセッション中に Authenticator や FIDO2 キーを登録する。
電話レピュテーション／ブロックの解除を Microsoft サポートに依頼
サインインログでエラー 399287 が繰り返し記録され、SMS／音声の経路自体がブロックされていると推定される場合は、Microsoft サポートにエスカレーションして「電話番号レピュテーション」および「テナント単位のテレフォニー制限」の状態を確認・解除してもらう必要があります。
特に以下のような状況では、テナント単位・番号単位のブロックが疑われます。
- 同じ電話番号で複数ユーザーの SMS 認証が一斉に失敗し始めた
- ある国・地域の回線からのみ 399287 が発生する
- テナントを新規構成して数日以内に SMS 認証を大量に試した
サポートチケットを作成する際には、後述の「サポートに渡すべき情報」を整理して添付しておくと調査がスムーズです。
サインインログで見るべきポイント
Entra 管理センターの「サインインログ」を使うと、エラー 399287 がどの段階で発生しているか、どの認証手段で失敗しているかを確認できます。
- Entra ID > サインイン を開き、「ユーザー」「アプリ」「日付」でフィルター。
- 該当する失敗イベントを開き、「詳細」「MFA 詳細」や「認証の詳細」タブを確認。
- ステータスが「失敗」、エラーコードが
399287となっていること、認証手段が SMS／電話であることを確認。 - 同じ電話番号からの試行が短時間に集中していないかを時系列でチェック。
ここで Authenticator やパスキーでの認証は成功しているが、SMS のみ失敗しているようなパターンであれば、電話系のブロックに絞り込んで調査できます。
なぜ SMS／音声を「補助」に降格すべきなのか（IRSF と電話系 MFA のリスク）
Microsoft が SMS／音声通話を「補助的な認証手段」に位置付けている背景には、テレフォニー詐欺、特に IRSF（International Revenue Share Fraud）への対策があります。IRSF はプレミアムレート番号を悪用して通話や SMS を大量に発生させ、課金から不正に利益を得る攻撃で、MFA の SMS／音声もよく標的にされます。
このような攻撃を防ぐため、Microsoft Entra ID は SMS／音声認証に対して機械学習やヒューリスティックに基づく検知・スロットリングを実施しており、結果として「正しい利用者」であっても一時的にブロックされることがあります。
また、SMS／音声は IRSF 以外にも次のようなリスクを抱えています。
- SIM スワップ攻撃（携帯番号の乗っ取り）
- SMS の盗聴・転送設定の悪用
- ローミング時の SMS 遅延・不達
- 国・地域による配信制限（テレフォニーの地域オプトインが必要な国コードなど）
そのため、Microsoft は公式ドキュメントで「テキストメッセージや音声通話による MFA から、Microsoft Authenticator などのモダンな認証方法へ移行すること」を推奨しており、電話を使う場合も主に補助的な利用に留めるべきとしています。
認証方法ごとの比較
| 認証方法 | セキュリティ | 利便性 | おすすめ度 |
|---|---|---|---|
| Microsoft Authenticator（プッシュ） | 高：フィッシング耐性は中程度だが、番号一致などでなりすましを軽減。 | 非常に高い。スマホの通知をタップするだけ。 | ◎（既定の認証方法として推奨） |
| FIDO2 セキュリティキー／パスキー | 非常に高い：フィッシング耐性があり、秘密鍵は端末から出ない。 | 慣れが必要だが、一度セットアップすればワンタッチでサインイン可能。 | ◎（パスワードレス戦略の中核） |
| SMS／音声通話 | 中～低：IRSF や SIM スワップなどのリスクあり。 | 電話番号さえあれば使えるが、遅延・不達も多い。 | △（予備用に限定） |
| パスワードのみ | 低：単一要素であり、漏えいリスクが高い。 | 入力の手間があり、覚える負担も大きい。 | ✕（MFA なし運用は避けるべき） |
再発防止のための運用テンプレート（ユーザー／管理者共通）
ユーザー側のルール例
- 必ず複数の認証手段を登録（Authenticator ＋ FIDO2／パスキー ＋ SMS など）。
- 機種変更の前 に Authenticator のクラウドバックアップ／アカウント移行を必ず実施。
- 電話番号を変更する場合は、事前に社内の申請フローで報告し、管理者に TAP 発行や MFA 再登録の調整を依頼。
- 旅行や出張で海外ローミングを利用する際は、SMS が届かない前提で Authenticator／パスキーを優先利用。
管理者側のルール例
- 新規ユーザー作成時の標準セットアップとして、初回サインイン時に Authenticator とパスキーの登録を必須化。
- Temporary Access Pass を常に利用可能な状態にしておき、ロックアウト時の復旧を定型化。
- 電話番号変更時の社内申請フォームを整備し、「本人確認 → TAP 発行 → 新番号での MFA 再登録」を標準フローにする。
- テレフォニーの地域オプトインが必要な国コードについては、事前に対象ユーザー・グループを整理し、必要に応じて Microsoft サポートに依頼しておく。
- サインインログを定期的にモニタリングし、エラー 399287 の急増など異常値にアラートを設定。
サポート・管理者に渡すと役立つ情報まとめ
既に質問文で整理されている内容も含め、ヘルプデスクや Microsoft サポートに渡すと役立つ情報をテンプレート化しておきましょう。
| 項目 | 例 | 備考 |
|---|---|---|
| エラーコード | 399287 | MFA の電話系ブロックが疑われる。 |
| エラーメッセージ | Sorry, we’re having trouble verifying your account. Please try again. | スクリーンショットも添付しておくとよい。 |
| Request ID | 28ff5656-b048-49b8-ac2c-eb98a3b74c00 | 実際には画面に表示された値をそのままコピー。 |
| Correlation ID | cadb36f0-096f-42cf-b8be-b0ad76befe64 | 同上。 |
| 事象発生時刻（UTC） | 2025-08-23 00:26:35Z | タイムゾーン（JST など）も併記すると調査しやすい。 |
| 影響範囲 | 特定ユーザーのみ／テナント内の複数ユーザー／特定国・キャリアのユーザー など | IRSF 疑いか、設定ミスかの切り分け材料になる。 |
| 携帯キャリア／国番号 | 例：+81（日本）／+1（米国）など | テレフォニーの地域オプトインが必要な国コードかどうかを判断する材料。 |
| SMS の他サービスでの受信可否 | 他社サービスの SMS は届くが、Microsoft からの SMS だけ届かない、など | キャリア側のブロックか Microsoft 側のブロックかを切り分ける。 |
すぐ使えるチェックリスト
最後に、本記事のポイントをチェックリスト形式でまとめます。社内 Wiki や運用手順書にそのまま貼り付けて使えるよう、粒度を揃えています。
- [ ] Microsoft Authenticator を登録し、「既定のサインイン方法」に設定した
- [ ] FIDO2 セキュリティキーまたはパスキーを少なくとも 1 つ追加登録した
- [ ] SMS／音声通話による MFA を「予備の認証手段」として登録し、既定から外した
- [ ] Authenticator アプリのクラウドバックアップ／アカウント移行を有効化した（機種変更対策）
- [ ] テナント管理者が、必要なユーザーに対して Temporary Access Pass（TAP）を利用できる状態にした
- [ ] エラー 399287 が発生した場合に、サインインログとエラー詳細（Request ID／Correlation ID／Timestamp）を必ず控える運用にした
- [ ] 電話番号変更時の社内フロー（本人確認 → TAP 発行 → 新番号での MFA 再登録）を社内 Wiki に明文化した
- [ ] 新入社員・新アカウント向けの標準セットアップ手順に、Authenticator／パスキーの登録を必須項目として追加した
エラー 399287 自体は一見すると「ただの SMS 不達」に見えますが、裏では Microsoft のテレフォニー保護機構によるブロックやレピュテーション判定が動いていることが多く、ユーザーだけでの復旧は困難です。だからこそ、「Authenticator＋パスキーを主役、SMS／音声は補欠」という設計に切り替えておくことが、もっとも現実的な再発防止策になります。
コメント