Azure AD（現 Microsoft Entra ID）の多要素認証で、SMSコードが届かず「BadReputation」と表示されてしまうと、多くの管理者は「設定を間違えたのか？」「ユーザー側の問題か？」と戸惑います。本記事では、この謎のエラーの正体と、具体的なブロック解除の手順、再発防止のための運用ポイントまでを詳しく解説します。
SMSによる多要素認証が「BadReputation」で失敗する現象とは
まずは、実際に現場でよく発生している現象を整理します。Azure AD / Microsoft Entra ID のテナント内ユーザーが、サインイン時に SMS を使って多要素認証（MFA）を行おうとすると、次のようなログが出力されて認証に失敗します。
| ログの種類 | 項目 | 表示内容の例 |
|---|---|---|
| Authentication Methods ログ | Method | Text message (SMS) |
| Authentication Methods ログ | Failure reason | Multi-factor authentication method is blocked |
| Authentication Methods ログ | Result detail | BadReputation |
同時に、以下のような条件が揃っていることが多いです。
- Authentication Methods ポリシーでは SMS が有効になっている
- 従来の per-user MFA は無効にしている
- Conditional Access ポリシーでは「MFA 必須」を要求している
つまり「設定上は SMS を使えるはずなのに、なぜかバックエンド側でブロックされている」という状態です。このときにキーとなるのが BadReputation という見慣れないフラグです。
「BadReputation」とは何か ― Microsoft の自動保護フラグの正体
BadReputation は、Microsoft がクラウド側で実装している自動保護システムによって付与される内部的なフラグです。端的に言えば、 「この電話番号、またはこのテナントからの SMS ベースの認証トラフィックは、不審、あるいは悪用されている可能性が高い」 と判断された状態です。
このフラグが付与されると、対象の電話番号（あるいは場合によってはそのテナント全体）からの SMS 認証要求がブロックされ、ユーザーは SMS コードを受け取れなくなります。管理者側からはポータル上で設定を見直しても原因が分からず、「ポリシーは合っているのに失敗する」という見え方になるのが厄介なポイントです。
BadReputation が付与される主なトリガー
Microsoft は BadReputation の内部ロジックを公開していませんが、実際の事例から、次のような要素がトリガーになりやすいと考えられます。
| トリガー候補 | 概要 | 想定されるシナリオ |
|---|---|---|
| 短時間の大量 SMS リクエスト | 特定の番号やテナントから短時間で異常な数の SMS 認証要求が発生 | テスト環境で同じ番号を使って何度も登録・検証を繰り返した |
| 特定の国・地域からの集中トラフィック | スパム SMS が多い地域や、過去に悪用の多かったエリアから大量の要求 | 海外拠点からの一斉展開、あるいは VPN・プロキシ経由での大量アクセス |
| 過去に悪用履歴のある電話番号 | 第三者により不正利用されたことがある電話番号やレンタル番号 | 短期レンタルのSMS受信サービスや、一時的な電話番号を使って検証していた |
| ボット的な挙動 | 一定パターンで繰り返される登録・削除・再登録などの操作 | 自動化ツールやスクリプトでユーザー登録とMFA設定を一括実行 |
ポイントは、管理者やユーザーが「悪意」を持っていなくても、自動保護のロジックから見ると「怪しい挙動」に見えてしまう場合があるということです。内部的には、スパム SMS やアカウント乗っ取りを防ぐための仕組みであり、正しく運用している企業にも副作用として影響が出る可能性があります。
まず確認したい設定とログのチェックポイント
BadReputation が疑われる場合でも、基本的な設定ミスがないかを先に確認しておくことは重要です。サポートに依頼する前に、次のポイントを押さえておきましょう。
1. Authentication Methods ポリシー
- Azure ポータルで「Azure Active Directory / Microsoft Entra ID」 → 「Security」 → 「Authentication methods」へ移動
- 「Text message（SMS）」が有効になっているか確認
- 対象ユーザーやグループがスコープに含まれているか確認
2. Per-user MFA が無効になっているか
- 従来の per-user MFA と新しい Authentication Methods ポリシーが混在していると、想定外の挙動につながることがあります。
- 可能であれば per-user MFA は無効化し、Authentication Methods ポリシー＋条件付きアクセスに統一するのが望ましいです。
3. Conditional Access（条件付きアクセス）の設定
- サインイン時に「多要素認証を要求する」ポリシーが適切に構成されているか確認
- 対象アプリ、ユーザー、場所、デバイスプラットフォームなどの条件が過剰になっていないか見直し
4. サインインログと Authentication Methods ログの突き合わせ
サインインログと Authentication Methods ログを同じタイムスタンプで照合すると、問題の切り分けがしやすくなります。
| ログ種類 | 確認するポイント | BadReputation のときの特徴 |
|---|---|---|
| サインインログ | 「ステータス」「条件付きアクセス」「詳細」 | CA 要件は満たしているが、MFA フェーズで失敗する |
| Authentication Methods ログ | 「Result」「Result detail」「Failure reason」 | Result: failure / Result detail: BadReputation / Failure reason: Multi-factor authentication method is blocked |
ここまで確認しても、設定上問題がなく BadReputation が表示されているのであれば、テナント管理者側の操作だけで解除することはできません。次のステップとして、Microsoft サポートへの問い合わせが必須になります。
BadReputation によるブロックを解除する手順（Microsoft サポート依頼）
BadReputation は Microsoft 側のバックエンド保護システムが付与するフラグであり、管理者がポータル画面からオン／オフを切り替えることはできません。解除には、Microsoft サポート経由での対応が必須です。
STEP 1: Azure ポータルからサポートチケットを起票する
- Azure ポータルに全体管理者（またはサポート依頼権限を持つアカウント）でサインインします。
- 左下の「ヘルプ + サポート」メニューを開き、「新しいサポートリクエスト」を選択します。
- 問題の種類として「技術的」「Identity」など、実際の画面に即したカテゴリを選択し、製品で「Azure Active Directory / Microsoft Entra ID」またはそれに相当するものを指定します。
- 概要欄に「SMS MFA が BadReputation エラーでブロックされている」ことを明記します。
STEP 2: サポートに伝えるべき情報を整理する
あらかじめ必要な情報を整理しておくと、調査がスムーズに進みます。次の表を参考に、チケットの説明欄に記載しておきましょう。
| 項目 | 説明 | 記載例 |
|---|---|---|
| テナント ID | 問題が発生している Azure AD / Entra ID テナントの ID | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
| 影響を受けている電話番号 | 国コードを含めた完全な番号 | +81-90-1234-5678 |
| 国 / 地域 | 電話番号が属する国、利用している拠点の所在地 | 日本（東京）、または海外拠点の国名 |
| 発生日時 | エラーが発生し始めた日時と、代表的な再現時刻 | 2025/04/01 10:15 頃から継続的に発生 |
| エラーログの情報 | Authentication Methods ログ、サインインログのスクリーンショットや詳細 | Result detail: BadReputation, Failure reason: Multi-factor authentication method is blocked |
| 再現手順 | ユーザーがどのような操作をするとエラーになるか | ブラウザからのサインイン → SMS コード送信 → コードが届かずエラー |
| 影響範囲 | 特定のユーザー／番号のみか、複数ユーザーか | +81-90-xxxx-xxxx の番号を使用しているユーザーのみ |
説明欄には「SMS MFA が BadReputation によりブロックされているため、対象番号／テナントの BadReputation フラグの確認と解除をお願いしたい」旨を明確に記載するとよいでしょう。
STEP 3: Microsoft 側で BadReputation フラグを解除してもらう
サポート エンジニアがログやバックエンドの情報を確認し、問題が BadReputation であると判断した場合、必要に応じてエンジニアリング チームにエスカレーションされます。そこで対象の電話番号またはテナントに付与されている BadReputation フラグを解除する作業が行われます。
この作業は Microsoft 側の内部システム上でのみ実施可能であり、テナント管理者が GUI や PowerShell から操作する手段は提供されていません。解除が完了すると、サポートから「再度テストしてください」といった案内が届くことが多いです。
STEP 4: 解除後に SMS MFA が利用可能になる
BadReputation フラグが解除されると、対象の電話番号に対して SMS が再び送信されるようになり、ユーザーは通常どおり SMS を用いた多要素認証を完了できるようになります。ただし、解除が完了した直後は、キャッシュやシステム反映のタイミングにより数分程度タイムラグがある場合もありますので、少し時間を置いてから再度テストするのがおすすめです。
解除後に行う確認手順と正常動作の見分け方
BadReputation の解除連絡を受けたら、次の手順で動作確認を行いましょう。
1. テスト用ユーザーで実際にサインインしてみる
- 対象の電話番号を使用しているユーザーでサインインを試行します。
- SMS コードが問題なく届くか確認します。
- コードを入力し、サインインが成功することを確かめます。
2. Authentication Methods ログで「Success」を確認
- Azure ポータルで Authentication Methods 活動ログを開きます。
- 対象ユーザー、対象電話番号でフィルタリングします。
- Result が Success になっているか確認します。
BadReputation が残っている状態では、Result は failure のままですが、解除後であれば同じユーザー・同じ電話番号でも Success に変わっているはずです。これにより、設定ではなく BadReputation に起因する問題だったことを客観的に示すことができます。
3. 他のユーザーにも影響がないかスポットチェック
特定の番号だけのブロックだったのか、テナント全体に影響があったのかを把握するため、複数のユーザーで簡易テストを行っておくと安心です。とくに、同じ国コード、同じキャリアの番号を複数利用している場合には、代表的なパターンをいくつかテストしておくことをおすすめします。
再発防止のための設計と運用のベストプラクティス
BadReputation は、一度解除されればそれで終わりというものではなく、運用次第では再び付与される可能性があります。ここでは、再発防止のために意識したいポイントを整理します。
1. 電話番号の運用を「安定化」させる
- 検証用途であっても、短期間に同じ番号を登録・削除・再登録する操作は避ける。
- できるだけ実在ユーザーの実番号を使い、「共通テスト番号」をむやみに共有しない。
- 短期レンタルの SMS 番号サービスなど、「誰でも使える番号」の利用は避ける。
BadReputation のトリガーになりやすいのは、「ボット的」「テスト的」に見える挙動です。番号に対する操作回数を減らし、ユーザー単位で安定運用することが防止策になります。
2. SMS を唯一の MFA 手段にしない
SMS は便利な一方で、今回のようにキャリアや地域、クラウド側の保護機構の影響を受けやすい手段でもあります。そのため、SMS だけに依存しない MFA 設計が重要です。
| MFA 手段 | 特徴 | 利用を推奨するシナリオ |
|---|---|---|
| Microsoft Authenticator アプリ | プッシュ通知やワンタイムパスコードを使用。セキュリティレベルが高い。 | スマートフォンアプリの利用が許容される社員・職員全般 |
| FIDO2 セキュリティキー | フィッシング耐性が高いハードウェアキー。パスワードレスにも対応。 | 特に権限の高い管理者アカウントや重要システムの利用者 |
| 音声通話による認証 | 電話回線を使ってワンタイムコードを音声で案内。 | SMS が届きにくい環境や、SMS が制限されている端末 |
| OATH ハードウェアトークン | 物理トークンでワンタイムコードを生成。オフライン環境でも利用可能。 | スマホを持ち込めない現場、工場、厳格なセキュリティゾーン |
「Authenticator アプリ＋SMS」「FIDO2＋SMS」のように、少なくとも二種類以上の MFA 手段を用意し、どれか一つが使えなくなっても業務が止まらない設計を心がけましょう。
3. 大量導入・国際展開時は事前にサポートへ相談する
数千ユーザー単位の一括展開や、複数国・複数地域から同時に SMS MFA を使い始めるケースでは、短期間に多くの SMS リクエストが一気に増えるため、BadReputation のリスクが上がる可能性があります。
- 展開計画（いつ、どのくらいのユーザーが、どの地域から利用開始するか）を整理する。
- 事前に Microsoft サポートに相談し、「この期間に SMS トラフィックが増加する」旨を伝えておく。
- 可能であれば、段階的なロールアウト（部門単位・拠点単位）を実施する。
これにより、予期せぬ自動ブロックのリスクを下げつつ、問題が発生した場合も迅速に原因を特定しやすくなります。
4. ログ監視とアラートで「異常の早期検知」を行う
BadReputation によるブロックは、ある日突然、ユーザーからの問い合わせで気づくこともあります。次のような監視・アラートを組み込むことで、早期検知が可能になります。
- Authentication Methods ログで、Result: failure / Result detail: BadReputation を検出するクエリを用意する。
- 同一電話番号・同一ユーザーに対するエラーの急増をアラート条件にする。
- 監査ログと組み合わせて、電話番号の登録・削除操作の急増も監視する。
Azure Monitor や SIEM 製品と連携して、BadReputation らしきパターンを検知したら管理者に通知する仕組みを作っておくと、ユーザー影響を最小限に抑えられます。
よくある質問（FAQ）
Q. 管理者がポータルや PowerShell から BadReputation を解除できますか？
A. 現時点ではできません。BadReputation は Microsoft 側の自動保護システムで管理されるフラグであり、テナント管理者が直接操作するインターフェイスは提供されていません。解除には Microsoft サポートへの依頼が必須です。
Q. BadReputation が付いているということは、アカウントが侵害されたという意味ですか？
A. そうとは限りません。BadReputation は「悪用の可能性が高いトラフィックパターン」に対する自動防御であり、実際に侵害が発生したことを示すものではありません。ただし、大量のサインイン試行や不自然なアクセスパターンが背景にある可能性はあるため、念のためサインインログやセキュリティアラートを確認することをおすすめします。
Q. すべての SMS 認証が止まるのですか？ それとも特定の番号だけですか？
A. 実際の影響範囲はケースバイケースです。特定の電話番号だけがブロックされるケースもあれば、同一テナント内の複数番号に影響が出るケースも考えられます。そのため、問題が発生したら「他のユーザー・他の番号」でも簡易テストを行い、影響範囲を把握することが重要です。
Q. BadReputation が付いていても、Authenticator アプリや FIDO2 キーの MFA には影響がありますか？
A. 一般的には、BadReputation の影響を受けるのは SMS ベースの認証のみです。Authenticator アプリ、FIDO2 セキュリティキー、音声通話などは通常どおり利用できる場合が多いため、代替手段を事前に用意しておくことが非常に重要です。業務が止まらないよう、複数の MFA 手段を有効にしておきましょう。
Q. 再発を完全に防ぐことはできますか？
A. BadReputation のロジックは公開されていないため、「完全に防げる」と言い切ることはできません。ただし、本記事で紹介したように、
- 電話番号の登録・削除を乱発しない
- テスト用途の番号と本番運用の番号を分ける
- SMS に依存しない MFA 設計にする
- 大量展開時には事前にサポートと連携する
といった運用を行うことで、リスクを大きく下げることは十分に可能です。
まとめ：BadReputation による SMS MFA ブロックへの向き合い方
SMS による多要素認証は、ユーザーにとって分かりやすく導入しやすい一方で、キャリアや地域の制約、そして今回のような Microsoft 側の自動保護（BadReputation）など、さまざまな要因に影響を受けやすい方式でもあります。
本記事で解説したように、
- BadReputation は「不審または悪用の可能性が高い」と判断された際に付与される自動保護フラグであること
- テナント管理者側の操作だけでは解除できず、Microsoft サポートへの依頼が必須であること
- 解除後はログで「Success」に変わることを確認し、再発防止のために運用ルールと MFA 設計を見直すこと
を理解しておくことで、いざ「BadReputation」が発生した際にも落ち着いて対応できるようになります。
特に、SMS を唯一の MFA 手段にしないことは、セキュリティと業務継続性の両面で重要なポイントです。Authenticator アプリや FIDO2 キーなどの代替手段を組み合わせ、ログ監視や事前相談も活用しながら、Azure AD / Microsoft Entra ID 環境の認証基盤をより堅牢で安定したものにしていきましょう。
コメント