LINEで受けた問い合わせを Salesforce のリードにする：リードにする合図・重複の突き合わせ・割り当て・同意

LINE で受けた問い合わせを Salesforce のリードにするとき、決めることは4つです。いつ作るか、どの項目に何を入れるか、誰と突き合わせるか、誰に渡すか。この記事はその段階を扱います。LINE のユーザーIDがプロバイダーごとに別の値になることなど、Salesforce と LINE をどうつなぐかの設計は「Salesforce と LINE をつなぐ：何を・どの向きで・誰のIDで流すか」に書いたので、ここでは繰り返しません。

結論から言うと、友だち追加の時点ではリードを作りません。Webhook で届くのはユーザーIDで、表示名や画像URLはプロフィールAPIで別に取ることになります（取得に同意していないユーザーは取れません）。どちらにも、会社名もメールもありません。Salesforce のリードは姓と会社名が必須なので、そのまま作ると「名前の無いリード」が積み上がります。リードにする合図を、会社名と連絡先を聞いた後に置くのが、この記事の出発点です。

友だち追加で分かることと、リードが必須とする項目は、ほとんど重ならない

ユーザーが友だち追加すると、フォローイベントが Webhook で届きます。ブロックを解除したときにも同じイベントが届きます（メッセージ（Webhook）を受信する）。イベントに入っているのはユーザーIDで、それを使ってプロフィールを取ると、表示名・ユーザーID・プロフィール画像のURL・ステータスメッセージが返ります。ただし、プロフィール情報の取得に同意できていないユーザー（PC版の LINE だけを使っているユーザー）の場合、イベントの送信元ユーザーのプロフィール情報は含まれません（プロフィール情報取得の同意）。

メールアドレスは、ここでは取れません。取れるのは LINE ログインを使ったときで、メール取得権限を事前に申請し、ユーザーが許可した場合に限られます（LINEログインの統合）。LIFF アプリ経由でも、チャネルでメールのスコープを選び、ユーザーが認可した場合に取れます（LIFFアプリをチャネルに追加する）。

一方、Salesforce のリードは、姓（LastName）と会社名（Company）が必須です（Lead オブジェクトリファレンス）。会社名が分からないときは、姓と名の組み合わせや「Unknown」「Not Provided」のような仮の値を入れて作る、と Salesforce は案内しています（ナレッジ記事 000392271）。作れはしますが、仮の値で作ったリードは、あとで本当の会社名に直す手間が残ります。

表示名は姓でも会社名でもありません。表示名を姓に入れてリードを作ると、営業が名前から相手を特定できず、あとで同じ人のリードが2件になる原因になります。LINE の規約も、ユーザー識別のための内部識別子以外の LINE ユーザー情報を24時間以上保存するなら、保存することをユーザーに明示するよう求めています（LINE Developers ユーザーデータポリシー 3.2.3）。表示名やプロフィール画像を Salesforce に持たせるかどうかは、この条文に当たるかを確かめてから決めます。

リードにする合図は、会社名と連絡先を聞いた後に置く：3つの型

「聞く」やり方は、大きく3つです。フォームで聞く、自社の顧客IDと結ぶ、トークの内容を担当者が入力する。どれを選ぶかで、リードが作られる時点と、入る項目と、つまずく場所が変わります。

型①：LIFF のフォームで聞くときは、IDトークンをサーバーで検証する

LIFF アプリは、LINE ログインのチャネルに追加します。追加するときに選ぶスコープで、取れる情報が決まります。openid はIDトークンの取得、profile は表示名などの取得、email はIDトークンのメールの取得です（LIFFアプリをチャネルに追加する）。ユーザーIDがプロバイダーごとに別の値になる点があるので、LIFF は Messaging API と同じプロバイダーに置きます（「Salesforce と LINE をつなぐ」）。

フォームの回答と一緒にサーバーへ送るのは、liff.getIDToken() で取ったIDトークンです。IDトークンの有効期間は発行から1時間です（LIFF API リファレンス）。liff.getProfile() などで取った表示名やプロフィールの詳細を、そのままサーバーに送ってはいけない、と公式は書いています。サーバーは受け取ったIDトークンを LINE の検証用エンドポイント（POST /oauth2/v2.1/verify）に送って検証し、ユーザーIDとプロフィールを安全に取り出します（LIFFアプリおよびサーバーでユーザー情報を使用する、IDトークンからプロフィール情報を取得する）。

LINE に登録されているメールと、問い合わせで使いたい会社のメールは、同じとは限りません。LIFF のメールをそのまま Email に入れるか、フォームで会社のメールをあらためて聞くかは、営業が連絡に使うアドレスで決めます。

LIFF の URL に付けた追加情報は、LIFF アプリを開くときに liff.state というクエリパラメータに入って届きます（LIFFアプリを開く）。入口（リッチメニュー、友だち追加後のあいさつ、QR）ごとに追加情報を変えれば、どの入口から来たかをフォームの送信と一緒に持ち帰れます。1つのチャネルに追加できる LIFF アプリは最大30件です。

型②：アカウント連携は、リードを作る型ではなく、既存の顧客に結ぶ型

アカウント連携は、LINE のユーザーIDと自社サービスのアカウントを結ぶ仕組みです。連携トークン（10分間有効、1回のみ）を発行して連携URLを送り、ユーザーが自社のログイン画面で認証すると、自社側で nonce を作り、連携完了のイベントがユーザーIDと nonce を添えて Webhook で届きます（ユーザーアカウントの連携）。自社の顧客IDを持つ相手が結ばれるので、新しいリードを作らず、既存の取引先責任者のユーザーID項目を埋める使い方になります。会員IDとユーザーIDを結んだあとの動きは、当社のデモ「LINE×CRM連携の流れ」（架空のデータ）で操作して確かめられます。

型③：トークの内容から入力するときは、本文を受けた時点で保存する

メッセージイベントで届いたテキストは、受信したあとに取り直すためのAPIがありません。画像・動画・音声・ファイルは取得できますが、一定期間後に自動で削除されます（メッセージ（Webhook）を受信する）。担当者が入力する運用でも、本文は受け口で受けた時点で Salesforce か自社のデータベースに保存しておきます。また、ユーザーがメッセージの送信を取り消すと送信取消イベントが届き、保存した本文を消すことが推奨されています（同ページ）。

リードにしてよいかの見分け：3つの問い

聞いたあとに、すべてをリードにする必要はありません。リードにする前に、次の3つを順に確かめます。

3つ目の「意思があるか」は、合図の置き方がそのまま基準になります。たとえば、友だち追加後に出す「資料請求フォーム」の送信を合図にするなら、友だち追加だけの人は最初からリードになりません。

リードの項目にどう入れるか：対応表

フォームの回答と LINE から届く値を、リードのどの項目に入れるかの一覧です。

外部IDの項目は、1つのオブジェクトに最大25個作れ、「ユニーク」を付ければ同じ値の重複を防げます。テキスト項目は最大255文字で、33文字のユーザーIDは収まります（カスタム項目の属性）。外部IDをキーにした書き込み（upsert）の動きは、「Salesforce と LINE をつなぐ」で扱いました。リードソースの「LINE」は、標準の選択リストに値を足して使います。LeadSource は選択リストで、リードの出どころを入れる項目です（Lead オブジェクトリファレンス）。

流入元は、友だち追加経路の集計とは別に、自社の入口で持つ

LINE 公式アカウントの管理画面の「友だち追加経路」で見られるのは、経路ごとの友だち追加数とブロック数の集計です。期間は最大90日で、期間内に20回未満の経路は数値が出ません（LINE公式アカウント 分析 – 友だち）。特定のユーザーがどの経路で友だち追加したかは、Messaging API では確認できない、と LINE Developers の FAQ にあります（FAQ「友だち追加経路をユーザー単位で確認できますか？」）。ただし分からないのは標準機能と Messaging API だけを使った場合で、LINE の中に仕組みを足せば人ごとに取れます。友だち追加の直後に「どこで知りましたか」と聞くボタンを置く、追加後に送るリンクを人ごとに変えて押した人を記録する、といった方法もあります（比べ方は友だち追加経路の付け方の記事にまとめています）。リードに「どこから来たか」を載せたいなら、型①の説明にある LIFF URL の追加情報などで、自社の入口を分けて持ちます。

重複は、作る前に突き合わせる：標準の一致ルールだけでは足りない

LINE の問い合わせは、同じ人が何度も来ます。友だち追加し直す人、LIFF のフォームを2回送る人、すでに取引先責任者として登録されている人。リードを作る前に、既存のリードと取引先責任者を探します。

標準のルールは、メール単独では照合しない

Salesforce には、標準のリード重複ルール（Standard Lead Duplicate Rule）があります。2017年の夏のリリース以降に作られた組織では、リード同士に加えて、リードと取引先責任者の照合も含みます。作成時の既定の動作は「許可」で、重複の可能性をアラートで知らせたうえで、作成は止めません（Standard Lead Duplicate Rule）。

問題は、その中の一致ルールの式です。標準のリード一致ルールは、「姓・名・メール」「姓・名・電話」「姓・名・役職・会社名」のように、姓と名を軸にした組み合わせで照合します。メールだけで照合する式はありません。空欄の項目は原則「一致しない」扱いですが、姓と名の列には例外があり、メールを含む組み合わせでは空欄を無視します（Standard Contact Matching Rule and Standard Lead Matching Rule）。つまり、フォームで姓とメールを聞いていれば、名が空でも、既存の「姓＋メール」に当たります。拾えないのは、姓の表記が既存のレコードと違うときです。表示名やニックネームを姓に入れた、既存が別の表記になっている、といった場合です。

姓が違ってもメールが同じなら同じ人、という照合にしたいときは、一致ルールを自分で作ります。Setup の「一致ルール（Matching Rules）」で、対象のオブジェクトと照合する項目を選び（最大10項目）、有効にします。有効にしたルールは、重複ルールと重複ジョブで使えます（Customize Matching Rules）。重複ルールには、動作（アラートかブロックか）と、照合するオブジェクトの組み合わせを設定します（Customize Duplicate Rules）。

API で書くときは、重複が見つかったときの動きを決めておく

受け口から API でリードを作るときは、Duplicate Rule Header（REST API は バージョン52.0以降）で、重複ルールの動きを指定できます。allowSave は、重複ルールでアラートが有効なとき、アラートを無視して重複したレコードを保存するか（true）、保存を止めるか（false）を決めます。includeRecordDetails は、重複と判定されたレコードの全項目を返すか、IDだけを返すか、runAsCurrentUser は、現在のユーザーの共有ルールで照合するかどうかを決めます。REST API ではどれも既定は false です（REST API の Duplicate Rule Header、SOAP API の DuplicateRuleHeader）。

標準のリード重複ルールの、作成時の既定は「許可（アラート）」でした。この状態の重複ルールに、ヘッダーを付けずに重複するリードを書くと、保存は止まります。受け口には、そのときの経路が要ります。経路は3つに分けます。ユーザーIDが一致していれば、既存のレコードを更新する。メールだけが一致していれば、保存せず担当者の確認の一覧に回す。どちらも一致しなければ、新しく作る。

リードを取引先責任者に変換するときも、照合の対象が違う

営業がリードを変換して既存の取引先に結ぶとき、既存の取引先責任者の候補が画面に出るのは、取引先責任者の一致ルールが姓・名を評価している場合です。候補が出ないときは、取引先責任者側の一致ルールが名前を見ていないことが多い、と Salesforce は案内しています（ナレッジ記事 000382137）。リード側だけでなく、変換の相手側のルールも確かめておきます。

営業への引き渡し：割り当てルールで渡し、通知は別に作る

リードができたら、オーナー（担当者かキュー）を決めます。Salesforce のリードの割り当てルールは、条件を並べた行を上から順に評価し、最初に当てはまった行でオーナーが決まります。どの行にも当てはまらなかったリードは、Web-to-Lead の既定の担当者や、インポートした管理者に回ります。最後の行を条件なしの受け皿にしておくと、決まらないリードが出ません（Set Up Assignment Rules）。

REST API でリードを作るとき、Sforce-Auto-Assign ヘッダーを付けなければ、有効な割り当てルールが適用されます。FALSE を指定すると適用されず、割り当てルールのIDを指定すると、そのルールが使われます（Assignment Rule Header）。

ここに落とし穴があります。割り当てルールの行に通知メールのテンプレートを指定しても、API で作られたリードは、割り当てられても通知メールが送られません。REST API では、通知メールを出すための EmailHeader が使えないためで、Salesforce は、Flow か Apex のトリガーで別にメールを送ることを案内しています（ナレッジ記事 000384839）。キューに割り当てた場合の通知は、キューのメールアドレスとキューのメンバーに送られる設定です（Set Up Assignment Rules）。通知を担当者に届ける仕組みは、受け口の側で用意するものと考えて設計します。

通知を出したあとも、担当者がリードをまだ開いていないことは分かります。リードの IsUnreadByOwner は、割り当て済みでまだオーナーが開いていないときに true になる項目です（Lead オブジェクトリファレンス）。これで絞った一覧を、営業責任者が見る運用にすると、通知が届かなかったリードを拾えます。

最初の返信は、LINE で返すか、メールで返すか

LINE で返すか、メールで返すかは、通数と同意で変わります。メッセージイベントに対する応答メッセージは、料金プランの通数に数えられません。担当者があとから送るプッシュメッセージは通数に数えられます（Messaging APIの料金）。メールで連絡する場合は、LINE の規約が、LINE ユーザー情報に含まれる連絡先で連絡するときは事前に本人の同意を取るよう求めています（ユーザーデータポリシー 3.2.11）。

最初の1通を自動応答で返す設計もあります。フォームを送った直後に、受け付けたことと次の連絡の手段を LINE で返す形です。いつまでに担当者から連絡するかの約束は、営業の体制に合わせて自社で決める値で、LINE や Salesforce の仕様が決めるものではありません。

ブロックは、Salesforce に戻す

ユーザーがブロックすると、フォロー解除イベントが届きます。ブロックしたユーザーには、プッシュメッセージは届かず、通数にも数えられません（Messaging APIの料金）。担当者がリードの画面で「LINE で連絡できる状態か」を見られないと、届かない返信を待つことになります。受け口でフォロー解除を受けたら、リードか取引先責任者の友だち状態の項目を更新し、ブロック解除でフォローイベントが届いたら戻します。受け口の作り方（署名の検証、イベントの保存、重複の除去、失敗したときの再試行）は「LINE × Slack連携」に譲ります。

同意は、問い合わせへの対応・連絡・LINE の配信を分けて記録する

LINE で聞いた情報を Salesforce に持つことへの同意と、その後に連絡や配信をすることへの同意は、別のものです。分けておかないと、フォームを送った人の全員に、営業メールや配信を送ってよいのかが、後から分からなくなります。

Salesforce では、リードに「Email Opt Out（HasOptedOutOfEmail）」の項目があり、Salesforce からのメールを受け取りたくないかどうかを持てます（Lead オブジェクトリファレンス）。Setup の「Data Protection and Privacy」で「データ保護の詳細をレコードで使えるようにする」を有効にすると、Individual オブジェクトを使えるようになり、リードにつなげられます（IndividualId）。Individual には、勧誘しない（HasOptedOutSolicit）、個人データを処理しない（HasOptedOutProcessing）、追跡しない（HasOptedOutTracking）、忘れてほしい（ShouldForget）などの項目があります（Set Up Tracking and Storage of Certain Data Privacy Preferences、Individual オブジェクトリファレンス）。

退会と削除の入口も、設計に入れておきます。LINE の規約は、本人から開示・訂正・削除・利用停止を求められたら対応すること、アカウントを紐付ける場合は連動を解除する機能と退会の機能を提供することを求めています（ユーザーデータポリシー 3.5.3・3.2.10）。利用目的の文面、保存してよい期間、勧誘の可否は、法務の部門と先に合わせてください。この記事は、その内容を決めるものではありません。

入れ先が Salesforce でないときに変わること

入れ先が HubSpot・kintone・スプレッドシートの場合、変わるのは主に、重複を判定する仕組みと、ユーザーIDの置き場です。

どの入れ先でも、「ユーザーIDを照合の第一のキーにする」「メールの一致は担当者の確認に回す」「同意は連絡の目的ごとに分ける」は変わりません。変わるのは、そのキーでの更新を、入れ先がどの機能で受けてくれるかです。連携ツールの機能と料金は、各社の公式の資料で確かめてください。台帳の側の作り方の比べ方は「LINEと今の顧客管理をつなぐ3つの作り方と、費用が決まる所」にまとめています。

Aurant Technologies では、LINE の問い合わせを営業にどう渡すかの設計について、LINE運用・伴走支援のページから相談できます。