Microsoft 365 管理者のSMS多要素認証でエラー399287が発生した時の原因と復旧手順・再発防止策

唯一のグローバル管理者アカウントで Microsoft 365 管理ポータルにサインインしようとしたところ、SMS の 2 要素認証でエラーコード「399287」が表示され、課金や請求書ダウンロードを含むあらゆる管理作業が止まってしまう――本記事では、実際に発生したケースをもとに、この問題の原因と復旧手順、そして再発防止のためのベストプラクティスを具体的に解説します。

Microsoft 365 管理者の SMS 認証でエラー「399287」が出るとどうなるか

まずは、今回のケースで実際に起きていたことを整理します。ポイントは「Microsoft 365 の管理ポータルに入る前の段階で詰まっているため、すべての管理作業ができなくなる」という点です。

典型的なエラー発生の流れ

唯一のグローバル管理者アカウントで Microsoft 365（または Azure Portal / Entra 管理センター）にサインインしようとする
パスワード入力までは正常に完了し、2 段階目の認証として「SMS」による多要素認証（MFA）が要求される
「SMS を送信」を選択すると、コード送信の段階、またはコードを入力して検証する段階でError Code: 399287 が表示される
その結果、ポータルに入れず、課金情報の確認・請求書ダウンロード・ライセンス管理など一切の管理作業が行えない

問題なのは、このアカウントが「唯一の」グローバル管理者であることです。
他に代わりの管理者がいないため、セルフサービスで何とかする手段がほぼなく、Microsoft サポートの力が必須となります。

今回のケースの要約

項目	内容
対象サービス	Microsoft 365 管理センター / Azure Portal / Entra 管理センター
対象アカウント	唯一のグローバル管理者アカウント
認証方式	多要素認証（MFA）の SMS 認証
エラー	Error Code: 399287（Request ID / Correlation ID / UTC 時刻付き）
影響	ポータルへサインインできず、請求書ダウンロード・課金管理・ライセンス管理などが一切できない
Authenticator	Microsoft Authenticator アプリは未設定（SMS のみ）

ここから分かるように、「エラー 399287」は単なる一時的な SMS 障害ではなく、アカウント／電話番号側に何らかのブロックがかかっている状態を疑うべきサインです。

原因：電話番号・アカウントに付与された「悪いレピュテーション」

今回のケースでは、Microsoft のバックエンド側で、当該アカウントおよび電話番号に不正利用の疑い（悪いレピュテーション）が付けられ、SMS 認証がブロックされていました。

Entra ID（旧 Azure AD）や、関連する認証バックエンドには、

不自然なサインイン試行
ボット的な挙動
電話番号を悪用した不正転送・不正認証試行

といった兆候を検知する仕組みがあります。これらが一定の条件を満たすと、その電話番号やアカウントに対して自動的にブロックがかかることがあります。

レピュテーションが悪化する例

パターン	説明
短時間に大量の SMS 認証試行	認証コードの再送を何度も繰り返すなど、ボットや攻撃と誤認される挙動
複数の国・地域からの異常なサインイン	VPN やプロキシ経由で別地域からのサインインが繰り返される
IRSF のような電話悪用の疑い	不正な国際転送や通話収益目的の不審な挙動が検知される
キャリア側の異常検知	携帯キャリア側でスパム・詐欺疑いがつき、結果としてサービス側でもブロックが強化される

こうした「レピュテーション悪化」の結果、SMS 認証だけがピンポイントでブロックされる場合があります。この状態にハマると、いくら正しい電話番号と本人であっても、ユーザー側から解除することはできません。

実際に有効だった解決策：Microsoft サポートによるブロック解除

今回の事例で有効だったのは、Microsoft サポート（エンジニアリングチーム）に依頼して、

ブロック解除
レピュテーションのクリア（リセット）

を行ってもらうことでした。

サポート側でバックエンドの状態を確認し、「不正利用の疑いとして付与されていたフラグ」を解除してもらうことで、SMS 認証が再び機能するようになり、管理ポータルへのサインインが復旧しています。

つまり、ユーザー側の設定変更ではどうにもならないレイヤーの問題であり、最初から「サポート案件」として扱うべき事象と言えます。

すぐにやるべき復旧手順（管理者が 1 名のみの場合）

ここからは、自組織で同じような状況が起きた場合に、最短で復旧するための具体的な手順を整理します。管理者が 1 名だけ、かつその管理者がロックアウトされている状況を想定しています。

ステップ 1：サポートに伝える情報を整理する

まず、サポートとやり取りする際に必要となる情報を整理します。エラー画面に表示されている内容は、必ずスクリーンショットに残しておきましょう。

種別	具体例
エラーコード	399287
Request ID	エラー画面に表示される GUID 形式の ID
Correlation ID	Request ID とセットで表示される GUID
発生時刻	エラー画面に表示される UTC 時刻（自分のローカル時間もメモしておくと良い）
サインイン ID（UPN）	[email protected] など、グローバル管理者のサインイン ID
電話番号	+81xxxxxxxxxx の形式で、国番号を含めて控える
テナント ID	可能であれば事前に控えておく（GUID 形式）。不明な場合は、テナントドメイン名（contoso.onmicrosoft.com）を伝える

これらの情報が揃っていると、サポート側でログをたどりやすくなり、原因特定と解除がスムーズになります。

ステップ 2：Microsoft サポートへ連絡する

次に、Microsoft サポートへ連絡します。通常は管理センターから「サポート」を開きますが、今回はそもそもサインインできない状態です。そのため、

Microsoft 365 のサポート窓口（電話 / Web フォーム）
購入元パートナー経由のサポート窓口

など、テナント契約時に案内された連絡先から問い合わせます。

問い合わせ時には、次のようなポイントをはっきり伝えると話が早く進みます。

「唯一のグローバル管理者アカウントでサインインを試みている」
「多要素認証（MFA）の SMS を選択すると、エラーコード 399287 で失敗し、ポータルに入れない」
「Phone/SMS にレピュテーション（悪い評価）が付いてブロックされている可能性があるので、ブロック解除とレピュテーションのクリアを依頼したい」

最初の一次サポートでは「パスワードリセット」や「別ブラウザーを試す」などの一般的な案内がされることもありますが、問題の本質はバックエンドのブロックである旨を繰り返し伝え、必要であれば「エンジニアリングチームへのエスカレーション」を求めます。

ステップ 3：解除後の動作確認

バックエンドのブロック解除・レピュテーションクリアが完了したら、すぐにサインイン動作を確認します。

同じグローバル管理者アカウントでサインインを試みる
SMS 認証を選択し、コードが正常に届くか、検証が通るか確認する
Microsoft 365 管理センターに入れたら、[課金] > [請求書と支払い] に移動し、請求書 PDF のダウンロードが行えるかを確認する

ここまで完了すれば、ひとまず「業務上の影響」は解消された状態です。
しかし、このまま SMS だけに頼り続けると、同じトラブルが再発するリスクが高いため、すぐに認証方式を見直すステップに進みます。

ステップ 4：復旧直後に必ず行うべき安全対策

ブロック解除後、正常にサインインできるようになった瞬間が、セキュリティ強化の最大のチャンスです。以下の設定を、可能な限りその場で実施してください。

Microsoft Authenticator を登録し、第一候補にする
- アカウントの「セキュリティ情報」から Microsoft Authenticator アプリを追加
- できれば「番号一致」「サインイン要求の通知承認」を有効化
FIDO2 セキュリティキー / パスキー（プラットフォーム）を追加する
- 物理セキュリティキー（USB/NFC）を登録し、別デバイスにもパスキーを設定
- 紛失や故障に備えて複数本登録しておく
SMS / 音声通話は「最後のバックアップ要素」に格下げする
- 管理者アカウントでは原則として SMS / 音声通話を使わない方針へ変更
- 一般ユーザー向けに限定する、またはバックアップ用として最小限だけ残す

このタイミングで、ブレイクグラス（非常用）アカウントの作成と、条件付きアクセスの見直しも同時に進めると、同種の障害に対する耐性が大きく向上します。

なぜ管理者に SMS 認証を使うべきではないのか

「とりあえず SMS で 2 要素認証を有効化しておけば安心」という考え方は、すでに時代遅れになりつつあります。特に管理者アカウントで SMS をメインに使い続けることは、技術的にも運用的にもリスクが高いと言えます。

SMS 認証の主な弱点

不正転送のリスク（キャリア側の転送設定を悪用される）
SIM スワップ攻撃（なりすましで SIM を再発行される）
IRSF（国際通話収益分配詐欺）など、電話番号を絡めた詐欺への悪用
キャリア依存・電波状況依存のため、安定性が低い
スパムフィルタやレピュテーション判定に巻き込まれ、正当な SMS が届かないケースがある

こうした理由から、Microsoft を含む多くのベンダーは、管理者や特権アカウントに対して SMS を用いた認証を推奨していません。代わりに、フィッシング耐性のある認証（FIDO2 / パスキー / Windows Hello / Authenticator 通知など）を推奨しています。

認証方式の比較

認証方式	特徴	管理者利用の推奨度
FIDO2 セキュリティキー / パスキー	フィッシング耐性が非常に高く、秘密情報はデバイス外に出ない	最優先で推奨
Microsoft Authenticator（通知＋番号一致）	プッシュ通知と番号一致により、誤承認やスパム承認を大幅に減らせる	管理者の標準方式として推奨
Microsoft Authenticator（コード表示）	アプリ内のコードを入力する方式。プッシュが使えない環境で有用	サブ的に推奨
SMS 認証	導入は簡単だが、IRSF や SIM スワップなどのリスクが高い	管理者では非推奨（バックアップ用途に限定）
音声通話認証	通話によるコード読み上げ。SMS 同様に悪用されやすい	管理者では非推奨
メールによるワンタイムコード	メールアカウントの乗っ取りと紐づきやすく、単独では弱い	単独利用は避けるべき

今回のようにSMS 認証がブロックされると、管理者自身もどうにもできないという構造的な問題もあります。これを機に、管理者アカウントの認証方式を全面的に見直すことを強くおすすめします。

Entra ID（旧 Azure AD）での再発防止設定と運用ベストプラクティス

ここからは、Microsoft Entra ID を前提とした再発防止策・運用のベストプラクティスを整理します。

認証方法ポリシーで「フィッシング耐性のある認証」を必須にする

Entra 管理センターでは、

Entra ID > セキュリティ > 認証方法

から、ユーザーごと・グループごとに利用可能な認証方法を制御できます。ここで、少なくとも以下を満たすように設計するのが望ましいです。

管理者ロール（グローバル管理者、特権ロール管理者、セキュリティ管理者など）には、FIDO2 / パスキー / Microsoft Authenticator を必須にする
管理者ロールに対しては、SMS / 音声通話を無効化するか、利用可能でも「バックアップのバックアップ」程度にとどめる
一般ユーザーに対しても、徐々にプッシュ通知＋番号一致など、フィッシング耐性の高い方式へ移行する

特に管理者グループには、専用のセキュリティグループを作成して認証方法ポリシーを割り当てておくと、誤設定を避けやすくなります。

条件付きアクセス（CA）で認証強度を要求する

次に、条件付きアクセスを使って、特権アカウントには常に強い認証を要求するポリシーを構成します。

対象ユーザー：管理者ロール・特権ロール・重要なアカウントを含むグループ
対象クラウドアプリ：Microsoft 管理ポータル、Entra 管理センター、Azure Portal など
アクセス制御：認証の強度（Authentication strength）で「フィッシング耐性のある MFA」を要求

これにより、仮に SMS が有効のままだったとしても、管理者が SMS だけで認証を通過することはできなくなります。

ブレイクグラス（非常用）アカウントを 2 つ用意する

「唯一の管理者がロックアウトされる」事態を避けるために、ブレイクグラスアカウントの準備は必須と言えます。少なくとも 2 アカウント用意し、以下のようなポリシーで運用します。

項目	通常管理者アカウント	ブレイクグラスアカウント
用途	日常的な管理作業	通常経路でサインインできないときの「最後の切り札」
パスワード	長く複雑、定期的に更新	非常に長いパスフレーズを設定し、オフラインで安全に保管
MFA	FIDO2 / Authenticator など複数手段	状況に合わせて慎重に構成（あえて CA から除外する場合も）
条件付きアクセス	厳格な CA ポリシーが適用される	原則 CA から除外し、ロックアウトの連鎖を防ぐ
使用頻度	日常的に利用	年数回の動作確認を除き、基本的にログインしない
監査	サインインログを定期的に確認	サインインが発生したら即座にアラートが飛ぶように設定

ブレイクグラスアカウントは、運用ルールとセットで設計しないと、

誰もパスワードを知らない
逆に日常的に使われてしまい、リスクが高まる

といった形で形骸化・危険化してしまいます。
「誰が」「どの場面で」「どの手順で」使用できるのか、あらかじめ文書化しておきましょう。

自己復旧（SSPR）と一時アクセスパス（TAP）の設計

管理者が複数いる環境であれば、SSPR（セルフサービスパスワードリセット）とTAP（一時アクセスパス）を組み合わせることで、ロックアウト時の復旧をかなり柔軟にできます。

SSPR を有効化し、各管理者に複数の回復手段（Authenticator、FIDO2、代替メールなど）を登録させる
管理者ロックアウト時の手順として、「別の管理者が TAP を発行し、ブートストラップ的に復旧する」フローを整備する
誰が TAP を発行できるか、承認フローや記録の残し方を決めておく

今回のように「管理者が 1 人だけ」の場合、どうしてもサポート頼みになってしまうため、可能であれば中長期的には管理者を複数名に増やすことも検討してください。

監視とログで「異常の兆候」を早期に検知する

レピュテーション悪化や電話系のブロックは、ある日突然表面化します。完全に防ぐことは難しいですが、サインインログやセキュリティアラートを監視することで、兆候に早く気付くことはできます。

サインインログにおいて、1 アカウントからの大量な SMS 認証試行がないか確認する
短時間に異なる国からのサインイン試行が連続していないか確認する
電話番号関連のブロックや、キャリア側エラーが増えていないかをモニタリングする

これらのログを、SIEM や監視サービスと連携し、アラートとして検知できるようにしておくと、業務に影響が出る前にサポートへ相談することが可能になります。

IRSF（国際通話収益分配詐欺）と SMS 認証の関係

今回のテーマから少し踏み込んで、IRSF（International Revenue Share Fraud：国際通話収益分配詐欺）についても触れておきます。

IRSF は、攻撃者が特定の国際電話番号やプレミアム番号に大量の通話・転送を発生させ、その通話料金の一部を不正に得る手口です。この過程で、

電話番号の不審な利用
異常な国際ルートを通じた通信

が発生するため、キャリアやサービス提供側の防御ロジックに引っかかり、当該電話番号のレピュテーションが一気に悪化することがあります。

SMS 認証や音声通話認証は、このような電話ベースの詐欺と親和性が高く、結果として、

正当なユーザーの認証 SMS や音声が届かなくなる
サービス側がブロックを強め、今回のようなエラーコードを返す

といった副作用を生みます。

この観点からも、管理者アカウントに電話ベースの認証を使うことは避けるべきであり、FIDO2 や Authenticator への移行はセキュリティと可用性の両面でメリットが大きいと言えます。

管理者アカウント運用のチェックリスト

最後に、今回のトラブルを教訓として、Microsoft 365 / Entra ID 管理者アカウント運用のチェックリストをまとめます。

チェック項目	状態	コメント
グローバル管理者が複数存在する	はい / いいえ	1 名しかいない場合は、早急に 2 名以上にする
ブレイクグラスアカウントが 2 つ以上ある	はい / いいえ	用途・運用ルール・保管方法を文書化しておく
管理者の認証方式に FIDO2 / Authenticator が設定されている	はい / いいえ	SMS / 音声通話が第一優先になっていないか確認
認証方法ポリシーで管理者には強い方式のみを許可している	はい / いいえ	管理者グループ向けのポリシーを用意する
条件付きアクセスで「フィッシング耐性のある MFA」を要求している	はい / いいえ	管理ポータル・特権操作には必ず強い認証を要求
SSPR と TAP の運用設計がある	はい / いいえ	ロックアウト時の復旧フローを事前に決めておく
サインインログ・セキュリティログを定期的に確認している	はい / いいえ	SIEM や監視サービスと連携して早期検知
請求書ダウンロード・課金作業を代替できる体制がある	はい / いいえ	特定の個人に依存しないよう、権限と手順を分散させる

これらの項目を定期的にレビューすることで、今回のような「唯一の管理者がロックアウトされる」リスクを大幅に減らすことができます。

まとめ：エラー「399287」をきっかけに認証基盤を見直す

本記事で扱ったポイントを、最後に整理します。

エラーコード 399287 は、今回のケースでは電話番号・アカウントに付与されたレピュテーション起因の SMS ブロックが原因だった
ユーザー側の設定変更だけでは解決できず、Microsoft サポート（エンジニアリングチーム）によるバックエンドのブロック解除・レピュテーションクリアが必要だった
復旧後は、Microsoft Authenticator や FIDO2 / パスキーを第一候補の認証方式として登録し、SMS / 音声通話はバックアップ用途に格下げすることで再発リスクを減らせる
ブレイクグラスアカウントを 2 つ以上用意し、SSPR / TAP を活用できるようにしておけば、単一管理者ロックアウトという最悪の状況を避けられる
IRSF をはじめとする電話系詐欺やキャリア側のブロックは、SMS 認証そのものの信頼性を揺るがす要因であり、管理者用途では電話ベースの認証を極力避けるべきである

もしすでに「管理者はみんな SMS 認証だけで運用している」という状態であれば、エラー 399287 が出ていなくても、今すぐ認証方式の見直しを始める価値があります。
今回のトラブルを、自社の認証基盤と運用ルールをアップデートするきっかけとして活用してください。

この記事を書いた人

佐藤健司

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