Microsoft 365 や Azure AD（現 Microsoft Entra ID）のグローバル管理者アカウントで、突然 SMS を使った多要素認証（MFA）が通らなくなり、エラー 399287 とともにサインインできなくなると、業務への影響は非常に深刻です。本記事では、この「MFA（SMS）失敗・エラー 399287」の原因や背景を整理しつつ、実務での復旧ステップと、再発防止のための設計・運用のポイントを詳しく解説します。
管理者アカウントで MFA（SMS）が失敗する「エラー 399287」とは
グローバル管理者アカウントでサインインする際、SMS を利用した多要素認証が通らず、次のようなメッセージが表示されるケースがあります。
- 「Sorry, we’re having trouble verifying your account. Please try again.」
- Error Code: 399287
- Request Id / Correlation Id / Timestamp（例：2025‑08‑15T06:58:51Z）
このとき、パスワード入力までは成功しているにもかかわらず、SMS によるコード認証で失敗し続け、グローバル管理者がポータルに入れない状態になります。複数の管理者アカウントで同様の症状が同時期に発生することもあり、非常に焦りやすいパターンです。
| 項目 | 内容 |
|---|---|
| 影響範囲 | Microsoft 365 / Azure AD（Entra ID）のグローバル管理者アカウントなど特権アカウント |
| 症状 | パスワードは通るが、SMS ベースの MFA が成立せずサインインできない |
| 表示メッセージ | Sorry, we’re having trouble verifying your account. Please try again. |
| 代表的なエラー情報 | Error Code: 399287 / Request Id / Correlation Id / Timestamp（UTC） |
| 発生の特徴 | 同じ組織内の複数ユーザー・管理者で同様の事象が発生することがある |
なぜ SMS の MFA だけが通らないのか：原因の一例と背景
この現象の原因の一例として、Microsoft 側で電話番号やサインインが「不正利用の疑い」ありと判定され、SMS 認証経路がブロックされるケースが挙げられます。特に、国際 SMS を多用したり、短時間で多数の認証リクエストが発生したりすると、電話番号やサインイン元に「bad reputation（悪評）」が付与されることがあります。
電話番号の「悪評（bad reputation）」とは
Microsoft 365 の SMS 認証は、Microsoft 自身と、複数の通信事業者・テレフォニープロバイダの仕組みを組み合わせて提供されています。この中で、
- スパム SMS の送受信に悪用されている疑い
- 国際収益共有詐欺（IRSF）への関与が疑われる通話・SMS パターン
- 短時間で異常に多い認証 SMS 送信リクエスト
などが検知されると、その電話番号や国／地域、あるいは特定のルートに対し「悪評」が付き、SMS ルート全体が抑止されることがあります。この状態になると、ユーザー側では何も設定を変えていないのに、突然 SMS が届かなくなり、エラー 399287 のような形で MFA が失敗します。
なぜ管理者アカウントで問題になりやすいのか
- 管理者アカウントはセキュリティ強度を高めており、MFA が必須になっていることが多い
- グローバル管理者が 1〜2 名だけ、かつ認証方法が SMS のみに依存しているケースが依然として存在する
- 運用上、管理者が頻繁にサインインとサインアウトを繰り返していると、SMS リクエスト回数が多くなりやすい
このような状況で SMS 経路がブロックされると、「管理者だけが一斉に入れない」という最悪のシナリオにつながります。
Microsoft による「悪評クリア」で復旧するケース
実際の事例では、Microsoft サポートに対して詳細なログ（Error Code 399287、Request Id、Correlation Id、Timestamp、電話番号など）を提供し、調査の結果、Microsoft 側で当該番号やアカウントのブロック解除・評価リセット（悪評クリア）を行うことで復旧しています。
ただし、これはあくまで「現象の解消」であり、同じ運用を続けていると、将来的に再び SMS 経路がブロックされるリスクがあります。そのため、復旧後はSMS への依存をやめ、Microsoft Authenticator や FIDO2 セキュリティキーを中心とした運用へ移行することが重要です。
実務での復旧ステップ（緊急度順）
ここからは、実際に現場でこの問題に直面したときに「何から手を付けるべきか」を、緊急度順に整理して解説します。
ステップ 1：別経路で一時的にログインする
まず最優先すべきは、何らかの方法で管理者権限を持つアカウントをポータルにログインさせることです。すでに SMS 以外の MFA 手段を登録している場合は、それを活用できます。
- Microsoft Authenticator アプリ（プッシュ通知、番号一致、ワンタイムパスコード）
- FIDO2 セキュリティキー（物理キー）
- OATH ハードウェアトークン
- パスワードレスサインイン（Phone sign-in など）
これらの方法でログインできる管理者アカウントが存在する場合、そのアカウントを使って暫定的な復旧作業を進めます。
ブレークグラス（緊急）アカウントの活用
設計がきちんとしている環境であれば、条件付きアクセス（CA）ポリシーから除外された ブレークグラスアカウント が 2 つ以上用意されているはずです。これらのアカウントには、通常
- MFA を要求しない（または別の経路で認証可能）
- 強力なランダムパスワードが設定されている
- 利用状況が監視されている
といった条件が設定されています。すでにブレークグラスアカウントが存在する場合は、それでサインインし、他の管理者の認証方法リセットや TAP 発行などの復旧作業を進めます。
ステップ 2：別の特権管理者が実施できる復旧策
何らかの形で管理者ポータルに入れたら、次に行うべきは影響を受けているユーザーの認証方法を整えることです。
認証方法のリセット
別の特権管理者（例：グローバル管理者、認証管理者など）は、Microsoft Entra ID のポータルから該当ユーザーの認証方法をリセットできます。
- 対象ユーザーを選択
- 「認証方法」または「認証情報」メニューを開く
- 既存の電話番号や Authenticator 情報を削除・リセット
- ユーザーに対し、新しい認証方法の登録フローへ誘導
この際、再登録ではSMS ではなく Authenticator や FIDO2 を主経路として登録させるのがポイントです。SMS はあくまで「バックアップ手段」として位置付けることを推奨します。
Temporary Access Pass（TAP）の発行
Microsoft Entra ID では、Temporary Access Pass（TAP：一時アクセスパス）という機能を利用して、端末紛失や機種変更時にユーザーが再度強力な認証方法を登録できるようにすることができます。
- 管理ポータルで TAP を有効化（テナントレベル設定）
- 対象ユーザーに対して TAP を発行（有効期限・回数を限定）
- ユーザーは TAP を使ってサインインし、Authenticator や FIDO2 の登録を行う
TAP は通常パスワードよりも短命で、用途が限定されているため、セキュリティと利便性のバランスが取りやすい仕組みです。SMS が使えない状態でも、TAP 経由で新しい認証手段を登録できるため、今回のような障害時にも非常に有効です。
条件付きアクセス（CA）の一時緩和
条件付きアクセスで「管理者は必ず強力な MFA を要求」といった厳しいポリシーを設定している場合、再登録の途中で詰まることがあります。そのような場合には、
- 該当ユーザーを一時的に特定の CA ポリシーから除外する
- 特定のグループに一時的な緩和ポリシーを適用し、そこに影響ユーザーを追加する
- 再登録完了後、元の厳格なポリシーに戻す
といった運用で、セキュリティを大きく落とさずに復旧作業を進めることができます。
ステップ 3：Microsoft へのエスカレーション（ブロック解除依頼）
SMS 経路が Microsoft 側でブロックされている場合、テナント管理者側から設定を変更するだけでは復旧できないケースが多くなります。このときは、Microsoft サポートへのエスカレーションが不可欠です。
どこから問い合わせるか
- Microsoft 365 管理センター
サポート → 「新しいサービス リクエスト」からケースを登録 - Azure ポータル（Entra ポータル）
「ヘルプ＋サポート」 → 「新しいサポート リクエスト」から登録
添付すると調査が早くなる情報
サポートに問い合わせる際には、以下の情報をまとめて提供すると、調査がスムーズに進みます。
| 項目 | 内容 |
|---|---|
| Error Code | 399287 |
| Request Id / Correlation Id | サインイン失敗画面やサインインログに表示される ID |
| Timestamp（UTC） | エラーが発生した日時（UTC ベースで記載） |
| 影響ユーザー | UPN（メールアドレス）、管理者権限の有無 |
| 電話番号 | E.164 形式（例：+81XXXXXXXXXX）、国／地域 |
| 再現手順 | どのポータルからサインインし、どの画面でエラーになったか |
| 影響範囲 | 何名の管理者／ユーザーに影響し、業務にどの程度支障が出ているか |
これらの情報を基に、Microsoft 側で電話番号やルートの評価を確認し、必要であればブロック解除や悪評クリアを行います。
ステップ 4：復旧後の確認
サポート対応や認証方法の再登録が完了したら、必ず次の点を確認します。
- 対象アカウントでサインインし、SMS 認証が通るか
- Microsoft Authenticator や FIDO2 でのサインインが問題なく行えるか
- 条件付きアクセスやセキュリティポリシーが、復旧前と意図した通りの状態になっているか
- 不要になった一時的な緩和措置や TAP が残っていないか
特に、暫定対応として緩和した CA ポリシーや TAP を「戻し忘れる」ことが多いため、チェックリスト化して確実に確認することをおすすめします。
よくある原因とセルフチェック
エラー 399287 のような SMS 認証失敗が発生したとき、現場で簡単に確認できるセルフチェックポイントを整理します。
| 想定される原因 | セルフチェックのポイント |
|---|---|
| 電話番号の悪評（bad reputation） | 短時間に多数の SMS 認証を発生させていないか、他サービスでも SMS が届きにくくなっていないか |
| 通信事業者側の制限 | 国際 SMS の受信が制限されていないか、フィルタリング設定や迷惑メッセージフォルダを確認 |
| 条件付きアクセスの設定不整合 | 特定の場所やデバイスに対して過剰な制限をかけていないか、対象ユーザーが想定外にポリシーから除外されていないか |
| 端末側の問題（Authenticator 使用時） | スマートフォンの時刻が自動同期になっているか、通知がブロックされていないか、バッテリーセーバーが影響していないか |
| 番号変更や SIM 交換 | ユーザーが最近電話番号を変更していないか、eSIM 再発行などの履歴がないか |
これらのセルフチェックだけでは解消できない場合でも、事前に確認しておくことでサポートへの説明がスムーズになり、調査時間の短縮につながります。
再発防止のベストプラクティス（管理者向け）
今回のような事象は、一度復旧しても、設計や運用を見直さないままだと再発する可能性があります。ここでは、Microsoft 365 / Entra ID 管理者向けに、再発防止のためのベストプラクティスをまとめます。
SMS／音声通話による MFA を原則「管理者では使わない」
管理者アカウントについては、SMS／音声通話を「原則として使わない」方針を強く推奨します。代わりに以下を主経路とします。
- Microsoft Authenticator アプリ（番号一致有効）
- FIDO2 セキュリティキー
- パスワードレスサインイン
SMS は手軽ですが、「IRSF（国際収益共有詐欺）」などテレフォニー詐欺の主要な入口にもなりやすく、通信経路や事業者側の制御も絡むため、エンタープライズの特権アカウント向きではありません。
MFA 手段は最低 2 種類以上を登録する
管理者アカウントには、最低でも2 種類以上の MFA 手段を登録させることが重要です。
- 例 1：Authenticator（プッシュ）＋ FIDO2 キー
- 例 2：Authenticator（ワンタイムコード）＋ OATH ハードウェアトークン
こうしておくことで、片方の手段に障害が発生しても、もう一方でログインして復旧作業を行うことができます。
ブレークグラスアカウントを 2 つ以上用意し CA から除外する
組織全体の「最後の砦」として、ブレークグラスアカウントを 2 つ以上用意し、条件付きアクセスやリスクベースポリシーから除外しておきます。
- 強力で長いランダムパスワードを設定し、オフラインで厳重に保管
- メールボックスは通常利用しない（通知専用にするなど）
- 毎月または四半期に 1 回、サインイン確認を行い、ログを必ずレビュー
このブレークグラスアカウントが存在するかどうかで、今回のような障害の「復旧しやすさ」が大きく変わります。
TAP（Temporary Access Pass）を有効化し運用ルールを決める
端末紛失や機種変更、認証アプリの再インストールなどが発生したときに、ユーザーが素早く安全に認証方法を再登録できる仕組みとして TAP を有効化しておきます。
- 有効期限や利用回数に厳しい制限を設ける
- 発行できるロールを限定する（例：認証管理者、ヘルプデスク）
- 発行・利用ログを定期的にレビューする
TAP の運用が整っていれば、SMS や Authenticator が一時的に使えなくなっても、サービス全体を止めずに再登録作業を進められます。
条件付きアクセスを「管理者向け」「一般ユーザー向け」で分離する
条件付きアクセスを 1 本のポリシーですべてのユーザーに適用すると、管理者向けの厳しい設定と、一般ユーザー向けの利便性のバランスを取るのが難しくなります。そこで、
- 特権ロールに割り当てられた管理者向けポリシー（非常に厳格）
- 一般ユーザー向けポリシー（利便性と安全性のバランス重視）
といった形でポリシーを分離し、管理者向けには特に SMS を使わない設計を徹底します。
サインインログ・MFA レポート・アラートの定期確認
再発防止の観点では、問題が「起きてから気付く」のではなく、「起きそうな兆候」を捉えることが重要です。
- サインインログで、MFA 失敗が急増していないかを定期的にチェック
- 特定の電話番号やユーザーに失敗が集中していないかを確認
- アラートルールを設定し、「管理者のサインイン失敗が一定回数を超えたら通知」を実装
これにより、SMS の届きにくさや認証方法の問題を早期に検知し、今回のような大規模障害に発展する前に手を打つことができます。
ユーザー教育：SMS のリスクと強力認証の利用徹底
最後に、技術的な対策だけでなく、ユーザー教育も欠かせません。
- SMS はフィッシングや詐欺に悪用されやすく、攻撃者にとっても狙いやすい経路であること
- Authenticator や FIDO2 による認証は、利用者にとっても「タップするだけ」で比較的簡単であること
- 電話番号を安易に他サービスで使い回さないこと
といった点を周知し、「とりあえず SMS」という文化から「標準は Authenticator／FIDO2」へと意識を変えていくことが、長期的なセキュリティ向上につながります。
問い合わせ時に添えるとよい情報テンプレート
Microsoft サポートに連絡する際に、そのままコピー＆ペーストして使いやすいテンプレート例を示します。実際の値に置き換えて利用してください。
【テナント情報】 ・テナント名： ・テナント ID（GUID）： 【影響ユーザー情報】 ・UPN（メールアドレス）： ・国／地域： ・電話番号（E.164 形式）： ・管理者ロール（例：グローバル管理者、セキュリティ管理者 など）： 【エラー情報】 ・Error Code：399287 ・Request Id： ・Correlation Id： ・Timestamp（UTC）： 【発生状況】 ・発生開始日時（ローカル時刻・UTC 両方）： ・影響ユーザー数（管理者 / 一般ユーザー）： ・影響業務（管理ポータルに入れない、設定変更ができない など）： ・再現手順： 1. （例）portal.office.com にアクセス 2. 管理者アカウントでサインイン 3. MFA（SMS）でコード入力画面に遷移 4. コードを入力するとエラー 399287 が表示される 【実施済みの対処】 ・別の認証方法（Authenticator / FIDO2 等）での試行結果： ・他の管理者アカウントでの再現有無： ・通信事業者への確認状況： ・条件付きアクセス / 認証方法ポリシーの変更有無： 【要望】 ・当該電話番号 / アカウントに対するブロック有無の確認 ・必要に応じた悪評クリア / ブロック解除の実施
事前にここまで整理しておけば、サポート担当者とのやり取りがスムーズになり、復旧までの時間短縮が期待できます。
まとめ：エラー 399287 は「終わり」ではなく、設計を見直すチャンス
本記事で取り上げたケースでは、Microsoft 側でのブロック解除（悪評クリア）により、最終的に SMS 認証は復旧しました。しかし、根本的な教訓は「管理者アカウントが SMS に依存していたこと」にあります。
- 管理者は SMS／音声通話を原則として使わず、Authenticator や FIDO2 を主経路にする
- MFA 手段を複数登録し、どれか 1 つの障害でロックアウトしない設計にする
- ブレークグラスアカウントと TAP を用意し、緊急時の復旧ルートを必ず確保する
- 条件付きアクセス・ログ監視・ユーザー教育を組み合わせて、再発を防ぐ
エラー 399287 自体は厄介な事象ですが、これをきっかけに認証基盤全体の設計・運用を見直すことで、より強固で、障害にも詐欺にも強い Microsoft 365 / Entra ID 環境を作り上げることができます。もし今まさに同様のトラブルに直面している場合は、本記事の復旧ステップとベストプラクティスを参考にしつつ、同時に「今後どう改善するか」までをセットで検討してみてください。
コメント