結論：Microsoft 365やAzureへのサインインでエラー399287が出た場合は、パスワードよりもSMS・音声通話による本人確認の経路を先に疑います。Microsoftの一次資料では、「Sorry, we’re having trouble verifying your account」という表示は、同じユーザー、電話番号、または組織から短時間に多数の電話・SMS認証が行われたため、Microsoft側で制限またはブロックされた場合に発生し得ると説明されています。ただし、公開されている製品資料は399287を特定の原因へ一対一で対応付けていないため、「電話番号の評判だけが原因」と断定するのは避けるべきです。別の認証方法が表示されるならMicrosoft Authenticatorや確認コードを使い、管理者はサインインログと診断結果を確認します。代替手段がない場合は、別の管理者がTemporary Access Passを発行して安全に認証方法を再登録するのが実務的です。 最新の画面名や提供条件は更新で変わるため、以下の順番で確認してください。
最初に確認するポイント
| 症状・条件 | 主な原因 | 最初の確認 |
|---|---|---|
| SMSまたは音声通話を選ぶと399287になり、Authenticatorなど別の方法ではサインインできる | 電話認証経路に対する一時的な制限、電話番号・ユーザー・組織単位のブロック、または通信事業者側の配送問題が考えられます。公開一次資料だけでは399287の原因を一つに確定できません。 | 「別の方法でサインイン」を開き、Authenticator通知、Authenticatorの確認コード、パスキーなど登録済みの別手段が使えるか確認します。 |
| どの認証方法を選んでも失敗し、Conditional AccessやMFAの画面で止まる | 電話認証だけでなく、Conditional Access、認証方法ポリシー、初回登録未完了、またはアカウント状態が影響している可能性があります。 | Microsoft Entra管理センターの「Entra ID > Monitoring & health > Sign-in logs」で対象イベントを開き、「Launch the Sign-in diagnostic」を実行します。 |
| 別の管理者は存在するが、対象ユーザーに利用可能なMFA方法が残っていない | 既存の電話番号やAuthenticator登録が失効・削除され、新しい方法を登録するための強い認証も完了できない状態です。 | 対象ユーザーがTemporary Access Passポリシーの対象か確認し、短時間・原則1回限りのTAPを発行できるか判断します。 |
| 唯一の全体管理者がロックアウトされ、テナント内から認証方法を変更できない | 管理者自身は自分のユーザーオブジェクトを管理者権限で救済できず、代替管理者もいないため、テナント内の通常手順だけでは復旧できない可能性があります。 | エラー画面のRequest ID、Correlation ID、UTC時刻、テナントID、対象UPNを控え、Microsoftの正式なサポート窓口へ連絡できる契約・請求情報を準備します。 |
安全な対処手順
1. 最初にエラー情報を保存し、無制限の再試行を止める
エラー画面を閉じる前に、エラーコード、Request ID、Correlation ID、発生日時、対象アプリ、選んだ認証方法を記録します。ブラウザー変更やパスワード再設定を何度も繰り返しても、電話認証経路の制限そのものは解消しないことがあります。まず一度だけ別のネットワークや端末状態を確認し、その後は登録済みの別認証方法または管理者による診断へ進みます。
- エラーコード399287と画面の全文を保存する
- Request ID、Correlation ID、Timestampを控える
- SMS、音声通話、Authenticatorのどこで失敗したか記録する
- 同じ電話番号を複数の管理者アカウントで共用していないか確認する
注意：短時間にSMSや音声通話を連打すると、追加のレート制限を招く可能性があります。コードやTAP、電話番号をチャットや公開チケットへ貼り付けないでください。
2. 登録済みの別認証方法でアクセスを回復する
サインイン画面に「別の方法でサインイン」がある場合は、Microsoft Authenticatorの通知または確認コード、パスキー、FIDO2セキュリティキーなど、電話回線に依存しない方法を選びます。アクセスできたらSecurity infoで現在の方法を確認し、新しい強い認証方法を追加して動作確認した後に、問題のある電話方法を見直します。MicrosoftはSMSと音声通話から、Authenticatorなどの新しい方法へ移行することを推奨しています。
- mysignins.microsoft.com/security-infoを開く
- 新しい認証方法を追加し、別ブラウザーで実際にサインインを確認する
- 少なくとも2種類の独立した方法を登録する
- 管理者アカウントは緊急用アカウントを含めて単一の電話番号へ依存させない
注意：新しい方法の動作確認前に、最後に使える認証方法を削除しないでください。
3. 管理者がサインインログと認証方法を確認する
別のAuthentication Administratorまたは適切な権限を持つ管理者は、サインインログで失敗イベントを特定し、診断結果を確認します。その後、「Entra ID > Users > 対象ユーザー > Authentication methods」で登録方法を確認します。「Require re-register MFA」は電話番号、Microsoft Authenticator、ソフトウェアOATHを削除し、ハードウェアOATHを無効化するため、単なる再送ボタンではありません。代替の初期登録手段を用意してから実行します。
- ユーザーと時刻でサインインログを絞り込む
- FailureイベントのAuthentication Detailsと診断結果を確認する
- 認証方法ポリシーでAuthenticatorまたはTAPが対象ユーザーに許可されているか確認する
- Revoke sessionsは必要な場合だけ行い、既存セッションへの影響を利用者へ伝える
注意：「Require re-register MFA」は既存方法を破壊的に消します。TAPや別の有効な方法を準備せずに実行すると、ロックアウトを悪化させます。
4. Temporary Access Passで認証方法を安全に再登録する
TAPを使う場合は、まず「Entra ID > Authentication methods > Policies > Temporary Access Pass」で対象ユーザーまたはグループを有効化します。次に「Entra ID > Users > 対象ユーザー > Authentication methods > Add authentication method」からTAPを作成し、原則として1回限り、必要最小限の有効時間にします。ユーザーはSecurity infoへTAPで入り、Authenticatorやパスキーを登録します。TAPの実値は作成直後にしか表示されないため、安全な経路で本人へ渡します。
- TAPポリシーの対象範囲を必要なユーザーだけに限定する
- 開始時刻と有効時間を作業時間に合わせる
- 登録後に新しい認証方法で再ログインを確認する
- 不要になったTAPと古い認証方法を削除する
Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"$properties = @{ isUsableOnce = $true; lifetimeInMinutes = 60 }
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId "[email protected]" -BodyParameter $properties注意：TAPはパスワード同等以上に慎重に扱ってください。1回限りのTAPで新しい方法を登録する場合、サインインから10分以内に登録を完了する必要があるケースがあります。
5. 唯一の管理者が入れない場合は正式なサポートへ切り替える
テナント内に操作できる別管理者がいない場合は、推測で認証情報を変更し続けず、Microsoftの正式なサポートへ本人確認とテナント回復を依頼します。Request ID、Correlation ID、発生日時、対象UPN、テナントID、契約・請求を確認できる情報を準備すると、調査が進みやすくなります。復旧後は、日常利用しない緊急アクセス用アカウントと複数のフィッシング耐性認証方法を整備します。
- サポートには秘密情報ではなく識別情報とエラー情報を渡す
- 電話番号のブロック解除を保証する表現は避け、認証経路の調査を依頼する
- 復旧後に管理者の認証方法と緊急アクセス設計を棚卸しする
注意：Microsoftを名乗る相手でも、パスワード、確認コード、TAP、Authenticator承認を要求する連絡には応じないでください。
よくある質問
パスワードをリセットすればエラー399287は直りますか？
必ずしも直りません。パスワード認証とMFAの電話認証経路は別に管理されているため、SMSや音声通話が制限されている場合は、パスワードを変えても本人確認で再び止まることがあります。まず別認証方法の有無とサインイン診断を確認してください。
管理者が「Require re-register MFA」を押しても安全ですか？
影響を理解して準備した場合に限って使います。この操作は電話番号、Authenticatorアプリ、ソフトウェアOATHを削除し、ハードウェアOATHも無効化します。対象ユーザーがTAPなどで新しい方法を登録できる状態を先に用意し、実施後の確認手順まで決めてください。
復旧後もSMSをMFAの主な方法として使い続けてよいですか？
利用自体は可能な場合がありますが、MicrosoftはSMSや音声通話からAuthenticator、パスキー、FIDO2などの新しい方法へ移行することを推奨しています。少なくとも管理者アカウントは電話番号だけに依存せず、独立した複数の認証方法を登録するのが安全です。
公式情報
画面や仕様が異なる場合は、利用中の製品・契約・管理ポリシーを確認したうえで公式情報を参照してください。
- Microsoft Learn: Microsoft Entraの電話認証方法とトラブルシューティング
- Microsoft Learn: ユーザーのMFA認証方法を管理する
- Microsoft Learn: Temporary Access Passの構成と利用
- Microsoft Learn: Microsoft Entra Sign-in diagnosticsの使い方
まとめ
原因を一つずつ切り分け、変更前の状態と結果を記録しながら進めることが重要です。操作後は同じ症状が再発しないか確認し、組織管理の端末ではポリシー変更を管理者へ確認してください。
コメント