Microsoft Entra ID（旧Azure AD）のSMS多要素認証でエラー399287が発生し、しかもテナント内のグローバル管理者が自分一人だけという状況になると、業務が完全に止まってしまうリスクがあります。本記事では、電話番号に付いた「悪評（bad reputation）」が原因でSMS MFAがブロックされるケースを取り上げ、Microsoftサポートへの依頼手順から、回復後に必ずやっておきたい再発防止策までを実務目線でまとめます。
SMS多要素認証が突然失敗し始める典型的なパターン
まず、今回のようなトラブルがどのようなシナリオで起きるのかを整理しておきましょう。よくあるパターンは次のようなものです。
- Microsoft Entra IDで、ユーザーに対してSMSによる多要素認証（MFA）を利用している。
- ある日突然、SMSコード入力のフェーズで認証が失敗し、サインインが完了しなくなる。
- 同じ携帯電話番号を、他のテナントや別アカウントで使うとMFAが通る。
- 旧スマートフォンを紛失しており、Microsoft Authenticatorアプリによるサインインは不可能。
- 当該テナントのグローバル管理者アカウントが自分一人しかおらず、ポータルにサインインできないため、自分自身のMFA再登録や解除もできない。
表にすると、状況は次のように整理できます。
| 項目 | 状況 |
|---|---|
| 認証方式 | SMSによる多要素認証（MFA） |
| エラー | エラーコード 399287 |
| 電話番号 | 他テナントでは正常、問題のテナントだけ失敗 |
| Authenticator | 旧端末紛失のため使用不可 |
| 管理者構成 | グローバル管理者が本人1名のみ |
この状態に陥ると、テナント側の画面に入れないため、通常の「認証方法のリセット」や「MFA再登録の要求」といった操作が一切行えません。ここが最大の詰まりポイントです。
エラー399287と「電話番号の悪評（bad reputation）」という概念
エラーコード399287は、表側の画面にはあまり情報が出ませんが、裏側では電話番号に対してセキュリティ上のフラグが立ち、MFAでの利用がブロックされている状態を示すケースがあります。
このときポイントになるのが、次のような考え方です。
- ブロックされているのは「ユーザー」ではなく「電話番号」そのもの。
- Microsoft側のセキュリティシステムで、その番号に「悪評（bad reputation）」が付けられている可能性がある。
- 悪評が付いている電話番号は、特定の条件下でMFA要素として拒否されることがある。
- このフラグはテナント管理者がポータルから解除することはできず、Microsoftのバックエンド作業が必要。
つまり、管理者がポータルでいくらポリシーやユーザー設定を確認しても、肝心の「電話番号の評判」部分にはアクセスできません。そのため、テナント内の設定をいじっても解決しないわけです。
なぜ同じ電話番号でも他テナントでは成功するのか
「同じ電話番号なのに、別のテナントでは問題なくMFAできるのに？」という疑問は非常に自然です。この現象は次のように説明できます。
- 電話番号の悪評フラグは、利用状況・組み合わせ・リスク判定の結果によって動きます。
- あるテナント＋特定のアカウントの組み合わせだけが、システム上「危険」と判定されている可能性があります。
- 他のテナントでは、同じ番号でも「危険度の閾値に達していない」ため、MFAが通過することがあり得ます。
要するに、電話番号に対する評価は一枚岩ではなく、テナントやサインインの履歴、位置情報、試行回数など複数の要素が複合的に影響しています。結果として「このテナントでだけSMSがダメ」という歪（いびつ）な状態が生まれます。
テナント管理者が自力でできること・できないこと
まず冷静に、「ポータルに入れなくてもできること」と「絶対に自力ではできないこと」を切り分けておきましょう。
| 区分 | できること | できないこと |
|---|---|---|
| ユーザー設定 | 別アカウントからの操作が可能なら、MFA再登録の要求や認証方法のリセット | 自分自身が唯一の管理者で、サインインできない場合は何もできない |
| 認証方法ポリシー | SMSを許可する/しない設定の確認・変更（ポータルに入れれば） | 電話番号の悪評フラグの確認・解除 |
| 条件付きアクセス | SMSがブロックされていないかの確認・調整（ポータルに入れれば） | エラー399287のようなバックエンド制御の解除 |
| バックエンド制御 | なし | 電話番号に付与されたブロックや悪評フラグの除去 |
特にエラー399287に絡む「電話番号の悪評フラグ」は、テナント外側の仕組みで動いているため、管理者権限がどれだけあっても自力解除は不可能と考えておくのが現実的です。
実際に有効だった解決ステップの全体像
ここからは、実際にこの種のトラブルが解消されたパターンをベースに、具体的な手順を整理していきます。
ステップ1：ほかにサインインできる手段がないか最終確認
まずは、サポートに行く前に次のような「最後の望み」を一通り試しておきましょう。
- Authenticatorアプリのクラウドバックアップ（Microsoftアカウント経由）がないか確認し、新端末で復元を試す。
- バックアップコードをどこかに保存していないか確認する。
- 音声通話や別の電話番号など、他のMFA要素を登録していないか思い出す。
- 別のグローバル管理者アカウントが本当に存在しないか、組織内に確認する。
ここまで試してもどうにもならない場合は、Microsoftサポートによるバックエンド作業が必須になります。
ステップ2：Microsoftサポートにエスカレーションする
エラー399287が発生しており、電話番号の悪評が疑われる場合、次のようにサポートへ状況を伝えます。
- 「SMSによるMFAでエラー399287が発生し、特定テナントのグローバル管理者がロックアウトされている」
- 「同じ電話番号で他テナントではMFAが成功する」
- 「旧スマートフォンを紛失しており、Authenticatorアプリは利用できない」
- 「当該テナントには他のグローバル管理者が存在せず、自分でMFAの解除や再登録ができない」
そして、次の2点をバックエンドで実施してほしい旨を明確に依頼します。
- 対象アカウントのMFAブロック解除
- 電話番号に付いた悪評（bad reputation）フラグの除去
これをシンプルに伝えるだけでも話は進みますが、可能であれば後述のテンプレートに沿って具体的な情報を添付しておくと、調査・解除までの時間短縮が期待できます。
サポート依頼時に準備しておきたい情報テンプレート
以下の情報は、公開フォーラムには絶対に書き込まず、必ずプライベートメッセージやサポートチケットの中だけで共有してください。
| 項目 | 内容例 |
|---|---|
| 対象ユーザー | UPN / メールアドレス（例：[email protected]） |
| テナントID | Directory ID / Tenant ID（GUID形式：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx） |
| 電話番号 | E.164形式（例：+81xxxxxxxxxx） |
| 国／地域 | 例：Japan |
| 発生日時 | できる限りUTCで記載（例：2025-11-23T03:00:00Z） |
| エラー情報 | Error code 399287、サインインログのCorrelation ID / Request ID（取得できる場合） |
| 状況・事情 | 旧端末紛失でAuthenticator不可／当該テナントのグローバル管理者は本人のみ など |
特にCorrelation IDやRequest IDが取れていると、Microsoft側のログ検索が一気にスムーズになります。ブラウザのサインイン画面でエラーが表示された際に記載されていることが多いので、スクリーンショットを撮っておくのも有用です。
サポート窓口の作成例
サポートチケットは、通常次のいずれかから作成します。
- Microsoft 365 管理センター → サポート → 新しいサービス要求
- Azure ポータル → ヘルプ + サポート → 新しいサポート要求
すでにサインインが難しい場合は、電話問い合わせやコールバックのオプションを利用し、「唯一の管理者がMFAでロックアウトされている」という緊急性を明示して伝えるのがポイントです。
サポート対応後に行う確認と再登録
サポート側でバックエンド作業が完了すると、通常は次のような状態に変わります。
- エラー399287が発生していたSMSによるMFAが通るようになる。
- 対象アカウントのMFAブロックが解除される。
この時点で行うべき確認・作業は次の通りです。
- AzureポータルまたはMicrosoft 365管理センターにサインインし、SMSによるMFAが正常に完了するか確認する。
- サインインできたら、すぐに認証方法のページを開き、以下のように複数の認証手段を登録する。
- Authenticatorアプリ（新端末）
- プッシュ通知＋ワンタイムコード
- 電話番号（SMS／音声）
- FIDO2セキュリティキーやパスキー
- 必要に応じて、管理者用の別アカウントやブレークグラスアカウントについても、同様に認証方法を整備する。
ここで手を抜くと、数カ月後にまた同じようなトラブルに見舞われる可能性があります。回復直後が、最もモチベーションが高いタイミングなので、一気に整備を進めてしまいましょう。
グローバル管理者が複数いる場合の代替・暫定対応
今回のケースでは管理者が1名のみでしたが、もし他にもグローバル管理者が存在する場合は、サポートに行く前にテナント内でできることがいくつかあります。
別管理者によるMFA再登録の要求・認証方法のリセット
別のグローバル管理者がポータルにサインインできる場合、その管理者から次の操作を実施してもらうことで、当該ユーザーのMFA問題を解決できることがあります。
- 対象ユーザーに対して「MFA の再登録を要求」する。
- 対象ユーザーの認証方法をリセットする。
ただし、電話番号そのものに悪評フラグが付いている場合、認証方法をリセットしてもSMSでの認証は失敗し続ける可能性があります。その場合は、やはりMicrosoftサポートでのフラグ解除が必要です。
Temporary Access Pass（TAP）を使った一時的な回復
組織でTemporary Access Pass（TAP）が有効化されている場合は、別管理者がTAPを発行することで、MFAに詰まっているユーザーを一時的にサインインさせることができます。
- TAPは、一定時間だけ有効な一時パスコード。
- ユーザーはTAPを使ってサインインし、その後改めて認証方法を登録し直す。
- MFAの再登録・Authenticatorのセットアップ・FIDO2キー登録などを一気に行う。
ただし、これもやはり「電話番号の悪評」の問題を根本的に解決するものではありません。TAPでサインインし、新しい電話番号や別の認証方法を十分に登録してから、問題の番号を使わない運用に切り替える、といった判断が必要になる場合もあります。
Authenticatorバックアップがある場合の復元
Microsoft Authenticatorアプリは、個人のMicrosoftアカウントに紐づけたクラウドバックアップ機能を持っています。旧端末でバックアップを有効にしていた場合は、新端末に同じMicrosoftアカウントでサインインすることで、次のような復元が可能になる場合があります。
- 旧端末で使っていたMFAアカウントを新端末に復元。
- 復元したAuthenticatorを用いて、SMSを使わずにMFAを完了。
- その後、電話番号や別の認証方法を追加登録し直す。
今回のように旧端末を紛失していても、バックアップさえあれば復元できることがあります。今後に備えても、管理者アカウントのAuthenticatorバックアップは必ず有効化しておきましょう。
再発防止のベストプラクティス：設計と運用のチェックリスト
一度このようなトラブルを経験すると、「もう二度と同じ目に遭いたくない」と強く感じるはずです。そこで、再発防止のために最低限押さえておきたいベストプラクティスを整理します。
グローバル管理者は必ず2名以上にする
- グローバル管理者が1名だけだと、その人がロックアウトした瞬間にテナント全体が詰みます。
- 最低でも2名、可能であれば3名以上の管理者を用意し、役割を分散させるのが安全です。
- 一部の管理者には、条件付きアクセスの編集権限や認証方法の管理権限だけを付与するなど、ロールベースで権限を分割するのも有効です。
ブレークグラス（緊急）アカウントを2つ用意する
ブレークグラスアカウントとは、緊急時にポータルへアクセスするための「最後の鍵」です。次のようなルールで運用することが推奨されます。
- テナント内に少なくとも2つのブレークグラスアカウントを用意する。
- これらのアカウントは、条件付きアクセスやMFAポリシーの対象外とし、極めて強固なパスワードを設定する。
- パスワードはオフラインの安全な場所（耐火金庫など）に保管し、定期的に更新する。
- 通常業務では使わず、本当に緊急のときだけ利用する。
Temporary Access Pass（TAP）を回復手段として設計に組み込む
近年のEntra ID環境では、パスワードレス認証やFIDO2キー、パスキーの活用が進んでいます。これに伴い、アカウント回復手段としてTAPを設計に組み込むことが重要になっています。
- 重要なアカウント（グローバル管理者・セキュリティ管理者など）向けにTAPを利用できるようにポリシーを構成する。
- 実際の運用手順書に「MFAが詰まったらTAP発行→サインイン→認証方法再登録」というフローを明記しておく。
- 定期的にテストユーザーでTAPによる回復手順をリハーサルしておく。
管理者アカウントには必ず複数の認証方法を登録する
管理者アカウントに「Authenticatorアプリだけ」「SMSだけ」といった単一要素しか登録していないと、今回のようなトラブルのダメージが致命的になります。次のような組み合わせを推奨します。
- Authenticatorアプリ（プッシュ通知＋コード）
- FIDO2セキュリティキーまたはパスキー
- SMSまたは音声通話による電話認証（1つ以上の電話番号）
- バックアップコード（可能な場合）
実際には「Authenticator＋FIDO2＋電話」があれば、かなりの障害に耐えられる構成になります。電話番号が悪評でブロックされても、他の要素でサインインできるため、落ち着いて番号を差し替えることができます。
認証方法ポリシーと条件付きアクセスの定期点検
また、次のような定期点検をスケジュール化しておくと、トラブルの早期検知につながります。
| チェック項目 | 内容 |
|---|---|
| 認証方法ポリシー | SMSが許可されているか／不要に制限しすぎていないかを確認。 |
| 条件付きアクセス | SMSを利用したサインインが特定の条件でブロックされていないか確認。 |
| 管理者アカウント | 複数の認証方法が登録されているか、定期的にサインインテストを実施。 |
| ブレークグラスアカウント | パスワード・運用ルールが最新か、緊急時に誰がどのように使うかを再確認。 |
電話番号の悪評を避けるための利用上の注意
電話番号に悪評が付与される仕組みの詳細は公開されていませんが、一般的に次のような行動は避けた方が無難です。
- 短時間に大量のMFAコード送信を繰り返す（誤入力連発・自動化された試行など）。
- 同じ番号を多くのアカウントで使い回しすぎる。
- 使い捨て番号や一時的なオンライン番号をMFA用に使う。
- 番号変更時に古い番号を放置したまま、長期間何度もエラーを出し続ける。
管理者アカウントに紐づく電話番号は、できるだけ安定して利用し続ける前提で運用し、変更が必要な場合は早めに認証方法を再登録しておくと安全です。
よくある勘違い・落とし穴
エラー399287やSMS MFAの障害対応で、実務上よく見かける勘違いをまとめます。
公開フォーラムに個人情報を書いてしまう
焦ってしまうと、技術コミュニティやQ&Aサイトに、次のような情報を書き込んでしまうケースがあります。
- 対象テナントID（GUID）
- UPN／メールアドレス
- 電話番号
- サインインログの詳細な情報
これらはすべて個人情報・機密情報です。公開掲示板に書き込まず、必ずサポートチケットやプライベートメッセージの中だけで提供するようにしましょう。
SMSサインイン設定とSMSによるMFAが同じものだと思っている
Microsoft Entra IDには、「SMSサインイン」と「SMSによるMFA」という似た用語がありますが、これは別物です。
| 機能 | 概要 |
|---|---|
| SMSサインイン | パスワードの代わりにSMSコードだけでサインインする仕組み。 |
| SMSによるMFA | パスワードや他の要素に加えて、SMSコードを2要素目として使う仕組み。 |
SMSサインインを有効化しているかどうかに関わらず、MFAのバックエンド側で電話番号がブロックされていると、MFA自体が失敗します。今回のようなエラー399287は、後者の問題に分類されます。
唯一の管理者をロックアウトさせてしまう設計
「管理者は自分一人で十分」「管理者アカウントはシンプルな方が安全」と考えてしまい、結果として唯一のグローバル管理者がロックアウトするパターンは少なくありません。
実際には、冗長性のない設計ほど危険です。管理者だけでなく、ネットワーク機器やサーバーの冗長構成と同じように、「壊れても別の経路で復旧できる」構成を意識する必要があります。
まとめ：エラー399287は早めのサポート依頼と設計見直しが鍵
本記事で取り上げたケースでは、電話番号に付与された「悪評（bad reputation）」が原因でSMSによるMFAがブロックされ、エラー399287として表面化していました。この状況は、テナント管理者の操作範囲を超えたものであり、MicrosoftサポートによるバックエンドでのMFAブロック解除と悪評フラグの除去によって解決しました。
同様のトラブルに直面した際は、次のポイントを押さえるとスムーズです。
- エラー399287が出ており、他テナントでは同じ番号が使えるなら、「電話番号の悪評」を疑う。
- Authenticator復元や他のMFA要素を試しつつ、ダメなら迷わずMicrosoftサポートにエスカレーションする。
- サポート依頼時には、UPN／テナントID／電話番号／発生日時／Correlation IDなどを整理して提出する。
- 解除後はすぐに複数の認証方法を登録し、ブレークグラスアカウントやTAPなどの回復手段も整備する。
一度しっかりと設計し直しておけば、次に似たような問題が発生しても、慌てることなく「どの経路で復旧するか」を選べるようになります。エラー399287は厄介に見えますが、原因と解決フローを理解しておけば、十分にコントロール可能なリスクに変えられるはずです。
コメント