Microsoft Entra ID（Azure ポータルや Office.com）でサインインしようとすると SMS の MFA 認証コードが送れず、Error Code: 399287 で止まってしまうことがあります。SMS 以外の方法を登録していないと本人確認が完了できず、実質ログイン不能になります。ここでは原因の切り分けから復旧の現実的な進め方、再発防止の運用までを整理します。
症状：MFA の SMS 認証コードが送れず、Error Code: 399287 でサインインできない
Microsoft Entra ID（旧 Azure AD）を利用する環境では、Azure Portal、Microsoft 365（Office.com）、管理センターなどのサインイン時にMFA（多要素認証）が要求されることがあります。通常は SMS に認証コードが届きますが、何らかの理由でコード送信が失敗し、次のような状態になります。
| 起きること | 画面上の特徴 | 困るポイント |
|---|---|---|
| SMS 認証コードが送信されない | コード送信操作の直後にエラーになり先へ進めない | 本人確認を完了できず、サインインが詰む |
| Error Code: 399287 が表示される | Request Id / Correlation Id / Timestamp が併記されることが多い | ユーザー側の設定だけでは改善しないケースがある |
| SMS 以外の認証手段が無い | Authenticator や別手段の選択肢が表示されない | 「代替手段で回避」ができず、復旧まで業務停止 |
...onmicrosoft.com の“ビジネスアカウント”に見えて混乱 | 普段のアカウントと別物に見える／どの UPN で認証しているか曖昧 | 誤ったアカウントで試行を続けて長期化しがち |
ポイントは、「SMS が届かない」ではなく「SMS が送れない（ブロック/拒否される）」状態になっている場合があることです。特に Error Code: 399287 のパターンでは、ユーザーの端末や回線の問題に見えて、実際はMicrosoft 側のバックエンドで SMS が止められていることがあります。
まずやるべき切り分け：端末・回線の問題と、サーバー側ブロックを分ける
最短復旧を狙うなら、むやみに何十回も送信を試さず、最初に「ユーザー側で改善できる領域か」を切り分けます。ここでの狙いは、サポートへ出すべき情報を揃えつつ、無駄な試行でロックや疑い判定を悪化させないことです。
| 確認項目 | 具体的な確認方法 | 判定の目安 |
|---|---|---|
| SMS を受信できる状態か | 同じ番号に他サービスの SMS を送ってみる／家族・同僚から SMS を送ってもらう | 受信が全滅なら端末/回線/契約側の疑いが濃い |
| 迷惑 SMS ブロック/フィルタ | キャリア迷惑 SMS 設定、端末のブロック設定、メッセージアプリのフィルタを確認 | 受信はするが特定の送信元だけ消える場合に要注意 |
| 国番号・電話番号の登録形式 | 登録番号が国情報と一致しているか（例：日本なら +81）を管理者に確認 | 番号形式が崩れていると送信できない場合がある |
| 短時間に送信を連打していないか | 「何度も再送」していれば一旦止める（連打はリスク判定を悪化させやすい） | 送信回数が多いほど不利になりやすい |
| Error Code: 399287 と ID 情報 | エラー画面の Request Id / Correlation Id / Timestamp を控える（スクリーンショット推奨） | これが揃うとサポート側が追跡しやすい |
ここで「他の SMS は普通に受け取れるのに、Entra ID の送信だけ失敗する」「エラー画面に Request/Correlation/Timestamp が出る」という条件が揃う場合、端末ではなく、認証フロー側（Microsoft 側）で止まっている可能性が高くなります。
...onmicrosoft.com が出て混乱する理由：アカウント（UPN）とテナントの話
「普段使っているアカウントと違う表示に見える」「突然 ...onmicrosoft.com の“ビジネスアカウント”で認証しているように見える」という混乱は、Entra ID ではよく起きます。結論から言うと、これは別のアカウントに勝手に変わったというより、次のどれかが原因で“今サインインしようとしている主体”がズレていることが多いです。
| よくある混乱 | 起きがちな原因 | 整理のコツ |
|---|---|---|
普段は会社ドメインで入っていたのに onmicrosoft.com が出る | UPN（サインイン ID）がテナント既定ドメインのまま／表示上そう見える | 「どの UPN で入っているか」を最優先で特定する |
| 個人アカウントと職場/学校アカウントが混ざる | ブラウザにサインイン情報が残っている／選択画面で別を選んだ | 一度サインアウトし、InPrivate/シークレットで試す（情報収集目的） |
| 同じメールアドレスに見えるのにテナントが違う | ゲスト招待や複数テナント所属で「同名ユーザー」が存在する | 組織名（テナント名）表示を確認し、管理者に照会する |
| どのアカウントの MFA を直せばいいかわからない | 対象が「ユーザー」なのか「別テナントのゲスト」なのか不明 | エラー画面の情報＋対象 UPN をセットでサポートへ渡す |
特に重要なのは「いま止まっているのは、どの UPN（例：[email protected] なのか、[email protected] なのか）」です。これがズレたままサポートへ相談すると、調査対象が合わず、復旧が長引きます。
UPN を特定するために押さえるべき情報
- サインインに入力している ID（メールアドレス形式の文字列）
- 組織名（サインイン画面に表示される会社名・学校名）
- エラー画面の Request Id / Correlation Id / Timestamp
- 可能なら「どのサービスから入ろうとしているか」（Azure Portal / Office.com / Teams など）
「たぶんこのアカウントだろう」で進めるより、エラー画面の情報と一緒に、対象 UPN を確定させるほうが復旧は速いです。
Error Code: 399287 の核心：Microsoft 側で SMS がブロックされることがある
この事象の厄介な点は、ユーザーや管理者がいくら設定を見直しても、Microsoft 側の判定（バックエンド）で SMS が止められている場合があることです。現場では、次のような説明で扱われるケースがあります。
- アカウントや電話番号に対して不正/悪性の判定（いわゆる reputation 判定）が付いた
- その結果、SMS を使った追加認証が送信段階でブロックされた
- ユーザー側では解除できず、Microsoft 側でunblock / 判定クリアの対応が必要になる
もちろん原因はこれだけではありません。しかし、Error Code: 399287 のように「送信要求が通らない」「ID 情報付きで止まる」パターンでは、ユーザーの受信環境の問題ではなく、送信が許可されていない状態が疑われます。
なぜ SMS が止められるのか（背景として知っておくと納得しやすい）
SMS/音声を使った認証は、仕組みとして電話網（キャリアのネットワーク）を通ります。この領域では、IRSF（International Revenue Share Fraud：電話網を悪用した不正課金や不正中継など）を含むテレフォニー詐欺が問題になりやすく、サービス側は「怪しい兆候がある送信」を抑止する設計を取りがちです。
つまり、ユーザー視点では「急に届かなくなった」でも、サービス側は「不正利用を止めるために送らない」という判断をすることがあります。ここが、SMS が“便利だけど詰みやすい”と言われる理由です。
解決への最短ルート：現実的な復旧フロー（ユーザーだけで抱え込まない）
結論として、ユーザー側の努力だけで解決しないケースがあるため、状況に応じて「管理者」または「Microsoft サポート」を巻き込みます。復旧フローを分岐させると迷いません。
| あなたの立場 | 最短でやるべきこと | 狙い |
|---|---|---|
| 自分がテナント管理者（別の管理者アカウントで入れる） | 一時的なサインイン手段を用意し、SMS 以外へ移行 | ユーザーを詰ませずに復旧させ、再発も止める |
| 管理者ではない（自分も管理者も入れない/連絡が取れない） | 組織の IT 管理者へ連絡、またはサポート窓口で調査依頼 | バックエンド側のブロック解除を狙う |
| テナント管理者だが“唯一の管理者”がロックアウト | 緊急用アカウント（ブレイクグラス）が無いならサポートへ | 最悪ケース。復旧に時間がかかるため情報を揃える |
管理者ができる「詰ませない」暫定対応：Temporary Access Pass などで脱 SMS
管理者が別アカウントで Entra 管理センターに入れるなら、ユーザーにSMS 以外のサインイン経路を提供して、ログインできた瞬間にAuthenticator への移行まで一気に進めるのが最短です。
代表的な選択肢は次のとおりです（テナント設定によって使える/使えないがあります）。
- Temporary Access Pass（TAP）：一時的に使えるパスコードでサインインさせ、認証方法の再登録へ誘導
- MFA の再登録を要求：ユーザーの認証方法をいったん整理し、再セットアップへ（ただし“入れる手段”が別途必要）
- 条件付きアクセス/セキュリティ既定値の影響確認：例外設計や緊急時対応を検討（恒久的な無効化は非推奨）
重要なのは、復旧のゴールを「とりあえず入れた」ではなく、「SMS 依存から脱却して、次に詰まない状態にする」まで置くことです。SMS が通るようになっても、同じ構造のままだと再発します。
Microsoft 側の解除が必要なケース：サポートへ“調査＋ブロック解除”を依頼する
ユーザー側/管理者側でできることを尽くしても、SMS が送信されず Error Code: 399287 が続く場合、Microsoft 側の調査（バックエンド）が必要になります。このとき、依頼の出し方でスピードが変わります。
| サポートに伝える情報 | 具体例 | なぜ重要か |
|---|---|---|
| エラーコード | 399287 | 事象の入口。分類が早くなる |
| Request Id / Correlation Id | エラー画面に出る英数字 | サーバー側ログの追跡に直結する |
| Timestamp（時刻） | UTC 表記のこともある | 該当ログの検索範囲を絞れる |
| 対象アカウント（UPN） | [email protected] / [email protected] | 別アカウントを調査して空振り…を防ぐ |
| 認証方式 | SMS による MFA、送信できない | 音声/アプリ等と原因が変わる |
| 電話番号（国情報含む） | +81XXXXXXXXXX | 番号/国ごとの送信制御や判定の調査に必要 |
| 国/地域・キャリア | 日本、主要キャリア名など | 地域要因の切り分けに役立つ |
| スクリーンショット | エラー画面（ID と時刻が見える） | 伝達ミスを減らせる |
また、サポートに電話番号やアカウント情報を渡す必要がある場合は、公開の場に書かず、指定された手段で非公開（プライベート）共有を徹底します。組織のルールに従い、チケットやプライベートメッセージでの共有に限定してください。
問い合わせ文のテンプレ（そのまま使える形）
状況説明が長くなると要点が埋もれます。サポート側が調査を開始できる情報を、箇条書きで短く渡すのがコツです。
- 事象：Microsoft Entra ID サインイン時、SMS MFA の認証コードが送信されず失敗する
- Error Code：399287
- Request Id：XXXX（エラー画面の値）
- Correlation Id：XXXX（エラー画面の値）
- Timestamp：YYYY-MM-DD hh:mm:ss（エラー画面の値）
- 対象 UPN：user@xxxxx（onmicrosoft.com を含む場合は両方記載）
- 電話番号：+国番号…（例：+81…）
- 国/地域：Japan
- 依頼：SMS 送信がブロックされている可能性の調査、必要なら unblock / reputation 判定のクリアを実施してほしい
この形で出すと「何を調査すればいいか」「どのログを見ればいいか」が明確になり、やり取りの往復が減ります。
復旧確認：直ったかどうかは「SMS が届く」ではなく「サインインが完走する」で判断する
サポート対応後や管理者対応後は、次の順番で確認すると混乱が少ないです。
- 同じ UPN でサインインし、MFA 要求まで進む
- SMS の送信操作でエラーにならず、認証コードが届く
- コード入力後、サインインが最後まで完了する
- サインイン直後に「認証方法の追加/変更」に進み、SMS 以外を登録する
「コードは届いたが、最後で別エラーになる」「別アカウントで入れてしまった」などの取り違えを避けるため、完走確認が重要です。
再発防止の本丸：SMS 単独運用をやめ、Authenticator を軸に複数手段を登録する
今回のように SMS が送れない状態になると、SMS しか登録していないユーザーは本人であっても証明できず、結果としてロックアウトします。復旧後は「いつかまた起きる前提」で、認証方法を再設計してください。
推奨構成（現場で効く順番）
- Microsoft Authenticator を登録（可能なら最優先）
- 代替として Authenticator のコード（TOTP） も使える状態にする
- 可能なら FIDO2 セキュリティキー / パスキー の導入も検討
- どうしても SMS を残すなら、あくまで補助として位置づける
| 認証方法 | 安全性 | 運用性 | コメント |
|---|---|---|---|
| Microsoft Authenticator（プッシュ） | 高い | 高い | SMS より詰みにくい。端末変更手順は別途整備すると安定 |
| Authenticator（ワンタイムコード / TOTP） | 高い | 中 | 通知が届かない環境でも使える。バックアップ設計が重要 |
| FIDO2 セキュリティキー / パスキー | 非常に高い | 中〜高 | フィッシング耐性が強い。導入コストと社内教育が必要 |
| SMS | 低め | 高い（ただし詰むと重い） | 電話網由来のリスク（IRSF 等）とブロックがあり得るため単独は避ける |
| 音声通話 | 低め | 中 | SMS 同様にテレフォニー領域の影響を受ける。補助用途に留める |
「安全性」だけでなく「障害時に詰まない」ことも運用品質です。特に管理者アカウントや業務継続に直結するアカウントは、複数の認証手段を登録し、手順をドキュメント化してください。
“詰み”を設計で防ぐ：管理者・テナント運用のチェックポイント
SMS 障害をきっかけに、テナント全体の運用を見直すと再発が激減します。特に、Entra ID は「設定が正しいのに、緊急時の入口が無い」状態が起きやすいので、次の観点が重要です。
緊急時に入れる経路（ブレイクグラス）の整備
管理者が全員 MFA で詰むと、ユーザーの救済もできません。組織のポリシーに従いつつ、緊急用アカウントの扱いを決めます。
- 緊急用の管理者アカウントを複数用意し、日常利用しない
- 認証要件（条件付きアクセスやセキュリティ既定値）で、緊急アカウントの扱いを設計する
- 緊急アカウントのサインイン監視（アラート）を有効にする
- 保管方法（パスワード管理、責任分界）を文書化する
アカウント表記の混乱を減らす（UPN とドメイン整理）
onmicrosoft.com が悪いわけではありませんが、ユーザーが混乱しやすいのは事実です。次の方向で整理すると、トラブル時に対象特定が速くなります。
- 可能なら、ユーザーが普段使う UPN を会社のカスタムドメインに寄せる
- 「サインイン ID（UPN）」を社内で統一し、入社時/異動時の手順に組み込む
- 複数テナント/ゲストが絡む場合は、利用シーンごとに入口（URL/手順）を明確化する
| 運用項目 | 推奨 | 理由 |
|---|---|---|
| MFA の既定手段 | Authenticator を標準にする | SMS より詰みにくく、セキュリティ面でも有利 |
| 代替手段 | 最低 2 種類登録 | 一つ死んでも本人確認が続行できる |
| 管理者救済手段 | TAP や緊急アカウントの設計 | 障害時にユーザーを救えない事態を避ける |
| アカウント識別 | UPN・テナント名を台帳化 | 問い合わせ・調査が速い（誤認が減る） |
| 再登録手順 | 端末変更・紛失時の手順を用意 | 最も起きやすいのに放置されがちな事故を抑える |
よくある質問（現場で詰まりやすいポイント）
SMS が届かないだけなら、電話番号を変えれば解決しますか？
回線・端末・番号側の問題であれば改善する可能性はあります。ただし Error Code: 399287 のように送信がブロックされている疑いが強い場合、番号変更だけでは解けないことがあります。まずは対象 UPN とエラー情報を揃えて、管理者またはサポートに「送信が拒否されていないか」の観点で調査してもらうほうが早いです。
「普段のアカウント」と違う表示が出ます。乗っ取られたのでしょうか？
不安になりますが、表示の違いはテナント既定ドメイン（onmicrosoft.com）や複数アカウントの保持で起きることが多いです。重要なのは「いま認証しようとしている UPN がどれか」を確定させることです。エラー画面の情報と合わせて管理者に確認すると、対象の取り違えを防げます。
Request Id / Correlation Id / Timestamp は、なぜそんなに大事ですか？
これらはサポート側がバックエンドのログを追跡するための手がかりです。特に SMS 送信が内部的に拒否されている場合、ユーザー画面からは原因が見えにくいため、ログ追跡に必要な情報が揃っているかで解決までの往復回数が変わります。
復旧後、SMS を残してもいいですか？
「残す」こと自体は選択肢ですが、SMS 単独運用は避けるのが現実的です。SMS はテレフォニー領域の影響（不正対策・ブロック、IRSF など）を受けやすく、今回のように突然詰むリスクがあります。Authenticator を主軸にし、SMS は補助として位置づけるのが安全です。
まとめ：399287 の SMS 送信失敗は、Microsoft 側の解除で直ることがある。復旧後は SMS 依存をやめる
Microsoft Entra ID の MFA で SMS 認証コードが送れず Error Code: 399287 になる場合、ユーザー側の設定や端末だけでは解決できず、Microsoft 側（バックエンド）でのブロック解除・判定クリアが必要になるケースがあります。だからこそ、エラー画面の ID 情報を揃えて、管理者やサポートに「調査できる形」で依頼するのが最短です。
そして復旧したら、同じ詰みを繰り返さないために、Microsoft Authenticator を登録し、認証方法を複数用意してください。MFA は「強くする」だけでなく「止まらない」設計が、結局いちばんのセキュリティになります。
コメント