今回のアップデートの本質は、「メールアドレスが可変になった」点にある。メールアドレスを変更した後も、旧メールアドレスはエイリアス（分かりやすい別名）として残り、同じ受信トレイに届くため、送受信やログインが継続できる。つまり、ユーザーにとっては1つのアカウントだが、外部システムから見ると「複数のメールアドレスを持つ1ユーザー」という状態になる。

その問題は？

　企業側で想定できる問題は以下の2場面で発生する可能性がある。

メールアドレスでユーザーを識別している

　ログイン時に取得したメールアドレスをユーザーIDとして扱っている場合、次のような事象が起きる。

• ユーザー名を変更した後、別ユーザーとして認識される
• 既存データにアクセスできなくなる

　特に「Sign in with Google」（Googleアカウントの認証情報を使い、外部のWebサイトやアプリケーションに登録、ログインできるサービス）を使っている場合、認証プロトコルOAuth（Open Authorization）の状態によって挙動が変わる恐れがある。ユーザーがWebサイトやアプリケーションにログイン済みかつ、OAuthが有効なままであれば、そのままログインできる。ログアウトしたり、OAuthの有効期限が切れたりした場合はログインできなくなる。

メールとパスワードで認証を使っている

　メールとパスワードの組み合わせであれば、問題はないように思える。しかし、別の問題が潜んでいる恐れがある。旧メールでならログインできるものの、新メールでSign in with Googleを使ってログインすると別アカウントとして扱われる可能性があるのだ。結果として、「同一人物の二重アカウント」が発生する恐れがある。

問題が起こらないようにするためには？

Subject IDを主識別子に使う

　Subject IDは、Sign in with GoogleのIDトークンに含まれる固定識別子だ。Google側で付与される不変IDであり、ユーザー名を変更しても影響を受けない。

メールベースでアカウントを復旧できるようにする

　Googleは旧メールアドレスをエイリアスとして残している。復旧を希望した場合、旧メールアドレスにメールを送信できる。ユーザーが復旧用のメールを旧メールアドレスで受信すれば、Googleは同一アカウントと認識する。

業務で使っているWebサイトやアプリケーションのメールアドレスを更新できるようにする

　ユーザー側がSign in with GoogleでログインしたいWebサイトやアプリケーションに登録しているメールアドレスを古いものから新しいものに書き換えできるようにしておく。その後、Sign in with Googleに新しいメールアドレスでログインすれば、Googleはユーザーを同一アカウントとして認識する。

情シスがやるべきことは？

　この変更が示しているのは、「認証の前提が変わった」という事実だ。メールアドレスは“連絡手段”であって“識別子”ではない。そこで、Googleなど外部のIDと社内で利用しているサービスのIDをひも付けるための設計を見直すことが大切だ。