過去数十年にわたり、数多くのシステムがさまざまな人によって作られ運用されてきましたが、それぞれのユーザーがログインして使うシステムを作る上で、識別子をどう定義するべきかのベストプラクティスはまだ広まっていないように感じます。
識別子（Identifier）つまり、ユーザー同士を見分けるのにどの属性を使うべきでしょうか。ログインの時にパスワードとともに入力する「ユーザーID」はどうでしょうか。
下記の記事では、「識別子」とログイン時の「ユーザーID」、そして「ユーザー名」を分けて管理するべきで、それはなぜなのかという明快な主張がなされています。主に企業内システムを念頭に置いて記述されていますが、B2Cのサービスでも基本的に同様です。
筆者のPrithvi Poreddyさんの許可を得まして、翻訳を公開します。
「メールアドレスを識別子として扱うのをやめよう」
（Prithvi Poreddy、2025年11月9日）
社員が退職します。18か月後、その社員が使っていたメールアドレスが新入社員に再割り当てされました。
数日以内に、次の2つのことが起こり始めます。
まず1つ目。IT部門が存在を把握していなかったサービス向けのパスワードリセットメールが届きます。以前の社員が会社のメールアドレスで登録していたものです。
次に、そしてより懸念すべきこととして、プロビジョニング済みのSaaSアプリケーションにおいて、新入社員のメールアドレスが、完全に削除されず「無効化」状態で残っていたアカウントに一致します。SSOで認証すると、Salesforce、Workday、Slackのようなシステムで、前任者のロール、権限、データアクセスを継承してしまいます。
これらは特殊なケースではありません。メールアドレスを「再利用可能な識別子」として扱うことの、予測可能な帰結です。このシナリオは、不適切な識別子戦略から生じる、3つのより広範な問題を浮き彫りにします。
jsmith、jsmith1、jsmith2のような予測可能なユーザー名は、アカウント列挙攻撃を可能にします。攻撃者は警告を発生させることなく有効なアカウントを発見でき、クレデンシャルスタッフィングや標的型フィッシングが容易になります。
Jane Doeが結婚してJane Smithになったとします。本来は単純な属性更新で済むはずの変更が、40ものシステムにまたがる3週間がかりのプロジェクトになります。名前が変わるたびに、技術的負債が積みあがつていきます。
コンプライアンスへの影響を考えてください。監査人が「退職者が24時間以内にすべてのアクセスを失っている」ことの証明を求めてきたとします。IdPの無効化タイムスタンプは提示できても、なぜログ上に退職者がデータにアクセスした記録が残っているか説明できません。原因は、18か月前に再利用されたメールアドレスなのです。
何が変わったのか
20年前は、ckeyやjsmithのような名前ベースの識別子や再利用可能なメールアドレスは妥当な選択でした。メールは主にコミュニケーションのためのもので、認証には使われていませんでした。すべてのシステムはファイアウォールの内側で動いていました。アイデンティティシステムが管理するユーザー数も数百人程度でした。
しかし、今日の現実は根本的に異なります。メールアドレスは多数の外部システムにまたがるセキュリティ認証情報として機能します。ユーザーは日常業務の中で20以上のSaaSアプリケーションに認証します。プライバシー規制は、システム識別子における個人特定情報の扱いを問題視します。監査フレームワークは、完全な追跡可能性を要求します。退職後何年経っていても、あらゆるアクセス判断を特定の人物にまで遡及できなければなりません。
文脈は変わりました。識別子は変わっていません。
識別子の考え方：
「ユーザー名」を単一のものとして考えるのをやめましょう。必要なのは、明確に分離された3つの異なるレイヤーです。
システム識別子（不変）
コンピュータが内部で使用するもの。UUID、A123456、固定の従業員番号など。ユーザーが目にすることはありません。アプリケーションが参照し、データベースが外部キーとして使い、監査ログもこれに紐づきます。これはユーザーインターフェースではなく、配管（インフラ）です。
認証用クレデンシャル（可変）
ユーザーがログイン時に入力するもの。メール、バッジ番号、任意のユニークなユーザー名、パスキーなど。これはレイヤー1にマッピングされるため、変更しても何も壊しません。認証はユーザー体験の関心事、アイデンティティはデータ完全性の関心事です。
表示名（人が読める名前）
レポートやUIに表示される名前。「Jane Smithがこの申請を提出しました。」当人の名前が変われば変わって構いません。表示ロジックであり、アイデンティティロジックではありません。
ほとんどの組織はこの3つのレイヤーを混同しています。それが識別子問題の主因です。
アイデンティティ vs. 属性：根本的な転換
アイデンティティは不変、その他すべては可変の属性だと考えてください。
Jane Doeが結婚してJane Smithになっても、彼女のアイデンティティ（A123456）は変わらず、属性（名前、場合によってはメール）が更新されます。彼女のアイデンティティを参照するすべてのシステムは最新の属性を自動的に反映します。
彼女が企業グループ内でCompanyAからCompanyBへ異動しても、同じアイデンティティのまま、法人、コストセンター、上長といった属性が変わるだけです。孤立アカウントは発生せず、監査証跡も壊れません。
一人に一つのアイデンティティ、多くの変わりうる属性。法人、雇用ステータス、部署は属性であり、アイデンティティの一部ではありません。アイデンティティは動かない錨です。
ベストプラクティス
不変のシステム識別子を確立する
システム生成の意味を持たない識別子を選びましょう。接頭辞付きの連番（A123456）、UUID、あるいは本当に恒久的であれば人事システムの恒久従業員番号でも結構です。
識別子に人物の情報をエンコードしないでください。ロール、部門、雇用形態は変わりうる属性です。識別子は恒久的な配管（インフラ）です。
既存システムについては、基準となる参照項目（人事システムの従業員ID、ディレクトリのObjectGUID、アイデンティティシステムの内部ID）を特定し、すべてをそこへマッピングします。
メールアドレスを再利用しない
退職者が出たら、そのアドレスを無効化し、永久に再利用不可としてマークします。作成時の衝突は明確なルールで処理します：firstname.lastname、次はfirstname.lastname2など。
一時的に不格好なjohn.smith3のほうが、john.smithを再利用するセキュリティリスクよりもましです。
例外：同一人物が12〜18か月以内に復帰する場合は再利用ではなく再活性化します。元のアイデンティティとメールを復元しましょう。
ログインとアイデンティティを分離する
ユーザーはメールアドレス、バッジ番号、任意のユーザー名、パスキーなどで認証します。すべてが不変の識別子にマップされます。この分離により、認証方法の変更が各システムのアイデンティティ参照を壊すことはありません。
退職者のアイデンティティを「墓碑化（無効化）」する
削除ではなく無効化します。アイデンティティレコードと監査履歴を保持します。識別子やメールアドレスを再利用しないでください。数年後でも「誰がいつ何にアクセスしたか」に答えられなければなりません。削除や再利用されたアイデンティティではそれが不可能になります。
墓碑化し、再循環はしない。
やってはいけないこと
システム識別子に名前を使わない
結婚、法的変更、文化的慣習により名前は変わります。大規模な組織では名前の衝突（同姓同名）も起きます。名前は個人情報を含みます。名前変更のたびに技術的負債が積み上がります。
メールアドレスをデータベースの主キーにしない
名前変更、ドメイン変更、衝突解決のためにメールアドレスは変更が必要になります。メールアドレスを識別子にすると、変更時にすべてのシステムで更新が必要になります。メールアドレスが単なる属性であれば、変更は単なる更新で済みます。
社内異動で新しいアイデンティティを作らない
部門Aから部門Bへ移ったとしても、同じ人物は同じアイデンティティです。部門は属性であり、アイデンティティの境界ではありません。新しいアイデンティティを作ると監査証跡が破綻し、ユーザーが同じ雇用主に対して複数のクレデンシャルを管理する羽目になります。
識別子に意味を埋め込まない
C123456は契約社員、E123456は正社員、といった設計は、一見論理的でも契約社員が正社員になった途端に破綻します。関係性が変わっても識別子は変えるべきではありません。
自組織への重要な問い
アクセス可否に関するすべての判断を全システム横断で特定の人物へと追跡できますか？社員が名前を変更したらどうなりますか？メールアドレス再利用の現行ポリシーは？一人の人物に対していくつの識別子タイプが存在しますか？部門や法人をまたいで異動した場合、新しいアイデンティティを付与していますか？
これらに素早く一貫して答えられないなら、そこが出発点です。
今後の進め方
新しいアイデンティティの正しいパターンを今すぐ確立しましょう。既存の識別子を正準化した源泉にマッピングします。自然なトリガーイベント（名前変更、異動、アプリケーションのアップグレード）に合わせて段階的に移行します。
正準マッピングがあり、新しいアイデンティティが新しいパターンに従っていれば、混在環境は管理可能です。完璧を求めて前進を止めないでください。
成功する組織は、システムが清廉潔白な組織ではありません。混乱を認め、前進の道筋を作り、時間をかけて一貫して実行する組織です。
次回の記事では、このモデルを複雑にする現実的課題—多くのSaaSプラットフォームが識別子としてメールアドレスの使用を強制し、それを変えられない—に取り組みます。
あなたの組織ではどんな識別子の課題に直面していますか？長年のうちにいくつの識別子タイプが積み重なってきましたか？ぜひ経験を聞かせてください。
いかがだったでしょうか。歴史的経緯を抜きにして考えれば、ログイン時のIDにはユニーク属性かつ、ユーザーが覚えやすいメールアドレスなどを使い、内部の識別子としては別途不変なユニーク属性を持っておく、というのは筋が通っていると思います。
なお、ログイン時のIDにバッジ番号などを使う案が書かれていますが、SaaSによってはメールアドレスでのログインを強制するケースがあるので、ちょっと微妙かなと思います。もちろん企業システムにおいてはすべてSSOしているのが一番だろう、そうでなければサービスごとにパスワードは違うはずでそのためにはパスワードマネージャーを導入しているはずだから別にIDが何だろうと記録されているはずでは、という理想論はありますが、実際にはなかなか難しいと思いますので。
そして気になる、SaaSプラットフォームや多くのライブラリー類が、この3種類の属性を区別していない点について、次の記事が出ましたら、また翻訳したいと思います。