2026年 Google Accountのユーザー名変更後、ログインと復旧をどうテストする？

Google Accountのユーザー名変更を開発者向けにテストするなら、ユーザー識別にはIDトークンのsubを使い、メールアドレスは変更され得る属性として扱ってください。既存の認可が有効な場合、認可を取り消して再ログインした場合、自社サービスの復旧メールを受け取る場合を分けて検証します。

Sign in with Googleを実装し、メールアドレスでユーザーをひも付けている開発者向けです。
QA担当者は、アカウントが継続して同じ利用者に結び付くかを確認できます。
アカウント復旧を担当する人は、本人識別と連絡先メールの違いを押さえられます。

最終更新：2026年10月25日。Google Developers Blog、Google OpenID Connect文書、Google Accountヘルプの記載を確認しています。地域やアカウント資格による提供範囲は変わる可能性があるため、公開前にも公式情報を確認してください。

Google Accountのユーザー名変更を開発者向けにテストする指標

Google Developers Blogによると、米国のユーザーは2026年3月31日からGoogle Accountのユーザー名を変更でき、旧アドレスは同じ受信トレイに関連付けられたアドレスとして残ります。また、既存の認可が有効なら以前のメールアドレスが返る場合があり、認可を取り消して再ログインすると新しいアドレスが返る場合があります。これらは一律の返却保証ではありません。 Googleの開発者向け説明に沿い、認可状態ごとに実際の挙動を記録してください。

Google OpenID Connect文書では、subはユーザーの識別子として定義され、emailはメールアドレスを表すクレームです。したがって、データベースの主キーやログイン検索をメールアドレスだけに依存させないでください。IDトークンのクレーム定義を確認し、subとメールの保存先・用途を分けます。

メールアドレスと安定識別子の差

既存ユーザーをメールアドレスで検索し、その値を恒久的な本人識別子として扱う設計では、変更後のメールを新規ユーザーと誤認する可能性があります。反対に、変更前後のメールが同じ受信トレイに届くことを理由に、サービス側の連絡先情報まで自動で更新済みと見なすのも危険です。

Googleログインの主体はsubで判定し、メールアドレスはプロフィールまたは連絡先の属性として管理します。メールを変更する場合は、利用者が新しい宛先を管理できることを自社の手順で検証し、その結果と更新日時を記録してください。認証済みのメール情報をバックエンドで扱う際は、Googleのバックエンド認証ガイドも参照できます。

認可状態ごとのログイン継続性

まず、許可を得たテストアカウントで、既存の認可を維持したままログインします。受け取ったIDトークンの検証を通したうえで、sub、email、email_verified、自社の内部ユーザーID、最終的に開いたアカウントを記録します。画面に表示されたメールアドレスだけでは、正しいアカウントに接続した証拠になりません。

次に、同じテストアカウントで既存の認可を取り消し、再度ログインします。メールアドレスに差があっても、subに基づいて元の内部ユーザーとデータに結び付くかを確認してください。重複ユーザーが作られた場合は、登録処理がメールを主キーとしていないか、既存アカウント検索とメール更新の順序に問題がないかを調べます。

Googleの実際のIDトークンを確認できないテストでは、メール欄を書き換えたフィクスチャを使って自社の関連付け処理を検証できます。ただし、これは自社ロジックの試験です。Googleがその値を発行したことや、Googleログインが成功することの証明にはなりません。本番相当の認証経路では、トークンの署名・発行者・対象者などの検証を省略しないでください。

復旧メールの到達とアカウント一致

ログイン用のGoogle識別子、自社サービスに登録された連絡先メール、復旧メールの送信先は、別の項目として照合します。Google Accountの変更が、自社サービスの連絡先や復旧先まで書き換えるわけではありません。更新時には、本人確認の有無、変更前後の値、確認済み状態、更新後に復旧対象となる内部ユーザーを記録してください。

復旧テストでは、メールが受信できたかに加え、リンクの遷移先が自社の正しい環境か、トークンの使用後に正しい内部アカウントへ入れるかを確認します。旧アドレスがGoogle Accountの受信先として残っていることだけを根拠に、自社の復旧メールも届くと判断しないでください。テストデータに実在の個人情報を使わない方針は、プライバシーに関する案内と照らして整備できます。

リリース前の合否チェック

• [ ] ユーザー検索と一意制約がメールアドレスではなく、検証済みのsubを基準にしている
• [ ] 認可を維持したログインで、受信したクレームと内部ユーザーIDを記録する
• [ ] 認可を取り消して再ログインし、同じ利用者のアカウントが重複作成されないことを確認する
• [ ] メールアドレスの変更と、連絡先・復旧先の更新を別々の処理として検証する
• [ ] 復旧メールの宛先、到着、リンク先、復旧後の内部アカウントを確認する
• [ ] フィクスチャ試験、Googleでの実ログイン、メールの実受信を別々の証跡として記録する
• [ ] 実アカウントで変更を試せない場合は、未検証の範囲と理由をリリース記録に残す

Google Accountのユーザー名変更機能は、地域やアカウント資格によって利用できる範囲が異なる可能性があります。Google Accountヘルプで対象条件を確認し、実アカウントの変更ができない場合は、フィクスチャの合格を実ログインの検証済みとして扱わないでください。テスト項目の整理には確認用チェックリストも使えます。

よくある確認事項

既存認可で古いメールが返っても、ログインは失敗ですか？

必ずしも失敗ではありません。Googleの開発者向け説明では、既存の認可が有効なときに以前のメールアドレスが返る場合が示されています。判定の中心はメール文字列ではなく、検証済みトークンのsubが意図した内部ユーザーに結び付くかです。受け取った値と認可状態を一緒に記録してください。

メールアドレスを主キーにしている既存システムは何を直すべきですか？

GoogleのIDトークンに含まれるsubをユーザー識別に使い、メールは変更されるプロフィール情報として扱う設計に改めます。既存データの移行では、メール一致だけで異なるアカウントを自動統合しないでください。本人確認と既存アカウントとの関連付けを明示し、移行後に重複や誤結合がないかを確認します。

認可を取り消した後の再ログインで、どの値を比較しますか？

テスト前後のsub、メールアドレス、自社の内部ユーザーID、関連するデータを比較します。subに基づいて同じ内部アカウントに戻り、別の新規アカウントが作成されないことを確認してください。テスト用フィクスチャでメールだけを差し替えた結果は、Googleが返した値と区別して記録します。

旧メール宛ての復旧メールが届けば、復旧機能の確認は完了ですか？

到着だけでは完了しません。自社サービスに登録されている復旧先と、メール内のリンクが対象とする環境・アカウントを確認し、復旧後に正しい利用者の状態へ戻ることまで検証します。Google Account側の旧アドレスの扱いと、自社サービスの送信先設定は別のものとして評価してください。

復旧メールの到着確認だけが必要なら、受信先を分けて主メールアドレスをテストに使わない方法もあります。MSGTMPの一時メールは、自社サービスが送信した復旧メールの受信確認に利用できます。これはGoogleの本人識別やログイン動作を証明するものではありません。実際のユーザーアカウントに必要な長期の復旧先は、継続して管理できるメールアドレスを使ってください。

よくある質問