外部サイトでの会員登録におけるコンバージョン低下は、多くのB2C向けポータルが抱える課題です。この課題を技術的に解決するためには、OAuthプロトコル特有の「画面遷移（リダイレクト）」や「パスワード入力」がもたらすUXの断絶をいかに排除するかが鍵となります。
今回取り組んだ仮想プロジェクト「たてはまペットクリニック」では、Salesforceを完全に裏方のIDaaS（Identity as a Service）として機能させ、ReactベースのSPA（Single Page Application）単体で登録からログインまでを完結させるシステム要件を設定しました。
本アーキテクチャの核心は、B2C特有の複雑なリレーションデータ（個人取引先、ペット情報、診療予約）の生成と、OTP（ワンタイムパスワード）によるセキュアな認証を、画面遷移を一切伴わず「Reactドロワー内の状態（State）管理」のみでシームレスに処理した点にあります。ユーザーは、背後でSalesforceが動いていることを一切意識しません。
本記事では、連載第1回として、このネイティブアプリに近いUXを実現するためのアーキテクチャ全体像と、技術選定におけるトレードオフを整理します。
システム全体像とデータモデル
アーキテクチャ解説：SPA × Salesforce Headless Identityの全体像
本プロジェクトにおけるシステム全体のアーキテクチャ図です。 この図は、ReactなどのSPA（シングルページアプリケーション）で構築された独自のWebフロントエンドから、Salesforceの「Headless Identity」を用いてパスワードレス認証を行い、最終的にExperience Cloud（LWR）の認証済みセッションを確立するまでの一連の流れを示しています。
システムは大きく分けて以下の4つのレイヤーで構成されています。
1. Web Client (React SPA)
ユーザーとの最初の接点となる独自のWebサイトです。「はじめての方（登録）」と「ログイン」の入り口から、画面遷移を伴わずにシームレスに6桁のOTP（ワンタイムパスワード）認証UIを提供します。
2. Integration Layer (BFF)
フロントエンドとSalesforceの間を取り持つAPIプロキシ（Node.js等のBackend For Frontend）です。SalesforceのOAuthフローが返す 302 Redirect やCORS（Cross-Origin Resource Sharing）の制約をブラウザ単体で突破するのは困難であるため、この層で安全にリダイレクトをハンドリングし、フロントエンドに結果だけを返します。
3. Salesforce Backend (Headless APIs & Apex Custom Handlers)
認証とデータ生成の心臓部です。 外部クライアントアプリケーション（ECA）でスコープ制御されたAPIエンドポイント（/auth/headless/init/... や /auth/headless/register）がリクエストを受け取ります。
ここでの最大のポイントは Apex Custom Handlers の動きです。登録フローでは、トランザクション内で「個人取引先（Person Account）」「ペット情報（Pet__c）」「予約（Appointment__c）」のレコードを作成しますが、Userレコードだけは insert せず、インスタンス（Instance）のみをリターンしてプラットフォームに作成を委譲する特殊な仕様となっています。
4. Experience Cloud (LWR)
APIによる認証が成功して取得したアクセストークンを、UI Bridge API（/oauth2/singleaccess）を利用して frontdoor_uri に変換し、このLWRポータル画面へ遷移させます。これにより、独自のWebサイトからSalesforceのマイページへ、ユーザーにログインを意識させることなくシームレスにログイン状態を引き継ぎます。
注目したい設計の工夫
- データモデルの分断と連動
ゲスト状態から一気に複雑なリレーショナルデータ（取引先〜ペット情報〜予約）を生成する「Atomic Transaction」がApex内で完結しているため、データ不整合が起きません。 - APIとUIの架け橋（Single Access）
APIで取得したトークンを、いかにして「Cookieベースの画面ログイン状態」に変換するか。この最後の1マイルをsingleaccessAPI が安全に繋いでいます。
パスワードレス採用の判断基準とトレードオフ
一般的なID/パスワードによるHeadless認証と比較し、今回はOTPを用いた「ヘッドレス登録」「パスワードなしのヘッドレスログイン」を採用しました。
- メリット: パスワードの新規考案や管理の手間を省くことで、初回登録時の心理的ハードルを極限まで下げ、コンバージョン率（予約完了率）を最大化できます。パスワードリスト攻撃などのセキュリティリスクも低減されます。
- デメリット: API呼び出しが「OTP初期化」と「検証・トークン取得」の2段階に増えるため、フロントエンド側で中間状態（OTP送信待ち、メールアドレスの一時保存）を管理するState設計が複雑化します。また、Salesforce側で
Auth.LoginDiscoveryHandlerなどの構築が追加で必要となり、初期開発工数は増加します。
今回は「初回のハードルを下げる」というビジネス要件の優先度が高いため、開発工数増のトレードオフを受け入れてパスワードレスアーキテクチャを選択しています。
ユーザー体験（UX）の設計とコンポーネント分割
標準的なWeb要素を起点としつつ、画面遷移による離脱を防ぐため、ユーザーの目的に応じて2つのUI導線を設計しました。
新規登録導線（左ドロワー）
サイト中央の「はじめての方 (新規登録・予約)」ボタンをトリガーとし、画面左からドロワーフォーム（LeftDrawer）を展開します。氏名やペット情報を入力させ、データはAPI送信時までReact側のStateで一時保持されます。
既存ログイン導線（右ドロワー）
ヘッダー右上の「ログイン」ボタンをトリガーとし、画面右からドロワーフォーム（LoginDrawer）を展開します。こちらはメールアドレス入力のみを求めるシンプルなUIとなっています。
スマート6桁OTP認証（共通）
いずれの導線でも、入力完了後は同一UI内で SmartOtpInput コンポーネントに切り替わります。リアルタイムバリデーションを通過したデータのみをSalesforceへ一括送信し、エンドポイント（自己登録 または ログイン）を自動で振り分けます。
マイページ遷移
認証完了と同時にExperience Cloud側へ遷移し、ログイン状態のままマイページを表示します。
まとめ
コンバージョン率の最大化を目的としたパスワードレス認証の採用は、ユーザーの心理的ハードルを下げる一方で、APIの多段化や中間状態の管理といったフロントエンドの複雑化をもたらします。また、B2Cモデルにおける個人取引先（Person Account）を前提としたデータモデル設計は、以降のバックエンド処理の基盤となります。
ビジネス要件（CVR向上）とシステム要件（開発工数と状態管理）のトレードオフを正しく評価し、アーキテクチャを決定することがプロジェクト成功の第一歩です。
続いて第二弾の記事もご覧ください。
参考URL
Headless Identity for Customers and Partners
読者の声