Entra ID（旧Azure AD）でMFAを有効化しようとしても、「完了したか分からない」「security-infoに入れない」「個人Microsoftアカウント＋GitHub連携でディレクトリが迷子」などで詰まりがちです。原因の多くは“どのアカウント／どのテナントで登録しているか”のズレ。確実に登録を終える手順と確認方法をまとめます。
今回の症状が起きる理由
Entra ID のMFAは、単に「スマホに番号を登録したら終わり」ではありません。さらに、Azure Portal や mysignins（security-info）周りはログインセッション（Cookie）とテナント（ディレクトリ）の影響を強く受けます。個人Microsoftアカウント（MSA）をAzureに紐付けている場合や、同じメールアドレスで「個人アカウント」と「組織アカウント」が併存している場合は、入口で別物として扱われて迷子になりやすいです。
| よくある症状 | ありがちな原因 | 最初に見るポイント | 効く対処 |
|---|---|---|---|
| MFAを設定したのに「未対応」っぽい案内が消えない | 別テナントで登録している／別アカウントで登録している／MFAの仕組みが複数混在 | Azure Portalのディレクトリ、テナントID、サインイン時のアカウント種別 | テナントID指定で security-info へ誘導し直す／MFA方式を整理 |
| security-info（登録画面）に入れない・遷移ループする | Cookieで別ディレクトリへ飛ぶ／個人アカウント側のセッションが優先される | 同一ブラウザで複数アカウントにログインしていないか | シークレットウィンドウ＋テナントID指定URLで入り直す |
| SMSは登録できたが Authenticator のQRが出ない | 認証方法ポリシーで Authenticator が無効／対象ユーザーに割り当たっていない | Entra IDの Authentication methods で Microsoft Authenticator が許可されているか | Authenticator を有効化し対象を割り当てる |
| APIが止まるのが不安 | ユーザー資格情報でAPIを動かしている（対話サインイン前提） | APIの認証方式（サービスプリンシパル／マネージドID／ユーザーログイン） | サービスプリンシパル or マネージドIDへ切替、もしくは対話不要の方式へ移行 |
| 特定アカウントだけ登録できない | GitHub連携などでサインイン導線が複雑化／権限・ユーザー種別の差 | 別の管理者アカウントで同じ操作ができるか | 新規グローバル管理者で切り分け→問題アカウントに戻って対処 |
最初に整理したい：MFAの「有効化」は1種類ではない
「テナントでMFAを有効化したい」というとき、実際には次のような仕組みが絡みます。ここが混ざると、登録状況の判断が一気に難しくなります。
| 仕組み | ざっくり何をするもの？ | どこで確認する？ | つまずきやすい点 |
|---|---|---|---|
| セキュリティ既定値（Security defaults） | 基本のセキュリティをテナントに一括適用（MFA相当を要求） | Entra IDのプロパティ／セキュリティ設定 | 条件付きアクセス等との併用で挙動が読みづらくなる |
| 条件付きアクセス（Conditional Access） | 条件（アプリ、場所、リスク等）に応じてMFA要求を制御 | Entra 管理センターの条件付きアクセス | 対象ユーザー/除外、例外設定で「自分だけ通らない」が起きやすい |
| ユーザー単位MFA（Per-user MFA） | ユーザーごとにMFAを強制するレガシー方式 | 旧来のユーザー単位MFA画面 | モダン設定と二重管理になり、検証オプションが干渉しやすい |
| 認証方法ポリシー（Authentication methods policy） | Authenticator/SMS/FIDO2等「使える方法」をテナントで制御 | Entra 管理センターの Authentication methods | Authenticatorが無効だと、登録画面にQRが出ない |
この記事の中心は、「登録画面に入れない」→「正しいテナントへ誘導して登録を完了」→「Authenticatorを許可」→「レガシー干渉を整理」という順で、最短で詰まりを解く方法です。
結論：主因は「どのアカウント／どのテナント（ディレクトリ）で登録しているか」のズレ
同じブラウザで Azure Portal を開き、同じメールアドレスでログインしているように見えても、裏では次のような“別人扱い”が起きます。
- 同じメールアドレスでも「個人Microsoftアカウント（MSA）」と「組織アカウント（Entra ID）」が並存している
- Azure Portal 上でディレクトリ（テナント）を切り替えたつもりでも、security-info は別テナント側のセッションで開いてしまう
- GitHub連携などで、サインイン画面の選択肢が増え、意図せず別の経路（個人側）へ戻る
- 自分はテナントに対してGuest（ゲスト）として参加しており、登録すべき場所が想定と違う
まずやるべき：テナントIDを確定し、入口を固定する
登録画面に入れない問題は、入口を「正しいテナント」に固定すると一気に解決することが多いです。特に個人アカウント＋GitHub連携の環境では、テナントIDを明示したURLが強力です。
テナントIDの確認方法
- Azure Portal：Microsoft Entra ID → 概要 → テナントID
- Entra 管理センター：Microsoft Entra ID の概要（Overview）に表示
テナントID指定で「正しいディレクトリ」に誘導する例
以下は考え方の例です。目的は「同じアカウントに見えても、必ずこのテナントとして扱う」状態を作ることです。
- myaccount をテナント指定で開く：
https://myaccount.microsoft.com/?tenant=<tenant_ID> - security-info（登録画面）へ進む：
https://mysignins.microsoft.com/security-info（または組織向けのショートリンク）
ポイントは、最初の1回をテナント指定で踏むことです。これで以降の遷移が「同じディレクトリ」で揃いやすくなります。
URLを使い分ける早見表
| 用途 | URL例 | 期待する挙動 | うまくいかないときのサイン |
|---|---|---|---|
| テナント固定の入口 | https://myaccount.microsoft.com/?tenant=<tenant_ID> | そのテナントのアカウント情報として表示される | 個人アカウント管理（live.com）に飛ぶ／別組織の表示になる |
| security-info（MFA登録） | https://mysignins.microsoft.com/security-info | 認証方法（SMS/Authenticator等）の追加・削除ができる | ログインループ／権限エラー／画面が真っ白 |
| サインイン状況の確認 | https://mysignins.microsoft.com/ | 最近のサインイン履歴を見られる | 想定外のアカウントが表示される |
「security-info に入れない」問題の実戦的な直し方
セッションが混線している場合、設定自体が正しくても画面に到達できません。まずは“環境”のノイズを落としてから、テナント固定で入り直します。
手順：セッション混線をリセットしてから入る
- ブラウザをシークレット（InPrivate）で開く（まずこれが最短です）
- シークレット内で、いきなり security-info を開かずにテナントID指定の myaccountを踏む
https://myaccount.microsoft.com/?tenant=<tenant_ID> - 同じタブで security-info を開く
https://mysignins.microsoft.com/security-info - アカウント選択が出たら、“いつも使う方”を何となく選ばない
「職場または学校」寄りの表示（組織アカウント）になっているかを意識する
それでもループする場合の追加策
- Edge/Chrome の“別プロファイル”を作り、Azure専用として使う（個人利用と分離できる）
- 同じブラウザで複数のMicrosoftアカウントに同時ログインしている場合はいったん全てサインアウトしてからやり直す
- 拡張機能（広告ブロッカー/追跡防止）でリダイレクトが壊れることがあるため、シークレットで無効化して試す
- 会社ネットワークのプロキシ/VPNが絡む場合、別回線（テザリング等）でテストして切り分ける
「完了しているのか分からない」を“確認できる状態”にする
MFAの「完了」は、感覚ではなく証跡で判断すると迷いが消えます。ユーザー側の見え方と、管理者側の見え方の両方を用意しておくのがコツです。
ユーザー自身が確認できるポイント
- security-info に登録済みのサインイン方法（SMS、Authenticator等）が表示されている
- 次回サインインでMFA（追加認証）が要求され、成功できる
- Authenticator を追加したい場合は、security-info の「サインイン方法の追加」から選べる
管理者が確認できるポイント（おすすめ）
「本当にMFAが満たされたか」は、サインインログで確認できます。ポリシーが効いているか／別テナントで満たしてしまっていないかの判断にも使えます。
- Entra 管理センターでサインインログを開く
- 対象ユーザーのログインを選び、Authentication details（認証の詳細）や条件付きアクセスの評価結果を確認する
- 「MFAが要求された／満たされた」ことが分かる記録が残っているかを見る
| 確認したいこと | 見る場所 | 確認のコツ |
|---|---|---|
| どのテナントでサインインしているか | Azure Portal / Entra 管理センターのディレクトリ表示 | 作業のたびにディレクトリ名とテナントIDを見て“固定”する |
| MFAが要求されたか・満たしたか | サインインログ（認証の詳細、CA結果） | 対象アプリ（Azure Portal等）でフィルターすると見つけやすい |
| 登録済みの認証方法 | security-info | SMSしか無い/Authenticatorが無いなら「許可設定」側を疑う |
SMSはできたのに Authenticator のQRが出ないとき
このパターンは非常に多く、原因はシンプルです。テナント側で Microsoft Authenticator が許可されていない、または対象ユーザー（または対象グループ）に割り当たっていないことがほとんどです。
テナント側：Authenticator を許可する（認証方法ポリシー）
- Entra 管理センターで Authentication methods（認証方法） を開く
- Microsoft Authenticator を有効化する
- 適用対象（All users / 特定グループ）を設定する
設定後、security-info 側で「サインイン方法の追加」→「Authenticator アプリ」が選べるようになり、QRコードが表示されることが期待できます。
登録手順：SMS登録済みでも Authenticator は追加できる
- security-info（
https://mysignins.microsoft.com/security-info）を開く - サインイン方法の追加を選ぶ
- Authenticator アプリを選択
- 画面の指示に従い、スマホの Microsoft Authenticator で QR を読み取る
- テスト通知（承認）まで完了させる
「SMSは登録できたのにQRが出ない」という場合、端末やアプリの問題よりも先に、テナント側の許可設定を疑うのが近道です。
レガシー（ユーザー単位MFA）とモダン設定の“干渉”を片付ける
スムーズに見えても、裏でレガシー設定が残っていると、登録画面の表示・要求される方法・検証オプションが噛み合わず、結果として「できたはずなのに終わっていない」状態に見えます。ここは整理して一貫性を作るのがポイントです。
整理の考え方
- 「ユーザー単位MFA」でユーザーを強制しているのか、条件付きアクセスで強制しているのか、まず一本化する
- 認証方法ポリシーで「使わせたい方法（Authenticator等）」を許可し、登録画面と一致させる
- 古い検証オプションが残っている場合、不要なものは外して移行の整合性を取る
判断がラクになる“見る場所”の整理
| 見たいもの | 見る場所 | 見てほしいポイント |
|---|---|---|
| テナントとして何を許可しているか（Authenticator等） | Authentication methods（認証方法） | Microsoft Authenticator が有効か／対象ユーザーに割り当たっているか |
| いつ・誰にMFAを要求するか | 条件付きアクセス | 対象ユーザー/除外、対象アプリ（Azure Portal等）、例外条件 |
| ユーザー単位MFAが残っていないか | ユーザー単位MFA（旧画面） | Enabled/Enforced になっていないか、不要な検証オプションが残っていないか |
| 実際にMFAが満たされたか | サインインログ | 認証の詳細・CA結果で「MFAが要求され満たされた」ことを確認 |
「どれが効いているのか分からない」状態を放置すると、登録してもまた別経路で要求され、永遠に終わらない感覚になります。許可（方法）と要求（ポリシー）と証跡（ログ）の3点を揃えるのが、再発防止としても一番効きます。
切り分けが最速：別のグローバル管理者を作って試す
特定アカウント（個人Microsoftアカウント＋GitHub連携など）だけが迷子になる場合、テナントの設定が悪いのか／そのアカウント固有の問題なのかを分けると、解決までが短くなります。
おすすめの切り分け手順
- 新しい管理者アカウント（グローバル管理者権限）を用意する
- そのアカウントで security-info に入り、Authenticator を含めて登録できるか試す
- 登録できるなら、テナントの大枠は正常で、問題は「元のアカウントの導線／ディレクトリ／ユーザー種別」側に寄っていると判断できる
この方法の利点は、「テナント設定を大きく弄る前に」原因の当たりを付けられることです。特に期限が迫っている状況では、まずこの切り分けが効きます。
個人アカウント＋GitHub連携で迷子になりやすいポイント
GitHubとMicrosoftアカウントを連携していると、サインイン画面での選択肢が増えたり、以前の選択（「このアカウントを既定にする」等）が効いていたりして、意図せず別の経路に戻りがちです。ここでは、迷子を減らす実務的な工夫をまとめます。
- Azure用のブラウザプロファイルを分ける（個人用途とCookieを分離）
- アカウント選択画面が出たら、メールアドレスだけでなく、表示される組織名・アイコンも確認する
- 「前回のアカウントで自動的にサインイン」されるなら、いったん明示的にサインアウトしてから入り直す
- テナント固定URL（
?tenant=）をブックマークし、毎回そこから入る
根本的には、“入口を固定して、同じテナントで登録させる”ことが最重要です。導線の混乱を気合で突破しようとすると、別テナントで登録→未完了に見える、を繰り返します。
APIが止まるか不安なときの判断基準
「Azure Portal の裏で API が動いている」「MFAを有効化すると止まるのでは？」という不安は自然です。結論としては、APIが“ユーザーの対話サインイン”に依存していない限り、ユーザーのMFA有効化がAPI停止に直結することは通常ありません。
ただし、古い方式で「ユーザー名とパスワードで自動ログインしてトークンを取る」ような実装だと、MFA強制で詰みます。まずは方式を見極めましょう。
| API/自動化の認証方式 | 例 | MFA有効化の影響 | 推奨アクション |
|---|---|---|---|
| サービスプリンシパル（アプリ登録） | client secret / 証明書でアプリがトークン取得 | 低い（ユーザーの対話が不要） | 期限管理（シークレット/証明書）を徹底し運用継続 |
| マネージドID | Azure上のリソースがIDで認証 | 低い（ユーザー不要） | 可能なら最優先で採用（秘密情報の管理が軽い） |
| CI/CD（例：GitHub Actions）でのOIDC連携 | Federated credentials（Workload identity federation） | 低い（ユーザー不要） | シークレット依存を減らせるため移行候補として強い |
| ユーザー資格情報での自動ログイン | スクリプトにユーザーID/パスワード、古いフロー | 高い（MFA要求で止まる可能性） | サービスプリンシパル/マネージドIDへ移行を計画 |
| デバイスコード等の対話を前提 | 人が操作して承認する運用 | 中（運用次第で影響） | 運用手順の見直し、対話不要の方式へ置き換え検討 |
「うちのAPIはどれ？」を短時間で把握する方法
- API実行環境にアプリ登録のクライアントIDやテナントIDが設定されていれば、サービスプリンシパル系の可能性が高い
- 実装や設定にユーザー名・パスワードが残っていれば赤信号（MFA強制で止まりやすい）
- サインインログで、API実行に紐づくサインインがユーザー名で出ているか、アプリケーションで出ているかを見る
不安が大きい場合は、MFAを強制する前に「サインインログで誰がどの方式でサインインしているか」を棚卸しし、止めたくないものがユーザー依存になっていないかを先に確認すると安全です。
最短で解決する“王道ルート”
ここまでの内容を、実務でそのまま使える順番に並べます。迷ったらこの順で進めるのが最短です。
- テナントIDを確認し、作業中のディレクトリを固定する
- シークレットウィンドウで、
https://myaccount.microsoft.com/?tenant=<tenant_ID>から入ってセッションを整える https://mysignins.microsoft.com/security-infoに進み、登録状況（SMS/Authenticator）を確認する- AuthenticatorのQRが出ないなら、Authentication methods で Microsoft Authenticator を許可し、対象ユーザー/グループを割り当てる
- ユーザー単位MFAが残っていそうなら、レガシー設定を整理して二重管理をやめる
- 「このアカウントだけ無理」なら、別のグローバル管理者で切り分けして問題の所在を確定する
- API停止が不安なら、APIの認証方式を棚卸しし、ユーザー依存ならサービスプリンシパル/マネージドIDへ寄せる
よくある落とし穴
- SMS登録＝MFA完了とは限らない（組織がAuthenticator必須にしていることがある）
- 登録できたのに未完了に見えるときは、別テナントで登録している可能性が高い
- QRが出ないときに端末のせいにしがちだが、多くはテナント側の許可（ポリシー）の問題
- APIが止まるかは「MFAを有効化したか」より、APIがユーザー対話に依存しているかで決まる
「できてるのか分からない」「画面に入れない」は、設定の難しさというより導線が分岐しやすいことが原因になりがちです。テナント固定→登録画面→許可設定→ログ確認、の順で整えると、同じ問題が再発しにくい形で片付きます。
コメント