Microsoft Entra ID（旧 Azure AD）でサインインしようとしたとき、SMS を使った 2 段階認証だけが失敗し、「Error 399287」と表示されて先に進めない──そんな状況になると、ユーザーも管理者も身動きが取れなくなりがちです。本記事では、実際に発生した事例をベースに、エラー 399287 の正体・原因の切り分け・Microsoft へのエスカレーション方法・再発防止の設計ポイントまでを、管理者目線で詳しく解説します。
Microsoft Entra ID「エラー 399287」とは何か
エラー 399287 は、Microsoft Entra ID（旧 Azure AD）で SMS／音声電話を使った多要素認証（MFA）を行う際に表示されることがあるコードです。典型的には、以下のような流れで発生します。
- ユーザー名とパスワードの入力までは成功する
- 2 段階認証として「電話番号への SMS」や「音声通話」を選択
- コード送信前後で「Sorry, we’re having trouble verifying your account. Please try again.」といったメッセージとともに Error 399287 が表示される
Microsoft Q&A などでは、エラー 399287 は Microsoft の PhoneReputation サービス によって「その電話番号（またはトラフィック）がブロックされた状態」で発生することが案内されています。多くのケースで、サインインの「パスワード」までは問題なく通り、SMS／電話による MFA の部分だけがブロックされているのが特徴です。
| 観点 | エラー 399287 の典型パターン |
|---|---|
| 発生タイミング | MFA ステップ（SMS／電話）の直前または直後 |
| 他の認証方法 | Microsoft Authenticator 等の別の MFA は成功することが多い |
| ログ上の表示 | 「Multi-factor authentication method is blocked」「BadReputation」などの詳細が出る場合がある |
| 影響範囲 | 多くは「該当の電話番号／テナント」に限定（アカウント自体が無効とは限らない） |
実際に発生した事例：SMS MFA が突然使えなくなったケース
ここでは、実際に発生した「エラー 399287」による障害事例を整理します。
事象の概要
- 対象：Microsoft Entra ID テナントの一部ユーザー
- 現象：
- パスワード入力までは成功
- SMS による 2 段階認証へ進むと Error 399287 が表示される
- コード入力画面まで進めない、またはコード入力後に同エラーで失敗
- ログ：サインイン画面に Error Code／Request ID／Correlation ID／Timestamp が表示・記録されている
- 他の認証方法：Authenticator アプリなど、SMS 以外の MFA が登録されていれば問題なく利用できるケースもあり
原因：SMS トラフィックに「悪評（BadReputation）」が付与されていた
Microsoft サポートからのフィードバックによると、このケースでは次のような状態でした。
- 対象電話番号（または同一テナントからの SMS トラフィック）が、Microsoft の PhoneReputation／テレフォニー保護の仕組みで 「BadReputation」判定 となっていた
- その結果、SMS／電話を使った MFA メソッドだけがバックエンドでブロック されていた
- ユーザーや管理者側の設定だけでは解除できず、Microsoft のエンジニアリングチームによる解除が必要だった
同様の事例が Microsoft Q&A にも複数報告されており、サインイン／認証方法ログには「Result detail: BadReputation」や「Multi-factor authentication method is blocked」といった詳細が記録されていることが確認されています。
対応：Microsoft によるバックエンド解除で復旧
上記の事例では、次のような流れで復旧しました。
- 管理者がサインインログや認証方法ログを確認し、SMS メソッドでのみ爆発的に失敗が出ていることを確認
- ユーザー側の端末設定や電話番号形式、認証方法ポリシーに問題がないことをチェック
- Request ID／Correlation ID／発生時刻／対象ユーザー／電話番号／国番号などを添え、Microsoft サポートにチケットを起票
- サポートからエンジニアリングにエスカレーションされ、バックエンド側で「BadReputation」の解除とブロック解除 が行われる
- 数十分〜数時間後、ユーザーが再度サインインを試すと SMS 認証が正常に完了するようになった
| 項目 | 内容 |
|---|---|
| 最終的な原因 | PhoneReputation による SMS MFA メソッドのブロック（BadReputation） |
| 解決策 | Microsoft によるバックエンドでの「悪評」クリアとブロック解除 |
| ユーザー側の設定変更 | 特になし（ただし、今後のために Authenticator 等の代替 MFA を追加） |
| 再発防止 | SMS／音声の利用を最小限にし、Microsoft Authenticator・パスキーを中心とした構成に変更 |
Microsoft のテレフォニー保護と PhoneReputation の仕組み
PhoneReputation とテレフォニー保護の概要
Microsoft Entra ID は、SMS や音声通話を利用した認証に対して テレフォニー詐欺対策 を実装しています。これには、以下のような特徴があります。
- すべての SMS／音声認証リクエストを、ヒューリスティック・リスクシグナル・機械学習モデルなどを使ってリアルタイムに評価
- 異常なリクエストパターンや高リスク地域からのトラフィックを検出
- 不正・濫用の疑いがある場合、その電話番号やテナントに対して スロットリングやブロック を行う
- ブロック時のユーザー側の見え方として、「Sorry, we’re having trouble verifying your account」やエラー 399287 などが表示される
このとき、内部的に使われる評価指標のひとつが PhoneReputation（電話番号の評判） であり、不自然な認証要求が集中した電話番号や、特定の地域コードに紐づくトラフィックなどが「BadReputation（悪評）」として扱われることがあります。
IRSF（国際収益分配詐欺）の脅威
Microsoft が公式ドキュメントで重視しているテレフォニー詐欺の代表例が IRSF（International Revenue Share Fraud：国際収益分配詐欺） です。
IRSF は、攻撃者が国際電話やプレミアムレート番号を悪用し、通話や SMS トラフィックを大量に流すことで通信事業者との収益分配から不正な利益を得る手口です。典型的なパターンは次の通りです。
- 攻撃者が高額課金のプレミアム番号を取得
- 盗んだアカウントや自動スクリプトを使い、MFA やワンタイムコード送信の仕組みに大量の SMS／音声認証を発生させる
- Microsoft やキャリアからその番号に大量のトラフィックが流れ、攻撃者が収益の一部を得る
このような背景から、Microsoft はテレフォニー認証に対して厳しめの保護・スロットリングをかけています。正規ユーザーにとっては「急に SMS が届かなくなった」「Error 399287 が出た」という形で見えるものの、その裏側では 高額請求やサービス劣化を防ぐための安全装置 が動いている、と捉えることができます。
| 観点 | IRSF 攻撃 | 正規ユーザーへの影響 |
|---|---|---|
| トラフィック量 | 短時間に非常に大量の SMS／音声認証リクエスト | 同一番号・同一テナントへの制限が強まる |
| 地域コード | 高リスクな国番号を回遊しながら攻撃 | 一部の国番号については「事前の利用申請（opt-in）」が必要になる |
| 検知後の動作 | トラフィック遮断・スロットリング | 「Sorry, we’re having trouble verifying your account」や Error 399287 が表示される |
エラー 399287 につながりうるその他のパターン
BadReputation 以外にも、SMS／音声 MFA がブロックされるパターンとして、次のようなものが考えられます。
- 短時間に何度も SMS コードを要求し、スロットリング（回数制限） に引っかかっている
- 電話番号のフォーマットが E.164（
+81 90xxxx...など）になっておらず、正しく解釈されていない - 特定の国番号が テレフォニー利用の「要申請地域」 に該当していて、テナントがまだ有効化されていない
- ユーザーが「MFA ブロック」状態に設定されており、電話を含む MFA メソッドがすべて拒否されている
したがって、「エラー 399287 ＝すべて BadReputation」というわけではなく、ログ上の詳細や発生条件を丁寧に切り分けることが重要です。
エラー 399287 発生時に疑うべき主な原因
実務的な観点から、エラー 399287 が出た際にまず疑うべき原因を一覧にしたものが下表です。
| カテゴリ | 具体的な原因候補 | ログや症状のヒント | 優先的な対応 |
|---|---|---|---|
| テレフォニー保護 | PhoneReputation による BadReputation 判定 | 認証方法ログに「BadReputation」「Multi-factor authentication method is blocked」などが出る | 別メソッドで回避しつつ Microsoft サポートにエスカレーション |
| ポリシー設定 | Authentication methods ポリシーで SMS／音声が無効、または対象外グループ | 一部ユーザーのみ影響、テストユーザーでは再現しない | Entra 管理センターの「Authentication methods > Policies」を確認・修正 |
| ユーザー状態 | ユーザーが MFA ブロック状態になっている | すべての MFA メソッドが失敗する／別メソッドでも失敗 | 管理者がユーザーのブロック解除を実施 |
| 番号／キャリア | 電話番号形式の誤り・番号重複・キャリア側で海外 SMS 拒否など | 別の電話番号に変更すると成功する／特定キャリアのみ失敗する | 番号形式を E.164 に統一、キャリア設定や迷惑 SMS フィルタを確認 |
| スロットリング | 短時間に大量の SMS／電話認証を試行 | 「回数制限」系のメッセージが出る、時間を空けると復旧する | しつこく連打せず、数分〜十数分あけて再試行。できれば Authenticator へ切り替え |
| 地域制限 | テレフォニー利用に opt-in が必要な国番号からの SMS／音声 | 特定の国番号だけ SMS が届かない、他国番号では問題ない | Telephony fraud 保護の対象地域リストを確認し、必要に応じて Microsoft サポートに有効化申請 |
ユーザー側で今すぐできる切り分け手順
まずは、現場のユーザー自身でも実施できる簡単な切り分けから始めると、管理者やサポートへの情報提供もスムーズになります。
1. 別の認証方法でサインインできるか試す
- Microsoft Authenticator（プッシュ通知＋番号一致）
- Authenticator のワンタイムパスコード（OATH-TOTP）
- FIDO2 セキュリティキー／パスキー
- 別の電話番号（予備の携帯・オフィス番号など）
「SMS／電話だけが失敗し、他の方法は成功する」 場合、テレフォニー保護や PhoneReputation 側の問題である可能性が高まります。
2. 端末側の SMS／電話環境を確認
- 機内モードになっていないか
- 迷惑 SMS フィルタやセキュリティアプリで海外 SMS がブロックされていないか
- SIM の有効期限切れや料金未払いがないか
- 別の端末に SIM を挿しても同様に届かないか
ここで問題が見つかった場合は、まず端末やキャリアの問題を解消してから再度試します。
3. 短時間での連続リクエストを控える
焦って SMS コードを連打要求すると、Microsoft 側でスロットリングがかかり、かえって状況が悪化することがあります。
- 何度も失敗した場合は、最低でも数分～十数分は時間を空ける
- 可能であれば、Authenticator など別の方法に切り替える
4. 管理者に伝えるべき情報を整理しておく
- エラーメッセージ全文（スクリーンショット推奨）
- 表示されている Error Code／Request ID／Correlation ID／Timestamp
- サインイン試行時刻（ローカル時刻）とタイムゾーン
- 使おうとした電話番号（国番号を含めた完全な形式）
ここまで分かっていれば、管理者がサインインログと突き合わせて原因を特定しやすくなります。
管理者向け：詳細なトラブルシューティング手順
サインインログと認証方法レポートの確認
管理者は、まず サインインログ と Authentication methods Activity ダッシュボードを確認し、問題がどのフェーズで起きているかを把握します。
- Microsoft Entra 管理センター（
entra.microsoft.com）にサインイン - Entra ID > サインイン を開き、対象ユーザー＋対象時刻でフィルタ
- 該当イベントを開き、「認証の詳細」タブで MFA のステップと結果を確認
- 必要に応じて、Authentication methods > Activity から「SMS」「Phone call」メソッドの失敗状況を確認
ここで以下のような情報が得られると、原因がかなり絞り込めます。
- Result detail が BadReputation / Multi-factor authentication method is blocked
- 失敗している認証方法が「Text message (SMS)」に集中している
- 別メソッド（Authenticator、FIDO2 等）は成功している
MFA 登録のリセットと代替認証の付与
ユーザーが SMS しか登録しておらず、しかも BadReputation でブロックされている場合、そのままでは本人が何もできない状態 になりがちです。そのため、管理者側で次のような措置を取ります。
- ユーザーに対して 「Require re-register multifactor authentication」 を実行し、MFA を再登録させる
- 一時的に Temporary Access Pass（TAP） を発行し、Authenticator／パスキーを登録させる
- もしくは、管理者がユーザーの認証方法として Authenticator や FIDO2 キーを追加設定（物理的にユーザーと連携できる場合）
TAP は、時間制限付きの一次コードであり、最初のサインインや強力な認証方法の再登録時に使うことを想定した仕組みです。ユーザーは TAP で一度だけサインインし、そのセッションの中で Microsoft Authenticator やパスキーを登録することで、今後 SMS に依存しない運用に移行できます。
PhoneReputation ブロック解除を Microsoft に依頼する
ログ上で明らかに BadReputation／メソッドブロックが疑われる場合は、Microsoft サポートにエスカレーションし、PhoneReputation の解除を依頼 する必要があります。
その際、最低限以下の情報をまとめておきます。
- 影響を受けているテナント ID
- 影響ユーザーの UPN（メールアドレス）
- 該当する電話番号（
+81など国番号を含めた E.164 形式） - エラーが発生した日時（UTC での Timestamp を含む）
- 当該イベントの Request ID／Correlation ID
- サインイン／認証方法ログのスクリーンショットまたは出力
Microsoft Q&A の事例では、これらの情報をもとにエンジニアリングチームがバックエンド側のブロックを解除し、「悪評（BadReputation）」をクリアした結果、SMS MFA が再度利用可能になったことが報告されています。
なぜ SMS／音声から Authenticator・パスキーに移行すべきか
Microsoft 自身の推奨
Microsoft は公式ドキュメントにおいて、SMS／音声通話による MFA から、Microsoft Authenticator などのモダンな認証方法へ移行すること を繰り返し推奨しています。
- SMS／音声は、盗聴・番号乗っ取り・IRSF 攻撃などのリスクが相対的に高い
- Microsoft Authenticator のプッシュ通知（番号一致）は、データ通信ベースでより信頼性が高く、フィッシング耐性も高い
- Authenticator は MFA だけでなく、パスワードレスサインイン（パスキー）にも対応しており、今後の認証基盤としても拡張性が高い
さらに、Microsoft Entra の「Recommendations」では、テナント内で SMS／音声を使っているユーザーが多い場合に 「useAuthenticatorApp」 という推奨が表示され、Authenticator への移行を促す仕組みも提供されています。
SMS MFA 特有のリスクと運用上のつらさ
SMS／音声による MFA は手軽な一方で、運用上次のような問題を抱えています。
- SIM スワップ攻撃：悪意ある第三者が通信事業者を騙して SIM を再発行し、SMS コードを奪取
- 電波状況の影響：地下・屋内・海外など、電波が弱い環境ではコードが届かない
- テレフォニー保護によるブロック：IRSF 対策などで正規ユーザーも巻き込まれることがある
- 端末変更時のトラブル：電話番号変更やキャリア移行時に MFA が復旧できず、ロックアウトが発生
これに対して、Microsoft Authenticator や FIDO2 キー／パスキーは、暗号鍵ベースでフィッシング耐性が高く、テレフォニーチャネルに依存しない ため、安定性・安全性ともに優れています。
現実的な移行ステップ
とはいえ、すべてのユーザーから一気に SMS を取り上げるのは現実的ではありません。以下のような段階的な移行を推奨します。
| 段階 | 内容 | ポイント |
|---|---|---|
| フェーズ 1 | 全ユーザーに Microsoft Authenticator を「追加」させる | SMS は残したまま、Authenticator を第一優先にする |
| フェーズ 2 | 高権限アカウントから順に SMS／音声を無効化 | グローバル管理者・特権ロールは Authenticator／パスキー必須に |
| フェーズ 3 | 一般ユーザーに対しても SMS／音声を「予備手段」に格下げ | Authentication methods ポリシーで SMS／音声の利用を最小化 |
| フェーズ 4 | 一部業務（例：フロントラインワーカー）を除き、SMS 利用を段階的に停止 | 必要であれば、フロントライン向けには SMS サインインや QR 認証を検討 |
再発防止のベストプラクティス（利用者・管理者向け）
利用者向け：最低限やっておきたいこと
- Microsoft Authenticator を第一手段として登録
- プッシュ通知＋番号一致を有効にし、可能であればパスワードレスサインイン（パスキー）もセットアップ
- 予備の認証方法を複数用意
- 別端末の Authenticator（会社支給スマホなど）
- OATH-TOTP（ハードウェアトークンや他社 OTP アプリ）
- 予備の電話番号（家族の番号を使う場合は規程に注意）
- 電話番号変更時は必ず IT 管理者に連絡
- 自力での番号変更だけでなく、管理者側の登録も更新してもらう
管理者向け：認証基盤設計のポイント
管理者側では、Authentication methods ポリシーを軸に設計を見直すことが重要です。
- Authentication methods ポリシーでモダンメソッドを優先
- Microsoft Authenticator（通知・コード）の有効化
- FIDO2 セキュリティキー／パスキーの有効化
- SMS／音声は原則「予備」に位置づけ、利用を最小限にする
- 電話番号は E.164 形式で登録
- 例：
+81 90xxxx....、+1 425xxxx.... - テナント内で電話番号がユニークになるよう管理する
- 例：
- ユーザーが MFA ブロック状態になっていないか定期確認
- 不正報告や誤操作でブロックされたユーザーを監視・解除
- サインインログ／Authentication methods Activity の継続監視
- 特定ユーザーや特定番号で SMS 失敗が急増していないかチェック
- 異常な再試行や特定地域への集中トラフィックを早期に検知
- 高リスク地域へのテレフォニー制限
- Telephony fraud 保護の「要申請地域」リストを参考に、不要な地域への SMS／音声を抑制
- 必要な地域のみ Microsoft サポートを通じて有効化する
- 一時アクセス パス（TAP）の活用
- 新規ユーザーの初回サインインや端末紛失時の救済に TAP を利用
- サインイン後に Authenticator／パスキーを必ず登録させる運用をセットで設計
- ブレイクグラス（緊急回復）アカウントの用意
- ごく少数の管理用アカウントを、強固なパスワード＋複数の MFA で保護
- これらには SMS／音声を使わず、Authenticator／FIDO2 のみを利用
- 利用ルールや定期的な動作確認手順を文書化
認証方法ごとの役割整理
最後に、代表的な認証方法を「役割」と「どの程度 SMS の代わりになりうるか」という観点で整理しておきます。
| 認証方法 | 主な用途 | SMS の代替度合い | コメント |
|---|---|---|---|
| Microsoft Authenticator（通知＋番号一致） | 日常的な MFA／パスワードレスサインイン | ◎（第一候補） | データ通信ベースで安定。フィッシング耐性が高く、Microsoft も最優先を推奨 |
| Microsoft Authenticator（OTP コード） | オフライン環境や通知が届かない場合 | ○ | 通知が使えないときのバックアップとして有効 |
| FIDO2 セキュリティキー／パスキー | 高セキュリティなパスワードレス認証 | ◎ | 物理キーやデバイス内の秘密鍵に基づく。管理者アカウントで特に推奨 |
| Temporary Access Pass（TAP） | 初回サインイン／ロックアウト時の救済 | △（一時的代替） | あくまで一時コード。TAP でサインイン後に Authenticator 等を必ず登録 |
| SMS／音声通話 | 最終手段の MFA／パスワードリセット | ▲（予備としてのみ） | テレフォニー詐欺や BadReputation の影響を受けやすいため、利用は最小限に |
よくある質問（FAQ）
Q1. エラー 399287 が出るのは一部ユーザーだけです。何を疑うべきですか？
まずは、そのユーザーのサインイン／認証方法ログを確認し、失敗しているメソッドが SMS／電話に集中しているか を確認してください。そのうえで、以下の可能性を検討します。
- そのユーザーの電話番号だけが BadReputation 判定になっている
- Authentication methods ポリシーで、SMS の対象グループから外れている
- ユーザーが MFA ブロック状態になっている
Q2. 管理者側で BadReputation を直接解除することはできますか？
いいえ、テナント管理者の画面から BadReputation を直接解除することはできません。サインインログや認証方法ログを添えて Microsoft サポートにチケットを起票し、エンジニアリングチームに解除を依頼 する必要があります。
Q3. SMS がブロックされているせいで、唯一の MFA 手段が使えず、ユーザーがログインできません。
このようなケースを防ぐためにも、日頃から 複数の MFA 手段 を登録しておくことが重要です。すでにロックアウトが発生している場合は、以下の対応を検討します。
- 管理者が Temporary Access Pass（TAP）を発行し、そのセッションで Authenticator／パスキー を登録させる
- 管理者がユーザーの認証方法をリセットし、別の認証方法を追加する
- どうしても解決できない場合は、Microsoft サポートにテナントオーナーとして連絡し、アカウント回復を依頼する
Q4. TAP を使うには追加のライセンスが必要ですか？
Temporary Access Pass 自体に追加料金はありませんが、利用するユーザーには Microsoft Entra ID Premium P1 相当のライセンスが必要とされています。P1 は単体で購入するほか、Microsoft 365 E3/E5 や Business Premium などのバンドルにも含まれます。
Q5. SMS サインイン（電話番号だけでサインインする機能）は安全ですか？
SMS サインインは、主に フロントラインワーカー向けに利便性を重視した機能 として位置付けられており、情報系ワーカーには推奨されていません。Microsoft も「Frontline workers を主な対象とし、それ以外には推奨しない」と明記しているため、一般的なオフィスワーカーには Authenticator／パスキー中心の構成を採用することをお勧めします。
まとめ：エラー 399287 をきっかけに認証設計を見直す
本記事で解説したポイントをまとめると、次のようになります。
- エラー 399287 は多くの場合、テレフォニー保護／PhoneReputation による SMS／電話認証メソッドのブロック が原因で発生する
- 原因切り分けでは、別メソッドでのサインイン可否・サインイン／認証方法ログ・電話番号形式・スロットリング・地域制限 を順番に確認する
- BadReputation などのバックエンドブロックは、Microsoft サポートへのエスカレーションとエンジニアリングによる解除 が必要になる
- 再発防止の本質は、SMS／音声への依存を最小化し、Microsoft Authenticator・パスキー・FIDO2 を中心としたモダン MFA に移行すること にある
- Temporary Access Pass やブレイクグラスアカウントを組み合わせることで、ロックアウト耐性の高い認証基盤 を構築できる
「エラー 399287 が出たから直す」という点対応で終わらせず、今回のインシデントをきっかけに テレフォニーに頼らない認証方法への移行 を進めることで、セキュリティ・安定性・運用コストのすべてを中長期的に改善できるはずです。
コメント