Microsoft Entra（旧 Azure AD）/ Microsoft Security 環境で、通話（電話呼び出し）認証や SMS（テキスト）認証による多要素認証（MFA）を実行すると「Error Code: 399287」が表示され、サインインできないケースがあります。この記事では、エラー 399287 が示す状態、管理者が取るべき現実的な対応、Microsoft サポートへ渡すべき情報、そして復旧までの暫定回避策を具体的にまとめます。
エラー 399287（通話/SMS MFA）とは：現象の特徴
エラー 399287 は、Microsoft Entra のサインイン時に 通話認証または SMS 認証での MFA が成立しないときに表示されることがあります。画面上には次のような情報が併記されるのが典型です。
- Error Code: 399287
- Request Id または Correlation Id
- Timestamp（発生時刻）
特にやっかいなのは、同じ組織内だけではなく、複数ユーザー、場合によっては別テナントの管理者やユーザーも同様に 399287 に遭遇しており、「自分たちの設定が悪いのか」「自力で解除できるのか」が判断しづらい点です。
| 観点 | よくある状況 | ポイント |
|---|---|---|
| 発生タイミング | 通話/SMS で MFA を実行した直後 | パスワード入力後の追加認証フェーズで止まる |
| 影響範囲 | 特定ユーザーのみ〜複数ユーザー | 同一番号・同一拠点など共通点がある場合も |
| 表示情報 | Error Code / Request Id / Timestamp | この情報が復旧の最短ルートになる |
原因：MFA が「bad reputation」として Microsoft 側でブロックされている
結論から言うと、エラー 399287 は対象アカウントの MFA（通話/SMS）が「bad reputation（不正の疑いがある状態）」として Microsoft 側でブロックされていることが原因として説明されるケースがあります。
ここで重要なのは、これはテナント管理者が画面操作で解除できる種類のブロックではない点です。パスワード変更、認証方法の再登録、電話番号の再入力、サインインのやり直しなど、管理者が思いつく「一般的な対処」を一通り試しても、根本のフラグが Microsoft 側に残っている限り、通話/SMS は失敗し続けることがあります。
「bad reputation」ブロックが疑われるサイン
- 電話は通じる/SMS も受信できる環境なのに、MFA だけ 399287 で失敗する
- 同じ番号・同じキャリア・同じ国/地域など、条件が似たユーザーで連鎖する
- ユーザー側の端末変更や再登録では改善しない
- エラー画面に Request Id / Correlation Id / Timestamp が明確に出ている
なお、なぜ bad reputation と判定されたのかは、運用上のセキュリティ判断（不正利用対策）に関わるため、一般公開の情報だけでは断定できません。記事としては踏み込みすぎず、現場対応として「解除に必要な動き」を最短化するのが得策です。
まず押さえるべき現実：自分たちだけで解除できないケースがある
エラー 399287 を前にすると、管理者は次のような操作を試しがちです。しかし、bad reputation ブロックが原因の場合、これらは「周辺整理」にはなっても、解除そのものには直結しないことがあります。
| よく試される対処 | 期待 | bad reputation ブロック時の現実 |
|---|---|---|
| ユーザーのパスワード変更 | サインインが復旧する | 電話/SMS のブロックは残ることがある |
| MFA 方法の削除→再登録 | 認証情報がリセットされる | Microsoft 側の評価フラグは別管理の可能性 |
| 電話番号の変更・再入力 | 別の番号なら通る | ユーザー側だけで解けない場合がある |
| 端末/ブラウザ変更、キャッシュ削除 | クライアント要因を排除 | 根因がサーバー側なら改善しない |
だからこそ、次章の「Microsoft サポートへ渡す情報の準備」を最優先に進めるのが、復旧までの最短ルートになります。
解決策：Microsoft サポート経由で内部チームに解除してもらう
このタイプの 399287 は、Microsoft サポートに問い合わせ、必要情報を共有したうえで内部エンジニアリングチームにブロック解除を依頼することで解決した、という報告が現実的な落としどころです。
ポイントは「問い合わせる」ではなく、最初から調査に必要な材料をセットで渡すことです。Request Id / Correlation Id / Timestamp が揃うと、サポート側が内部ログを追いやすくなり、やりとりの往復が減ります。
サポートに伝えるべき情報（これだけは揃える）
| 項目 | 具体例 | メモ |
|---|---|---|
| テナント ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | Entra 管理センターのテナント情報などで確認 |
| テナント名 | Contoso | 口頭・文章の識別用。ID とセットで |
| 影響ユーザーの UPN | [email protected] | 複数いる場合はリスト化 |
| エラーコード | 399287 | 必ず明記 |
| Request Id / Correlation Id | 画面に出た ID | 複数回出るなら「最新の失敗分」を優先 |
| Timestamp | 2025-xx-xx xx:xx:xx | タイムゾーン（JST/UTC）も明記 |
| 発生条件 | 通話 / SMS、アプリ名、場所 | 「どの MFA 手段で失敗するか」を分けて書く |
サポート起票の現実的なルート
組織のロールや契約形態によって入口は変わりますが、一般的には次のどちらかが現実的です。
- Azure ポータル / Entra 管理センターからサポート要求を作成
- Microsoft 365 管理センターからサポート チケットを作成
どちらの入口でも、最終的に「内部で調査できる材料（Request/Correlation と時刻）」が揃っているかが勝負です。
管理者が準備しておくと復旧が早いもの
サポートに投げる前に、管理者側でできる「準備」をしておくと、切り分けと復旧が早まります。ここでは、自分たちで解除できない前提を崩さず、それでもサポートが動きやすい状態を作るための手順に絞ります。
サインイン情報の整理（ユーザーから回収する内容）
- エラー画面のスクリーンショット（Request/Correlation/Timestamp が写るもの）
- 失敗した MFA 方法（通話 / SMS）
- 失敗したアプリ（例：Microsoft 365 ポータル、Outlook、Teams、VPN など）
- 発生した場所（社内/社外、国/地域、回線種別：モバイル/固定/社内 Wi-Fi）
- 連続試行した回数（短時間に何回も試すと状況が悪化する可能性があるため、控えめに）
「Flag sign-in errors for review（サインイン エラーのフラグ付け）」を活用する
一部の画面や案内で「Flag sign-in errors for review」という項目に触れられることがあります。これを有効化した状態で再現させると、サポート側で診断情報を追いやすくなることがあります。
ただし、組織の設定や管理画面の更新状況によって表示や導線が異なる場合があります。見つからない場合は無理に探し回るより、Request/Correlation/Timestamp を確実に押さえる方が効果的です。
暫定回避策：どうしても今サインインが必要な場合の選択肢
業務上「サポートの解除を待てない」ことはよくあります。ここでは、電話/SMS が詰まったときに代替手段で復旧できる可能性がある選択肢をまとめます（ただし、ブロック範囲によっては同じように失敗することもあります）。
代替 MFA 手段の候補
| 手段 | 強み | 注意点 |
|---|---|---|
| Microsoft Authenticator（プッシュ/番号照合） | SMS/通話より強固で運用もしやすい | 初回登録の導線を確保する必要がある |
| FIDO2 セキュリティキー / パスキー | フィッシング耐性が高い | 事前配布やデバイス要件がある |
| Temporary Access Pass（TAP） | 管理者主導で一時的に登録を進めやすい | 組織のポリシー設計が必要（有効期限・回数など） |
| 別アカウント（緊急用ブレークグラス） | 管理系の復旧に役立つ | 運用設計が必須。平時から準備していないと間に合わない |
現場で多いのは、Temporary Access Pass（TAP）で一度サインインし、Authenticator 登録へ誘導するパターンです。これにより、電話/SMS に依存しない認証へ移行でき、同種トラブルの再発リスクも下げられます。
ただし、ここでの主目的は「ブロック解除」ではなく業務継続のための迂回です。根本対応（bad reputation フラグ解除）は、引き続きサポートへ依頼するのが安全です。
サポート問い合わせ文テンプレート（そのまま貼れる形）
サポートとの往復を減らすため、最初の連絡で必要情報をまとめて提出するのがコツです。以下は実務で使いやすいテンプレートです（自社情報に置き換えてください）。
件名：Microsoft Entra MFA（通話/SMS）で Error Code: 399287 が発生しサインイン不可 【事象】 Microsoft Entra のサインインにて、通話認証または SMS 認証を使用すると Error Code: 399287 が表示され失敗します。 ユーザー側の再試行、端末/回線変更、MFA 再登録等では解消しません。 【対象テナント】 Tenant ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Tenant 名：Contoso 【影響ユーザー】 UPN：[email protected] UPN：[email protected]（複数いる場合は追記） 【エラー情報】 Error Code：399287 Request Id：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Correlation Id：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx（表示がある場合） Timestamp：2025-xx-xx xx:xx:xx JST（タイムゾーン明記） 【補足】 ・失敗する MFA 方法：通話 / SMS（該当するもの） ・発生アプリ：例）Microsoft 365 ポータル / Teams / Outlook ・発生場所・回線：例）日本、モバイル回線 ・エラー画面のスクリーンショット添付：あり（Request/Correlation/Timestamp が写るもの） 【依頼】 本件、MFA が bad reputation 等の理由でブロックされている可能性があると考えています。 内部チームでの調査およびブロック解除可否をご確認ください。
テンプレートのままでも通じますが、特にTimestamp のタイムゾーンと、エラー画面のスクリーンショットがあると、初動が速くなりやすいです。
解除後にやるべきこと：復旧で終わらせない
Microsoft 側でブロックが解除され、通話/SMS でサインインできるようになっても、そこで終わりにすると再発しやすくなります。エラー 399287 はセキュリティに関係する文脈で語られることが多いため、復旧後は「通常運用に戻す」だけでなく、安全側に寄せる後処理をおすすめします。
| 項目 | 実施内容 | 狙い |
|---|---|---|
| 認証手段の見直し | SMS/通話依存を減らし、Authenticator や FIDO2 を優先 | 同種トラブル・攻撃耐性の両面で改善 |
| 影響ユーザーの棚卸し | 同条件（同キャリア/同地域/同番号形式）のユーザーを確認 | 潜在的な影響の把握 |
| サインイン監視 | 失敗が多いユーザー、短時間多発、国外などの傾向を監視 | 再発・不正兆候の早期検知 |
| 運用手順の整備 | Request/Correlation/Timestamp の回収手順を社内標準化 | 次回の復旧時間を短縮 |
再発を減らす実務ポイント：SMS/通話を「最後の手段」にする
SMS と音声通話は導入が簡単な一方で、フィッシングや番号乗っ取り（SIM スワップ等）などのリスクが指摘されやすく、運用上もトラブルが起きやすい手段です。エラー 399287 のようなケースを経験すると、組織としては次の方針が現実的です。
- 通常運用は Authenticator / FIDO2 / パスキー中心にする
- SMS/通話は「どうしても無理なユーザー向けの暫定」や「限定用途」に寄せる
- 新規入社・端末更改のタイミングで移行を進める（いきなり全社切替より成功しやすい）
- 緊急時のために TAP や ブレークグラスなどの復旧導線を用意しておく
こうした設計に寄せておくと、万が一電話/SMS がブロックされても「ログインできる手段がゼロ」になりにくく、業務停止のリスクを下げられます。
よくある質問（エラー 399287）
Q. ユーザーがパスワードを変えれば直りますか？
A. 直る場合もありますが、エラー 399287 が bad reputation ブロックに起因するケースでは、パスワード変更だけで解除できないことがあります。まずはエラー画面の Request Id / Correlation Id / Timestamp を回収し、サポートに提出できる形に整えるのが近道です。
Q. 管理者が MFA をリセット（再登録）すれば直りますか？
A. 一般的な MFA 問題には有効ですが、399287 の文脈では、ユーザー側の再登録では解消しないことがあります。再登録は「状況整理」にはなりますが、根本解除はサポートが必要になる可能性を前提に動くのが安全です。
Q. 解除までの間、業務を止めない方法はありますか？
A. 可能性としては、Authenticator や FIDO2、Temporary Access Pass（TAP）など、電話/SMS 以外の MFA 方法を使うことで迂回できる場合があります。ただしブロックの範囲によっては別手段でも失敗することがあるため、並行してサポートへの依頼は進めてください。
Q. サポートに渡す情報で一番大事なのは？
A. Error Code: 399287 と、Request Id / Correlation Id、Timestamp（タイムゾーン付き）です。これが揃うと内部ログ調査が進みやすく、解決までの往復が減ります。
まとめ：399287 は「自力で頑張る」より「正しい材料でサポートに渡す」が最短
- エラー 399287 は、通話/SMS MFA が bad reputation として Microsoft 側でブロックされていることが原因の可能性が高い
- ユーザー/管理者の通常操作だけでは解除できない場合があるため、Microsoft サポート経由で内部チームの解除が現実的
- サポートには Tenant ID、UPN、Error Code、Request/Correlation、Timestamp を揃えて提出する
- 解除を待つ間は、Authenticator / FIDO2 / TAP など電話/SMS 以外の手段で業務継続を検討する
コメント