Microsoft AuthenticatorからGoogleへ移行する方法|TOTP互換性・機種変更の違い

Microsoft AuthenticatorからGoogle Authenticator(Google認証システム)へ乗り換える場合は、対象サービスの認証アプリ設定でQRコードを再発行し、Google側へ登録して検証します。TOTPを利用するサービスなら互換性がありますが、Microsoftのプッシュ承認やパスワードなしサインインを、そのままGoogle側へ移せるわけではありません。旧アプリを消す前に、移せる認証方式かを確認してください。

目次

一括移行・機種変更・バックアップ復元を分ける

やりたいこと公式に案内される方法
MicrosoftからGoogleへアプリを変えるサービスごとの認証アプリ追加・変更で再登録する
Google Authenticatorの端末を変えるGoogleアカウント同期、または旧Googleアプリのコード転送
Microsoft Authenticatorの端末を変えるMicrosoftのバックアップ復元。同じ端末種類が条件
Microsoftのプッシュ承認をGoogleへ移すTOTPの再登録とは別。必要なMicrosoftアプリ固有の方法は残す

Googleのコード転送手順は、旧端末のGoogle Authenticatorから新端末のGoogle Authenticatorへ移す流れです。Microsoftの復元手順もMicrosoft Authenticatorへ戻すための機能です。これらをMicrosoftからGoogleへ一括でインポートする手順として使わず、アプリを変える場合は各サービスの登録変更を進めます。

機種変更だけなら、必ず全サービスを一から再登録しなければならないとは限りません。MicrosoftのバックアップはiOSからiOS、AndroidからAndroidという同じ端末種類が条件で、仕事・学校アカウントは名前だけが復元され、追加のサインインが必要です。復元後も各アカウントが実際に使えるか確認してください。

互換性があるのはTOTPのコード認証

TOTPの仕様(RFC 6238)は、共有した秘密鍵と時刻を使うコードの仕組みです。アプリに同じサービス名を手入力しただけでは、そのサービスに認証方法として登録されません。サービスが発行した設定用QRコードや秘密鍵が必要です。

Microsoft Entraの公式資料も、OATH TOTPを使う第三者の認証アプリを利用できると説明しています。ただし、組織の許可方式や条件付きアクセスによって、その方法でサインインできない場合があります。Microsoft Authenticatorの番号一致プッシュやパスワードなし認証の登録を、TOTPコードの互換性だけを根拠に削除しないでください。

  • コードを入力するTOTP:そのサービスが対応し、設定変更を許可していればGoogle側へ再登録できる。
  • 通知の承認・番号一致:Microsoft Authenticatorに届く要求をGoogleのTOTPコードへ自動移植するものではない。
  • パスワードなし・パスキー・端末認証:TOTPとは別の登録。必要な認証方法や端末要件を別に確認する。

移行前に準備するもの

  • 対象のサービス名とアカウント名を一覧にし、コード方式かプッシュ方式かを分ける。
  • 旧アプリで現在ログインできることと、パスワードを確認する。
  • サービスが提供する回復コードや別の認証方法を、他人に共有されない場所へ保存する。
  • Google Authenticatorを準備し、端末の日時が正しいか確認する。
  • 仕事・学校のアカウントは、TOTPが許可されているかIT担当者へ確認する。

QRコード、設定用の秘密鍵、回復コードはログインを助ける重要な情報です。移行記録にはサービス名・日時・成否を残し、QRや秘密鍵そのものを共同のメモやチャットへ貼らないでください。

サービスごとに再登録する手順

  1. 対象サービスの公式サイトへ、旧アプリを使ってログインします。設定中のセッションは作業が終わるまで残します。
  2. セキュリティや二段階認証の画面から「認証アプリを追加」「認証アプリを変更」等を開きます。追加と置換はサービスによって異なります。
  3. サービスが表示した設定用QRコードをGoogle Authenticatorの追加操作で読み取ります。同じ電話でQRを表示している場合は、サービスが案内する手動設定用キー等を使います。
  4. Google側で生成したコードをサービスの検証欄へ入力し、登録の保存・完了まで進めます。
  5. ログイン済みの設定画面を残した状態で、別ウィンドウ等から新しいログインを試します。新しいコードによる追加認証が成功するか確認します。
  6. 成功してから、サービス側に残す認証方法と不要な旧登録を整理します。最後に旧アプリ側の不要な項目を削除します。

変更によって秘密鍵が再発行されると、旧アプリのコードが使えなくなる場合があります。「新旧アプリを残せば必ず両方のコードが使える」「同じQRを二つで読むと停止時間ゼロ」とは保証できません。複数認証方法の追加が許されるか、既存設定を置き換えるかをサービスの画面で確認してください。

アプリ内の項目削除は、サービス側の認証方法を無効にする操作とは別です。不要な旧認証方法がサービス側に独立して残っている場合は、サービス側でも正しい対象を確認して整理します。

Microsoftの個人用と仕事・学校用の設定

アカウント種類公式の設定入口と確認点
個人用MicrosoftアカウントMicrosoftアカウントのSecurity→Manage how I sign in→新しいサインインまたは確認方法→アプリを使用。別Authenticatorの設定を選ぶ
仕事・学校のアカウントセキュリティ情報の登録画面。許可されている場合に「別の認証アプリを使用したい」を選ぶ

個人用の入口はMicrosoftのアカウント追加手順、仕事・学校用の別認証アプリの選択はセキュリティ情報の登録手順で確認できます。組織で表示されない、登録はできても利用が拒否される場合は管理者へ確認します。個人用と組織用を同じ設定画面だと考えないでください。

仕事・学校用ではメールアドレスを追加できても、それがMFAの代わりになるとは限りません。Microsoftの資料ではメールはパスワードリセット用で、二要素認証には別の方式が必要です。移行のために組織のMFA全体を無効にする必要もありません。

具体例:GitHubのTOTPアプリを変更する

GitHubの公式変更手順では、プロフィール→Settings→Password and authentication→Two-factor methodsでAuthenticator appのEditを開きます。QRコードを新しいアプリで読み取り、コードをVerify欄へ入力してSaveします。新しいコードで検証し保存するまでは、変更が有効にならないと説明されています。

GitHubは2FA全体を解除せずアプリを変更でき、この変更だけで回復コードを新しくする必要はないと案内しています。他のサービスでは回復コードが更新される場合もあるため、「すべてのサービスで同じ動き」とは考えず、各サービスが提示する回復コードと設定結果を確認します。

コードが通らない・登録できないとき

状態確認する点
新しいコードが無効違うアカウントを登録していないか、サービスで保存したか、期限内のコードか、端末日時は正しいか
Google側に移したつもりだが空Google同期はGoogle Authenticator内のコードが対象。Microsoftのバックアップを読んだわけではない
仕事アカウントで登録やサインインを拒否組織の許可する認証方法と認証強度・端末条件を管理者へ確認
旧アプリを失いログインできないサービスの回復方法または組織のIT窓口を利用。コードの再生成を推測で試さない

Googleの公式案内では、バージョン7.0でアプリ内の時刻補正設定がなくなり、OSの時刻設定を使います。古い「コードの時刻調整」メニューを探すより、端末の日時を確認します。コードが通らない状態で旧アプリやバックアップを削除しないでください。

Googleの同期を使うか、端末内で使うか

Google AuthenticatorはGoogleアカウントへサインインしてコードを同期でき、アカウントなしで使う選択もあります。アカウントなしで使う場合の機種変更は、利用可能な旧端末からの手動転送を事前に準備します。同期先のGoogleアカウントに入れなくなった場合も考え、サービスごとの回復方法は別に確保してください。

旧アプリを削除する前の最終確認

移行の完了は、新アプリにサービス名が並んだことではなく、サービス側で設定を保存し、新しいコードで追加認証を含む実際のログインが通ったことで判断します。対象ごとの結果と残す認証方法を記録してから、旧アプリの不要な項目を整理してください。

  • 移行対象すべてで新しいコードを使うログインを確認した。
  • Microsoft固有のプッシュ承認やパスワードなし認証を、ほかの用途でまだ使っていないか確認した。
  • 対象サービスの回復方法と、組織の必要な認証方式を残した。
  • Googleの同期または端末転送の方法を把握した。

一部のコードを移しただけなら、Microsoft Authenticator全体やクラウドバックアップを消す必要はありません。使い続ける方法を残し、確認できた対象だけ整理することで、乗り換えと認証の継続を両立できます。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次