Azure ポータルへのサインイン時に「Sorry, we’re having trouble verifying your account. Please try again.」と表示され、エラー 399287 で SMS／音声通話の多要素認証（MFA）が通らない——一方で Microsoft Authenticator やモバイルの Azure アプリでは入れる。この記事は、この“Web ポータルだけが電話番号検証を強制する”状況の原因と対処を、実務者視点でまとめた決定版ガイドです。
状況の整理（症状と前提）
まずは発生状況を明確化します。次の表で、症状・影響範囲・よくある前提条件を確認してください。
| 項目 | 内容 |
|---|---|
| 主な症状 | Azure / Microsoft Entra ID サインイン時に電話／SMS の MFA が選ばれ、エラー 399287 で失敗。「Sorry, we’re having trouble verifying your account. Please try again.」が繰り返し表示される。 |
| 影響対象 | 主に Azure ポータル（web） でのサインイン。モバイルの Microsoft Authenticator（プッシュ通知＋番号一致）や Azure モバイルアプリではサインインできるケースが多い。 |
| 再現特徴 | 認証方法の選択肢に進めず、電話番号検証が強制される／切り替えできない。メソッド選択画面に戻されるループが発生することもある。 |
| ログのヒント | サインインログに PhoneReputationBlocked、ResultType の失敗、ConditionalAccessStatus の要求未満などが記録される。 |
根本原因（よくある 3 パターン）
本事象の背後には、次の三つの要因が絡んでいることがほとんどです。
PhoneReputation によるブロック
Microsoft Entra の内部サービス PhoneReputation が、当該電話番号を「悪評（bad reputation）」と判定し、SMS／通話の配信自体を抑止している可能性があります。迷惑電話・スパム・高リスク帯域からの大量要求・転送番号等が検知トリガーになり得ます。電話がユーザーに届かない／使えないため、最終的にエラー 399287 で弾かれます。
電話／SMS MFA の脆弱性対策（段階的廃止の流れ）
フィッシング耐性が低い電話トランスポート（音声通話・SMS）は、業界全体で縮小方向にあり、Microsoft も強い認証（Authenticator のプッシュ＋番号一致、FIDO2 セキュリティキー、パスワードレス）への移行を推奨しています。しきい値超過や不審アクティビティがあると、自動ブロックや強制メソッド選択が発生しやすくなります。
ポリシー競合（ユーザー単位 MFA × 条件付きアクセス）
ユーザー単位 MFA の「有効化」と、条件付きアクセス（CA） での「MFA 要求（または Authentication Strength）」が重複すると、既定メソッドの選択やメソッド評価順が不安定になり、Web ポータルのみ電話が強制される・メソッド選択に戻る、といったループを誘発します。
| 原因 | 現れ方 | 確認ポイント | 第一推奨対処 |
|---|---|---|---|
| PhoneReputation ブロック | SMS／通話が届かない／即失敗 | サインインログの PhoneReputationBlocked、エラー 399287 | 番号のブロック解除依頼＋電話認証の無効化 |
| 電話トランスポートの縮小 | 電話が選ばれ続ける／他メソッドに切替不可 | CA の要求メソッド、認証方法ポリシー | Authenticator / FIDO2 への移行、既定メソッドの見直し |
| ポリシー競合 | 選択画面ループ／Web のみ失敗 | ユーザー単位 MFA と CA の重複 | ユーザー単位 MFA を無効化し、CA＋認証方法ポリシーへ統一 |
最短で復旧させるための対処フロー
管理者の工数を最小化しつつ安全に復旧するため、以下の順で実施してください。
- 安全な認証方法に切替（既定メソッドを更新）
- 管理者または対象ユーザーが Authenticator（プッシュ＋番号一致） を登録済みなら、それを 既定のサインイン方法 に設定します。
- FIDO2 セキュリティキー（YubiKey など）を登録済みなら、これも既定候補に。
- パスワードレス サインイン（Authenticator のパスワードレスや Windows Hello for Business）を許可している場合は、優先度を最上位へ。
- 電話番号のブロック解除を依頼 別アカウント（後述の“緊急用管理者”）で管理ポータルに入り、次の情報をまとめて Microsoft サポートへ提出します。内部フラグ解除後、SMS／通話は復旧します（ただし将来の再発を防ぐため、電話トランスポート自体は停用方針が無難）。 提出項目 記入例 テナント ID（Directory ID） xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 発生時刻（UTC・ローカル両方） 2025-11-05 03:21 UTC / 2025-11-05 12:21 JST Request Id / Correlation Id 失敗画面またはサインインログから採取 電話番号（国番号付き） +81-90-xxxx-xxxx エラーコード 399287
- 再発防止：電話／SMS MFA をポリシーで非推奨・無効化
- 認証方法ポリシー で「テキストメッセージ（SMS）」「音声通話」を 使用不可 に設定。
- 条件付きアクセス では「MFA を要求」ではなく Authentication Strength を使い、Phishing-resistant MFA または Strong MFA を構成。
- Combined security information registration を有効化し、初回登録時点で Authenticator / FIDO2 を必須化。
なぜ「Web ポータルだけ」失敗するのか（仕組みの理解）
同じアカウントでも、クライアント・フローにより選ばれる認証メソッドが異なります。特に Azure ポータル（ブラウザ）は、CA 要件 と 既定のサインイン方法、登録済みメソッドの評価順 に敏感です。電話が“既定扱い”または CA の評価で優先されると、Authenticator が登録されていても電話が先に提示され、結局 PhoneReputation により失敗します。一方、モバイルアプリは既存セッションやデバイス認証が効いていて別メソッドで通過でき、差が生まれます。
運用担当者向け：確認手順（ログ・ポリシー・登録状況）
サインインログでの確認（KQL サンプル）
Entra 管理センターの「サインイン」から、次のような条件で絞り込みます。
- ユーザー名（UPN）
- 結果：失敗
- アプリケーション：Azure Portal（または Azure Resource Manager）
- 日付／時刻範囲：発生時刻付近
Kusto クエリの例：
// 399287 と PhoneReputation の痕跡を検索
SigninLogs
| where ResultType != 0
| where ResultDescription has "399287" or AdditionalDetails has "PhoneReputation"
| project TimeGenerated, UserPrincipalName, ResultType, ResultDescription, ConditionalAccessStatus, AuthenticationRequirement, AuthenticationDetails, CorrelationId, RequestId
| order by TimeGenerated desc 看過しやすいポイントとして、AuthenticationDetails に phone / sms のトランスポート種別や、チャレンジ順序のヒントが出ることがあります。
登録済みの認証方法を棚卸し
対象ユーザーの「セキュリティ情報（既定のサインイン方法）」を確認し、次の観点で見直します。
- Authenticator（プッシュ＋番号一致）が登録済みか。ワンタイムパスワード（TOTP）だけになっていないか。
- FIDO2 セキュリティキー、Windows Hello for Business の有無。
- 既定メソッドが「電話」になっていないか。
ポリシーの健全性チェック
| 項目 | 望ましい状態 | 要注意状態 |
|---|---|---|
| ユーザー単位 MFA | 基本 無効。CA と認証方法ポリシーへ統一。 | “有効”のまま放置（CA と二重適用でループの温床）。 |
| 認証方法ポリシー | 電話／SMS を 使用不可。Authenticator と FIDO2 を許可。 | 電話が許可・優先され、既定メソッドが電話に。 |
| 条件付きアクセス | Authentication Strength を使用（Phishing-resistant/Strong）。 | 「MFA を要求」のみで具体メソッドが曖昧。 |
| 登録体験 | Combined registration を有効化し、初回に安全メソッドを必須。 | レガシー登録で電話が先に登録される。 |
実践手順：安全メソッドへの移行と強制
Authenticator（プッシュ＋番号一致）を既定にする
- 対象ユーザーの「セキュリティ情報」で 既定のサインイン方法 を「Microsoft Authenticator – 通知」に設定。
- 条件付きアクセスで対象アプリ（Azure ポータル）に Authentication Strength: Strong 以上 を適用。
- ユーザーに「番号一致」および「アプリロック」の有効化を周知。
FIDO2 セキュリティキーの導入
- 認証方法ポリシーで FIDO2 を許可し、AAGUID（許可するキーの機種）を設定。
- 登録ポリシーで Attestation を求め、紛失時の復旧手順（予備キー・管理者解除）をドキュメント化。
電話／SMS を無効化する設定例（方針）
- 認証方法ポリシー：Text message と Voice call を Disallow。
- CA：Require authentication strength → Phishing-resistant MFA または Strong MFA。
- ユーザー単位 MFA：Disabled。Enforced/Enabled は廃止。
PowerShell／Graph を使った管理の一例（参考）
GUI での操作が難しい場合や自動化したい場合は、Microsoft Graph PowerShell SDK を利用します（以下は概念的なサンプル）。
# Graph へ接続（適切なスコープを指定）
Connect-MgGraph -Scopes "User.ReadWrite.All","Policy.Read.All","Policy.ReadWrite.AuthenticationMethod"
Select-MgProfile -Name "beta"
# ユーザーの認証方法を一覧
Get-MgUserAuthenticationMethod -UserId [[email protected]](mailto:[email protected])
# 既定のサインイン方法を Authenticator に
# ※実際のプロパティはテナントの状態により異なるため、GUI と併用で確認してください
# Update-MgUserAuthenticationMethod -UserId ... -IsDefault $true
# 認証方法ポリシーの電話を無効化（概念例）
Get-MgPolicyAuthenticationMethodsPolicy
# Update-MgPolicyAuthenticationMethodsPolicy -... <電話/SMS を Disallow>
# 条件付きアクセスで Authentication Strength を要求（概念例）
# New-MgIdentityConditionalAccessPolicy -... -GrantControls @{BuiltInControls=@("authenticationStrength")}
Disconnect-MgGraph 実装はテナントごとの差異が大きいため、変更前には必ずテスト用グループで段階的に適用してください。
サポートにブロック解除を依頼する際のテンプレート
PhoneReputation の解除依頼は、情報不足だと差し戻されがちです。以下のテンプレートを参考にすることで、一次回答までの往復を最小化できます。
件名: 電話番号の PhoneReputation 解除依頼（エラー 399287）
内容:
* テナント名 / テナント ID:
* 影響ユーザー（UPN）:
* 影響番号（国番号付き）:
* 発生時刻（UTC とローカル）:
* エラー表示メッセージ:
* Request Id / Correlation Id:
* サインインログ抜粋（ResultType/ResultDescription/AuthenticationDetails）:
* 発生範囲（Azure ポータルのみ/全体）:
* 既知の対策（Authenticator/FIDO2 は登録済みか、既定メソッドは何か）:
* 再発防止方針（電話トランスポートの停止予定 等）: セキュリティ観点：なぜ電話／SMS をやめるべきか
電話／SMS は、SIM スワップ、スミッシング、音声ボット、転送設定の悪用、海外回線の迂回など多様な攻撃ベクトルに晒されています。Authenticator（番号一致） と FIDO2 は、チャネル乗っ取りに強く、人間の注意力に過度に依存しない 構造であるため、フィッシング耐性 と ユーザー体験 の両立が可能です。
| メソッド | 耐フィッシング性 | ユーザー体験 | 推奨度 |
|---|---|---|---|
| 音声通話／SMS | 低 | 可変（回線品質依存） | 非推奨 |
| Authenticator（TOTP） | 中 | 良 | 推奨（代替） |
| Authenticator（プッシュ＋番号一致） | 高 | 非常に良 | 最優先 |
| FIDO2 セキュリティキー | 最高 | 良（慣れが必要） | 最優先 |
よくある落とし穴と回避策
- 落とし穴：ユーザー単位 MFA の「有効化」を残したまま CA を導入。
回避：ユーザー単位 MFA を停止し、CA＋認証方法ポリシーで統一。 - 落とし穴：Authenticator は登録済みだが 既定 が電話のまま。
回避：既定メソッドを Authenticator（通知）に変更。 - 落とし穴：緊急時に操作できる管理者が 1 人しかいない。
回避：クラウドのみの緊急用管理者（Break-glass） を最低 2 つ、電話トランスポート無しで用意。 - 落とし穴：Combined registration を無効にしており、ユーザーがまず電話を登録してしまう。
回避：登録体験を新方式に統一し、初回で安全メソッドを必須に。
監査と可観測性：再発を検知する
PhoneReputation や電話メソッドの失敗は、定期監査とアラート設定で早期に気付けます。
Log Analytics への送信とアラート（クエリ例）
// PhoneReputation 由来の失敗を検知
SigninLogs
| where ResultType != 0
| where ResultDescription has "Phone" or AdditionalDetails has "PhoneReputation"
| summarize count() by bin(TimeGenerated, 1h) 上記をアラート化し、一定回数以上で管理者に通知。並行して「電話／SMS 使用ユーザー数」の月次レポートを可視化し、ゼロ化を KPI に設定すると着実に移行が進みます。
トラブルシュート・シナリオ別ガイド
ケース A：メソッド選択画面に進めずループする
ユーザー単位 MFA と CA の二重要求が起点。ユーザー単位を無効化し、CA で Authentication Strength を指定。登録済みメソッドの既定を Authenticator に。ケース B：電話が着信しない／SMS が届かない
PhoneReputation の可能性が高い。サインインログから RequestId/CorrelationId を採取し、サポートに解除依頼。同時に電話トランスポートを無効化。ケース C：Authenticator だけで入れるのに Web だけ失敗
Web はメソッド優先度の影響を受けやすい。既定メソッドと CA を見直し、Web でも Authenticator が最初に選ばれるよう整える。
移行計画のサンプル（30 日プラン）
| 期間 | タスク | 成果物／完了条件 |
|---|---|---|
| Week 1 | 現状調査（電話メソッド使用者、ポリシー、失敗ログ） | 棚卸しレポート、影響ユーザー一覧 |
| Week 2 | 認証方法ポリシー整備、CA で Authentication Strength 定義、パイロット開始 | パイロット 10～20% ユーザーで成功 |
| Week 3 | 全社展開、ユーザー周知（番号一致・アプリロック・FIDO2 配布） | 電話／SMS 使用率 5% 未満 |
| Week 4 | 電話トランスポートの無効化、残件フォロー、アラート設定 | 使用率 0%、アラート稼働、運用手順書更新 |
チェックリスト（公開前／適用前に確認）
- 緊急用管理者（Break-glass）アカウントを 2 つ以上 用意し、強い認証のみを登録している。
- ユーザー単位 MFA を無効化し、認証方法ポリシー と CA（Authentication Strength） に統一している。
- Authenticator（プッシュ＋番号一致）または FIDO2 を 既定メソッド に設定している。
- 電話／SMS は Disallow で、例外の承認プロセスが定義されている。
- サインインログのダッシュボードとアラートが稼働している。
- サポート依頼テンプレート（ブロック解除用）を整備済み。
参考情報（タイトルのみ）
- Understanding telephony fraud risk for Microsoft Entra MFA
- Protecting authentication methods in Microsoft Entra ID
- It’s Time to Hang Up on Phone Transports for Authentication
まとめ：エラー 399287 は“電話をやめる”サイン
エラー 399287 は、多くの場合 PhoneReputation によるブロックと、電話トランスポート依存 の運用設計が引き起こします。短期的にはサポートによる番号のブロック解除で復旧しますが、根治には Authenticator／FIDO2 への全面移行、ユーザー単位 MFA の撤廃、Authentication Strength の活用 が不可欠です。本記事の手順を順守すれば、Azure ポータルでもアプリでも一貫して強固かつ使いやすいサインイン体験を実現できます。
コメント