Microsoft Entra ID（旧 Azure AD）でグローバル管理者が SMS 多要素認証（MFA）でサインインしようとすると「399287：電話番号の評価が悪い」のエラーで拒否される――本稿はこの非常時の実務対応を、復旧手順から安全な認証方式への移行、再発防止の設計指針まで、現場でそのまま使える形でまとめたガイドです。
目次
状況と課題の整理：エラー 399287 と Authenticator 復元失敗
次のような流れで障害が発生します。
- スマートフォンの機種変更やアプリ再インストール後、Microsoft Authenticator のクラウドバックアップから組織アカウントの MFA 設定が復元されない。
- 代替手段として SMS を選択すると、サインイン画面でエラー 399287（電話番号が「悪い評価」＝poor reputation と判定）によりワンタイムコード送信がブロックされる。
- 結果として、グローバル管理者でテナントに入れない状態に陥る。
このエラーは、テレコム詐欺対策（IRSF＝International Revenue Share Fraud、SIM スワップ、番号スパム濫用など）に基づき、SMS 送信先の電話番号に対してゲートウェイ側でリスクが検出されたときに発生します。まずはアクセスの迅速な回復、続いてより強固な認証方式へ切り替え、最後に再発させない運用設計の三段構えで対処します。
最短での復旧：管理者権限でのバックエンド解除を依頼する
結論から言えば、Microsoft サポートにケースを起票し、エンジニアリング チームによる当該電話番号のブロック解除と悪評フラグのクリアを依頼するのが最短です。依頼の際は根拠情報を欠かさず添えます。
サポートに提出する必須情報（テンプレート）
| 項目 | 記入例 / 注意点 |
|---|---|
| テナント ID（Tenant ID） | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx（GUID） |
| 影響ユーザー | [email protected]（UPN） |
| 対象電話番号 | E.164 形式で +819012345678 のように記載（国番号＋市外局番先頭の 0 を除く） |
| 発生時刻 | YYYY-MM-DD HH:MM（タイムゾーン明記）。複数回あれば時系列で列挙 |
| Correlation ID / Request ID | サインイン失敗画面またはサインインログの詳細から取得（各回分） |
| エラーコード | 399287（Failure reason の文字列も併記） |
| 影響範囲 | 当該 1 番号のみ／特定キャリアのみ／複数ユーザー 等を記述 |
この情報が揃っていると、バックエンドでの番号ブロックと「悪い評価」フラグの解除判断が迅速になります。解除後は同じ番号で SMS が再び利用可能になりますが、これは暫定措置です。復旧次第、必ずより強固な認証方式に切り替えます。
暫定アクセスの代替策：ブレークグラスで入れる設計になっているか
本来、「テナントに誰も入れない」事態を避けるため、MFA 無効の非常用アカウント（ブレークグラス）を 2 つ以上準備しておくべきです。今回未整備であれば、復旧後ただちに整備します。設計の要点は次のとおりです。
- アカウント数：最低 2。用途は「テナント管理者権限の緊急用」。
- パスワード：推奨 24 文字以上・ランダム・保管は金庫＋二人承認。
- 条件付きアクセス（CA）：全ポリシーから除外（ただし、固定 IP のみ許可など最小限の縛りは可）。
- 利用監視：サインインが発生したら即時アラート（メール＋チャット）を飛ばす。
- 日常利用禁止：通常運用には絶対に使わない（監査で定期確認）。
より安全な認証方式への切り替え：SMS/音声通話からの脱却
SMS/音声通話はテレコム経路の脆弱性（IRSF、SIM スワップ、番号ポータビリティ悪用等）に晒されます。復旧したら即時に、次のいずれかへ移行します。
推奨 1：Microsoft Authenticator（プッシュ通知＋番号一致）
- 管理ポータルで セキュリティ > 認証方法 のポリシーを確認し、プッシュ通知・番号一致を許可。
- ユーザーはスマホに最新版 Authenticator をインストールし、組織アカウントを登録。
- ログイン時に「番号一致」を有効化し、通知のみの承認を禁止（通知爆撃対策）。
推奨 2：FIDO2 セキュリティキー（フィッシング耐性）
- 管理ポータルで FIDO2 セキュリティキー を許可し、対象ユーザー／グループを割り当て。
- ユーザーは物理キー（USB-A/C、NFC、BLE 等）を 2 本以上登録（紛失に備え冗長化）。
- CA の 認証の強度（Authentication strengths） で「フィッシング耐性」を要求するポリシーを作成。
認証方式の比較（意思決定の早見表）
| 方式 | フィッシング耐性 | 復旧容易性 | 運用コスト | 主なリスク | 推奨度 |
|---|---|---|---|---|---|
| SMS / 音声通話 | 低 | 中（番号依存） | 低〜中 | IRSF、SIM スワップ、通信事業者経路の不正 | 暫定のみ |
| Authenticator（プッシュ＋番号一致） | 中〜高 | 高（クラウドバックアップで復元可） | 低 | 端末紛失、通知爆撃（番号一致で緩和） | 推奨 |
| FIDO2 セキュリティキー | 高 | 中（予備キー必須） | 中（キー購入） | キー紛失・破損（保管ルールで緩和） | 最優先 |
再発防止のベストプラクティス：失敗しない設計と運用
Authenticator のクラウドバックアップを必ず有効化
- iOS：Authenticator 内の クラウドバックアップ をオン（iCloud に紐づく）。復元前に旧端末で最新化しておく。
- Android：Authenticator で Microsoft アカウントにサインインし、クラウドバックアップ をオン。
- 注意：別 Apple ID / Microsoft アカウントに切り替えると復元できません。機種変更前にアカウント一致を点検します。
非常用ブレークグラス アカウントの標準化
| 設計項目 | 推奨値 / 実装ヒント |
|---|---|
| 命名規則 | [email protected]、[email protected] のように一目で判別可能に |
| 権限 | グローバル管理者＋必要最小限、日常は PIM で無効（緊急時のみ昇格） |
| CA 除外 | 全 CA から除外。ただし 信頼できる場所（固定 IP）縛り を併用可 |
| 監査 | 月次でサインイン履歴をレビュー。アラート ＝ 即インシデント扱い |
| 保管 | 二人承認の紙封筒＋金庫。ローテーションは年 1 回以上 |
追加の MFA 方法を最低 2 系統以上登録
- Authenticator（プッシュ）に加え、TOTP（コード）、FIDO2 予備キー、予備電話番号を登録。
- 登録状況は定期棚卸（四半期）でチェック。未登録ユーザーには自動リマインド。
ログ監査とブロックリストの点検
サインインログと MFA ブロック関連のメトリクスを定期監査します。KQL の例を示します（ログ分析ワークスペースを前提）。
// エラー 399287 の発生を検出
SigninLogs
| where Status.ErrorCode == 399287
| project TimeGenerated, UserPrincipalName, IPAddress, Location, Status
// 電話番号を使った MFA 失敗の傾向
SigninLogs
| extend methods = tostring(AuthenticationDetails)
| where methods has "PhoneAppOTP" or methods has "OneWaySMS" or methods has "TwoWayVoiceMobile"
| summarize count() by bin(TimeGenerated, 1d), ResultType, tostring(Status.FailureReason)発生が見えたら、対象の電話番号・キャリア・国際番号の組み合わせを洗い出し、切り分けを進めます。
サインインが通った後に必ずやること（恒久対策）
- Authenticator を再登録し、プッシュ通知＋番号一致に切り替え。
- 不要になった SMS 認証方法を削除（セキュリティ情報ページまたは管理者側の認証方法管理から）。
- FIDO2 セキュリティキーを 2 本以上登録。鍵の保管・貸与禁止・廃棄手順を文書化。
- CA で「フィッシング耐性の強度」を必須化し、強度要件を満たさない経路（SMS など）を通さない。
- バックアップの有効化（Authenticator）と復旧コードの保管（該当するサービス）。
原因を理解する：電話番号が「悪い評価」になる背景
- IRSF（国際プレミアム番号詐欺）：攻撃者が高額課金の国際番号へ誘導する通話・SMS を大量に発生させる手口。事業者やゲートウェイは疑わしい宛先を自動遮断する。
- SIM スワップ：正規ユーザーの番号が乗っ取られると、SMS MFA が攻撃者に届く。キャリア側の異常検知と事業者間のリスク共有により番号評価が下がることがある。
- スパム濫用履歴：過去に同一番号で短時間に大量の OTP 要請があると、しきい値を超えて評価が悪化する。
いずれもユーザー側で直接解除できないため、サポート経由のバックエンド解除が必要になります。再発防止は、そもそも SMS に依存しない設計にすることです。
現場で使えるチェックリスト
| フェーズ | 実施項目 | 完了条件 |
|---|---|---|
| インシデント受理 | Tenant ID / UPN / 電話番号（E.164）/ 発生時刻 / Correlation & Request ID を収集 | サポート提出用シートに記入済み |
| 暫定対応 | Microsoft へ解除依頼、可能ならブレークグラスで管理ポータルに入る | SMS 送信が復旧 or 代替経路でサインイン可能 |
| 恒久対策 | Authenticator（番号一致）または FIDO2 へ切り替え、CA 強度を適用 | SMS を削除、二系統以上の認証が登録済み |
| 運用改善 | ブレークグラス整備、バックアップ有効化、ログ監査とアラート構築 | 運用手順と監査スケジュールが公開 |
よくある落とし穴と回避策
- 落とし穴：Authenticator のバックアップは「個人用」と「職場/学校」アカウントで復元の扱いが異なる。
回避策：組織アカウントは復元後に再登録が必要になる場合がある前提で計画する。 - 落とし穴：ブレークグラスを CA 除外したが、他の新規ポリシーの対象に無自覚で含めてしまう。
回避策：「除外グループ」を作り、全 CA の除外に同一グループを参照させる。 - 落とし穴：FIDO2 を 1 本だけ登録して紛失。
回避策：最低 2 本登録＋保管ルール（オフィス保管と個人保管に分散）。 - 落とし穴：番号一致を有効化していないプッシュ通知で、ユーザーが誤承認。
回避策：プッシュ承認は番号一致必須のポリシーにする。
問い合わせ文面サンプル（そのまま編集して使える）
件名：SMS MFA エラー 399287 によるサインイン不可（テナント ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx）
現象：
グローバル管理者（UPN: [[email protected]](mailto:[email protected])）が SMS MFA でサインイン時に
エラー 399287（電話番号の評価が悪い）でコード送信がブロック。
影響：
管理者がテナントへアクセス不可。Authenticator は再インストール後に復元できず。
対象電話番号（E.164）：+819012345678
発生時刻（JST）：2025-11-10 09:12 / 09:15 / 09:22
Correlation ID / Request ID：
・2025-11-10 09:12 Correlation: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee / Request: ffffffff-....
・2025-11-10 09:15 Correlation: ...
希望対応：
当該番号に対する SMS ブロックと悪評フラグの解除をご確認ください。管理者向け実務 Tips
- 番号表記の正規化：ユーザー教育として E.164 で登録（例：日本の携帯は
+8190から始まる）。 - OTP 要求のスロットリング：短時間の再送要求を制限する UI/運用で評価悪化を避ける。
- 運用ダッシュボード：「SMS 失敗率」「番号一致未有効ユーザー数」「FIDO2 登録率」を KPI 化。
- インシデント ドリル：四半期に 1 回、ブレークグラスでの入室訓練と復旧シナリオの通し稽古を実施。
付録：ユーザー画面で Correlation ID & Request ID を控える方法
- サインインが失敗した画面の「詳細表示」から、エラーコード／タイムスタンプ／Correlation ID／Request ID をコピー。
- 時刻はタイムゾーンを明記（UTC／JST など）。複数回失敗した場合はすべて記録。
まとめ：復旧 → 移行 → 再発防止の 3 ステップで安定運用へ
SMS MFA エラー 399287 は、ユーザー側での即時解除が難しい性質上、Microsoft サポートによるバックエンド解除が最短の復旧手段です。復旧後はただちに Authenticator（番号一致）や FIDO2 へ移行し、ブレークグラス＋多経路 MFA＋ログ監査の三点セットで運用の復元力を高めてください。これにより、同様の障害を業務影響なく受け止められる体制が実現します。
実装ロードマップ（90 日プラン）
| 期間 | 主なタスク | 達成基準 |
|---|---|---|
| Day 0–7 | 番号解除依頼／ブレークグラス整備／Authenticator 再登録 | 管理者が CA を編集可能・SMS 依存を解消 |
| Day 8–30 | FIDO2 ポリシー展開、番号一致の全社必須化、KPI 設計 | 強度「フィッシング耐性」適用済みユーザー ≥ 50% |
| Day 31–90 | FIDO2 2 本目の普及、ログ分析の自動化、監査運用定着 | FIDO2 登録率 ≥ 80%、月次監査レポート運用 |
トラブルシューティング補遺：それでも入れない場合
- キャリア側の制限：国際 SMS/音声の受信制限が有効な場合、解除が必要。
- 端末の受信設定：迷惑 SMS フィルタや着信拒否で OTP が消えていないか確認。
- 地域依存の問題：特定の国・地域でのみ失敗するなら、国際経路の問題としてサポートに伝える。
- アカウント状態：ユーザーが無効化・リスクブロック・サインイン許可の制限を受けていないか、管理ポータルで点検。
セキュリティ方針への反映例（サンプル条文化）
- すべての管理者アカウントは フィッシング耐性 MFA（FIDO2 または Windows Hello for Business）を必須とする。
- SMS/音声通話は原則禁止。やむを得ない場合の暫定利用は 7 日以内に廃止。
- ブレークグラスは 2 アカウント以上、CA 除外、固定 IP 制限、アラート必須。
- Authenticator のクラウドバックアップを全社必須（機種変更手順に含める）。
- 四半期ごとに MFA 登録状況とログ分析の監査レポートを作成し、経営に報告。
ケーススタディ（想定シナリオ）
管理者 A さんが端末交換後にログイン不能。SMS で 399287。サポート解除で入室後、次を実施：
- Authenticator 再登録と番号一致有効化。
- FIDO2 キー 2 本登録（USB-C と NFC）。
- 管理者全員に「強度：フィッシング耐性」を必須化。
- ブレークグラス 2 アカウント整備、固定 IP のみ許可。
- ログの KQL アラートを構築し、399287 と SMS 失敗率を監視。
以後、SMS 経路がブロックされても業務に影響なし。監査でも改善が確認できました。
エンジニア向け補足：運用自動化のヒント
- 登録状況の可視化：Graph API でユーザーの認証方法（Phone、FIDO2、Authenticator）を定期収集しダッシュボード化。
- アラート自動発報：ログクエリのしきい値超過で ITSM にインシデント自動起票。
- デバイス前提の設計：MDM で Authenticator のインストール・バックアップ設定を強制。
結び
「まず入れるようにする」ためのバックエンド解除、「二度と困らない」ための認証方式見直し、「組織として強くなる」ための運用設計。この 3 点を押さえれば、Entra ID における SMS MFA エラー 399287 は恐れるに足りません。今日から計画と実装を前に進めていきましょう。
コメント