Azure AD / Microsoft Entra ID で、これまで問題なく使えていたSMSによる多要素認証（MFA）が、突然「BadReputation」「エラー 399287」で一斉に失敗することがあります。本記事では、この現象の正体と、管理者がすぐに取るべき対処手順、再発防止の考え方をまとめます。
SMSによるMFAが「BadReputation」で失敗するとは
テナントでSMSを使った多要素認証（Text message / SMS）を利用していると、ある日から突然、特定ユーザーや複数ユーザーでMFAが通らなくなることがあります。このとき、ユーザー側には「コードが届かない」「MFAを完了できない」としか見えませんが、サインインログには次のような情報が記録されています。
| 項目 | ログ上の値の例 |
|---|---|
| Authentication method | Text message (SMS) |
| Failure reason | Multi-factor authentication method is blocked |
| Result detail | BadReputation |
| Error code | 399287 |
| Correlation ID / Request ID / Timestamp | それぞれの失敗試行ごとに発行される |
この「BadReputation」は直訳すると「評判が悪い」ですが、ここでは電話番号や送信経路がスパム・不正利用の疑いありと判断され、Microsoft側のバックエンドまたは通信事業者のレピュテーション判定でブロックされている状態を指します。
重要なポイントは、認証方法ポリシーでSMSが有効になっていても、ユーザー単位MFAを使っていなくても、条件付きアクセスで正しく「MFAを要求」していても、このブロックは発生しうるという点です。設定が正しくても、レピュテーション（評判）によってSMS自体が止められるケースがある、ということになります。
この問題の特徴と誤解しやすいポイント
設定を変えても解消しない
BadReputation によるブロックは、テナント管理者側の設定変更だけでは解消しないケースがほとんどです。次のような対処を行っても、問題は継続して発生します。
- SMSを一度無効化して再度有効化する
- 条件付きアクセスを一時的に緩める／無効化する
- ユーザーの電話番号を再登録する、別の番号に変える
- 別ユーザーのアカウントでMFAを試す
実際には、複数番号・複数アカウントでも同様に失敗することが多く、「設定ミスではなさそうだが、原因が見えない」という状況に陥りがちです。
SMSサインインとMFA用SMSの混同
Microsoft Entra ID には、以下のように「SMSを使う2つの用途」が存在します。
| 用途 | 概要 | 設定場所の例 |
|---|---|---|
| SMSサインイン（パスワードレス） | 電話番号＋SMSコードだけでサインイン | 認証方法ポリシー> SMSサインイン |
| SMSによるMFA | 通常のID/パスワードに加える2段階目の要素 | 認証方法ポリシー> テキストメッセージ（SMS） |
BadReputation が出ているのは後者、「MFA用のSMS」側であることが多いですが、ログを見る際にこの2つを混同すると切り分けを誤る原因になります。サインインログでは、どの方法が失敗しているかを必ず確認しましょう。
すぐに取るべき対処フロー（実務手順）
BadReputation によるエラーが確認できたら、管理者が行うべきことは大きく次の4ステップです。
- 証跡を揃える
- Microsoftへエスカレーションする
- 解除後の確認を行う
- 業務継続のための一時回避策を展開する
証跡を揃える：最低限そろえたい情報
Microsoftサポートにエスカレーションする前に、次の情報を整理しておきます。これをきちんと揃えておくことで、対応スピードが大きく変わります。
| 区分 | 必要な情報 | ポイント |
|---|---|---|
| ログ情報 | ・Error code: 399287 ・Result detail: BadReputation ・Failure reason: Multi-factor authentication method is blocked ・Correlation ID / Request ID / Timestamp（UTC） | 同じ事象が複数回ある場合は数件分を取得しておく |
| ユーザー情報 | ・影響ユーザーのUPN ・電話番号（E.164形式：+国番号……） ・国名 / 国コード | 複数ユーザーに影響している場合は、それぞれ列挙 |
| テナント情報 | ・テナントID（GUID） | Azureポータルのテナント情報画面などから取得 |
| 再現条件 | ・どのアプリで発生しているか（例：Exchange Online, SharePoint, 自社アプリなど） ・サインインフロー（ブラウザ版、スマホアプリ、Officeクライアント等） ・適用されている条件付きアクセスのポリシー名 | 「いつ・どのような操作をしたら再現するか」を1行で説明できるようにする |
特に、Timestampは必ずUTCで記録しておくことがポイントです。日本時間（JST）でメモしてしまうと、サポート側でのログ突き合わせに余計な時間がかかります。
Microsoftへのエスカレーション：依頼内容は明確に
証跡が揃ったら、Microsoftサポート（チケット／プライベートメッセージ）にエスカレーションします。依頼内容としては、次のように「BadReputation による SMS MFA ブロック解除と原因調査」を明記するとよいでしょう。
件名：SMSによるMFAが「BadReputation（エラー 399287）」でブロック解除要請
概要：特定/複数ユーザーでSMS MFAが失敗しています。
サインインログに Result detail: BadReputation が出力されており、
SMSによる多要素認証が完了できない状況です。
依頼：誤判定/地域要因の可能性も含め、バックエンドでのブロック解除と
原因調査をお願いします。
添付情報：
・テナントID：＿＿＿＿＿＿＿＿＿＿＿＿＿＿
・影響ユーザーUPN：＿＿＿＿＿＿＿＿＿＿＿＿＿＿
・電話番号（E.164形式）：＿＿＿＿＿＿＿＿＿＿＿＿＿＿
・国・国コード：＿＿＿＿＿＿＿＿＿＿＿＿＿＿
・Correlation ID / Request ID / Timestamp（UTC）：＿＿＿＿＿＿＿＿＿＿
・再現手順・影響範囲・関連ポリシー（CA/認証方法）：＿＿＿＿＿＿＿＿＿＿
BadReputation はMicrosoft側のレピュテーション判定ロジックの結果であり、顧客側ポータルから解除する手段は提供されていません。したがって、エンジニアリングチームによるバックエンドでの解除作業が不可欠になります。
解除後の確認：サインインログまでしっかり確認
Microsoft側でブロック解除が行われたら、次の流れで復旧を確認します。
- 影響ユーザーの1名でサインインを実施し、SMSによるMFAを実行
- ユーザーの画面上でMFAが成功し、アプリ利用できることを確認
- サインインログを再度確認し、当該試行でBadReputationやエラー399287が出ていないことを確認
- 複数ユーザーでスポットチェックを行い、局所的な問題が残っていないか確認
復旧後すぐに、社内向けに「発生原因・影響範囲・再発時の連絡先」を簡潔に共有しておくと、次回以降の初動が早くなります。
一時的な回避策：代替認証を最低2種類用意
BadReputation の調査・解除には、どうしても時間がかかる場合があります。その間に業務が止まらないよう、代替認証手段を最低2種類は用意しておくことが重要です。
| 代替手段 | 概要 | メリット | 注意点 |
|---|---|---|---|
| Microsoft Authenticator（プッシュ＋番号一致） | スマホアプリにプッシュ通知を送り、表示された番号を一致させて承認 | 利便性が高く、セキュリティ強度もSMSより高い | スマホアプリのインストールと初期登録が必要 |
| 音声通話によるMFA | 登録した電話番号に自動音声でコードを読み上げ | SMSが届かないときのバックアップとして有用 | 通話料や国際電話規制の影響を受けることがある |
| Temporary Access Pass（TAP） | 一時的なパスコードでサインイン・再登録を行う | ロックアウト時のレスキュー手段として強力 | 発行・管理フローの整備が必須 |
| FIDO2 / パスキー | セキュリティキーやOS/ブラウザに紐づくパスキーで認証 | フィッシング耐性が高く、SMS依存から脱却可能 | デバイス管理やユーザー教育が必要 |
運用上は、普段からSMSを主役にはせず、AuthenticatorやFIDO2を「第一候補」、SMSと音声通話を「予備」位置づけとするポリシーが望ましい構成です。
想定される原因：なぜBadReputationになるのか
BadReputation はあくまで「レピュテーションが悪化している」という結果を示すラベルであり、原因の詳細はMicrosoft内部や通信事業者側のチェックに依存します。一般論として、次のような要因が考えられます。
- 短時間に大量のSMS送信・MFA試行が行われた
- 誤った番号入力やテストで、同じ番号宛てに失敗を繰り返した
- 特定の国・地域で、不正アクセスやスパム行為が多発しているプレフィックスがある
- 新しく割り当てられた番号・回線に、過去にスパム利用歴があった
- 通信事業者側のスパム対策ルールが一時的に厳格化された
これらはあくまで一般的な想定要因であり、実際の個別ケースの判断はMicrosoft側の内部ログ・キャリアとの連携情報によります。そのため、管理者側から「この操作で解除する」といったテクニックは存在せず、サポートへのエスカレーションがどうしても必要になります。
再発時・今後のための設定確認チェックリスト
BadReputation が発生したとき、あるいは今後の再発に備えて、次のチェックリストで自社の設定を棚卸ししておくと、切り分けがスムーズになります。
| チェック項目 | 確認内容 | 備考 |
|---|---|---|
| 認証方法ポリシー | 「テキストメッセージ（SMS）」が対象ユーザー/グループに許可されているか | 除外グループや条件付き有効化をしていないかも確認 |
| 用途の混同 | SMSサインイン（パスワードレス）とMFA用SMSを混同していないか | どちらのログかを必ず区別する |
| 電話番号の形式 | 電話番号がE.164形式（例：+81xxxxxxxxxx）で登録されているか | 0始まりの国内形式が混ざっていないか要チェック |
| 条件付きアクセス | 「MFAを要求」ポリシーでブロック系ポリシーと競合していないか | ブロックポリシーの対象/除外条件も確認 |
| ユーザー単位MFA | レガシーなユーザー単位MFAが無効化されているか | ポータル上で混在していないか再確認 |
| ABテスト | 別の番号・別地域キャリアで同じ現象が再現するか | 特定キャリア／特定番号だけの問題かを切り分ける |
| ログ分析 | Result detail: BadReputation の発生件数・期間・対象ユーザーを把握 | 一時的なスパイクか、継続的かを見極める |
このチェックリストを社内の運用手順書やWikiに組み込んでおくことで、現場のヘルプデスク担当者でも一定レベルまで一次切り分けができるようになります。
モニタリングと早期検知の仕組みづくり
サインインログでの定期レビュー
手動でもよいので、週次・月次で「Result detail: BadReputation」「エラーコード399287」をキーワードにサインインログをレビューする仕組みを作ると、問題の早期検知につながります。
Azure Monitor / Log Analytics にサインインログを送っている場合は、Kustoクエリ（KQL）で次のような検索を用意しておくと便利です。
SigninLogs
| where ResultDetail == "BadReputation"
or ErrorCode == 399287
| project TimeGenerated, UserPrincipalName, AuthenticationRequirement,
AuthenticationMethodsUsed, ResultDescription, CorrelationIdこのクエリ結果をもとに、一定件数以上のBadReputationが発生した場合にアラートメールを飛ばすようにしておけば、ユーザーからの問い合わせより先に運用側で気付ける可能性が高まります。
内部運用フローの例
BadReputation を含むMFA障害に備えて、次のような社内運用フローを定めておくと、トラブル時のバタつきを大幅に減らせます。
- ヘルプデスクが「SMSコードが届かない」「MFAが完了しない」という問い合わせを受ける
- サインインログを確認し、BadReputation / 399287 の有無を確認
- 該当する場合は、あらかじめ用意したチェックリストで一次切り分け
- 必要な証跡をテンプレートどおりに収集し、運用チームからMicrosoftサポートへエスカレーション
- ユーザーには代替認証（Authenticator、音声通話、TAP など）へ切り替える手順を案内
- 復旧後、発生原因・影響範囲・再発防止策を振り返り、手順書を更新
「BadReputation のログを見つけたら、誰が、どこまでやるか」をあらかじめ決めておくことで、実際の障害発生時に迷いが少なくなります。
運用上のベストプラクティス：SMSを「主役」にしない設計へ
BadReputation は、ある意味で「SMSというチャネルの脆さ」が表面化した例とも言えます。今後の運用では、次のような方針にシフトしていくことをおすすめします。
優先度の高い代替認証を標準化する
- 第1候補：Microsoft Authenticator（プッシュ＋番号一致）
- 第2候補：FIDO2 / パスキー
- 予備：音声通話／SMS
このように、「フィッシング耐性が高く、レピュテーションブロックの影響を受けにくい認証方式」を標準とし、SMSはあくまで予備の手段とすることで、BadReputation 発生時のインパクトを最小化できます。
オンボーディング／ロック時のTAP運用
ユーザーが新規に参加するタイミングや、スマホ紛失などでMFAが使えなくなったときのために、Temporary Access Pass（TAP）を使ったオンボーディング・復旧フローを整備しておくと、SMSが使えない状況でも安定してアカウントを復旧できます。
具体的には、次のような運用が考えられます。
- ユーザー入社時にTAPを発行し、初回サインイン＋認証方法登録を完了させる
- スマホ紛失などでMFAが使えなくなった場合に、管理者がTAPを短時間有効で発行し、AuthenticatorやFIDO2の再登録を行ってもらう
このときも、TAPの発行権限や承認フローを明確にしておくことが重要です。
ユーザー周知とミニマニュアル
最後に、ユーザー向けの簡易マニュアルとして、次のような内容を1枚にまとめておくと、現場での混乱が大幅に減ります。
- 「SMSが届かない／MFAが失敗したとき」に試すこと
- Wi-Fi/モバイルネットワークの確認（Authenticator用）
- 別の認証方法（プッシュ通知、FIDO2、音声通話）への切り替え手順
- それでもダメな場合の連絡先（内線番号・メールアドレス）
- スマホ機種変更・紛失時にやるべきこと
- 社外でMFAが必要な場面（VPN、重要システム など）の一覧
「とりあえずSMS」ではなく、「困ったらここを見れば切り替え方が分かる」という状態を作ることが、BadReputation のようなトラブル発生時にもユーザー体験を損なわないための鍵です。
まとめ：BadReputationは「設定ミス」ではなく「レピュテーション問題」
- Result detail: BadReputation / エラーコード399287 は、SMSによるMFAがMicrosoft側のレピュテーション判定でブロックされている状態を示す。
- 認証方法ポリシーや条件付きアクセスが正しく設定されていても発生しうるため、管理者側だけで完全に解消することはできない。
- 実務的には、証跡（Correlation ID / Request ID / Timestamp（UTC）/ テナントID / 電話番号など）を揃え、Microsoftサポートにブロック解除と原因調査を依頼することが必須となる。
- 復旧までの間は、Authenticator、FIDO2、音声通話、TAPなどの代替認証手段で業務を継続させる体制が重要。
- 中長期的には、SMSを主役にしない認証設計・ログモニタリング・ユーザー周知によって、同様の障害が発生した際の影響を最小限に抑えられる。
「BadReputation」は一見すると原因が見えづらいエラーですが、正しくログを読み取り、迅速にMicrosoftへエスカレーションし、代替手段を標準化することで、ビジネスへのダメージを最小限に抑えることができます。本記事を、自社テナントのMFA運用の見直しや、トラブル時のリファレンスとして役立てていただければ幸いです。
コメント