Microsoft Entra External ID が正式リリースされて以降、Azure AD B2C からの移行や新規設計で「メールアドレスに頼らずユーザー名でログインさせたい」という相談が増えています。本記事では、External ID でメール不要のユーザー名＋パスワード認証がどこまで実現できるのか、Azure AD B2C との違いや現実的なアーキテクチャを整理します。
Entra External ID と Azure AD B2C の関係
External ID は「新世代の顧客 ID 基盤」
Microsoft Entra External ID は、顧客やパートナーなど組織外ユーザー向けの ID & アクセス管理（いわゆる CIAM）を担う新しいプラットフォームです。外部テナント内でユーザーフロー（サインアップ／サインインフロー）を定義し、
- メール＋パスワード
- メール＋ワンタイムパスコード（OTP）
- ソーシャルログイン（Google / Facebook / Apple など）
- OIDC / SAML / WS-Fed などのカスタム外部 IdP
といった認証方法を組み合わせてアプリ向けのサインイン体験を構成できるようになっています。
Azure AD B2C はレガシー方向へ
一方 Azure AD B2C は、長年使われてきた既存の顧客 ID ソリューションで、独自 UI やカスタムポリシー（Identity Experience Framework）など高い柔軟性を持っています。しかし 2025 年 5 月 1 日以降、新規顧客向けの購入はできないレガシー製品という位置づけになりました。
既に B2C テナントを持っている既存顧客は引き続き利用できますが、「これから CIAM を新規導入する」ケースでは、基本的に Entra External ID が第一候補になります。この前提を踏まえたうえで、「メール不要のユーザー名＋パスワードログイン」がどこまで可能かを見ていきます。
要件整理：「メールに依存しないユーザー名＋パスワード」とは
まず、よくある要望をもう少し言語化しておきます。
| 要件・イメージ | 具体的な意味合い |
|---|---|
| メールアドレスでログインさせたくない | サインイン画面でユーザーは ユーザー名だけ 入力し、メールアドレス欄はそもそも存在しない UI にしたい。 |
| ユーザー名＋パスワードのみでサインイン | アカウントの主識別子がユーザー名（ID）であり、「メールアドレス＝ログイン ID」ではない。 |
| メールアドレス自体を持たない利用者も許容したい | 学生アカウントや会員番号ベースなど、そもそもメールアドレスを持たない／配布しないユーザーも混在する前提。 |
| メールはあっても「連絡先」に過ぎない | メールアドレスを登録してもよいが、それは通知やパスワードリセットのための 連絡先属性 に過ぎず、ログイン ID とは独立して扱いたい。 |
この記事では、上記のような意味での「メールに依存しないユーザー名＋パスワード」を念頭に、External ID / B2C の仕様と選択肢を整理していきます。
現状仕様の整理と公式見解
Entra External ID のローカルアカウント
External ID の「ローカルアカウント」は、External テナントそのものに作成される顧客アカウントです。公式ドキュメントによると、ローカルアカウントのサインイン方法としては次のようなパターンが提供されています。
| サインイン方法 | ユーザーが入力するもの | 特徴 |
|---|---|---|
| メール＋パスワード | メールアドレス、パスワード | デフォルトのローカルアカウント。サインアップ時にメールを検証し、そのメールを使ってサインイン・パスワードリセットを行う。 |
| メール＋ワンタイムパスコード（OTP） | メールアドレス、メール宛てのワンタイムコード | パスワードを持たない方式。毎回メールに送信されるコードでサインインする。 |
| ソーシャルログイン / カスタム IdP | 外部 IdP 側の資格情報 | Facebook, Google, Apple, OIDC, SAML/WS-Fed などの外部 IdP にリダイレクトして認証。 |
ここで重要なのは、「ローカルアカウントはメールアドレスを前提としている」という点です。メール＋パスワード／メール＋OTP のいずれも、メールアドレスが主なサインイン識別子 になっています。
Username / alias サインイン（プレビュー）の限界
External ID には、「username or alias sign-in（プレビュー）」という機能も登場しています。これは、既にメール＋パスワードでサインインするローカルアカウントに対して、メールとは別の識別子（ユーザー名や会員番号など）を追加し、
- メールアドレス または ユーザー名
のどちらでもサインインできるようにする機能です。
ただし、この機能の前提はあくまで「メール＋パスワードのローカルアカウントが存在していること」であり、
- メールアドレス”なし”のユーザー
- メール属性を一切持たないデータモデル
を許容するものではありません。つまり、ユーザー体験としては「ユーザー名でサインインできる」ように見えても、ディレクトリ内部ではメールアドレスが必須属性であることは変わらない、という点に注意が必要です。
Azure AD B2C のローカルアカウント（ユーザー名サインイン）
Azure AD B2C のローカルアカウントは、サインイン方式として
- メール
- ユーザー名
- 電話番号
のいずれか（または組み合わせ）を選択できることが公式ドキュメントで説明されています。
| サインイン方式 | ログイン ID | メールとの関係 |
|---|---|---|
| メールサインイン | メールアドレス | メール自体がログイン ID になる。 |
| ユーザー名サインイン | ユーザー名（任意の文字列） | サインアップ時にメールも合わせて登録し、主にパスワードリセットで利用。ただしログイン ID はあくまでユーザー名。 |
| 電話番号サインイン | 電話番号 | パスワードレス方式。リカバリ用にメールを登録させる構成が推奨されている。 |
B2C の「ユーザー名サインイン」においても、サインアップ時にメールアドレスを登録しておくことが推奨されており、パスワードリセットなどの用途で利用されます。とはいえ、
- ユーザーがログインするときに入力するのはあくまで「ユーザー名」
- アプリ側の画面にもメール欄を表示せず、裏側の属性として保持するだけ
といった構成を取れるため、「メールに依存しないユーザー名サインイン」にかなり近い体験が実現できます。
Microsoft Q&A の公式回答のポイント
2025 年 9 月に公開された Microsoft Q&A のスレッドでは、まさに本記事と同じ質問（External ID で「メール不要のユーザー名＋パスワード」ログインは可能か？）が行われています。このスレッドに対する Microsoft モデレーターの回答を要約すると、以下のとおりです。
| 質問 | 回答要旨 |
|---|---|
| External ID でメールに依存しないユーザー名＋パスワードログインはできるか？ | 現時点の External ID の既定ユーザーフローでは、ユーザー名のみでのログインはサポートされておらず、ローカルアカウントはメールベースの識別子に強く結びついている。 |
| 代替案や推奨構成は？ | どうしてもユーザー名＋パスワード（メール不要）を実現したい場合は、Azure AD B2C を利用するのが現実的、という趣旨の案内。 |
| ロードマップは？ | External ID については、現時点ではロードマップに載っていない。要望があれば Azure フィードバックポータルに投稿し、今後のリリースノートやブログを確認してほしい、という案内。 |
この Q&A と公式ドキュメントを突き合わせると、External ID では依然として「ローカルアカウント＝メール前提」であり、username/alias サインインのプレビューを含めても、メール属性を完全に排除したユーザー名のみのローカルアカウントは実現できない、ということが分かります。
結論：External ID 単体では「メール不要のユーザー名＋パスワード」は実現できない
ここまでの整理を踏まえると、少なくとも 2025 年秋時点では次のようにまとめられます。
- Entra External ID のローカルアカウントは、メールアドレスを必須の識別子として前提としている。
- username/alias サインイン（プレビュー）を有効化しても、「メールを持たないユーザー」や「メール属性を完全に意味なしにしたい」要件は満たせない。
- Microsoft Q&A でも、External ID の既定ユーザーフローでのユーザー名のみログインは「非サポート」と明言されている。
したがって、「メール不要（メール非依存）のユーザー名＋パスワードログイン」をアイデンティティ基盤そのものに期待するのであれば、External ID 単体では実現できない、というのが現状の答えになります。
実務で取りうるアプローチ
とはいえ、要件が「絶対にメール属性を持ちたくない」のか、「ログイン画面ではユーザー名だけを見せたい」のかによって、現実的な設計は変わってきます。ここでは、代表的な設計パターンを 4 つに整理します。
| アプローチ | 概要 | 向いているケース |
|---|---|---|
| A. 既存 Azure AD B2C を継続利用 | B2C のユーザー名サインインを継続利用し、アプリは引き続き B2C に対して認証を行う。 | 既に B2C を本番利用しており、External ID への即時移行が必須ではない環境。 |
| B. External ID ＋ アプリ側マッピング | アプリ側で「ユーザー名 → メールアドレス」のマッピングを持ち、External ID にはメールでサインインさせる。ユーザーにはユーザー名だけを見せる。 | メール自体は持ってよく、あくまで「画面上ではユーザー名でログインさせたい」場合。 |
| C. 外部 IdP（B2C / 自前 IdP）を External ID にフェデレーション | ユーザー名ログインをサポートする別 IdP を立てて、External ID には OIDC / SAML IdP として接続する。 | 既に自前 IdP や B2C を運用しており、それを継続利用したい場合。 |
| D. External ID の「メール必須」を受け入れて設計を変更 | ビジネス面でメール必須を許容し、メール＋パスワード or メール＋OTP＋MFA を前提にシンプルに設計。 | 新規サービスや、ユーザーがメールアドレスを必ず持っている B2B/B2E に近いユースケース。 |
アプローチ A：既存の Azure AD B2C を使い続ける
既に Azure AD B2C を本番で利用していて、ユーザー名サインイン（あるいはカスタムポリシー）でメール非依存のログイン体験を構築済みであれば、External ID への即時移行にこだわらず、B2C を継続利用する選択肢があります。
- B2C は 2025 年 5 月以降、新規顧客向けの販売は終了しましたが、既存顧客は引き続き利用可能とされています。
- ユーザー名サインインに加え、カスタムポリシーでさらに柔軟な認証フローを構成できるため、「メールを一切使わないユーザー名＋パスワード」フローを構築している環境もあります。
一方で、長期的には External ID や他のサービスへの移行が必要になる可能性が高いため、
- 新規アプリは External ID 前提で設計しつつ、既存アプリは B2C のまま維持する
- 将来的にユーザーデータを External ID に移行しやすいよう、ユーザー属性スキーマやクレーム設計を見直しておく
といった「段階的移行」戦略を採るのが現実的です。
アプローチ B：External ID ＋ アプリ側マッピングで「疑似ユーザー名ログイン」
「メールアドレスを主識別子にしたくはないが、システム内部で保持するのは構わない」というケースでは、次のような構成がよく使われます。
- ユーザー登録時に、ユーザー名＋メールアドレス の両方をアプリ側データベースに保存する。
- External ID にはメールアドレスを使ってローカルアカウントを作成する。
- サインイン画面では「ユーザー名」と「パスワード」を入力させる。
- アプリは「ユーザー名 → メールアドレス」のマッピングを引き、External ID のサインイン画面に
login_hintとしてメールを渡す。 - External ID のサインイン画面では、既にメール欄が埋まった状態でユーザーにパスワードだけ入力させる（もしくはネイティブ認証 API で裏側からメール＋パスワードを投げる）。
| 観点 | 利点 | 注意点 |
|---|---|---|
| ユーザー体験 | 画面上は「ユーザー名＋パスワード」だけに見えるため、従来の B2C 的な UX を保ちやすい。 | External ID の標準 UI が一瞬見えるなど、完全にカスタム UI にはできないケースもある。 |
| ID モデル | アプリ内部では「ユーザー名」を主キーとして扱い、メールは単なる属性にできる。 | External ID では依然としてメールが識別子であるため、「メールを絶対に持ちたくない」要件は満たせない。 |
| 実装コスト | Rest API や MSAL を使った実装としては比較的シンプルで、現行アプリにも組み込みやすい。 | ユーザー名→メールのマッピングが壊れないよう、登録・変更のトランザクション設計に注意が必要。 |
このパターンは、「External ID の制約は受け入れるが、ユーザー体験としてはユーザー名ログインにできるだけ近づけたい」という場合に有力な折衷案になります。
アプローチ C：外部 IdP（B2C / 自前 IdP）を External ID にフェデレーション
External ID 自体にはカスタム OIDC / SAML IdP を接続できるため、
- ユーザー名ログインをサポートする自前 IdP（Keycloak など）
- 既存の Azure AD B2C テナント
を OIDC / SAML プロバイダーとして External ID のユーザーフローに接続することもできます。
この場合の概念構成は次のようになります。
| レイヤー | 役割 |
|---|---|
| アプリケーション | External ID を信頼し、External ID が発行するトークンを検証する。 |
| External ID | アプリ向けの front door 的な役割。 外部 IdP（B2C / 自前 IdP）を OIDC / SAML としてフェデレーションする。 |
| 外部 IdP | ユーザー名＋パスワードなど、独自の認証方式を提供する中核の IdP。 |
利点としては、
- 既存のユーザー名ログイン基盤をほぼそのまま流用できる
- External ID 側では B2B/B2E との統合や条件付きアクセスなどの機能を活用できる
といった点が挙げられます。一方で、IdP が二段構えになるため、運用やトラブルシュートが複雑になりがちです。長期的には External ID に集約する計画を描いたうえで、「移行期間中のブリッジ構成」として採用するのが現実的です。
アプローチ D：External ID の「メール必須」を受け入れて設計を変更
最後に、「そもそもビジネス的にメールアドレス必須でも問題ない」ケースでは、External ID の仕様に合わせて次のように割り切ってしまうのも有力です。
- サインイン方式は「メール＋パスワード」もしくは「メール＋OTP」にする。
- MFA（メール＋SMS など）を組み合わせてセキュリティを高める。
- ユーザー名はあくまで「表示名」として扱い、ログイン ID にはしない。
この割り切りにより、
- パスワードリセットや通知の設計がシンプルになる
- アカウント移行や統合が行いやすい
- 公式ドキュメントどおりの構成に近く、トラブル時の情報も得やすい
というメリットが得られます。「既存システムのユーザー名文化」を残したい誘惑はありますが、新サービスであればあえてメールを主識別子に揃えるのも長期運用の観点では悪くありません。
アプリ側マッピング方式（アプローチ B）の設計例
実務で最も採用しやすいのがアプローチ B なので、もう少し具体的な設計例を示します。
全体フローのイメージ
| ステップ | 処理内容 |
|---|---|
| 1. サインイン画面表示 | アプリ側で独自の「ユーザー名＋パスワード」画面を表示する（HTML / SPA / ネイティブアプリなど）。 |
| 2. ユーザー入力 | ユーザーがユーザー名とパスワードを入力して送信。 |
| 3. マッピング解決 | アプリサーバーが自前 DB から「ユーザー名 → メールアドレス」を取得する。見つからなければエラー。 |
| 4. External ID へリダイレクト | 取得したメールアドレスを login_hint として、External ID の /authorize エンドポイントにリダイレクト。 |
| 5. External ID サインイン | External ID の画面ではメール欄が自動入力された状態になり、ユーザーはパスワードのみ再入力するか、ネイティブ認証 API を用いて裏側でサインインを完結させる。 |
| 6. トークン受領 | External ID から ID トークン／アクセス トークンが返却され、アプリは通常どおりセッションを確立する。 |
この方式で重要になるのは、
- ユーザー名とメールアドレスの一貫性をどう担保するか
- 「メールアドレス変更」や「ユーザー名変更」の UX をどう設計するか
- ログイン試行回数やロックアウトの制御を External ID とアプリで二重に行わないようにするか
といった点です。
データモデルの例
アプリ側のユーザーテーブルは、例えば次のようなカラムを持たせておくと整理しやすくなります。
| カラム | 用途 | 備考 |
|---|---|---|
| user_id | アプリ内部の主キー | UUID など。External ID の sub とは切り離しておく。 |
| login_name | ユーザーが入力するユーザー名 | ユニーク制約を付与。表示名（display_name）とは別にしてもよい。 |
| External ID ローカルアカウントのメール | External ID テナント側とも一貫性を持たせる必要がある。 | |
| entra_object_id | External ID 側のユーザーオブジェクト ID | Graph API 経由の操作時に利用。 |
ユーザー登録・変更時には、
- アプリ側 DB の更新
- External ID のユーザー属性更新（メール、displayName など）
を一連の処理として設計し、どちらかだけが成功／失敗することがないようにするのがポイントです。
メリット・デメリットの整理
| 項目 | メリット | デメリット |
|---|---|---|
| ユーザー体験 | 従来の ID＋パスワードに近い画面構成を維持できる。 | External ID の UI との整合を取る必要があるため、完全に自由な UX にはしにくい。 |
| 移行容易性 | B2C のユーザー名ログインからの移行時に、ユーザー名を維持したまま External ID に移行しやすい。 | 既存ユーザーのメールアドレスをすべて収集・検証する必要がある場合、初期コストが高くなる。 |
| セキュリティ | 最終的な認証は External ID に任せるため、条件付きアクセスやリスクベース MFA などの恩恵を受けられる。 | ユーザー名→メールのマッピング情報が漏洩すると、フィッシングやなりすましの足掛かりになり得るため、DB の保護が重要。 |
メール非依存ログインを選ぶときの運用・セキュリティ注意点
「メールに依存しない」ログイン方式を志向すると、特に次のような運用・セキュリティ上の課題が出てきます。
パスワードリセット手段の確保
- メールを持たないユーザーがいる場合、本人確認＋パスワード変更 のプロセスをどう設計するかが最大の課題になります。
- 電話番号や SMS を使う場合、External ID の SMS 認証や SMS ベースのパスワードリセット機能を活用することも検討できます。
- それも難しい場合、コールセンターやサポート窓口での手動対応（本人確認書類の確認など）が必要になり、運用コストが一気に跳ね上がります。
アカウント列挙・総当たり攻撃への対策
- ユーザー名ログインでは、短い・推測しやすい ID が使われやすく、アカウント列挙攻撃のリスクが高まります。
- エラーメッセージを統一する（「ユーザー名またはパスワードが違います」）など、ID の存在有無が推測されにくいメッセージ設計が重要です。
- External ID 側のロックアウト・リスクベースサインイン・条件付きアクセスと、アプリ側のレート制限（IP ベース、ユーザー名ベース）を組み合わせるとより安全です。
MFA とデバイス情報の活用
- メール非依存ログインは、それ自体が危険というわけではありませんが、パスワードに一極集中するリスク が高まります。
- External ID の条件付きアクセス機能を使い、IP / デバイス / リスクレベルに応じて MFA を要求するルールを設けることで、総合的なリスクを抑えられます。
ロードマップと情報収集のコツ
「将来的に External ID がユーザー名のみのローカルアカウントをサポートするか？」は、多くの組織が気にしているポイントです。ただし前述のとおり、Microsoft Q&A の回答では「現時点ではロードマップに載っていない」とされています。
今後の動向を追うには、次のような情報源を定期的にチェックしておくとよいでしょう。
- Microsoft Learn の External ID ドキュメント（特に「外部テナントの認証方法」「ローカルアカウント」「username / alias sign-in」関連のページ）
- Microsoft Entra Blog（新機能発表や GA / プレビュー終了のお知らせ）
- Entra External ID のリリースノート
- Microsoft Q&A（External ID タグのついた質問）
- Azure フィードバック ポータル（同様の要望がどれくらい投票されているか）
特に、username/alias sign-in（プレビュー）が GA する際には仕様が変わる可能性もあるため、「メール必須がどこまで緩和されるか」を確認しておくとよいでしょう。
まとめ
本記事で整理した内容を、あらためてポイントだけまとめます。
- Entra External ID のローカルアカウントは、メールアドレスを前提とした設計であり、「メール不要のユーザー名＋パスワード認証」を基盤側だけで満たすことはできません。
- username/alias sign-in（プレビュー）は、メールベースのローカルアカウントに別名を紐づける機能であり、「メール属性を完全に排除したい」という要件は満たせません。
- Azure AD B2C はユーザー名サインインをサポートしており、カスタムポリシーを用いればメール非依存に近い構成も可能ですが、2025 年 5 月以降は新規顧客の購入ができないレガシー製品です。
- すでに B2C を利用している場合は、B2C 継続利用＋段階的な External ID への移行 を検討するのが現実的です。
- 新規に External ID を使う場合、「アプリ側でユーザー名→メールをマッピングし、External ID にはメールでサインインさせる」というワークアラウンドにより、見かけ上のユーザー名ログインを実現できます。
- メール非依存ログインを選ぶほど、パスワードリセットやアカウント列挙対策、MFA 設計などの運用・セキュリティ要件は厳しくなります。External ID の条件付きアクセスや SMS 認証なども活用して、全体としてのリスクを抑えることが重要です。
- External ID の機能追加は継続的に行われているため、公式ドキュメント・ブログ・フィードバック ポータルを定期的に確認し、要件と実装のギャップが縮まっていないかをウォッチしておくとよいでしょう。
結論として、現時点では Entra External ID 単体で「メールに依存しないユーザー名＋パスワードのみ」のログインを実現することはできません。この要件がどうしても譲れない場合は、
- 既存 Azure AD B2C を継続利用する
- 外部 IdP（自前 IdP など）を用意して External ID にフェデレーションする
といった構成を取りつつ、将来の External ID の機能拡張を待つ、というスタンスが現実的です。一方、「画面上の体験としてユーザー名ログインに見せたい」というレベルであれば、アプリ側マッピング方式などのワークアラウンドで十分にカバーできるため、自組織の要件と運用コストを見比べながら、最適なアプローチを選択してください。
コメント