LINE公式アカウントは全社で1つか店舗別か。運用と顧客データの設計
複数店舗でLINE公式アカウントを使う場合、顧客が何を受け取りたいかと、誰が配信・問い合わせに責任を持つかで構成を選びます。店舗数だけで「一つにまとめる」「すべて分ける」と決めると、店舗移動や本部配信が増えたときに運用が複雑になります。
本記事は2026年9月8日時点の公式資料を踏まえた設計ガイドです。全社共通、店舗別、併用の比較は設計上の判断であり、特定構成で費用やブロックが必ず減るという実績ではありません。
三つの構成を、担当者の日常業務から比較する
| 構成 | 向いている業務 | 事前に解決する課題 |
|---|---|---|
| 全社で一つ | 共通会員、店舗をまたぐ利用、本部主導の案内 | 利用店舗の判定、問い合わせの振り分け |
| 店舗ごと | 営業時間や商品が異なり、店舗が顧客対応を完結する | 更新作業の重複、本部の確認、閉店時の案内 |
| 本部と店舗を併用 | ブランド情報と各店の案内を明確に分ける | 複数追加の説明、同内容の重複送信、総配信頻度 |
共通アカウントでは「A店の予約について質問しているのに、本部から誰も返信しない」状態を避ける必要があります。店舗別では「共通キャンペーンを全店に設定したつもりが、二店舗で日付が違った」という確認作業が生じます。運用の手間は消えるのではなく、構成によって置き場所が変わります。
全社共通にするなら、利用店舗を顧客が変更できるようにする
店舗のQRコードから友だち追加した顧客でも、その後に別店舗を使うかもしれません。追加経路を永続的な所属店舗として扱うと、不要な店舗情報を送り続けることになります。
公式の友だち分析には追加経路の集計がありますが、集計期間や少人数データの表示制限があります。経路集計を、すべてのユーザーIDと店舗を一対一で取得できる機能だと見なさないことが大切です。友だち分析の公式マニュアル
共通アカウントの設計案としては、利用者が「よく使う店舗」を選び直せる画面やメニューを用意します。予約に関する通知は予約データの店舗、販促は本人が希望した店舗というように、目的ごとに参照する情報も分けます。
| 項目 | 保存・利用の考え方 |
|---|---|
| 友だち追加の経路 | 集客施策の集計に使い、現在の利用店舗と区別する |
| 希望する店舗 | 顧客が変更できる値として扱う |
| 予約先の店舗 | 予約DBにある当該予約の情報を使う |
| 問い合わせの担当店 | 会話ごとに引き継ぎ先を記録する |
| 配信の希望 | 店舗・内容の希望と更新時点を管理する |
「どの店舗に所属しているか」を一つの項目で済ませるより、予約と販促を別々に判断できる方が、店舗を併用する顧客にも対応しやすくなります。
店舗別にするなら、共通ルールと店舗の裁量を決める
店舗別アカウントでは、各店が営業時間や空き状況を素早く案内できます。その一方、本部で確認する範囲が曖昧だと、画像、表現、価格、問い合わせ対応にばらつきが出ます。
本部が管理するのは、ブランド表示、共通原稿、配信承認が必要な条件、権限の付与・削除などです。店舗が管理するのは、当日の営業案内、店舗内で完結する問い合わせ、承認済みテンプレートの必要項目などと分けられます。
フランチャイズや別法人の店舗が含まれる場合は、顧客データを誰が管理し、どの範囲で本部と共有するかを先に合意します。システム上で同じ一覧を見せられることは、共有範囲の合意の代わりにはなりません。
同じプロバイダーでも、友だち関係はアカウントごとに考える
LINEのユーザーIDは、同じプロバイダー内のチャネルで同じ値になり、別プロバイダーでは異なります。そのため、会員連携を計画するときには、プロバイダーの構成を早い段階で確認します。ユーザーIDの公式説明
ただし、ユーザーを識別できることと、別の公式アカウントから配信できることは別です。本部の友だちを、そのまま全店舗の友だちとして扱う設計にはしません。アカウントの追加状態、利用者への案内、配信方式の条件を個別に確認します。
プロバイダーは実際のサービス提供主体を踏まえて管理し、制作会社の都合だけで決めないようにします。契約終了後も自社の管理者が必要なチャネルを扱える構成にします。プロバイダー・チャネル管理の公式推奨
費用はアカウント数と対象者数の両方で比較する
一つのアカウントにまとめれば必ず安くなるわけではありません。プラン、アカウントごとの配信通数、運用作業、顧客データ連携の開発範囲で変わります。料金は見積時点の公式プランで確認します。LINE公式アカウントの料金プラン
例えば、架空の三店舗で「各店300人へ月2回」の案内を予定すると、配信計画上は300人×2回×3店舗で1,800人分の送信です。同じ人が三店舗すべての対象なら、その人は最大6回受け取る計画です。ここから未達や実際の課金対象を確認し、費用を算出します。
比較表には月額料金だけでなく、月に何回原稿を登録するか、何人が承認するか、重複した対象者にどう配慮するかも入れます。併用構成では本部と店舗の配信予定を同じカレンダーで見られると、集中する日を調整できます。
実務例:二店舗を使う顧客の案内を整理する
架空のスポーツ用品レンタル店で、顧客が平日はA店、週末はB店を使うとします。共通アカウントを選び、会員画面に希望店舗を複数登録できる設計にします。予約確認は予約した店舗からの情報を表示し、店舗の休業案内は希望した店舗だけを対象にします。
問い合わせは最初に予約の有無を確認し、予約番号がある場合は担当店へ、ない場合は希望店舗を尋ねます。本部が会話を受けたまま放置しないよう、担当決定までの窓口も定めます。
この例で重視するのは会員データの共通化です。一方、店舗ごとのサービスが大きく異なるなら、別アカウントの方が利用者にとって分かりやすい場合もあります。
開設前の受入条件に、閉店と担当交代を入れる
| 想定する場面 | 確認する結果 |
|---|---|
| 顧客が店舗を変更する | 次回の販促対象と予約通知先が意図どおりになる |
| 二店舗を同時に利用する | 予約情報を混ぜず、問い合わせ先が分かる |
| 本部と店舗が同日に配信する | 受信回数を事前に確認して調整できる |
| 店長が異動する | 新担当者がアクセスでき、旧担当の権限を整理できる |
| 店舗が閉店する | 予約、問い合わせ、掲載中リンクを引き継げる |
| 店舗統合を行う | 顧客への案内と必要な追加手続きが計画されている |
アカウント構成は、現時点の組織図だけでは決めきれません。顧客の店舗移動と、閉店・譲渡・運用委託の変更まで一度試算してから選ぶと、後から必要になる作業を見積もれます。
よくある質問
多店舗なら店舗別アカウントがよいですか?
店舗ごとに情報や問い合わせ対応が完結するなら候補になります。共通会員や店舗をまたぐ利用が多い場合は、全社共通アカウントと店舗選択の仕組みも比較します。
店舗のQRコードだけで利用店舗を自動管理できますか?
追加経路の集計と、ユーザーごとの現在の利用店舗は別です。経路分析の取得条件を確認し、必要に応じて顧客が希望店舗を選び直せる仕組みを用意します。
同じプロバイダーなら別店舗からも配信できますか?
同じプロバイダー内でユーザーIDが共通でも、別の公式アカウントの友だち関係まで共通になるわけではありません。配信元ごとに友だち追加の状態や送信条件を確認します。
一つにまとめると料金は下がりますか?
一律には決まりません。各アカウントのプランと送信対象、重複配信、原稿登録・承認の作業、データ連携の開発範囲を合わせて比較します。
この記事に関連するサービス
全社共通・店舗別の構成を、会員連携や問い合わせの担当分担から比較したい方は、LINEアプリ開発のサービスをご覧ください。
出典・参照
- LINE Developers — ユーザーIDを取得する (2026年9月8日確認)
- LINE Developers — プロバイダーとチャネル管理のベストプラクティス (2026年9月8日確認)
- LINEヤフー — 分析:友だち (2026年9月8日確認)
- LINEヤフー — 料金プラン (2026年9月8日確認)