Azure ポータルや Microsoft 365 へのサインイン中に「Error Code: 399287」が表示され、SMS／音声通話のコード認証が完了しない――。本記事では、この現象の主因（MFA に登録された電話番号が悪質番号としてブロック）をわかりやすく解説し、現場で即実行できる復旧手順と、再発させないための設計・運用までを実務視点でまとめます。
Azure／Microsoft 365 サインイン時の「Error Code: 399287」徹底解説
「399287」は多要素認証（MFA）の電話番号方式（SMS または音声通話）が自動ブロックされた状態を示します。電話番号の“評判（Reputation）”が通信事業者や認証基盤の不正対策により悪化しているとき、認証コード送信そのものが止められ、ユーザーは認証ステップを完了できません。Request Id／Correlation Id／タイムスタンプは、裏側の検知ルールに一致して遮断された事実をたどるための手がかりです。
このエラーで表に出やすい症状
- SMS が届かない、または着信が鳴らない／すぐ切れる。
- 画面に Error Code: 399287 と表示され、戻っても同じステップでループする。
- 別のブラウザーやシークレット ウィンドウ、端末を変えても解消しない。
- サインイン ログ上は「MFA チャレンジ未完了」や「認証方法に到達できず」のような結果が続く。
なぜ電話番号がブロックされるのか（技術的背景）
近年、IRSF（International Revenue Share Fraud：国際通話不正）を含む音声系の不正が増加しています。攻撃者は盗まれたアカウントやボットを使って、特定の番号へ大量の発信・SMS 送信を誘導し、接続料の分け前を得ようとします。こうした濫用を抑止するため、番号の悪評化（スパム・詐欺の疑い）や異常トラフィックのパターンが検知されると、電話番号単位で一時的または持続的にブロックがかかります。本人に悪意がなくても、過去にその番号が使われていた・再販された・転送設定で疑わしい網を経由している等の要因で巻き添えが発生します。
まず最初に確認する 4 点（管理者・サポート用チェックリスト）
- 対象ユーザーの MFA 登録方法：電話番号のみなのか、Authenticator／パスキー／FIDO2 など他方式が併用されているか。
- 番号の属性：個人携帯か代表番号か、内線転送・クラウド PBX・050/0AB〜J の IP 電話か、海外 SIM か。
- 最近の変更：番号変更、キャリア乗り換え、留守電／転送設定、海外渡航、SMS 受信拒否設定、迷惑電話フィルター。
- ログ情報：Request Id／Correlation Id／発生時刻（UTC）／ユーザー名／テナント ID（GUID）。
この 4 点がそろうと、ブロックの切り分けと解除依頼がスムーズです。特に時刻はUTCで控えておくと解析が確実になります。
原因と復旧の要点（早見表）
| 手順 | 目的／内容 | 必要権限 | 補足・注意 |
|---|---|---|---|
| ① 原因の把握 | エラー 399287 は電話番号の悪評化に伴う MFA ブロックが主因。 | 閲覧権限（監査ログ・サインイン ログ） | SMS／音声が一切届かない傾向。ほかの方式があれば暫定ログイン可能。 |
| ② 管理者による解除 | 別の 全体管理者（Global Administrator） または Privileged Authentication Administrator が対象ユーザーの MFA 再登録またはブロック解除を実施。 | GA / PAA / Authentication Policy Administrator | Microsoft Entra 管理センター（旧 Azure AD）で「ユーザー > 認証方法」から操作。 |
| ③ サポート依頼 | 自分が唯一の管理者で解除できない／解除後も届かない場合は Microsoft サポートへ非公開で依頼（メール・電話・サポート チケット）。 | テナントのサポート連絡権限 | メールアドレス／電話番号／テナント ID／国名・国番号／エラー画面のキャプチャ／Request Id／Correlation Id／UTC 時刻を提出。 |
| ④ 動作確認 | 解除後に SMS／音声コード受信→入力→サインインが可能か検証。 | ユーザー | 改善しないときはキャッシュ削除・別ブラウザー・端末変更・機内モード ON/OFF で再試行。 |
| ⑤ 再発防止 | 電話番号依存を減らし、Microsoft Authenticator（プッシュ＋番号一致）やパスキー／FIDO2へ移行。SMS／音声は予備に。 | GA / セキュリティ管理者 | 条件付きアクセスで電話ベースの MFA を主経路にしない設計に。登録方法の冗長化も必須。 |
管理者 UI での具体的な操作手順（Microsoft Entra ID）
以下は一般的な UI 名称です。テナントの表示名やロールアウト状況により文言が一部異なる場合があります。
対象ユーザーの MFA 再登録を強制する
- 管理者アカウントで Microsoft Entra 管理センターにサインイン。
- ユーザー → 対象ユーザーを選択。
- 認証方法（Authentication methods） を開き、再登録を必要とする（Require re-register MFA） を実行。
- ユーザーにいったんサインアウトを指示し、次回サインインで新しい方法（Authenticator／パスキー等）を登録してもらう。
電話番号のブロック解除（通話／SMS が止まっている場合）
- 対象ユーザーの 認証方法 にある 電話 を確認。
- 「ブロック」の状態が有効なら解除。電話の方式をいったん削除し、新しい電話番号として再登録してから試行するのも有効です。
- 暫定措置として Authenticator の一時パスワード（TAP: Temporary Access Pass）を発行し、ユーザーが自力で Authenticator／パスキーを追加できる導線を整備。
権限の目安：全体管理者（Global Administrator）、Privileged Authentication Administrator、Authentication Policy Administrator のいずれかがあれば多くの操作が可能です。
Microsoft サポートへ依頼する際のポイント（自分が唯一の管理者・解除不能時）
ユーザー自身が唯一の管理者でロックアウトされた、もしくは UI で再登録してもブロックが解けない・SMS が届かない場合は、個人情報を公開せず、プライベート チャネルでサポートへ依頼します。提出すべき最低限の情報は以下です。
- 影響ユーザーの メールアドレス（UPN）
- 電話番号（国番号を含む国際表記）
- テナント ID（GUID）
- 国名／国番号
- Request Id／Correlation Id／発生時刻（UTC）
- エラーが見える 画面キャプチャ
上記がそろっていれば、バックエンドでのブロック解除や到達性チェックが迅速です。公開フォーラムやコミュニティへの投稿は厳禁です。
依頼時に使えるテンプレート（コピペ可）
件名：MFA 電話番号ブロックによる Error 399287 の解除依頼
テナント ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
ユーザー UPN：[[email protected]](mailto:[email protected])
電話番号（E.164）：+81xxxxxxxxxx
国名・国番号：Japan / +81
発生時刻（UTC）：2025-11-05T02:10:30Z
Request Id：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Correlation Id：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
現象：MFA で SMS/音声が届かず Error Code: 399287 が表示。別ブラウザー・端末でも再現。
希望：番号のブロック解除または到達性の確認、必要に応じて追加情報提示可。 解除後の確認・運用のコツ
- 5〜10 分ほど間隔を空けてから再試行（キャッシュや一時的スロットリングの影響を避ける）。
- ブラウザーのCookie／サイトデータ消去、別プロファイルや InPrivate で検証。
- 携帯側の迷惑メッセージフィルター・SMS 拒否設定・着信拒否・機内モードなどを確認。
- 可能であれば別の通信回線（Wi‑Fi／モバイル）でテスト。
- 暫定的にAuthenticator を主方法として登録し、SMS／音声の再開を待つ。
ログで原因を追跡する（監査・可観測性）
サインイン ログ（Log Analytics にエクスポートしている場合）
// 399287 に該当するサインインを直近 7 日で抽出
SigninLogs
| where TimeGenerated > ago(7d)
| where tostring(Status.errorCode) == "399287"
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, Status, ConditionalAccessStatus
| order by TimeGenerated desc
Microsoft Graph API での調査例
# PowerShell（Microsoft Graph SDK）例
Connect-MgGraph -Scopes "AuditLog.Read.All","User.Read.All"
$from = (Get-Date).AddDays(-7).ToString("o")
$filter = "createdDateTime ge $from and status/errorCode eq 399287"
Get-MgAuditLogSignIn -Filter $filter -All |
Select-Object createdDateTime, userPrincipalName, status |
Sort-Object createdDateTime -Descending
ログの時刻は UTC で扱われます。ユーザー報告時刻（ローカル）とのずれに注意しましょう。
電話番号に依存しない MFA 設計（再発防止の実践）
SMS／音声通話はユーザー体験は簡単ですが、IRSF や番号評判に左右されやすく、また SIM スワップや SS7 の脆弱性などセキュリティ面でも相対的に弱い方式です。以下の順でより強い認証へ移行するのが定石です。
| 方式 | 推奨度 | ポイント | 運用のコツ |
|---|---|---|---|
| Microsoft Authenticator（プッシュ＋番号一致） | 高 | 通知の承認に加え、画面の数字一致で中間者攻撃・誤承認を抑止。 | 初期登録を TAP でブートストラップ。業務端末必須化も検討。 |
| パスキー（Passkey）／FIDO2 セキュリティキー | 最高 | フィッシング耐性。ユーザー所持＋生体要素で UX と強度を両立。 | 紛失時の代替経路を整備（TAP／Break‑Glass／補助キー）。 |
| SMS／音声（電話ベース） | 中〜低 | 導入が容易だが攻撃面と可用性に弱点。 | 主経路にしない。緊急時のバックアップ用途に限定。 |
条件付きアクセスの例（方針）
- 重要アプリは Authenticator または FIDO2/パスキー必須。
- 電話ベース MFA のみのユーザーは登録フローへ誘導（ブロックではなくリダイレクト）。
- リスクが高いサインイン（匿名 IP／海外）のときは 強い方式を追加要求。
登録・復旧の運用設計
- 二経路以上の認証方法を標準化（Authenticator＋FIDO2、Authenticator＋SMS など）。
- 緊急管理者（Break‑Glass）を最低 2 アカウント用意し、条件付きアクセスから除外して厳重保管。
- Temporary Access Pass（TAP）を有効化し、紛失時のセルフリカバリーを簡便に。
- 番号変更・解約時のオフボーディング手順を定義（在籍中に再登録完了）。
よくある落とし穴と対策
- 代表番号・内線転送を MFA に使う：IVR／転送網で遅延・着信拒否・スコア悪化。個人直通の携帯番号か、そもそも Authenticator/FIDO2 に移行。
- 海外出張中のローミング：現地キャリアのスパムフィルターで SMS が遅延・欠落。出張前にオフラインでも使える FIDO2 を配布。
- 仮想番号（050／クラウド PBX）：一部網での到達性が不安定。認証では極力使用しない。
- 1 方式しか登録していない：紛失・故障で即ロックアウト。二経路以上を標準要件に。
- 唯一の管理者がロックアウト：テナント全体が止まるリスク。管理者は最低 2 名以上＋Break‑Glass。
現場対応フロー（テキスト図）
[ユーザー] Error 399287 を報告
|
v
[一次切り分け] 他方式での暫定ログイン可否 / Authenticator 登録有無
|
+-- 可：ログイン後に Authenticator/FIDO2 を追加、電話は予備へ格下げ
|
+-- 不可：
|
v
[管理者] Entra で「再登録を必要とする」→ TAP 発行 → 登録ガイド
|
+-- 改善：完了
|
+-- 未改善：番号削除→再登録 / 別番号で試験
|
+-- なお不可：Request/Correlation Id を添えてサポートへ
ユーザー向けの案内文（社内ヘルプデスク用サンプル）
件名：サインイン時の認証エラー（399287）について
現在、電話番号に起因するセキュリティブロックにより SMS/音声の認証が停止しています。
当面は Microsoft Authenticator（スマホアプリ）または配布済みのセキュリティキーでの
サインインをご利用ください。未登録の方には IT から一時パス（TAP）を発行し、
初回登録のご案内をお送りします。電話番号方式は予備として継続提供しますが、
主方式は Authenticator／パスキーへ段階的に移行します。 トラブルシュート補足（改善しない時の着眼点）
- 端末設定：SMS 受信拒否、ショートメッセージサービスセンター番号（SMSC）の設定、迷惑電話設定。
- キャリア側要因：海外からの SMS を遮断していないか、国際 SMS 受信可否。
- アプリ競合：着信制御アプリ（迷惑電話ブロッカー）が阻害していないか。
- 番号の再割り当て：他者から回ってきた番号の場合、旧評判の影響が残ることがあるため、別番号への切替で改善することが多い。
- IP アドレス・場所の急変：高リスク判定により追加要素が求められる。強い方式（FIDO2 等）を用意。
セキュリティ＆ガバナンスのベストプラクティス
- 登録ガバナンス：新入社員は初日に Authenticator＋FIDO2 を登録。SMS は予備。
- 運用 KPI：電話のみ MFA のユーザー比率、TAP での復旧件数、登録完了までの日数を継続監視。
- 教育：「番号一致」（画面に出た数字をアプリ側で入力）を周知し、誤承認を削減。
- 監査：月次でサインイン ログをレビューし、同一番号への大量試行や海外同時ログインを点検。
Q&A
Q. 399287 は必ず電話番号ブロックを意味しますか？
実務上は電話ベース MFA が到達不能・ブロックであるケースが大半です。例外的に、同時期に条件付きアクセスやリスクベース ポリシー変更があり、別要因で止まっているように見えるときもあります。ログと UI の状態（認証方法・ブロック欄）を併読しましょう。
Q. 電話番号を変えると直りますか？
多くのケースで改善します。企業の代表番号や転送番号は避け、本人直通の番号を登録してください。とはいえ根本対策は「電話に依存しない設計」です。
Q. 管理者が 1 人しかおらず入れない時は？
Microsoft サポートに非公開で連絡し、Request Id／Correlation Id 等を提示して解除を依頼します。復旧後は管理者の冗長化と Break‑Glass を必ず整備しましょう。
Q. ユーザー体験を落とさずに強い MFA に移れますか？
はい。Authenticator のプッシュ通知＋番号一致は学習コストが低く、FIDO2/パスキーは初回セットアップさえ整えれば日常運用はむしろ快適です。TAP を活用した段階的移行が現場では成功しやすいです。
まとめ（要点のおさらい）
- エラー 399287は、電話番号の悪評化による MFA ブロックが主因。
- 解除は 管理者の再登録・ブロック解除またはMicrosoft サポートへの個別依頼で対応。
- 復旧後はAuthenticator／パスキー／FIDO2 を主方式に、SMS／音声は予備へ。
- ログ（Request Id／Correlation Id／UTC 時刻）を整えておくと、解析・解除が速い。
- 組織として二経路以上の認証・管理者冗長化・TAP・Break‑Glassを整えて再発と不正リスクを最小化。
付録：管理者のためのチェックリスト
| 項目 | 状態 | メモ |
|---|---|---|
| 影響ユーザーの他方式（Authenticator/FIDO2） | □ あり／□ なし | |
| 認証方法の再登録（Require re-register MFA） | □ 実施 | |
| 電話方式のブロック解除／番号再登録 | □ 実施 | |
| Temporary Access Pass の発行 | □ 実施 | |
| サインイン ログの確認（UTC・Id 収集） | □ 実施 | |
| サポート依頼（非公開チャネル） | □ 実施 | |
| 条件付きアクセスの見直し（電話主経路の排除） | □ 済 | |
| 管理者冗長化／Break‑Glass 整備 | □ 済 |
コメント