Azure Portal にサインインすると MFA（多要素認証）の登録（セットアップ）画面にリダイレクトされ、Next を押しても同じ画面のまま先へ進めない――この症状は「MFA 登録が必須なのに、誤ったテナント（ディレクトリ）へ誘導されている」状態で起きやすいトラブルです。この記事では原因の切り分けと、テナント指定 URL で復旧する具体手順をまとめます。
今回のトラブルの典型パターン（現象を整理）
まず、今回の「MFA 登録画面で固まる」問題は、単に MFA を登録していないだけではなく、登録フロー自体が同じ画面をループする点が特徴です。次のような状況が重なると、Azure Portal を開けない（＝管理画面に到達できない）状態になりがちです。
| よくある症状 | 背景として多い状態 | 最初に試すべきこと |
|---|---|---|
| MFA セットアップ画面に飛ばされる | セキュリティ既定値や条件付きアクセスで「MFA 登録が必須」 | テナント（ディレクトリ）が正しいか確認 |
Next を押しても同じ画面のまま | 別テナントへ誘導／セッション情報の混在／ブラウザ制限 | テナント指定 URL で Azure Portal を開く |
画面上に domain.onmicrosoft.com が見える | 初期ドメイン（onmicrosoft.com）側のテナントに入っている可能性 | 意図したテナント名・ドメインと一致するか照合 |
なぜ「テナント違い」で MFA 登録が進まなくなるのか
Azure の「テナント」は、Microsoft Entra ID（旧 Azure Active Directory）でいうディレクトリ（組織の境界）です。1つのユーザーが複数テナントに所属（ゲスト参加含む）していると、サインイン時に意図しないテナントへ入ってしまうことがあります。
一方で、テナント側で MFA 登録が必須化されている場合、サインイン後に「セキュリティ情報を設定してください（MFA セットアップ）」というフローへ強制的に誘導されます。ここで誤ったテナントに誘導されると、次のようなズレが発生し、登録ウィザードが正常遷移できず「同じ画面に戻る」現象が起きやすくなります。
- ポリシー（必須化）をかけているテナントと、ユーザーが実際に管理したい（サブスクリプションが存在する）テナントが一致していない
- ブラウザに残っているセッション（Cookie/トークン）が、別テナントの状態を引きずっている
- 表示上は
domain.onmicrosoft.comのような初期ドメインに見えるが、想定していたテナント名・組織と一致していない
なお、Microsoft Entra テナントには初期ドメインとして xxx.onmicrosoft.com が割り当てられ、これは変更できない（追加ドメインは可能）という前提があります。
まず結論：Azure Portal を「テナント指定 URL」で開いてディレクトリを固定する
このケースで最も効果が出やすいのが、Azure Portal をテナントを明示した URLで開く方法です。Portal のログイン体験を「そのテナントに固定」できるため、誤誘導やセッションの混線を避けられます。
最短で試す手順（ユーザー側）
- ブラウザのプライベートモード（InPrivate / シークレット）で新規ウィンドウを開く（既存 Cookie を極力使わない）
- 下記のように テナントを URL に入れて Azure Portal を開く
- 表示が切り替わったら、MFA 登録（セキュリティ情報の追加）を完了させる
- 完了後、通常の
https://portal.azure.comへ戻してもログインできるか確認する
使う URL（コピペ用）
下記の <tenantID> や <domain.onmicrosoft.com> を自分の値に置き換えてください。
| 用途 | URL | 狙い |
|---|---|---|
| Azure Portal を特定テナントで開く | https://portal.azure.com/<tenantID> | 誤ったディレクトリへの誘導を抑止 |
| Azure Portal をテナント名で固定 | https://portal.azure.com/<domain.onmicrosoft.com> | 覚えやすい（ドメインが分かる場合） |
| セキュリティ情報（MFA 登録先）へ直接 | https://mysignins.microsoft.com/security-info | MFA の追加登録画面へ直行 |
| MFA セットアップ短縮リンク | https://aka.ms/mfasetup | 環境によっては上記へ誘導される |
| My Account をテナント指定で開く | https://myaccount.microsoft.com/?tenantId=<tenantID> | アカウント管理側から正しいテナントへ寄せる |
補足：mysignins.microsoft.com/security-info は、組織アカウント（Entra ID）でのセキュリティ情報（MFA 方法）を追加・管理する公式導線として案内されています。
補足：myaccount.microsoft.com は tenantId パラメータを受け取る形の URL が確認できます。
「正しいテナントか」を見分けるチェックポイント
この手のトラブルでは、技術的な操作よりも先に“自分が入るべきテナント” の特定が勝負です。特に、画面上に domain.onmicrosoft.com が表示されている場合、以下の観点で「それが意図したテナントか」を冷静に確認してください。
| 確認項目 | 具体例 | 判断のコツ |
|---|---|---|
| テナント（ディレクトリ）名 | Contoso / 自社名 など | 自社の正式名称と一致するか |
| 初期ドメイン | contoso.onmicrosoft.com | 「見覚えのない onmicrosoft.com」なら要注意 |
| カスタムドメイン | @contoso.com | メールアドレスのドメインとテナントが一致するか |
| Tenant ID（GUID） | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | チーム内で共有されている Tenant ID と一致するか |
Tenant ID（テナント ID）は、Microsoft Entra 管理センターや Azure portal のプロパティ画面などで確認できます（確認できる管理者がいる場合は、その人に教えてもらうのが最短です）。
自分でやりがちな「テナント取り違え」あるある
- 別案件で作った検証用テナントに以前ログインした履歴が残っていて、Portal がそちらを優先してしまう
- 取引先テナントにゲスト招待されており、アカウント選択やディレクトリがそちらになっている
- 同じメールアドレスに見えるが、実体は「個人 Microsoft アカウント」と「職場/学校アカウント」が混在している
それでも改善しない場合の追加切り分け（“詰まりポイント” を潰す）
テナント指定 URL を試しても画面がループする場合、次の追加要因が重なっていることがあります。ここからは「再現率が高い順」に潰していくのがおすすめです。
ブラウザ要因（Cookie/拡張機能/追跡防止）
- 拡張機能（広告ブロッカー、トラッキング防止、スクリプト制御）が登録ウィザードの動作を止めることがあります。いったん全無効化するか、別ブラウザで試してください。
- 企業ネットワークで「Microsoft の認証関連ドメイン」への通信がプロキシで書き換え・遮断されると、画面遷移がループすることがあります（社外回線やスマホテザリングで試すと原因が切り分けできます）。
- プライベートモードでも直らない場合は、対象ドメインの Cookie を削除してから試します（例：
portal.azure.com/login.microsoftonline.com/mysignins.microsoft.com）。
認証方法の不一致（組織ポリシーと登録しようとしている方法がズレている）
テナント側の設定によっては、SMS や音声通話が禁止されていたり、Authenticator アプリや FIDO2 など特定方式のみ許可されている場合があります。許可されていない方式を選ぼうとすると、UI が進めない/戻るように見えるケースがあります。
- Authenticator アプリを使う場合：端末側の時刻ずれ、通知ブロック、旧端末の残骸なども疑います。
- 会社支給端末の場合：MDM の制限でカメラや通知が制御され、QR 登録が詰まることがあります。
「サインインはできているが、ポータルだけが進まない」パターン
ポータル側の遷移がうまくいかない場合、先に mysignins.microsoft.com/security-info で MFA を完了させ、その後でポータルへ戻ると通ることがあります。
管理者が確認すべきポイント（ユーザーだけで詰むケース）
もしあなたが「管理者に頼れる状況」であれば、次の確認が最短ルートです。逆に、あなたが全体管理者（Global Administrator）で、かつ自分が入れなくなっている場合は、復旧手段を増やす（緊急用アカウント）という観点が非常に重要になります。
管理者側チェックリスト
| 観点 | 確認内容 | 意図 |
|---|---|---|
| MFA 必須化の設定 | セキュリティ既定値／条件付きアクセス／登録キャンペーン等の有無 | 「必須化」自体が原因か、別要因かを分ける |
| 認証方法ポリシー | 許可している MFA 方法（Authenticator、SMS、FIDO2 など） | ユーザーが選べる方法の不足を防ぐ |
| ユーザーの登録状態 | 既存のセキュリティ情報が壊れていないか、再登録が必要か | ループの温床（古い登録）を排除 |
| テナントの誤誘導 | ユーザーが入るべきテナントの Tenant ID / ドメインを共有 | URL 指定で正しいテナントへ誘導できるようにする |
“全体管理者が自分だけ” は避ける（詰み対策）
今回のように「ポータルに入れない」系のトラブルは、管理操作そのものができなくなるのが最大のリスクです。Microsoft は、誤って管理者が締め出されるリスクを減らすために、2つ以上の緊急用（ブレークグラス）アカウントを用意することを推奨しています。
- 緊急用アカウントは「いざという時だけ」使い、普段は使わない（監視対象にする）
- 条件付きアクセスを設計する際、緊急用アカウントを除外する設計を検討する（ロックアウト対策として推奨される）
- 緊急用アカウントの扱いは社内手順として文書化し、保管・監査を徹底する
この運用ができていると、たとえ普段使いの管理者アカウントが MFA 登録で詰まっても、緊急用アカウントでサインインして原因を取り除けます。
再発防止の実務ノウハウ（この記事の結論）
「MFA 登録画面が進まず Azure Portal に入れない」問題は、単発の UI 不具合に見えて、実際はテナント（ディレクトリ）・ポリシー・セッションの三つ巴で起きることが多いです。再発防止のために、次の3点をセットでやるのがおすすめです。
- テナント情報（Tenant ID / 初期ドメイン）をチームで共有し、迷ったらテナント指定 URL で入る運用にする
- MFA 登録は Portal からだけに頼らず、
mysignins.microsoft.com/security-infoを案内できるようにする - 緊急用（ブレークグラス）アカウントを最低2つ用意し、ロックアウト時の復旧経路を確保する
今回のケースのように、テナントを URL で明示してアクセスし直すだけで解決することも多いので、まずは「どのテナントに入っているか」を疑い、テナント指定 URL でディレクトリを固定するところから着手してください。
コメント