Auth0におけるメールアドレス重複への対応：Non-Unique Emailsの活用

企業のDX推進に伴い、顧客ID統合基盤（CIAM）としてAuth0を採用するケースが急増しています。その際、既存システムからの移行において技術的ハードルとなるのが「メールアドレスの重複」です。
従来の認証基盤では、家族間でのメールアドレス共有や、用途別（ログイン用/連絡用）の重複登録が許容されてることが少なくありません。しかし、Auth0の標準仕様では「メールアドレスは一意にユーザーを識別できるもの」という前提があるため、そのままではスムーズなデータ移行が困難になります。

本コラムでは、この課題を解決するAuth0の機能「Non-Unique Emails※」に焦点を当て、設定方法からデータ移行、そして「パスワードリセット」を正しく機能させるための具体的な実装ステップを解説します。

※「Non-Unique Emails」機能は、執筆時点(2026年3月)においてEarly Access段階のものです。最新のサポート状況や仕様の詳細については、Auth0公式ドキュメントを併せてご確認ください。

なぜ「メールアドレス重複」が移行の壁になるのか

多くの認証システムでは、「会員番号」などを主キーとして管理しており、メールアドレスは単なる「属性情報」や「連絡先」として扱われるケースが頻繁に見られます。そのため、以下のような運用が許容されている場合があります。

家族間での共有: 1つのメールアドレスを家族（父、母、子など）で共有し、それぞれの会員番号で登録している。
用途別の使い分け: 1人のユーザーが「ログイン用」と「リカバリー用」として同じメールアドレスを複数のアカウントで登録している。

一方、Auth0を含むモダンな認証システムの多くは、セキュリティと利便性の観点から「メールアドレス＝個人を特定するID」として扱い、データベース内での一意性を求めるのが標準仕様となっています。この仕様ギャップにより、移行時に同一メールアドレスのユーザーを登録できない事象が発生します。

画面イメージ

「Non-Unique Emails」オプションを利用したメールアドレス重複の解決

このギャップを埋め、既存の運用を維持したままAuth0へ移行するための機能が、「Non-Unique Emails」オプションです。

Auth0の標準データベースでは、ログイン識別子として安全に利用するため、デフォルトで「Email」フィールドにユニーク制約（重複禁止）がかけられています。
「Non-Unique Emails」オプションをオンにすると、このデータベースレベルのユニーク制約が解除されます。これにより、1つのAuth0テナント内に「全く同じメールアドレスを持つ複数のユーザーレコード」をエラーなく共存させることが可能になります。
ただし、ユニーク制約を外すことは、システムがメールアドレスのみでユーザーを特定できなくなることを意味します。そのため、個々のユーザーを確実に見分けるための「主キー（Primary Identifier）」として、「ユーザー名（Username）」などの併用が必須となります。

【目指すデータ構造のイメージ】

Aさん：ユーザー名 123456789/ メール family@example.com
Bさん：ユーザー名 987654321 / メール family@example.com

このように、メールアドレスが同一でも「ユーザー名」を必須・一意とすることで、システムは明確に別のアカウントとして認識できるようになります。

画面イメージ

オプション有効化の手順

Auth0において「メールアドレスの重複」を許容する設定は、既存のデータベース接続（Database Connection）に対して後から変更することはできません。本機能を利用するには、「Non-Unique Emails」を有効にした新しいデータベース接続を新規作成する必要があります。

1. 新しいデータベース接続の作成

Auth0 Dashboardの左メニューから Authentication > Database を選択します。
[+ CREATE DB CONNECTION] ボタンをクリックし、新しい接続を作成します（例: Non-Unique-Emails-DB）。

2. 識別子と重複許可の設定

作成した接続の Settings タブを開き、以下のトグルスイッチを ON に設定します。

Requires Username
メールアドレスが重複するため、ユーザーを一意に特定するための「ユーザー名（Username）」の登録を必須とします。
Non-Unique Emails
システム全体のメールアドレス一意性チェックを解除し、重複登録を可能にします。

3. アプリケーションとの紐付け

Applications タブに移動します。
作成した新しいデータベース接続を利用するアプリケーション（SPAやWebアプリなど）を ON にして紐付けます。

【注意点】

本設定はデータベース接続の作成時に決定され、一度作成されると、後から「メールアドレス一意（Unique）」の設定に戻すことはできません。

ユーザーデータの移行・登録

既存基盤からエクスポートしたユーザーデータをAuth0へ移行する際、JSON構造の作り方が重要になります。
重複メールアドレスを持つユーザーを登録する場合、email の値には重複があっても問題ありませんが、username には必ず一意な値をセットします。

【ユーザーAの登録データ例（JSON）】

{
  "email": "family@example.com",
  "email_verified": true,
  "username": "123456789",
  "password": "hashed_password_value...",
  "connection": "Username-Password-Authentication"
}

【ユーザーBの登録データ例（JSON）】

{
  "email": "family@example.com",
  "email_verified": true,
  "username": "987654321",
  "password": "hashed_password_value...",
  "connection": "Username-Password-Authentication"
}

このように、usernameを一意な値に保つことで、Auth0は内部的に別々のアカウントとして登録・管理します。

オプション有効時のパスワードリセット挙動

最も懸念される「パスワードリセット」の挙動について解説します。
通常、パスワードリセット画面では「メールアドレス」の入力が求められますが、Non-Unique Emailsオプション有効時では、「ユーザー名」を入力してリクエストを送るフローに変化します。

画面表示の自動切り替え

Auth0の「New Universal Login」を使用している場合、Requires Usernameを有効にした時点で、ログイン画面およびパスワードリセット画面の入力ラベルが自動的に「Email」から「Username or Email」または「Username」へと変更されます。

リセットフローの実行

ユーザーがパスワードリセット画面で「ユーザー名（例: 123456789）」を入力すると、Auth0は以下のロジックで処理を行います。

入力された Username (123456789) に一致するアカウントを検索する。
そのアカウントに登録されている Email (family@example.com) を特定する。
特定されたメールアドレス宛に、パスワード再設定用URLを含んだメールを送信する。

ユーザー体験としては、「自分のIDを入力すると、いつものメールアドレスに再設定メールが届く」という自然なフローとなります。

※多要素認証の場合は、ユーザーネームに紐づいたメールアドレスへ認証用のコードが送信されます。

画面イメージ

導入時の考慮事項

既存ID（会員番号）の活用

usernameをユーザーに自由に決めさせると、それ自体が重複する（取り合いになる）リスクが生じます。既存基盤からの移行プロジェクトでは、「既存の会員番号」をそのままAuth0のusernameとして移行するのが最もトラブルが少なく、推奨されるアプローチです。

おわりに

本構成を採用することで、既存システムの「ログインID」と「メールアドレス」の関係性を維持したままデータ移行が可能になります。結果として、移行期間中に発生しがちな「メールアドレスを変更してください」といったユーザーへの案内や、複雑な重複チェック処理の実装を回避でき、開発・運用コストの削減につながります。

「メールアドレスの重複」は、セキュリティポリシーの厳格なAuth0への移行において障壁となりがちですが、「Non-Unique Emails」と「username」を正しく組み合わせることで、標準機能を活かしたスムーズな解決が可能です。

NTTドコモビジネス Xでは、こうしたAuth0の機能特性を理解し、お客様の既存システムの制約に合わせた最適な移行設計・実装支援を行っています。「自社の複雑なIDデータをどう移行すべきか悩んでいる」という方は、ぜひ一度ご相談ください。