Azure ポータルへのサインイン時に、MFA の SMS が届かず「エラーコード 399287」で止まってしまうと、仕事が完全に止まってしまいます。本記事では、実際に Microsoft 側のバックエンド解除で復旧した事例をもとに、「なぜ SMS 認証がブロックされたのか」「どう復旧し、再発を防ぐか」をユーザー・管理者それぞれの視点から詳しく解説します。
Azure ポータルのサインインで発生するエラー 399287 の概要
エラーコード 399287 は、Azure ポータル（Microsoft Entra 管理センターを含む）にサインインする際、SMS または音声通話による多要素認証（MFA）がブロックされたときに発生するエラーです。
典型的な症状は次のようなものです。
- ユーザー名・パスワードまでは正常に入力できる
- 本人確認の手段として「SMS」または「電話」を選択するとエラー 399287 が表示される
- SMS ワンタイムコードがまったく届かない、もしくは送信自体が失敗する
| 項目 | 内容 |
|---|---|
| エラーコード | 399287 |
| 主な現象 | SMS / 音声通話による MFA が完了せず、サインインできない |
| 影響 | Azure ポータル・Microsoft Entra 管理センター・Azure DevOps などにログイン不可 |
| 主な原因 | 電話番号または認証フローが「不正利用の疑い」としてブロックされている |
| よくある誤解 | 「携帯電話の電波が悪い」「Azure 側の一時的な不具合」だけと思い込んでしまう |
このエラーの厄介な点は、ユーザーだけでなくテナント管理者アカウントでも発生することです。管理者が SMS しか登録していない状態で番号がブロックされると、テナント全体の管理ができなくなるリスクがあります。
実際の事例：Microsoft によるバックエンド解除で復旧
今回のケースでは、ユーザーから以下の情報を添えて Microsoft サポートに問い合わせが行われました。
- エラーコード：399287
- Request Id（リクエスト ID）
- Correlation Id（相関 ID）
- Timestamp（タイムスタンプ）
- 影響を受けているユーザー UPN
- 認証に使っている電話番号（国コード付き）
サポート側の調査の結果、電話番号に紐づく不正利用疑い（いわゆる「悪いレピュテーション」）によって、バックエンドで SMS / 音声の認証が自動的にブロックされていることが判明しました。
Microsoft 側で以下の対応が行われたことで、サインインが復旧しています。
- 電話番号に対する内部的なブロックの解除
- 悪いレピュテーションのクリア（電話番号の評価リセット）
解除後は、同じ電話番号でも SMS 認証が正常に完了し、Azure ポータルへ問題なくサインインできるようになりました。
| タイミング | 状況 |
|---|---|
| 事象発生前 | 同じ電話番号で長期間 SMS 認証を利用。特に問題はなかった。 |
| 事象発生時 | 急に SMS が届かなくなり、エラー 399287 が表示されるようになった。 |
| サポート対応中 | テナント管理者側での設定変更では改善せず、Microsoft 側でブロックを確認。 |
| バックエンド解除後 | SMS 認証が復旧し、Azure ポータルへのサインインも正常に完了。 |
このように、テナント管理者の操作だけでは解除できない種類のブロックが存在することを理解しておくことが重要です。
なぜ電話番号がブロックされるのか：レピュテーションと IRSF の観点
電話番号の「レピュテーション」とは
クラウドサービスや通信事業者は、不正利用や詐欺行為を検出するために、電話番号ごとに「レピュテーション（信用評価）」を持っています。例えば、次のような特徴を持つ番号は、システム上で「危険度が高い」と判定されやすくなります。
- 短期間に大量の SMS / 通話を発信している
- 特定の国・地域への不自然な頻度の通信がある
- 過去に不正アクセスや詐欺行為と関連づけられた可能性がある
このレピュテーションが一定の閾値を下回ると、その電話番号からの SMS / 音声通話が自動的に拒否される場合があります。Azure の MFA では、この仕組みによって SMS 認証が成立せず、結果としてエラー 399287 が表示される、というわけです。
IRSF（国際収益分配詐欺）と SMS / 音声 MFA のリスク
Microsoft が SMS / 音声通話の MFA を相対的に非推奨とする背景には、IRSF（International Revenue Share Fraud：国際収益分配詐欺）と呼ばれる不正の存在があります。
- 国際電話料金が高額な国・プレミアム番号に対して、大量の発信を行わせる
- 通話料の一部が不正業者にキックバックされる構造を悪用する
- SMS / 音声認証の仕組みを踏み台にして、想定外の発信を誘発するケースもある
このような事情から、SMS / 音声による MFA は、仕組み自体が攻撃の標的になりやすいと考えられています。そのため、Microsoft は Microsoft Authenticator アプリ や FIDO2 セキュリティキー・パスキー のような、フィッシング耐性の高い認証を強く推奨しています。
ユーザーがすぐにやるべきこと：短期的な対処
まずは、エラーが一時的なものなのか、電話番号のレピュテーションによるブロックなのかを切り分けるために、ユーザー側で以下のチェックを行いましょう。
- Azure ポータルへ再サインインし、SMS 認証が完了するか確認する
- サインインできたら、すぐに Microsoft Authenticator を登録し、既定のサインイン方法を変更する
- 可能であれば、FIDO2 セキュリティキー / パスキー や OATH ハードウェアトークンも追加する
- 今後のために、エラーコード・Request Id・Correlation Id・Timestamp を必ず控えておく
| 操作 | 目的 | ポイント |
|---|---|---|
| 再サインイン | ブロックが継続中か、一時的な障害かを確認 | 時間を空けても再発するなら、番号レピュテーションが疑わしい |
| Authenticator 登録 | SMS に依存しない MFA 手段を確保 | 可能な限り 通知ベース のサインインを有効化する |
| FIDO2 / パスキー追加 | フィッシング耐性の高い認証を追加 | 管理者・特権ユーザーには必須レベルで検討 |
| エラー情報の控え | Microsoft サポートへのエスカレーションに必須 | スクリーンショット + テキストで保管しておくと安心 |
Microsoft Authenticator を既定の MFA に切り替える
なぜ SMS / 音声より Authenticator が推奨されるのか
Microsoft Authenticator は、スマートフォンアプリを使って認証を行う方式です。「番号マッチング」や「プッシュ通知承認」により、次のようなメリットがあります。
- SMS の盗聴・転送・SIM スワップ攻撃の影響を受けにくい
- ローミング中や電波の悪い環境でも、Wi-Fi さえあれば認証できる
- ワンタイムパスコード（TOTP）もアプリ内で生成できるため、オフラインでも利用可能
結果として、セキュリティと利便性を両立しつつ、電話番号のレピュテーション問題からも距離を置けるのが最大の利点です。
ユーザー側の登録手順（概要）
- スマートフォンに Microsoft Authenticator アプリをインストールする
- PC ブラウザーで Azure ポータル、または自分の セキュリティ情報管理ページ を開く
- 「セキュリティ情報」や「追加のセキュリティ確認」などのメニューから、「認証アプリ」を追加
- 画面に表示される QR コードを、スマートフォン上の Authenticator で読み取る
- テストコード（または通知承認）を使って、登録が成功したことを確認する
- 既定のサインイン方法を「Microsoft Authenticator」に変更する
ここまで完了すれば、少なくとも「SMS が使えないから Azure に入れない」という状態はかなり起こりにくくなります。
複数のバックアップ認証手段を用意する
実運用では、少なくとも 2 種類以上の認証手段を各ユーザーに持たせることが推奨されます。特に管理者や重要システムの担当者は、次のような組み合わせを検討しましょう。
おすすめの組み合わせ例
- Microsoft Authenticator（通知） + FIDO2 セキュリティキー
- Microsoft Authenticator（TOTP） + パスキー（デバイスに紐づく）
- FIDO2 セキュリティキー（2 本以上） + 予備電話番号（最終手段として）
| 認証方法 | セキュリティ | 運用コスト | コメント |
|---|---|---|---|
| SMS / 音声通話 | 低～中 | 低 | IRSF や SIM スワップ、番号レピュテーション問題に弱いため「最終手段」扱い推奨 |
| Microsoft Authenticator（通知） | 中～高 | 低 | 標準的な MFA。番号マッチングを有効にしてフィッシング耐性を高める |
| Microsoft Authenticator（TOTP） | 中 | 低 | オフラインでも利用可能。通知が使えない環境のバックアップに最適 |
| FIDO2 セキュリティキー / パスキー | 非常に高い | 中 | フィッシング耐性 MFA。管理者や高リスクユーザーには必須レベルで検討 |
| OATH ハードウェアトークン | 中 | 中 | スマホを持たないユーザー向けの選択肢。物理管理ルールが重要 |
管理者向け：認証方法ポリシーの見直し
個々のユーザー対策だけでなく、テナント全体のポリシーとして SMS / 音声通話への依存度を下げることが、再発防止には不可欠です。
認証方法ポリシーの設定場所
管理者は、Microsoft Entra 管理センターで次のように設定を確認・変更できます。
- Microsoft Entra 管理センターに管理者アカウントでサインイン
- 「セキュリティ」 > 「認証方法」 > 「ポリシー」 を開く
- 各認証方法（Microsoft Authenticator、FIDO2 セキュリティキー、SMS、音声通話など）の有効/無効や対象ユーザーを設定
おすすめの構成イメージ
| 認証方法 | 状態 | 対象ユーザーの例 | 備考 |
|---|---|---|---|
| Microsoft Authenticator | 有効（推奨） | 全ユーザー | 既定の MFA として利用。通知 + TOTP の両方を許可 |
| FIDO2 セキュリティキー / パスキー | 有効（強く推奨） | 管理者、特権ロール、重要システム利用者 | パイロット導入から段階的に拡大 |
| SMS | 限定的に有効 | 一部ユーザー（どうしても必要な場合のみ） | 「最終手段」扱いにし、利用範囲を最小化 |
| 音声通話 | 原則無効または限定的に有効 | 視覚障がい者など特別な配慮が必要なユーザー | 必要性が明確なケースに絞る |
| OATH ハードウェアトークン | 必要に応じて有効 | スマホを持たないユーザー | 配布・回収・棚卸しの運用ルールをセットで整備 |
条件付きアクセスで「認証強度」をコントロールする
Microsoft Entra の条件付きアクセス（Conditional Access）には、「認証強度」という概念があります。これを活用することで、すべてのサインインで強い認証を要求するのではなく、「リスクに応じて必要な強度を出し分ける」ことができます。
具体的な設計例
- 管理者用ポリシー： 管理ポータルへのアクセス時は「フィッシング耐性 MFA（FIDO2 / パスキー）」を必須にする
- 標準ユーザー向けポリシー： 社外からのアクセス時のみ MFA を要求し、社内ネットワークや信頼済みデバイスでは頻度を抑える
- 高リスク検出時ポリシー： サインインリスクが高と判定された場合、パスワードリセットや強い認証を要求する
| ポリシー名 | 対象 | 要求する認証強度 | 目的 |
|---|---|---|---|
| Admin-HighSecurity | 全管理者・特権ロール | フィッシング耐性 MFA（FIDO2 / パスキーなど） | テナント管理機能へのアクセスを最も強固に保護する |
| User-StandardMFA | 全ユーザー | Authenticator または FIDO2 | 社外アクセス時に基本的な MFA を強制する |
| RiskySignIn-Remediate | サインインリスクが高のユーザー | 強い MFA + パスワード変更 | 乗っ取り疑いのあるアカウントを早期に是正 |
このように設計しておけば、SMS が使えない状況でも、より安全な認証方法で業務を継続できるようになります。
ユーザー個別設定とロールごとの強度設計
テナント全体のポリシーに加え、ユーザーごとの認証方法設定を丁寧に整えることも重要です。
ユーザー個別の認証方法を確認・編集する
- Microsoft Entra 管理センターで 「ユーザー」 を開く
- 対象ユーザーを選択し、「認証方法」 をクリック
- 登録済みの電話番号 / Authenticator / FIDO2 キー / OATH トークンなどを確認
- 不足している認証手段を追加し、既定のサインイン方法を Authenticator または FIDO2 に設定
特に、次のようなユーザーは優先的に整備すべきです。
- グローバル管理者 / セキュリティ管理者 / Exchange 管理者 などの特権ロール保持者
- 経理・人事など、機密データへのアクセス権が広いユーザー
- 外部からのリモートアクセスが多いユーザー
ログ監視と運用：再発を防ぐために見るべきポイント
一度ブロックが解除されても、電話番号のレピュテーションが再び悪化すれば、エラー 399287 が再発する可能性があります。これを防ぐためには、ログの定期的な確認が欠かせません。
確認しておきたい主なログ
- サインインログ： 認証失敗の理由や MFA の種類を確認し、SMS の失敗が継続していないかをチェック
- Identity Protection（ユーザーリスク / サインインリスク）： 不自然な場所・デバイスからのアクセスが増えていないか
- 認証方法利用状況： ユーザーがどの認証方法をどのくらい使っているかを把握し、SMS 依存のユーザーを洗い出す
これらを定期的に確認し、SMS の失敗や不審な試行が多い番号を早期に把握することで、ブロックに至る前に対処しやすくなります。
再発・復旧フローのテンプレート
いざエラー 399287 が発生したときに慌てないよう、あらかじめ 「再発・復旧フロー」 を決めておくと運用が安定します。
- ユーザーからの報告受付： どの画面で・どのタイミングでエラーが出ているかを確認
- 代替認証の試行： Authenticator や FIDO2 キーが登録されていれば、それでサインインできるか試す
- 管理者側の確認： サインインログでエラーの詳細を確認し、ユーザー単体の問題か、広範囲な問題かを判断
- テナント設定の確認： 認証方法ポリシーや条件付きアクセスに最近の変更がないかを確認
- Microsoft サポートへのエスカレーション： テナント側操作で解決できない場合、必要情報を添えて問い合わせ
| サポートに渡すべき情報 | 内容の例 |
|---|---|
| エラーコード | 399287 |
| Request Id / Correlation Id | エラー画面の「詳細」に表示される ID をそのままコピー |
| Timestamp | 発生時刻（できれば UTC とローカル時刻の両方） |
| 対象ユーザー UPN | [email protected] 形式のサインイン名 |
| 電話番号 | +81 90-xxxx-xxxx など、国コード付き表記 |
| 影響範囲 | 単一ユーザーなのか、複数ユーザーや管理者も影響を受けているのか |
これらの情報がそろっていれば、Microsoft 側でも電話番号のレピュテーションやバックエンドブロックの有無を調査しやすくなり、復旧までの時間短縮が期待できます。
よくある質問と実務的な回答
- Q. テナント管理者だけで完全に解除できますか？
A. できない場合があります。電話番号の評価（レピュテーション）に起因するブロックは、Microsoft 側での解除が必要になることがあり、管理センター上のユーザーブロック解除だけでは不十分なケースがあります。 - Q. 電話番号を変えればすぐ解決しますか？
A. 新しい番号に問題がなければエラーが出ないこともありますが、根本的な対策にはなりません。最終的には Authenticator や FIDO2 による MFA を既定とし、SMS 依存を減らすことが重要です。 - Q. なぜ SMS は非推奨なのですか？
A. IRSF のような通話系の不正に利用されやすく、また SIM スワップや SMS 転送などの攻撃手法も存在します。Authenticator や FIDO2 は、これらの攻撃に対してより強い耐性を持つため、優先的に利用することが推奨されます。 - Q. 管理者が SMS しか登録しておらず、ログイン不能になった場合は？
A. その管理者自身では解決できない可能性が高く、別のグローバル管理者 または Microsoft サポート の協力が必要になります。平常時から、複数の管理者に FIDO2 / Authenticator を登録させておくことが必須です。 - Q. 個人の Microsoft アカウントでも同様の問題は起こりますか？
A. はい、起こり得ます。個人アカウントでも SMS 認証が利用されているため、番号のレピュテーション次第では似たようなブロックがかかる可能性があります。個人利用でも Authenticator などへの移行を検討してください。
ありがちな落とし穴と避けるべき運用パターン
最後に、エラー 399287 のような事態を招きやすい「ありがちな運用」と、それを避けるためのポイントを整理します。
- NG：管理者が 1 つの携帯番号だけに依存している
→ 対策：複数の管理者に FIDO2 キー + Authenticator を設定し、「誰か 1 人の携帯にすべてが依存する」状態を排除する。 - NG：SMS / 音声通話がデフォルトで、Authenticator は任意
→ 対策：認証方法ポリシーと教育を通じて、Authenticator を既定とし、SMS はあくまで「どうしても必要なユーザー向けの例外」にする。 - NG：ユーザーに認証方法の自己管理を丸投げ
→ 対策：最初のセットアップ時に IT 部門が同席し、最低 2 種類以上の認証手段を必ず登録する運用ルールを明文化する。 - NG：ログを見ておらず、問題は「起きてから考える」
→ 対策：サインインログと Identity Protection の監視を、週次や月次の定例タスクに組み込み、怪しい動きや失敗が多い番号を早期に特定する。
まとめ：エラー 399287 に強いテナント設計へ
エラーコード 399287 は、単なる「SMS が届かない不具合」ではなく、電話番号のレピュテーションや不正利用疑いに起因するブロックである可能性が高いエラーです。今回の事例のように、最終的な復旧には Microsoft 側のバックエンド解除が必要になるケースもあります。
しかし、同じことを繰り返さないようにするためには、テナント側の設計と運用の見直しが不可欠です。
- 短期的には：Microsoft によるブロック解除と、ユーザーの Microsoft Authenticator 登録
- 中長期的には：認証方法ポリシーの見直しと、条件付きアクセスによる認証強度コントロール
- 恒久対策として：FIDO2 / パスキー等のフィッシング耐性 MFA へのシフトと、ログ監視・復旧フローの整備
これらを順番に進めていけば、「電話番号がブロックされたら Azure に入れない」という構造から脱却し、エラー 399287 が発生しても業務が止まらない、強いテナント運用へと近づくことができます。
コメント