セグメント配信をAPIで実装する。対象抽出・除外・送信確認の設計

会員ランク、購入履歴、申込状況などを使ってLINE配信の対象を分けるとき、重要なのはAPIの選択だけではありません。誰を対象にしたか、誰を除いたか、どの時点のデータを使ったかを後から説明できる設計にします。

この記事では2026年9月8日時点の公式仕様を確認し、自社データを使うセグメント配信の構成と受入条件を整理します。掲載する構成は設計案で、実際の顧客データを使った抽出や配信は行っていません。

標準アップロードとAPI開発を比較する

LINE公式アカウントの管理画面にも、ユーザーIDアップロードやチャットタグなどを利用するオーディエンスがあります。月に一度の対象更新でよい場合は、管理画面で運用できるかを先に確認します。標準オーディエンスの公式マニュアル

方法	選びやすい条件	必要な運用
管理画面へのIDアップロード	更新頻度が低く、担当者が確認できる	対象ファイルの作成・確認・削除
APIで明示した複数宛先へ送る	自社で対象IDを決め、同内容を送る	分割、送信状態、重複制御
オーディエンス＋ナローキャスト	対象集団や条件を組み合わせたい	準備完了、人数条件、非同期の結果確認
個別のPush	顧客ごとに内容やタイミングが違う	対象者の条件、最新状態、個別の送信記録

対象者が多いから必ずナローキャストが正解というわけではありません。いつ誰を確定し、どの単位で結果を追いたいかを整理して選びます。

会員番号を受け取るだけで、本人と結び付けない

自社会員とLINEを連携する場合、本人がログインしていることを確認したうえで、検証したLINE側の識別情報と対応づけます。チャットで会員番号を入力してもらうだけでは、他人の番号を知っている人を除けません。公式のアカウント連携ガイド

設計案として、会員ID、対応するLINEユーザーID、連携した時点、連携解除、配信に関する希望などを別々に管理します。退会、家族間のアカウント共有、別のLINEへの連携変更も、対象を誤らないための確認事項です。

顧客DBから取り出した情報をすべてLINEへアップロードする必要はありません。対象抽出に使う購買情報は自社側に保持し、APIには利用する機能で必要な情報だけを渡します。

抽出条件より先に、除外条件を決める

「過去に商品Aを買った人」という条件だけでは、既に商品Bを購入済み、案内を希望していない、返品対応中といった人にも送る可能性があります。配信ごとに除外を優先するルールを決めます。

項目	決める内容
抽出	購入日、商品、会員状態、対象店舗
除外	今回の目的を既に達成、退会、配信希望の変更など
基準時点	何月何日何時のデータか
更新の遅れ	許容できる時間と送信を止める条件
承認	誰が件数・条件・原稿を確認するか
記録	抽出処理の版、対象件数、除外件数、配信ID

送信待ちの間に申込や取消が変わる業務では、抽出時点の一覧だけで送ってよいかを確認します。送信直前の再確認が必要なら、その処理を見積範囲へ入れます。データ更新が止まっているのに、前日の一覧で自動送信を続けないための判定も必要です。

ナローキャストでは、準備と送信の二段階を追う

オーディエンス作成は非同期です。配信前に READY を確認します。また、利用可能なオーディエンスへIDを追加した場合は、状態が READY のままでも追加処理が終わっていない場合があるため、該当ジョブの完了も確認します。公式のメッセージ送信ガイド

さらに、ナローキャストの送信リクエストが受理されても、その後に処理が失敗する可能性があります。進行状況を確認し、受理だけを配信完了と表示しません。ナローキャストの公式仕様

段階	保存する状態の例
自社データを抽出	基準時点、対象件数、条件の版
オーディエンスを準備	作成中、利用可能、追加処理中、失敗
送信を依頼	リクエストID、受理、エラー
非同期の結果を確認	進行中、完了、失敗、要確認
業務の成果を確認	案内先の申込・購入などの結果

ナローキャストには、属性やオーディエンスの組み合わせによるプライバシー保護の制限があります。同じ公式アカウントでIDアップロードした対象など、人数条件の扱いが異なる例外もあるため、一律に「全セグメントは50人必要」とはしません。オーディエンスの公式ガイドと送信の制限事項

対象未指定と失敗時の全件再送を防ぐ

ナローキャストで recipient を省略すると、友だち全体が対象になる仕様です。画面の選択が空だったときに、サーバーがそのまま対象指定を省略する実装は避けます。送信対象指定の公式説明

設計上は、対象が未確定、抽出件数が想定外、除外が反映されていない場合に送信へ進まないようにします。確認画面には対象名だけでなく、基準時点と件数、除外条件を表示します。

通信失敗時には、同じ送信を管理する再試行キーを使う方式を検討します。対応するAPI、同一内容での利用、保持期間などに条件があるため、単に新しいキーで再送しないようにします。公式の再試行ガイド

実務例：体験済みの人へ会員案内を送る

架空の語学教室で、体験を終えた人へ入会案内を送る設計を考えます。抽出条件は体験完了ですが、既に入会した人、案内を希望していない人、個別対応中の人を除外します。

夜間に一覧を作り、翌日の配信前に入会情報を反映する必要があるとします。同期が失敗した場合は送信を止め、担当者が最新の入会一覧を確認する運用にします。停止の理由を「配信エラー」と一括にせず、「対象データの更新未完了」と表示すると、確認すべき担当が分かります。

成果を見る際も、対象件数、実際の送信結果、案内ページの利用、入会という順に別々の数字を確認します。入会のすべてをLINEだけの効果と判断せず、他の接点も記録します。

費用と受入条件を、抽出から復旧まで見積もる

配信費は対象者数と送信方式のルールで確認します。対象を絞ることで計画通数が変わる場合はありますが、連携開発や運用の費用まで必ず下がるとは限りません。Messaging APIの料金

確認する場面	合格の判断
別人の会員番号を入力する	認証なしで連携されない
抽出が0件・想定外に多い	全体配信へ置き換えず、確認または停止する
抽出後に申込・退会が変わる	合意した更新時点と除外ルールを満たす
オーディエンス追加が未完了	追加処理の完了前に送信しない
送信受付後に失敗する	進行状況から検知し、全件の無条件再送をしない
月間の上限に近づく	通数と予約される送信枠を確認する
担当者が調査する	条件の版と配信IDから処理を追える

対象抽出、連携、送信、結果確認のどこまでを標準機能・外部ツール・独自開発で担うかを分けて依頼すると、見積の比較もしやすくなります。

よくある質問

セグメント配信には必ず独自開発が必要ですか？

管理画面のIDアップロードやチャットタグなどで運用できる場合があります。更新頻度、送信直前の除外、外部DBとの自動連携が必要かを確認してから開発範囲を決めます。

会員番号を送ってもらえばLINEと連携できますか？

会員番号を知っているだけでは本人と確認できません。自社会員としての認証と、LINE側の識別情報の検証を行い、他人の会員情報へ結び付かないようにします。

オーディエンスがREADYなら追加した全員へ送れますか？

既存オーディエンスへIDを追加した場合は、READYのまま追加処理が進むことがあります。追加した対象を含めるには、該当ジョブが完了したことも確認します。

ナローキャストの受付成功は配信完了ですか？

送信は非同期で進むため、受付後に失敗する可能性があります。リクエストIDを保存し、進行状況を確認して、受付・完了・失敗を分けて表示します。

この記事に関連するサービス

会員・購買・申込データから対象を選び、除外や再試行まで含めた配信を設計したい方は、LINEアプリ開発のサービスをご覧ください。

LINEアプリ開発のサービス・相談窓口を見る