Azure へサインインすると「Microsoft Authenticator の6桁コード」を求められるのに、手元の Authenticator が8桁コードしか表示せず先へ進めない――この症状は、MFA 登録が“個人用 Microsoft アカウント”側になっている／テナント側の登録と食い違っているときに起きがちです。原因の切り分けから復旧、ロックアウト時の現実的な逃げ道までをまとめます。
結論：見ているコードが「別物」になっていることが多い
Azure（正確には Microsoft Entra ID を使う職場/学校アカウントのサインイン）で求められる「6桁コード」は、多くの環境で Authenticator アプリのワンタイム パスコード（OTP / TOTP）です。一方、Microsoft Authenticator に表示される「8桁コード」は、設定のされ方によっては 個人用 Microsoft アカウント（いわゆる MSA）の確認コードとして表示されている場合があります。
そのため、Outlook や Microsoft 365 には入れるのに Azure だけ入れない、という “ねじれ” が発生します。よくあるのは次のパターンです。
6桁と8桁の「正体」を先に整理
「6桁が正しい／8桁が間違い」と決めつけるより、今見えているコードが“どのアカウントの、どの認証方式のコードか”を整理すると復旧が早くなります。
| 表示されるコード | 主に紐づく先 | よく使われる用途 | Azure で6桁を求められたときの判断 |
|---|---|---|---|
| 6桁（30秒ごとに変化） | 職場/学校アカウントの Authenticator 登録（TOTP/OTP） | 「コード入力」での MFA | まずはこの6桁を出せる状態が理想。出ないなら登録不足/ねじれを疑う |
| 8桁（一定時間で変化） | 個人用 Microsoft アカウント（MSA）など別系統の確認コード | 個人用アカウントの2段階認証、別サービスの確認 | “見ているアカウントが違う”サインになりやすい。職場/学校側の再登録が必要 |
| 桁数が異なる/コードが出ない | プッシュ承認（番号一致）やパスワードレス設定 | 「承認」ボタンでの MFA | サインイン画面で「別の方法」を選び、コード入力以外が選べるか確認 |
上記を踏まえ、実際の現場で多い“詰まり方”を症状別にまとめると次の通りです。
| よくある状態 | 画面上の見え方 | なぜ起きる | まずやること |
|---|---|---|---|
| Authenticator に「個人用 Microsoft アカウント」しか登録されている | 8桁コードは出るが、Azure の6桁入力に合わない | 職場/学校アカウント側の MFA 登録（テナント側）が欠けている/壊れている | セキュリティ情報ページから「職場/学校」アカウントとして再登録 |
| 同じメールアドレスに「個人用」と「職場/学校」が混在 | サインイン時にアカウント選択が出たり、別テナントに飛ぶ | ブラウザのセッションや自動入力で別アカウントに誘導される | シークレット/プライベートでサインインし直し、テナントを固定 |
| テナント側では6桁 OTP を要求しているが、端末時刻がズレている | 6桁を入れても「コードが違う」 | OTP は時刻同期に依存する | 端末の日時を自動設定にして再試行 |
| 自分が唯一の全体管理者で、MFA 再登録できず詰む | Azure に入れずサポート チケットも作れない | いわゆるテナント ロックアウト | 別管理者でのリセット or サポート経由での解除が必要 |
最初にやるべき「切り分け」チェック
闇雲に削除・再登録を繰り返すと、状況によっては復旧が遠回りになります。まずは以下をチェックしてください。
Authenticator で「該当アカウント」が本当に職場/学校アカウントか
- Authenticator に表示されているアカウント名が、会社名/学校名や ドメイン（[email protected]）として出ているか
- 「Microsoft」という汎用名の項目だけになっていないか（個人用アカウント側の可能性）
- 同名のアカウントが複数ある場合、6桁/8桁のどちらが出るかを見比べる
ポイントは「Azure が要求しているのは、今ログインしようとしている テナントに紐づく職場/学校アカウントの MFA」だということです。Authenticator に“それ用の登録”が存在しないと、コードの桁数以前に噛み合いません。
端末の時刻同期（時刻の自動設定）
- Android：設定 → システム → 日付と時刻 → 「ネットワーク提供の時刻/自動設定」をオン
- iPhone：設定 → 一般 → 日付と時刻 → 「自動設定」をオン
OTP は30秒ごとに変わるため、端末が数分ズレているだけでも失敗します。コードが「6桁で表示されているのに通らない」場合は特にここが盲点です。
ブラウザのサインイン状態（別アカウントに誘導されていないか）
- まずは シークレット/プライベート ウィンドウで Azure にサインインを試す
- パスワード マネージャーや自動入力が、個人用アカウントの方を出してこないか注意する
同じメールアドレスで「個人用」と「職場/学校」が存在すると、意図しない方にログインしてしまい、結果として“違う認証”を求められます。
サインイン時に「個人用アカウント」と「職場または学校アカウント」の選択肢が出る場合は、必ず職場または学校を選びます。以前に個人用を選択したままブラウザに記憶されていると、以後も自動で個人用に寄ってしまい、Azure だけ認証が噛み合わない原因になります。
どうしても取り違える場合は、対象サイトの Cookie/サイトデータを削除してから、シークレットでやり直すと改善することがあります。
セルフ復旧で直ることが多い手順（軽症）
次の順番で進めると、手戻りが少なく復旧しやすいです。
Authenticator を更新し、時刻同期を確認する
- Authenticator を最新版に更新する（表示や登録フローが改善されていることがあります）
- 端末の日時を自動設定にする（前述）
「職場/学校アカウント」として正しい導線で再登録する
重要なのは、Authenticator 側でアカウントを追加するだけではなく、テナント側（セキュリティ情報）に“Authenticator を使う”登録を作り直すことです。最も実務で使われる入口は次のどちらかです。
https://mysignins.microsoft.com/security-infohttps://aka.ms/mysecurityinfohttps://aka.ms/mfasetup（環境によって上記ページへ誘導されます）
上記へアクセスし、職場/学校アカウントでサインインできたら、画面の指示に沿って次を実施します。
- 「サインイン方法の追加」→「Authenticator アプリ」
- 表示された QR コードを Authenticator で読み取る
- 「テスト」手順が出たら、そこで示されるコード/承認を完了させる
Authenticator アプリ側の操作は基本的に次の流れです。
- 「＋」→「職場または学校アカウント」を追加
- 「QR コードをスキャン」
- 登録が完了したら、アカウント一覧に“組織名”で出ることを確認
サインイン画面で「別の方法」を選んで突破できないか試す
組織の設定次第では、サインイン画面に「別の方法でサインイン」や「別の方法を試す」が出ます。ここから次を選べる場合があります。
- Authenticator の承認（プッシュ通知）
- SMS
- メール
- 回復コード
もし一度でも突破できれば、その後にセキュリティ情報ページで登録を作り直すのが最短です。逆に、突破手段が一切なく、セキュリティ情報にも入れない場合は “重症” 側の手順に進みます。
Authenticator の再インストールは最後の手段
「アプリを入れ直せば直るのでは？」と思いがちですが、Authenticator の再インストールは登録情報を失うリスクがあり、特に管理者アカウントでは危険です。実務では次の順序で検討します。
- まずは端末時刻・ブラウザ セッション・テナント固定など、“取り違え”の要因を潰す
- 次に、セキュリティ情報ページから再登録（QR で追加）を行う
- それでもダメで、かつ代替手段（SMS/別管理者/回復コード）が確保できている場合のみ、再インストールを検討する
なお、クラウド バックアップ機能が有効でも、組織のポリシーやサインイン状態によって復元がスムーズにいかないことがあります。管理者アカウントは「バックアップがあるから大丈夫」と過信せず、複数の復旧経路を前提に設計しておくのが安全です。
「セキュリティ情報」ページに入れないときの現実的な回避策
よくある詰まり方は、次のような表示です。
- 個人用アカウントでログインしてしまい、「ここは職場/学校アカウントでサインインしてください」と出て詰まる
- 別テナントに誘導され、対象のテナントでの登録を編集できない
ブラウザ セッションを分離して「アカウント取り違え」を止める
- シークレット/プライベートで
mysignins.microsoft.comを開く - 可能なら、別ブラウザ（Chrome と Edge など）で分ける
- いったん
https://login.microsoftonline.com/logout.srfにアクセスしてから試す
テナント（組織）を固定して開く
複数テナントに所属している、または同一メールで個人用/職場用が混在している場合は、アクセス先でテナントを明示すると改善することがあります。環境により使える形式が異なるため、次を上から順に試すのが実務的です。
https://mysignins.microsoft.com/security-info?tenantId=<テナントID(GUID)>https://mysignins.microsoft.com/security-info?tid=<テナントID(GUID)>https://portal.azure.com/#@<テナントの既定ドメイン(例: contoso.onmicrosoft.com)>
テナントID（ディレクトリID）が分からない場合でも、既定ドメイン（xxxx.onmicrosoft.com）が分かれば #@ 形式で Azure ポータルのサインイン先を固定できることがあります。
テナントID（ディレクトリID）が分からない場合の探し方
Azure に入れない状態でも、Microsoft 365 側に入れているなら、次のどこかで手がかりが得られることがあります。
- Microsoft 365 管理センターの「組織のプロファイル/組織情報」画面（組織名や既定ドメインが分かる）
- サインイン後に表示される「マイ アカウント」系ページで、組織情報（ディレクトリ情報）が確認できる場合がある
- 社内の管理者/情シスが管理台帳に控えている（テナントIDは運用で必ず控えるべき情報）
それでも直らない場合に疑うべき「登録のねじれ」
再登録しているのに改善しない場合、アプリの表示上は登録できていても、テナント側の認証方法が別物になっていることがあります。典型例を挙げます。
- テナント側では「Authenticator（6桁 OTP）」が既定なのに、ユーザー側は「個人用アカウントの8桁コード」を見ている
- テナント側で強制しているのが「OTP」ではなく「プッシュ承認」なのに、サインイン画面がコード入力に固定されている（条件付きアクセス/セッション状態の影響）
- 過去に登録していた端末を削除したが、テナント側に古い登録が残っている
この段階では “自分の端末操作だけで完結させる” のが難しくなるため、次の章の「管理者によるリセット」を優先するのが安全です。
別の管理者がいるなら「管理者リセット」が最短（中〜重症）
自分が Azure に入れない場合でも、同一テナントの別管理者が Azure/Entra に入れるなら、そこで MFA を一度リセットしてもらうのが最短です。依頼時に伝えるべきポイントと、管理者側での作業のイメージをまとめます。
依頼するときに伝える情報
| 項目 | 例 | 目的 |
|---|---|---|
| 対象ユーザー（UPN） | [email protected] | 誤って別ユーザーを触らないため |
| 所属テナントの識別 | contoso.onmicrosoft.com / テナントID | 別テナント作業を防ぐ |
| 症状 | 「6桁要求だが8桁しか出ない」 | 認証方法の食い違いと判断しやすい |
| いつから/直前の変更 | MFA 再登録、端末変更、条件付きアクセス変更など | 再発防止・影響範囲の確認 |
管理者側でよく行う対応
- ユーザーの認証方法（Authenticator/電話/SMS 等）を削除して、再登録を促す
- 「次回サインイン時に MFA を再登録させる」設定を有効にする
- 必要に応じて、既存のサインイン セッションを無効化（再認証を強制）する
管理画面は、環境によって Microsoft Entra 管理センター（entra.microsoft.com）や Azure ポータル、Microsoft 365 管理センターから辿ることになります。名称や配置は変わることがありますが、狙いは一貫して「テナント側の認証方法の登録をいったん白紙に戻し、正しい登録で作り直す」です。
自分が唯一の全体管理者なら「テナント ロックアウト」になり得る（重症）
もしあなたが テナント唯一の全体管理者（グローバル管理者）で、かつ代替のサインイン手段がなく、セキュリティ情報にも入れない場合は、いわゆる テナント ロックアウトの状態になり得ます。この場合、ユーザー側の操作だけでの復旧は期待できません。
ロックアウト時にやるべきこと
- Microsoft 365 管理センターに入れるなら、そこからサポート リクエスト（サービス要求）を起票する
- 管理センターにも入れない場合は、契約形態に応じたサポート窓口（電話/パートナー経由）を使う
- 本人確認・テナント所有確認に必要な情報を用意する（契約情報、ドメイン所有の確認、請求情報など）
実務的には、Azure だけに閉じずに「Microsoft 365 側から支援ルートを確保する」ことが多いです。Azure に入れないからサポートを諦めるのではなく、入れる管理ポータル（Microsoft 365 管理センター、パートナー ポータル等）を探して、そこからエスカレーションします。
再発防止：同じ詰み方をしないための運用設計
今回の症状は、技術的には「MFA 登録の不整合」ですが、運用設計としては “詰みポイント” を潰すことが重要です。特に管理者アカウント周りは、Azure/Entra の設計そのものよりも、いざという時の 復旧経路の有無が生死を分けます。
最低限おさえたいチェックリスト
| 項目 | 推奨 | 狙い | メモ |
|---|---|---|---|
| 全体管理者の人数 | 複数名 | 一人が詰んでも復旧できる | 日常運用用と緊急用で役割分離すると安全 |
| 緊急用（ブレークグラス）アカウント | 用意する | 条件付きアクセスや MFA 設計ミスでも最後に入れる | 強固なパスワード＋厳格な保管、利用時は監査ログ確認 |
| 認証手段の多重化 | 複数登録 | 端末紛失・機種変更でも詰まない | SMS を許可するかはリスク評価次第。可能なら FIDO2/パスキーも検討 |
| MFA 設定変更時の検証 | 別アカウントで事前検証 | 本番テナントでのロックアウトを防ぐ | 条件付きアクセスは段階導入が基本 |
| テナント情報の台帳化 | 必ず控える | tid/tenantId が必要になった時に詰まない | テナントID、既定ドメイン、契約情報、サポート契約をまとめて保管 |
「8桁コードが出る＝全部ダメ」ではない
今回のように “桁数が違う” と焦りがちですが、裏を返すと「何らかのアカウントとしては Authenticator が動作している」状態でもあります。問題は、Azure が求めるのが “そのアカウントではない” ことです。
やるべきことは、以下の順で整理できます。
- ログインしようとしているのは「職場/学校アカウント」か
- そのアカウントに対して、テナント側のセキュリティ情報に Authenticator が登録されているか
- 登録が壊れているなら、セキュリティ情報ページから再登録できるか
- 再登録できないなら、別管理者またはサポートでリセットできるか
よくある質問（同じ状況で迷いやすいポイント）
Outlook や Microsoft 365 には入れるのに、Azure だけ入れないのはなぜ？
サービスごとにサインインの入口やセッション管理が異なり、結果として「別のアカウント/別テナント」に誘導されることがあります。特に、ブラウザに残っているサインイン情報や、個人用 Microsoft アカウントが優先される状態だと、Azure だけが別ルートになりやすいです。シークレットでの再試行と、セキュリティ情報ページでの登録確認が効果的です。
Authenticator からアカウントを削除しても直りません
Authenticator 側を消しても、テナント側（セキュリティ情報）に古い登録が残っていると、サインインフローが噛み合いません。逆に、テナント側の登録を修復することで、Authenticator 側は “正しく追加し直す” だけで済むことが多いです。
サポートに連絡する前に用意しておくべき情報は？
- テナントの既定ドメイン（
xxxx.onmicrosoft.com） - 可能ならテナントID（ディレクトリID）
- 影響しているユーザー（UPN）
- 発生日時、直前に変更した設定、表示されるエラー文（スクリーンショット）
- 契約/請求に関する情報（サポート契約の確認に使われることがあります）
まとめ：桁数の問題ではなく「どの MFA 登録を参照しているか」の問題
Azure が6桁を求め、Authenticator が8桁しか出さないとき、根本原因は「コードの入力ミス」ではなく、個人用 Microsoft アカウントと職場/学校アカウントの取り違え、または テナント側の MFA 登録の不整合であることがほとんどです。まずはセキュリティ情報ページから職場/学校アカウントとして再登録し、無理なら管理者リセット、管理者が自分だけならサポート経由での解除――という順で進めると、最短で復旧できます。
コメント