Azureポータルに入ろうとすると、サインイン自体はできるのに「6桁の確認コード」を要求されて先へ進めない――。Microsoft Authenticatorには8桁コードしか出ず、プッシュ通知も届かない場合、原因は個人用Microsoftアカウントではなく、Entra ID（旧Azure AD）側のMFA設定にあることが多いです。復旧手順と再発防止をまとめます。
症状の整理：なぜ「入れそうで入れない」状態になるのか
今回のケースで特徴的なのは、最初の認証（個人用Microsoftアカウントのサインイン）は通るのに、その後の追加認証で止まる点です。流れとしては次のような状態になりがちです。
- Azureポータルへアクセス
- 個人用Microsoftアカウント（例：outlook.com / hotmail.com）でパスワードレス等のサインインは成功する
- 直後に「6桁コード」入力が求められる（Authenticatorアプリ、または別のMFA手段）
- しかし、手元のAuthenticatorに表示されるのは「8桁コード」だけ／プッシュ通知が来ない
- MFAを再登録しようとしても、その操作自体が「6桁コード」を要求して詰む
この状態は、単なるパスワード間違いやブラウザ不具合というよりも「テナント（Entra ID）側の管理者アカウントがMFAでロックされている」可能性が高いです。
最重要ポイント：8桁コードと6桁コードは同じものではない
混乱しやすいのがここです。Microsoft Authenticatorで見えるコードが「8桁」でも、サインイン画面で求められている「6桁」とは用途も仕組みも違うことがあります。
| 比較項目 | 個人用Microsoftアカウント側（パスワードレス等） | Entra IDアカウント側（テナントのMFA） |
|---|---|---|
| よくある対象 | outlook.com / hotmail.com など | tenant.onmicrosoft.com / 会社ドメインのユーザーなど |
| Authenticatorの挙動 | パスワードレス承認、8桁コード表示など | 6桁のワンタイムパスコード（OTP）や承認通知など |
| 求められるコード | 8桁（用途が限定的） | 6桁（MFAの確認コードとして一般的） |
| 8桁を6桁に流用できるか | できない（別の認証方式として扱われるため） | |
| 「番号を選んで承認」通知 | 届く場合がある | 設定が消えている／端末変更／登録解除などで届かないことがある |
つまり「Authenticatorにはコードが出ているのに通らない」こと自体が異常というより、求められているMFAが“別アカウント（別テナント）向け”である可能性を強く示します。
背景：個人用MicrosoftアカウントでAzureを使っていても、裏側に“テナント”がいる
個人用MicrosoftアカウントでAzureサブスクリプションを利用している場合でも、Azureの管理（ポータル操作、RBAC、課金やリソース管理）は、どこかのタイミングでEntra ID（テナント）と結びつきます。結果として、Azureポータルでの操作中に次のようなことが起きます。
- 最初は「個人用Microsoftアカウント」として認証が通る
- その後、サブスクリプションが属するテナントのセキュリティ要件（MFAなど）で追加認証が発生する
- 追加認証の対象が、テナント内のEntra IDアカウント（例：[email protected]）になっている
この「途中から別のMFAが出てくる」挙動が、今回の詰まりポイントです。
まずは軽い切り分け：ブラウザ要因と“本当のロックアウト”を分ける
本題のテナントロックアウトに入る前に、数分でできる確認だけ先に済ませると、無駄な遠回りを減らせます。
| 確認項目 | 狙い | 結果の見立て |
|---|---|---|
| InPrivate / シークレットで試す | Cookieやアカウント混在を排除 | 改善するならブラウザ起因の可能性 |
| 別ブラウザ（Edge/Chrome）で試す | 拡張機能やキャッシュ差を排除 | 改善するならローカル環境要因の可能性 |
| サインイン画面に表示されるアカウント（メール）を注意深く見る | 求められているMFAの主体を確認 | tenant.onmicrosoft.com等ならテナント側MFAが濃厚 |
| Authenticatorに“対象アカウント”が存在するか確認 | そもそも登録が残っているか | 消えているならMFA再登録が必要 |
これらを試しても「6桁コード要求」から一切進めない、かつAuthenticator側に該当アカウントが存在しない（または通知が来ない）なら、次の章の可能性が高くなります。
結論：これは“テナント ロックアウト（tenant lockout）”に該当する
テナント ロックアウトとは、ざっくり言うとテナント内で管理権限を持つアカウントが、認証（主にMFA）で詰んでしまい、管理操作による復旧手段がテナント内に残っていない状態です。
通常のMFAトラブルなら、同じテナント内の別のグローバル管理者が次のような復旧を行えます。
- 対象ユーザーの認証方法（セキュリティ情報）をリセットする
- Authenticatorを再登録させる
- 必要に応じて一時的な認証手段を追加する
しかし今回のように「グローバル管理者が自分だけ」かつ「自分がMFAでロック」だと、テナント内部の管理操作そのものができません。これが最も厳しいパターンです。
“よくある誤解”と、やっても解決しない行動
詰まっているときほど、試行錯誤で時間を消耗しがちです。次の行動は、今回のタイプの問題では解決につながりにくい（または状況を悪化させる）代表例です。
- 個人用Microsoftアカウントのパスワードをリセットする：最初のサインインは通るため、核心はそこではないことが多いです。
- Authenticatorを入れ直す／端末移行を繰り返す：テナント側アカウントの登録情報（6桁OTPの種）が失われている場合、復元できません。
- MFA再登録ページへ進もうとする：再登録の入口で既に6桁コードを要求され、ループしがちです。
- 「どれかのコードで通るはず」と8桁を6桁として入力する：方式が違うため通りません。
ポイントは、“MFAを直すためにMFAが必要”という矛盾状態に陥っていることです。これがテナントロックアウトの典型です。
復旧ルートは2つだけ：別の管理者がいるか、いないか
この手のトラブルの復旧ルートは、実務上ほぼ二択です。
| 状況 | テナント内で復旧できる？ | 現実的な手段 |
|---|---|---|
| 別のグローバル管理者がいる | できる | 別管理者がMFA/認証方法をリセット → 対象者がAuthenticator再登録 |
| グローバル管理者が自分だけで、自分がMFAでロック | できない | Microsoftサポート対応（データ保護チームへのエスカレーション） |
今回の条件（管理者が1人、かつその本人がMFAで詰んでいる）では、テナント内部の操作では復旧できません。ここを早めに受け入れることが、最短で復旧するコツです。
復旧手順：Microsoftサポートに「テナント ロックアウト」であることを伝える
Azureポータルに入れないため通常のサポートチケット作成ができず、行き詰まりやすいのですが、このケースはサポート側での対応が前提になります。やることはシンプルで、要点は「これはtenant lockoutで、Data Protection team（データ保護チーム）の対応が必要」と正しく伝えることです。
サポートへ伝えるべき要点（最初に言うべきこと）
- Azureポータルで、個人用Microsoftアカウントのサインイン後にEntra ID側のMFA（6桁）が求められて進めない
- 該当Entra IDアカウントがAuthenticatorから消えており、通知も届かない
- MFA再登録も6桁要求でループする
- テナント内のグローバル管理者が自分だけで、リセットしてくれる管理者がいない
- したがってtenant lockout状態で、Data Protection teamへのエスカレーションが必要
本人確認に備えて準備する情報（求められやすいもの）
サポートとのやり取りでは、テナントの正当な所有者／管理者であることの確認が入ります。最低限、次をすぐ出せるようにしておくとスムーズです。
| 情報 | 例 | メモ |
|---|---|---|
| 連絡先電話番号（国番号付き） | +81… | 折り返しや追加確認に使われることがあります |
| 連絡先メールアドレス | 普段受信できるアドレス | Azureに紐づくものと別でも良い場合があります |
| 該当グローバル管理者のアカウント | [email protected] | 「6桁コード」を求められている主体 |
| 国／地域 | Japan | 契約・請求情報と整合することが重要です |
| タイムゾーン | UTC+9 | 連絡調整や本人確認の補助情報になります |
さらに、可能なら次の情報も手元にあると話が早くなることがあります（必須ではありません）。
- サブスクリプションID（分かる場合）
- テナントID（分かる場合）
- 課金に使っている支払い方法の一部情報（サポートの指示があった場合のみ）
- 過去の請求メールや領収書メール（テナント／サブスクリプションの紐づけ確認に役立つことがあります）
サポート側で進む流れ（一般的なイメージ）
サポートに状況が正しく伝わると、次のような流れになります。
- 一次窓口で事象整理（MFAが通らず管理者がロックされていること、別管理者がいないこと）
- tenant lockoutとして扱われ、データ保護チーム（Data Protection team）へエスカレーション
- データ保護チームが、テナントの所有者／管理者であることを確認
- 確認が取れ次第、MFA設定のリセット、またはアクセス復旧のための手段が案内される
ここで重要なのは、テナント内で自分が操作して直すのではなく、サポート側の手続きで“アクセスできる状態に戻す”ことです。焦って別の操作を増やすより、必要情報を揃えてサポートとのやり取りを前へ進めるのが最短です。
復旧できたら最優先でやること（再ロック防止の“初動”）
アクセスが戻った直後は、再び同じ状態に落ちるリスクが残っています。特に「管理者が1人だけ」のままだと、次に端末紛失やアプリ削除が起きた瞬間に再発します。復旧直後に優先して実施したい項目をまとめます。
| 優先度 | やること | 目的 |
|---|---|---|
| 高 | グローバル管理者をもう1つ作る（最低2名体制） | 片方がMFAで詰んでも、もう片方で復旧できる状態にする |
| 高 | 認証方法を複数登録（Authenticator以外も） | 端末故障・機種変更で詰まらないようにする |
| 中 | 管理者アカウントを“日常用”と分離 | 誤操作や端末変更の影響を減らす |
| 中 | バックアップ端末にもAuthenticatorを登録 | 単一端末依存を解消 |
| 中 | テナント所有情報・契約情報を整理 | 万一の本人確認を速くする |
再発防止のベストプラクティス：小規模テナントほど“保険”が効く
グローバル管理者は最低2つ（できれば役割分担）
テナントロックアウトの最大要因は「管理者が1人しかいない」ことです。小規模・個人利用でも、管理者アカウントは複数用意しておくのが基本です。
- メイン管理者：日常の運用で使う
- 予備管理者：緊急時だけ使う（普段はサインインしない）
予備管理者は、資格情報の保管（パスワード管理、保管場所、アクセス権）まで含めて「緊急用の運用」を決めておくと事故が減ります。
認証方法は“複線化”する（1種類だけにしない）
Authenticatorだけに依存すると、端末紛失・故障・アプリ削除で詰みます。利用可能な範囲で複数の認証方法を登録しておくのが安全です。
- Microsoft Authenticator（プッシュ承認／OTP）
- SMS／音声通話（利用可能なら）
- 予備メール（設定可能な範囲で）
- 可能ならFIDO2セキュリティキー（管理者アカウントの“最後の鍵”として強い）
特に管理者アカウントは、セキュリティ強度と可用性（ログインできること）の両立が必要です。「強すぎて入れない」は運用上のリスクになります。
Authenticatorが“いつの間にか消えた”に備える視点
Authenticatorからアカウントが消える原因は、必ずしも「誰かに消された」だけではありません。例えば次のような運用イベントでも起こり得ます。
- 機種変更時にアプリ移行が不完全だった
- 端末の初期化／修理でアプリが再インストールになった
- 仕事用プロファイル（MDM）削除と一緒に消えた
- 誤ってアカウントを削除した（気づきにくい）
だからこそ、単一端末・単一アプリに依存しない設計が効いてきます。バックアップ端末の用意や、別経路の認証方法登録が“保険”になります。
「個人用Microsoftアカウント」と「Entra IDアカウント」は別物として管理する
今回のようなトラブルは、両者を同一視していると判断が遅れます。次の点を押さえておくと、切り分けが早くなります。
- 個人用Microsoftアカウント：パスワードレスや回復情報は「個人向けの設定」で完結する
- Entra IDアカウント：テナント（組織ディレクトリ）側のMFA・セキュリティ既定値・ポリシーの影響を受ける
個人用アカウント側が正常でも、テナント側のMFAが壊れるとAzureポータルだけ入れない、という状況が起きます。
FAQ：同じ状況で詰まりやすい質問
6桁コードがどうしても出せません。8桁を使えませんか？
使えません。8桁と6桁は同じ「コード」に見えても、認証方式が別です。サインイン画面が求めている方式（多くはEntra IDのMFA）に合致しないと通りません。
「別の方法でサインイン」を押しても何も選べません
テナント側に登録されている認証方法がAuthenticatorのみ、かつそのAuthenticator登録が失われている場合に起きやすいです。別管理者がいないなら、サポート対応が必要になります。
サブスクリプションやリソースは消えますか？
この問題自体でリソースが消えるわけではありません。ただし長期間アクセスできないと、更新・請求・運用に支障が出ます。復旧プロセスを早めに開始するのが重要です。
まとめ：管理者が1人のMFAロックは“自力復旧できない設計”になりやすい
Azureポータルで「6桁コード」を求められ、Authenticatorには「8桁」しか出ない／通知も来ない場合、個人用Microsoftアカウントではなく、テナント（Entra ID）側のMFAが原因であることがあります。特に、グローバル管理者が自分だけで、その自分がMFAでロックされている状態はテナントロックアウトに該当し、テナント内の操作では復旧できません。
復旧の現実解は、Microsoftサポートへ「tenant lockoutであり、Data Protection teamへのエスカレーションが必要」と伝え、本人確認のうえでアクセス回復を進めてもらうことです。復旧後は、管理者アカウントを複数用意し、認証方法を複線化して、同じ行き詰まりを確実に防ぎましょう。
コメント