Azure ポータルや Microsoft 365 にサインインしようとしたとき、SMS による本人確認だけが要求され、送信ボタンを押した瞬間にエラー 399287 で失敗する──このパターンにはまると、管理者でも身動きが取れなくなりがちです。本記事では、この「Error Code: 399287」の正体と Microsoft へのアンブロック依頼の仕方、さらに再発させないための MFA 設計・運用のベストプラクティスまでを、実務目線で詳しくまとめます。
Azure サインインで発生するエラー 399287 の症状
まずは、実際にエラー 399287 が発生する典型的な状況を整理します。
- ユーザーが Azure ポータルや Microsoft 365、Entra ID の各種ポータルにサインインする
- パスワードまでは正しく通るが、「本人確認」の画面で SMS または音声通話のみが選択肢として表示される
- 電話番号は正しく登録されており、普段の通話や SMS には問題がない
- 「コードを送信」や「テキスト メッセージを送る」をクリックすると 即時に失敗し、「Sorry, we’re having trouble verifying your account.」のようなメッセージとともに
Error Code: 399287が表示される - 詳細を展開すると Request ID / Correlation ID / Timestamp が併記されている
この時点でユーザー側・キャリア側の通信に問題があるように見えますが、実際にはそうとは限りません。多くのケースでは、番号そのものが物理的に使えないのではなく、Microsoft 側の「Phone Reputation（電話番号の評判）」システムによりブロックされている可能性が高いことが分かっています。
エラー 399287 の正体：Phone Reputation による MFA ブロック
Microsoft Entra ID（旧 Azure AD）では、SMS や音声通話を使った MFA に対して、内部的に Phone Reputation という評価サービスを使っています。これは、攻撃や不正利用に悪用されやすい番号を自動的に検知し、MFA 用のコード送信をブロックするための仕組みです。
Microsoft Q&A やコミュニティでは、エラー 399287 について次のような説明がなされています。
- エラー 399287 は、「MFA メソッドがブロックされている（MFA method blocked）」「Phone reputation によりユーザーがブロックされている」状態を示す
- 番号自体が無効とは限らず、不正利用リスクが高いと判定されたために SMS／音声通話だけが遮断されているケースがある
- 最終的な復旧には、Microsoft のサポート／エンジニアリングによる バックエンド側のアンブロックが必要
Phone Reputation で「悪い評判（bad reputation）」が付く典型パターンとして、次のようなものが考えられます。
| 状況 | Phone Reputation が悪化しやすい理由 |
|---|---|
| VoIP 番号・共有番号を使用 | スパムや自動ダイヤルに使われやすく、不特定多数のユーザーに共有されるため、悪用履歴が付きやすい |
| 複数テナントで同一番号を登録 | 多数のテナントから同じ番号に大量の MFA トラフィックが流れ、不審なパターンとみなされることがある |
| 短時間で何度も SMS 認証を連続試行 | 攻撃者の総当たりに似た挙動となり、リスクが高いと判定される可能性がある |
| 海外プレミアム番号など特殊な番号 | IRSF（国際収益分配詐欺）などの電話系攻撃で悪用されるケースが多く、全体としてリスクが高い |
一度 Phone Reputation でブロックされると、ユーザー側で番号を変えたり再登録したりしてもすぐには解消しません。「同じ番号のまま何度やり直しても、SMS だけ永遠に届かない」という状態に陥るのはそのためです。
まずやるべきこと：サインインを復旧させる暫定対応
本質的な解決はアンブロック依頼と MFA 設計の見直しですが、まずは「ログインできない」状況を解消する必要があります。ここでは、エラー 399287 が出ているユーザーを いかに早くサインイン可能な状態に戻すかにフォーカスして解説します。
SMS 以外の認証方法が登録されている場合
ユーザーが既に以下のいずれかを登録している場合は、そちらを使ってサインインすることでひとまずポータルに入れます。
- Microsoft Authenticator アプリ（プッシュ通知／番号一致）
- Authenticator アプリの TOTP コード
- FIDO2 セキュリティキー
- プラットフォーム／クロスプラットフォームのパスキー
サインインに成功したら、次の対応を行います。
- ポータル右上のユーザーアイコンから「アカウント」または「マイ サインイン」に移動
- 「セキュリティ情報」「認証方法」画面で、Authenticator・FIDO2・パスキーを複数登録
- 「既定のサインイン方法」を Authenticator または FIDO2／パスキー に変更
- SMS／音声通話は「予備（バックアップ）」程度の位置付けにするか、不要であれば削除
この時点で、SMS が依然として 399287 で失敗し続けても、日常業務には支障が出ない状態を作れます。
別の全体管理者がいる場合：Temporary Access Pass を使う
ユーザーが SMS 以外の認証方法を持っておらず、かつテナント内に 別の全体管理者（Global Administrator） が存在する場合は、Temporary Access Pass（TAP） を使った復旧が最も安全で確実です。
TAP は、期限付きのワンタイム パスコードで、パスワードレスの認証手段を登録したり、紛失時の復旧に使える仕組みです。管理者は次のように操作します。
- Microsoft Entra 管理センターに 別の管理者アカウントでサインイン
- Entra ID > ユーザー > 対象ユーザー を開く
- 左メニューから 「認証方法」 を選択
- 「認証方法の追加」 をクリックし、「Temporary Access Pass」 を選択
- 有効期間と使用回数（単回／複数回）を設定して作成し、生成された TAP コードを安全な経路でユーザーに伝える
ユーザー側は、サインイン画面で「サインイン オプション」から TAP を使ってログインし、その直後に必ず以下を行います。
- Microsoft Authenticator を登録し、プッシュ通知＋番号一致を有効化
- 可能であれば FIDO2 セキュリティキー／パスキーも登録
- 既定のサインイン方法を Authenticator または FIDO2／パスキーに変更
こうすることで、SMS が Phone Reputation によってブロックされたままでも、再び同じ問題にはまりにくい構成にできます。
「管理者が一人しかいない」「管理者も入れない」場合
小規模テナントや検証用テナントでは、管理者アカウントが 1 つだけというケースも珍しくありません。このアカウントが SMS MFA で 399287 に詰まると、ポータルに入る手段が完全に失われます。
この場合は、迷わず Microsoft サポートに直接アンブロック依頼を行う必要があります。Microsoft Q&A では、サポート窓口での問題種別として次のように指定することが案内されています。
- Problem type（問題種別）：Identity → Multifactor Authentication
- Problem subtype（サブタイプ）：MFA method blocked / Phone reputation
併せて、電話によるサポート窓口（Global Customer Service phone numbers）経由でのエスカレーションも有効です。
Microsoft へのアンブロック依頼：伝えるべき情報
Phone Reputation によるブロックは、管理ポータル側から直接解除できません。サポート経由でバックエンドのエンジニアリング チームにエスカレーションし、対象番号の評判をクリアしてもらう必要があります。
サポート チケットを起票する際に、次の情報をセットで伝えると話が早くなります。
| 項目 | 内容 |
|---|---|
| テナント ID（Directory ID） | Entra ID の「概要」画面に表示される GUID |
| 対象ユーザーの UPN | 例：[email protected] |
| 電話番号（E.164 形式） | 国コードを含めた形式（例：+81xxxxxxxxxx） |
| エラー コード | 399287 |
| Request ID / Correlation ID / Timestamp | エラー詳細に表示される値をそのまま転記（Timestamp は UTC） |
| 発生したポータル | Azure ポータル、Microsoft 365 管理センター、My Sign-Ins など |
| 試行回数と期間 | 「同日に数回」「数日間で十数回」など、おおよその回数と期間 |
| 回線種別 | 携帯キャリア／固定回線／VoIP など（可能ならキャリア名も） |
これらの情報をもとに、サポート側で「Phone Reputation によるブロック」であるかどうかを確認し、必要に応じてエンジニアリング（PG チーム）にアンブロックを依頼してもらう流れになります。
サポート依頼文のサンプル
実際にサポートに送る文章は、次のようなイメージで作成するとよいでしょう（値は自分の環境に置き換えてください）。
件名：SMS 本人確認失敗（Error 399287）につき電話番号アンブロックのお願い テナント ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 対象ユーザー（UPN）：[email protected] 電話番号（E.164）：+81xxxxxxxxxx 発生時刻（UTC）：2025-08-18T05:43:14Z Error Code：399287 Request ID：0c9bff95-eb4a-4a1f-9fc6-7e7395c42700 Correlation ID：6a38d62e-d4e7-44a0-a371-dc4b85a3a7f1 事象： Azure ポータルへのサインイン時に SMS による本人確認が必要となるが、 「コードを送信」を押下すると即時に失敗し、Error Code: 399287 が表示されます。 同一番号で複数回再試行しましたが、SMS は一度も届いていません。 想定している原因： Phone Reputation により当該番号の SMS/音声通話による MFA がブロックされている可能性があります。 要望： ・当該電話番号のアンブロックおよび評判クリア ・再発防止策があればご教示ください 補足： ・VoIP ではない携帯電話番号です ・エラー発生後は追加の再試行を控えています
実際のやり取りでは、サポート側から追加のログや再現手順の確認が入ることもありますが、上記レベルの情報を最初から提示しておくと、エスカレーションまでがスムーズになります。
恒久対策：SMS／音声通話に依存しない MFA 設計へ
Phone Reputation によるブロックは、多くの場合一時的なものですが、根本的な問題は 「SMS を主要な MFA 手段として使っている」点にあります。Microsoft 自身も、SMS と音声通話による MFA は 「最も安全性が低い方法のひとつ」であり、Authenticator や FIDO2 などへの移行を推奨しています。
また、ゼロトラストおよび Secure Future Initiative の一環として、フィッシング耐性 MFA（FIDO2／パスキーなど）を広く採用することが目標として掲げられています。
認証方法ポリシーの見直し
Entra ID の「認証方法ポリシー」では、利用できる認証手段を細かく制御できます。
- 有効化を推奨する方法
- Microsoft Authenticator（プッシュ通知＋番号一致）
- FIDO2 セキュリティキー／パスキー
- OATH-TOTP（ハードウェア／ソフトウェア トークン）
- Temporary Access Pass（復旧用）
- 慎重に利用すべき方法
- SMS サインイン／SMS による MFA
- 音声通話
- メール OTP
実務的には、次のような構成がバランスよくおすすめです。
| 用途 | 推奨する認証方法 | SMS／音声通話の扱い |
|---|---|---|
| 通常ユーザー | Authenticator（プッシュ）、パスキー | 原則無効。どうしても必要な場合のみ限定的に許可 |
| 管理者・特権ロール | FIDO2／パスキー＋Authenticator の多重登録 | 無効化（バックアップにも使わない） |
| 来訪者・外部ユーザー | メール OTP、外部 IdP 連携など | 国や回線事情に応じて最小限に |
| ロックアウト時の復旧 | Temporary Access Pass | 使用しない |
条件付きアクセスと認証強度を組み合わせる
Entra ID の条件付きアクセスでは、「認証強度」を使って フィッシング耐性 MFA を必須とするポリシーを設定できます。たとえば次のような方針が考えられます。
- 重要な管理ポータル（Entra 管理センター、Azure ポータル、Azure DevOps など）には「フィッシング耐性 MFA」を必須化
- 一般社員向け SaaS には「中程度以上の認証強度（Authenticator／FIDO2 等）」を要求
- SMS のみでは満たせない認証強度にしておくことで、自然と SMS からの脱却を促す
運用手順と Runbook の整備
技術的な設定だけでなく、運用フローも合わせて整備しておくことが重要です。
- ロックアウト時の標準フローとして TAP による復旧を Runbook 化
- ユーザーが Authenticator／FIDO2 を失ったら、まず TAP を発行して再登録させる
- SMS は使わない・使わせない方針を明文化
- 全体管理者は必ず 2 人以上用意し、各自に 複数の強力な認証方法を登録させる
- テナントごとに「サインインできなくなったときの問い合わせ窓口」と「Microsoft サポートへのエスカレーション手順」を文書化
電話番号の「衛生管理」
どうしても SMS を残さざるを得ない場合でも、Phone Reputation が悪化しにくい使い方を心がけるべきです。
- E.164 形式で番号を登録する（例：
+81から始まる形式） - 出来る限り 携帯キャリアの個別番号を使い、共有番号や代表番号・VoIP 番号の利用は避ける
- ユーザーに対し、「SMS が届かないときに何度も連打しない」「複数デバイスで同時に試さない」ことを周知
- 異常を感じたら早い段階で管理者・サポートに相談し、むやみに再試行回数を増やさない
解除後に必ず行うべき確認ポイント
サポート対応により Phone Reputation がリセットされると、再び SMS が届くようになります。しかし、同じ使い方を続けていると再ブロックのリスクがあります。アンブロック後は、次のチェックリストで構成を見直しましょう。
| 確認項目 | チェック内容 |
|---|---|
| SMS 認証の動作確認 | 1～2 回だけテストし、成功することを確認（大量試行は避ける） |
| Authenticator／FIDO2／パスキーの登録 | 少なくとも 2 種類以上の認証方法が登録されているか |
| 既定の認証方法 | 「既定」が SMS／音声通話になっていないか確認 |
| 認証方法ポリシー | SMS が「必須」になっていないか、必要最小限に制限されているか |
| 条件付きアクセスの認証強度 | 管理ポータルなど重要シナリオでフィッシング耐性 MFA が必須になっているか |
| サインイン ログ | 同一ユーザー／同一番号での失敗が連続していないか、不審なパターンが残っていないか |
よくある誤解と避けるべき NG 対応
エラー 399287 に遭遇したとき、つい取ってしまいがちな「やらない方がいい対応」も整理しておきます。
ユーザー削除＆再作成で解決しないことが多い
Phone Reputation によるブロックは、電話番号に紐づく評価であり、ユーザー アカウントそのものに紐づいているわけではありません。そのため、ユーザーを削除して再作成しても、同じ番号を使う限り状況が変わらないことがほとんどです。
SMS の連打は逆効果
「たまたま電波が悪かったのかも」と考えて何度も SMS の送信ボタンを連打すると、かえって Phone Reputation が悪化するリスクがあります。複数のテナントやアカウントで同じ番号を使っている場合は、なおさら注意が必要です。
Auth 方法を片方だけに依存する構成
「Authenticator だけ」「SMS だけ」といった 単一の認証方法に依存した構成は、端末紛失や Phone Reputation ブロックなど、単一ポイント障害（SPOF）の原因になります。最低でも次の 2 つ以上を組み合わせておきましょう。
- Authenticator（プッシュと TOTP）
- FIDO2 セキュリティキー／パスキー
- OATH トークン
- Temporary Access Pass（復旧用）
小規模テナント・個人開発者が取るべき現実的プラン
開発用のテスト テナントや、個人事業レベルの Microsoft 365 環境では、「管理者が 1 人」「電話番号も 1 つだけ」というケースが多く、エラー 399287 は特に深刻です。そのような環境での現実的な対策をまとめます。
- 可能であれば 2 つ目の管理者アカウントを作り、別の端末／別の電話番号で Authenticator を登録
- 少なくとも 1 つの管理者アカウントでは FIDO2 セキュリティキーまたはパスキーを登録しておく
- 個人のスマートフォン 1 台だけに依存せず、予備デバイス（タブレットなど）にも Authenticator を登録しておく
- どうしても SMS を使う場合も、「最後の手段」と位置づけ、通常のサインインには使わない
こうした「多重化」を行っておけば、仮に Phone Reputation で 1 つの番号がブロックされても、別の認証手段でポータルに入って復旧作業を行うことができます。
なぜ今 SMS をやめるべきなのか
最後に、「なぜそこまで SMS を避けた方がよいのか」をもう少し踏み込んで整理しておきます。
- 通信経路の安全性の問題
- SMS／音声通話はもともと暗号化を前提として設計されておらず、さまざまな手段で盗聴・改ざんのリスクが指摘されています。
- 信頼性の問題
- 国やキャリアによっては、SMS の到達率が 50% 程度に落ち込む地域もあると報告されています。
- テレフォニー系攻撃（IRSF など）の温床
- 国際電話料金を悪用する詐欺や、自動発信のボットネットなど、電話番号を使った攻撃の対象になりやすい
- 攻撃者のツールが SMS 前提で進化している
- フィッシング キットやマルウェアの多くが SMS ベースの 2FA を前提としており、「2FA バイパス」が商品化されている
こうした背景から、Microsoft 自身も SMS／音声通話からの脱却と、Authenticator や FIDO2／パスキーへの移行を繰り返し推奨しています。エラー 399287 は、その方向転換を考えるきっかけととらえることもできます。
まとめ
- Error Code: 399287 は、多くのケースで Phone Reputation による SMS／音声通話 MFA のブロックを示している
- 番号自体が無効とは限らず、Microsoft の内部評価でリスクが高いと判断されたことで一時的に遮断される
- まずは Authenticator／FIDO2／パスキー、または Temporary Access Pass でサインインを復旧し、SMS に依存しない構成へ切り替える
- 根本的な解除には、Microsoft サポートへ テナント ID／UPN／電話番号／Request ID／Correlation ID／Timestamp を添えてアンブロック依頼を行う
- アンブロック後は、認証方法ポリシーや条件付きアクセス、運用フローを見直し、フィッシング耐性 MFA 中心の設計に移行する
- SMS はあくまでも「最後のバックアップ」程度にとどめ、可能な限り利用を縮小することが長期的な安定運用につながる
エラー 399287 に直面しているテナントでは、単に「SMS を復旧する」のではなく、この機会に MFA 全体の設計を見直し、より安全で運用しやすい認証アーキテクチャへとアップデートしていくことを強くおすすめします。
コメント