LINEログインとSalesforce 会員ID連携とオフライン属性の名寄せ設計

LINEログインとSalesforce連携が必要とされる背景

現代のCRM戦略において、LINEは単なる通知ツールではなく、顧客との「デジタル接点」そのものです。しかし、LINE公式アカウントの管理画面（LINE Official Account Manager）だけでは、顧客が過去に何を買い、どのような属性（購入金額、最終来店日など）を持っているかを把握することは困難です。

Salesforce側に蓄積された購買データや商談履歴をLINEのUID（User ID）と紐付けることで、以下のような「高度な出し分け」が可能になります。

• 店舗でA商品を購入した顧客にのみ、1週間後にLINEでB商品のクーポンを送る
• Salesforce上の会員ランクが「プラチナ」のユーザーに対し、LINEのリッチメニューを限定版に切り替える
• ECサイトのカゴ落ちデータをトリガーに、LINEでリマインドメッセージを自動送信する

これらを実現するには、WebトラッキングとID連携の深い理解が欠かせません。詳細は以下のガイドを参考にしてください。

WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ

ID連携における「3つのキー情報」を理解する

名寄せ設計において、どの値を「ユニークキー」にするかを定義することは最優先事項です。

1. LINEユーザー識別子（UID）

LINEログインやLIFFを通じて取得できる U から始まる33桁の英数字（例：U1234567890abcdef1234567890abcdef）です。これはユーザーがLINEで設定した「LINE ID」とは異なり、プロバイダごとに固定される内部識別子です。開発ドキュメントでは userId と表記されます。

2. Salesforce取引先責任者ID（Contact ID）

Salesforce側で顧客一人ひとりを識別する 003 から始まる18桁のIDです。LINE連携を行う場合、取引先責任者（Contact）オブジェクトに、LINEのUIDを格納するためのカスタム項目（一意・外部ID属性を推奨）を用意します。

3. 共通キー（会員番号・メールアドレス）

LINEとSalesforceを紐付けるための「名寄せのきっかけ」となる情報です。ログイン認証に使用するメールアドレスや、会員登録時に発行される会員番号がこれに該当します。

名寄せのアーキテクチャ：オンラインとオフラインの統合

名寄せが最も困難なのは、実店舗（オフライン）での接点です。店舗に来店した顧客が、すでにLINE友だちであるか、あるいはSalesforceに登録済みの会員であるかを判定するフローを構築する必要があります。

LIFF（LINE Front-end Framework）を活用したセキュアな連携

オフライン接点では、店頭のQRコードからLIFFアプリを起動させる手法が標準的です。LIFFを使用することで、ユーザーは外部ブラウザに遷移することなく、LINEアプリ内で会員証表示やログイン操作を完結できます。

この際、LIFFから取得した idToken をサーバーサイド（HerokuやAWS、あるいはSalesforceの公開サイト）に送り、LINE側のAPIで検証することで、なりすましを防止したセキュアなID連携が可能となります。

オフライン属性の名寄せフロー

1. 顧客が店頭の「LINE会員証」QRコードを読み取る
2. LIFFアプリが起動し、自動的にLINEのUIDを取得する
3. UIDがSalesforceに存在するかチェック
   • 存在する場合： そのまま会員証を表示
   • 存在しない場合： ログイン画面（または新規登録画面）を表示
4. 顧客がログインに成功したら、入力された「メールアドレス」をキーにSalesforce内を検索し、既存の取引先責任者レコードにLINEのUIDを書き込む

このように、ID連携のタイミングで「既存データとの突き合わせ」を行うことで、二重登録を防ぎつつ、オフラインの行動履歴をSalesforceへ集約できます。

実名ツール・サービス比較

LINEとSalesforceを連携させるには、自社開発の他に、連携済みのSaaSやコネクタを利用する選択肢があります。それぞれの特性を比較します。

※料金の詳細は、各社公式サイトの最新情報をご確認ください。
・ソーシャルPLUS 公式サイト
・Salesforce Digital Engagement 公式

実装ステップ：LINEログインからSalesforce格納まで

ここでは、自社でスクラッチ開発、あるいはSalesforceの機能をベースに構築する際の手順を解説します。

ステップ1：LINE Developersでの設定

まず、LINE Developersにログインし、以下の設定を行います。

1. LINEログインチャネルの作成：Webアプリ用またはLIFF用。
2. コールバックURLの設定：Salesforceの認証プロバイダURL、または中継するWebサーバーのURLを指定。
3. OpenID Connectの申請：ユーザーのメールアドレスを取得したい場合は、LINE側での審査申請が必要です。

ステップ2：Salesforce側での受け皿作成

Salesforceの「設定」から「認証プロバイダ」を開き、新規作成します。プロバイダタイプには「OpenID Connect」を選択。ここでLINE Developersから取得した Client ID と Client Secret を入力します。

また、取引先責任者オブジェクトに LINE_UID__c などのカスタム項目を追加しておきます。

ステップ3：ID連携処理（名寄せロジック）の実装

認証後の「登録ハンドラ（Registration Handler）」クラスに、以下のようなロジックを記述します（Apexコード例の概念）。

1. LINEから返されたUIDをクエリし、既存の取引先責任者があるか確認。
2. 存在しなければ、メールアドレスで再検索。
3. それでも存在しなければ、新規レコード作成または既存レコードへのUID紐付けをユーザーに促す。

高度なデータ基盤を構築する場合、Salesforce単体ではなくBigQuery等のデータウェアハウスを介した設計が有効です。これにより、膨大なLINE行動ログを安価に蓄積・分析できます。詳細は以下を参照してください。
高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャ

運用の壁：よくあるエラーと回避策

1. 二重登録（名寄せ失敗）の防止

「すでに会員登録しているのに、LINE連携時に新しく別レコードが作成されてしまう」ケースです。これは、メールアドレスの一致確認をスキップしたり、大文字小文字の差異を許容していない場合に発生します。Salesforceの「一致ルール」と「重複ルール」を適切に設定し、Apex側で upsert 操作を慎重に行う必要があります。

2. LINEアプリ内ブラウザの「戻る」ボタン挙動

LINEログインの認可フロー中にユーザーが「戻る」ボタンを押すと、ステートの不整合でエラー（CSRF対策のstateミスマッチ）が発生します。これを防ぐには、エラーハンドリング用のカスタムページを用意し、再度ログインを促す親切なUX設計が求められます。

3. LINEブロック時の対応

ユーザーがLINEをブロックしても、Salesforce側のUIDは有効なままです。Messaging APIの Webhook（unfollow イベント）を検知し、Salesforce側の「LINE配信可否フラグ」を自動で false に更新するバッチ、あるいはリアルタイム連携が必要です。

こうした動的なフラグ管理は、リッチメニューの制御にも応用可能です。
LINE データ基盤から直接駆動する「動的リッチメニューとキャンペーンモジュール」のアーキテクチャ

まとめ：データドリブンなCRMへの転換

LINEログインとSalesforceのID連携は、単なる「便利なログイン手段」の提供ではありません。それは、顧客の断片化されたオンライン・オフラインの行動を統合し、一人ひとりに最適化された体験を提供する基盤作りです。

設計においては、技術的なAPI連携だけでなく、「どのタイミングで、どの情報を、何のキーで名寄せするか」というビジネスロジックの定義が成否を分けます。本記事で示したアーキテクチャを参考に、拡張性と保守性の高いCRM基盤を構築してください。