Microsoft 365 ログイン「エラー399287」原因と解決：SMS MFAが通らない時の復旧手順と再発防止

Microsoft 365／Microsoft Entra ID（旧 Azure AD）にサインインした際、「Sorry, we’re having trouble verifying your account.（エラー 399287）」が出て SMS による多要素認証（MFA）が失敗する――本記事は、その原因・影響・復旧手順・再発防止策を技術的背景まで含めて徹底解説します。管理者・情報システム担当・上級ユーザーの方の現場対応にそのまま使える具体策をまとめました。

Microsoft 365 ログイン時の本人確認エラー（399287）の概要

サインイン画面でパスワード入力後に本人確認が求められる段階で、SMS によるワンタイムコードの受信・入力を試みても失敗し、エラーコード 399287 が表示される事象です。多くのケースで、パスワードの再設定（SSPR）は成功しても、SMS がブロックされているため最終の本人確認を完了できず、管理者を含む複数テナント（委任・B2B 参加含む）へのアクセスが 同時に失われます。

主な症状

正しいパスワードを入力しても、SMS によるコード認証が繰り返し失敗する。
「別の方法で確認」から電話・SMS を選んでも同様に弾かれる。
管理者アカウントであっても、管理センターに入れない（MFA 通過が前提）。
他テナントの来訪者（B2Bゲスト）としてのサインインも連鎖的に失敗する。

原因：Microsoft 側の「不審」判定による SMS MFA 自動ブロック

最も一般的な原因は、当該の 電話番号またはアカウントが Microsoft 側のリスク判定により「bad reputation（不審）」 とみなされ、SMS 経由の MFA が自動ブロック されていることです。
このブロックは 番号単位／アカウント単位 で適用されるため、同じ番号を登録している複数テナントのサインインや、同一アカウントが参加する複数テナントの認証フローに波及します。

判定対象	ブロックの適用範囲	具体例	運用上の注意
電話番号（E.164）	同番号を登録する全テナントの SMS/音声	「+81XXXXXXXXXX」を個人・管理者・ゲストで共用	テナントをまたいだ連鎖障害。番号の再登録・方法追加が必須
アカウント（UPN）	当該サインイン ID に紐づく全テナント	同じ UPN で複数組織の B2B 招待を受けている	解除後ただちに Authenticator / FIDO2 を追加

なぜ SMS はブロックされるのか（背景）

IRSF（国際収益共有詐欺）対策：特定の番号帯やトラフィック特性が不正利用と相関しやすく、プラットフォーム側で遮断が強化されることがあります。
SIM スワップ／番号再利用：キャリアの番号再割当や SIM 交換に伴い、正当な利用者の SMS が届かない・ハイジャックされるリスクがあります。
フィッシング回避：SMS は一時コードの傍受・中間者攻撃に弱く、近年は Authenticator／FIDO2／パスキーへの移行が推奨されています。

結論：自己解除は不可。サポートによる「MFA ブロック解除」依頼が必要

ユーザー・管理者の権限では 399287 の根本解除はできません。まずは Microsoft 365 管理センターからのサポートチケットや、適切なサポート窓口（Microsoft Q&A 等のプライベート経路）で、MFA ブロックの解除（unblock） を依頼してください。

解決の全体フロー（要約）

サポートへ解除依頼：対象メールアドレス・電話番号・国名を伝え、エンジニアリング側でブロック解除を実施してもらう。
ログイン確認：解除後に再サインインし、SMS 認証が通るか確認する。
認証方法を即時変更：ログインできた直後に、aka.ms/mysecurityinfo にアクセスして Authenticator／FIDO2／パスキーを追加。電話・SMS のみ依存から脱却する。
再発防止：管理者複数人体制、ブレークグラス（緊急）アカウント、強固な認証方法ポリシー、登録方法の多様化を整備する。

実務で使える詳細手順

1. サポートへ解除依頼する（必須）

以下の情報を整理して依頼します。番号は E.164 形式（+国番号～） で記載し、可能であれば本人確認の実施可否・タイムスタンプ（時刻・タイムゾーン）・影響テナントも添えます。

【依頼テンプレート（例）】
・事象：Microsoft 365 サインイン時に「Sorry, we’re having trouble verifying your account.（エラー 399287）」で SMS による MFA が失敗。
・影響：当該番号／アカウントを用いる複数テナントでサインイン不可。
・対象ユーザー：[email protected]（UPN）
・対象電話番号：+81XXXXXXXXXX（国：Japan）
・発生日時：2025-10-31 09:14 JST 頃から継続
・希望対応：MFA に対する SMS ブロックの解除（unblock）
・補足：SSPR は成功。解除後に Authenticator/パスキーへ移行予定。

よくある落とし穴

番号の桁誤り（国内表記のまま、0 始まりで記載）
別名義の番号（家族・同僚の番号）を混在利用している
法人契約の代表番号を流用して複数アカウントに登録している
複数テナントで同じ番号を使い回しており、解除後も再ブロックを誘発

2. 解除完了後のログイン確認

サポートから解除完了の連絡を受けたら、以下を実施します。

通常どおり UPN とパスワードでサインイン。
SMS を受信し、ワンタイムコードが通るか確認。
成功したら すぐに次の「認証方法の切り替え」へ（再ブロックのリスクを最小化）。

3. 認証方法を即時に切り替える

サインイン可能なうちに、aka.ms/mysecurityinfo にアクセスし、以下を追加・既定化します。
SMS／音声のみの構成を解消して、フィッシング耐性の高い要素を第一選択にします。

Microsoft Authenticator（プッシュ承認＋番号一致、またはオフライン TOTP）
FIDO2 セキュリティキー／パスキー（プラットフォーム／クロスプラットフォーム）
バックアップ手段として、別デバイスの Authenticator・予備の FIDO2 キー・別番号（音声通話は最小限）

モバイル端末の紛失・機種変更に備え、Authenticator のアカウントバックアップと復元手順も合わせて確認しておきましょう。Outlook モバイルに内蔵された Authenticator Lite を暫定的に有効活用する選択肢もあります（環境による）。

4. 再発防止の設計（管理者向け）

全体管理者（GA）の冗長化：少なくとも 2～3 名。互いに MFA リセットが可能な運用に。
ブレークグラス（緊急）アカウント：MFA ポリシーの対象外・強力な長桁パスフレーズ・保管/監査手順を整備。
認証方法ポリシー：電話/SMS は「補助」扱いにし、Authenticator／FIDO2／パスキーを必須に近づける。
登録体験の整備：新入社員・端末交換のオンボーディングでまず Authenticator と FIDO2 をセットアップ。
Temporary Access Pass（TAP）等の代替経路
条件付きアクセス：強固な方法のみ許可・高リスクセッションのブロック。国/ロケーション・デバイス準拠性の組合せで段階防御。
監査とアラート：MFA 登録変更・サインイン失敗・ブロック発生の検知を運用ルール化。

補足 — SMS/音声による MFA のリスクと運用指針

SMS/音声は IRSF・SIM スワップ・ローミング障害・遅延 の影響を受けやすく、安定性・安全性の観点で劣後します。
近年の推奨は、Authenticator（番号一致）／FIDO2／パスキーが中心です。
やむを得ず電話を許可する場合でも、「予備」扱いとし、最初に選ばれないようユーザー教育・既定値を調整します。

認証方法の比較（現場向けチートシート）

認証方法	長所	短所	推奨運用
Authenticator アプリ	ワンタップ承認／番号一致・オフラインコード・フィッシング耐性	端末紛失時に復元が必要	主要手段。バックアップ用に別端末や TOTP を併設
FIDO2 キー／パスキー	物理要素で強固・PIN/生体と組合せ・ユーザビリティ高	初期コスト・保管/紛失リスク	管理者・特権用途は必須級。予備キーを封印保管
SMS／音声	導入容易・追加機器不要	IRSF・SIM スワップ・遅延・ローミング費用・盗聴リスク	補助手段に限定。既定値から外す

現場で役立つトラブルシュート観点

番号の表記：+81 のような国番号付き（E.164）。内線・代表番号・050 番号の流用は避ける。
キャリア事情：海外ローミング・機内モード・SMS 受信拒否設定・留守番電話転送の確認。
複数テナントの巻き添え：同一番号／同一アカウントを複数テナントで使っていないか棚卸し。
同期遅延：解除直後は数分～の伝播遅延があり得る。認証方法の追加まで一息に実施。
代替経路：管理者が TAP を発行できる構成なら、初回サインインを確保して mysecurityinfo で方法追加。

やってはいけないこと

SMS が通らないからといって メールアドレスを認証手段の代わりに使おうとする（サインイン MFA と SSPR の混同）。
管理者アカウントで 電話のみに依存する設計の継続。
複数ユーザーで 同じ電話番号を共用する（代表番号など）。
解除直後に認証方法を変更せず、同じ構成で運用を続ける。

ユーザー向けセルフヘルプ（アクセス回復時）

サインインできたらすぐ aka.ms/mysecurityinfo を開く。
「セキュリティ情報を追加」から Authenticator を登録。番号一致を有効に。
可能であれば FIDO2 キー／パスキー を 2 本以上登録（メイン＋予備）。
電話・SMS は 削除ではなく優先度を下げる（緊急時の予備として残す）。
端末を機種変更する際は、Authenticator のバックアップと復元テストを事前に実施。

管理者の実装チェックリスト

GA を 2 名以上、各自が互いの MFA リセットを実施可能。
ブレークグラスアカウント（MFA 例外・監査付き・長桁パス）を 1～2 個用意。
Authentication Methods ポリシー：電話/SMS は許可するが既定から外し、Authenticator/FIDO2/パスキーを推奨。
条件付きアクセス：特権ロールには強力な方法のみ。国/リスク/デバイス準拠性の組合せで段階認証。
TAP の運用整備：初回登録・紛失時の速やかな回復経路に。
オンボーディング手順書に「mysecurityinfo での多要素登録」を標準化。
退職・異動時の番号再利用を防ぎ、番号とアカウントのひも付けを棚卸し。

FAQ：エラー 399287 に関するよくある質問

Q1. 自力でブロックを解除できますか？

A. できません。ユーザー・管理者権限では不可能で、サポートへの解除依頼が唯一の正攻法です。解除後に Authenticator／FIDO2／パスキーへ移行しましょう。

Q2. 電話を「音声通話」に変えれば回避できますか？

A. 同一番号がブロック対象の場合、SMS だけでなく音声通話も失敗するケースが一般的です。番号・アカウントの解除が先決です。

Q3. SSPR（パスワード再設定）が成功したのに、なぜ入れない？

A. SSPR はパスワードの更新にすぎず、サインインの最終段で求められる MFA 手段がブロックされていれば通過できません。

Q4. テナント A で発生したのに、テナント B のゲストでも失敗するのはなぜ？

A. 判定は 番号／アカウント単位で行われます。B2B でまたがる全テナントの認証フローに波及します。

Q5. 解除後にまず何をすべき？

A. 初回サインインで 最優先で Authenticator／FIDO2／パスキーを登録し、電話・SMS を補助に格下げします。再発防止の鍵です。

インシデント対応プレイブック（配布用ひな型）

検知：ユーザーから 399287 の報告を受領。対象 UPN・番号・国・発生時刻を収集。
一次切り分け：複数ユーザー／複数テナントで再現するか。SMS/音声とも失敗かを確認。
エスカレーション：サポートへ unblock 依頼（テンプレ使用）。優先度は「完全に業務不能」。
回復：解除連絡後に本人と同時接続でサインイン→mysecurityinfo→Authenticator/FIDO2/パスキー登録。
封じ込め：条件付きアクセスで電話の優先度を下げ、特権ロールに強力な方法を強制。
再発防止：番号共用の禁止、オンボーディング時の登録標準化、ブレークグラス点検。
事後レビュー：時系列・影響・恒久対策・運用改善を記録し、社内ナレッジへ反映。

ケーススタディ：海外出張中に 399287 が発生した場合

ローミングの不確実性：SMS 配送ルートやキャリア相互接続の違いが影響しやすい。
一時的回避策：現地 SIM に差し替えると番号が変わるため不可。解除依頼を先行し、回復直後に Authenticator/パスキーへ移行する。
事前対策：渡航前に オフライン TOTP や FIDO2 キー を必ず登録して携行。

ポリシー設計の勘所

ユーザビリティと攻撃耐性のバランスが鍵です。電話/SMS は “繋がるときは便利” ですが、「繋がらないと完全停止」に直結します。最初に選ばれる手段を Authenticator（番号一致）や FIDO2/パスキーに寄せ、電話は「最後の砦」にとどめる設計が、実運用の停止時間を最小化します。

テンプレ：社内周知用の短文

【重要】Microsoft 365 の認証方法を見直します
・SMS/音声は補助手段に変更します
・Authenticator（番号一致）と FIDO2/パスキーの登録をお願いします
・登録ページ：aka.ms/mysecurityinfo（社外ネットからも可）
・不明点は情シスまで

まとめ

399287 は Microsoft 側ブロックが原因で、自己解除はできません。まずは解除依頼が必須。
解除後は 即時に Authenticator／FIDO2／パスキーへ移行し、電話・SMS 依存を脱却。
管理者は 冗長化・ブレークグラス・強力な方法の既定化・登録標準化で、将来のロックアウトを未然に防ぎましょう。

付録：本記事の要点（1ページ版）

項目	要点
症状	SMS MFA が失敗し、エラー 399287。SSPR 後も最終認証で停止。
原因	番号／アカウントが「bad reputation」判定でブロック。
影響	同一番号・同一アカウントを利用する全テナントに波及。
復旧	サポートに unblock 依頼 → サインイン確認 → 認証方法を強化手段へ切替。
再発防止	複数管理者・ブレークグラス・Authenticator／FIDO2／パスキーの標準化。

本記事が、現場の「いま困っている」を最短で解消し、次のインシデントを防ぐ具体的アクションにつながれば幸いです。

この記事を書いた人

佐藤健司

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