Salesforce LWRサイトの「ヘッドレスID設定」とは？UIを自由に作れる次世代の認証基盤を解説【自社Webサイトの裏でLWRを呼び出す】

LWRサイトのワークスペースにある「管理」メニューを開くと、「ヘッドレス ID 設定」という項目があることにお気づきでしょうか？

ヘッドレス ID 設定
プラットフォーム外アプリケーションでヘッドレス ID サービス用の Experience Cloud サイトを使用する方法を設定します。これらの設定はサイトのログインおよび登録環境に影響しません。

「サイトのログイン環境に影響しない」と書かれていますが、では一体何のための設定なのでしょうか？今回は、この設定の正体である「ヘッドレス ID (Headless Identity)」の概念と、どのような場面で使われる機能なのかを解説します。

ヘッドレスIDとは？「顔（UI）」を持たない認証機能
具体的にどのような設定があるのか？
この設定画面がやっていること
Mobile Publisher との違い
どんな時に使うの？
まとめ
参考URL

ヘッドレスIDとは？「顔（UI）」を持たない認証機能

通常、Experience Cloud サイトで会員登録やログインを行う場合、Salesforce が提供する標準のログイン画面（またはエクスペリエンスビルダーで作成した画面）を使用します。これは「画面（ヘッド）」と「認証機能（ボディ）」がセットになっている状態です。

一方、ヘッドレス ID は、その名の通り「画面（ヘッド）」がありません。Salesforce は裏側の認証機能（API）だけを提供し、ユーザーが操作するログイン画面のデザインや挙動は、開発者が自由に作成した外部のアプリ（モバイルアプリやWebサイト）側に委ねるという仕組みです。

つまり、「見た目は完全にオリジナルのアプリだが、ID管理の実体はSalesforceにある」という構成を実現するための機能です。

Headless Identity のイメージ（Gemini Nano Banana が生成）

具体的にどのような設定があるのか？

「ヘッドレス ID 設定」セクションでは、主にヘッドレス登録（新規ユーザー作成）とパスワードレスログインに関するバックエンド処理を設定します。

主な設定項目は以下の通りです。

A. ヘッドレス登録 (Headless Registration)

外部アプリの「新規登録フォーム」からユーザー情報を受け取った際に、Salesforce側でどう処理するかを定義します。

ヘッドレス登録を許可: 外部からのAPIによるユーザー登録を受け付けるかどうかのスイッチ。
登録ハンドラ (Apexクラス):
- これが最も重要です。外部から送られてきたデータ（氏名、メールなど）を受け取り、Salesforce内の User レコードや Contact レコードを実際に作成・更新するApexロジックを指定します。
- 通常のソーシャルログイン（Auth.RegistrationHandler）に似た仕組みです。
登録を実行するユーザー:
- 上記のApexクラスを、どの権限（ユーザー）として実行するかを指定します。

B. パスワードなしのヘッドレスログイン

電話番号（SMS）やメールによるワンタイムパスワード（OTP）を使ったログインの設定です。

OTP送信設定: ユーザー確認のために送信するメールテンプレートなどを指定します。

C. ヘッドレスのパスワードを忘れた場合 (Headless Forgot Password)

パスワードリセットフロー: 外部アプリの画面から「パスワードを忘れた」操作をした際、裏側でSalesforceのパスワードリセットプロセスを回すための設定です。

D. ボット対策とセキュリティ (reCAPTCHA)

画面（UI）を自由に作れるということは、裏を返せば「外部からAPIを直接叩きやすくなる」ため、悪意のあるボットによるスパム登録などの標的になりやすい側面があります。これを防ぐため、設定画面内には「Google reCAPTCHA」のシークレットキーや、ボット判定のスコアしきい値（例: 0.7など）を指定する項目が用意されています。自由なUIと引き換えに求められる、必須のセキュリティ対策を設定する場所でもあります。

この設定画面がやっていること

ワークスペースにある「ヘッドレス ID 設定」は、外部アプリからAPI経由でリクエストが来た際に、Salesforce側でどう処理するかを決めるバックエンドの司令塔のような役割を果たします。

具体的には以下のような制御を設定します（※画面上の見た目を設定する場所ではありません）。

誰が処理するか（実行ユーザー）: 外部から「新規登録したい」というリクエストが来た際、Salesforce内部のどの権限（ユーザー）を使ってデータを書き込むかを指定します。
どう処理するか（ハンドラ）: 送られてきたデータ（メールアドレスや名前など）を、Salesforceの User オブジェクトや Contact オブジェクトにどうマッピングするかというロジックを指定します。

この設定を行うことで、既存のLWRサイトのログイン画面（ブラウザで見る画面）には一切影響を与えずに、裏口のような専用のAPI窓口を開放することができるのです。

Mobile Publisher との違い

よく混同される機能に「Mobile Publisher」がありますが、アプローチが全く異なります。

Mobile Publisher: Experience Cloud で作ったWebサイトを、そのままアプリの枠（ガワ）で包んで表示するもの。画面はSalesforce側で管理します。
ヘッドレス ID: アプリの画面は、Swift (iOS) や Kotlin (Android)、React などでイチからフルスクラッチで開発します。Salesforceはログインの裏処理だけを担当します。

どんな時に使うの？

主に「顧客体験（UX）にとことんこだわりたい」というケースで採用されます。

ブランド独自の世界観を持つモバイルアプリ
- ログイン画面で突然SalesforceっぽいWeb画面に切り替わるのを防ぎ、アプリネイティブな操作感を維持したい場合。
IoTデバイスやスマート家電
- 画面を持たないデバイスや、特殊なインターフェースを持つ機器から、ユーザー認証を行いたい場合。
既存のECサイトやコーポレートサイトとの統合
- すでに運用中のWebサイトがあり、その会員データベースとしてSalesforceを利用したいが、画面遷移はさせたくない場合。