AIで作ったセグメントをLINE配信に戻す方法｜送り方の選び方と、禁止される「属性の特定」

CDPやCRM、BigQueryでAIが作ったセグメント（離反しそうな会員、次に同じ商品を買いそうな会員といった区分）をLINEの配信に戻す方法は、LINEのオーディエンスにするか、ユーザーIDを直接指定するかで分かれます。オーディエンスにする方法は、①管理画面でユーザーIDの一覧ファイルを取り込む「ユーザーIDアップロード」、②Messaging APIで同じ種類のオーディエンスを作る方法、③そのオーディエンスをナローキャストでLINE側の属性や過去の配信と掛け合わせて送る方法、④ユーザーIDの分からない顧客について、メールアドレスや電話番号をビジネスマネージャーで読み込んで共有する方法の4つです。オーディエンスを使わず、会員ごとのユーザーIDを指定してプッシュやマルチキャストで送る方法もあります（メッセージを送信する、オーディエンスを使う、オーディエンスのマニュアル、共有できるオーディエンス）。

越えてはいけない線も決まっています。Messaging APIの開発ガイドライン（LINE Developers）は、特定のユーザーIDについて、ナローキャストの絞り込みに使う属性（性別・年齢・地域など）を特定する行為と、そのためにオーディエンス管理のAPIやナローキャストを使うことを禁止しています（Messaging API開発ガイドライン）。LINE公式アカウント利用規約も第18条で、みなし属性を使って送ったメッセージに接触した人の属性を識別する行為を禁止し、属性ごとに遷移先を分けることや、URLに経路を追える情報を付けることをその例に含めています（LINE公式アカウント利用規約）。ここから導けるのは、セグメントは自社のデータで作り、LINEの推定属性は配信の絞り込みにだけ使う、という線です。

どの方法でも、LINEのユーザーIDと自社の会員IDが正しく結び付いていること、行動や購買の分析結果を配信に使うことを利用目的として示し、同意を得ていることが前提になります。以下では、戻し方ごとの違い、してはいけないこと、IDの紐付けと同意の確かめ方、スコアが変わるたびの運用の順に、LINE Developersの各ドキュメントとAPIリファレンス、LINEヤフーの規約、個人情報保護委員会のガイドラインとQ&Aをもとに整理します。いずれも2026年9月25日に本文を確認しました。

AIのセグメントをLINEに戻す方法と、それぞれの違い

戻し方によって、宛先の持ち方、人数の条件、呼び出しの上限が違います。まず表で並べ、そのあと1つずつ見ていきます。

出典：オーディエンスのマニュアル（2025年9月1日更新）、Messaging APIリファレンス（制限事項・レート制限・同時処理数・各送信方法）、オーディエンスを使う、共有できるオーディエンス（2026年6月17日更新）、ビジネスマネージャー利用規約 第5条

セグメントの材料がどこにあるかでも、進み方は変わります。フォームの回答やタグのように材料がLINEの中で集まるなら、LINE公式アカウントのCRMオプションで足りることがあります。購買やアプリの利用履歴のように材料がLINEの外にあり、それをAIで区分するなら、以下の方法で戻します。

管理画面のユーザーIDアップロード：ファイルを読み込んで作る

AIが出した会員の一覧をファイルに書き出し、担当者が管理画面で読み込む方法です。中身をユーザーIDに限ったTXT形式かCSV形式のファイルを使います。1回に選べるファイルは5つまでで、1ファイルに入れられるIDは150万件までです（オーディエンスのマニュアル）。作ったオーディエンスは、メッセージ配信の配信先を「絞り込み」にして、1通に10個まで、含めるか除外するかを選んで使えます（絞り込み配信のマニュアル）。開発は要りませんが、書き出しと読み込みが手作業になるので、スコアを更新した日と読み込んだ日がずれやすくなります。

ファイルの中身で読み込みに失敗するケース、作成から180日で切れる期限（オーディエンスを使う）、名前の付け方と台帳での管理は、LINE公式アカウントのオーディエンスの作り方で詳しく扱っています。

Messaging APIのオーディエンス：データ基盤から作って足す

同じユーザーIDアップロードのオーディエンスを、データ基盤からAPIで作る方法です。1回のリクエストでJSONなら1万件、ファイルなら150万件までのユーザーIDを渡せます。作成とIDの追加は、オーディエンス管理のエンドポイントとして1分あたり60リクエストまでで、1つのオーディエンスに対する処理は同時に10件までです（ユーザーIDアップロード用のオーディエンスを作成する、同時処理数の制限）。

APIで作ったオーディエンスも管理画面で作ったオーディエンスも、同じLINE公式アカウントの中なら、初期設定なしで相互に利用できます（オーディエンスを使う）。データ側がAPIでオーディエンスを用意し、文面と送るタイミングは担当者が管理画面で決める、という分担が組めます。ステップ配信でも、開始条件と分岐にMessaging API経由のオーディエンスを指定できるとされています（ステップ配信のマニュアル）。

• 作成は非同期です。配信に使う前に、ステータスがREADYになったこと、IDを追加した場合はその処理（ジョブ）がFINISHEDになったことを確かめます（メッセージを送信する）。
• 一度追加したユーザーIDは削除できません（ユーザーIDを追加するエンドポイントの注記）。スコアが下がってセグメントから外れた人を抜く操作が無いので、中身が入れ替わるセグメントは作り直します。
• LINEのプライバシーポリシー（2022年3月改定以降のもの）に同意していない人のIDは無視され、指定した数より送信対象が少なくなることがあります（作成のエンドポイントの注記）。

ステップ配信のマニュアルには、オーディエンスを開始条件にすると、開始後に新しくオーディエンスに入った人も配信対象になると書かれています。AIが毎日見つける「休眠の兆しがある会員」をAPIで同じオーディエンスに追加していき、ステップ配信の入口にする組み方が考えられますが、IDを追加した場合にこの扱いになるかは、マニュアルに明記がありません。テスト用のアカウントで確かめてから使ってください。また、利用中のステップ配信は、条件にしたオーディエンスを使えなくなった時点で停止します（ステップ配信のマニュアル）。

ナローキャスト：LINE側の条件と掛け合わせて送る

ナローキャストは、オーディエンスや過去のナローキャストのリクエストIDを合計10件まで、AND・OR・NOTで組み合わせ、さらに性別・年齢・OS・地域・友だち期間の属性で絞って送る方法です（ナローキャストメッセージを送る）。たとえば、AIのセグメントのオーディエンスから、直近の配信を開封した人のオーディエンスを除く、といった指定ができます。

人数の条件があります。属性を使うにはターゲットリーチが100人以上必要で、属性かオーディエンスを使った場合、最終的な送信対象は50人以上、指定した各オーディエンスも50人以上でなければ送れません。ユーザーIDアップロードとチャットタグのオーディエンスにはこの人数の制限がかかりませんが、属性で絞れば、属性の条件として最終的な送信対象50人以上が求められます（属性情報やオーディエンスを利用したメッセージ送信の制限事項）。条件ごとの下限は管理画面の絞り込み配信と同じ考え方で、LINE公式アカウントのセグメント配信でも整理しています。

送信は非同期で、リクエストが受け付けられても、送信開始の時点で人数不足などにより失敗することがあります。結果は進行状況のエンドポイントで確かめ、失敗した場合は、送信対象が少なすぎた、50人未満のオーディエンスが含まれていた、といった理由がエラーコードで返ります。レート制限は1時間あたり60リクエストなので、セグメントを細かく分けてそれぞれに別の文面を送る設計にすると、この上限に当たりやすくなります（ナローキャストメッセージの進行状況を取得する、レート制限）。

もう1つ、ナローキャストでは、実際に届く人数ではなく、アカウントのターゲットリーチの人数分が、当月に配信できるメッセージの残数からいったん予約されます。残数がターゲットリーチに満たないと送信開始時にエラーになり、配信が終わるまでほかのメッセージが送れなくなることもあります。リミットオブジェクトで最大送信数を指定すると避けられる場合があります（当月に配信できるメッセージの残数に関する注意事項、リミットオブジェクト）。

ビジネスマネージャーの共有：ユーザーIDの無い顧客に送る

会員のユーザーIDが分からない場合は、メールアドレスや電話番号のリストをビジネスマネージャーで読み込み、オーディエンスとしてLINE公式アカウントに共有する方法があります。共有したオーディエンスは、LINE公式アカウントでは狙って送ること（リターゲティング）にも、送り先から外すこと（除外）にも使えます。共有にはビジネスマネージャーの組織へのアカウントの接続と組織の認証審査が要り、配信に使えるのはサイズが50以上のものです（共有できるオーディエンス）。共有の設定ができるのは、アカウント種別が認証済アカウントかプレミアムアカウントの場合だけで（オーディエンスを使う）、ステップ配信の開始条件や分岐には、共有されたオーディエンスを指定できません（ステップ配信のマニュアル）。

ビジネスマネージャー利用規約の第5条は、この読み込みについて、連絡先を指定の方法で変換して渡すこと、宛先を定められた件数以上にすること、取得と配信のキーにすることの両方について同意を含む適法な手段で許諾を得ていると表明することを求めています。連絡先の誤りや不一致で、意図と別の人に届く場合があることも同じ条にあります。第4条3項は、特定の個人を識別する目的でビジネスマネージャーを使うことと、そこで得たデータで特定の個人を識別することを禁じています（ビジネスマネージャー利用規約）。法的な整理は、後の「同意と利用目的の確かめ方」で扱います。

オーディエンスを使わない方法：ユーザーIDを指定して送る

会員ごとにユーザーIDを指定して、プッシュかマルチキャストで送る方法です。マルチキャストは1回のリクエストで最大500件のユーザーIDを指定でき、送り先が1人ならプッシュが推奨されています。送れるのはLINE公式アカウントを友だち追加している人で、プッシュはこれに加えて、7日以内に1対1のトークでメッセージを送ってきた人にも送れます（リファレンスのマルチキャスト、リファレンスのプッシュ）。

オーディエンスを通さないので、ナローキャストのような人数の条件はかかりません。AIが会員ごとに違う商品や文面を選ぶなら、この方法がいちばん素直です。ただし、アカウントを削除した人、ブロックしている人、友だちでない人を宛先に入れても、リクエストは成功扱いのまま届きません。他のプロバイダーで取得したユーザーIDのように、チャネルに存在しないIDを入れた場合も届きません（プッシュとマルチキャストの送信条件）。送る前の点検は、後の「戻す前にそろえる」の節で扱います。

してはいけないこと：「属性の特定」と、その周りの禁止

開発ガイドラインの禁止事項は短い文ですが、リンク先を見ると範囲が分かります。ここでいう属性はナローキャストのデモグラフィックフィルターの項目、つまり性別・年齢・OS・地域・友だち期間のことです。特定のユーザーIDについてそれを割り出すこと、そのためにオーディエンス管理のAPIを使ったり、ナローキャストを送ったりすることが禁止されています（ユーザーの属性を特定する行為の禁止）。このうち性別や年齢などはLINEが毎日推定・更新している値で、配信の時点と後とで変わることもあります（絞り込み配信のマニュアル）。

LINEは仕組みの側でも、少ない人数の結果を見せない作りにしています。ナローキャストの人数の下限について、リファレンスとドキュメントは、送信対象のユーザーの属性を推測できないようにするためと説明していて（進行状況を取得するエンドポイントの注記、メッセージを送信する）、オーディエンスの人数や配信の統計にも、プライバシーを保護するための下限があります。

AIを使った運用で、この禁止や周りの決まりに触れるおそれのある場面を、想定例で並べます。左の列は、この記事の説明のために作った例です。

場面は説明のための想定例。決まりの出典は各行のリンク先。

表の1行目の条文は、みなし属性を使って送った場合の決まりです。自社のデータだけで作ったユーザーIDのオーディエンスやユーザーID指定の送信は、条文の書きぶりからは対象外と読めますが、属性のフィルターを重ねた時点で対象に入ります（LINE公式アカウント利用規約 第18条）。迷う配信では、属性で絞ったものに会員単位の計測を付けない、と決めておくと線を越えません。

戻す前にそろえる：ユーザーIDと会員IDの対応表

AIのセグメントは会員IDで出てくるので、LINEに戻すには会員IDとユーザーIDの対応表が要ります。ユーザーIDは、同一人物でもプロバイダーが違えば別の値になり、同じプロバイダーの中なら、LINEログインのチャネルでもMessaging APIのチャネルでも同じ値になります（ユーザーIDを取得する）。プロバイダーを複数持つ会社では、どのプロバイダーで取ったIDかを対応表に残しておかないと、届かないIDが混ざります。

紐付けは公式の仕組みで取る

会員IDとユーザーIDを結び付ける公式の方法は、次の2つです。

• Messaging APIのアカウント連携：ボットサーバーがユーザーIDから連携トークン（10分間有効で1回だけ使える）を発行し、ユーザーに自社サイトでログインしてもらいます。予測できないnonceを付けてLINEプラットフォームへリダイレクトし、本人と確認できると、ユーザーIDとnonceを含むアカウント連携イベントが届くので、nonceから会員IDを引いて結び付けます。前提として、ユーザーが友だち追加している必要があります（アカウント連携の手順）。
• LINEログイン（LIFFを含む）：ログインで受け取ったIDトークンをサーバーで検証し、その中のユーザーIDを使います（IDトークンからプロフィール情報を取得する）。LIFFについては、liff.getProfile()などで取ったプロフィールをそのままサーバーへ送らず、IDトークンかアクセストークンを送ってサーバーで検証するよう案内があります（LIFFでユーザー情報を使うときの注意）。

アカウント連携のドキュメントは、連携を独自に実装すると、攻撃者が自分のLINEアカウントを他人の会員アカウントに結び付けるおそれがあると注意しています（アカウント連携のドキュメント）。AIが会員ごとに選んだ中身を送る以上、紐付けの誤りはそのまま別人への送信になります。フォームにユーザーIDを入力させる、URLのパラメータで受け取る、といった確かめようのない取り方で作った対応表は、使う前に取り直します。

LINEログインを使う場合は、同意画面でLINE公式アカウントの友だち追加を促すオプションがあり、ログイン時に友だち関係が変わったかはコールバックのパラメータで、今の友だち関係はLINEログインのAPIで確かめられます。この機能は、LINEログインのチャネルに、同じプロバイダーのMessaging APIチャネルにひもづくLINE公式アカウントをリンクして使います（友だち追加オプション）。

対応表に残す項目

対応表には、少なくとも次の項目を持たせておくと、送る前の点検と、後からの説明ができます。項目の選び方は当社の提案で、持たせる理由は右の列の決まりによります。

項目は当社の提案。理由の出典は各行のリンク先。

表示名やプロフィール画像など、ユーザーID以外のLINEユーザー情報を24時間以上保存するなら、その旨を利用者に明示しなければなりません。友だち情報とグループ情報は、明示しても24時間以上は保存できません（LINEユーザーデータポリシー 3.2.3）。AIの特徴量に表示名を使うような設計は避けます。

送る前にIDを点検する

Messaging API開発ガイドラインは、存在しないユーザーIDにリクエストを送ることを禁じています（開発ガイドラインの禁止事項）。リファレンスは、ユーザーIDが有効かどうかをプロフィール情報の取得で確かめる方法を示していて、ステータスコード200以外が返るIDには送れません。200以外になる理由として、IDが存在しない、プロフィール情報の取得に同意していない、友だちでない、ブロックされた、が挙がっています（プロフィール情報を取得する）。オーディエンスの作成で無効なIDを示すエラーが返ったときも、同じ方法で200以外のIDを除いてから再実行するよう案内されています（オーディエンス管理に関するエラーの対処方法）。

日々の抽出では、フォローとフォロー解除のWebhookで友だち状態を対応表に反映しておき、友だちでない人を最初から外しておくと、届かないリクエストを減らせます（フォロー解除イベント）。

同意と利用目的の確かめ方

LINE側の同意で、届く人数が変わる

LINE側の同意は2か所で効いてきます。1つは、プロフィール情報の取得への同意です。iOS版かAndroid版のLINEを使う人は利用開始時に同意していますが、PC版だけを使う人は同意できず、その人のユーザーIDはWebhookに入ってきません（ユーザーのプロフィール情報取得の同意）。もう1つは、ユーザーIDアップロードのオーディエンスで、LINEのプライバシーポリシー（2022年3月改定以降）に同意していない人は、追加しても無視されます（オーディエンス作成の注記）。

LINE公式アカウント利用規約の第8条3項は、事業者がLINEヤフーに識別子（LINEヤフーが発行する利用者の内部識別子を含む）を渡した場合の扱いを定めていて、LINEヤフーは突合に同意を得た人の個人情報とだけ突合し、突合できなかったものは個人データとして取得せずに削除するとしています（LINE公式アカウント利用規約）。AIのセグメントの人数とLINEで実際に届く人数は一致しない前提で、効果を見るときの母数を決めておきます。

自社のプライバシーポリシーに、分析と配信を利用目的として書く

個人情報保護委員会のガイドライン（通則編）の3-1-1は、本人から得た情報から行動や関心を分析する場合、どのような取扱いが行われているかを本人が予測できる程度に利用目的を特定しなければならないとしています。閲覧履歴や購買履歴を分析して趣味・嗜好に応じた広告に使う、という書き方が例に示され、「マーケティング活動に用いるため」だけでは具体的に特定したことにならない例に挙がっています（個人情報の保護に関する法律についてのガイドライン（通則編））。Q&Aの2-1も、いわゆるプロファイリングでは、分析結果の使い道だけでなく、分析すること自体を利用目的に含めるよう求めています（ガイドラインに関するQ&A 2-1）。

AIで会員を区分してLINEで案内するなら、何の情報を分析し、その結果をLINEなどでの案内に使うことが読み取れるように利用目的を書きます。LINE側の規約も同じ方向です。LINEユーザーデータポリシーは、サービスのプライバシーポリシーを作って誰でもいつでも見られるように公開すること、利用目的を特定し、個人情報の収集と利用に同意を求めることを開発者に求めています（LINEユーザーデータポリシー 2.2〜2.4）。LINE公式アカウントAPI利用規約の第5条4項も、利用者の情報を自社のプライバシーポリシーで扱うこと、それをいつでも見られるようにすることを、利用者が見る画面に示すよう定めています（LINE公式アカウントAPI利用規約）。

LINEから受け取った情報の使い道にも枠があります。LINE開発者契約の5.2.3は、利用者が提供したLINEアカウント情報を、同意を受けた時期以降に、同意を受けた用途でだけ使えるとし、第三者のサービスで広告配信に使うことを禁止の例に挙げています。8.2は、APIで取得したユーザーのデータを自社のアプリケーション等の外で使うことを禁じています（LINE開発者契約）。LINEユーザーデータポリシーの3.2.4も、サービスの提供のために取得したLINEユーザー情報を他の目的に使うことを禁じています（LINEユーザーデータポリシー）。

渡す先ごとに確かめる：LINEヤフー、委託先、別のアカウント

セグメントを作って送るまでに、データは社外にも出ます。渡す先によって、確かめる条文が変わります。

Q&Aの7-41が例に挙げているのは、顧客のメールアドレスをSNS運営事業者に渡し、その事業者のユーザーと突合して広告を表示する形です（Q&A 7-41）。ビジネスマネージャー利用規約の第5条12項が定める、読み込んだ連絡先をLINEヤフーのデータとマッチングして配信先を選ぶ仕組みと形が近いものです（ビジネスマネージャー利用規約）。ユーザーIDのオーディエンスも含め、自社の対応をどちらで整理するかは、法務と決めてから始めます。

改正個人情報保護法（2026年7月公布）は施行前

改正個人情報保護法は2026年7月17日に公布され、施行は原則として公布の日から2年を超えない範囲内とされています。個人情報に当たらなくても、電話番号・メールアドレス・Cookie IDなど特定の個人に連絡できる記述を含む情報について、不適正な利用と不正な取得を禁じる規定（第31条の2）が加わり、政令・規則・ガイドラインは個人情報保護委員会が検討を進めている段階です（令和８年 改正個人情報保護法について、改正法の概要資料）。LINEのユーザーIDがこの規定の対象に入るかは、この記事の時点では確かめられていません。施行までに、ガイドラインで改めて確認してください。

スコアが変わるたびの戻し方と、記録の残し方

出入りの多いセグメントは、送るたびに作り直す

ユーザーIDアップロードのオーディエンスは、IDを足せても消せず、作成から180日で使えなくなり、1チャネルあたり1,000件までしか持てません（オーディエンスの仕様、ユーザーIDを追加するエンドポイント）。一方で開発ガイドラインは、ナローキャストに使わないオーディエンスの作成と削除を高頻度で繰り返すことを、レート制限の範囲内でも行わないよう求めています（大量リクエストの禁止）。両方を満たすには、スコアの更新とオーディエンスの作成を切り離し、送る直前に、その回の送信対象でオーディエンスを作ります。

セグメントの出入りをそのまま映したいなら、オーディエンスを使わず、毎回の抽出結果をマルチキャストで送る方法もあります。人数の条件はかかりませんが、APIからの送信なので、文面は自社のシステム側で持つことになります（リファレンスのマルチキャスト）。

送った結果は、集計の単位で確かめる

セグメントの中に配信しない人を残して差で読む場合の、LINE での残し方と、来店・購入の突き合わせは「LINE配信で増えた売上の測り方」で解説しています。

ナローキャストは、受け付けから14日以内なら進行状況のエンドポイントで送信の成否と人数を確かめられ、開封やクリックはメッセージごとの統計で見られます。プッシュとマルチキャストは、リクエストにユニット名を1つ指定して送れば、そのユニットの単位で統計を取れます。ユニット名に使えるのは半角英数字とアンダースコアで30文字まで、1か月に付けられるのは1,000種類までです。どちらの統計も送信から14日間だけ更新され、20未満の値はnullになります（進行状況を取得する、ユーザーの操作に基づく統計情報、ユニットごとの統計情報、マルチキャストのリクエストボディ）。

AIのセグメントの効果を見るなら、セグメントの中から無作為に選んだ一部には送らずに残し、送った群との差で読むと、セグメントの質と配信の効き目を分けて考えられます。ユニット名を「churn_v3_send」のように、セグメント・モデルの版・群の順に並べておくと、後から集計しやすくなります。

送信のログに、セグメントの出どころを残す

ログについては、開発ガイドラインの推奨事項に、APIへのリクエストの記録（レスポンスヘッダーのリクエストID、リクエストした時刻、HTTPメソッド・呼び出したエンドポイント・返ってきたステータスコード）と、受信したWebhookの記録を一定の期間残すことが挙がっていて、LINE側はこれらのログを提供していないとされています（ログ保存の推奨）。AIのセグメントで送る場合は、これに加えて、モデルの版、セグメントの定義、抽出した日時、対象者が同意したプライバシーポリシーの版をリクエストIDと結び付けて残しておくと、ある会員になぜそのメッセージが届いたのかを後から説明できます。

よくある質問

まとめ

AIで作ったセグメントをLINEに戻すときは、担当者が管理画面で配信を組むならユーザーIDアップロード、データ基盤から自動で用意するならMessaging APIのオーディエンス、LINE上の反応や属性と掛け合わせるならナローキャスト、ユーザーIDの無い顧客にはビジネスマネージャーの共有、会員ごとに中身を変えるならユーザーIDを指定した送信、と使い分けます。どれを選んでも、会員IDとユーザーIDの紐付けは公式の仕組みで取り、分析して配信に使うことを利用目的に書いて同意を得ておくことが前提です。LINEの推定属性は配信の絞り込みにだけ使い、特定の人の属性を割り出したり、属性で送った配信の接触者を会員単位で追ったりはしません（Messaging API開発ガイドライン、LINE公式アカウント利用規約）。

ユーザーIDの紐付けや同意の取り方、送り方の選択といったLINE側の設計はLINEの運用と連携開発の支援で、セグメントを作る元になる計測とBigQueryなどのデータの整備はマーケティングデータの計測・分析基盤の支援で、Aurant Technologiesがご相談をお受けしています。セグメントの定義と送り方を並べて、どこから手を付けるかを決めるところからお手伝いします。