Azureサインインエラー399287で本人確認できない時の原因と対処法

iPhone の復元後に Microsoft Authenticator が使えなくなり、SMS 認証も通らず Azure にサインインできない――この記事では、実際に発生したエラーコード「399287」のケースをもとに、原因の考え方と管理者・利用者それぞれが今すぐ取るべき対処手順、そして再発防止につながる設計ポイントを詳しく解説します。

Azure へのサインインで本人確認できない（エラー 399287）とは

まずは、今回の事例の全体像を整理します。ポイントは次のとおりです。

iPhone を再充電・システム復元した後、Microsoft Authenticator が使えなくなった
企業アカウント（Microsoft Entra ID／旧 Azure AD）のサインイン時に、本人確認のための SMS コードも失敗
テナント管理者自身もログインできず、Azure ポータルや管理画面にアクセスできない
結果として、Azure 上のシステム・サービスが止まり、業務に重大な影響が出ている
サインインログには Error Code: 399287 と Request ID / Correlation ID / Timestamp が記録されている
画面上には、「サインインエラーのフラグ」を有効化 する案内が表示されている

これを表にすると、状況がより把握しやすくなります。

項目	内容
環境	Microsoft Entra ID（旧 Azure AD）テナント、iPhone + Microsoft Authenticator
発生タイミング	iPhone の再充電・システム復元後
主な症状	Authenticator が機能せず、SMS コードによる本人確認も失敗
影響範囲	一般ユーザーだけでなく、テナント管理者もサインイン不可
ログ上の情報	Error Code: 399287、Request ID、Correlation ID、Timestamp
画面の案内	「サインインエラーのフラグ」を有効化するリンク／ガイド

このようなケースでは、ユーザー側の操作だけでは解決できず、テナント側・Microsoft 側のバックエンド対応が必要になることが多いです。

今回の事例での最終的な解決内容

今回のケースでは、最終的に次のような対応で問題が解消しました。

Microsoft 側のバックエンドで、電話番号やトラフィックに付いていた 「悪評（bad reputation）」がクリア された
これにより、SMS 認証が再び通るようになり、Azure ポータルへのサインインが可能に

つまり、ユーザーの入力ミスや端末の不具合というよりは、テレコム／セキュリティ側の自動防御によるブロックが主な原因だったと考えられます。

この経験から導き出される重要な教訓は、次の 2 点です。

SMS / 音声通話だけに多要素認証 (MFA) を依存しない
Microsoft Authenticator 等の強固な認証方式を「主」、SMS を「予備」にする設計へ見直す

なぜ本人確認できなくなるのか：主な原因候補

エラー 399287 を含むサインイン時の本人確認エラーは、単一の原因とは限りません。今回のケースも含め、現実的に想定される主な原因は次のようなものです。

電話番号・トラフィックの「悪評（bad reputation）」

国際的なテレコミュニケーションの世界では、IRSF（International Revenue Share Fraud：国際収益共有詐欺）などに代表される通話・SMS を悪用した詐欺が多発しており、電話番号や通信経路に対して「評判スコア」のような概念が適用されることがあります。

短時間に大量の SMS がやり取りされた
特定の国・番号帯からのアクセスで不審な挙動が検出された
過去に不正アクセスや詐欺行為に悪用された番号帯と関連している

このような要因により、電話番号や発信元に「悪評」が付き、セキュリティ上の理由から SMS がブロックされることがあります。Azure 側から見ると、「SMS が届かない」「本人確認コードが利用できない」状態となり、結果として認証が通らなくなります。

Authenticator 登録情報の失効・復元ミス

もう一つの典型的な要因が、端末復元後に Microsoft Authenticator の登録情報が正しく復元されていないケースです。

iPhone を初期化／システム復元した結果、Authenticator アプリ内のアカウント情報が消えた
クラウドバックアップを有効化していなかったため、以前の MFA 共有情報が復元されない
テナント側でセキュリティポリシーが変更され、古い登録情報が無効化されていた

この場合、アプリ上でアカウントが見えていたとしても、サーバー側には「すでに無効なデバイス」と認識されている可能性があります。その結果、プッシュ通知やワンタイムパスコードによる認証が受け付けられません。

その他の要因（条件付きアクセスやリスクベースポリシー）

加えて、次のような要因も間接的に影響することがあります。

条件付きアクセスで 「信頼されていない国・ネットワークからのサインインをブロック」 している
ユーザーやサインインがリスクと判定されると、追加の MFA を要求しつつブロック閾値を超えてしまう
時間帯やデバイスプラットフォームに応じた制御で、新しい iPhone からのアクセスが弾かれる

まとめると、「端末・アプリ側の問題」と「バックエンドのセキュリティ制御」が組み合わさることで、表面的には「SMS も Authenticator もダメ」という事象として現れていると考えるべきです。

原因カテゴリ	具体例	典型的な症状	確認ポイント
テレコム／悪評	IRSF 対策で番号ブロック	SMS が届かない、本人確認コードが不達	他サービスでも SMS が届かないか、国際 SMS の扱い
Authenticator 側	登録情報の失効、バックアップ未設定	プッシュ通知が来ない、コードが認証されない	管理ポータルの MFA 状態、端末変更の履歴
ポリシー設定	条件付きアクセス、リスクベース	一部の場所・デバイスだけ失敗する	サインインログの条件付きアクセス結果・リスク

いますぐできる一般的な対処手順（再発時の手引き）

同様のトラブルが再発した場合、ユーザー・管理者がとるべき「今すぐできる」標準的な手順を整理します。

1. 画面の「サインインエラーのフラグ」を有効化し、20 分以内に再現

サインイン画面に「サインインエラーのフラグを有効にする」といったリンクが表示されている場合は、必ずこれを有効化してから、同じ手順でエラーを再現してください。目安は20 分以内です。

この操作により、問題発生時の詳細な診断情報が Microsoft 側に送信される
サポートへのエスカレーション時に、原因調査が格段にしやすくなる
あとからフラグを有効にしても、過去の失敗には遡れないことが多い

「とりあえず何度も試してから問い合わせる」のではなく、最初の数回の失敗時点でフラグを有効化して再現する習慣をつけると、後の対応がスムーズになります。

2. サポート／テナント管理者に渡す情報を整理する

併せて、次の情報をあらかじめメモしておき、サポートや管理者に共有できるようにしておきましょう。

テナント名／テナント ID
影響を受けているユーザーの UPN（メールアドレス）
利用している 電話番号（+国番号付き） と国名
Error Code（399287）
Request ID、Correlation ID
Timestamp（UTC または現地時刻で記録）
どの画面で、どの操作をしたときにエラーになったか（スクリーンショットがあるとなお良い）

この情報が揃っていれば、テナント管理者や Microsoft サポートが「バックエンドのブロック解除」や「悪評クリア」の対応に進みやすくなります。

3. 管理者がサインインできない場合の対処方針

今回のケースのように、テナント管理者自身もサインインできない場合は、次の順で検討します。

既定のブレークグラス管理者アカウントでログインできないか確認
ログインできる管理者がいれば、対象ユーザーの MFA をリセット または Temporary Access Pass (TAP) を発行
どうしても誰も入れない場合は、Microsoft サポートにテナント所有者確認書類を添付してエスカレーション

ブレークグラスアカウントは、後述するように「緊急用の最後の砦」として設計しておく必要があります。

テナント管理者が行う具体的な操作

ここからは、管理者視点での具体的な操作をもう少し踏み込んで解説します。

MFA 状態のリセット

ユーザーの MFA 設定が壊れている／整合性が取れないと判断される場合、管理者は対象ユーザーの MFA をリセットできます。概念的な手順は次のとおりです（実際の UI は随時変わる可能性があります）。

Entra 管理センターに管理者でサインイン
「ユーザー」から対象ユーザーを検索・選択
「認証方法」または「多要素認証」の設定画面を開く
登録済みの認証方法を削除／リセット する
ユーザーに対し、次回サインイン時に新しい認証方法の登録を行うよう案内

この際、Authenticator を最優先で再登録させ、そのうえで SMS や音声通話を予備として追加させるとよいでしょう。

Temporary Access Pass (TAP) の発行

TAP（Temporary Access Pass） は、限られた期間だけ有効な一時コードを発行し、それを使ってユーザーにサインインさせる仕組みです。MFA が壊れてしまったときの「救済用チケット」として非常に有効です。

有効期限を短く設定できる
1 回または複数回利用のどちらかを選べる
このコードでサインインさせ、その場で Authenticator や FIDO2 キーを登録させる 運用が可能

管理者は、対象ユーザーの TAP を発行し、安全な経路（対面や電話など）で伝えたうえで、即座に新しい強固な認証方法に切り替えることが重要です。

Microsoft サポートへのエスカレーション

「サインインエラーのフラグ」を有効化しても改善せず、MFA リセットや TAP 発行でも根本的なブロック解除ができない場合は、Microsoft サポートへの問い合わせが必須となります。

特に、電話番号の悪評やバックエンドのブロック解除は、管理者だけでは対応が難しい領域です。その際には、先ほど整理したエラー情報やユーザー情報に加え、テナント所有者であることを証明する書類（契約情報など）が求められることがあります。

Microsoft Authenticator を主役にするべき理由

今回のように SMS がブロックされると、「SMS に依存した MFA 設計」の脆さが一気に露呈します。Microsoft 自身も、SMS / 音声通話は強度の低い認証方法として位置付けており、可能な限り Authenticator や FIDO2 キーなどに移行することを推奨しています。

SMS / 音声通話が抱えるリスク

IRSF をはじめとするテレフォニー詐欺に弱い
SIM スワップ攻撃など、電話番号を乗っ取られるリスクが存在する
圏外やローミング、海外渡航時など、電波状況やキャリア事情に左右されやすい
企業側のコスト（通話料金・SMS 料金）が継続的に発生する

Authenticator / FIDO2 キーとの比較

主要な認証方法を比較すると、次のようなイメージになります。

認証方法	セキュリティ強度	ユーザー操作性	外部依存	推奨度
Microsoft Authenticator（通知）	高い（プッシュ通知 + アプリ保護）	タップだけで認証できる	インターネット接続のみ	最優先で採用したい
Microsoft Authenticator（ワンタイムコード）	高い（時間ベースワンタイムパスワード）	数字を入力する一手間	オフラインでも使用可能	通知の補完として有効
FIDO2 セキュリティキー / パスキー	非常に高い（フィッシング耐性）	キーを挿す／タップするだけ	物理キーの管理が必要	高セキュリティ用途に最適
SMS / 音声通話	相対的に低い（テレフォニー詐欺、SIM スワップ）	誰でも直感的に使える	キャリア・回線品質に依存	予備としての採用に留める

この表からもわかるように、Authenticator と FIDO2 キーを組み合わせた構成が、セキュリティと使い勝手のバランスが最も良いと言えます。SMS は「どうしても必要な場面のバックアップ」として位置付けるのが現実的です。

再発防止のための認証設計と運用ルール

今回のような「誰もサインインできない」事故を防ぐには、単に一度直すだけでなく、認証方法の設計と運用ルールを見直すことが重要です。

認証方法は必ず複数登録させる

ユーザーごとに、少なくとも次のような構成を目指しましょう。

Microsoft Authenticator（通知 or ワンタイムコード）
FIDO2 セキュリティキー／パスキー
（必要に応じて）電話番号（SMS／音声は予備扱い）

特に管理者・特権ユーザーについては、1 つの認証方法が使えなくなっても、すぐに別の方法でサインインできる冗長性を必須とすべきです。

Authenticator のクラウドバックアップを標準にする

端末変更や復元時のトラブルを減らすため、Authenticator アプリのクラウドバックアップを有効化し、その利用を社内ルールとして周知します。

新しい端末に切り替える前に、既存端末側でバックアップが有効か確認
切り替え後、最初のサインイン時に Authenticator の登録状況をテスト
うまく移行できなかった場合でも、管理者が TAP や MFA リセットで迅速にリカバリできるようにする

ブレークグラス管理者アカウントを 2 つ用意する

テナント全体がロックアウトされる事態に備えて、2 つの独立したブレークグラス（緊急用）管理者アカウントを用意するのがベストプラクティスです。

設計ポイント	内容
アカウント数	最低 2 アカウント（片方が使えなくなってももう一方でリカバリ可能）
パスワード	長く複雑で推測困難なものを設定し、厳重にオフライン保管
サインイン制限	利用場所・IP アドレスを強く制限し、日常利用はしない
監査	サインインが発生したら即アラートが飛ぶように監視設定
使用ルール	「本当に緊急時のみ使用」「利用後は必ず設定を見直す」などの手順を文書化

ブレークグラスアカウントは、「普段は眠っているが、非常時には必ず機能してくれる最後の砦」です。今回のように管理者もロックアウトされる事態を想定し、設計段階から組み込んでおきましょう。

サインインログとリスクレポートの定期監視

トラブル発生後に慌ててログを見始めるのではなく、平常時からサインインログやリスクレポートを定期的に確認する運用を作ると、異常に早く気付くことができます。

ログ／レポート種別	主な確認内容	活用目的
サインインログ	エラーコード、条件付きアクセスの結果、失敗パターン	異常な失敗増加や特定ユーザーの問題を早期検知
リスクのあるサインイン	不審な場所・IP・デバイスからのアクセス	不正アクセス兆候の把握とブロック方針の調整
リスクのあるユーザー	パスワード漏洩などのリスクシグナル	MFA の強化やパスワードリセットの判断材料

また、今回のようなエラーが出た場合は、該当ユーザー周辺で同様の失敗が増えていないか も併せて確認し、広範囲な障害なのか、限定的な問題なのかを切り分けることが重要です。

現場でそのまま使えるサポート依頼テンプレート

最後に、実際のサポート依頼時にコピペして使えるテンプレートを掲載します。自社向けに少しカスタマイズしておくと、トラブル発生時の初動が格段に速くなります。

事象: Azure/Entra サインインで本人確認不可。Error Code 399287。SMS も失敗。
日時: &lt;UTC または現地時刻&gt;
Request ID: &lt;貼り付け&gt;
Correlation ID: &lt;貼り付け&gt;
ユーザー: &lt;UPN/メール&gt;
電話番号: +&lt;国番号&gt;&lt;番号&gt;（国: &lt;国名&gt;）
テナント: &lt;テナント名 / テナントID&gt;
実施済み: 「サインイン エラーのフラグ」有効化し再現済み
要望: バックエンド側のブロック/悪評クリア、MFA リセット/TAP 発行支援

このテンプレートを使うことで、エラー 399287 を含むサインインエラーの際に、必要な情報を漏れなく、短時間で提供できるようになります。

よくある疑問への Q&A

Q. Authenticator がない状態で、どうやって最初の一歩を踏み出せばいい？

A. ユーザー自身ではどうしようもないケースが多く、テナント管理者の TAP 発行や MFA リセットが必須です。まずは社内の IT 管理窓口に連絡し、「エラーコード 399287」「SMS も失敗している」ことを伝えましょう。

Q. 一度バックエンドのブロックが解除されたら、もう安心？

A. いいえ。今回のようなブロックは、再度「悪評」が付けば再発しうるものです。SMS 頼みの設計を改め、Authenticator や FIDO2 キーなどの強固な認証方法に移行することが根本的な対策となります。

Q. 海外出張やローミング環境では、何に注意すべき？

A. 海外では SMS が届きにくくなったり、異常なトラフィックとみなされたりするリスクが高まります。渡航前に Authenticator と FIDO2 キーを必ず登録し、SMS に頼らなくてもサインインできる状態にしておくことを強く推奨します。

Q. エラー 399287 だからといって、必ず電話番号の悪評が原因？

A. ログ上のエラーコードだけでは、必ずしも単一の原因に断定できません。サインインエラーのフラグを有効にしたうえで、サインインログやサポートの解析結果を総合的に見る必要があります。

まとめ：Authenticator を「主」、SMS を「従」にした設計へ

今回は、Azure へのサインインで本人確認ができず、エラー 399287 が発生した事例をもとに、原因の可能性と対処手順、再発防止のポイントを整理しました。

電話番号やトラフィックがテレコム側の対策で「悪評」扱いとなり、SMS 認証がブロックされることがある
端末復元などにより、Authenticator の登録情報が失効している場合も多い
今回のケースでは、バックエンド側のブロック解除（悪評クリア）によって SMS 認証が回復し、サインインが可能になった
しかし、根本的には SMS 依存の MFA 設計から脱却し、Authenticator や FIDO2 キーを主役とする構成に改めるべきである
ブレークグラス管理者、TAP、複数認証方法の登録、ログ監視といった仕組みを事前に整えることで、再発時の停止時間を最小化できる

エラー 399287 自体は一つの通過点に過ぎません。重要なのは、このトラブルをきっかけに認証基盤の設計と運用を見直し、「誰もサインインできない」時間を限りなくゼロに近づけることです。この記事を参考に、自社テナントの MFA 設計・運用ガイドラインをアップデートしてみてください。

この記事を書いた人

佐藤健司

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

Azureサインインエラー399287で本人確認できない時の原因と対処法

Azure へのサインインで本人確認できない（エラー 399287）とは

今回の事例での最終的な解決内容