Microsoft 365（Outlook / ポータル）にサインインしようとしたときに「本人確認ができません」「エラー 399287」と表示され、SMS による多要素認証が通らず業務が止まってしまう――そんな状況からの復旧手順と、再発させないための Entra ID（旧 Azure AD）側の設計・運用ポイントを、実際の事例をもとに詳しく解説します。
エラー 399287「本人確認ができません」とは？
Microsoft 365 にサインインする際、ID・パスワードまでは正しいのに、MFA（多要素認証）の SMS が届かない、あるいは SMS 認証ステップで次のようなメッセージが出て止まってしまうことがあります。
- 「本人確認ができません」
- 「要求を完了できませんでした」
- サインイン ログ上のエラーコード: 399287
このエラーは、単純な「ワンタイムパスワードの入力ミス」ではなく、電話番号そのものが Microsoft 側の不正対策ロジックでブロックされている疑いが強いケースです。いわゆる電話番号の「reputation（評判）」が低下し、セキュリティ保護のため SMS / 音声通話が拒否されている状態と考えられます。
特に以下のような状況が重なっていると発生しやすくなります。
- 短時間に大量の SMS 認証要求を繰り返した
- 国際 SMS（海外宛て / 海外から）が絡む番号・キャリアを利用している
- IRSF（International Revenue Share Fraud：国際収益共有詐欺）などのテレフォニー詐欺対策上、疑わしいパターンに該当した
この状態に陥ると、ユーザー側で SMS の再送を何度押しても改善しません。テナント管理者が Microsoft サポートに依頼して、番号のブロック解除（reputation のクリア）を行ってもらう必要があります。
結論：Microsoft による番号ブロック解除と、認証方法の見直しが必須
本文で扱う実際の事例では、最終的に Microsoft 側で電話番号のブロック解除（reputation クリア）を行ったことで、サインインと SMS 認証が復旧しました。
しかし、これはあくまで「応急処置」です。再び同じ番号で大量の SMS 認証を行えば、同様のブロックが再発する可能性があります。そのため、根本的な再発防止策としては、Microsoft Authenticator アプリ（プッシュ通知＋番号一致）をメインの認証方法に切り替え、SMS / 音声通話は冗長手段にとどめる設計が重要です。
以降では、
- 今すぐ復旧したいときの実務手順（テナント管理者向け）
- サポートに伝えるべき情報とテンプレート
- Entra ID 側で行う再発防止の設定
- ユーザー向けセルフチェックと FAQ
を順番に解説していきます。
今すぐサインインを復旧したいときの流れ
業務影響が出ているときに、情シス / 管理者がまず行うべき流れをまとめると、次の 3 ステップになります。
- Microsoft サポートへの依頼（テナント管理者）
- ブロック解除後のサインイン確認（ユーザー＋管理者）
- 認証方法の見直しと Authenticator への移行
ざっくりとした対応の一覧を表にすると、以下の通りです。
| ステップ | 主体 | やること | ポイント |
|---|---|---|---|
| 1. サポート依頼 | テナント管理者 | エラー 399287 の詳細情報を添えて、番号ブロック解除（reputation クリア）を依頼 | Request Id / Correlation Id / Timestamp を必ず記録 |
| 2. 復旧確認 | ユーザー＋管理者 | プライベート ブラウザーで再サインインし、SMS 認証が通るか確認 | ダメなら、再度サインイン ログの「追加情報」を採取して再エスカレーション |
| 3. 再発防止 | 管理者 | Authenticator / パスキー中心に認証方法ポリシーを設計し、SMS/音声は冗長手段に限定 | 登録キャンペーンや案内メールでユーザーの移行を促進 |
テナント管理者向け：Microsoft サポートへの問い合わせ手順
エラー 399287 のように電話番号がブロックされている疑いがある場合、情報を揃えてからサポートへ依頼すると対応がスムーズです。最低限、次の情報を整理しましょう。
| 項目 | 内容 | 取得のヒント |
|---|---|---|
| エラーコード | 399287 | ユーザー画面のメッセージ、またはサインイン ログ |
| Request Id / Correlation Id | サインイン試行ごとに発行される GUID | Entra 管理センター → ID → サインイン → 対象のログを開いて確認 |
| Timestamp（UTC） | エラーの発生日時（UTC） | サインイン ログの日時を UTC で控える |
| ユーザー UPN | [email protected] の形式 | 対象ユーザーのサインイン ID |
| 電話番号 | +国番号電話番号（E.164 形式） | 例: +81xxxxxxxxxx。国/地域名も併記 |
| 事象の概要 | 本人確認ができない、SMS が届かないなどの症状 | ユーザーからの聞き取り内容を簡潔に整理 |
これらを踏まえて、サポートには次のように依頼します。
- エラー 399287 が発生していること
- 対象ユーザーと電話番号、国/地域
- 不正対策で番号がブロックされている可能性があるため、電話番号のブロック解除（reputation クリア）を希望すること
- 解除後は Microsoft Authenticator（プッシュ＋番号一致）へ移行予定であること
後述の「サポート提出用テンプレート」をそのまま使えば、毎回ゼロから文章を考えずに済みます。
ブロック解除後に行うサインイン確認
Microsoft 側で電話番号のブロックを解除してもらったら、必ずユーザーと一緒にサインインテストを行いましょう。ポイントは「キャッシュの影響を除外する」ことです。
- ユーザーに、ブラウザーの シークレット / プライベート ウィンドウ を開いてもらう
- Microsoft 365 ポータル（例:
https://portal.office.com）にアクセスし、通常通り ID / パスワードを入力 - MFA ステップで SMS が届くか確認する
- 届いたワンタイム パスワードを入力し、サインインが完了するかを確認
それでも失敗する場合は、Entra 管理センターのサインイン ログで当該試行を開き、「追加情報」や「詳細」を再度確認します。新しい Request Id / Correlation Id を添えて、サポートに再度エスカレーションしましょう。
なぜ SMS / 音声通話による MFA は非推奨なのか
今回のように、電話番号の reputation によってブロックされるリスクがあるのは、主に SMS / 音声通話を利用した MFA です。Microsoft 自身も、より安全な認証方法として Microsoft Authenticator アプリやパスキー（FIDO2）を推奨しています。
SMS / 音声通話が抱える代表的な問題点は次の通りです。
- IRSF などのテレフォニー詐欺に狙われやすい（不正な国際電話・SMS に利用されやすい）
- 国際 SMS の到達性が不安定（キャリアやローミング状況に依存）
- SIM スワップ攻撃など、電話番号ハイジャックのリスク
- ユーザーが海外出張中・機内モード・圏外などで利用できない場面が多い
対して、Microsoft Authenticator（プッシュ通知＋番号一致）や FIDO2 / パスキーは、
- フィッシング耐性が高い（番号一致やデバイス紐づけ）
- SMS や音声通話のコスト・到達性に依存しない
- IRSF のような電話料金を悪用する攻撃の対象になりにくい
といったメリットがあります。したがって、今回のような障害をきっかけに、組織全体の MFA 設計を見直し、「アプリ / パスキー中心、SMS / 音声は最低限」という方針へ移行することを強くおすすめします。
MFA 手段の比較表：何をメインにすべきか
代表的な認証方法を、セキュリティ・運用・ユーザー体験の観点で比較した表を用意しました。
| 認証方法 | 特徴 | セキュリティ | 運用上のポイント |
|---|---|---|---|
| Microsoft Authenticator （プッシュ＋番号一致） | スマホアプリに通知が届き、表示された番号を一致させて承認 | 高い（プッシュ爆撃対策、なりすまし耐性が高い） | スマホ必須。登録キャンペーンで全社展開しやすい |
| FIDO2 セキュリティキー / パスキー | 物理キーや OS / ブラウザーに紐づいたパスキーでサインイン | 非常に高い（フィッシング耐性） | キーの配布・紛失対応が必要。重要アカウントに優先導入 |
| SMS / 音声通話 | 電話番号宛てにワンタイム パスワードを送信 | 中程度（IRSF、SIM スワップ等のリスク） | 国際 SMS やキャリア事情に大きく依存。冗長手段に限定推奨 |
| メールによるコード | 登録メールアドレスにコード送信 | 低〜中程度（メールアカウント乗っ取りリスク） | パスワードリセット用途などに限定利用が現実的 |
認証方法の切り替え：ユーザー側の手順
ブロック解除後は、影響を受けたユーザーに対し、次のように案内して Microsoft Authenticator を登録してもらいましょう。
- ブラウザーで 「マイ アカウント」→「セキュリティ情報」（もしくは
https://aka.ms/mysecurityinfo）を開く - 「+ 方法の追加」から「Microsoft Authenticator」を選択
- スマホに Microsoft Authenticator アプリをインストール（済みなら不要）
- 画面に表示される QR コードをアプリでスキャンし、アカウントを登録
- テストコードの承認を行い、プッシュ通知が正常に届くことを確認
- 必要に応じて「デフォルトのサインイン方法」を「Microsoft Authenticator – 通知」に変更
このとき、同じ画面で SMS / 電話番号を削除してしまうと、万一スマホが故障した際の復旧手段がなくなるため、
- Authenticator（メイン）
- SMS / 音声 or 別デバイス Authenticator（バックアップ）
といった形で、最低でも 2 系統の認証方法を持たせるように案内すると安心です。
管理者向け：Entra ID の認証方法ポリシーで再発防止
個々のユーザー設定だけでなく、テナント全体として「どの認証方法を許可するか」を統制するには、Entra ID の 認証方法ポリシー（Authentication methods policy）を設計する必要があります。
認証方法ポリシーの設計ポイント
Entra 管理センターから、
- 「ID」→「セキュリティ」→「認証方法」
に進むと、許可する認証方法や対象ユーザー/グループを細かく制御できます。再発防止の観点からは、次のような方針がよく使われます。
| 認証方法 | 推奨設定例 | ねらい |
|---|---|---|
| Microsoft Authenticator | 組織全体で許可し、登録を必須化・推奨 | メイン MFA として統一し、ユーザー体験を標準化 |
| FIDO2 / パスキー | 特定グループ（管理者・重要アカウント）で必須または強く推奨 | 高リスクアカウントのセキュリティ強化 |
| SMS / 音声通話 | 必要最小限のグループに限定し、一般ユーザーには原則非推奨 | IRSF や電話番号ブロックのリスク低減 |
| 一時アクセス パス（TAP） | ヘルプデスク用に許可し、発行は厳格な手続きのもとで実施 | 紛失・機種変更時の安全な再登録手段として活用 |
登録キャンペーンで Authenticator 未登録ユーザーを洗い出す
Entra ID には、Authenticator の登録を促す 「登録キャンペーン」機能があります。これを有効化すると、Authenticator をまだ登録していないユーザーに対して、サインイン時に登録を促す画面を自動的に表示できます。
- 対象グループを段階的に拡大（IT 部門 → 部門リーダー → 全社）
- 移行期間中は SMS も残しつつ、最終的には「Authenticator 登録済みが標準」の状態に持っていく
といったステップを踏むことで、電話番号ブロックが再発しても影響度を小さく抑えられます。
条件付きアクセスでリスクを抑えた MFA 運用に
さらに、条件付きアクセス ポリシーを併用することで、「いつ」「どこから」「どのデバイスで」サインインしたときに MFA を要求するかを柔軟にコントロールできます。
- 社外ネットワーク・未知の場所からのアクセスに対してのみ MFA を必須にする
- 準拠デバイス（Intune 管理下の PC / モバイル）からのアクセスは、条件付きアクセスで緩和
- リスクの高い国・地域からのアクセスをブロック
こうした設計により、ユーザーが不要に SMS 認証を求められる回数を減らし、結果的に「怪しいトラフィック」と見なされる機会を減らすことにもつながります。
ユーザー側でできるセルフチェック
エラー 399287 のような深刻なブロックはユーザーだけでは解決できませんが、単純な設定ミスやキャリア側の問題で SMS が届いていないだけのケースも存在します。ヘルプデスクに連絡してもらう前に、次のチェックリストを案内すると切り分けがスムーズになります。
| チェック項目 | 確認すること |
|---|---|
| 日時・タイムゾーン | PC / スマホの日時が現地時間と合っているか、タイムゾーンが正しいか |
| 電波状態 | 圏外・機内モード・データ通信 OFF になっていないか |
| 国際 SMS の契約 | 海外からの SMS を受信できる契約か、ローミング時の制限がないか |
| 迷惑 SMS フィルタ | キャリアの迷惑 SMS フィルタでブロックされていないか（設定アプリを確認） |
| 電話番号の登録状況 | セキュリティ情報に登録されている番号が現行の番号と一致しているか |
| 代替認証手段 | Authenticator（別端末）や別電話番号など、第二の認証手段が登録されているか |
これらを確認しても解決しない場合、または画面に明示的に エラー 399287 が表示されている場合は、ユーザーの自己解決は難しいため、速やかにテナント管理者へエスカレーションしてもらうよう案内しましょう。
よくある質問（FAQ）
Q1. 自力で電話番号のブロック解除はできますか？
A. ほとんどの場合、できません。番号の reputation に基づくブロックは Microsoft 側の内部ロジックで判定されており、ユーザーやテナント管理者がポータル上の操作だけで解除することはできません。テナント管理者経由で Microsoft サポートに問い合わせ、ブロック解除（reputation クリア）を依頼する必要があります。
Q2. 別の電話番号を登録すれば解決しますか？
A. 一時的な回避策としては有効な場合がありますが、根本解決にはなりません。新しい電話番号でも同様の使い方をしていれば、再びブロックされる可能性があります。また、認証手段として電話番号に依存する設計自体のリスクは残ったままです。Authenticator / パスキーへの移行を前提に、SMS はあくまで冗長手段と捉えるのが現実的です。
Q3. なぜ Microsoft Authenticator やパスキーの方が安全なのですか？
A. 主な理由は次の通りです。
- フィッシング耐性：攻撃者が偽サイトにユーザーを誘導しても、番号一致や FIDO2 の仕組みにより認証情報を盗み取りにくい
- 電話網に依存しない：IRSF や国際 SMS の到達性問題の影響を受けない
- デバイス紐づけ：特定のスマホや物理キーに紐づいており、単なる「数字 6 桁」よりも盗まれにくい
このため、Microsoft だけでなく、多くのセキュリティベンダーや専門家が SMS による MFA からの脱却を推奨しています。
Q4. スマホが壊れた / 機種変更した場合はどうすればいいですか？
A. 事前にバックアップ手段を用意しておくことが重要です。
- 別デバイス（タブレットなど）にも Authenticator を登録しておく
- 一時アクセス パス（TAP）を使った復旧フローをヘルプデスクで用意しておく
- 特定のユーザーには FIDO2 キーを配布し、スマホとは別系統の認証手段として運用
こうした準備をしておけば、今回のような番号ブロックやデバイス故障が発生しても、業務停止を最小限に抑えられます。
Q5. 電話番号ブロックは再発しますか？
A. 残念ながら、条件が揃えば再発し得ます。特に国際 SMS や特定のキャリアを経由する場合、IRSF 対策ロジックとの兼ね合いでブロック判定されやすくなります。だからこそ、
- Authenticator / パスキー中心の認証設計に移行すること
- SMS / 音声に依存した運用（ワンタイムパスワードの連打など）をやめること
が、長期的な再発防止には不可欠です。
サポート提出用テンプレート（コピペして使えます）
最後に、Microsoft サポートへエスカレーションする際にそのまま利用できるテンプレートを掲載します。テナント管理者の方は、社内ナレッジやヘルプデスク用 Runbook に貼り付けておくと便利です。
事象: サインイン時に本人確認不可、エラー 399287
ユーザー: <UPN>
電話番号: +<国番号><番号>（国/地域: <国名>）
発生日時(UTC): <YYYY-MM-DDTHH:MM:SSZ>
Request Id: <...>
Correlation Id: <...>
希望対応: 電話番号ブロック解除（reputation クリア）の確認と実施
補足: 解除後は Authenticator（プッシュ＋番号一致）へ移行予定
問い合わせ時には、個人情報の扱いにも注意してください。
※ 個人情報（電話番号・メールアドレス等）は公開フォーラムに記載しないでください。必要な共有はプライベートメッセージやサポートチケットで行います。
運用面でのまとめ：情シス・管理者が押さえるべきポイント
エラー 399287「本人確認ができません」は、単純な設定ミスではなく、電話番号の reputation に関わる深刻なブロックである可能性が高い事象です。再発を防ぎつつ、業務影響を最小限に抑えるために、情シス・管理者は次のポイントを押さえておきましょう。
- サインイン ログの確認方法と、Request Id / Correlation Id / Timestamp の採取手順をヘルプデスクと共有しておく
- Microsoft サポート向けテンプレートを社内ナレッジに登録し、誰でもすぐにエスカレーションできる状態にしておく
- 認証方法ポリシーを見直し、Microsoft Authenticator（プッシュ＋番号一致）＋パスキーを標準に据える
- SMS / 音声通話は冗長手段に限定し、利用対象やシナリオを明確に決めておく
- ユーザー向けに「MFA が使えなくなったときの連絡先」と「スマホ紛失・機種変更時の手順」を周知しておく
今回のようなトラブルは、単に「障害対応」として終わらせるのではなく、組織全体の認証基盤をより安全で運用しやすい形にアップデートするチャンスです。この記事を参考に、Microsoft 365 / Entra ID の MFA 設計を見直し、電話番号ブロックや SMS 不達に振り回されない認証環境を整えていきましょう。
コメント