Microsoft 365 / Microsoft Entra ID へのサインイン時に、SMS 本人確認で「Error Code: 399287」が出て先に進めないケースが急増しています。本記事では、このエラーの正体（電話番号の悪評判・バックエンドブロック）と、ユーザー／管理者それぞれの復旧手順、さらに二度と同じトラブルで「詰み」にならないための設計・運用のポイントまでを具体的に解説します。
M365 / Microsoft Entra ID で発生する SMS 本人確認エラー「399287」とは
まずは、今回の事象を整理します。典型的には次のような流れです。
- Microsoft 365 / Microsoft Entra ID にサインインする
- 多要素認証で「電話での確認（SMS／音声）」を選択する
- SMS コードを送信しようとすると、次のメッセージが表示される
- 「アカウントの確認に問題が発生しました。もう一度お試しください。」（Error Code: 399287）
- 何度やり直しても同じエラーになり、本人確認が完了せずサインインできない
- 別のブラウザ／端末／ネットワークやパスワードリセットを試しても状況は変わらず、完全にロックアウトしてしまう
質問サイトや Microsoft Q&A でも、同様の問い合わせが 2025 年に入ってから急増しており、特定の電話番号やアカウントでのみ発生するケースが多く報告されています。
| 観測される症状 | よくある状況 |
|---|---|
| SMS 認証を選ぶと必ず Error 399287 | Authenticator 未登録、または旧スマホ故障で利用不能 |
| パスワード変更しても改善しない | 本人確認ステップで詰まり、どのポータルにも入れない |
| 別ユーザーや別テナントでは正常 | 特定ユーザー／特定電話番号のみ影響 |
| ユーザーがサポートチケットを作れない | サインインできず管理センターにアクセスできない |
結論：Error 399287 は「PhoneReputation（電話番号の悪評判）」によるブロックが濃厚
公開情報や複数の事例から、Error Code: 399287 は Microsoft Entra の PhoneReputation サービスによる MFA ブロックと関連づけられています。Stack Overflow などでも、「PhoneReputation MFA Block」という内部名で説明されており、不正利用の疑いがある電話番号に対して SMS 認証を拒否する仕組みだと示唆されています。
さらに、Microsoft は公式ドキュメントの中で、テレフォニー（SMS／音声）ベースの認証について、IRSF（International Revenue Share Fraud：国際収益分配詐欺）などのテレフォニー不正に対抗するために、リスクの高い番号やトラフィックを自動検出してブロック／スロットリング（制限）することを明言しています。
また、Microsoft Q&A では複数のスレッドで、
- SMS／音声による MFA は IRSF に弱く、Authenticator アプリを推奨している
- 不正対策として、一部の電話番号や発信経路が「悪評判（Bad Reputation）」扱いになり、通信がブロックされることがある
といった回答が繰り返し示されています。
つまり、Error 399287 が出ている場合、ユーザーの操作ミスやブラウザの不具合ではなく、
- 電話番号・発信経路そのものが「危険な発信源」と判定されている
- Microsoft 側の防御機構により、SMS 本人確認がそもそも試行できない状態
である可能性が非常に高い、ということです。
| ブロックされうる対象 | 具体例 |
|---|---|
| 電話番号 | IRSF 攻撃の踏み台に使われた番号、短時間に大量の OTP 試行があった番号 |
| 発信地域・国番号 | 特定の国・地域からの異常な通信量が検出された場合の一時的制限 |
| ユーザー／テナント | 同一アカウントの認証試行が機械的・自動的と判断されたケース |
このフラグは、通常の管理ポータルや PowerShell では直接解除できません。そのため、ユーザー側でできることと、管理者・Microsoft サポート側で行うべきことを切り分けて考える必要があります。
ユーザーがまず試すべきこと：自助でできる確認ポイント
完全に「詰み」と決めつける前に、ユーザー自身で確認すべきポイントを整理します。ここを確認してもなおダメなら、管理者やサポートへのエスカレーションを検討します。
別の認証方法が登録済みならそちらを使う
まず、SMS 以外の MFA 手段が登録されていないかを確認します。たとえば次のようなメソッドです。
- Microsoft Authenticator アプリ（プッシュ通知／ワンタイムパスコード）
- 別の電話番号（SMS／音声）
- FIDO2 セキュリティキー（YubiKey など）
- ハードウェアトークン（組織が配布している場合）
サインイン画面で「別の方法でサインイン」リンクが表示される場合は、そこから他のメソッドを選択できないか確認してください。Authenticator や FIDO2 でサインインできるのであれば、ひとまず業務継続を優先し、後から電話番号の見直しや再登録を行うのが良いです。
SMS 受信環境のセルフチェック
電話番号や端末側の問題で SMS が届いていないだけ、という可能性もゼロではありません。次の観点を短時間で確認しましょう。
| チェック項目 | 具体的な確認内容 |
|---|---|
| 電話番号の形式 | 国番号を含む E.164 形式（例：+81 90xxxx…）で登録されているか。 先頭の 0 をそのまま入れていないか（例：+81090… などの誤登録） |
| 端末の状態 | 機内モードになっていないか、圏外やローミング制限がかかっていないか。 SMS 拒否設定・迷惑メッセージフィルタで国際 SMS がブロックされていないか。 |
| キャリア側の制限 | 国際 SMS を拒否する設定になっていないか。 法人契約の場合は、回線管理者が特定の番号をブロックしていないか。 |
| サインイン環境 | 別ブラウザ（Edge/Chrome/Firefox）やシークレットウィンドウで再試行。 他のネットワーク（自宅 Wi‑Fi／モバイル回線／会社回線）から試してみる。 |
ただし、SMS が「届いている」のに Error 399287 が表示される場合は、電話番号の評判やバックエンドブロックの可能性が一層高くなります。
完全に詰まった場合は管理者に「MFA リセット」または「TAP 発行」を依頼
Authenticator など他の手段もなく、SMS も 399287 で通らない場合、ユーザー単独では解決できません。この場合は、組織の管理者（全体管理者／特権ロール管理者など）に、次のいずれかを依頼します。
- MFA のリセット（登録済み認証方法のクリアと再登録要求）
- Temporary Access Pass（TAP：一時アクセス パス）の発行
管理者が別アカウントでサインインできるのであれば、ユーザー自身は一切の認証が通らなくても復旧の糸口を作ることが可能です。
管理者向け：Microsoft Entra 管理センターでの復旧フロー
ここからは、Microsoft Entra ID の管理者が取るべき実務的なステップを解説します。ポイントは、
- まずサインインログで「本当に 399287 が出ているか」を事実確認する
- ユーザーの認証方法を整理し、非テレフォニー系（Authenticator／FIDO2）を優先するように再設計する
- 必要に応じて TAP を発行し、ロックアウトしたユーザーに再登録してもらう
サインインログで Error 399287 を確認する
管理者は、Entra 管理センターから対象ユーザーのサインインログを確認できます。
- Microsoft Entra 管理センターにサインイン
- 「Microsoft Entra ID」 > 「サインイン」を開く
- ユーザー名やアプリケーションでフィルターし、該当するサインイン失敗イベントを確認
- 詳細ビューで、エラーコード（399287）／メッセージ／タイムスタンプ／Request ID／Correlation ID を控える
ここで 399287 が継続的に発生していることが確認できれば、PhoneReputation ブロックの裏付け材料になります。サポートにエスカレーションする際にも、この情報が必須となります。
認証方法のリセットと再登録要求
次に、該当ユーザーの認証方法（Authentication methods）を見直します。
- Entra 管理センター > 「ユーザー」から対象ユーザーを開く
- 「認証方法」を選択
- 必要に応じて、登録済みの電話番号メソッド（SMS／音声）を削除する
- 「再登録を要求」を有効にし、ユーザーに再登録を促す
ただし、ユーザーがすでにロックアウトしている場合、単に「再登録を要求」するだけではログインまで到達できません。そのため、次のステップとして TAP を利用した一時サインイン経路を提供します。
Temporary Access Pass（TAP）で一時的にサインインさせる
TAP（Temporary Access Pass）は、認証アプリや FIDO2 を紛失したユーザーに対して、管理者が一時的なログインコードを払い出す仕組みです。利用イメージは次のとおりです。
- 管理者が対象ユーザーの「一時アクセス パス」を発行
- ユーザーに安全な経路で TAP を伝達
- ユーザーは TAP でサインインし、Authenticator や FIDO2 を再登録
- 登録が完了したら、TAP は短時間で無効化（使い捨て）する
このフローにより、電話番号そのものがブロックされている状況でも、Authenticator などの非テレフォニー系認証へ移行できます。
認証方法ポリシーの見直し：SMS を「主役」から「予備」へ
復旧作業と並行して、テナント全体の認証方法ポリシーを見直すことを強くおすすめします。
- 既定（推奨）の方法を Authenticator / FIDO2 に設定
- SMS／音声通話は「予備」「緊急用」の位置づけに変更
- 条件付きアクセスで、「信頼された場所・デバイス」からの初回登録を許可する
Microsoft 自身も、テレフォニー MFA のリスクと IRSF への脆弱性から、Authenticator などアプリベースの MFA を推奨しています。
Microsoft サポートへのエスカレーション：バックエンドブロック解除を依頼する
ここまでの対処を行っても、特定の電話番号でのみ 399287 が解消しない場合、Microsoft 側のバックエンドで PhoneReputation／テレフォニーブロックがかかっている可能性が濃厚です。この場合、管理者や販社から Microsoft へサポートチケットを起票し、ブロック解除を依頼します。
ポイントは、ロックアウトしている本人以外の管理者アカウントでチケットを作ることです。M365 テナントには、原則として複数の全体管理者／ブレークグラスアカウントを用意しておくべきであり、今回のような事態でその価値が発揮されます。
サポートへ伝えるべき情報一覧
調査をスムーズに進めてもらうためには、最初の問い合わせで可能な限り情報を渡すことが重要です。次のような項目をテンプレート化しておくと便利です。
| 項目 | 内容 |
|---|---|
| 事象 | SMS 本人確認で Error Code: 399287 が表示され、サインインできない |
| 影響範囲 | ユーザー名（UPN）／影響ユーザー数／テナント ID |
| 発生日時 | UTC とローカルタイム（JST など）両方で、YYYY‑MM‑DD HH:MM:SS 形式 |
| 技術情報 | Request ID / Correlation ID（サインインログまたはエラー画面から取得） |
| 電話番号情報 | 国番号付き（E.164）形式、国／地域、キャリア種別（携帯／固定／仮想番号） |
| 試した対処 | ブラウザ変更・ネットワーク変更・パスワードリセット・MFA リセットなど |
| 最近の変更 | 条件付きアクセス、認証方法ポリシー、番号変更などの有無 |
問い合わせ文の例
問い合わせ内容は、次のような形でまとめると伝わりやすくなります（必要に応じて翻訳し、英語で送付するとよりスムーズなこともあります）。
件名：SMS 本人確認で Error Code: 399287 が発生しサインインできない（PhoneReputation / Bad Reputation 解除のお願い） ・テナント ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ・影響ユーザー UPN：[email protected] ・影響ユーザー数：1 名（または複数名ならその旨記載） ・発生日時（UTC）：2025-xx-xx xx:xx:xx ・エラー表示：Error Code: 399287 「アカウントの確認に問題が発生しました。」 ・Request ID / Correlation ID：サインインログから取得した値 ・対象電話番号（E.164）：+81xxxxxxxxxx（携帯 / 固定 / 仮想番号） ・試した対処：MFA リセット、ブラウザ変更、ネットワーク変更、パスワード変更 など ・結果：上記対処でも SMS 本人確認のみ継続的に Error 399287 が発生 ・お願い：当該電話番号またはアカウントに付与されている PhoneReputation / Bad Reputation / テレフォニーブロックの有無を確認し、 正当なユーザーであればブロック解除をご検討いただきたい
このように、「ブロック解除してほしい」ではなく「具体的なエラーコードと技術情報を添えて調査依頼をする」形にすると、サポート側も原因にたどり着きやすくなります。
よくある原因と切り分けのポイント
Error 399287 の根本原因は「電話番号／発信経路の評判が悪化した結果のブロック」であることが多いのですが、その背景には様々な要因が絡んでいます。代表的なものを表に整理します。
| 原因カテゴリ | 具体例 | 切り分けの視点 | 対処の方向性 |
|---|---|---|---|
| テレフォニー詐欺・IRSF 疑い | 短時間に大量の認証試行、海外回線経由での異常トラフィック | 他ユーザーや他電話番号では正常か、同地域で多発していないか | Microsoft に調査依頼し、ブロック解除を検討。テレフォニー MFA の利用を最小化。 |
| 電話番号形式の誤り | 国番号抜け、先頭 0 の扱いミス、E.164 形式でない登録 | Azure AD 上の登録番号と実際の番号が一致しているか | 正しい形式で再登録。ユーザー教育資料にも E.164 形式を明記。 |
| キャリア側のフィルタ | 国際 SMS の遮断、迷惑メッセージ判定、法人契約のフィルタリング | 同じ番号で他サービスの SMS は届くか、別回線ではどうか | キャリアに問い合わせ、国際 SMS の許可設定を確認。必要に応じて回線変更。 |
| ユーザー登録情報の不整合 | 古い電話番号が残存、別ユーザーとの番号共有／重複登録 | 管理センターで当該番号が複数ユーザーに紐づいていないか | 不要な登録を削除し、ユーザー単位で一意な番号に整理。 |
| 条件付きアクセス／リスクベースポリシー | 初回登録や回復手順が、場所／デバイス条件によりブロックされる | サインインログにリスク判定や CA による拒否が出ていないか | 初期登録／復旧用の例外ポリシーを設計し、TAP 経由で登録させる。 |
予防策・ベストプラクティス：次に同じトラブルを起こさないために
Error 399287 を一度踏んでしまったら、「復旧して終わり」ではなく、必ず設計と運用を見直すことが重要です。ここでは、実務で役立つベストプラクティスをまとめます。
認証方法は最低 2 つ以上を標準とする
「Authenticator だけ」「SMS だけ」といった単一手段は、どれほど強固な認証方式であっても、紛失・障害で即ロックアウトにつながります。最低限、次のような組み合わせを標準とするのがおすすめです。
- Microsoft Authenticator（プッシュ通知＋ワンタイムコード）
- FIDO2 セキュリティキー（物理トークン）
- バックアップ用電話番号（できれば別キャリア）
特に管理者アカウントについては、Authenticator ＋ FIDO2 ＋ 別端末のように、異なる種類の MFA 手段を 2 つ以上登録しておくことが望ましいです。
ブレークグラスアカウントを 2 つ用意する
テナント全体がロックアウトする最悪の事態に備え、MFA を適用しないブレークグラスアカウントを 2 つ以上用意しておきましょう。
- 強力で長いパスワード（パスフレーズ）を設定し、厳重に保管する
- 条件付きアクセスで「特定の固定 IP 以外からはサインイン不可」にする
- 通常業務では一切使用せず、監査ログで利用を常にチェックする
このブレークグラスアカウントがあることで、本記事のように特定管理者がロックアウトしていても、別経路でサポートチケットを起票し、TAP を発行することが可能になります。
TAP（Temporary Access Pass）の運用ルールを決めておく
TAP は非常に強力な復旧手段ですが、運用ルールが曖昧だとセキュリティリスクにもなり得ます。あらかじめ次のようなルールを決めておきましょう。
- 発行権限を持つロール（全体管理者／認証管理者など）を明確にする
- 有効期限は短め（例：60 分以内）、使用回数は 1 回のみを基本とする
- 発行・利用状況を定期的に監査し、不正利用がないか確認する
- ユーザー向けマニュアルに「TAP でサインインしたら、即座に Authenticator と FIDO2 を登録する」と明記する
テレフォニー依存の最小化：SMS／音声は「非常用」に格下げ
Microsoft が繰り返し述べている通り、SMS／音声通話による MFA は IRSF をはじめとするテレフォニー詐欺に弱く、アプリベースの MFA よりもセキュリティリスクが高いとされています。
そこで、認証方式を次のような優先度に再設計することを推奨します。
| 認証方式 | セキュリティ | 利便性 | 推奨度 | 備考 |
|---|---|---|---|---|
| Authenticator（プッシュ＋コード） | 高 | 高 | ◎ メイン推奨 | 番号一致・デバイス登録を併用すると安全性さらに向上 |
| FIDO2 セキュリティキー | 非常に高 | 中 | ◎ 管理者・高リスクユーザー向けに推奨 | 物理キー紛失リスクに注意（予備キーを用意） |
| SMS／音声通話 | 中〜低 | 中 | △ 非常用／バックアップ用途 | IRSF・スパム・電話番号の評判に依存する |
電話番号・国コードの棚卸しと更新プロセス
電話番号が古いまま放置されていると、退職者の番号や解約済み番号に SMS が飛び続ける原因になり、最悪の場合は第三者にコードが届くリスクもあります。次のような運用を検討しましょう。
- 年に 1 回程度、全ユーザーの認証方法を棚卸しし、不要な番号や古い端末情報を削除する
- 人事異動・退職・端末変更時には、アカウント運用チェックリストの中に「認証方法の更新」を組み込む
- 共有電話番号（代表番号など）を MFA に使わないポリシーを明文化する
ユーザー教育：ロックアウト時の連絡先とセルフチェック手順を周知
最後に、ユーザー教育も重要です。次のような内容をイントラネットやマニュアルにまとめておくと、現場での混乱を大きく減らせます。
- 「SMS が届かない／Error 399287 になったときのセルフチェック 3 ステップ」
- ロックアウト時に連絡すべき窓口（ヘルプデスクや IT 管理者）の連絡先
- Authenticator のバックアップ／複数端末登録の方法
- 復旧手順（TAP 利用など）の簡易フロー図
こうした情報が事前に共有されているだけで、ユーザーは焦らずに状況を説明でき、管理者もスムーズに切り分けと対応を行えます。
まとめ：Error 399287 で「詰まない」テナント設計へ
本記事で見てきたように、Microsoft 365 / Entra ID での Error Code: 399287 は、多くの場合ユーザーやブラウザの問題ではなく、Microsoft 側の不正対策（PhoneReputation／テレフォニーブロック）が働いた結果です。
復旧までの大まかな流れを改めて整理すると、次のようになります。
- ユーザー側で別の認証方法や SMS 受信環境を確認（簡易セルフチェック）
- 管理者がサインインログで 399287 を確認し、MFA リセットや TAP 発行で一時的なサインインを確保
- ユーザーに Authenticator / FIDO2 を再登録させ、SMS 依存から脱却する
- 必要に応じて、別管理者アカウントや販社経由で Microsoft サポートにエスカレーションし、PhoneReputation / テレフォニーブロックの解除を依頼
- 復旧後は、認証方法ポリシー・ブレークグラスアカウント・TAP 運用・ユーザー教育を見直し、「次に同じエラーが出ても詰まない」設計にする
結論： Error 399287 は、Microsoft 側のバックエンドブロック解除＋テレフォニー依存からの脱却によって根本的に解決できます。Authenticator を主軸とし、TAP や複数の認証手段を組み合わせることで、組織全体としての耐障害性とセキュリティを同時に高めていきましょう。
コメント