「電話番号＋SMS ワンタイムパスコードだけでサインアップ／サインイン」を Microsoft Entra External ID で実現できるか――2025年11月時点の最新仕様に基づき、できること／できないこと、実現パターン、設計の勘所を整理しました。ユーザーフローに Phone OTP が出てこない理由、UI カスタマイズの限界、現実的な PoC 手順と代替案まで、実装者目線で具体的に解説します。
結論（2025年11月時点の要点）
- External ID（顧客テナント）では、ローカルアカウントの主要素として選べるのは「メール＋パスワード」または「メール＋ワンタイムパスコード（Email OTP）」です。電話番号＋SMS OTP を主要素にした自己登録／サインインは未提供です。
- SMS は External ID で多要素認証（MFA）の第二要素として利用可能です。2025年10月以降はパスワードリセット（SSPR）での SMS 利用も公開プレビューとしてアナウンスされており、回復手段としての活用が視野に入ります。
- ワークフォース（社内）テナントでは「SMS サインイン（パスワードレス）」が構成可能ですが、これは CIAM（External ID）の自己登録フローとは別物で、顧客向けアプリの「電話番号だけでの新規登録・即ログイン」をそのまま満たすものではありません。
- サインアップ／サインイン画面の UI は、External ID のCompany Branding と Custom CSS、Branding Theme（アプリ単位のテーマ）で大幅に見た目を変えられます。ただし、独自 HTML を完全に差し替える（Custom page URI で置換）ことは不可です。
- 「電話番号だけの UX」が必須なら、実現路線はAzure AD B2C（従来）での Phone サインアップ／サインイン、または外部 IdP（Auth0 / Cognito など）を OIDC/SAML で連携する Bring Your Own Identity の2択が現実的です。B2C は新規購入制限がある一方で少なくとも 2030 年までは継続サポートが示されています。
なぜユーザーフローに「Phone one‑time passcode」が出てこないのか
External ID（顧客テナント）の「Sign up & sign‑in」ユーザーフローにおけるローカル ID は、現状「Email（パスワード／OTP）」のみです。SMS ベースのサインインは Microsoft Entra ID 全体の「認証方法」では存在しますが、外部テナントの自己登録用の主要素としては未統合です。結果として、管理センターで SMS を有効化しても、External ID のユーザーフロー作成画面に「Phone OTP」が現れません。
要件別：実現可否と現実解
| 要件 | External ID 単体の可否 | 現実解・代替策 | 補足 |
|---|---|---|---|
| 既存ユーザーが電話番号＋SMS OTP だけでログイン | ×（主要素としては不可） | ワークフォースの「SMS サインイン」は可。顧客向けは Email 主体＋SMS を MFA/SSPR に活用 | External ID のユーザーフローは Email ベース。電話は 2 要素や回復手段で活用 |
| 新規ユーザーが電話番号だけで自己登録→即サインイン | × | Azure AD B2C（Phone サインアップ）／外部 IdP を OIDC/SAML で連携 | B2C は Phone ローカルアカウントが構成可能。長期は移行計画を前提に |
| 画面は電話番号入力欄のみ（メール欄なし） | × | External ID ではメール欄が必須。B2C/外部 IdP か、ネイティブ認証（モバイル）で完全自前 UI | CSS で隠してもサーバー側スキーマは変わらず非推奨 |
| HTML/CSS レベルで全面カスタマイズ | △（CSS は可／HTML 置換は不可） | Company Branding＋Custom CSS＋Branding Theme。完全置換が必要なら B2C のカスタムページ／外部 IdP | External ID は CSS で色・フォント・レイアウト調整が可能 |
External ID でできる UI カスタマイズの範囲
- Company Branding（中核）：背景、ロゴ、フッター、レイアウトを定義し、Custom CSS のアップロードで配色・タイポグラフィ・要素位置を統一可能。
- Branding Theme（アプリ別テーマ）：最大 5 つのテーマを作成し、アプリごとに見た目を切り替え可能。ライブプレビューでレイアウトやスタイルを確認。
- 言語／テキストカスタマイズ：言語ごとにプレースホルダーや補足文を上書き可能（ユーザーフローの言語設定／Company Branding のいずれからでも反映）。
- できないこと：独自 HTML の全面置換、JavaScript を用いたフォーム構造の変更、メール要素をサーバー側で省略。
「電話番号だけの UX」を実現する設計パターン
パターン A：Azure AD B2C（従来）で Phone サインアップ／サインイン
従来の Azure AD B2C はユーザーフローで「電話番号をローカル ID」にでき、Phone OTP だけで自己登録→即サインインが構成できます。B2C は新規購入が制限されている一方、少なくとも 2030 年までの継続サポートが示されています。既存テナント保有やパートナー経由の入手が可能な場合、短期に「電話番号主体の PoC」を最も低コストで成立させられます。
パターン B：外部 IdP 連携（Bring Your Own Identity）
Auth0 や Amazon Cognito など、Phone OTP を主要素にできる CIAMをフロントに据え、External ID へは OIDC/SAML でフェデレーションする方式。ユーザー自己登録と検証は外部 IdP が担当し、発行トークンをアプリが受け取ります。UI は外部 IdP 側で完全制御でき、電話番号のみの画面も容易です。
パターン C：アプリ側で電話番号を検証し、Graph API でユーザー作成
アプリ側で SMS ベンダー（Twilio / Azure Communication Services など）を使って電話番号を検証。検証後に Microsoft Graph API を呼び出して External ID にユーザーを作成します。ただしサインインは Email 主体のため、初回サインイン完了までの体験は「電話番号だけ」にはなりません。電話番号は MFA/SSPR の手段として紐づけます。
パターン D：ワークフォースの SMS サインインを応用
社内向けのワークフォース テナントでは「SMS サインイン（パスワードレス）」が構成できます。ただしこれは「既存ユーザーに電話番号を割り当ててログインさせる」性質で、External ID の自己登録 UX とは合致しません。顧客向けサービスに適用する場合は、ライセンス／コストモデルや責任分界の整理が必要です。
比較表：External ID と代替案の違い
| 観点 | External ID | Azure AD B2C | 外部 IdP（BYOI） |
|---|---|---|---|
| 主 ID としての Phone OTP | ×（未提供） | ○（ユーザーフロー構成可） | ○（サービス次第） |
| 自己登録（Phone のみ） | × | ○ | ○ |
| 画面フルカスタム（HTML） | ×（CSS/テーマは可） | ○（カスタムページ URI） | ○ |
| MFA での SMS | ○（第二要素） | ○ | ○ |
| SSPR での SMS | △（公開プレビューの報告） | ○ | ○ |
| 長期ロードマップ | 機能拡張中（Phone 主要素は未公表） | サポート継続（新規購入は制限） | 各サービス次第 |
最短で PoC を成立させる現実路線（External ID 前提）
アーキテクチャ概要
- 認証方式：Email OTP ベースの「Sign up & sign‑in」ユーザーフロー。
- UI：Company Branding＋Custom CSS でブランド統一（メール欄は必須／非表示化は非推奨）。
- セキュリティ：MFA はリスクに応じて SMS を第二要素として要求。SSPR に SMS（プレビュー）を組み合わせて回復性を確保。
- アプリ実装：OIDC（推奨）で External ID のトークンを受領。初回サインイン後はプロフィール編集で電話番号の登録を促す。
手順（ダイジェスト）
- External テナントを作成し、アプリ登録（Web/SPA）を作成。
- 「User flows」で Sign up & sign‑in を作成し、Email with one‑time passcode を選択。収集属性（Display Name など）を設定。
- Company Branding でロゴ／背景／レイアウトを調整し、Custom CSS をアップロードして色・フォント・余白・フッター体裁を統一。
- Branding Theme を作成し、対象アプリに割り当て（アプリ別に配色やロゴが変わる場合）。
- Authentication Methods で Email OTP を有効化。MFA で SMS を有効化し、対象グループを限定。
- SSPR を構成（Email OTP を必須にし、SMS の公開プレビューを評価環境で検証）。
- アプリ側で OIDC のリダイレクト URI／スコープ／PKCE を設定。ユーザーフローのエンドポイントを組み込み、サインイン／サインアップを統合。
「電話番号のみ」をどうしても満たしたい場合の現実的ブループリント
- 短期（PoC）：B2C で Phone サインアップ／サインインのフローを構成し、アプリの UI は B2C のカスタムページで完全制御。External ID は将来統合を見据え、クレーム・属性設計を合わせる。
- 中期（ハイブリッド）：外部 IdP（Phone 主体）をフロントに、External ID へフェデレーション。アプリは最終的に External ID のトークンを受ける構成に寄せる。
- 長期（移行）：External ID の機能拡張（Phone 主要素の提供）に合わせて、ユーザーフローを段階的に置換。サインイン方式の切り替えは「新規ユーザーにのみ適用」の運用が安全。
セキュリティと不正対策（Phone/SMS を使うなら必ず実装）
| リスク | 症状 | 推奨対策 |
|---|---|---|
| IRSF（国際電話収益シェア不正） | 大量の OTP 送信による課金・在庫枯渇 | 送信回数レート制限、再送待ち時間、国別ブロック、信用スコアによるチャンレンジ/ブロック |
| ボット登録 | サインアップのスパム | CAPTCHA・端末指紋・難読化、IP レピュテーション、同一端末からの試行制限 |
| OTP リレー攻撃 | 中継／ソーシャルエンジニアリング | 高リスク時のチャレンジ（知識ベース質問／デバイス検証）、通知・アラート |
| SMS 配送失敗 | 電波／キャリア事情で未達 | バックアップ要素（Email OTP / Authenticator / 音声通話）を準備 |
運用・課金の見取り図
- MAU 課金：External ID は月間アクティブユーザー単位。評価環境ではテストアカウントの清掃で無駄なカウントを抑制。
- SMS 追加コスト：MFA／SSPR の SMS には国・地域別の従量費が発生。上限・警告の運用とアラート設定を。
- ログ：サインインログは標準。サインアップログ（プレビュー）は不正対策や UX 分析に有用。SIEM 連携で相関分析を。
実装チェックリスト（PoC 用）
- ユーザーフロー：Email OTP を選択／属性は最小から開始。
- ブランディング：ロゴ・背景・配色・レイアウトを Company Branding と Custom CSS で統一。要素非表示の CSS ハックは避ける。
- アプリ：OIDC（PKCE）で統合、エラーハンドリングと OTP 再送の UI を丁寧に。
- セキュリティ：MFA のグループ適用、SSPR の多経路化、レート制限／CAPTCHA、有効期限・再送制御。
- 観測：サインイン／サインアップのログ収集、エラー率と到達率モニタリング、KPI（登録完了率・再送率）設計。
よくある誤解と注意点
- 誤解：「SMS サインインを有効にすれば External ID の画面に Phone OTP が出てくる」
→ 実際：SMS サインインはワークフォース向けの「認証方法」。External ID の自己登録用主要素には未統合です。 - 誤解：「CSS でメール欄を隠せば電話番号だけで登録できる」
→ 実際：サーバー側スキーマは Email 必須。隠蔽は UX 崩壊と障害の原因。 - 誤解：「Custom page URI で独自 HTML を差し替えられる」
→ 実際：External ID は Company Branding＋Custom CSS による見た目の最適化が範囲。完全置換は不可。
サンプル設計：電話検証を組み込んだ「妥協案」
「電話中心の体験」を保ちながら現行仕様に沿う妥協案です。
- トップ画面は電話入力 → SMS 検証（アプリ内実装）。
- 検証成功後、バックグラウンドでユーザーの仮登録（External ID のローカル ID は Email。メールは後段で提示）。
- ユーザーフロー（Email OTP）に遷移し、OTP はメールに送付。電話は MFA 登録に誘導。
- 以降の重要操作（住所登録・決済等）には SMS を追加要素として要求。
完全な「電話だけ」とは異なりますが、入口は電話精査→本登録は Email OTPで、心理的には電話主体の導線を維持できます。
ネイティブ認証（モバイルアプリ）の活用ポイント
External ID のネイティブ認証を使うと、モバイルアプリ内でピクセルパーフェクトな認証 UIを作れます。ただし Web ブラウザでのホスト画面とは別経路であり、外部テナントの主要素が Email である事実は変わりません。モバイル中心であれば、UI 要件は満たしやすくなります。
実装の落とし穴（回避策付き）
- SMS 過剰コスト化：PoC 段階からレート制限と国別ルールを組み込み、アラートを設定。
- 再送地獄：OTP の有効期限・再送間隔を明示し、メール／音声通話の代替を UI に常設。
- ログ未収集：サインイン／サインアップログを監視し、未達率・離脱率を KPI 化。
- CSS による DOM 依存：将来の UI 更新で崩れるため、配色・余白・フォント中心のカスタムに留める。
まとめ
- External ID では、電話番号だけでの自己登録・即ログインは未対応。ユーザーフローは Email 主体です。
- UI は Company Branding＋Custom CSS＋Branding Theme で見た目は大きく変えられるが、独自 HTML への置換は不可。
- 「電話主体」の UX が譲れない場合は、Azure AD B2C の Phone サインアップか、外部 IdP 連携で早期に PoC を成立させるのが近道。
- External ID を軸にするなら、まずは Email OTP ベースで PoC を固め、SMS はMFA と SSPR（プレビュー）に活用。将来の Phone 主要素の提供に備え、段階移行ができる属性設計・クレーム設計を。
付録：設計のための観点チェック
| 観点 | 質問 | 備考 |
|---|---|---|
| ID スキーマ | ローカル ID は Email でよいか？別名（ユーザー名）を許容するか？ | 別名サインイン（プレビュー）で Email 以外の識別子を補助に |
| 回復 | SSPR の経路は Email／SMS／音声のうち何を許可するか？ | 認証方法ポリシーでグループ別に構成 |
| 不正対策 | CAPTCHA とレート制限の閾値は？ | 送信数・端末・IP のしきい値設計 |
| 観測 | どのログをどこに出すか？ | サインイン／サインアップログ＋SIEM 連携 |
| 将来変更 | Phone 主要素が提供された場合の切り替え手順は？ | 新規ユーザーから段階適用、既存は並行運用 |
コメント