Azure ログインで本人確認できないエラー399287の原因と対処法｜SMS認証ブロック時の解決手順

Azure ポータルにサインインできているのに、最後の「本人確認」だけが何度やっても通らない。エラー 399287 とともに「アカウントの確認に問題が発生しました。もう一度お試しください。」と表示され、業務が止まってしまう――この記事では、実際に Microsoft 側のバックエンド解除で解決したケースをベースに、原因の考え方と具体的な対処・再発防止策を詳しく整理します。

Azure ログインで発生するエラー 399287 とは？

Azure ポータルにサインインした際、次のようなメッセージが表示されて本人確認（多要素認証）が完了せず、ポータルが利用できない場合があります。

アカウントの確認に問題が発生しました。もう一度お試しください。

このとき内部的には エラーコード 399287 が発生しており、電話番号（SMS や音声通話）を用いた本人確認がブロックされている可能性が高い状況です。

よくある状況としては、次のようなパターンが見られます。

2025年1〜2月までは同じアカウント・同じ電話番号で問題なく認証できていた
現在も Azure サブスクリプションは有効で、請求や契約には問題がない
ユーザー名とパスワードは正しく、サインイン自体は通るが「本人確認ステップ」で失敗する
SMS 認証、音声通話、利用可能な代替ログイン方法を試しても突破できない
パスワードリセットを実施しても状況が変わらない

このような場合、多くの管理者は「Azure AD（現 Microsoft Entra ID）の設定ミス」や「ユーザーのロックアウト」を疑いますが、実際には電話番号や発信国などの“レピュテーション（評判）”が低く判定され、Microsoft のテレフォニー詐欺対策システムによって自動的にブロックされているケースが存在します。

症状の整理：どのようなときに「本人確認できない」状態になるのか

まずは、エラー 399287 で想定される症状を整理しておきます。次の表は、よくある問い合わせの状況をまとめたものです。

項目	状況
サインイン ID	正しい UPN（メールアドレス形式）でサインイン可能
パスワード	正しく認証される。誤り時は別のエラーが出る
本人確認ステップ	SMS や音声通話のコード入力前後で「アカウントの確認に問題が発生しました」となり進めない
MFA 方法	電話番号（SMS／音声）を主として登録している
時期	2025年1〜2月までは正常に利用できており、あるタイミングから突然失敗し始める
サブスクリプション	有効状態。請求未払いなどはない
試行済み対策	パスワードリセット、ブラウザー変更、シークレットモード、キャッシュ削除等を試すも改善なし

ここまでの状況が揃っている場合、クライアント側の一時的な不具合や設定ミスではなく、バックエンド側の電話番号ブロック を疑うのが合理的です。

背景：電話番号レピュテーションとテレフォニー詐欺（IRSF）対策

エラー 399287 の裏側で何が起きているのかを理解するために、Microsoft が採用しているテレフォニー詐欺対策の考え方を押さえておきましょう。

IRSF（国際収益分配詐欺）とは

IRSF（International Revenue Share Fraud：国際収益分配詐欺） は、国際電話料金を悪用して収益を得るタイプの詐欺です。攻撃者は特定の国や番号帯に大量の発信を行い、その通話料金の一部を不正に受け取ります。

この手口を防ぐため、通信事業者やクラウド事業者は「どの番号・どの国からどのような頻度で発信されているか」を基にレピュテーション（評判）スコアを管理し、不自然な挙動を見つけると、その番号や番号帯をブロックする仕組みを持っています。

電話番号レピュテーションが Azure MFA に影響する仕組み

Azure で SMS や音声通話を利用した MFA を行う場合、裏側では次のような流れでテレフォニーが利用されています。

ユーザーが Azure ポータルにサインインし、電話番号によるコード送信を選択する
Microsoft のテレフォニー基盤が、登録された電話番号宛に SMS／音声通話を発信する
その際、発信元・発信先の電話番号や国コードのレピュテーションがチェックされる
レピュテーションが一定の閾値を下回ると、セキュリティ保護のために通話／SMS がブロックされる

このブロックは、多くの場合ユーザーやテナント管理者の画面からは直接確認できず、Microsoft 側のバックエンドでのみ把握できる内部フラグとして扱われます。そのため、ユーザー側で電話番号を変更したりパスワードをリセットしたりしても、根本的なブロック状態は解除されません。

どんなときにレピュテーションが悪化するのか

要因	例
大量・高頻度な認証試行	短時間に何度も SMS 認証を繰り返した場合、攻撃と誤認されることがある
疑わしい番号帯の利用	国際プレミアム番号など、歴史的に詐欺でよく使われる番号帯
発信国のリスク	特定の国や地域からの通信が全体的に高リスクと判定されているケース
事業者・回線の特性	一部の VoIP、プリペイド、仮想番号などはレピュテーションが不安定になりやすい

今回のケースでは、Microsoft 側の製品グループ／エンジニアリングチームによる「バックエンドでのブロック解除」と「電話番号レピュテーションのクリア」を行った結果、SMS 認証が再び利用可能になった、という流れでした。

結論：最終的な解決策は「Microsoft 側でのブロック解除」

ユーザー側・管理者側が行える操作には限界があり、今回のようなエラー 399287 のケースでは、最終的に次の対応が決め手となりました。

Microsoft 製品グループ／エンジニアリングによるバックエンド操作で、該当アカウントに紐づくブロック状態を解除
同時に、問題の電話番号に紐づく「悪評（reputation）」情報をクリア
解除後は、Azure ポータルへのサインインおよび SMS 認証が正常に完了

ポイントは、ユーザー操作だけでは解除できないタイプのブロックが存在するという事実です。これを踏まえ、次の章からは「すぐにやるべきこと」と「中長期的な対策」を整理していきます。

すぐにやるべき対処：ユーザー・管理者共通のアクション

Microsoft サポートへ必要情報をまとめて提示する

バックエンド側のブロックは、サポート経由で Microsoft に調査・解除を依頼する必要があります。その際に必要となる情報を、あらかじめ整理しておきましょう。

情報項目	内容	備考
エラーコード	399287	画面に表示されない場合でも、ログやサポートとの会話で確認
Request ID	サインインエラー画面に表示される GUID	ユーザー単位のトレースに必須
Correlation ID	同じく GUID 形式	複数の内部ログを紐づけるために使用
発生日時	UTC でのタイムスタンプ	タイムゾーンを誤ると調査が難航するため注意
国／地域	ユーザーが実際にアクセスしている国・地域	VPN やプロキシ利用の有無も伝えるとベター
電話番号	国コードを含む形式（例：+81xxxxxxxxxx）	MFA に登録している番号を正確に記載

サポートにケースを起票する際のポイントは、「バックエンド側でのブロック有無の確認」と「電話番号レピュテーションのクリア」を明示的に依頼することです。

問い合わせ文のイメージ

Azure ポータルでのサインイン時に本人確認ができず、エラー 399287 が発生しています。
該当ユーザーは 2025年1〜2月までは正常に電話番号での MFA 認証ができていましたが、
現在は「アカウントの確認に問題が発生しました。もう一度お試しください。」と表示されます。

下記の情報を基に、バックエンド側で当該アカウント／電話番号に対するブロック有無および
電話番号レピュテーションの状態をご確認いただき、必要に応じてブロック解除／レピュテーションのクリアをお願いできますでしょうか。

・ユーザー UPN：
・発生日時（UTC）：
・エラーコード：399287
・Request ID：
・Correlation ID：
・国／地域：
・MFA に登録している電話番号（E.164形式）：+81…

MFA 手段を「より安全な方法」中心に組み替える

電話番号のブロックが解除されたとしても、そもそも SMS／音声通話はテレフォニー詐欺に弱く、安全性も相対的に低い という前提は変わりません。今後のトラブルを減らすためにも、MFA の主役は Microsoft Authenticator（アプリ認証） に移行しておくことを強く推奨します。

MFA 手段	主な特徴	推奨度
Microsoft Authenticator（プッシュ通知）	スマホアプリに通知が届き、承認ボタンをタップするだけ。フィッシング耐性も高い	◎（第1候補）
Microsoft Authenticator（TOTP コード）	アプリ内の 6 桁コードを入力。オフラインでも利用可能	◎
FIDO2 セキュリティキー／パスキー	物理キーや OS のパスキー機能を利用。フィッシング耐性が非常に高い	◎（併用推奨）
SMS／音声通話	電話番号宛にコードを送信。テレフォニー詐欺やレピュテーション低下の影響を受けやすい	△（予備扱い）

実運用では次のような構成が現実的です。

第1候補：Microsoft Authenticator（プッシュ）
第2候補：同じく Authenticator の TOTP コード
バックアップ：別端末の Authenticator、FIDO2 セキュリティキー／パスキー
最終予備：SMS／音声（どうしても必要なユーザーのみ）

緊急時のために「一時アクセスパス（TAP）」の運用を決めておく

すでに本人確認ができない状態では、ユーザー自身が MFA 設定を変更することができません。Microsoft Entra ID の管理者は、一時アクセスパス（Temporary Access Pass, TAP） を用意しておくことで、次のような復旧フローを取ることができます。

管理者が対象ユーザーに対して TAP を発行する
ユーザーは TAP を使ってサインインし、新しい Authenticator や FIDO2 キーを登録する
登録完了後、TAP を無効化しておく

この運用を事前に設計しておくことで、「MFA が壊れてしまい何もできない」という事態を大幅に減らすことができます。

管理者向け：Microsoft Entra ID 側で見直すべき設定

次に、テナント管理者の視点で「どの設定を見直すべきか」を整理します。電話番号ブロックは Microsoft 側の問題であっても、その影響を最小限に抑える設計は管理者側で行うことができます。

認証方法ポリシーの確認と整理

Microsoft Entra ID の「認証方法ポリシー」では、どの認証手段を許可するかを制御できます。エラー 399287 をきっかけに、次のように整理しておくと安全です。

Authenticator アプリ（プッシュ／TOTP）は必ず許可
FIDO2 セキュリティキー／パスキーも許可し、可能なら必須に近い位置づけに
SMS／音声は「一部のユーザーにのみ許可」または「特定のグループでのみ利用可」とする
メールによるコードなど、フィッシングに弱い手段は極力利用しない

認証の強度（Authentication Strength）の活用

認証の強度（Authentication Strength） を使うと、「このアプリにはフィッシング耐性の高い MFA 必須」といったポリシーを柔軟に構成できます。例えば：

管理ポータル（Azure ポータル、Microsoft 365 管理センターなど）には「強い認証」を要求
一般ユーザー向けの業務アプリには「標準の認証」を要求
SMS のみでは「強い認証」を満たさないように定義

これにより、電話番号に問題が発生した場合でも、少なくとも管理系アカウントは Authenticator や FIDO2 のみで運用できるようになります。

条件付きアクセスとサインイン／リスク検出ログの確認

条件付きアクセスでは、ユーザー・デバイス・アプリ・場所などに応じて MFA を要求するルールを設定できます。エラー 399287 のような事象が発生した際には、次のログを重点的に確認しましょう。

ログ種別	確認ポイント
サインインログ	対象ユーザーのサインイン試行を絞り込み、MFA ステータスや失敗理由を確認
リスク検出ログ	異常な場所／デバイスからのサインインが増えていないか、リスクレベルの推移を確認
監査ログ	MFA 設定の変更や認証方法ポリシーの変更が直近で行われていないか確認

サインインログでは、「MFA 拒否」「電話ベースの MFA 失敗」といったステータスが出ていないかをチェックし、再発の兆候を早期に検知します。

多要素認証のベストプラクティスと構成パターン

エラー 399287 は「電話番号ベースの認証に依存しすぎる設計のリスク」を浮き彫りにします。ここでは、Azure／Microsoft Entra ID 環境で現実的に取り得る MFA のベストプラクティスを具体的に示します。

認証方式ごとの比較

方式	強み	弱み	向いているケース
Authenticator プッシュ	操作が簡単、フィッシング耐性が比較的高い、ほとんどのユーザーに展開可能	スマホが必須／電池切れ・紛失のリスク	一般ユーザー、管理者全般
Authenticator TOTP	オフラインでも利用可能、バックアップ用途に最適	コード入力が必要でプッシュよりやや手間	電波状況が不安定な現場、海外出張など
FIDO2 キー／パスキー	フィッシング耐性が非常に高い、パスワードレス構成に向く	キーの配布・保管が必要、運用設計のハードルがやや高い	特権管理者、開発者、機密性の高いシステム利用者
SMS／音声	スマホさえあれば利用可能、導入初期のハードルが低い	テレフォニー詐欺・番号レピュテーションに左右される、安全性は相対的に低い	どうしてもアプリを入れられない一部ユーザー向けの予備

実際の解決例から学べるポイント

今回のケースで行われた最終対応は、次の 2 点に集約されます。

Microsoft 側でのバックエンドブロック解除
電話番号レピュテーションのクリア

この結果、Azure ポータルへのサインイン時に SMS を用いた本人確認が再び成功するようになり、ユーザーは元通り業務を再開できました。

この過程で見えてきた教訓は次の通りです。

どれだけクライアント設定やブラウザーを変えても解決しない問題は、早めに「クラウド側のブロック」を疑う
Request ID や Correlation ID、UTC 時刻を押さえておくとサポートの調査が格段にスムーズになる
「電話番号認証に依存しない MFA 設計」こそが長期的な安定運用の鍵

再発防止のための詳細チェックリスト

最後に、再発防止の観点から「ここまでやっておけば安心」と言えるチェックポイントを、少し踏み込んで解説します。

発生時刻とトレース情報を必ず残す

サインインエラーが出たタイミングで、画面に表示される Request ID／Correlation ID／UTC 時刻をスクリーンショットで保存
可能であれば、ユーザー名やアクセス元 IP、利用端末の種別も一緒にメモ
これらの情報は、サポートにとって「ログの中から該当イベントを探すための鍵」となる

Microsoft へのケース起票時に情報を出し切る

最初の問い合わせで、国／地域・電話番号・影響ユーザー数・発生日などをまとめて提供
「電話番号レピュテーションの状態」「バックエンドでのブロック解除可否」の確認を明示的に依頼
やり取りの中で得られた知見（どのルールに引っかかったかなど）は、社内ナレッジとして必ず残す

Authenticator と予備手段の登録徹底

新規ユーザー作成時のオンボーディング手順に「Authenticator 登録」を必ず組み込む
スマホ紛失などの事故に備え、管理者・重要ユーザーには「予備端末」を用意する
年に 1 回程度、全ユーザーに対して「MFA 手段の棚卸し」を実施し、使われていない番号や古い端末を整理

認証ポリシー・条件付きアクセスの定期レビュー

新しい認証方式（例：パスキー）が使えるようになったタイミングで、ポリシーに反映する
条件付きアクセスのルールが増えすぎていないか、競合していないかを半年〜1年ごとに確認
特権ロール（グローバル管理者など）のアカウントが、必ず強固な MFA を使っているかを点検

SMS／音声通話の利用は最小限に

短信・通話のコストやレピュテーションリスクを考慮し、「どうしても必要なケース」に限定
個人所有のプリペイド SIM や、レピュテーションが不安定な番号帯は極力避ける
可能であれば、企業契約でレピュテーションの安定した番号を用意し、そこに集約する

ユーザー教育で押さえておきたいポイント

技術的な対策だけではなく、ユーザー教育も重要です。現場ユーザーに対しては、次のようなメッセージを平易な言葉で伝えておきましょう。

「SMS よりもアプリ認証の方が安全で、トラブルも少ない」こと
スマホを機種変更した際は必ず Authenticator を移行し、古い端末の登録を削除すること
異常なサインイン通知や、身に覚えのない認証要求が来たら、必ず管理者に連絡すること

また、IT 部門は「MFA が効かなくなったときの駆け込み先」を明確に示し、TAP や復旧フローをユーザーに周知しておくと安心です。

まとめ：エラー 399287 を“設計見直し”のきっかけに

Azure ログイン時のエラー 399287 は、一見すると「よくわからない一時的な不具合」に見えますが、その裏側には 電話番号レピュテーションとテレフォニー詐欺対策 という、クラウドサービスならではの仕組みが存在します。

今回のように Microsoft 側のバックエンドでブロックを解除してもらうことは、あくまで対症療法に近い側面があります。長期的には、

Authenticator や FIDO2 を中心とした「電話番号に依存しない MFA 設計」への移行
認証方法ポリシー／認証の強度／条件付きアクセスの整理
一時アクセスパスを含む復旧フローの整備
ユーザー教育と定期的な棚卸し

といった施策を組み合わせることで、同様の事象が発生した際にも「大きな業務停止につながらない」強い認証基盤を構築できます。

もし現在すでにエラー 399287 に直面している場合は、本記事のチェックリストやサポートへの問い合わせテンプレートを参考に、まずはバックエンドブロックの有無を確認しつつ、同時並行で MFA 設計の見直しに着手することをおすすめします。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure ログインで本人確認できないエラー399287の原因と対処法｜SMS認証ブロック時の解決手順

Azure ログインで発生するエラー 399287 とは？

症状の整理：どのようなときに「本人確認できない」状態になるのか