Microsoft AuthenticatorからGoogle Authenticatorへの安全な移行手順（2025年版）｜二段階認証・TOTP乗り換えガイド

Microsoft AuthenticatorからGoogle Authenticatorへ安全に乗り換えるための現実的な解を、実務でそのまま使える手順・チェックリスト・トラブル対応とともに解説します。結論は「一括移行機能はない」。だからこそ、最短・最小リスクで“個別再登録”を回すための段取り力が重要です。

結論：一括移行は不可、各サービスを個別に再登録する

現時点（2025年11月）では、Microsoft AuthenticatorからGoogle AuthenticatorへTOTP（時間ベースワンタイムパスワード）を直接エクスポート／インポートする公式の一括移行機能は存在しません。

これは仕様上不思議ではありません。TOTPの“鍵（シークレット）”は、各サービスのセキュリティ境界内で生成・配布され、アプリ間で自由に持ち出せる設計にはなっていないためです。Google Authenticator間の端末移行や、Microsoft Authenticator間のバックアップ復元は用意されていますが、異なるアプリ間の自動移行は想定外です。

したがって、各サービスのアカウント設定画面で「認証アプリを再登録」するのが唯一の正攻法かつ安全な手段になります。本記事は、この“個別再登録”を最短・最少リスクで終わらせるための実務ガイドです。

全体像と作戦：失敗しないための3原則

• 原則1：追加→確認→削除 … 先にGoogle Authenticatorを追加登録し、ログイン検証まで済ませてから、Microsoft Authenticatorの古い登録を削除します。
• 原則2：並行稼働期間を持つ … 移行中は両アプリを併用し、すべてのサービスで新コードが通ることを確認するまで旧アプリを残します。
• 原則3：バックアップコードの確保 … 変更時に提示される「バックアップコード／回復コード」は、その場で印刷または安全な保管庫に保存します。

事前準備（チェックリスト）

項目	内容	完了
対象サービスの棚卸し	Microsoft Authenticatorに登録済みのサービス名を洗い出し、優先度を付ける（業務・金融→優先）。	□
Google Authenticatorの導入	新端末または既存端末にインストールし、初期設定を完了。必要ならGoogleアカウント同期の要否も判断。	□
時刻の自動設定	iOS/Androidで「自動日時設定」を有効化（TOTPは時刻同期が命）。	□
回復手段の確保	各サービスのバックアップコード、回復用メール、SMS番号、予備キー（FIDO等）を確認。	□
管理者方針の確認（組織）	職場・学校テナントではGoogle Authenticatorが許可されているか、MFA方式のポリシーを確認。	□
メンテナンス時間の確保	30〜90分の“移行ウィンドウ”を確保。業務時間外や低負荷の時間帯を選ぶ。	□

標準手順（各サービス共通）

1. Google Authenticatorを準備 … iOS/Androidにインストールし、起動確認まで済ませておきます。
2. 対象サービスへ通常ログイン … パスワード＋Microsoft Authenticatorのコード（またはプッシュ）でログイン。
3. セキュリティ設定を開く … 「セキュリティ」「ログインとセキュリティ」「二段階認証」などの項目に進みます。
4. 認証アプリの追加／変更を選択 … 「認証アプリを設定」「Authenticatorアプリを追加」「二段階認証を再設定」等を選び、QRコードを表示。
5. QRコードをGoogle Authenticatorで読み取り … アプリ右下の“＋”→「QRコードをスキャン」。6桁（場合により8桁）のコードが生成されます。
6. 検証コードを入力して有効化 … サービス側の入力欄に新コードを入力し、登録完了。
7. ログイン検証 … いったんログアウトし、再ログインでGoogle Authenticatorのコードが通るかを確認。
8. 正常動作を確認後に旧登録を削除 … Microsoft Authenticator側の該当エントリを削除。クラウドバックアップも不要なら無効化。

ポイント：QRコードの表示中に、同じQRをMicrosoft AuthenticatorとGoogle Authenticatorの両方で読み取ることが可能です（同一シークレットを複数端末に登録できるサービスが一般的）。これにより、切り替え中の“ゼロダウンタイム”が実現しやすくなります。

主要サービス別の注意点（抜粋）

サービス	設定箇所の目安	特筆事項
Microsoft アカウント / Entra ID（旧Azure AD）	「セキュリティ情報」「サインイン方法の追加」→「認証アプリ（OTP）」	番号一致のプッシュ通知はGoogle Authenticatorでは使えません。OTP（TOTP）方式を追加。有効後に旧アプリの通知は無効化。
Google アカウント	「2段階認証プロセス」→「認証システムアプリをセットアップ」	Google Authenticatorとの相性は当然良好。バックアップコードの保管を忘れずに。
GitHub	「Settings」→「Password and authentication」→「Two-factor authentication」	TOTPとリカバリーコード、予備のFIDOセキュリティキー併用が推奨。
AWS	IAMユーザーまたはIAM Identity CenterのMFA設定	アカウント種別で設定場所が異なります。運用環境ではダウンタイム回避のため事前に第2要素を準備。
各種SNS（X等）	「セキュリティ」→「2段階認証」→「認証アプリ」	SMSよりTOTP推奨。バックアップコードを必ず保存。
金融・取引所系	「セキュリティ」「二段階認証」	審査や一時ロックが入る場合あり。営業時間内のサポート対応時間も考慮して作業。

“アプリ専用機能”は持ち越せない：プッシュ通知の扱い

Microsoftアカウントの「番号一致プッシュ確認」など、アプリ固有のプッシュ機能はGoogle Authenticatorへは継承できません。Google AuthenticatorはTOTP生成に特化しており、プッシュ承認は非対応です。必要に応じて、サービス側で「プッシュ承認をオフにして、TOTP（認証アプリ）を有効化」してください。

セキュリティ設計を理解する：なぜ一括移行できないのか

• TOTPは“共有シークレット＋時刻”で生成 … QRコードの中身は「otpauth://」形式で、発行者（issuer）、アカウント名、桁数、周期、アルゴリズム等を含みます。
• シークレットの逆流出を防ぐ思想 … 一度登録したシークレットをアプリから“取り出せる”と攻撃面が増えます。そのため多くの実装はエクスポートを制限します。
• 移行はサービスの支配下で … 再登録のたびに本人確認（ログイン＋コード入力＋回復コード提示等）を求めることで安全性を担保しています。

このため、“アプリからアプリへ鍵を運ぶ”のではなく、“各サービスが新しいアプリを信頼する”手続きを踏むことが求められます。

ゼロダウンタイムで移行する具体テクニック

• ダブルスキャン … QR表示中に、Microsoft AuthenticatorとGoogle Authenticatorの両方で同じQRをスキャン。新旧どちらのコードでもログインできる状態で移行を進める。
• セッション維持 … 設定変更中にセッションが切れないよう、別ブラウザ／別ウィンドウでログイン済み画面を保持。
• 優先順位付け … 業務・金融・管理者アカウントから先に。メールや主要クラウドを先行移行すると全体が回しやすい。
• 停止時間の明示（組織） … 社内告知で“影響し得る時間”を共有。運用監視や値洗いのタイミングは避ける。

トラブルシューティング

症状	想定原因	対処
コードが常に無効になる	端末時刻のズレ／間違ったアカウントに登録／桁数や周期が異なる特殊実装	OSの自動時刻をON→再起動。QRを再登録。桁数（6/8桁）や30秒周期に依存するサービスの仕様に注意。
ログインできずロック	旧アプリを先に削除／バックアップコード未保存	回復用メール・SMS・バックアップコードを使用。最終手段は本人確認を経たサポート依頼。
エンタープライズで登録が拒否される	MFA方式のポリシーでGoogle Authenticatorが非許可	管理者に確認。許可方式（OTP/FIDO）へ切り替えるか、既定のAuthenticatorを継続。
同じサービスが重複表示される	旧登録の削除忘れ	新アプリでの成功を確認後、旧アプリ側エントリを削除。混乱を避けるため名称も整理。

安全に“やらないこと”リスト

• 非公式ツールでシークレット抽出を試みない … 端末のルート化／脱獄や暗号化バックアップの解析は、漏えい・規約違反・端末破損のリスクが高い。
• 旧アプリの先行削除をしない … 新ログインの成功確認が終わるまで旧環境は保持。
• バックアップコードを画面キャプチャだけで保管しない … 画像は誤共有の危険。PDF印刷やパスワード管理ツールの安全領域を利用。

移行後の整備（運用ベストプラクティス）

• 名称の標準化 … Google Authenticator側の表示名を「発行者｜環境｜用途」（例：AWS｜Prod｜Admin）などに統一。
• 予備要素の多重化 … バックアップコード＋FIDO（パスキー／セキュリティキー）を併用して単一障害点を排除。
• 重要アカウントの年次点検 … ログインテスト、回復経路、連絡先、管理者権限の棚卸しを定期実施。
• 端末紛失への備え … 端末のリモートワイプ設定、有効なPIN/生体認証、最新OS更新を徹底。

具体シナリオで学ぶ：実務フローの例

ケースA：個人ユーザー（10サービス）

1. リスト化（メール、クラウド、開発サービス、SNS、金融）。
2. Google Authenticator導入→動作確認。
3. メールとクラウドから移行開始（影響が大きい順）。
4. 各サービスで「認証アプリを再設定」→QRをGoogle Authenticatorでスキャン→検証→旧エントリ削除。
5. 最後に金融系と暗号資産口座を移行（営業時間を考慮）。
6. Microsoft Authenticatorのクラウドバックアップを無効化→アプリ削除。

ケースB：小規模チーム（共同運用アカウントあり）

1. 責任者を一名定め、移行ウィンドウを告知。
2. 共有アカウントは「TOTP＋FIDOキー×2本（別担当者）」の構成に再設計。
3. 移行ログ（誰が・いつ・何を・結果）を残す。
4. 平常時の手順書を更新し、緊急時の連絡経路を明記。

よくある質問（FAQ）

Q. Google Authenticatorに“同期”機能があるなら、自動で全部移りませんか？

A. 同期はGoogle Authenticator内の端末間での話で、他アプリからの自動受け入れではありません。各サービスの再登録は必要です。

Q. 1つのアカウントを複数端末のGoogle Authenticatorに登録してもよいですか？

A. 多くのサービスで可能です（同一QRを複数端末でスキャン）。ただし管理負荷と紛失リスクが増える点に注意。

Q. 6桁と8桁の違いは？

A. サービス側の仕様です。QRに桁数情報が含まれるので、通常は意識不要です。

Q. 企業のMFAがプッシュ限定で、Google Authenticatorが許可されません。

A. 管理者ポリシーに従う必要があります。許可方式（OTPやFIDO）へ設計変更が可能か、IT管理者に相談してください。

移行作業のテンプレート（コピペ可）

サービス名	優先度	設定箇所	バックアップコード保管	担当	状態	備考
例：GitHub	高	Two-factor authentication → Authenticator app	済／未	山田	未／進行中／完了	FIDOキー併用
例：Google	高	2段階認証プロセス → 認証システムアプリ	済／未	山田	未／進行中／完了	回復電話番号確認
例：AWS	高	IAM / Identity Center → MFA	済／未	山田	未／進行中／完了	本番は時間外で実施

アンインストール前の最終チェック

• 全サービスでGoogle Authenticatorのコードが通るか“実ログイン”で確認。
• バックアップコードが正しく保管されているか再点検。
• Microsoft Authenticatorのクラウドバックアップを無効化（不要な復元データを残さない）。
• エントリが空であることを確認してから、Microsoft Authenticatorをアンインストール。

まとめ：計画と確認が最大のセーフティネット

Microsoft AuthenticatorからGoogle Authenticatorへの乗り換えは、一括移行機能がないがゆえに“面倒”に見えます。しかし、追加→確認→削除の順序と、バックアップコードの確実な保管、そして落ち着いた作業計画があれば、安全に・短時間で・確実に完了できます。個人でも組織でも、棚卸し→並行稼働→最終削除の三段階を意識し、今日から少しずつ進めていきましょう。

付録：実務メモ（覚えておくと捗る細則）

• 命名規則 … 例「Issuer｜Env｜Role」。「GitHub｜Work｜Owner」「AWS｜Prod｜Admin」など。
• グルーピング … 業務・個人・金融・趣味にグループ化。高優先アカウントは先に。
• 定期点検 … 年1回の「二段階認証棚卸し」で、不要サービスの登録削除と回復経路の更新。
• 時刻ズレ対策 … 旅行や機内モード後は時刻自動設定を再確認。ズレは失敗の元。
• 端末世代交代 … 新スマホ購入時は、今回と同様の“個別再登録”が基本。予備端末の用意やFIDOキーの併用で運用を強化。

作業手順（簡易版・貼り出し用）

1. Google Authenticatorをインストール。
2. 対象サービスへログイン→セキュリティ設定を開く。
3. 「認証アプリを追加／変更」→QR表示。
4. Google Authenticatorでスキャン→コード入力→有効化。
5. ログアウト→再ログインで新コードの動作確認。
6. Microsoft Authenticatorの同エントリを削除。
7. すべてのサービスで繰り返す。
8. バックアップコードを安全に保存。
9. 完全移行後、Microsoft Authenticatorのバックアップ無効化→アンインストール。

注意喚起：組織アカウントの特別ルール

職場・学校テナントのアカウントは、管理者ポリシー（条件付きアクセス、許可された多要素方式、デバイス要件）に縛られます。組織がMicrosoft Authenticatorのプッシュ承認を必須としている場合、個人判断でGoogle Authenticatorへ切り替えることはできません。まずはIT管理者に相談し、OTP（TOTP）方式の追加許可や、FIDO認証の導入など、組織方針に沿った方法で進めましょう。

このガイドでできること／できないこと

できること	できないこと
各サービスでの安全な二段階認証の再登録、移行計画の策定、ゼロダウンタイム移行の実践。	アプリ間でTOTPシークレットを自動移送すること、プッシュ承認の移植、管理者ポリシーの回避。

最後に

“一括移行なし”という制約は裏を返せば、各サービスがあなた本人を正しく再検証できるということです。少し手間でも、安全は作業順序と準備で確保できる。このガイドの手順とチェックリストを使い、確実な移行を実現してください。