Microsoft Entra External ID（External tenant／外部テナント）を評価していて「ローカル アカウント用のサインアップ フローが見当たらない」と迷うことがあります。結論から言うと、ユーザー フロー作成画面に出てくる「Email with password（メール＋パスワード）」が、外部テナント文脈での“ローカル アカウント”そのものです。
結論：External tenantの「ローカル アカウント」は“テナント内で完結するID”
Microsoft Entra External ID（顧客向けの外部テナント／CIAM）では、ドキュメント上で「local account（ローカル アカウント）」という言葉が出てきます。しかし多くの人が想像する “Workforce（従業員）テナントのローカルユーザー” とは意味が異なります。
外部テナントでのローカル アカウントは、メール アドレスをサインイン名として、テナント内に資格情報（パスワード もしくは ワンタイム パスコード）を保持する方式を指します。サインアップ（自己登録）でユーザー オブジェクトがディレクトリに作成され、その後はそのユーザーとしてサインインできる、というのが基本形です。
そのため、ポータルのユーザー フロー作成時に表示される 「Email with password（パスワード付き電子メール）」 は、まさに「ローカル アカウント」の実体です。別に「ローカル アカウント専用の設定メニュー」や「内部ユーザー向けの作成画面」が隠れているわけではありません。
混乱の原因：「local account」という言葉がテナントの種類で意味が変わる
同じ Microsoft Entra の管理画面でも、Workforce（従業員）テナントとExternal（顧客）テナントでは設計の前提が異なります。ここが噛み合っていないと、「ドキュメントにあるはずの項目が無い」と感じやすくなります。
| 観点 | Workforce（従業員）テナント | External tenant（顧客向け 外部テナント） |
|---|---|---|
| 主な対象 | 社員・社内システム・業務SaaS | 顧客（B2C）・取引先（B2B顧客）・会員 |
| 「ローカル アカウント」の連想 | 管理者が作成する社内ユーザー／組織のアカウント | メール＋パスワード（またはメールOTP）で自己登録し、外部テナント内に保存される非フェデレーションID |
| サインアップ体験の作り方 | （用途により）招待、既存アカウント、セルフサービスサインアップなど | ユーザー フロー（サインアップ／サインイン、パスワード リセット等）で作る |
| よくある落とし穴 | 「顧客向けの自己登録UI」を想定してしまう | 「社内ローカルユーザーの作成画面」を探してしまう |
つまり、External tenant の世界では「ローカル＝社内」ではなく、「ローカル＝この外部テナントの中で完結して管理される」という意味合いです。
画面上の呼び名を揃える：用語・UI対応表
本件は、英語UI／日本語UIの表記差、そして「外部テナント＝外部ユーザー」という前提が重なって混乱が増幅します。まずは、管理センター上で“どの文字列が何を指すのか”を固定しましょう。
| ドキュメント／概念 | 管理センターで見える表記（例） | 意味 |
|---|---|---|
| Local account（ローカル アカウント） | Email accounts（電子メール アカウント） | 外部テナント内で資格情報を保持する認証方式の大枠 |
| メール＋パスワード | Email with password（パスワード付き電子メール） | メールをIDとして登録し、パスワードでサインインする |
| メールOTP（パスワードレス） | Email one-time passcode（電子メール ワンタイム パスコード） | サインインのたびにメールで一時コードを受け取ってサインインする |
| 外部IdP（連携ログイン） | Google / Facebook / Apple / OIDC / SAML/WS-Fed など | 外部プロバイダーで認証し、外部テナントが検証してトークンを発行する |
「ローカル アカウント」という単語に引っ張られて“別の設定画面”を探すより、まずユーザー フローの ID プロバイダーにある「Email accounts」配下を見に行くのが最短です。
ポータル上で「Email with password」しか出てこないときに確認すべきこと
ユーザー フロー作成時の「ID プロバイダー」に、「Email with password（パスワード付き電子メール）」しか見えないことがあります。これは仕様として自然で、次のどちらか（または両方）が原因になりがちです。
- まだ外部 IdP（Google / Facebook / Apple / OIDC / SAML など）を追加していないため、選択肢が「電子メール アカウント」だけになっている
- メール ワンタイム パスコード（Email one-time passcode）をテナント レベルで有効化していないため、「電子メール ワンタイム パスコード」の選択肢が出てこない
Microsoft Learn の手順でも、ユーザー フロー作成時の「電子メール アカウント」には、「パスワード付き電子メール」と「電子メール ワンタイム パスコード」の2系統があることが明記されています。
実務で迷子になりやすい：外部テナントに切り替わっていない問題
もうひとつ多いのが「そもそも管理センターで外部テナントに切り替わっていない」ケースです。複数テナントを扱う運用では、意図せず Workforce 側を見ていて、画面構成やメニューが一致しない…ということが起きます。
| チェック項目 | 見る場所（目安） | 期待する状態 |
|---|---|---|
| テナント切り替え | Microsoft Entra 管理センター上部の設定（ディレクトリ＋サブスクリプション） | 操作対象が External tenant（外部テナント）になっている |
| ユーザー フローの場所 | Entra ID > External Identities > ユーザー フロー | サインアップ／サインイン用のユーザー フローを作成できる |
外部テナントのユーザー フロー作成手順としても、まず「ディレクトリ＋サブスクリプション」で外部テナントへ切り替えることが前提に置かれています。
設定手順：外部テナントで「メール＋パスワード」のサインアップ フローを作る
「ローカル アカウントのサインアップ フロー」を探している場合、実際にやることはユーザー フローを1本作って、アプリに割り当てることです。画面名は更新されることがありますが、考え方は変わりません。
ユーザー フローを作成する
- Microsoft Entra 管理センターにサインインし、対象テナントが External tenant になっていることを確認します。
- Entra ID > External Identities > ユーザー フロー を開き、「新しいユーザー フロー」を選びます。
- 作成画面の「ID プロバイダー」で「電子メール アカウント」を有効にし、「パスワード付き電子メール（Email with password）」を選択します。
- サインアップ時に取得したいユーザー属性（表示名、姓、名など）を必要最小限で選びます。
- 保存してユーザー フローを作成します。
この時点で「Email with password」＝ローカル アカウントが成立します。
アプリケーションをユーザー フローに追加する（ここが抜けると「動かない」）
ユーザー フローは作っただけでは終わりません。外部テナントに登録しているアプリケーションにユーザー フローを関連付けることで、アプリにアクセスするユーザー向けのサインアップ／サインイン エクスペリエンスが“アクティブ化”されます。
手順の目安は次の通りです（管理センターの更新で表示名が変わる場合があります）。
- ユーザー フロー一覧から対象フローを開きます。
- 左メニューの「使用」配下にある「アプリケーション」を開きます。
- 「アプリケーションの追加」を選び、対象アプリを選択して関連付けます。
重要な制約として、アプリケーションは1つのユーザー フローにしか割り当てられない一方で、ユーザー フローは複数のアプリケーションで使い回せる、という整理が示されています。設計段階で「アプリごとに体験を変えるのか／共通化するのか」を決めておくと後戻りが減ります。
最短の動作確認：「ユーザー フローの実行」でサインアップ体験をシミュレーション
外部テナントには、ユーザー フローを実際に動かして確認できる「ユーザー フローの実行」機能があります。アプリケーションに紐づくユーザー フローを選び、実行してサインアップ／サインイン情報を入力することで、期待通りの画面になるかを確認できます。
- 前提として、リダイレクト URI を持つアプリケーションがユーザー フローに関連付けられている必要があります。
- まだ追加していない場合は、その場でアプリを追加でき、反映まで少し時間がかかる場合がある、と案内されています。
- テスト用の URL（OpenID 構成 URL やユーザー フロー エンドポイント URL）も画面に表示され、コピーして検証できます。
「Email with password」が“外部ユーザー用”に見えてしまうポイントを分解する
質問でよくあるのが「Email with password は外部ユーザー用アカウントに見える。だからローカルじゃないのでは？」という疑問です。ここは言葉の整理をすると腑に落ちます。
| 誤解しやすい点 | 実際に起きていること | どう考えるとスッキリするか |
|---|---|---|
| 外部テナントだから「外部ユーザー」しかいない | はい、その通りです。外部テナントは顧客向けで、基本的にユーザーは外部の人です。 | External tenant の文脈では「外部ユーザー」と「ローカルアカウント」は両立します（外部の人が、テナント内にローカルIDを作る）。 |
| 「ローカル＝社内ユーザー」だと思ってしまう | それは Workforce の発想です。 | External tenant の「ローカル」は「このテナントで資格情報を保持する」という意味です。 |
| Microsoft アカウントやSNS連携と区別がつかない | Email with password はフェデレーションではありません。 | 外部 IdP 連携ではなく、外部テナントが認証してトークンを発行します。 |
要するに、External tenant の「ローカル アカウント」は“顧客が作るローカルID”です。Workforce の「管理者が作る内部ユーザー」とは文脈が違うだけで、どちらも「テナント内のディレクトリにユーザーが作られる」という点は共通しています。
「Email one-time passcode」が必要なら、テナント側の有効化も見る
もし要件として「パスワードを持たせたくない」「パスワード運用を避けたい」などがある場合、外部テナントでは メールのワンタイム パスコード（Email one-time passcode） をローカル アカウントの選択肢として使えます。
ただし、ユーザー フロー作成時に選択できるようにするには、テナント レベルで Email one-time passcode を有効化しておく必要があります。手順としては「外部 ID > All Identity Providers > Email One-time-passcode」付近の設定が案内されています。
| 症状 | 原因の候補 | 対処の方向性 |
|---|---|---|
| ユーザー フローで「Email one-time passcode」が出ない | Email one-time passcode が未有効化 | 外部 ID の ID プロバイダー設定で有効化してから、ユーザー フローを作成・更新する |
| ソーシャルログイン（Google等）が出ない | そのIdPをまだ追加していない | 先に IdP の追加（アプリ登録・クライアントID/シークレット設定）を行い、ユーザー フローで選択する |
| 「ローカル アカウント」っぽい項目が無い | 用語の取り違え | External tenant では Email with password / Email OTP がローカル アカウントに該当する、と理解して設計する |
外部テナントで「メール＋パスワード」を選ぶときの設計ポイント
「Email with password」を採用すると決めたら、実運用で差が出るポイントを先に整理しておくと、評価がスムーズになります。
サインアップで取得する属性は“最小”から始める
最初から項目を増やすと離脱が増えます。まずは必須のメール＋パスワード（またはOTP）と、業務上どうしても必要な属性（例：表示名、国/地域、同意フラグなど）に絞り、足りなくなったら段階的に追加するのが現実的です。
カスタム属性を使うなら「b2c-extensions-app」を理解しておく
外部テナントで拡張属性（カスタム ユーザー属性）を使うと、内部的に b2c-extensions-app というアプリが見える場合があります。これは外部テナントの拡張属性を格納するために自動作成されるもので、削除しないように案内されています。
パスワード リセットは「ユーザー体験」と「サポート工数」を左右する
メール＋パスワードの方式では、パスワード リセットが必ず課題になります。外部テナントでは、パスワードのリセット時にワンタイム パスコードを送る仕組みが説明されており、ユーザー フローでリセット導線の表示やカスタマイズも可能です。
評価フェーズでは、次を最低限テストしておくと後戻りが減ります。
- 新規サインアップ時のメール検証（OTP受信〜完了まで）
- パスワードを忘れた時の復旧（リセット導線、迷わないUI）
- モバイル端末での入力ストレス（長いパスワード、コピペ制限）
B2B顧客を想定するなら「企業SSO」をどこまでやるか決める
B2B の顧客が「自社のEntra（職場アカウント）でそのままSSOしたい」と求めることは珍しくありません。外部テナントのユーザー フロー作成画面には「Microsoft Entra ID サインアップ オプションは使用できない」という注記があり、職場アカウントをそのまま“サインアップ手段”として提供する設計とは別物です。必要なら、カスタム OIDC / SAML/WS-Fed などのフェデレーションで“企業IdP”を追加し、ユーザー フローで選択できるようにする方向で検討します。
方式選定の目安：ローカル（メール）と外部IdPの使い分け
| 方式 | ユーザー体験 | 運用の特徴 | 向いているケース |
|---|---|---|---|
| Email with password（パスワード付きメール） | 一般的。多くのユーザーが慣れている | パスワード管理・リセット対応が必要 | 会員サイト、B2C、パスワード前提の業務SaaS |
| Email one-time passcode（メールOTP） | パスワード不要で軽い。端末変更でも継続しやすい | メール到達率・遅延がUXに直結。迷惑メール対策が重要 | ライトな会員登録、短期利用、パスワードレスを重視 |
| ソーシャル（Google / Apple等） | 入力が少なく高速。離脱が減ることが多い | 外部IdPの規約・仕様変更の影響を受ける | コンシューマー向け、登録のハードルを下げたい |
| 企業IdP（OIDC / SAML/WS-Fed） | 企業ユーザーにとってはSSOで最適 | IdPごとの調整が必要。テナント間の契約・運用が絡む | 大口B2B顧客、既存IdP連携が必須 |
よくある質問
「ローカル アカウントのサインアップ フロー」が別メニューに存在すると思っていました
External tenant では、サインアップ体験は基本的に「ユーザー フロー」で定義します。ID プロバイダーとして「電子メール アカウント」を選び、その中の「Email with password」または「Email one-time passcode」を選んだ時点で、それがローカル アカウントのサインアップになります。
「Email with password」は“外部ユーザー用”だから、ローカルではないのでは？
外部テナントにおける「ローカル」は「社内」ではなく「テナント内で資格情報を保持する」という意味です。Email with password はフェデレーションではなく、外部テナント側で認証してユーザーをディレクトリに作成するため、ローカル アカウントに該当します。
ユーザー フローを作ったのに、サインアップ画面が確認できません
多くの場合、アプリケーションがユーザー フローに関連付いていないか、リダイレクト URI のあるアプリが紐づいていないのが原因です。ユーザー フローにアプリを追加し、必要なら「ユーザー フローの実行」でテストすると切り分けが早くなります。
将来、サインイン方法を変更したら既存ユーザーはどうなりますか？
たとえばメール＋パスワードからメールOTPへ変更すると、新規ユーザーのサインイン方法は変わますが、既存ユーザーは元の方式を引き続き求められる、という整理が示されています。方式変更は“新規のみ”に効くことがあるため、評価時点で将来の移行方針も検討しておくと安心です。
外部テナントでの「自己登録」は、従業員テナントのセルフサービス サインアップと同じですか？
同じ「サインアップ」という言葉でも、外部テナント向けユーザー フローと、従業員テナント向けのセルフサービス サインアップは別物として説明されています。ドキュメントでも外部テナント向け手順であることが明記され、従業員テナント向けは別記事が案内されています。
まとめ：探している機能は「Email with password」に集約されている
Microsoft Entra External ID（External tenant）で「ローカル アカウント用のサインアップ フローが見当たらない」と感じたら、まず用語の前提を疑ってみてください。External tenant におけるローカル アカウントは、メール＋パスワード（またはメールOTP）で自己登録し、テナント内に作られるユーザーのことです。
画面上に別の“ローカル アカウント専用メニュー”は基本的に存在しません。ユーザー フローの「Email with password」こそが、あなたが探しているローカル アカウントのサインアップ フローです。
参考リンク
- Microsoft Learn：外部テナント アプリのサインアップおよびサインイン ユーザー フローを作成する
- Microsoft Learn：外部テナントのための ID プロバイダー（メール＋パスワード／メールOTP／ソーシャル／OIDC／SAML）
- Microsoft Learn：アプリケーションをユーザー フローに追加する
- Microsoft Learn：サインアップとサインインのユーザー フローをテストする（ユーザー フローの実行）
- Microsoft Q&A：External tenant の「Email with password」が local account に該当するという整理
コメント