LINEセグメント配信のやり方｜友だち情報欄とタグをどう設計するか、51万人アカウントの実装記録

LINEのセグメント配信のやり方を調べると、「配信作成画面で条件を指定して絞り込む」という操作手順が出てきます。操作自体はその通りで、覚えれば5分で終わります。ところが実際にやろうとすると、多くのアカウントで手が止まります。絞り込もうにも、絞り込みに使えるデータが友だちに何も付いていないからです。

先に結論を書きます。セグメント配信の成否は配信画面の操作ではなく、その手前のデータ設計で決まります。押さえる原則は3つです。

• 変わっていく「状態」は友だち情報欄に持たせる（残回数・購入日・最終来店日など、上書きされていく値）
• 起きた「行動」はタグで持たせる（ボタンを押した・回答した・使い切った、という事実のフラグ）
• どちらも手で付けない。QRコード・リッチメニュー・回答フォームに付与アクションを仕込み、友だちが動くたびに自動で貯まるようにする

graciautoは、有効友だち51万人を超える多店舗サロン企業のLステップ本番環境で、紙の回数券をLINE内でデジタル化するシステム（友だち情報欄9項目・リッチメニュー14枚・流入経路QR6本）を構築しました。この記事では、その実装で実際に使った友だち情報欄とタグの設計をそのまま公開しながら、何をどの順番で決めればセグメント配信が回るのかを解説します。

セグメント配信の「やり方」は2段階に分かれる

まず前提の整理です。セグメント配信のやり方は、使う環境によって2段階に分かれます。

• LINE公式アカウントの標準機能（絞り込み配信）：性別・年齢・OS・友だち期間などの属性で絞る方法。ただしこれらは「みなし属性」と呼ばれる推定値で、精度に限界があるうえ、ターゲットリーチが100人以上ないと属性での絞り込み自体が使えない仕様です（2026年7月時点）。そして最大の制約は、「自分のビジネスにとって意味のある情報」では絞れないことです
• Lステップなどの拡張ツール：友だち情報欄（自由に定義できるデータ項目）とタグで絞る方法。「残回数が1回以上の人」「A店のQRから登録した人」のような、自社の運用に直結した条件で配信できます

標準機能の操作手順そのものは、セグメント配信のやり方完全ガイドで解説しています。この記事が扱うのはその先、つまり「意味のある条件で絞れるアカウントをどう作るか」です。以下、拡張ツール（Lステップ）での実装を前提に進めますが、状態とタグの設計原則は他のツールでも同じです。

実装記録：デジタル回数券の友だち情報欄とタグをこう設計した

実例で見たほうが早いので、実際の設計を出します。案件は多店舗サロン企業の回数券デジタル化です。お客様が店頭のQRコードを読むと残回数が1回減り、残回数に応じてリッチメニューの表示が切り替わり、配信も残回数や有効期限で絞り込める、という仕組みです。全体像はLINE公式アカウント×AIで回数券をデジタル化する方法に書いたので、ここではデータ設計だけを取り出します。

友だち情報欄は「フォルダ＋統一命名」で9項目

友だち情報欄は「回数券管理」というフォルダを作り、その中に9項目を置きました。3つの券種それぞれに、残回数（数値型）・購入日（年月日型）・有効期限（年月日型）の3項目です。

命名は全項目を「回数券｜スタートアップ｜残回数」のように、「カテゴリ｜対象｜項目」の3要素で統一しました。地味に見えますが、これが後で効きます。友だち情報欄は配信の条件設定でドロップダウンから選ぶことになるため、名前だけで「何のデータか・どの商品のものか」が判別できないと、似た項目を取り違えてまったく別のセグメントに配信する事故につながります。運用が長いアカウントほど項目は増えるので、命名規則は1項目目を作る前に決めておくのが正しい順番です。

型の選択が、組める配信条件の幅を決める

友だち情報欄には型があり、どの型を選ぶかでその項目に使える絞り込み条件が変わります。実装で確認した範囲では次の通りです。

• 数値型：値の代入・加算・減算ができ、条件では完全一致に加えて「以上・以下・より大きい・より小さい」の比較が使えます。「残回数が1以上の人にだけ期限リマインドを送る」という配信はこの型だから組めます
• 年月日型：「経過期間」「残り期間」という日付ならではの絞り込みが使えます。基準日を指定しなければ当日が基準になるため、「有効期限まで残りわずかの人」という条件が、日付を毎回入れ直さなくても毎日自動で判定されます。さらに2025年9月のアップデートで年月日型は加算・減算にも対応しており、「購入日を代入してから6ヶ月を加算する」という操作で有効期限の自動計算までツール内で完結しました

やってしまいがちなのが、とりあえず全部テキスト型で持つ設計です。テキストで「残り3回」と書いてしまうと、数値比較も期間絞り込みも使えず、セグメント配信の条件に載せられません。項目を作る時点で「この項目はどんな条件で絞りたいか」から逆算して型を決める必要があります。

タグは「行動の事実」と「処理中のフラグ」に使う

タグは友だち情報欄と違って値を持たない、付いているか・いないかだけの目印です。回数券の実装では「回数券｜スタートアップ｜消化成功（一時）」のような一時タグを、消化処理が正常に通ったかどうかの判定フラグとして使いました（詳細は後述の失敗予防のところで説明します）。

使い分けの基準はシンプルです。数や日付など「今いくつか」を問う情報は友だち情報欄、「やったか・やっていないか」を問う情報はタグ。この2つを混ぜると、タグが「残1」「残2」「残3」のように増殖して管理不能になります。

付与は流入経路QRとアクションで自動化する

設計したデータは、自動で貯まる仕組みまで作って初めて機能します。回数券では店頭のQRコード（Lステップの流入経路機能）にアクションを仕込み、読み取られた瞬間に残回数の代入・購入日と有効期限の自動セット・リッチメニューの切り替えまでが走るようにしました。スタッフもお客様も、データを入力する場面が一切ありません。

この環境が参考になるのは、既存運用でも同じ型が徹底されていたことです。このアカウントには店舗ごとの流入経路が342本あり、どの友だちがどの店舗のQRから登録したかがすべてデータ化されています。だから「特定の店舗で登録した人にだけ配信する」が最初から可能な状態でした。51万人という規模でセグメント配信が成立しているのは、付与が自動化されているからです。手動でタグを付ける運用は、友だちが増えるほど確実に破綻します。

なお、流入経路分析やセグメントリッチメニューはLステップのプランによって使える範囲が変わります（2026年7月時点で流入経路分析はプロプラン限定）。ツール選定の段階で、組みたい仕組みに必要な機能とプランを確認しておくと手戻りがありません。

設計手順：5ステップと判断基準

実装記録を一般化すると、手順は次の5ステップになります。

• ステップ1：絞り込んで送りたい配信を、先に3本書き出す。「データを整えてから配信を考える」は順番が逆です。配信が決まらないままデータ設計を始めると、使われない項目とタグだけが増えます
• ステップ2：その3本の配信条件に出てくる情報を「状態」と「行動」に仕分ける。状態（残回数・最終来店日・購入店舗）は友だち情報欄、行動（予約ボタンを押した・アンケートに答えた）はタグです
• ステップ3：友だち情報欄の型と命名規則を決める。数値で比較したいなら数値型、期限や経過日数で絞りたいなら年月日型。命名は「カテゴリ｜対象｜項目」のように機械的に決められる形にします
• ステップ4：付与ポイントを実装する。友だち追加時・QRコード・リッチメニューのタップ・回答フォームの送信など、友だちが動く場所に付与アクションを仕込みます
• ステップ5：配信前に絞り込み結果の人数を確認してから送る。条件を組んだら、まず対象者数が想定と合っているかを見ます。想定100人の条件で対象が0人や全員になっていたら、条件式か付与の設計がどこかで壊れています

タグや項目の数の判断基準も書いておきます。最初から網羅的に作る必要はありません。ステップ1の「配信3本」から逆算すれば、初期は友だち情報欄と合わせて5〜10個で足ります。逆に、誰も全部を説明できない数十個のタグがある状態は、配信から逆算せずにデータから作った兆候です。その場合は使っている配信条件に登場するものだけ残して整理したほうが、結果的に配信は増えます。

実装で確認した仕様と、起こりうる失敗の予防設計

ここからは、本番実装の過程で確認できた仕様と、それを踏まえた予防設計です。セグメント配信のデータ設計では、ツールの評価タイミングや型の精度を知らないまま組むと、静かに壊れる箇所がいくつかあります。

条件は「そのアクションが実行される瞬間の値」で評価される

Lステップで複数のアクションを条件付きで並べる場合、各条件はそのアクションが実行される瞬間の友だち情報の値で評価されます。つまり「残回数を1減らす」の後ろに置いた条件は、すべて減算後の値を見ます。

これを知らずに組むと、たとえば回数券なら「残0の友だちがさらにQRを読むと残回数がマイナスになる」「最後の1回を使った直後と、使い切った後の空打ちが、どちらも残0で区別できない」という事態が起こりえます。予防策は、実行前の状態を先頭で一時タグに写し取っておく設計です。

• 最初に【残回数が1以上】の条件で一時タグを付与する（減算前の値で判定される）
• 同じ条件で残回数を減算する
• 成功メッセージは【一時タグを含む】、使い切り案内は【一時タグを除外】で出し分ける
• 最後に一時タグを解除して後始末する

「前の状態を後続のアクションに伝えたいときは一時タグを経由させる」。この型は回数券に限らず、条件分岐を含むアクション設計全般で使えます。

月単位の期間絞り込みを厳密な期限判定に使わない

年月日型の「経過期間で絞り込み」は便利ですが、月単位の判定は「購入から6ヶ月」という条件に6ヶ月と20日経過した友だちも含まれる挙動でした。ポイント失効や回数券の有効期限のように1日単位で正確に切りたい判定には向きません。厳密に判定したい日付は、有効期限そのものをフィールドに持たせて「残り期間（日）」で絞るのが正解です。日単位なら「当日まで有効・翌日から対象外」がカレンダー通りに機能します。

状態と履歴を混ぜない

友だち情報欄は上書き式なので、持てるのは「今の状態」だけです。残回数を減算すれば、いつ何回使ったかという過去は残りません。利用履歴・購入履歴のような「起きたことの記録」が必要なら、スプレッドシートなど外部に追記専用の台帳を分けて持たせます。回数券の実装でも、Lステップ側は状態（残回数・期限）、外部シートは履歴（購入・消化の記録）と役割を分離しました。配信条件に使うのは状態だけなので、この分離はセグメント配信の設計をむしろシンプルにします。

後から変えられる設定と、変えられない設定を区別する

実装で確認した範囲で、運用に影響が大きいものを挙げます。

• 流入経路の「アクションの実行（いつでも／初回のみ）」は登録後に変更できません。QRを読むたびに毎回発火させたい用途では、最初の設定を誤ると作り直しになります
• 配信条件のフィールドを別の項目に差し替えると、設定済みの比較演算子と値がリセットされます。差し替えたら条件全体を見直す前提で操作します
• 一方、タグや友だち情報欄のリネームは内部的な紐付けが保持されるため、既存アクションの参照は壊れません。命名規則の統一は後からでもやり直せます
• リッチメニューは登録しただけでは誰にも反映されません。適用のアクションを実行して初めて表示されるため、本番アカウント上でも配信せずに安全に準備を進められます

まとめ：配信画面より先に、データの置き場所を設計する

セグメント配信のやり方は、操作としては「条件を指定して送る」だけです。成果を分けるのはその条件に使えるデータが貯まっているかどうかで、それは3つの原則に集約されます。変わる状態は友だち情報欄に、起きた行動はタグに、付与は自動化する。そして設計は「送りたい配信3本」からの逆算で始める。この順番なら、タグだらけで絞れないアカウントにはなりません。

セグメントを切ること自体の効果、特にブロック率への影響はブロック率を下げる配信設計で、配信後にどの数字を見るかは配信文を書き直す前に見る3つの数字で書いています。あわせて読むと、設計から検証までの流れがつながるはずです。

graciautoでは、LINE公式アカウント・Lステップの構築を、今回のような友だち情報欄とタグの設計から請け負っています。「セグメント配信をやりたいがデータ設計から相談したい」という段階でも、現状のアカウント構成を見たうえで設計案をご提案できますので、お気軽にご相談ください。