LINE公式アカウントで受けた問い合わせを、SalesforceやkintoneなどLINE以外の業務システムへ自動で登録する。こうした連携を入れたあとに起こりやすいのが、「同じ問い合わせが2件登録されている」「届いたはずの問い合わせが登録されていない」という事態です。
この記事では、なぜそれが起こるのかをLINEの仕様から確認し、連携先ごとの防ぎ方と、発注・検収のときに確かめたい点を整理します。
結論：重複と抜けは「起こる前提」で設計します
【事実】LINE Developersの公式資料では、ネットワーク経路上の問題などにより、同じWebhookイベントが重複して送信される可能性があると案内されています。また、受信の順番がイベントの発生順と異なる場合があることも示されています。（出典：メッセージ（Webhook）を受信する）
【評価】つまり、「1回届いたら1件登録する」という素直な作りのままでは、二重登録は仕様上起こりえます。一方で、連携先のシステムが一時的に止まっていれば、登録されないまま終わる問い合わせも出ます。重複と抜けの両方を、最初から想定しておく必要があります。
二重登録が起こる3つの経路
1. 同じWebhookイベントが2回届く
【事実】LINEは、同じWebhookイベントを重複して送る可能性があるため、Webhookイベントに含まれるwebhookEventIdを使って重複を検出するよう案内しています。（出典：同上）
【評価】連携の処理では、受け取ったwebhookEventIdを記録し、同じIDが再び届いたら登録をしない、という確認を入れます。
2. 再送を有効にしたときの再送
【事実】LINEには、受け取りに失敗したWebhookを再送する機能があり、初期状態では無効です。有効にすると、ボットサーバーがステータスコード200番台を返さなかった場合に、一定期間内で再送されます。再送されたイベントにはdeliveryContext.isRedeliveryがtrueで入り、webhookEventIdは元のイベントと同じです。（出典：同上）
【評価】再送は抜けを減らすのに役立ちますが、処理は成功していたのに応答だけが遅れた場合などには、同じイベントがもう一度届きます。再送を使うなら、1の重複確認は必須です。
3. 同じ人から、別の問い合わせとして2回届く
【評価】利用者が送信ボタンを2回押す、返事がないので同じ内容を送り直す、といった場合は、LINE上は別のイベントです。webhookEventIdでは防げないため、「同じ人の問い合わせか」をLINEのユーザーIDで判定し、顧客の記録は1件にまとめ、問い合わせの記録は内容と時刻で人が確認できるようにします。
登録漏れが起こる経路
- 連携先のシステムがメンテナンス中、またはAPIの利用上限に達していて、登録が失敗した
- 処理に時間がかかり、LINEへの応答が遅れた
- エラーが起きても、誰にも知らされずに終わった
【事実】LINEは、ボットサーバーが200番台のステータスコードを返さなかった場合を受け取りの失敗として扱い、再送を有効にしていれば再送の対象にします。また、後続のリクエストが待たされるのを防ぐため、イベントの処理は非同期で行うことを推奨しています。再送の機能は確実な届け出を保証するものではなく、再送の件数が急増した場合には再送の設定が強制的に無効になる可能性があるとも案内されています。（出典：同上）
【評価】そのため、「受け取ったらすぐ応答し、登録は別に処理する」「登録に失敗したものは記録して、担当者に知らせる」「あとから再登録できる」という3点を、連携の作りに入れておきます。LINEの再送だけに頼らないことが大切です。
連携先ごとの、重複を防ぐ仕組み
重複を考えるときは、二つを分けます。同じWebhookイベントの再受信を見分けるキーはwebhookEventIdです。一方、同じ利用者の顧客情報を照合するキーには、LINEのユーザーIDを使います。表示名は利用者が変更できるため、照合キーには向きません（詳しくはLINE公式アカウントと顧客管理システムを連携する前に決めたいことで解説しています）。同じ利用者が別の問い合わせを送った場合は、顧客情報を一つにまとめても、問い合わせの記録まで一つにまとめるかは業務ルールとして決めます。
Salesforce
【事実】カスタム項目に「外部ID」を設定すると、その値をもとに、レコードがなければ作成し、あれば更新する（upsert）ことができます。組織で有効にしている重複ルールは、APIからの登録・更新でも確認に使われます。（出典：Upsert Records Using sObject Rows by External ID、Duplicate Rule Header）
【評価】ただし、取引開始（コンバート）が済んだリードは更新できません。取引開始後にまた連絡が来る人に備えて、取引先責任者の側にもLINEのユーザーIDを持たせ、そちらで照合する設計にしておきます。
kintone
【事実】複数のレコードを更新するAPIでは、レコード番号の代わりにupdateKeyで対象を指定でき、UPSERTモードにすると、該当するレコードがあれば更新、なければ新しく登録します。updateKeyに指定できるのは、重複禁止を設定した「文字列（1行）」または「数値」フィールドで、UPSERTモードではレコード追加の権限も必要です。（出典：複数のレコードを更新する）
【評価】顧客のアプリにLINEのユーザーIDのフィールドを作って重複禁止にしておけば、同じ人のレコードが2件できることを、kintone側でも防げます。
HubSpot
【事実】コンタクトは、一意の値を持つプロパティをidPropertyに指定して、作成と更新をまとめて行えます（upsert）。メールアドレスのほか、一意の値を持つカスタムプロパティも使えます。（出典：Upsert contacts）
【評価】LINEだけの問い合わせではメールアドレスが分からないことが多いため、LINEのユーザーIDを入れる一意のカスタムプロパティを用意する形が合います。
Googleスプレッドシート
【事実】Google Apps ScriptのLockServiceを使うと、複数の処理が同時に同じ部分を実行しないようにできます。（出典：Lock Service）
【評価】スプレッドシートには、重複を止める仕組みが標準ではありません。また、Google Apps ScriptのWebアプリで直接Webhookを受けると、リクエストのヘッダーを受け取れず、LINEの署名を確認できません（Web Apps）。Webhookは署名の確認とすぐの応答ができる連携サーバーで受け、スプレッドシートへの書き込みを任せる構成にします。そのうえで、書き込みの部分をロックで1件ずつにし、書き込む前にwebhookEventIdやユーザーIDがすでにあるかを確かめます。
発注・検収のときに確認したい5つのこと
- 重複を判定するキーは何か（LINEのユーザーID、
webhookEventIdなど） - 同じWebhookが2回届いたとき、どう動くか（実際に試したか）
- 連携先のシステムが止まっていたとき、問い合わせはどこに残るか
- 登録に失敗したことを、誰が、どうやって知るか
- 失敗した分を、あとから登録し直す手順があるか
【評価】画面上でLINEから業務システムに登録されることを確認しただけでは、この5つは確かめられません。見積もりや検収の段階で、答えが用意されているかを確認しておくと安心です。
まとめ
- LINEのWebhookは、同じイベントが重複して届くことがあり、順番が入れ替わることもある
- イベントの再受信は
webhookEventId、顧客の照合はLINEのユーザーIDで分けて考える - 抜けは「すぐ応答・別に登録・失敗を知らせる・再登録できる」で防ぐ
- Salesforce・kintone・HubSpotには、キーで作成と更新を切り分ける仕組みがある。スプレッドシートはロックと事前確認で補う
和-Nodeでは、連携が動いたあとに二重登録や登録漏れが起きないかを、構築の段階で確認してからお渡ししています。今の連携や見積もりの内容で気になる点があれば、初回30分の無料相談でお聞かせください。