Azure にサインインしようとすると MFA が「昔の携帯番号」に送られてしまい、認証を完了できずに詰む――このトラブルは、Microsoft Entra ID（旧 Azure AD）の仕組み上、本人だけでは解決できないケースが多いです。復旧の近道は、同一テナント内の管理者に “認証方法のリセット／再登録” を実施してもらうこと。管理者がいない場合は Microsoft サポート経由での復旧が必要になります。
なぜ「古い電話番号MFA」だと Azure にサインインできなくなるのか
Azure ポータルのサインインは、多くの場合「職場または学校アカウント（Microsoft Entra ID）」で行われます。MFA（多要素認証）に登録された電話番号・Authenticator アプリ・セキュリティキーなどは、ユーザーの“公開プロフィール”とは別に「認証方法（Authentication methods）」として管理されます。
この“認証方法”は、ログインして本人が更新できるのが理想ですが、サインイン自体が MFA で止まっていると、本人は変更画面へ辿り着けません。そのため、テナントの管理者権限（少なくとも認証関連の管理ロール）を持つ別ユーザーが、対象ユーザーの認証方法を更新・リセットする必要が出てきます。
まず確認：あなたのアカウントは「職場/学校」か「個人（Microsoft アカウント）」か
似た症状でも、アカウント種別が違うと復旧ルートが変わります。Azure サブスクリプションや MCT の運用で詰んでいる場合、多くは職場/学校アカウント側のロックアウトです。
| 項目 | 職場/学校アカウント（Microsoft Entra ID） | 個人アカウント（Microsoft アカウント） |
|---|---|---|
| 典型的なID表記 | [email protected] / [email protected] | [email protected] / [email protected] 等 |
| MFA変更の基本 | 同一テナントの管理者操作が基本 | 本人の復旧フォーム・本人確認フローが中心 |
| Azure/M365管理への影響 | テナント全体の運用に直結 | 個人サービス中心 |
| 詰みやすいパターン | 「自分しか管理者がいない」＋MFA喪失 | バックアップ手段なし＋回復情報が古い |
本記事は、主に職場または学校アカウント（Microsoft Entra ID）の想定で解説します。
サインインできない本人が最初に試せる「現実的な」チェック
管理者へ依頼する前に、本人側で確認しておくと復旧が速くなります。
| チェック項目 | 見る場所 / 操作 | うまくいけば | ダメなら |
|---|---|---|---|
| 「別の方法でサインイン」できないか | サインイン画面の「別の方法」や「他の方法を試す」 | Authenticator 通知、コード、セキュリティキーなど別経路で突破 | 管理者リセットへ |
| Authenticator が旧端末に残っていないか | 旧端末の Microsoft Authenticator / バックアップ | 通知承認やコードでログイン可能 | TAP などの発行が近道 |
| 職場PCが既にサインイン済みでないか | Teams/Outlook/Edge プロファイル等 | 一部の操作（連絡/情報確認）が可能 | ただし“認証方法変更”は結局管理者が安全 |
| 連続失敗でブロックされていないか | 短時間で何度も試さない（時間を置く） | 一時ブロック解除で再試行できる場合あり | 別ネットワーク/別手段、または管理者対応 |
なお、サポートの一般的な注意点として、短時間に繰り返し試すとブロックが長引くことがあります。焦って連打するより、別手段の有無を確認→管理者に依頼の方が、結果的に復旧が早いです。
結論：復旧の基本方針は「管理者が認証方法を更新・再登録させる」
このケースは、実務的には次のどれかで解決します。
| 復旧アプローチ | おすすめ度 | 向いている状況 | ポイント |
|---|---|---|---|
| Temporary Access Pass（TAP）を発行して復旧 | 高 | ユーザーが完全に MFA を失った／安全に再登録させたい | 時間制限つきのパスコードで“再登録の入口”を作れる |
| Require re-register MFA（MFA再登録の要求） | 高 | 端末紛失・電話番号変更・乗っ取り疑い | 登録済みの MFA 手段を整理し、次回サインインで再登録させる |
| 電話番号だけ差し替え（認証方法の編集/追加/削除） | 中 | 旧番号のみ問題で、他のMFA手段は正常 | 「プロフィール連絡先」ではなく「認証方法」を更新する |
| 管理者がいないなら Microsoft サポートへ | 必須 | 自分しか管理者がいない／全員がMFAで詰んだ | テナント所有の証明などが必要になりやすい |
以降は、現場で成功率が高い順に、具体手順をまとめます。
最短で安全：Temporary Access Pass（TAP）で復旧する手順
Temporary Access Pass（TAP）は、時間制限つきのパスコードを管理者が発行し、ユーザーがそれで一時的にサインインして、Authenticator などの強い認証方法を登録し直せる仕組みです。端末紛失・番号変更など “MFAの入口が消えた” 場合の復旧に非常に向いています。
管理者側：TAP を使えるようにする（初回のみ）
- Microsoft Entra 管理センター（entra.microsoft.com）に、適切なロールでサインインします。
- 「Entra ID」→「Authentication methods」→「Policies」を開きます。
- 一覧から「Temporary Access Pass」を選び、「Enable」をオンにします。
- 対象ユーザー（または対象グループ）をスコープに含めて「Save」します。
TAP の有効化には Authentication Policy Administrator が必要になる点が重要です。
管理者側：対象ユーザーに TAP を発行する
- 「Entra ID」→「Users」から対象ユーザーを選択
- 「Authentication methods」を開く
- 「Add authentication method」→「Temporary Access Pass」を選択
- 有効期限（例：1時間〜数時間）やワンタイム/複数回利用を設定して追加
- 表示された TAP の値は “OK を押すと二度と見えない” ため、必ず控えてユーザーへ安全に共有
発行作業は Authentication Administrator 等で可能ですが、ロールと対象（管理者ユーザーか一般ユーザーか）で権限要件が変わります。運用上は「特権認証管理者（Privileged Authentication Administrator）」がいると安心です。
ユーザー側：TAP でサインインして認証方法を入れ替える
- ブラウザで aka.ms/mysecurityinfo を開く
- アカウント（UPN）を入力
- TAP の入力を求められたら、管理者から受け取った TAP を入力
- サインイン後、新しい携帯番号やMicrosoft Authenticator、可能ならセキュリティキー（FIDO2）などを追加
- 最後に、古い電話番号や古い Authenticator 登録が残っていれば削除
TAP をワンタイムにした場合、登録フローの途中で時間切れになることがあるため、ユーザーには「手元に新端末・回線がある状態で、一気に登録を終える」よう依頼すると事故が減ります。
TAP 運用のコツ（現場で詰まりがちな点）
- TAP が出てこない：TAP ポリシーのスコープに対象ユーザー（または所属グループ）が入っているか確認
- 反映に数分かかる：発行直後はプロンプトが出るまで少し待つ必要がある場合があります
- 共有の仕方：メールに平文で貼らず、電話で読み上げ・期限短め・ワンタイム、など“漏えい前提”で設計
「MCTのラボ提供が止まっているので即復旧したい」場合でも、TAP は“最短かつ安全”になりやすい選択です。
強制リセット：Require re-register MFA（MFA再登録を要求）で復旧する手順
次に強力なのが、ユーザーの MFA 登録情報を整理し、次回サインイン時に再登録を必須にする方法です。電話番号変更や端末紛失で典型的に使われます。
管理者側：MFA 再登録を要求する
- Microsoft Entra 管理センターにサインイン
- 「Entra ID」→「Users」→ 対象ユーザーを選択
- 「Authentication methods」を開く
- 画面上部の操作から Require re-register MFA を実行
この操作は、ユーザーの電話番号や Authenticator アプリ登録、ソフトウェア OATH などを削除し、再登録を促す性質があります（“核オプション”に近い）。「新しい番号に差し替えるだけ」より影響が大きいので、実施前にユーザーへ周知し、業務影響（サインインし直し）を許容できるタイミングで行うのが安全です。
ユーザー側：再登録フローを完了する
管理者が実行すると、ユーザーが再度 Azure ポータルや Microsoft 365 にサインインしたとき、古い電話番号ではなく、Authenticator や新しい携帯番号などの登録を求められます。ここで登録を完了すれば、Azure サブスクリプションや MCT 関連リソースに再アクセスできる状態へ戻ります。
「電話番号だけ変えたい」場合にやるべきこと
“公開プロフィールの電話番号”と“認証用の電話番号”は別物です。MFA に使うべきなのは後者（Authentication methods）で、管理者もユーザーもここを更新します。公開プロフィールの連絡先フィールドを MFA に使う運用は推奨されません。
管理者が電話番号を追加・更新する基本手順
- 「Entra ID」→「Users」→ 対象ユーザー
- 「Authentication methods」
- 「+ Add authentication method」から Phone を追加（国番号付きの形式で登録）
- 旧い番号が残っていれば削除
この“認証方法の管理”は、旧UI（レガシー）から新UIへ段階的に変わってきています。現在は新しい Entra 管理センターの体験が基本で、レガシー体験は 2025年9月末で退役した旨が案内されています（画面表示が環境により多少異なることがあります）。
旧方式（per-user MFA）を使っているテナントの注意点
テナントによっては、条件付きアクセスではなく「per-user MFA（ユーザー単位MFA）」の設定画面が使われていることがあります。その場合、管理者は “選択ユーザーに連絡先方法の再入力を要求する” といった操作で復旧できることがあります。Microsoft のトラブルシューティングでも、別管理者が MFA 設定をリセットして復旧する流れが紹介されています。
ただし、旧ポータルは将来的な整理対象になりやすく、また運用が混在すると現場で混乱します。可能なら Entra 管理センターの「Authentication methods」中心の運用（TAP を含む）へ寄せる方が、復旧も標準化しやすいです。
管理者がいない（または全員が詰んだ）場合の現実的な復旧ルート
最も深刻なのが、自分しかグローバル管理者がいない、あるいは全管理者が同じように MFA でロックアウトしているケースです。この状態では、通常の「管理者がリセット」ができません。
最初に探すべきもの：ブレークグラス（緊急用）管理者アカウント
組織によっては、MFA を除外した緊急用アカウント（いわゆる break-glass）を用意している場合があります。もし存在するなら、そのアカウントでサインインし、TAP 発行や MFA 再登録要求を実施します。“あるかもしれない” なら、関係者に最優先で確認してください。
本当に誰も入れない場合：Microsoft サポート（Data Protection 経由を含む）
唯一の管理者が完全にロックアウトしている場合、コミュニティでは復旧できず、本人確認のうえでリセットできる専用のサポートチームへの連絡が必要になる旨が案内されています。
問い合わせ窓口は契約形態（Microsoft 365 / Azure など）や国・地域で異なりますが、Microsoft は「管理者向けサポート」や「国・地域別の問い合わせ先」ページを提供しています。電話サポートでは、組織の確認のための追加手順（PIN ベースの検証など）が入ることがあります。
- Microsoft 365 管理者向けサポートの案内：Microsoft Learn の Get support
- 国/地域別のカスタマーサービス電話番号：Customer service phone numbers
- サポート窓口の入口：Microsoft Support – Contact Us
サポート連絡前に準備すると強い「証跡」チェックリスト
“テナント所有者としての証明”が必要になることが多いため、手元で整理できるものを揃えておくと話が早いです。
| 準備物 | 例 | なぜ必要か |
|---|---|---|
| テナント情報 | tenant.onmicrosoft.com、カスタムドメイン名 | どの組織のどのテナントかを特定する |
| サブスクリプション/請求の証跡 | 請求書、契約ID、支払い情報、購入メール | 所有・管理権限の裏付けになる |
| ドメイン所有確認 | DNS 設定にアクセスできる、登録事業者情報 | 組織がドメインを管理している証明 |
| 影響範囲の整理 | 影響ユーザー、止まっている業務（MCTラボ等） | 優先度・緊急度を伝えやすい |
注意点として、サポート担当者が“本人の代わりに認証コードを送る/認証情報を勝手に変える”ことはセキュリティ上できません。テナント所有確認や所定手続きが前提になるため、証跡を用意して粘り強く進めるのが現実的です。
MCT・トレーニング運用の観点での「再発防止」ベストプラクティス
MCT の活動では、ラボ環境や受講者向けリソースを扱うことが多く、アカウント停止＝即サービス停止になりがちです。復旧できたら、同じ事故を繰り返さないために、次の設計を強くおすすめします。
運用を止めないための基本セット
- グローバル管理者を複数人（最低2）：単独管理は事故率が跳ね上がります。
- 緊急用（break-glass）アカウントを用意：強固なパスワード＋保管ルール、条件付きアクセスで厳重に監視。
- MFA 手段を複数登録：Authenticator＋電話＋セキュリティキーなど、単一障害点を作らない。
- TAP を“使える状態”にしておく：ポリシーだけでも事前に整備しておくと、復旧が爆速になります。
電話番号変更時に事故を起こさないコツ
- 番号を変える前に、新しい MFA 手段を先に追加（旧手段を消すのは最後）
- 「公開プロフィールの電話番号」ではなく、認証方法（Authentication methods）を更新する
- 一度に全手段を入れ替えない（環境によっては“セキュリティ情報の更新”が一定期間制限される場合がある）
よくある質問
自分だけで MFA を無効化してサインインできますか？
多くの場合できません。サインインの入口で MFA が必須になっている以上、本人が設定画面に入れないためです。管理者が “認証方法の管理” を行うのが正攻法です。
グローバル管理者ではない管理者でも対応できますか？
状況によりますが、少なくとも「Authentication Administrator」など、認証方法の管理に必要なロールがあれば対応できることがあります。TAP ポリシーの有効化には「Authentication Policy Administrator」が必要です。
“MFA の再登録要求”と “TAP” はどちらを選ぶべき？
迷ったら TAP を優先し、うまくいかない/登録情報が壊れている/乗っ取り疑いがあるなら再登録要求（強制リセット）を検討、が現場では安定します。TAP は復旧導線を作りやすく、影響もコントロールしやすいのが利点です。
“自分しか管理者がいない”状態で詰んだら？
break-glass アカウントがなければ、Microsoft のサポート窓口でテナント所有確認を行い、復旧を依頼する流れになります。コミュニティでは権限的に解除できない旨の案内もあります。
コメント