Azure にサインインしようとすると「Sorry, we’re having trouble verifying your account. Please try again.」が表示され、電話番号/SMS の本人確認を通過できずに止まってしまう――そんなときに見かけるのが Error 399287 です。サブスクリプションは有効なのに管理作業のためにログインできない場合、本人だけで解決するのは難しいことが多く、管理者（Entra/グローバル管理者）側の復旧作業が近道になります。
症状：Azure サインインで「本人確認に失敗しました」Error 399287 が出る
このトラブルは、Azure ポータルへのサインイン途中で追加の本人確認（MFA）を求められ、SMS/電話による確認が失敗して先に進めなくなるパターンが典型です。画面上は英語で次のようなメッセージが出ることがあります。
- Sorry, we’re having trouble verifying your account. Please try again.
- エラーコード：399287
「以前はログインできていた（1〜2月頃は大丈夫だった）のに最近になって発生」というケースも珍しくありません。これは、アカウントやテナントの設定変更だけでなく、認証側の判定（セキュリティ判定、リスク判定、回線や番号の信用度など）によって条件が変わり得るためです。
まずは切り分け：ユーザー側で試せる範囲のチェック
管理者対応が必要なケースが多い一方で、最初に「単純な環境要因」や「連続試行による一時制限」を外しておくと、復旧が早くなります。以下を上から順に確認してください。
| 確認ポイント | なぜ重要か | すぐできること |
|---|---|---|
| 別ブラウザー/シークレットで試す | Cookie・拡張機能・キャッシュが認証フローを壊すことがある | シークレット/プライベート、Edge/Chrome 切替、拡張機能を一時OFF |
| 別端末で試す（PC→スマホ等） | 端末側の証明書や時刻ズレ、ネットワーク制限の影響を受ける | 社内端末と私用端末で比較（会社ルールに従う） |
| ネットワークを変える（社内→テザリング等） | VPN/プロキシ/社内FWが認証ページやSMS連携を妨げることがある | VPNを一度切る、別回線でログインを試す |
| 端末の日時・タイムゾーン | 認証トークンの有効期限・TLSの整合性に影響 | 自動時刻合わせをON、再起動 |
| SMS受信状況（圏外/迷惑SMS/受信制限） | SMSが届かないだけで“本人確認失敗”に見える | 受信拒否設定、海外ローミング、迷惑SMSフィルタを確認 |
| 短時間に何度も試していないか | 失敗を繰り返すと一時的に認証が通りにくくなることがある | 連続試行を避け、原因の切り分け（端末/回線変更）を優先 |
ここでの目的は「自分の環境が原因で失敗しているのか」を切り分けることです。上の項目を試しても Error 399287 が継続するなら、次の章の内容（管理者対応）が本命になります。
原因として多いのは「SMS用の電話番号が信頼できない扱い」になるケース
Error 399287 の背景としてよく示唆されるのが、MFA（多要素認証）で登録しているSMS用電話番号が“信頼度が低い（悪い評判）”と判定されるケースです。特に次の条件が重なると起きやすいと言われます。
- 短時間に認証の試行（成功/失敗）を繰り返した
- SMSを受け取れない状態で何度も再送・再試行した
- 番号が使い捨て/共有/転送系（VoIP等）で、認証用途として弾かれやすい
- 過去に同じ番号で多くの認証が行われ、リスク判定が上がっている
ポイントは、本人の入力が正しくても「番号側の判定」で落ちることがある点です。この場合、利用者側でできることは限られ、管理者の権限で「認証方法を作り直す」「別の認証手段に切り替える」対応が必要になります。
なぜ“本人（一般ユーザー）だけ”では解決しにくいのか
Azure / Microsoft 365 のサインイン問題は、根本が「Entra ID（旧 Azure AD）の認証情報」にあることが多いです。ところが一般ユーザーは、次の作業を自分で実施できません。
- ユーザーの認証方法（MFA）の削除・再登録の強制
- MFA セッションの失効（サインイン状態の取り消し）
- 条件付きアクセス（Conditional Access）やセキュリティポリシーの調整
- Temporary Access Pass（一次的な復旧用パス）の発行
- サポートチケット（サービス要求）の起票
そのため、本人が「Microsoftの担当者に繋いでほしい」と考えても、実務としては 自組織の管理者が復旧・エスカレーションの窓口になります。これは“手続きの都合”というより、セキュリティ上、本人確認や設定変更をユーザー単独で完結させない設計だからです。
管理者に依頼する最短ルート：復旧のためにやること一覧
管理者にお願いしたいのは「本人確認のやり直し」ではなく、認証方法（SMS）に依存しない状態へ復旧することです。以下の順に進めると、現場では早く解決することが多いです。
| 優先度 | 管理者がやること | 狙い | 結果のイメージ |
|---|---|---|---|
| 高 | サインインログで失敗理由を確認 | “番号の問題”か“ポリシーの問題”かを特定 | すべき対処がブレなくなる |
| 高 | MFA（認証方法）のリセット/再登録を要求 | 古い情報・失敗ループを断ち切る | 登録し直しが走り、復旧の入口ができる |
| 高 | 電話番号の更新（可能なら別番号） | “信頼度が低い扱い”の番号から離脱 | SMSが通る/またはSMS依存を減らせる |
| 高 | 代替のサインイン方法を追加（Authenticator/FIDO2等） | SMSがダメでもログイン可能にする | 次回からはアプリ通知や鍵で認証 |
| 中 | MFA セッションの無効化（サインイン状態の取り消し） | 古いセッションや途中状態をクリア | 再サインインで新しいフローに乗る |
| 中 | 条件付きアクセス / セキュリティ既定値 / 認証方法ポリシーの再確認 | SMSしか使えない設計になっていないかを見直す | 再発しにくい構成にできる |
| 必要時 | サポートチケット起票（Microsoft への調査依頼） | テナント側で解けない判定/制限の調査 | 原因が確定し、解除や回避策が提示される |
管理者向け：Entra 管理センターでの具体的な復旧手順
ここでは一般的な流れを、実務で迷いにくい形でまとめます。テナントの構成（条件付きアクセス、セキュリティ既定値、SSPR など）により画面名や手順が多少異なることがありますが、考え方は共通です。
サインインログで「何が失敗しているか」を先に見る
いきなり設定をいじる前に、まずは サインインログで事実確認をします。ここで見たいのは次のポイントです。
- 失敗のタイミングが「パスワード後」なのか「MFA/本人確認段階」なのか
- 条件付きアクセスの適用結果（ブロック、要MFA、準拠デバイス要求など）
- 失敗時の詳細（追加情報、失敗理由、要求ID/相関IDが取れるか）
ログを見て「MFA 以外（例えばポリシーでブロック）」だった場合は、SMS番号の話とは別ルートになります。逆に、本人確認段階で落ちているなら本記事の対応が刺さりやすいです。
MFA（認証方法）のリセット/再登録を要求する
ユーザーが SMS で詰んでいるときは、ユーザーの認証方法を整理して“作り直す”のが定石です。実施の方向性は次のいずれか、または組み合わせになります。
- 登録済みの電話番号（SMS/音声）の削除または更新
- Microsoft Authenticator を主（推奨）にしてSMS は予備に回す
- 再登録を要求し、次回サインイン時に設定し直させる
SMS が“信用できない番号”として弾かれている疑いがあるなら、同じ番号を使い続けて再試行しても改善しないことがあります。別番号に差し替える、または Authenticator などの別手段へ移行が現実的です。
MFA セッションの無効化（サインイン状態の取り消し）
ユーザーが「認証の途中状態」に入ってしまっていると、端末やブラウザーを変えても同じところで詰まることがあります。管理者側でサインイン状態を取り消し（セッションの失効）し、新しい認証フローで再サインインさせると改善することがあります。
Temporary Access Pass（一次的な復旧用パス）を使う
SMS が通らず、Authenticator の追加もできない（＝サインインできないので追加手段を登録できない）という“詰み”状態では、Temporary Access Pass（TAP）が非常に有効です。TAP は管理者が発行する短期・回数制限付きのパスで、ユーザーがサインインして認証方法の登録をやり直すための「橋渡し」になります。
復旧の流れの例は次の通りです。
- 管理者がユーザーに Temporary Access Pass を発行（有効期限・回数を最小限に設定）
- ユーザーは TAP を使ってサインイン
- ユーザーは Microsoft Authenticator（推奨）や別の認証方法を登録
- SMS しか残っていない状態を解消し、認証方法を複線化
- 最後に、不要になった古い電話番号や弱い手段を整理
「SMS がダメ → サインインできない → 手段を変更できない」というループを断ち切れるため、管理者が使えるなら優先順位は高いです。
ユーザー側の実務：管理者に渡す情報が多いほど復旧が早い
管理者に「ログインできません」だけを伝えると、原因切り分けに時間がかかります。次の情報をまとめて渡すと、サインインログの検索やサポートエスカレーションがスムーズです。
| 渡すと役立つ情報 | 具体例 | 用途 |
|---|---|---|
| エラーコード | 399287 | 同一事象の特定、調査の起点 |
| 表示メッセージ | Sorry, we’re having trouble verifying your account… | 本人確認（MFA）段階の問題であることが伝わる |
| 発生日時 | 2026/01/07 10:15 頃 | サインインログを絞り込む |
| 試した環境 | Edge/Chrome、社内回線/テザリング | 端末・回線起因の除外 |
| 本人確認手段 | SMS（登録電話番号の末尾4桁） | 番号の更新や削除の判断材料 |
| スクリーンショット | エラー画面全体 | 誤認を減らし、状況共有が速い |
特に「発生日時」と「末尾4桁」は、管理者がログと照合しやすいのでおすすめです（番号全体を送る必要がある場合は社内ルールに従ってください）。
管理者が見落としやすい設定：SMS しか使えない構成になっていないか
復旧後に再発を防ぐには、そもそも “SMS が詰んだら終わり”という構成を避ける必要があります。見落としやすいポイントをまとめます。
認証方法を複線化する（最低2種類）
おすすめは、アプリ（Authenticator）＋予備（別手段）です。SMS は利便性が高い一方で、番号判定・回線事情・SIM再発行など外部要因に弱く、ビジネス用途の“主”に据えるのはリスクが残ります。
| 認証方法 | 強み | 弱み/注意点 | おすすめ度 |
|---|---|---|---|
| Microsoft Authenticator（プッシュ/コード） | SMSより安定、フィッシング耐性が高い運用が可能 | 端末機種変時の移行、端末紛失時の復旧設計が必要 | 高 |
| FIDO2 セキュリティキー / パスキー | フィッシング耐性が非常に高い、運用が固い | 配布・紛失時の手順、初期コスト | 高（組織向け） |
| SMS（電話番号） | 導入が簡単、誰でも使える | 番号の信用度判定・回線事情・SIM乗っ取り等に弱い | 中（予備向け） |
| メール（OTP） | 回線不要、予備として便利 | メール自体の保護が弱いと連鎖リスク | 中（条件次第） |
| Temporary Access Pass（TAP） | 詰み状態の復旧に強い | 常用ではなく“復旧用”。発行管理が重要 | 高（復旧用） |
「同じ電話番号を複数人で共有」を避ける
代表番号や共有携帯をMFAに使うと、運用上は便利に見えても、セキュリティと可用性の両面で問題が出やすくなります。特に次のような運用は避けるのが安全です。
- 1つの携帯番号を複数アカウントのMFAに登録
- 人の入れ替わりが多い部門で、番号が引き継がれ続ける
- 実在の本人と紐づかない番号（誰でも触れる端末）を使う
“番号の評判”の話に限らず、監査やインシデント対応の観点でも不利になります。
復旧用の管理者アカウント（ブレイクグラス）を設計しておく
今回のように「管理作業をしたいのに管理者本人が入れない」状況は現場で起こりがちです。最低限、次を満たす復旧用アカウント（ブレイクグラス）運用を検討してください。
- 通常の業務ユーザーとは分ける（普段は使わない）
- SMSに依存しない強い認証手段を持たせる（例：FIDO2）
- 利用時の手順、保管方法、監査ログの確認手順を決める
- 条件付きアクセスの例外設計は慎重に（“無防備”にしない）
それでも解消しない場合：Microsoft サポートへエスカレーション
管理者側で認証方法を整理しても解決しない、あるいはテナント側で説明のつかない制限が疑われる場合は、管理者が Microsoft サポートへ調査依頼するのが現実的です。起票時に揃えておくと強い情報は次の通りです。
| サポートに渡すと強い情報 | 例 | なぜ必要か |
|---|---|---|
| 対象ユーザー（UPN） | [email protected] | 調査対象の明確化 |
| テナント情報 | テナント名、テナントID（分かる範囲） | サポート側の照合が速い |
| 発生日時（できれば複数回） | 2026/01/07 10:15 / 10:22 | ログ追跡の精度が上がる |
| サインインログの該当レコード | 失敗理由、条件付きアクセス結果 | 原因が番号なのかポリシーなのかを切り分けられる |
| エラーコード・画面 | 399287、スクリーンショット | 同種事象に当てやすい |
| 試した対処 | MFAリセット、別番号、Authenticator 追加など | 二度手間を防ぐ |
なお、サポートへの依頼は通常、Microsoft 365 管理センターや Azure の管理ポータルからのサービス要求として行います。ユーザー本人ではなく、組織の管理者経由で進めるのが基本です。
管理者へ送る依頼文（そのまま貼れるテンプレート）
社内のIT管理者へ連絡する際、以下をそのまま貼って使えるようにしておくと話が早いです。必要に応じて日時や末尾4桁などを追記してください。
Azure サインイン時に本人確認（SMS/電話）が通らず、 「Sorry, we’re having trouble verifying your account. Please try again.」と表示され、Error 399287 になります。 ユーザー側でブラウザー/端末/回線変更などは試しましたが改善しませんでした。 Entra 側で以下の対応をお願いします。 ・対象ユーザーの MFA（認証方法）をリセット/再登録要求 ・SMS 用電話番号の更新（必要なら別番号へ）または削除 ・バックアップのサインイン方法の追加（Microsoft Authenticator など） ・必要に応じて MFA セッションの無効化（サインイン状態の取り消し） ・上記で解消しない場合は Microsoft サポートへサービス要求を起票して調査依頼 発生日時： 使用している認証手段：SMS（登録番号末尾4桁：____） スクリーンショット：あり/なし
まとめ：Error 399287 は「SMS依存をやめる」方向が最短で強い
Azure サインインで「本人確認に失敗しました」Error 399287 が出るとき、原因はユーザーの入力ミスというより、SMS用の電話番号や認証の判定が通らないことに起因するケースが目立ちます。そしてこの問題は、一般ユーザーだけで完結しにくく、Entra 管理者による MFA のリセット/再登録・代替手段の追加が実務上の近道です。
復旧だけでなく再発防止まで考えるなら、Microsoft Authenticator や FIDO2 など、SMSに依存しない方法を主にすることが効果的です。管理者に依頼する際は、エラーコード（399287）、発生日時、試した環境をセットで伝え、必要ならサポートへのエスカレーションまで一気に進められる形にしておきましょう。
コメント