Salesforceを会員・顧客基盤にする｜LINEログインを受け、配信までつなぐ全体像

すでに Salesforce を使っているなら、会員基盤を別に立てるより、Salesforce 自体を会員・顧客基盤（CIAM）にするのが自然な選択になります。役割がきれいに揃うからです——Experience Cloud で会員ポータルとログインを持ち、認証プロバイダ（Auth Provider）で LINE／ソーシャルログインを受け、Marketing Cloud でLINE配信、Data Cloud で購買・行動データを統合する、という具合です。この記事では、その全体像を技術の粒度まで下ろしたうえで、意思決定でつまずきやすい二つの論点——「重複会員を作らない設計」と「ライセンスの選び方」——を整理します。名寄せの具体的な実装設計は、深掘り記事の 「LINEログインとSalesforce 会員ID連携・名寄せ設計」 に譲り、本稿は各コンポーネントがどう噛み合うかの“地図”に徹します。

3つのレイヤーで、役割が揃う

Salesforceを会員基盤にする最大の理由は、会員データと顧客管理（CRM）が最初から一体になることです。会員基盤を別に持つと、購買や商談、問い合わせといった顧客データと、会員情報がまた分断され、名寄せの苦労を二重に抱えることになります。すでに社内でSalesforceを使っているなら、この一体化の効きは大きくなります。全体は、役割の異なる3つのレイヤーに分けて捉えると、見通しが良くなります。

この3層をつなぐ背骨は、「一人の会員を指し示す一意のキー」です。ログインで受け取る識別子、会員レコード、配信の宛先——これらが同じ人物を指していると保証できるかどうかで、設計の成否が決まります。以下、3つのレイヤーを順に、技術の中身まで見ていきます。

Salesforceを会員基盤にするとは、会員一人ひとりを取引先責任者（Contact）として持ち、そこに認証と配信を接続することです。

① ログインを受ける——認証プロバイダ（OIDC）で

Salesforceは、外部のソーシャルログインを標準の「認証プロバイダ（Auth Provider）」で受けられます。これは、LINEを外部のIDプロバイダ（IdP）としてSalesforceに登録し、OpenID Connect（OIDC）でユーザーの認証結果を受け取る仕組みです。設定画面で種別に「OpenID Connect」を選び、主に次の項目を埋めます。Consumer Key／Consumer Secret（＝LINEログインチャネルのチャネルID・チャネルシークレット）、認可・トークン・ユーザー情報の各エンドポイント、要求するスコープ、そして必須のApexクラスである Registration Handler です。

LINEはOIDCに準拠しているため、認可エンドポイント（access.line.me/oauth2/v2.1/authorize）、トークンエンドポイント（api.line.me/oauth2/v2.1/token）、ユーザー情報エンドポイント（api.line.me/oauth2/v2.1/userinfo）を指定すれば受けられます。スコープは openid を基本に、プロフィールが必要なら profile、メールアドレスが必要なら email を加えます。

ログインが成立するまでの流れ

認証プロバイダを登録すると、Salesforce側は固有のコールバックURL（リダイレクトURI）を自動生成します。これをLINE Developersのチャネル設定に「コールバックURL」として登録することで、両者が結ばれます。実際のログインは、標準的な認可コードフローで進みます。会員がログインボタンを押すとLINEの認可エンドポイントへ送られ、同意のあと、認可コードがコールバックURLに戻ります。SalesforceはこのコードをトークンエンドポイントでアクセストークンとIDトークンに交換し、必要ならユーザー情報エンドポイントも呼びます。IDトークンはJWTで、sub（そのチャネル配下でのLINEユーザーIDにあたる一意の識別子）や表示名、許可されていればメールなどのクレームを含みます。こうして得た値が Auth.UserData というオブジェクトにまとめられ、次章の Registration Handler に渡されます。設定後は、Salesforceが用意するテスト用の初期化URLで、実際にログイン画面へ載せる前に疎通を確認できます。

この往復では、安全性のための小さな作法もあります。認可リクエストには state（画面遷移をまたいだ改ざん・CSRFを防ぐ値）や nonce（IDトークンの使い回し＝リプレイを防ぐ値）を添えます。戻ってきたIDトークンは、まず署名を検証してからクレームを読むのが原則です。表示名やプロフィール画像といった追加の属性が要るときだけユーザー情報エンドポイントを呼ぶ、という使い分けにすると、余計な通信を増やさずに済みます。会員基盤として長く運用するなら、こうした検証を Registration Handler の手前で確実に効かせておくことが、なりすまし対策の土台になります。

② 重複会員を作らない——Registration Handlerの設計

Experience Cloudの外部ユーザーは、必ず取引先責任者（Contact）に紐づきます（B2C向けには個人取引先＝Person Accountを使う構成もあります）。つまり「Salesforceを会員基盤にする」とは、会員一人ひとりをContactとして持つ、ということです。そして、ソーシャルログインで入ってきたユーザーを既存のContactと正しく突き合わせるのが、認証プロバイダに設定した Registration Handler の役割です。

ここで、会員のデータモデルを最初に決めておく必要があります。Experience Cloudの外部ユーザー（User）は、Contactを介して取引先（Account）にもぶら下がります。createUser が返すUserには、外部ユーザー向けのプロファイルと、この所属先のContactが揃っていなければなりません。会員一人ひとりに取引先を作らないB2Cでは、代表的な取引先に相乗りさせる（いわゆるバケット取引先）か、個人取引先（Person Account）で一人＝一レコードとして持つかを、設計の初手で選びます。ここを曖昧にしたまま作り始めると、会員数が増えてからデータモデルの作り直しになりがちなので、名寄せキーと並んで最初に固めるべき論点です。

Registration Handler は、Auth.RegistrationHandler インターフェースを実装したApexクラスで、二つのメソッドを持ちます。初回ログイン時には createUser（ユーザーを新規に作って返す）が、2回目以降は updateUser（既存ユーザーを最新情報で更新する）が呼ばれます。

createUser と updateUser、どちらが呼ばれるか

分岐を決めるのは、Third-Party Account Link（TPAL、外部アカウントの紐付けレコード）の有無です。TPALは、Salesforceのユーザーと外部IdPの一意な識別子（RemoteIdentifier）を結ぶレコードで、ユーザー詳細ページの「サードパーティアカウントのリンク」欄に現れます。あるユーザーにTPALが無ければ初回とみなされて createUser が、既にあれば updateUser が呼ばれます。ここが堅牢さの勘所です。RemoteIdentifier にメールではなく sub（LINEユーザーID）を保持しておけば、利用者がLINE側のメールを変えても紐付けは切れません。UIDを軸にする理由がここにあります。

肝心なのは、Salesforceは重複を自動では名寄せしないという点です。createUser に渡される Auth.UserData には、identifier（＝sub）、email、氏名、attributeMap（プロバイダの生データ）などが入りますが、これを使って自前で既存のContactを検索し、見つかれば紐付け、なければ新規作成する——このロジックを書かないと、同じ人物が二重のユーザーになります。LINEのユーザーIDは、Contactに「外部ID」かつ「一意」の属性を付けたカスタム項目に格納するのが定石で、これが検索キーになります。

この名寄せをどう実装するか——検索キーの優先順位、ヒットしなかったときの扱い、オフラインで作った会員レコードとの突合まで——の具体的な設計は、名寄せ設計の深掘り記事にまとめています。本稿と重複しないよう、詳細はそちらに委ねます。

重複会員は「Salesforceが弾いてくれる」ものではなく、Registration Handlerで能動的に防ぐものです。

③ 配信と統合——GroupConnectとData Cloud

会員をContactに紐づけたら、その先の配信まで一続きにできます。Marketing Cloud の GroupConnect でLINE公式アカウントを連携すると、LINEのユーザーID（Address ID）を宛先に、Journey Builder（カスタマージャーニー）からLINE配信ができます。ログインで得たUIDと配信の宛先が同じ値であることが、ここで効いてきます。

ただし、ここにも落とし穴があります。新しく友だち追加したユーザーは、GroupConnectがランダムな連絡先キー（Contact Key）で自動生成するため、Service Cloudや外部CRMから取り込んだ会員の連絡先キーとは一致しません。放置すると、同じ人物が「CRM側の会員」と「LINE側の友だち」に分かれた別人として溜まっていきます。誰か分からないまま友だちになっている“匿名の連絡先”を、あとから本人の会員レコードに結びつける必要があるわけです。

解消の筋道はこうです。両者に共通して持てる LINE ID の項目で突合し、Contact Builderの取込定義（import definition）で連絡先キーを揃え、Automation Studioで定期実行して自動化します。さらに、どのチャネルにも紐づかない“みなし子”の連絡先（Orphan Contact）は溜まっていくため、定期的な削除・整理のルールも決めておきます。

より広く顧客データを束ねるなら、Data Cloud（CDP） で単一プロファイル化します。購買・行動・チャネルのデータを取り込み、同一人物のレコードを結ぶ（IDリゾリューション）ことで、会員一人の全体像を作れます。現時点でLINEのネイティブコネクタは見当たらず、GroupConnect経由や取込API（Ingestion API）での連携が実路線です。CRM／LTVの観点は CRM/LTV設計 を参照してください。

配信を一続きにできるからこそ、「誰に、何を、どこまで送ってよいか」の線引きも設計に含めます。LINEはブロックや友だち解除で宛先に届かなくなりますし、送れるメッセージの種類や量は公式アカウント側のプランに従います。会員基盤としては、同意の状態（オプトイン）や配信可否のフラグをContact側にも持たせ、UIDで結んだプロファイルと突き合わせて送信対象を絞り込めるようにしておくと、配信の精度とコンプライアンスの両方が扱いやすくなります。名寄せは「重複をなくす」だけでなく、「送ってよい相手を正しく特定する」ためにも効いてくる、というわけです。

意思決定の要——ライセンスの選び方でコストが激変する

最後に、見落とすと後で効いてくる論点です。Experience Cloudの外部ユーザーには複数のライセンス種別があり、用途で選び分けます。ログイン・セルフ登録・SSOに特化した「External Identity」は、大規模な消費者ID（CIAM）を捌くのに向きます。ケースやポータル体験まで出すなら「Customer Community」、レポートやロールベースの共有まで要るなら「Customer Community Plus」です。役割の違いは、次のように整理できます。

さらに課金には、登録会員数で課金する「メンバー単位」と、ログイン回数で課金する「ログイン単位」の二つのモデルがあります。目安は、月に4回を超えてログインするユーザーが多いならメンバー単位が割安、たまにしか来ないならログイン単位が有利、というものです。つまり「会員規模 × ログイン頻度」でコストが大きく変わるため、ここは要件を固めて正式な見積もりを取るべき領域です。ライセンスのリスト価格は変動するため、本稿では考え方の整理にとどめます。作る／買うの全体判断は 「認証は作るか買うか」 に譲ります。

▶ 全体像は 「LINEログインとは？仕組み・できること・導入の判断」 にまとめています。

参考にした一次情報：Salesforce 公式ドキュメント（認証プロバイダ・OpenID Connect の設定項目／Experience Cloud 外部ユーザーと取引先責任者の関係／Registration Handler と Third-Party Account Link／Marketing Cloud GroupConnect／外部ユーザーライセンス）、LINE Developers（LINEログインのOIDCエンドポイント・スコープ・メールアドレス取得権限の申請）。LINE UIDのプロバイダー単位の一意性、および各ライセンスのリスト価格は変動・要確認のため、本記事では考え方を中心にし、正式な費用は要見積もりです。仕様は改定される場合があるため、実装時は最新の公式情報をご確認ください（内容は執筆時点）。