Azure ポータルや Microsoft 365 に突然サインインできなくなり、「Sorry, we’re having trouble verifying your account.」とだけ表示されるとかなり焦ります。とくにエラーコード 399287 は、パスワードが合っていても SMS による多要素認証が進まず、管理者でも手詰まりになりがちな厄介なパターンです。本記事では、実際に解消されたケースをベースに、原因の整理から復旧手順、再発防止までを“情シス視点”で詳しく解説します。
Azure サインインでエラー 399287 が発生する症状
まずは、エラー 399287 が出るときの典型的な症状を整理します。
- Azure ポータル（
https://portal.azure.com）や Entra 管理センターにアクセス - ユーザー名・パスワードの入力は成功する
- 本人確認のために SMS または電話認証が求められる
- 「コードを送信」や「テキストメッセージを送信」を押すと、画面に次のメッセージが表示される
- Sorry, we’re having trouble verifying your account. Please try again.
- [詳細] を開くと Error code: 399287 とともに
Request IDCorrelation IDTimestamp (UTC)
- ブラウザーを変えても、シークレットウィンドウでも、別回線（モバイルテザリング等）でも同じユーザーだけが失敗する
よくある状況を表にまとめると次のようになります。
| 項目 | 内容 |
|---|---|
| 対象サービス | Azure ポータル / Entra 管理センター / Microsoft 365 管理センター など Entra ID 認証を使うサービス全般 |
| サインイン状態 | パスワード認証までは成功するが、多要素認証 (MFA) の SMS / 電話ステップで失敗 |
| 画面メッセージ | Sorry, we’re having trouble verifying your account. Please try again. と表示 |
| エラーコード | 399287 が表示される |
| ログ | サインインログに失敗イベントが記録され、Request ID / Correlation ID / Timestamp (UTC) が残る |
| 影響範囲 | 該当ユーザーの SMS / 電話による MFA のみが失敗し、他ユーザーは問題ないケースが多い |
この時点でブラウザーやネットワークを疑いがちですが、エラー 399287 の場合、ユーザーやテナント設定ではなく Microsoft 側の制御が原因であることが多い点がポイントです。
エラー 399287 の正体：SMS / 電話による MFA 方法がブロックされている
Microsoft の Q&A やフォーラムでは、エラー 399287 について「多要素認証メソッドがブロックされている状態」であると説明されています。
とくに多いのが、次のようなパターンです。
- SMS / 音声通話による MFA の電話番号が「悪評（Bad Reputation）」と判定された
- Microsoft の PhoneReputation 系の仕組みにより、その番号宛の SMS / 通話が制限されている
- 特定の国・地域向けの SMS 経路に制限がかかっている
- IRSF（International Revenue Share Fraud：国際収益分配詐欺）などの電気通信詐欺への対策として、疑わしいパターンが自動ブロックされている
この制御はMicrosoft のバックエンド側で行われるもので、テナント管理者がポータルから解除することはできません。パスワードを変えてもブラウザーを変えても解消せず、同じ電話番号を使っている限り、SMS / 電話による認証は失敗し続けます。
実際に、Microsoft Q&A のスレッドでは、サポートに問い合わせた結果「電話番号の reputation をクリアし、MFA メソッドのブロックを解除した」と説明されており、その後は問題なく Azure にサインインできるようになった事例が複数報告されています。
ユーザー視点から見た「原因の本質」
利用者側から見ると、次のように整理すると理解しやすくなります。
- パスワードも電話番号も合っている
- しかし「その電話番号宛ての MFA SMS/通話」自体が、Microsoft 側で危険と判断されて止められている
- 結果として「本人確認ができない」という表示になり、エラー 399287 が出る
つまり、ユーザーの操作ミスやテナント設定ミスではなく、「電話番号や経路がブロックされている」ことが本質的な原因であるケースが非常に多い、ということです。
まずユーザーがやるべきこと
エラー 399287 に遭遇したユーザーが、慌てて何度もボタンを押してしまうと、かえって状況が悪化する可能性があります。最低限、次のポイントを押さえておきましょう。
画面の情報を必ず控える
エラー画面の [詳細情報] には、Microsoft サポートにとって非常に重要な情報が表示されています。
| 項目 | 例 |
|---|---|
| Error code | 399287 |
| Request ID | 9cef285d-xxxx-xxxx-xxxx-f93852630600 |
| Correlation ID | 5e8043b9-xxxx-xxxx-xxxx-78080b0f12dd |
| Timestamp (UTC) | 2025-08-18T14:33:36Z のような UTC 時刻 |
スクリーンショットを保存するか、これらの値をテキストで残しておき、管理者やサポート窓口に渡せるようにしておきましょう。
何度も連続で再試行しない
短時間に何度も SMS 送信や再試行を繰り返すと、自動判定でブロックの閾値を超え、状況がさらに悪化する可能性があります。エラー 399287 が確認できたら、いったん試行を止めて、管理者やサポートに相談する方が安全です。
他の認証手段があれば試す
すでに Microsoft Authenticator アプリや FIDO2 セキュリティキーを登録している場合は、SMS/電話ではなくそれらを使ってサインインできるケースもあります。
- 別のブラウザーやシークレットウィンドウからサインインを開始
- 「別の方法を使う」「アプリで承認」などのリンクがあれば選択
- Authenticator アプリのプッシュ通知や番号入力、セキュリティキーでのサインインを試す
ただし本記事のテーマである「電話番号がブロックされている」場合、サインイン フロー自体が SMS に固定されていて他の方法が選べないことも多いため、その場合は無理に何度も試さず管理者にエスカレーションしてください。
管理者向け：実務的な原因切り分けと復旧フロー
1. 影響範囲とログの確認
まずは、テナント管理者として次の点を確認します。
- 問題が発生しているのは特定ユーザーか、複数ユーザーか
- すべてのサインインが失敗しているのか、SMS/電話を伴うサインインのみ失敗しているのか
- Microsoft Entra 管理センターの「サインイン」ログで、該当時刻のログを確認
- 結果が「失敗」になっているイベント
- 認証方法に「電話」「SMS」が含まれるか
- 詳細に
PhoneReputationやそれに類する情報が記録されていないか
この時点で、「特定ユーザーの SMS / 電話のみが失敗」「他のユーザーや他の認証方法では成功」という傾向が見られる場合、Microsoft 側の電話番号ブロックを強く疑ってよい状況です。
2. Microsoft サポートへの問い合わせ
エラー 399287 の解除は、基本的に Microsoft サポートに依頼する必要があります。管理者は Azure ポータルや Microsoft 365 管理センターからサポート リクエストを起票し、次の情報を添付します。
| 項目 | 内容例 |
|---|---|
| 影響ユーザー | UPN（例：[email protected]） |
| 影響電話番号 | +81xxxxxxxxxx のように E.164 形式で完全表記／国名も明記 |
| エラーコード | 399287 |
| Request ID / Correlation ID | ユーザーから収集した値をそのまま記載 |
| Timestamp (UTC) | エラー画面の UTC 時刻をそのまま記載（複数ある場合は複数記載） |
| 発生経路 | 例：Azure ポータル (portal.azure.com) にサインインした際、SMS による MFA で失敗 |
| 実施済み対処 | ブラウザー変更、パスワード再設定、別ネットワーク利用など、すでに実施した切り分け内容 |
| 依頼内容 | 電話番号に対するブロック解除 / reputation のクリア、および関連するバックエンド制御の解除を依頼 |
問い合わせ時のポイントは、単に「サインインできない」と伝えるのではなく、エラーコード 399287 で SMS / 電話の MFA がブロックされている疑いがあることを明示することです。これにより、サポート側も最初から適切なチームにエスカレーションしやすくなります。
3. ブロック解除後の動作確認
サポートによるバックエンドのブロック解除と電話番号の reputation クリアが完了すると、ユーザー側では次のような流れで復旧を確認できます。
- ユーザーに再度 Azure ポータルへアクセスしてもらう
- パスワード入力後、再び SMS によるコード送信を実施
- 今度は SMS が届き、コードを入力するとサインインが成功する
このタイミングで、すぐに認証方法の見直し（Authenticator アプリの既定化など）を案内するのが重要です。後回しにしていると、再び同じ電話番号がブロックされ、エラー 399287 が再発するリスクがあります。
一時的にアクセスを確保する方法：Temporary Access Pass (TAP)
ビジネスが止まるレベルで影響が大きい場合、Microsoft Entra ID の Temporary Access Pass (TAP) を活用すると、「とりあえずサインインできる状態」を用意することができます。
TAP の基本的なイメージは次の通りです。
- 管理者が一時的なパスコード（TAP）を発行
- ユーザーは TAP を使ってサインイン
- サインイン後、ユーザーが自身で Authenticator アプリや FIDO2 キーなどの認証方法を再登録
- TAP は短時間で失効させる（使い捨て）
これにより、SMS がブロックされている状態でも、安全にサインインさせたうえで認証手段を切り替えられるようになります。ただし TAP 自体も強力な手段のため、発行時には有効期限や使用回数を最小限にし、利用後は必ず無効化する運用ルールを明確にしておきましょう。
再発防止の鍵：認証方法の設計を見直す
なぜ SMS 認証を“主方式”にすべきでないのか
今回のように、電話番号や SMS 経路がブロックされると、SMS を唯一の認証手段にしているユーザーは即座に詰んでしまうことになります。また、SMS / 音声通話には次のようなセキュリティ上の弱点があります。
- IRSF をはじめとした通信事業者間の詐欺スキームのターゲットになりやすい
- SIM スワップ攻撃や SMS 転送設定を悪用される可能性がある
- ローミング中や電波状況により届かないことがある
- 認証ごとに通話料金・SMS 料金が発生し、コスト面でも非効率
このため、Microsoft もドキュメントやベストプラクティスで Authenticator アプリや FIDO2 / パスキーを第一候補とすることを推奨しています。
推奨される認証方式の構成
安全性と運用性のバランスを考えると、次のような構成が現実的です。
| 認証方法 | 位置付け | メリット | 注意点 |
|---|---|---|---|
| Microsoft Authenticator（番号一致プッシュ） | 既定（主方式） | フィッシング耐性が高く、ユーザー操作が簡単。リスクベースの制御とも相性が良い。 | スマホ紛失時に備え、予備の方法を必ず登録しておく。 |
| FIDO2 セキュリティキー / パスキー | 強力な予備 / 高リスク業務向け | パスワードレスでフィッシング耐性が最も高い。共有端末でも使いやすい。 | 初期導入コストや配布・回収の運用をどう設計するかがポイント。 |
| 別端末の Authenticator（2 台目スマホ・タブレット） | 予備 | メイン端末故障時のバックアップ手段として有効。 | 退職・端末返却時に登録解除を忘れないよう運用ルール化が必要。 |
| SMS / 音声通話 | 最後の補助的手段 | スマホアプリが使えないユーザー向けの逃げ道としては有用。 | 本記事で紹介したようなブロックや詐欺リスクを考慮し、主方式としては採用しない。 |
Entra 管理センターでのポリシー設定のポイント
認証方法ポリシーで SMS 利用を制限する
従来の「ユーザー単位の MFA 有効化」だけでは、どの認証方法を使わせるかまで細かく制御できません。今後は 認証方法ポリシーを使って、テナント全体の方針を明確にすることが重要です。
- Entra 管理センター > セキュリティ > 認証方法
- Microsoft Authenticator を「推奨」「必須」に近い形で有効化
- SMS / 音声通話は、特定のグループに限定するか、段階的に廃止する計画を立てる
あわせて、登録キャンペーン機能を利用し、「まだ Authenticator を登録していないユーザーに対して順次登録を促す」運用に切り替えるとスムーズです。
条件付きアクセスで SMS / 音声を避けたいシナリオを制御
条件付きアクセス ポリシーと組み合わせることで、次のような“守り方”も可能です。
- ハイリスク サインイン時（IP 評判が悪い、初見デバイスなど）は SMS / 音声を許可せず、Authenticator または FIDO2 のみを許可
- 特定の国や地域からのアクセスでは SMS / 音声の利用を制限
- 管理者ロールを持つアカウントには、そもそも SMS / 音声を使わせない
こうした設定により、攻撃者にとって狙いやすい SMS MFA の利用シーンを最小限に抑えることができます。
運用で気を付けたいポイント
サインインログと認証方法ログの定期確認
エラー 399287 のようなトラブルの多くは、サインインログや認証方法ログにヒントが残っています。情シス・セキュリティ担当者は、定期的に次の観点でログを確認しておくと、問題の早期発見につながります。
- MFA 失敗イベントが特定ユーザー／特定電話番号に偏っていないか
- 電話番号のフォーマットの誤り（国番号抜けなど）がないか
- 特定の国・地域からのアクセスで異常な失敗率が出ていないか
電話番号は必ず E.164 形式で登録する
Entra ID 上の電話番号は、+国番号から始まる E.164 形式で登録することが推奨です。
- 日本の携帯番号なら
+8190xxxx....のように登録 - 先頭の 0 を削除し、+国番号を付与する
- 社内の登録ルールとして明文化し、ユーザー自身のセルフサービス登録時にも同じルールを案内する
フォーマットがバラバラだと、国際 SMS の経路で思わぬ失敗やブロックにつながるケースもあるため、地味ながら重要なポイントです。
モバイルキャリア側の条件も確認する
とくに海外出張中のユーザーでは、次のような条件により SMS が届かないケースもあります。
- 国際ローミングが有効化されていない
- プレミアム SMS の受信がブロックされている
- 迷惑 SMS フィルタでブロックされている
エラー 399287 の場合は Microsoft 側のブロックである可能性が高いものの、通信キャリア側の制限と組み合わさっているケースもあるため、あわせて確認しておきましょう。
FAQ：現場でよく出る疑問
Q. 自分だけエラー 399287 で、他のユーザーは問題ありません。テナント設定の問題でしょうか？
A. 多くの場合、テナント全体の設定ではなく、そのユーザーの電話番号（または番号の属する範囲）に対するブロックです。他のユーザーが同じ国・同じキャリアでも問題ないなら、番号単位での reputation ブロックを疑い、Microsoft サポートにエスカレーションしてください。
Q. しばらく待てば自然に直りますか？
A. reputation のスコアは時間とともに変化する可能性がありますが、業務影響が出ているなら「自然回復待ち」はおすすめできません。サインインできない期間が長引くだけなので、速やかにサポートへ問い合わせ、ブロック解除と電話番号の reputation クリアを依頼しましょう。
Q. Microsoft Authenticator を主方式にしたいのですが、すでにサインインできず登録画面に行けません。
A. 管理者がいるテナントであれば、前述の Temporary Access Pass (TAP) を発行し、一時的にサインインさせてから Authenticator を登録させる、という手順が一般的です。管理者が自分だけの場合でも、Azure の課金情報や登録メールから Microsoft アカウント サポートに問い合わせ、回復の道を探ることができます。
Q. 管理者が 1 人しかおらず、その管理者のアカウントがエラー 399287 でロックされました。
A. もっとも厳しいケースですが、次のようなアプローチが考えられます。
- Azure サブスクリプションの課金情報から、サポート窓口に直接連絡し、所有者であることを証明した上でのテナント復旧を依頼する
- 今後に備えて、回復後は必ず 2 人以上のグローバル管理者を用意し、かつ認証方法も重ならないように設計する（Aさんは Authenticator + FIDO2、Bさんは Authenticator + 別電話番号など）
このケースはサポートの判断に大きく依存するため、テナント開設時から複数管理者と複数認証手段を用意しておくことが最大の予防策になります。
そのまま使えるサポート依頼テンプレート
最後に、Microsoft サポートへの問い合わせにそのまま流用できるテンプレートの一例を示します。内容は自社状況に合わせて適宜書き換えてください。
件名： Azure サインイン時の MFA エラー 399287 による本人確認不可について 本文： お世話になっております。 当社テナントにおいて、Azure ポータルへのサインイン時に SMS による多要素認証がエラーとなり、本人確認が完了できない事象が発生しております。 ■ 影響ユーザー UPN：<ユーザーUPN> ■ 影響電話番号／国 電話番号：+<国番号><番号> 国名：<国名> ■ エラー情報 Error code：399287 Request ID：<値> Correlation ID：<値> Timestamp (UTC)：<YYYY-MM-DDThh:mm:ssZ> ■ 発生事象 ・Azure ポータル サインイン時、パスワード入力後に SMS MFA が求められるが、 「Sorry, we’re having trouble verifying your account. Please try again.」と表示されサインイン不可。 ・ブラウザー変更、別ネットワーク、パスワード再設定などを行っても改善せず、 同一ユーザー／同一電話番号のみで事象が継続。 ■ 実施済み対処 ・ブラウザー変更（Edge / Chrome / シークレットモード） ・ネットワーク変更（社内・モバイルテザリング） ・サインイン試行の一時中断 ■ 依頼事項 ・当該電話番号およびユーザーに対するバックエンドのブロック解除 ・PhoneReputation などによる電話番号の悪評（Bad Reputation）のクリア ・必要に応じて SMS / 電話番号に関する制御状況のご確認 以上、ご確認のほどよろしくお願いいたします。
こうしたテンプレートを社内のナレッジとして残しておくと、将来同様のトラブルが起きた際にも素早くサポート依頼を行えます。
チェックリスト：エラー 399287 が出たときに確認すること
最後に、現場で迷わないためのチェックリストをまとめます。トラブル発生時には、これらを上から順に確認するとスムーズです。
| チェック項目 | はい / いいえ |
|---|---|
| エラー画面から Error code / Request ID / Correlation ID / Timestamp (UTC) を控えたか | |
| 同じユーザーで他のブラウザー・ネットワークでも再現するか確認したか | |
| 他のユーザーでは同様のエラーが出ていないことを確認したか | |
| Microsoft Authenticator や FIDO2 など、別の認証方法でサインイン可能かを確認したか | |
| サインインログで当該ユーザーの MFA 失敗イベントを確認したか | |
| 電話番号が E.164 形式で正しく登録されていることを確認したか | |
| Microsoft サポートに、エラー 399287 と電話番号ブロックの可能性を明示して問い合わせたか | |
| 復旧後、Microsoft Authenticator を既定の認証方法として登録したか | |
| 将来のために、TAP と複数認証手段を組み合わせた運用設計を見直したか |
まとめ：ブロック解除と認証設計の両輪で対処する
本記事で扱った Azure サインイン エラー 399287 は、多くの場合「電話番号や SMS 経路が Microsoft のバックエンドでブロックされている」ことが原因です。ユーザーやテナント設定だけでは解消できないため、Microsoft サポートによるブロック解除と電話番号の reputation クリアが欠かせません。
同時に、再発を防ぐには、Microsoft Authenticator を主方式に据え、SMS / 音声を補助的手段に格下げすることが重要です。認証方法ポリシーや条件付きアクセス、Temporary Access Pass を組み合わせることで、「安全かつ止まりにくい」サインイン環境を構築できます。
「とりあえず SMS でいいか」と後回しにされがちな認証方式ですが、今回のようなトラブルをきっかけに、ぜひ自社の Entra ID / Azure 環境の認証設計を見直してみてください。
コメント