LINEのアカウント連携解除｜ブロック・退会との違いと確認項目

LINEと自社サービスの会員アカウントを連携するなら、お客さんが後から連携を解除できる導線も必要です。LINEの公式資料では、いつでも解除できるようにし、連携時に解除できることを通知するよう求めています。

解除する場所や操作は、利用しているサービスの実装によって異なります。この記事は、すべてのLINE公式アカウントに共通する解除ボタンを紹介するものではなく、事業者が解除の画面と、その後の情報の扱いを設計するための確認事項です。

連携解除・ブロック・退会を同じ操作にしない

連携解除で外すのは、LINEのユーザーと、自社サービスの会員を結び付ける関係です。自社サービスを退会することや、予約・注文を取り消すことまで、同じ操作に含めるとは限りません。

操作	設計時に分けて説明すること
連携解除	LINEと会員情報の対応を外し、何が利用できなくなるか
ブロック	LINE側の操作であり、会員退会や注文取消の受付と混同しないこと
会員退会	自社サービスの契約・利用終了として、別途条件と確認があること
予約・注文の取消	個別の予約・注文を取り消す操作として、結果を確認すること

たとえば「連携解除」を押した利用者が、翌日の予約も消えたと思うと、来店や連絡が食い違います。解除画面には、残る予約・注文の扱いと、取消が必要な場合の行き先を示します。残存データの削除や保管期間も、サービスの方針に沿って別に説明してください。

お客さんが設定を何画面も探したり、解除のためだけに長い説明を送り直したりしなくて済むようにします。一方で、会員情報を変える操作なので、必要な本人確認や最終確認は省けません。

解除前の画面では、対象の連携、使えなくなる表示・通知、残るサービスの扱いを短く確認できる形にします。画面を見ただけで「どの会員との連携を解除するのか」が分からない場合は、先にその表示を直します。会員の詳細を不要に開示しない範囲で識別できることが条件です。

連携解除の確認順の設計例。対象の連携と影響を本人が確認し、サービス側で連携を無効にする。会員表示と送信予定の通知を見直し、解除完了と残る予約・注文の確認先を示す。

図：解除後の表示と通知まで確認するサービス側の設計例です。会員退会や予約取消が自動で行われるという意味ではありません。

公式資料では、連携状態に応じてユーザー別のリッチメニューを切り替える例も示されています。ただし、メニュー画像を変えただけでは、会員情報へのアクセスが止まったことにはなりません。個別リッチメニューの優先関係も確認し、画面とサーバーの状態を揃えます。

サービス側で連携を無効にしたら、次の表示と処理を点検します。

通知については、連携が必要な案内と、連携を使わない一般的な案内を分けます。すべての通知が自動的に止まると約束するのではなく、サービスとして何を停止するのかを明示します。送信直前にも現在の連携状態を確認する設計なら、解除前に用意した処理が残る問題を減らせます。

顧客情報を一つのIDへつなぐことは、解除後も無条件に使い続ける理由にはなりません。情報をつなぐ目的と、利用できる状態を合わせて判断します。複数のIDを扱う基本は顧客データ統合の設計を参照してください。

再び連携する場合、以前の対応関係を見つけただけで勝手に復活させないようにします。現在の会員へのログインと、LINE側の連携確認を通して、どのアカウントを結び付けるかを改めて確かめます。

公式のアカウント連携手順では、LINE側と自社サービス側を確認する流れが案内されています。連携解除と再連携も、その確認を前提としたサービスの状態遷移として扱います。

まずは解除操作を一回行った後に、会員情報の表示、送信予定の通知、残る予約・注文の案内を確認してください。「解除しました」という表示だけで終えず、実際の利用状態と一致することまで点検します。

仕様確認：2026年10月7日。解除後の画面・通知・再連携の説明は設計上の提案であり、LINEの標準機能だけですべて実現するという主張ではありません。