Shopify LINE連携の運用設計｜CRM・顧客対応・配信自動化がズレない作り方

ShopifyとLINE連携を調べると、LINE公式アカウントの作成、Messaging APIチャネル、LINEログインチャネル、連携アプリの設定手順が多く出てきます。

たとえば、Shopify App StoreのCRM PLUS on LINEの掲載では、LINE ID連携、Shopifyの顧客・購買データに基づく配信、チェックアウトリマインド、再入荷通知、発送通知、Shopify Flow連携、カスタマーサポートなどが紹介されています。

また、TSUMUGUの記事でも、ShopifyとLINE連携の全体像として、LINE公式アカウント、LINE ID連携、連携アプリを組み合わせる考え方や、カゴ落ち通知、ステップ配信、セグメント配信、問い合わせ対応が整理されています。

ここまでは導入の入口として重要です。

しかし、LINE連携を売上と顧客対応に使い始めると、別の問題が出ます。

• LINE友だちは多いが、Shopify顧客と紐づいていない
• カート、チェックアウト、注文、発送のどれを配信起点にするか曖昧
• 購入済み顧客に初回購入クーポンを送ってしまう
• LINEで問い合わせが来ても、Shopifyの注文履歴をすぐ確認できない
• ブロック済み、未連携、配信失敗の顧客が同じセグメントに混ざる

これらは、LINE連携アプリの設定ミスだけではありません。

Shopifyの顧客データ、購買イベント、同意状態、配信ログ、問い合わせ対応を、1つの運用として設計していないことが原因です。

Shopify LINE連携で先に決めるべきなのは、どのアプリを入れるかではなく、LINE ID、Shopify顧客、配信同意、購買イベント、CS履歴をどう結び直すかです。

先に結論：LINE連携は配信設定ではなく顧客運用の設計

ShopifyとLINEを連携するときは、最初に次の5つを決めます。

決めること	具体的に見る点
顧客の紐づけ	Shopify customer ID、メール、電話番号、LINE user ID、会員IDをどう対応させるか
イベントの使い分け	カート、チェックアウト、注文、支払、発送、問い合わせのどれを配信起点にするか
セグメントの正本	Shopify顧客タグ、CRM側セグメント、LINE側オーディエンスのどれを正式な条件にするか
同意とブロック	メール同意、LINE友だち、LINE ID連携、ブロック、配信停止をどう分けて扱うか
失敗時の対応	配信失敗、ID連携解除、重複顧客、問い合わせ未紐づけを誰が直すか

LINE連携は「メッセージを送れるようにする」だけなら簡単です。

実務で必要なのは、購入前、購入後、問い合わせ時に、顧客の状態に合った接点を作ることです。

そのためには、LINE公式アカウントを通知チャネルとして見るだけでなく、ShopifyのCRMとCSの入口として設計します。

ShopifyとLINE連携でできること

ShopifyとLINE連携でできることは、大きく分けると次のようになります。

領域	できること	設計で注意すること
友だち追加	ストア、注文完了ページ、マイページ、リッチメニューからLINEへ誘導する	友だち追加だけではShopify顧客と紐づかない
LINE ID連携	Shopify顧客とLINE user IDを紐づける	メール、電話、会員IDとの重複解消が必要
カゴ落ち・チェックアウト離脱	カート投入やチェックアウト開始後の未購入者へリマインドする	配信対象を未購入、同意あり、ブロックなしに絞る
購入完了通知	注文完了後にLINEで通知する	Shopify標準メール、LINE通知、SMSの重複を避ける
発送通知	発送完了や追跡番号をLINEで送る	フルフィルメント単位、分割発送、追跡番号未登録を扱う
セグメント配信	購入履歴、顧客タグ、商品カテゴリで配信対象を絞る	タグ命名、更新タイミング、同意状態を整える
問い合わせ対応	LINEで問い合わせを受け、注文履歴や顧客情報と照合する	CSツール、Shopify顧客、LINE会話履歴の紐づけが必要

Shopify Flowの対応アプリ一覧でも、CRM PLUS on LINEではチェックアウト、カート、商品閲覧のリマインド、購入・発送通知、Shopify顧客データに基づく配信、Shopify Flowを使った他アプリとの連携が説明されています。

つまり、LINE連携は販促だけではありません。

購入前のリマインド、購入後の通知、問い合わせ対応、顧客タグ運用、ロイヤルティ施策まで含む接点です。

LINE公式アカウント、LINE ID連携、連携アプリの役割分担

LINE連携の設計では、登場人物を分けます。

要素	主な役割	運用で決めること
LINE公式アカウント	顧客とのトーク、配信、リッチメニュー、問い合わせ窓口	誰が配信し、誰が問い合わせを見るか
Messaging APIチャネル	メッセージ送信、Webhook受信、Bot連携	Webhook URL、送信失敗、API制限、ログ管理
LINEログインチャネル	顧客のLINEログイン、ID連携、プロフィール取得	Shopify顧客とLINE user IDの対応、同意取得
連携アプリ	ShopifyとLINEの橋渡し、配信、ID連携、Flow連携	どこまでアプリ標準機能に任せるか
Shopify	顧客、注文、商品、カート、チェックアウト、発送の正本	どのイベントをLINEへ渡すか
CSツール	問い合わせの担当、ステータス、履歴管理	LINE会話とShopify注文をどう紐づけるか
外部CRM	LTV、会員ランク、メール、広告、ポイント管理	ShopifyタグとCRMセグメントの境界

LINE DevelopersのMessaging APIリファレンスでは、Webhookはユーザーが友だち追加したりメッセージを送ったりしたときに、LINE PlatformからWebhook URLへHTTPS POSTされる仕組みとして説明されています。

LINE Developers: Messaging API reference

また、LINE Login APIでは、ID tokenの検証、ユーザー情報の取得、プロフィール取得、友だち状態の確認などが用意されています。

LINE Developers: LINE Login v2.1 API reference

ここで重要なのは、LINE user IDを取得できることと、Shopify顧客を正しく運用できることは別だという点です。

メールアドレス、電話番号、Shopify customer ID、LINE user ID、会員ID、注文番号がそれぞれ別の役割を持ちます。これらを同じものとして扱うと、重複顧客や誤配信が起きます。

データの流れを先に描く

LINE連携では、次のような流れを先に描くと設計しやすくなります。

Shopify顧客
  ↓ LINE ID連携
LINE user ID / 友だち状態 / 同意状態
  ↓
CRM PLUS on LINE または連携基盤
  ↓
Shopify Flow / LINE公式アカウント / 外部CRM / CSツール
  ↓
配信ログ / 問い合わせ履歴 / 失敗キュー / 手動補正

Shopifyイベント
  ├─ カート
  ├─ チェックアウト
  ├─ 注文
  ├─ 支払
  ├─ 発送
  └─ 問い合わせ
      ↓
LINE配信・通知・CS対応

この流れで見ると、LINE連携には2種類のデータがあります。

1つ目は、顧客を特定するためのデータです。メール、電話、LINE user IDを同じものとして扱うと、重複顧客や誤配信が起きます。

データ	役割	注意点
Shopify customer ID	Shopify上の顧客正本	メール変更や電話変更があっても変わらない
メールアドレス	注文、会員登録、メール配信で使う	家族共有、別メール購入、入力ミスがある
電話番号	配送、本人確認、LINE通知対象の補助に使う	表記ゆれ、配送先電話との違いがある
LINE user ID	LINE配信や会話の対象を特定する	チャネル単位のIDとして扱う
会員ID	外部CRM、ポイント、店舗連携で使う	Shopify側にない場合はメタフィールドや外部DBで扱う
注文番号	購入・発送・問い合わせの参照キー	顧客の本人性そのものにはしない

2つ目は、配信やCS判断に使う状態データです。

状態	意味	使い方
LINE友だち	LINE公式アカウントを追加している	一斉配信や問い合わせ入口の対象になる
LINE ID連携済み	Shopify顧客とLINE user IDが対応している	購入履歴に基づく個別配信が可能になる
配信同意あり	マーケティング配信を送ってよい	キャンペーンや販促配信の条件にする
ブロック中	LINE配信できない	配信対象から除外し、CS対応時に状態を表示する
購入済み	注文履歴がある	初回施策、リピート施策、CS優先度に使う
問い合わせ中	未解決のCSチケットがある	販促配信より対応を優先する

この2種類を分けずに「LINE連携済み」という1つのタグだけで管理すると、すぐに破綻します。

カート、チェックアウト、注文、発送イベントの使い分け

Shopifyのイベントは、LINE配信の起点になります。

ただし、すべてを同じ「購入前後の通知」として扱うと、顧客体験が悪くなります。

イベント	代表的な使い方	配信前に見る条件
商品閲覧	閲覧商品に関連するレコメンド	ID連携済み、過剰配信なし、興味カテゴリが明確
カート投入	カート内商品のリマインド	直後に注文済みでない、在庫あり、ブロックなし
チェックアウト開始	チェックアウト離脱のリマインド	購入未完了、同意あり、一定時間経過
注文作成	購入完了通知、初回購入タグ付け	支払状態、キャンセル、不正疑いの確認
支払確定	会員ランク更新、購入後シナリオ開始	返金前提の注文や未払い注文を除外
発送完了	追跡番号通知、到着後フォロー	分割発送、追跡番号、配送会社を確認
返品・返金	フォロー停止、セグメント除外	購入済みタグやVIP条件を更新する
問い合わせ	CSチケット作成、注文照会	LINE user IDとShopify顧客の照合

カートは「商品を検討している状態」、チェックアウトは「購入手続きを始めた状態」です。注文作成と支払確定も分けます。未払い注文、不正疑い、キャンセル、後払いがある場合、注文作成だけで購入後シナリオを始めると、後続の配信や顧客タグがズレます。

受注、在庫、出荷、会計まで含めたイベント設計は、Shopify API連携の設計方法でも整理しています。LINE配信も、基本は同じです。どのデータを正本にし、どのイベントで動かすかを先に決めます。

顧客タグ、セグメント、同意管理をどう設計するか

Shopifyにはタグ機能があります。Shopify公式ヘルプでも、タグは商品、顧客、注文などの管理に使え、顧客タグをもとに動的な顧客セグメントを作れると説明されています。

Shopify Help Center: Creating and using tags in Shopify

ただし、LINE連携でタグを使う場合は、命名ルールを決めないとすぐに読めなくなります。

タグ種別	例	使い方	注意点
ID連携状態	line_linked, line_unlinked	LINE配信の可否確認	ブロック状態とは分ける
同意状態	line_optin, line_no_marketing	販促配信の除外条件	法務・プライバシー方針と合わせる
ライフサイクル	first_purchase, repeat_customer, vip	購入後シナリオ、優先CS	返金・返品時の更新ルールが必要
商品カテゴリ	cat_skincare, cat_coffee	関心カテゴリ配信	商品タグと顧客タグを混ぜない
キャンペーン	cp_202607_summer	期間限定配信、効果検証	終了後の削除や期限管理が必要
CS状態	cs_open, cs_complaint, cs_waiting	問い合わせ中の販促抑制	CSツール側の状態と二重管理しない
連携エラー	line_sync_error, line_delivery_failed	手動確認リスト	恒久タグにせず解消時に外す

タグは便利ですが、タグだけで顧客状態をすべて表現しようとすると危険です。LINE user ID、詳細な配信ログ、問い合わせ本文、配信失敗のエラー本文は、タグではなく連携アプリ、CRM、外部DB、CSツール側のフィールドとして扱います。

LINE配信のセグメントは、タグを増やすことではなく、配信してよい人、送るべき人、送らない方がよい人を分けることです。

LINE連携済み顧客と未連携顧客の分岐

Shopify LINE連携では、すべての顧客が同じ状態になるわけではありません。

最低でも、次の分岐を作ります。

顧客状態	配信・対応方針
LINE友だちだがShopify未連携	一斉配信や連携促進は可能。購入履歴ベースの個別配信はしない
Shopify顧客だがLINE未友だち	メール、マイページ、注文完了ページでLINE連携を案内する
LINE ID連携済みかつ同意あり	購入履歴、タグ、カート、発送に応じた配信対象にできる
LINE ID連携済みだが販促同意なし	注文・発送など必要通知に限定し、キャンペーン配信から除外する
ブロック中	配信対象から外し、CS画面ではLINE連絡不可として表示する
重複顧客候補	自動配信を保留し、メール・電話・注文履歴で確認する

よくある失敗は、「LINE友だち」と「LINE ID連携済み」を同じ意味で扱うことです。

友だち追加だけでは、誰がShopifyで何を買ったかは分かりません。逆に、Shopify顧客側にLINE IDが紐づいていても、ブロック中なら配信できません。

LINE DevelopersのWebhookドキュメントでは、ユーザーがLINE公式アカウントを友だち追加またはブロック解除したときのFollow event、ブロックしたときのUnfollow eventが説明されています。

LINE Developers: Receive messages webhook

友だち追加、ID連携、販促同意、ブロック、直近配信成功、CS対応中は、それぞれ別の状態として扱います。これを1つのタグだけで表現しないことが重要です。

重複顧客、ブロック、配信失敗が起きた時の運用

LINE連携は、正常系だけを見ると簡単に見えます。

実際には、次のような例外が起きます。

例外	起きること	対応方針
同じ人が別メールで購入	Shopify顧客が複数できる	メール、電話、配送先、LINE user IDで統合候補を出す
家族名義で注文	注文者とLINE利用者が違う	LINE配信は本人確認済みの顧客だけに限定する
ブロックされた	配信できない	ブロック状態を反映し、再送対象から外す
ID連携解除	購入履歴ベースの配信ができない	顧客タグやCRMセグメントから除外する
配信失敗	通知やリマインドが届かない	エラー種別、対象顧客、再送可否をログ化する
注文キャンセル後の配信	キャンセル済み顧客に購入後案内が届く	注文状態を再確認して配信前に除外する
返品後もVIPタグが残る	不適切な優遇や配信になる	返金・返品時のタグ更新ルールを作る

配信失敗時は、単に再送すればよいとは限りません。購入完了通知や発送通知は再送候補になりますが、カゴ落ち配信やキャンペーン配信は、時間が経つと価格や在庫、期限が変わっている可能性があります。

配信種別	失敗時の扱い
注文完了通知	顧客体験上必要なら再送候補にする
発送通知	追跡番号と配送状況を確認して再送する
カゴ落ち通知	一定時間を過ぎたら再送しない
再入荷通知	在庫が残っている場合だけ再送する
キャンペーン配信	期限、対象条件、配信回数を確認して判断する
CS返信	配信失敗を担当者へ通知し、メールや電話へ切り替える

この判断を連携アプリの管理画面だけで完結できるとは限りません。

配信ログ、失敗キュー、手動補正リストを用意し、EC担当、CS担当、開発担当が同じ状態を見られるようにします。

LINEで顧客対応する場合のCRM・CSツール連携

LINE連携をCSに使う場合、販促配信とは別の設計が必要です。

LINEで問い合わせを受けると、顧客は「自分の注文を分かってくれている」と期待します。しかし、担当者の画面にLINE名だけが表示され、Shopifyの注文履歴が見えない状態では対応できません。

CS対応で必要な情報	理由
Shopify顧客ID	注文履歴、住所、メール、電話を確認する
LINE user ID	LINE会話とShopify顧客を紐づける
直近注文	問い合わせ対象の注文を早く特定する
発送状況	追跡番号、配送会社、発送日を確認する
返品・返金状況	返金済み、返品受付中、検品待ちを確認する
顧客タグ	VIP、初回購入、問い合わせ中、クレーム対応中などを見る
配信履歴	どのキャンペーンや通知を見て問い合わせたか確認する

重要なのは、CS対応中の顧客に販促配信をそのまま送らないことです。

たとえば、返品相談中の顧客に同じ商品の再購入クーポンを送る、配送遅延の問い合わせ中にセール通知を送る、といったことは避けるべきです。

顧客タグやCSツールの状態を使い、cs_open や complaint_handling の顧客を一時的に販促配信から除外するルールを作ります。

アプリで足りる範囲とカスタム連携が必要な範囲

Shopify LINE連携は、最初からすべてをカスタム開発にする必要はありません。

CRM PLUS on LINEのようなShopifyアプリは、ID連携、チェックアウトリマインド、購入・発送通知、顧客データに基づく配信、Shopify Flow連携を短く始める入口になります。

一方で、運用が進むとアプリ標準機能だけでは足りない領域が出ます。

選択肢	向いている範囲	別設計が必要な範囲
LINE公式アカウント標準機能	一斉配信、リッチメニュー、簡易チャット	Shopify購入履歴に基づく個別配信
CRM PLUS on LINEなどの連携アプリ	ID連携、カゴ落ち、発送通知、セグメント配信	独自CRM、複雑な重複顧客統合、監査ログ
Shopify Flow	タグ付け、通知、軽い配信トリガー	細かい再実行、長期の状態管理、複雑な分岐
CSツール	問い合わせ担当、ステータス、会話履歴	Shopify注文・LINE IDとの照合設計
iPaaS	スプレッドシート、Slack、CRMへの軽い連携	大量配信、厳密な再実行、個人情報の権限管理
カスタムAPI・中間DB	複数システムの顧客統合、配信ログ、失敗キュー	保守担当や運用ルールがない状態

Shopify、店舗、モール、外部CRMで顧客が分かれている場合や、CSツール上でShopify注文、LINE会話、配信履歴を同時に見たい場合は、カスタムAPIや中間DBを検討します。逆に、ID連携、カゴ落ち、購入完了、発送通知、顧客タグ中心のセグメントで足りる段階なら、アプリ中心で始めても問題ありません。

在庫や発送イベントも絡む場合は、Shopify在庫連携の設計方法で整理しているように、在庫正本やフルフィルメントのタイミングも合わせて見る必要があります。

導入前チェックリスト

ShopifyとLINE連携を始める前に、次の表を埋めておくと、後から運用が崩れにくくなります。

チェック項目	確認内容
連携アプリ	ID連携、配信、通知、Flow連携、CS対応の範囲を確認した
Shopify顧客	customer ID、メール、電話、タグ、メタフィールドの使い方を決めた
LINE ID連携	連携導線、連携済み判定、解除時の扱いを決めた
配信同意	販促配信、注文通知、発送通知、問い合わせ返信の扱いを分けた
顧客タグ	命名ルール、付与条件、削除条件、責任者を決めた
イベント	カート、チェックアウト、注文、支払、発送、返品、問い合わせの起点を決めた
CS対応	LINE会話からShopify注文を確認できる
失敗時対応	誰がどの画面で再実行・補正するか決まっている

このチェックリストを省略すると、導入直後は動いても、配信対象が増えたタイミングで崩れます。

とくに、ID連携率が上がるほど、誤配信の影響も大きくなります。LINEは顧客に近いチャネルなので、関係ないメッセージ、重複配信、問い合わせ中の販促配信は、メール以上に不満につながりやすいです。

まとめ

Shopify LINE連携を設計するときは、次の順番で考えます。

1. LINE公式アカウント、LINE ID連携、連携アプリ、Shopify、CSツールの役割を分ける
2. Shopify customer ID、メール、電話、LINE user ID、会員IDの対応ルールを決める
3. カート、チェックアウト、注文、支払、発送、返品、問い合わせイベントを配信起点として整理する
4. 顧客タグ、同意状態、ブロック状態、CS状態を分けて管理する
5. LINE連携済み顧客と未連携顧客で配信・導線を分ける
6. 重複顧客、配信失敗、ID連携解除、ブロック時の対応を決める
7. LINE問い合わせ時にShopify注文履歴を見られるCS導線を作る
8. アプリで足りる範囲と、カスタムAPIや中間DBが必要な範囲を分ける

ShopifyとLINE連携は、カゴ落ち配信を設定するだけの施策ではありません。

顧客が購入前、購入後、問い合わせ時にLINEを使うなら、Shopifyの顧客データ、注文データ、発送データ、配信同意、CS履歴を一つの流れとして設計する必要があります。

Bitlightでは、Shopifyストア構築だけでなく、LINE公式アカウント、CRM PLUS on LINE、Shopify Flow、CSツール、外部CRM、API連携まで含めた運用設計を支援しています。

LINE連携を「カゴ落ち配信の設定」で終わらせず、顧客データ、配信同意、問い合わせ対応、失敗時の補正まで含めて整理したい場合は、現在のShopify設定とLINE運用を一緒に棚卸しできます。