LINEグループの参加・退出をCRMへ反映するには｜メンバーとBotの退出を分ける

LINEグループで人が参加・退出したことと、公式アカウントのBot自身が退出したことは、別のWebhookイベントです。CRMへ反映するときは、どのグループの、誰の参加状態が変わったかを確認します。メンバーの退出だけで、顧客の退会や契約終了まで確定してはいけません。

既存のグループへの招待方法は、Botを参加させる設定と返信先の話です。本稿は、参加後に人の出入りを受信し、外部の台帳へ誤って反映しないための実装・運用を扱います。

まず、三つのイベントを区別する

Messaging APIの公式リファレンスでは、Botがメンバーになっているグループトークまたは複数人トークへ、ユーザーが参加したことをmemberJoinedで通知します。参加したユーザーはjoined.membersという配列に入ります。

メンバー退出イベントはmemberLeftで、退出したユーザーをleft.membersの配列で扱います。一つのイベントに含まれる対象を一人と決め打ちせず、配列内の各対象を確認する設計にします。

一方、退出イベントのleaveは、公式アカウントがグループから削除されたか、グループ・複数人トークから退出した場合です。人が一人抜けた通知と混同すると、グループ全体を使えなくしたり、残っている人の案内を止めたりする誤りにつながります。

図：三つのイベントは順番ではなく、起きたことによる分岐です。台帳の更新方法は自社の設計例であり、公式APIがCRMを自動更新する機能ではありません。

図解画像を開く（保存用）

グループのIDと、対象になった人のIDを照合する

グループの場合、会話の場所はsource.groupIdで確認し、参加・退出した人はmembers配列内のuserIdで確認します。複数人トークなら会話の場所はroomIdです。場所のIDを一人の顧客IDとして登録しないでください。

台帳は「グループと人の参加関係」と「顧客本人の記録」を分けます。同じ人が複数の相談グループへ参加しても、グループを一つ退出しただけで、その人の顧客情報すべてを消す必要があるとは限りません。逆に、新しく入った人へ、既存顧客と同じ閲覧権限を無条件で付ける根拠にもなりません。

照合できる記録がなければ、名前から推測して別人の台帳を変更せず、確認待ちにします。IDがどのシステム・チャネルの範囲で使われるかは、LINEログインとMessaging APIのユーザーIDも確認できます。

受信した順番だけで、現在の状態を決めない

Webhookには再送があり、受信した順序とイベントの発生順序が異なる場合があります。公式の受信ガイドと共通プロパティを踏まえ、同じイベントを二重反映しないことと、古い状態へ戻さないことを別々に設計します。

たとえば、参加後に退出した人について、遅れて届いた参加イベントで再び参加中に戻してしまわないかを確認します。前後関係を扱う際はtimestampを参照し、照合結果が不明な場合の確認方法も決めます。再送対策の基本はWebhookの重複処理を防ぐ設計で整理しています。

受信前には署名の検証を維持します。参加者一覧をそろえるために、署名検証を無効にしたり、ログへ顧客の会話本文や認証情報を広く残したりする必要はありません。

参加状態の変更から、顧客の意思を推測しない

以下は架空の運用例です。家族と担当者が日程を相談するグループで、連絡担当者が一人退出しても、予約そのものを取り消したとは限りません。グループでの連絡が必要なら、権限のある担当が、誰へどの窓口で確認するかを判断します。

Bot自身が退出した場合も、以前のグループIDが残っていることを、今も連絡できる根拠にしません。進行中の相談をどう引き継ぐかを確認します。個別の支払いや予約情報を、残ったグループ全員へ自動で送る対応は避けてください。

保管しているデータの削除や利用停止は、適用する方針と本人からの依頼を別に確認します。参加イベントだけから、顧客の同意・退会・契約終了まで読み取れるとは説明しません。

公開前は、同じ人の参加・退出・再参加で確かめる

許可されたテスト用グループと担当者で、人の参加、退出、再参加、Bot自身の退出を区別して確認します。台帳で変わる参加関係と、変更しない予約・契約の記録を、あらかじめ決めておきます。

再送や順序が前後する場合、複数の対象が配列に入る場合、元の顧客を照合できない場合も試験項目にします。担当が同じ人の文脈を引き継げることと、別の人やグループの情報を混ぜないことを両方確かめてください。

※仕様確認日：2026年10月20日。台帳への反映は設計例であり、特定製品の提供機能や顧客への導入実績を示しません。