Azure ポータルにサインインしようとすると SMS による多要素認証（MFA）が求められるのに、「Sorry, we had trouble verifying your account. Please try again.（エラー コード: 399287）」と表示されて先へ進めない――しかもサポート チケットの作成にもサインインが必要で、完全に行き詰まってしまうケースがあります。本記事では、実際にあった事例をベースに、原因の整理と、ユーザー側・管理者側が取るべき対処、そして再発を防ぐための Azure / Microsoft Entra ID の運用ベストプラクティスを詳しく解説します。
Azure サインインで SMS 多要素認証が失敗するケースの全体像
今回取り上げるのは、次のような状況です。
- Azure ポータル（および他の Microsoft 365 などクラウド サービス）にサインインしようとすると SMS 認証が必須になっている
- 登録済みの携帯電話番号宛に SMS を送信しようとすると、画面上に
Sorry, we had trouble verifying your account. Please try again.（エラー コード: 399287）
と表示され、認証が完了しない - サポート チケットの作成や、管理ポータルのアクセス自体にもサインインが必要なため、自己解決の手段がほとんどない
このような状況では、「パスワードは合っているのになぜ？」という心理的な不安に加え、業務への影響（管理ポータルに入れない／アプリが使えない／ライセンスの更新ができない 等）も大きくなります。
実際にあった事例では、バックエンド側でアカウントのブロック解除と “悪評（bad reputation）” のクリアが行われたことで、SMS 認証が通るようになりました。さらに、Microsoft Authenticator アプリ（プッシュ通知やワンタイム パスコード）を登録して「SMS 依存」から脱却することで、同様のトラブルが起こりにくい構成へ改善しています。
実際の解決内容：バックエンドでのブロック解除と悪評クリア
発生していた症状
実例では、次のような症状が確認されていました。
| 項目 | 状況 |
|---|---|
| パスワード認証 | 正しいパスワードでサインインすると SMS 認証画面までは進む |
| SMS 送信 | 送信ボタンを押すと即座にエラー 399287 が表示され、コード入力画面に進まない／またはコード入力後にエラー |
| 他のサービス | Azure ポータルだけでなく、同じアカウントを使うサービス全般で同様にブロックされる可能性あり |
| サポート チケット | 管理ポータルに入れないためオンラインでのチケット起票ができない |
つまり、ID・パスワードは正しいものの、MFA の SMS ステップで「アカウント保護の観点からブロックされている」状態と考えられます。
最終的に行われた対応
このケースでは、Microsoft 側のサポートと連携が行われ、次のような対応が実施されました。
- バックエンド側で当該アカウントのブロック解除
- 電話番号やアカウントに紐づく “悪評（bad reputation）” のクリア
（短期間の連続失敗や、テレコム側の評価、疑わしいトラフィックなどにより付与される評価をリセット） - ユーザーに Azure ポータルへの再サインインを実施してもらい、SMS 認証の正常動作を確認
- その上で、Microsoft Authenticator アプリの登録（プッシュ通知／TOTP）を有効化し、以後はアプリ認証を主に利用する構成へ切り替え
ポイントは、「エラー 399287 だからといってユーザーの操作だけで解消できるとは限らない」という点です。多くの場合、バックエンドでのブロック解除が必要になり、そのためには管理者やサポート チームの介入が求められます。
なぜサインインできないとサポートにもたどり着けないのか
組織の Azure / Microsoft 365 テナントでは、サポート チケットの起票に「管理者権限＋サインイン」が必須となるケースがほとんどです。そのため、
- 唯一のグローバル管理者がロックされた
- 他の管理者は登録していない、または不在
といった状況では、組織としてサポートにアクセスできなくなるリスクがあります。これを防ぐには、後述するように、
- 複数の管理者アカウント（かつ異なる認証方法）を用意する
- ブレークグラス用のアカウントを厳格に管理しつつ準備しておく
といった運用が重要になります。
エラー 399287 のよくある原因と考え方
エラーコード 399287 自体は、公開されているドキュメントが多くありません。ただし、実際の事例や挙動から、「個別アカウントの保護判定（リスク評価）」に起因しているケースが多いと考えられます。
典型的な要因を整理すると、次のようになります。
| 原因カテゴリ | 想定される内容 | どこで対処するか |
|---|---|---|
| 通信・番号評価 | 短時間に SMS 認証失敗が連続した／海外からの発信・転送が疑われる／テレコム側のスパム判定等により、電話番号やトラフィックに「悪評」が付いた | サービス側・テレコム側のバックエンド。ユーザーや管理者からサポートへエスカレーションが必要 |
| テナント設定 | 条件付きアクセス ポリシー、MFA の再登録要求、特定の認証メソッド（SMS）の使用制限などの影響 | テナント管理者がポータルの設定やログを確認して調整 |
| SMS 不達 | 電波状況、ローミング、電話番号の形式、迷惑 SMS フィルタなどで、実際には SMS が届いていない・遅延している | ユーザー側の端末確認、キャリア側の設定、番号表記の修正など |
重要なのは、「入力ミスだけが原因とは限らない」ということです。本人が正しく操作していても、サービス側が「不正の可能性あり」と判断すれば、あえてブロックするように設計されています。これはセキュリティ上は正しい動きですが、誤検知や過剰防御が起きると、今回のような業務影響が出てしまいます。
通信・番号評価の問題
SMS 認証はテレコム（電話キャリア）との連携で実現されています。短期間に大量の認証 SMS が送信される、疑わしい番号帯に集中している、海外経由のトラフィックが多い…といった状況では、
- テレコム側がスパムや不正利用と判断してブロック
- クラウドサービス側が「IRSF（国際通話収益詐欺）」などを警戒して一時的に拒否
といった制御が働く場合があります。IRSF に悪用されると、サービス側・テレコム側の双方に損失が出るため、かなり敏感に検知される傾向があります。
テナント設定（条件付きアクセス、MFA ポリシー）との関係
Azure / Microsoft Entra ID のテナントでは、管理者がさまざまな条件付きアクセス ポリシーや MFA 設定を構成できます。例えば、
- 特定の国・地域からのアクセスのみ SMS を許可
- 「セキュリティの高い認証方法のみ許可」として SMS を禁止
- MFA の再登録を必須にしている（古い電話番号しか登録していないユーザーが弾かれる）
こうした設定と、ユーザーのアクセス元（IP アドレス、デバイス、場所など）が組み合わさることで、結果として SMS 認証がエラーとなる場合があります。
SMS 配信そのものの問題
単純に「SMS が届かない」ケースもあります。例えば、
- 機内モードや圏外になっている
- 現地キャリアとのローミング設定が無効
- 迷惑 SMS フィルタでブロックされている
- 電話番号の国番号や先頭の 0 の扱いが正しくない
この場合は、エラー 399287 というコードが出ないこともありますが、「SMS を送信しました」から先に進めない・コードが届かないといった形でユーザー体験としては似た状況になります。
エンドユーザーがすぐに試すべき対処
ここからは、ユーザーの立場で「いまこの瞬間にできること」を整理します。大きく分けると、
- 別の認証方法を使って突破する
- 管理者やサポートに適切に助けを求める
の 2 パターンです。
別の認証方法が登録済みならそちらを使う
すでに次のような認証方法を登録している場合、SMS の代わりにそれらを選択できる場合があります。
- Microsoft Authenticator アプリのプッシュ通知（番号一致など）
- Microsoft Authenticator アプリのワンタイム パスコード（TOTP）
- バックアップ電話番号宛の音声通話
- FIDO2 セキュリティキー／パスキー
サインイン画面に「別の方法でサインインする」「別の検証オプション」といったリンクが表示されている場合は、そこから他のメソッドを選べるかどうかを確認してみてください。
| 認証方法 | メリット | 確認ポイント |
|---|---|---|
| Microsoft Authenticator（プッシュ） | 操作が簡単で高速。フィッシング耐性が高い設定も可能 | スマホの通知がオフになっていないか、アカウントが登録済みか |
| Microsoft Authenticator（TOTP） | オフラインでも利用可能。番号一致が使えない環境でも有効 | アプリ内でアカウントを選ぶと 30 秒ごとのコードが表示されるか |
| FIDO2 セキュリティキー／パスキー | フィッシング耐性が高い。デバイス紐づけも可能 | ブラウザや OS が FIDO2／パスキーに対応しているか |
| バックアップ電話への音声通話 | SMS が届かない環境でも利用できる場合がある | 番号が最新か、国番号や桁数が正しいか |
管理者に状況を正確に伝える
別の認証方法も選べない場合、テナント管理者に助けを求めることが最も重要です。その際には次の情報を分かりやすく伝えると、調査がスムーズになります。
- 使用しているアカウント（例: [email protected]）
- エラー画面に表示されているメッセージとエラーコード（例: 399287）
- どの画面でエラーになるか（SMS 送信前／コード入力後など）
- 試した回数と、おおまかな時間帯
- 現在いる場所（国・地域）とネットワーク（社内 LAN / VPN / 自宅など）
管理者はこれらの情報をもとに、サインインログやリスク検知を調査し、必要に応じて Microsoft サポートにエスカレーションできます。
サインイン不要のサポート チャネルを使う
組織によっては、次のような「サインイン不要」のヘルプデスクやサポート窓口が用意されていることがあります。
- 社内の IT ヘルプデスク（電話・メール・チャット）
- パートナー会社や MS 認定リセラーのサポート窓口
「Azure にサインインできないので、管理者画面からチケットを作成できない」という状況も含め、まずは組織内のサポート体制に相談することが重要です。組織の方針に従い、外部の Microsoft サポートに連絡してもらいましょう。
テナント管理者が確認・対応すべきポイント
次に、テナント管理者の視点での確認事項と対処手順を整理します。管理者側でできることは、おおまかに次の 4 つです。
- ユーザーの強力な認証情報の確認・リセット
- 一時アクセス パス（TAP）の発行と案内
- サインインログやリスク検知の確認とチューニング
- Microsoft サポートへのエスカレーション（バックエンド解除依頼）
ユーザーの強力な認証情報をリセットする
管理ポータル（Microsoft Entra 管理センターなど）から、該当ユーザーの MFA 情報を確認し、必要に応じてリセットします。代表的な対応は次のとおりです。
- 強力な認証方法（Authenticator、FIDO2 など）を再登録必須にする
- SMS / 音声通話の番号が古い場合は、ユーザーに最新番号を確認の上で更新する
- 「すべての認証方法を一旦クリア → 再登録を求める」ことで整合性を取り直す
この際、ユーザーには「再登録の流れ」を事前に周知し、操作手順を分かりやすく案内することが大切です。
一時アクセス パス（TAP）の発行と利用
テナントで 一時アクセス パス（Temporary Access Pass: TAP） を有効化している場合、TAP は非常に強力な回復手段となります。
- 管理者が、一定時間のみ有効なワンタイム コード（TAP）を発行
- ユーザーは TAP を使ってサインインし、そのセッション中に Authenticator や FIDO2 などのメソッドを再登録
TAP 自体も強力な認証方法の一種なので、発行・伝達のプロセスは厳重に行う必要がありますが、「電話番号が使えない」「Authenticator アプリを失った」などのトラブル時に非常に有効です。
サインインログとリスク検知の確認
エラー 399287 が頻発するユーザーや IP アドレスがないか、次のような観点でログを確認します。
- サインインがどの場所（国・地域）から来ているか
- 同一 IP / デバイスからの短時間の連続試行がないか
- Identity Protection などのリスク検知が「高」や「中」でフラグしていないか
もし誤検知や過剰なポリシー設定が疑われる場合、
- 条件付きアクセスの条件を見直す（例：信頼済み場所の定義、サインインリスクのしきい値）
- リスクの自動ブロックではなく、サインイン後の追加検証に切り替える
といった調整を検討します。
Microsoft サポートにバックエンド解除を依頼する
ユーザー側・管理者側でできる操作を行っても解決しない場合、Microsoft サポートに「アカウントのブロック解除と悪評クリア」を依頼することになります。その際は次の情報を整理しておくとスムーズです。
- 影響を受けているユーザーの UPN（メールアドレス）
- エラーが発生したおおよその日時
- エラー メッセージとコード（例: 399287）
- アクセス元の国・地域、IP アドレスの情報（可能な範囲）
- 組織側で実施済みの対処（MFA リセット、TAP 発行など）
サポートでの確認の結果、必要と判断された場合には、エンジニアリング チームがバックエンド側でブロック解除を行います。その後、ユーザーに再サインインと Authenticator の登録を案内する、という流れになります。
再発防止のための恒久対策（ベストプラクティス）
同じようなトラブルを繰り返さないためには、「SMS 認証が壊れたら終わり」という構成から脱却し、フィッシング耐性の高い認証方法を主力とした多層的な設計が必要です。
SMS / 音声通話は “予備” に格下げする
現在のベストプラクティスでは、
- Microsoft Authenticator（番号一致・アプリ内確認・TOTP）
- FIDO2 セキュリティキー／パスキー
などのフィッシング耐性の高いメソッドを主力に据え、SMS / 音声通話はあくまで「予備」として位置付けることが推奨されています。
理由としては次のような点が挙げられます。
- SMS / 音声通話は IRSF（国際通話収益詐欺） などテレコムを悪用した攻撃のリスクが高い
- 通信環境やキャリアの事情により、配信品質が安定しないことがある
- フィッシングサイト上でもコードを入力させやすく、ソーシャルエンジニアリングに弱い
一方で、「スマホを持たないユーザーがいる」「一部の業務端末ではアプリインストールが制限されている」といった事情から、SMS / 音声通話を完全に廃止できない組織も多くあります。そのような場合でも、「主力は Authenticator / FIDO2、SMS はバックアップ」という設計にしておくだけで、エラー 399287 のような局面での影響を大きく減らせます。
認証方法を最低 2 つ以上登録させる
ユーザーごとに、最低でも次のような構成を目指すと安心です。
- Microsoft Authenticator（プッシュ ＋ TOTP）
- FIDO2 セキュリティキーまたはパスキー
- 予備としての SMS / 音声通話
テナントのポリシーとして「登録必須の認証方法数」を 2 つ以上に設定し、アカウント発行時のオンボーディング手順に組み込んでおくと、後から慌てて回復手段を用意する必要が少なくなります。
回復手段の事前整備（TAP・ヘルプデスク検証・ブレークグラス）
強固な MFA を導入しても、「利用者がスマホを紛失した」「番号が変わった」などの理由で認証できなくなる可能性はゼロにはなりません。そのため、「最後の砦」となる回復手段を設計しておくことが重要です。
| 回復手段 | 概要 | ポイント |
|---|---|---|
| 一時アクセス パス（TAP） | 管理者が発行する、一定時間だけ有効なワンタイム コードでのサインイン手段 | 発行フローと本人確認手順を明確にし、悪用されないよう厳格に運用する |
| ヘルプデスク検証 | 電話などで利用者の本人確認を行い、MFA リセットなどの操作を代行する | 質問項目や確認手順をテンプレート化し、「なりすまし」に悪用されないようにする |
| ブレークグラス アカウント | 非常時にのみ使用する、特別に厳格管理された管理者アカウント | 普段はサインイン禁止・パスワード保管方法を厳格に管理し、定期的に有効性を確認する |
条件付きアクセスとフィッシング耐性メソッドの優先度づけ
条件付きアクセス ポリシーでは、「どの認証方法を優先するか」「どの条件で追加の MFA を要求するか」を細かく制御できます。再発防止の観点では、次のような設計が有効です。
- 信頼済みデバイス・場所からのアクセスでも、「高リスク時」は必ず強力な MFA を要求
- フィッシング耐性の低い SMS / 音声通話は、あくまで限定的な利用にとどめる
- リスクベースのポリシーを設定しつつ、誤検知が多い場合は段階的にチューニングする
こうしたポリシー設計により、「必要なときにはしっかり守る」「過剰なときは適度に緩める」というバランスを取りつつ、エラー 399287 のようなトラブル時にも代替手段にスムーズに切り替えられるようになります。
運用ルール：失敗が続いたときの連絡フローを明文化する
最後に、技術的な対策だけでなく、運用ルールを文書化しておくことが非常に大切です。具体的には、次のような点を決めておきます。
- MFA が連続で何回失敗したら、どこに連絡すべきか
- ユーザーは、どの情報を伝えればよいか（アカウント名、エラーコード、時間など）
- ヘルプデスク側は、どの手順で確認・対応を進めるか
- 管理者がサポートにエスカレーションする基準と、その際に必要な情報
こうしたルールがあらかじめ決まっていれば、実際にトラブルが発生した際も「誰が何をすれば良いか」が明確で、復旧までの時間を短縮できます。
よくある質問（FAQ）
エラー 399287 が出たら、必ず Microsoft に連絡しないといけませんか？
必ずしもそうとは限りません。まずは、
- 別の認証方法（Authenticator、FIDO2 など）が使えないか確認する
- テナント管理者に連絡し、MFA のリセットや TAP の発行を依頼する
といった手順で解消するケースもあります。それでも解決しない場合に、管理者から Microsoft サポートにエスカレーションする流れが一般的です。
個人の Microsoft アカウントでも同じようなことは起きますか？
ここで説明している内容は主に 組織の Azure / Microsoft 365 テナント（Microsoft Entra ID） に対するものですが、個人の Microsoft アカウントでも類似のエラーが発生することはあります。その場合は、個人アカウント向けのサポート（Web フォームやチャットなど）を利用することになります。
電話番号を変更した後にサインインできなくなりました。どうすればいいですか？
電話番号変更に伴って SMS が届かなくなったケースでは、
- 既に Authenticator や FIDO2 が登録済みであれば、そちらを使ってサインインし、新しい番号を登録し直す
- 他の方法も使えない場合は、テナント管理者に連絡して TAP の発行や MFA リセットを依頼する
といった流れになります。電話番号変更の前後で、Authenticator や FIDO2 を必ず登録しておく運用が望ましいと言えます。
まとめ：エラー 399287 と賢く付き合うために
本記事で取り上げたポイントを改めて整理します。
- 症状：Azure にサインインする際、SMS 多要素認証が「エラー 399287」で失敗し、サポート チケットも作成できず行き詰まることがある。
- 原因：短期間の連続失敗やテレコム側の評価、テナント側の条件付きアクセスや MFA 設定などにより、アカウントや電話番号に「悪評」が付与され、サービス側が保護のためブロックしているケースが多い。
- 実際の解決例：Microsoft 側でバックエンドのブロック解除と悪評クリアが行われ、再度 SMS 認証が通るようになった。その上で、Microsoft Authenticator を登録し、以後はアプリ認証を主力とする構成に改善した。
- エンドユーザーの対処：別の認証方法でのサインインを試す／管理者に正確な情報を伝える／サインイン不要のサポート ルートを活用する。
- 管理者の対処：MFA 情報のリセット／TAP の発行／ログやリスク検知の確認・チューニング／必要に応じた Microsoft サポートへのエスカレーション。
- 再発防止：Authenticator と FIDO2 を主力とし、SMS / 音声通話は補助的なメソッドとして扱う。回復手段（TAP、ヘルプデスク検証、ブレークグラス アカウント）を事前に整備し、失敗時の連絡・対応フローを明文化する。
エラー 399287 は、ユーザーにとっては非常にストレスフルな状況を生みますが、その裏側では「アカウントを守るため」の仕組みが働いているとも言えます。だからこそ、技術的な対策と運用の両面から「壊れても復旧しやすい認証基盤」を設計することが、Azure / Microsoft Entra ID を安全かつ安定して利用していく上での鍵になります。
コメント