Entra External ID 外部テナントでローカルアカウントのサインアップフローが見当たらない原因と解決策（Email with password）

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」こそが、あなたが探しているローカルアカウントのサインアップフローです。

参考リンク

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。