Azure ポータルや Microsoft Entra ID（旧 Azure AD）にサインインしようとした瞬間、「アカウントの確認に問題が発生しました。Error Code: 399287」と表示され、SMS を使った多要素認証が進まず完全にロックアウト…という相談が増えています。本記事では、このエラー 399287 の正体（電話番号レピュテーション／MFA ブロック）と、テナント管理者・利用者それぞれが取るべき復旧手順、さらに再発防止のための認証設計を、実務目線で丁寧に解説します。
Azure（Microsoft Entra ID）サインイン時のエラー 399287 とは？
今回のケースは、Microsoft アカウントや Azure ポータルにサインインしようとした際、パスワード入力までは通るものの、SMS を使った多要素認証（MFA）が完了せず、次のようなメッセージが表示されるというものです。
Sorry, we're having trouble verifying your account. Please try again. Error Code: 399287 Request Id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Correlation Id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Timestamp: 2025-xx-xxTxx:xx:xxZ
画面上は「この電話番号宛てに SMS を送信してコードを入力してください」という流れですが、SMS がそもそも送信されず、何度リトライしても 399287 で止まる、というのが典型的な症状です。
| 視点 | 具体的な症状・ログ | ポイント |
|---|---|---|
| エンドユーザー | サインイン時に SMS 認証を選ぶと、 「アカウントの確認に問題が発生しました。もう一度お試しください。 Error Code: 399287」 となり先に進めない。 | ブラウザや端末を変えても再現することが多い。 |
| 管理者（サインインログ） | サインインログの認証詳細で、MFA のステップが 「電話（SMS）」や「テキストメッセージ」として記録されるが、 結果は Failure / Interrupted となる。 | MFA が要求されているが、SMS 送信の段階で失敗している。 |
| 根本要因 | Microsoft 側の電話認証基盤で、対象電話番号や発信元が 「悪いレピュテーション」と判断され、 SMS / 音声による MFA がバックエンドでブロックされている。 | ユーザーや管理者側での簡単な設定変更だけでは解除できない場合がある。 |
エラー 399287 の正体：電話番号レピュテーションとテレフォニー不正対策
公開情報やコミュニティの事例では、エラー 399287 は「PhoneReputation」による MFA ブロックと関連付けられているとされています。これは、Microsoft Entra が内部的に電話番号や回線の健全性をスコアリングし、不正の疑いが高い番号・国番号・トラフィックパターンを自動的にブロックする仕組みです。
背景には、International Revenue Share Fraud（IRSF：国際電話収益分配詐欺）などのテレフォニー不正があります。IRSF では、攻撃者が SMS / 音声による認証を悪用し、大量の認証リクエストを高額な国際プレミアム番号に流すことで、事業者・サービス提供者に巨額の通話料被害を与えます。Microsoft はこのような被害を防ぐため、
- 特定の国番号からの SMS / 音声トラフィックをデフォルトで無効化
- 異常な量の認証リクエストが見られた電話番号・ユーザー・リージョンの一時的なスロットリング（制限）
- 電話番号のレピュテーション（評判）に基づいたブロック
といった対策を組み合わせて運用しています。これらの対策が発動すると、エンドユーザーには単に「SMS が届かない」「エラー 399287」としか見えない形で影響が出ます。
特に、以下のような条件が重なるとブロックされやすくなります。
- 高リスクとされる国番号（テレフォニー不正が多い地域）の電話番号を使用している
- 短時間に大量の SMS 認証が発生している（人為的な誤操作やアプリのバグも含む）
- 同じ番号が複数テナントで使い回されている／過去に不正利用履歴がある
つまり、エラー 399287 は単なる「電波が悪い」「キャリアの障害」というレベルを超え、Microsoft 側の不正対策ロジックが “この番号は危ない” と判断している状態だと理解するとよいでしょう。
結論の概要：誰が何をすればよいか
本記事で解説する内容をざっくりまとめると、次のようになります。
- 原因の要点：対象アカウントの SMS / 音声による MFA がバックエンドでブロックされ、電話番号や発信元が「悪いレピュテーション」と判定されている。
- 対処の流れ：
- テナント管理者がサインインログと認証方法設定を確認
- 必要に応じてユーザーの MFA 登録をリセットし、TAP（Temporary Access Pass）で一時的なログイン経路を用意
- Identity Protection や条件付きアクセスによるブロックを確認・調整
- なお解消しない場合は、Microsoft サポートにエラー 399287＋RequestId・CorrelationId・Timestamp を提示し、電話レピュテーションの解除を依頼
- 今後の推奨：SMS / 音声はあくまで「補助的な手段」とし、Microsoft Authenticator（番号マッチング）や FIDO2 セキュリティキー／パスキーを主手段として登録・利用する。
テナント管理者が行うべき具体的な復旧ステップ
ここからは、テナント管理者（Microsoft Entra 管理者）向けに、実務フローとしての手順を詳しく整理していきます。
ステップ 1：サインインログで失敗イベントを特定する
まずは、ユーザーからエラーの画面情報を集め、サインインログ上で該当イベントを特定します。
- ユーザーに、次の情報を共有してもらいます。
- エラー画面のスクリーンショット（Error Code, Request Id, Correlation Id, Timestamp を含む）
- サインインに使った UPN（[email protected] 形式）
- 試した日時（ローカル時刻とタイムゾーン）
- アクセスしようとしたサービス（Azure ポータル、Microsoft 365 管理センターなど）
- 管理者として Microsoft Entra 管理センターにサインインし、
「Microsoft Entra ID > 監視 > サインイン」 を開きます。 - ユーザー名やサインイン時刻でフィルターし、必要に応じて Correlation Id / Request Id のフィルターも追加します。
- 該当イベントを開き、次の項目を重点的に確認します。
- 結果（成功 / 失敗 / 中断）
- 結果の詳細（MFA 失敗、チャレンジ失敗など）
- 認証の詳細（Authentication Details）：どの手段で MFA が要求され、どのステップで失敗しているか
| 確認項目 | 見る場所 | 確認したい内容 |
|---|---|---|
| サインイン結果 | サインインログの「基本情報」 | Result = Failure / Interrupted になっていないか。 |
| MFA 要求の有無 | サインインログの「詳細」 > Authentication Details | MFA が Required になっており、 Method = Phone/SMS で失敗しているか。 |
| 条件付きアクセス | サインインログの「条件付きアクセス」タブ | どの CA ポリシーが適用／ブロックしているのか。 |
このステップで「SMS 認証の段階で必ず失敗している」「他の方法（Authenticator など）はそもそも構成されていない」ことが見えれば、後続の対処方針が明確になります。
ステップ 2：ユーザーの認証方法（MFA）をリセット・整備する
次に、対象ユーザーの MFA 設定を確認し、必要に応じてリセットします。
- 「Microsoft Entra ID > ユーザー > 対象ユーザー」を開き、「認証方法」または「セキュリティ情報」タブを表示します。
- 登録されている認証方法を確認します。
- Microsoft Authenticator（通知／ワンタイムコード）
- 電話（SMS / 音声）
- FIDO2 セキュリティキー／パスキー
- メールアドレスなど
- 電話番号が登録されている場合は、次のような操作を検討します。
- 国番号や電話番号の誤りがないかを確認（+81 の有無など）
- 現在の電話番号を一度削除し、再登録してもらう
- 「多要素認証の再登録を要求」オプションを利用できる場合は有効化し、次回サインイン時に MFA の再登録を強制します。
- 併せて、「Authentication methods > Policies」で SMS / Voice の利用許可が無効化されていないかも確認します。
ここまでで解消するケースもありますが、電話番号そのもののレピュテーションが悪い場合は、再登録しても 399287 が継続することがあります。この場合、次の TAP を使った復旧導線の整備が重要です。
ステップ 3：一時アクセス パス（TAP）で復旧導線を作る
Temporary Access Pass（TAP）は、Microsoft Entra ID が提供する「時間制限付きの一時パスコード」です。通常の MFA 手段が使えなくなったユーザーに対して、一時的なログイン手段を提供し、そのセッション中に Authenticator や FIDO2 を再登録させる用途で使われます。
- 認証方法ポリシーで TAP を有効化
- 「Microsoft Entra ID > セキュリティ > 認証方法 > ポリシー」へ移動します。
- Temporary Access Pass（TAP）を選択し、対象ユーザー／グループに対して「有効」にします。
- TAP の有効期間（例：1〜24 時間）や最大使用回数（例：1〜2 回）などのポリシーを定義します。
- 対象ユーザーに TAP を発行
- 対象ユーザーの「認証方法」画面から「一時アクセス パスの追加」を選びます。
- 有効期限と利用回数を設定し、発行された TAP（英数字のコード）を安全な経路でユーザーに伝えます。
- ユーザーに TAP でサインインしてもらい、強固な認証方法を登録
- ユーザーは TAP を使って Azure ポータルや
https://myaccount.microsoft.com/https://aka.ms/mysecurityinfoなどにサインインします。 - サインイン後すぐに、Microsoft Authenticator（番号マッチング有効）や FIDO2 セキュリティキー／パスキーを登録します。
- 必要であれば、SMS / 音声も「あくまで予備」として登録します。
- ユーザーは TAP を使って Azure ポータルや
| TAP の特徴 | ポイント |
|---|---|
| 有効期限付き | 数時間〜数日など、短期的な復旧用途に限定できる。 |
| 使用回数を制限可能 | 1 回だけ使用可などにすることで不正利用リスクを抑えられる。 |
| 通常の MFA をバイパス | SMS がブロックされていても、TAP 自体が 2 要素として扱われるためログインできる。 |
ステップ 4：ポリシー／リスクベースによるブロック状況を確認
電話レピュテーションとは別に、Identity Protection や条件付きアクセスのポリシーがサインインをブロックしているケースもあります。こちらも合わせて確認しましょう。
- Identity Protection（ID 保護）の確認
- 「Microsoft Entra ID > セキュリティ > Identity Protection」へ移動し、
「リスクの高いユーザー」「リスクの高いサインイン」を確認します。 - 当該ユーザーが「高リスク」と判定されている場合、パスワード変更やサインインブロックが自動適用されている可能性があります。
- 「Microsoft Entra ID > セキュリティ > Identity Protection」へ移動し、
- 条件付きアクセス（CA）の確認
- 「セキュリティ > 条件付きアクセス」で、当該ユーザー／グループに適用されるポリシーを確認します。
- 場所（国／IP）、デバイスタイプ、クライアントアプリ、サインインリスクなどの条件によってブロックされていないかをチェックします。
Identity Protection や CA でブロックされている場合は、一時的な除外や緩和を行い、正当なユーザーであればアクセスを許可するよう調整します。
ステップ 5：解決しない場合のエスカレーション（Microsoft サポート）
ここまでの確認・設定変更を行ってもなお SMS 認証が エラー 399287 で必ず失敗する場合、テレフォニー基盤側のブロック解除を Microsoft サポートに依頼する必要があります。Microsoft 自身も、特定の国コードに対しては opt-in（明示的な有効化）やサポートチケットによる対応を求めています。
サポートチケットを発行する際は、次の情報を必ず添えてください。
- エラーメッセージ全文
- Error Code: 399287
- Request Id / Correlation Id / Timestamp（UTC）
- 影響を受けているユーザーの UPN とテナント ID
- 問題が発生している電話番号（国番号＋番号）と、その種別（携帯・固定・フリーダイヤル 等）
- 問題が発生し始めた日時と頻度（常に失敗するのか、断続的なのか）
- 他のユーザー・他の電話番号でも同様の事象が発生しているかどうか
- サインインログの抜粋（MFA がどの段階で失敗しているかが分かる情報）
問い合わせの際には、
- 電話番号が正当な業務利用であること
- IRSF 等の不正利用には関与していないこと
- 可能であれば、別の電話番号や Authenticator への切り替えも検討していること
を明示し、PhoneReputation / テレフォニー関連のバックエンドブロック解除を依頼すると話が通りやすくなります。
なお、テナント管理者権限を持たないエンドユーザーの場合は、自身でできることは限られます。エラー画面の情報（Request Id / Correlation Id / Timestamp / スクリーンショット）を添えて、社内の IT 管理者・ヘルプデスクにエスカレーションしてください。
エンドユーザー側で試せる応急処置
テレフォニー側のブロックが原因だったとしても、ユーザー側で試せることはゼロではありません。特に「すでに Authenticator など別の手段を登録済み」なら、SMS を回避できる場合があります。
別の MFA 手段を選択する
- サインイン画面に「別の方法を使用する」「別の確認方法を使う」といったリンクが表示されている場合は、Microsoft Authenticator アプリの通知やワンタイムコードを選択してみてください。
- Authenticator を登録済みなのに SMS がデフォルトで選ばれてしまう場合は、サインイン後に「セキュリティ情報」ページで既定のサインイン方法を変更しておくとよいでしょう。
ネットワークや端末の影響を切り分ける
- 別のブラウザ（Edge / Chrome / Firefox など）や プライベートウィンドウで試す。
- 別の端末（スマホ／別 PC）からサインインを試す。
- 別回線（Wi‑Fi ⇔ モバイル回線）でアクセスしてみる。
- 企業 VPN・プロキシ・海外経由のトンネルを使っている場合は、一度無効化してから試す。
端末の時刻設定を確認する（Authenticator 利用時）
今回の記事では主に「SMS 認証での 399287」に焦点を当てていますが、まれに Authenticator アプリ利用時の時刻ずれが原因で同じコードが出るケースも報告されています。端末の日時が「自動取得（ネットワーク時刻）」になっているか、タイムゾーン設定が正しいかも確認しておくと安心です。
再発防止：認証基盤の設計を見直す（ベストプラクティス）
エラー 399287 をきっかけに、そもそも SMS / 音声に過度に依存しない MFA 設計へ移行することが重要です。Microsoft 自身も、Windows Hello for Business や FIDO2 パスキーなどの フィッシング耐性の高い認証方法を優先するよう推奨しています。
推奨される MFA 構成パターンの例
| ユーザー種別 | 主なサインイン手段（第一候補） | 予備の手段 | SMS / 音声の位置付け |
|---|---|---|---|
| 一般ユーザー | Microsoft Authenticator（番号マッチング付き）またはパスキー | FIDO2 セキュリティキー、Authenticator のワンタイムコード | 利用可能だが優先度は低い。主に緊急時のバックアップ。 |
| 管理者／特権アカウント | FIDO2 セキュリティキー、Windows Hello for Business | Authenticator（番号マッチング）、別デバイスのパスキー | 原則無効化、または極力使用しない（テレフォニー不正リスクが大きいため）。 |
| スマホを常用しないユーザー | ハードウェアトークンや FIDO2 キー | PC ブラウザに登録したパスキー | 必要な場合のみ限定的に利用。 |
MFA 手段ごとの特徴とリスク比較
| 認証方式 | 安全性の傾向 | 主なリスク | 主な用途 |
|---|---|---|---|
| パスワードのみ | 低い | 総当たり／リスト型攻撃／フィッシングで容易に突破される。 | レガシーアプリ等やむを得ない場合のみ。 |
| SMS / 音声による MFA | 中程度 | IRSF 等のテレフォニー不正、SMS 乗っ取り、回線障害による不達。 今回のようなレピュテーションブロックの影響も受けやすい。 | 予備の MFA 手段、既存ユーザーの移行期間中。 |
| Microsoft Authenticator（プッシュ / コード） | 高い | MFA 疲れ攻撃（大量プッシュ）に対しては、番号マッチングでの対策が必須。 | 一般ユーザーの標準 MFA、パスワードレスサインイン。 |
| FIDO2 セキュリティキー／パスキー | 非常に高い | 紛失対策（複数キーの発行／バックアップ方法の整備）が必要。 | 管理者・高価値アカウント、ゼロトラスト環境の中核認証。 |
Microsoft も、SMS / 音声による認証は IRSF 等のテレフォニー不正に弱く、Authenticator や FIDO2 と比較してリスクが高いことを示しており、できるだけ Authenticator へ切り替えることを推奨しています。
テレフォニー不正（IRSF）を前提にした設計と運用
IRSF は、攻撃者が通信事業者の課金システムを悪用し、高額な国際プレミアム番号に大量の通話・SMS トラフィックを流して利益を得る手口です。MFA の SMS / 音声認証も格好の標的であり、大量の認証リクエスト → 通話料の膨張 → サービスエラーやブロックという形で影響が表面化します。
組織側としては、次のような対策が現実的です。
- 利用しない国番号を明示的に除外する
- 自組織のユーザーが所在しない国の電話番号には、SMS / 音声を許可しない。
- B2C / 外部 ID シナリオでは、Microsoft が推奨するように、不要なリージョンコードを除外する。
- テレフォニー利用状況の監視
- Azure / Microsoft 365 のレポートや課金情報から、SMS / 音声認証の利用量を定期的に確認する。
- 急激な増加があればすぐに調査し、疑わしいパターンを検知したら SMS / 音声を一時的に停止する。
- 認証方法ポリシーでの制御
- 特権アカウントや管理者には SMS / 音声を許可しない、あるいは強い制限をかける。
- 外部ユーザーには Telephony ではなく Email OTP や他の手段を優先する設計を検討する。
ヘルプデスク向け運用ルールの整備
エラー 399287 のようなトラブルは、ユーザーから見ると「ログインできない」の一言で済んでしまうため、フロントラインのヘルプデスクがどう動くかが極めて重要です。
少なくとも、次のような運用ルール・手順書を用意しておくことをおすすめします。
- MFA リセット／TAP 発行の標準手順
- どの権限ロールのメンバーが MFA リセット・TAP 発行を行うか。
- 本人確認に必要な情報（社員番号・連絡先・上長確認など）。
- 発行した TAP をどのチャネルで安全に伝えるか。
- サインインログの確認方法
- Request Id / Correlation Id / Timestamp を使ってログを引く手順。
- 電話／SMS による MFA が失敗しているのか、そもそも MFA 要求に進んでいないのかを読み解くポイント。
- Microsoft サポートへのエスカレーションテンプレート
- どの情報を、どのフォーマットでサポートに渡すか。
- エラー 399287 のように「テレフォニー基盤側の調査」が必要なケースを切り分ける条件。
- 緊急時の代替経路
- 重要システムにアクセスできない場合の「代替業務手順」（紙運用・オフライン申請など）。
- 少なくとも 2 つ以上の認証手段を事前に登録させる社内ポリシー。
サインイン失敗の監視と通知
最後に、サインイン失敗や MFA 失敗を継続的に監視する仕組みを用意しておくと、今回のような問題を早期に検知できます。
- サインインログを Log Analytics に送信し、
- 特定ユーザーの MFA 失敗回数の急増
- 特定の国番号・ IP ブロックからの不審な試行
- Identity Protection のアラート（リスクの高いサインイン・ユーザー）をメールや Teams に通知する。
- 定期的なレポートとして、どの認証方法がどの程度使われているかを可視化し、SMS 比率が高い部署には Authenticator への移行を促す。
期待される結果とまとめ
ここまでの内容を整理すると、エラー 399287 の対応は次のような流れになります。
- サインインログを確認し、SMS / 音声による MFA のステップで失敗していることを確認する。
- ユーザーの認証方法（MFA）を整理し、可能なら TAP を使って Microsoft Authenticator や FIDO2 パスキーを主手段として再登録する。
- Identity Protection や条件付きアクセスのポリシーが原因であれば、適切に緩和・調整する。
- なおも SMS が 399287 で失敗し続ける場合、Microsoft サポートにテレフォニー基盤側のブロック解除／電話レピュテーションのクリアを依頼する。
サポート／管理者によるバックエンドのブロック解除が完了すれば、SMS 認証自体は再び利用できるようになる可能性が高いです。ただし、再度同じようなブロックを招かないためにも、今後の運用では SMS / 音声に依存せず、Authenticator や FIDO2 などのより強固な方式を主役に据える設計が重要です。
「とりあえず SMS でいいか」と後回しにされがちな部分ですが、テレフォニー不正とそれに対する自動防御がますます強化されている現在、認証戦略そのものを見直す良いきっかけとして、エラー 399287 を前向きに捉えていただければと思います。
コメント