Microsoft Authenticator を新しいスマホへ移行したところ、Azure Entra ID のサインインで「操作が必要」と表示され、QR コードの読み取りを求められて先へ進めない——。この記事は、その状況を旧端末なしでも解決できる実務手順を、管理者・利用者の両視点で整理し、運用設計や予防策まで一気通貫で解説します。
問題の全体像：なぜ新しいスマホで「操作が必要」になるのか
Microsoft Authenticator のアカウント転送やクラウドバックアップは、一般的な TOTP（ワンタイムパスコード）エントリの復元には有効ですが、Azure Entra ID（旧 Azure AD）の MFA 登録そのものは別物です。組織のテナントに紐づく「認証方法（Authentication methods）」として登録された端末や通知設定は、新しい端末では再登録が必要です。これが満たされないと、Authenticator 上でアカウントが表示されていても、サインイン時に「操作が必要（Action required）」となり、サービス側が発行する新規 QR コードを読み取る要求で止まります。
- 要点：見えているだけでは「使える」状態ではない。
サーバー側（Entra ID）の登録をリセット→再登録する必要がある。 - QR コードの所在：ユーザー自身のサインイン再登録フローか、管理者がリセットした後の初回サインイン時に表示される。
前提と用語の整理
- Entra ID 管理センター：組織の ID とアクセス管理ポータル。ユーザー／認証方法／条件付きアクセスなどを管理。
- MFA（多要素認証）：パスワードに加え別要素（アプリ通知・TOTP・SMS・FIDO2 など）を要求する仕組み。
- Require re‑register MFA（多要素認証を再登録させる）：既存の Authenticator 紐付けを切り、次回サインイン時に再登録を強制する管理者操作。
- Temporary Access Pass（TAP）：一時的な使い捨てのアクセスコード。端末を失っても初期登録を自己完結させやすい救済手段。
最速の解決策（管理者向け 推奨フロー）
管理者（サブスクリプション所有者・グローバル管理者）であれば、旧端末がなくても次の流れで 5～10 分程度で復旧できます。
| 手順 | 操作内容 | 補足 |
|---|---|---|
| 1 | Entra ID 管理センターにサインイン | 管理者でのサインインが困難な場合は後述の「救済手順」へ |
| 2 | [ユーザー] → 対象ユーザー → [認証方法]を開く | 外部ユーザー形式の長い UPN（…#EXT#@…）でも手順は同じ |
| 3 | ［多要素認証を再登録させる］をクリック → 保存 | 既存の Authenticator 紐付けが無効化される |
| 4 | 利用者が新スマホでサインイン → 画面に出る新しい QR コードを Authenticator で読み取る | 以後は新スマホのみでプッシュ通知／コード生成が可能 |
| 5 | 動作確認後、旧スマホを初期化・返却 | 資産管理・紛失対策の観点でも速やかに実施 |
UI 操作の細部（管理者）
- ユーザー詳細 → 認証方法画面で、不要な電話・Authenticator・FIDO2など過去の方法を削除してから「再登録を要求」でもよい（より確実）。
- あわせてサインインセッションの取り消し（全デバイスの再認証を促す）を実行すると切替がスムーズ。
- 条件付きアクセスで対象ユーザーのアクセスを一時緩和しておくと導入時の詰まりを回避できる。
旧端末がまだ使える場合の簡易ルート（ユーザー主導）
- 旧スマホの Authenticator でサインイン要求を承認。
- 自分のセキュリティ情報（My Sign‑Ins）画面を開く（ポータル名のみ記載）。
- [サインイン方法を追加] → [Authenticator アプリ]を選択。
- 表示されたQR コードを新スマホの Authenticator で読み取る。
- 新スマホで認証が通ることを確認したら、一覧から旧端末のエントリを削除。
このルートは管理者を介さずに完結できるため、旧端末の一時的な使用が可能であれば最も手早い方法です。
サインイン不能・管理者権限がない場合の救済手順
どうしても管理者でサインインできない、他に管理者がいない、といったケースでは次の選択肢が現実的です。
| 手段 | 要件 | 実施ポイント | メリット／注意点 |
|---|---|---|---|
| ブレイクグラス（緊急アクセス）アカウントでの復旧 | テナント内に MFA 免除の緊急アカウントが事前に用意されている | 緊急アカでサインイン → 対象ユーザーのMFA リセットやTAP 発行を行う | 最速かつ確実。 平時からの整備が必須（強固なパスワード・厳格な保管・監査） |
| 他のグローバル管理者に依頼 | 同僚や管理委託先が管理者権限を持つ | 対象ユーザーの［多要素認証を再登録させる］実施、または不要な認証方法の削除 | 役割分担のある組織で現実的。 監査ログを残し、作業記録を保全 |
| Temporary Access Pass（TAP）の発行 | テナントで TAP を有効化済みであること | 管理者が対象ユーザーへ有効期限付きの一時コードを払い出し、 ユーザーは新端末で初期登録時に TAP を使用 | 端末紛失時でも自己完結可能。 有効期限／一回限り設定などポリシー管理が重要 |
| 組織のアカウント回復プロセス | ヘルプデスク・身元確認手順が定義されている | 本人確認後に管理者が MFA リセットや代替手段登録を実施 | セキュリティ強度は高いが、時間を要する。 手順の標準化が鍵 |
トラブルの原因別チェックと対処
| 症状 | 考えられる原因 | 対処法 |
|---|---|---|
| 「操作が必要」から先へ進まない | サーバー側の認証方法に旧端末が残っている／再登録が未実施 | 管理者でRequire re‑register MFAを実行 → 新端末で再登録 |
| QR コードを読んでも無効 | QR コードの有効期限切れ、時刻ズレ、ネットワーク制限 | QR を再発行、スマホの時刻自動設定、モバイル通信で試行 |
| プッシュ通知が届かない | 通知許可オフ、低電力モード、MDM ポリシーでの制限 | OS の通知設定を見直し、Authenticator のバックグラウンド実行を許可 |
| 番号マッチング画面が出ない／認証強度でブロック | 古いアプリ／セキュリティ既定や条件付きアクセスの要件不一致 | Authenticator を最新化、認証の強度や要件を一時緩和して再登録 |
| SMS やメールに頼り切り | 代替手段の未登録 | Authenticator に加え、FIDO2 セキュリティキーやSMSも登録 |
ベストプラクティス：運用と予防策
| 項目 | 推奨内容 |
|---|---|
| バックアップと復元 | Authenticator のクラウドバックアップを有効化。ただしEntra ID の MFA 登録自体は再設定が必要であることを周知。 |
| 代替認証の多層化 | SMS、電話、FIDO2、電子メールなどを最低 2 種類以上併用。 パスワードレス（Authenticator での電話サインインや FIDO2）も検討。 |
| ポリシー整合性 | セキュリティ既定（Security Defaults）や条件付きアクセスが厳格な場合は、 再登録時のみ一時緩和できる手順書を作っておく。 |
| 緊急アクセス | ブレイクグラスアカウントを 2 アカウント以上用意し、定期的にログインテスト。 パスワード保管は厳密に（分割保管・物理金庫など）。 |
| 年次点検 | 全ユーザーの認証方法棚卸し、不要エントリの削除、ローテーション実施。 テナントの認証方法ポリシー設定も見直す。 |
画面なしで理解する再登録の流れ（利用者向け）
- ブラウザーで職場アカウントにサインインを開始。
- 「追加の情報が必要です」や QR 表示画面が出たら、新スマホの Authenticatorを起動。
- アプリで[＋] → [職場または学校アカウント]を選択し、カメラで QR を読み取る。
- アプリ側に6 桁コードが出たら、画面の指示どおりに入力。
プッシュ通知の番号マッチングが表示される場合は一致する番号を選ぶ。 - 完了後は、旧端末のエントリをアプリ・ポータルの両方から削除しておく。
管理者のバリエーション：UI 以外での復旧（Microsoft Graph 例）
多数ユーザーの一括切替や自動化には Graph PowerShell が有効です。代表的な操作例を示します（実行前に検証環境でテストしてください）。
# Microsoft Graph PowerShell の接続（必要な最小権限は運用要件に合わせて調整）
Connect-MgGraph -Scopes "User.ReadWrite.All","Policy.ReadWrite.AuthenticationMethod","Directory.AccessAsUser.All"
# 対象ユーザー（例）
$UserId = "[[email protected]](mailto:[email protected])"
# 現在の認証方法一覧を確認
Get-MgUserAuthenticationMethod -UserId $UserId | Select-Object Id, OdataType
# Authenticator / Phone などを削除（サーバー側の紐付けを外す）
Get-MgUserAuthenticationMethod -UserId $UserId |
Where-Object { $*.OdataType -match "microsoftAuthenticatorAuthenticationMethod" -or $*.OdataType -match "phoneAuthenticationMethod" } |
ForEach-Object { Remove-MgUserAuthenticationMethod -UserId $UserId -AuthenticationMethodId $_.Id }
# サインインセッションを取り消し（再認証を促す）
Revoke-MgUserSignInSession -UserId $UserId
# 必要に応じて Temporary Access Pass（TAP）を発行
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $UserId ` -StartDateTime (Get-Date).ToUniversalTime()`
-LifetimeInMinutes 60 `
-IsUsableOnce:$false ポイント：
- 削除＝完全消去のため、ユーザーに再登録手順とタイムラインを案内してから実施します。
- TAP を使うと、ユーザーはパスワード入力に代えて一時コードで初期登録を進められます。
- 監査のため、実行結果と担当者・対象・時刻を必ず記録しましょう。
ポリシー影響の読み解き（条件付きアクセス／セキュリティ既定）
- セキュリティ既定（Security Defaults）が有効なテナントでは、ユーザー自身による MFA の解除や弱い方法の登録がブロックされることがあります。再登録に詰まりやすい場合は、期間限定で例外グループを作成して緩和し、完了後に戻す設計が安全です。
- 条件付きアクセスで「特定の認証強度（例：多要素・フィッシング対策済み）」を要求していると、Authenticator の再登録前にサインインが成立せず先へ進めないことがあります。再登録期間だけ一時的に対象ユーザーに緩和ポリシーを適用し、終わったら外す運用が現実的です。
- 認証方法ポリシーで Authenticator の利用を許可しているか、FIDO2 や SMS を併用できるかを確認します。TAPを採用する場合も同ポリシーで有効化されている必要があります。
移行プロジェクトとしてのチェックリスト
- 役割：管理者権限の確認（代替管理者・委託先も含む）
- 緊急アクセス：ブレイクグラスを 2 つ以上、年 1 回の動作確認
- ユーザー告知：再登録の目的、所要時間、自己完結手順（QR 提示→読み取り）
- ポリシー：セキュリティ既定／条件付きアクセスの一時緩和計画と復帰手順
- 代替手段：SMS・FIDO2・メールを事前登録（優先順位とガイド）
- 端末要件：OS 更新、時刻自動設定、通知・カメラ許可、MDM 制御の整合性
- 自動化：Graph スクリプトで削除／TAP 発行／セッション取り消しを標準化
- 監査：サインインログ監視、変更履歴の記録、ヘルプデスクのナレッジ更新
FAQ（現場でよくある質問）
Q. Authenticator のバックアップを復元したのに「操作が必要」が消えません。
A. バックアップはアプリ内リストの復元に過ぎず、Entra ID 側の登録は別管理です。管理者が Require re‑register MFA を実行するか、ユーザー自身が QR から再登録してください。
Q. QR コードはどこで表示されますか？
A. 管理者が再登録を要求した後の初回サインイン時、またはユーザーのセキュリティ情報ページで[サインイン方法を追加] → [Authenticator アプリ]を選択すると表示されます。
Q. 旧スマホが壊れて使えません。どうすれば？
A. 管理者が対象ユーザーの認証方法をリセットし、TAPで初期登録を支援するのが最速です。TAP が使えない場合は、暫定的に SMS などの代替手段を登録してから Authenticator を再設定します。
Q. Per-user MFA（レガシー有効化）と条件付きアクセスが混在しています。影響は？
A. 混在は挙動を複雑にします。いずれかに統一し、認証強度ベースのポリシーへ段階的に移行するのが望ましいです。
Q. パスワードレスに移行すべきですか？
A. 運用負荷やフィッシング耐性の観点から、Authenticator の電話サインインや FIDO2 セキュリティキーの併用を推奨します。MFA 再登録のたびに詰まるリスクを下げられます。
実務に使えるテンプレ：ユーザー案内メール（社内）
件名：Microsoft Authenticator 再登録のお願い（新スマホへの機種変更）
各位
新しいスマホでのサインイン時に「操作が必要」と表示された場合は、以下の手順で再登録してください。
1. PC で業務アカウントにサインインを開始
2. 画面の指示に従い QR コードを表示
3. 新スマホの Authenticator で [＋] → [職場または学校アカウント] → QR を読み取り
4. 6 桁コードの入力／番号マッチングで承認
5. 完了後、旧端末のエントリを削除
※ 旧端末が使えない方は、ヘルプデスクまでご連絡ください（TAP/SMS による救済あり）。
情報システム部 セキュリティ強化の仕上げ：再登録後にやること
- 旧端末のワイプ：個人情報保護とアカウント悪用防止のため必須。
- Authenticator の保護：アプリ PIN・生体認証・バックアップ有効化。
- 代替手段の追加：FIDO2 キーを 1 本以上必ず登録。SMS/メールも残す。
- ログの確認：再登録直後のサインイン失敗が続く場合は、ポリシーや端末時刻ズレを疑う。
ケーススタディ：時間がない管理者の最短レシピ
- 管理センターで対象ユーザー → 認証方法 → 不要エントリ削除。
- Require re‑register MFA を実行。
- サインインセッション取り消しを実行。
- ユーザーへ 3 行の案内を送付：「サインイン→QR 表示→Authenticator で読み取り」。
- 完了報告を受けたら、旧端末消去確認と代替手段登録をチェック。
まとめ
Microsoft Authenticator の「アカウント転送」は便利ですが、Azure Entra ID の MFA 登録は別管理であるため、機種変更時は再登録が不可欠です。管理者は Require re‑register MFA と不要エントリ削除、必要に応じた TAP 発行で、ユーザーは QR 読み取りと番号マッチングで新端末を正しく紐付ければ、旧端末がなくても短時間で復旧できます。さらに、ブレイクグラス、代替手段の多層化、ポリシー整合性、年次点検を組み合わせれば、次回以降の移行は「詰まらない・止まらない」運用に進化します。
付録：要点早見表
| 目的 | 操作 | 実施主体 | 備考 |
|---|---|---|---|
| 旧端末なしで新端末へ移行 | Require re‑register MFA → 新端末で QR 再登録 | 管理者＋ユーザー | 最速・確実 |
| 旧端末が一時的に使える | My Sign‑Ins から Authenticator を追加 → 新端末で QR 読取り | ユーザー | 管理者不要 |
| サインインできない | ブレイクグラス／他管理者経由でリセット、または TAP 発行 | 管理者 | 本人確認と監査ログを厳密に |
| 再発防止 | 代替手段の多層化・年次点検・ポリシー整備 | 管理者 | 運用ドキュメントと教育が鍵 |
コメント