LINEの友だち紹介を仕組みにする｜標準のクーポンで足りる範囲と、紹介者の記録

LINE公式アカウントで友だちの紹介に特典を出すとき、紹介1件ごとに、紹介した人と紹介された人の両方へ同じクーポンを配る企画なら、管理画面のクーポンの獲得条件「友だち紹介」で足ります。誰が何人紹介したかを人ごとに知りたい、紹介の人数で特典を変えたい、来店や購入で紹介を成立させたい、紹介の記録を自社の会員台帳に残したい、のどれかに当てはまるなら、標準のクーポンだけでは足りません。紹介者ごとの URL を自社で作り、友だち追加と紹介者を結ぶ仕組みが要ります。

標準の機能で届かないところを、LINE とほかのシステムをつなぐ仕組みをお客さまの側に置いて補うのが、LINE公式アカウントの運用を支援している当社の仕事です。そのため紹介の企画でも、どこまでを標準のクーポンに任せ、どこから作るかを先に分けておきたいと考えました。友だち紹介クーポンは2024年7月のアップデートで加わった機能で、紹介した人を人ごとに知れるかは、クーポンの設定のマニュアルだけでは分からず、分析の画面、Messaging API、Webhook の資料を合わせて読む必要があります。この記事は、それらの資料をもとに、標準で足りる企画と自社で作る企画を分け、自社で作るものと、紹介の特典と景品表示法の関係を書きます。

クーポンの作り方の画面手順は「LINE公式アカウント クーポンの作り方」に書いています。置き場所ごとの友だち追加経路と、自社の入口でユーザーIDを取る仕組みは「「どのQRから友だちが増えたか」を見る方法」に、会員証の作り方は「LINEでデジタル会員証を作るには？」に書いたので、ここでは繰り返しません。例は1つ、「紹介した人と紹介された人の両方に、店で使える500円引きのクーポンを出す」という説明のための作例（架空の企画）で通します。

標準の「友だち紹介」クーポンは、紹介1件ごとに両方へ配る仕組み

管理画面でクーポンを「作成」するとき、獲得条件を「条件なし」「抽選」「友だち紹介」から選びます。マニュアル「クーポン」によると、友だち紹介を選ぶと、紹介した人・紹介された人に当たるユーザーだけが獲得できるクーポンになります。誰に、どの順でクーポンが届くかは次のとおりです。

作るときに決めるのは、クーポン名、紹介ページの画像と注意事項、紹介期間、獲得してからの有効期間、クーポンの画像と利用方法、紹介する人が獲得できる枚数、クーポンコードやバーコード、クーポンの種類です。紹介する人の枚数は、上限ありなら1〜30枚、上限なしなら紹介した分だけ獲得できます。有効期間は獲得日の翌日から数え、最終日の23:59までです。紹介期間を過ぎると紹介も獲得もできなくなりますが、獲得済みのクーポンは有効期間が終わるまで使えます。保存したクーポンは編集も削除もできないので、紹介期間と枚数は保存の前に決めます。

設定の項目は1つのクーポン分で、紹介した人と紹介された人で特典を分ける欄は、マニュアルには見当たりません。作例なら、紹介した人にも紹介された人にも、同じ500円引きのクーポンが紹介1件ごとに届きます。紹介した人が3人紹介すれば、枚数の上限の範囲で3枚獲得します。

友だち紹介のクーポンは、管理画面（LINE Official Account Manager）でしか作れません。Messaging API のクーポンを作るエンドポイントで指定できる獲得条件は「条件なし」と「抽選」で、友だち紹介は API では作れないと書かれています。

紹介した人を人ごとに知る手がかりは、公式の資料に見当たらない

紹介した人に特典を出す企画で次に気になるのは、誰が何人紹介したかを、あとから人ごとに見られるかです。公式の資料のうち、紹介の数が出てきそうな4か所を突き合わせました。

4か所とも、分かるのは集計か、クーポンそのものの情報です。紹介した人のユーザーIDと、紹介された人のユーザーIDの組を取り出す方法は、今回見た公式の資料には見当たりませんでした。マニュアルは紹介ページの URL を編集すると正しく獲得できない可能性があると注意しているので、標準の紹介ページの URL に自社の印を付け足して紹介者を見分ける形も選びにくくなります。

標準で足りる企画と、紹介者の記録が要る企画

標準のクーポンは「紹介ページから初めて友だちになった」を紹介の成立とし、成立のたびに2人へクーポンを配る、という形に作られています。この形のままで企画が成り立つかどうかが、分かれ目です。

マニュアルの設定項目に、紹介の人数で特典を変える欄は見当たりません。紹介する人の枚数の上限（1〜30枚か、上限なし）は、1件ごとに同じクーポンが何枚まで届くかを決める項目です。来店や購入を成立にする場合も、標準のクーポンは友だち追加の時点で2人に届くので、来店や購入を待ってから紹介した人に出す、という順にはできません。

どちらか迷うなら、標準のクーポンで始め、分析の集計で紹介がどのくらい起きるかを見てから、記録の仕組みを作るかを決める順番も取れます。分析の数字は前日分が翌日に反映され、重複して数えられることもあるとマニュアルにあるので、見当をつける材料として読みます。紹介の数が少ないうちに入口とサーバーを作っても、作る費用に見合うかは分からないからです。

紹介者を自社で記録するときは、「紹介が成立した」を自分で決める

自社で記録する作りは、紹介者ごとの URL を開いた人がそのまま友だちになったら、紹介した人と紹介された人を1行に結ぶ、という形になります。入口の LIFF のアプリで IDトークンからユーザーIDを確かめる仕組みと、プロバイダーのそろえ方は、置き場所の代わりに紹介コードを持たせるだけで「「どのQRから友だちが増えたか」を見る方法」の方法1と同じなので、そちらに譲ります。友だち追加の促し方だけは、成立の確かめ方に関わるので下で書きます。LIFF のアプリを新しく作るなら、LINEミニアプリとして作ることが勧められています（違いは「LINEミニアプリの審査で止まる点とサービスメッセージの条件」）。ここで書くのは紹介に固有の4点で、紹介コード、コードの受け渡し、成立の決め方、紹介した人への特典の送り方です。

紹介コードは、知られても困らない値にして送る

紹介する人は、まず自社の LIFF のアプリを開いて紹介用の URL を受け取ります。URL に付ける紹介コードは、ユーザーIDそのものではなく、自社で発行して対応表で戻せる値にします。LIFF の開発ガイドラインは、LIFF のエンドポイント URL や LIFF URL のフラグメントにはアクセストークンやユーザーIDなどの機密が含まれるとして、URL が外へ漏れないよう注意しています。紹介の URL は人から人へ転送されるものなので、載せる値は、ほかの人に知られても困らないものにしておきます。

送る手段には、LIFF のシェアターゲットピッカーが使えます。送り先を選ぶ画面を出し、選んだ友だちやグループに、開発者が作ったメッセージを本人が送ったかのように届けます。使うには、LIFF のアプリを追加したチャネルの［LIFF］タブで「情報利用に関する同意について」に同意して有効にする必要があり、この同意はチャネルごとです。公式の手順は LINEログインのチャネルの画面で書かれているので、LINEミニアプリで作るときの画面はLINEミニアプリのドキュメントで確かめてください。友だちが［アプリからの情報アクセス］を［拒否］にしている場合などは送り先の「友だち」欄に出ないので、URL をコピーして送る手段も残しておきます。

紹介された人の紹介コードは、liff.init() の後に読む

紹介された人が LIFF URL を開くと、最初に開く1次リダイレクト先では、URL に付けた追加情報はまとめて liff.state というクエリパラメータに入っています。LIFFアプリを開くの流れでは、ここで liff.init() を実行し、その後に開く2次リダイレクト先の URL に、付けたパスやクエリが元の形で付きます。紹介コードは、liff.init() の後に開いたページの URL から読みます。サーバーには「紹介コード・紹介された人のユーザーID・開いた日時」を残します。

成立の前に、本人による紹介と、もとから友だちの人を除く

記録の次に決めるのが、何をもって紹介の成立とするかです。標準のクーポンは、紹介された人が一度でも友だちになったことがあれば獲得できない、としています。自社の記録でこれに近い条件にするなら、次の順に確かめます。

本人による紹介は、紹介コードの持ち主のユーザーIDと、開いた人のユーザーIDが同じかで見分けます。開いた時点で友だちかどうかは、liff.getFriendship() で取れます。公式の手順は、LIFF のアプリを追加した LINEログインのチャネルに LINE公式アカウントをリンクし、アプリに profile のスコープを選んでおく形で書かれています（LINEミニアプリのときの画面はLINEミニアプリのドキュメントで確かめます）。

開いた時点の友だち関係で除くなら、友だち追加は、LIFF の権限の同意画面に出す友だち追加オプション（「どのQRから友だちが増えたか」の方法1の促し方）ではなく、アプリの中で liff.requestFriendship() を呼んで促します。同意画面のオプション（On (normal)／On (aggressive)）で追加した人は、アプリが動く前の同意画面で友だちになっているので、アプリが最初に呼ぶ getFriendship ですでに友だちと返り、本物の紹介まで除いてしまいます。前後を比べられるのは、アプリの中で促す場合です。

友だちになったことは、2つの取り方があります。1つはフォローイベントで、follow.isUnblocked が false なら友だち追加、true ならブロック解除です。ただしリファレンスは、この値が友だち追加とブロック解除の完全な正確さを保証するものではないとしています。また、プロフィール情報の取得に同意していないユーザーは、Webhook にユーザーIDが含まれません。この同意は、iOS版・Android版の LINE を使う人は利用開始時に済んでいて、当たるのは PC版LINEだけを使う人などです。LIFF の profile スコープの同意とは別のものです。フォローイベントで突き合わせる作りでは、その人は入口の記録と結べません。もう1つは、アプリの中で requestFriendship で友だち追加を促したあとに、LIFF の中で liff.getFriendship() を取り直す形で、入口で確かめたユーザーIDと友だち関係から、Webhook を待たずに判定できます。

どちらの取り方でも、記録を始める前の友だち関係は自社に残っていないので、標準のクーポンの「一度でも友だちだった人は対象外」と全く同じ条件は、自社の記録だけでは決められません。紹介の告知には、対象外にする人の決め方を自社の言葉で書いておきます。来店や購入を成立の条件にするなら、紹介された人のユーザーIDを、会員証や予約の記録と結ぶ仕組みも要ります。

紹介した人への特典は、プッシュで送ると通数に数えられる

成立したら、紹介した人に特典を送ります。Messaging API では、条件なしか抽選のクーポンを作り、クーポンメッセージで送れます。クーポンメッセージの deliveryTag に表示経路の名前（半角英数字とアンダースコアで30文字まで）を入れておかないと、分析での経路は「不明」になります。

紹介した人へは、こちらから送るのでプッシュメッセージになり、料金プランのメッセージ通数に数えられます。応答メッセージは数えられませんが、紹介した人から届いたイベントへの返信ではないので、応答では送れません。紹介された人には、友だち追加のフォローイベントに応答してクーポンを送れば、通数に数えない送り方になります。応答トークンは Webhook を受け取ってから1分以内に使う決まりなので、成立の確かめはその間に済む範囲にとどめます。標準の友だち紹介クーポンの獲得通知は無償とされているので、紹介した人への送り方は標準との費用の違いになります。通数と料金プランの関係は「LINE公式アカウントの料金プランの選び方」にまとめています。

紹介の記録を何に使うかは、URL を開いた画面で示す

紹介の記録は、紹介した人と紹介された人の2人分の情報を結びます。LIFF の開発ガイドラインは、ユーザーの同意なく、cookie などでユーザーを追跡したり、LINE のユーザー情報と外部のセッション情報を結びつけたりしないよう求めています。紹介コードとユーザーIDを結んで何に使うかは、LIFF のアプリを開いたときに LINE が出す権限の同意画面とは別に、紹介する人の画面と紹介された人の画面の両方で示し、同意を得てから記録するのが筋だと当社は考えています。

とくに、紹介した人へ「紹介した相手が友だちになった」と知らせるかどうかは、紹介された人の情報を紹介した人に伝えることになります。知らせるなら、紹介された人に示す内容にそれを含めます。名前を出さず、成立した件数だけを知らせる形にもできます。会員の退会や連携の解除を受け付けるときは、LIFF のアプリに認可した権限を取り消すエンドポイントで、ユーザーの代わりに権限を取り消すことも、ガイドラインで求められています。LINEログインで受け取る情報の範囲は「LINEログインで取得できる情報」に書きました。

紹介の特典と景品表示法：原文の条件と、当社の読みを分けて書く

紹介の特典を決めるときに確かめたいのが、景品表示法の景品規制です。ここでは消費者庁の告示・運用基準・Q&Aの原文の条件を書き、LINE の友だち紹介への当てはめは「当社の読み」として分けます。どれも断定ではなく、最後の「消費者庁や専門家に確かめる点」を確かめてから決めてください。

紹介した人への特典

原文：運用基準の4(7)は、自己の商品・役務の購入者を紹介してくれた人への謝礼は「取引に附随」する提供に当たらないとし、括弧書きで「紹介者を当該商品又は役務の購入者に限定する場合を除く」としています。Q&A の Q31は、限定する場合は取引に付随する提供となって景品類に当たり、通常、総付景品の規制の対象になるとしたうえで、購入した上で紹介することが条件なら取引の価額はその商品の価格、過去の購入者に限るなら告知した後に起こり得る通常の取引のうち最低のもの、と示しています。

当社の読み：4(7)と Q31 は、購入者を紹介してくれた人への謝礼の規定です。標準の友だち紹介クーポンは、紹介された人が友だち追加した時点で紹介した人にクーポンが出て、購入は条件ではありません。この点で、規定の前提とは違うと当社は読んでいます。作例では、紹介した人に出るのも店で使う500円引きです。そのため、紹介した人への特典も、紹介された人への特典と同じく、自社の取引で使う割引券として、下の値引の考え方（運用基準 6(3)、Q11・Q21）で見るのが近い、と当社は読んでいます。

当社の読み（購入で成立させる場合）：自社の記録で、紹介された人の購入で紹介を成立させ、紹介できる人は絞らない形は、4(7)の本文の場面（購入者を紹介してくれた人への謝礼）にいちばん近いと当社は読んでいます。

当社の読み（紹介できる人を限定する場合）：自社の記録の仕組みで、紹介できる人を購入者に限定すると、4(7)の括弧書きと Q31 の場面に近づきます。会員に絞る場合は、その会員が購入者と同じ意味かで変わると当社は読んでいます。Q31 は、限定する場合は通常、総付景品の規制の対象になるとしています。そのうえで、特典の中身で見方が分かれ得ると当社は読んでいます。特典が品物や引換券なら、総付景品の限度（取引価額1,000円未満は200円、1,000円以上は10分の2）の中で考えます。作例の500円引きのような、自社の取引で使う割引券なら、値引（運用基準 6(3)）に当たるか、総付景品の告示2項の割引券（正常な商慣習に照らして適当なものには限度の規定を適用しない）に当たるかを見ます。どちらになるかは、割引の基準が取引通念上妥当かなど、企画の条件で変わります。

紹介された人への特典

原文と事実：紹介された人は、友だち追加で特典を受け取ります。Q18は、SNS のアカウントのフォローや「いいね」は通常は商品・サービスの購入に直ちにつながらないとし、Q20は、SNS の友達登録で応募でき、当選者が景品を受け取るのに来店が要る企画を、取引に付随し、来店したらもれなく受け取れるので総付景品の規制の対象としています。運用基準の4(2)は、取引を条件としなくても、取引の相手方を主たる対象として行われる提供は取引に付随するとしています。

原文：一方で、景品類の定義は、正常な商慣習に照らして値引と認められる経済上の利益を含みません。運用基準の6(3)は、取引通念上妥当と認められる基準で対価を減らすことを原則として値引に当たるとし、例に「次回の買物で○○円の割引」を挙げています。Q11は、クーポン券が各店舗で使える割引券である場合は、取引通念上妥当と認められる基準に従っていれば値引で景品規制は適用されず、1杯無料のような引換券なら総付景品の規制の対象、と分けています。Q21は、誰でも応募できる懸賞で店で使える値引券を配る企画を、来店が要るので取引に付随するとしつつ、正常な商慣習に照らして値引と認められるなら景品類に含まれない、としています。総付景品の告示の2項も、自己の取引で使う割引券で正常な商慣習に照らして適当なものには、限度の規定を適用しないとしています。

当社の読み：作例の「店で使える500円引き」を友だち追加で配る形は、誰でも参加でき、店で使う値引券を配る Q21 の形に近いので、値引として見る筋があると当社は読んでいます。クーポンの中身を品物の進呈などにして来店で受け取る形にすると、Q20 の形に近づきます。購入を条件にせず来店者に提供する場合の取引の価額は、Q72で原則100円（店で通常行われる取引の最低額が100円を超えるならその額とすることができる）とされているので、総付景品の限度は200円から考えることになります。

抽選や景品類と組み合わせる場合

原文と事実：管理画面のクーポンでは、友だち紹介と抽選は別の獲得条件で、1つのクーポンで両方は選べません。取引に付随する企画を、くじなど偶然で相手や額を決めて行うと懸賞になり、一般懸賞の限度（最高額は取引価額の20倍で10万円まで、総額は売上予定総額の2%）があります。運用基準の6(4)アは、対価の減額であっても、懸賞による場合、減額した金銭の使途を制限する場合（例は旅行費用に充てさせる場合）、同一の企画において景品類の提供と併せて行う場合は、値引に当たらないとしています。紹介した人に割引券、紹介された人に1杯無料の引換券、のように同じ企画の中で割引と景品類を組み合わせる形は、最後の場合に関わり得ると当社は読んでいます。新聞業・雑誌業・不動産業・医療用医薬品業などには業種別の告示があり、一般の規制と内容が違います。

始める前に決めることと、消費者庁や専門家に確かめる点

まず、記事の最初の判定の図の4つの問いに、自社の企画を当ててください。全部当てはまるなら、管理画面で友だち紹介のクーポンを作り、紹介期間・紹介する人の枚数・紹介ページの注意事項を、保存の前に決めます。1つでも外れるなら、入口を作る前に、紹介の成立の決め方（本人による紹介、もとから友だちの人、来店や購入）と、紹介の記録を何に使うかを示す文面を先に決めます。この2つが決まらないと、記録する項目も、同意の画面も決まらないからです。

景品表示法の当てはめは、次の点を消費者庁や専門家に確かめてください。

• 紹介した人への特典を、運用基準4(7)・Q31（購入者を紹介した人への謝礼）の規定で見るか、自社の取引で使う割引券として値引（運用基準6(3)・Q11・Q21）で見るか
• 紹介できる人を購入者に限定していないか（会員に絞るなら、その会員が購入者に当たるか）。限定するなら、取引の価額を何で置き、特典が品物・引換券なら総付景品の限度、自社の取引で使う割引券なら値引か総付景品の告示2項の割引券に当たるか
• 紹介を購入や契約で成立させる場合も、紹介できる人を購入者に限定していないか
• 友だちの多くが来店客であるなどの事情が、取引の相手方を主たる対象として行われる提供か（運用基準4(2)）の判断に関わるか
• 紹介された人への割引が取引通念上妥当な基準か（割引の額、使える範囲）、それとも引換券や品物か
• 抽選を組み合わせていないか。同じ企画の中で、割引と品物・引換券を組み合わせたり選ばせたりしていないか（運用基準6(4)ア）
• 業種別の告示がある業種か

紹介の記録のように LINE とほかのシステムをつなぐ仕組みを作る前の、どこまでを標準のクーポンに任せるかで迷う段階の相談も、当社のLINE運用・伴走支援のページで受け付けています。

仕様と規定は、2026年10月14日に次の公式の資料を開いて確かめたものです。LINEヤフー for Business：マニュアル「クーポン」（2026.04.27 更新）、「分析 – クーポン」（2025.05.21 更新）、「分析 – 友だち」（2026.03.24 更新）、お知らせ「アップデート情報 2024年7月」（2024.08.15）。LINE Developers：Messaging APIリファレンス、クーポンを作成してユーザーに送る、Messaging APIの料金、ユーザーIDを取得する、ユーザーのプロフィール情報取得の同意、LIFFアプリおよびサーバーでユーザー情報を使用する、LIFFアプリを開く、LIFFアプリを登録する、LIFFアプリを開発する、LIFFアプリ開発ガイドライン、LINEミニアプリ。消費者庁：景品規制の概要、景品類等の指定の告示、同運用基準、総付景品の告示、懸賞の告示、景品に関するQ&A（景品類とは）・（景品規制について）。紹介した人を人ごとに知る手がかりの表は、管理画面の分析2つ、Messaging API のクーポン、Webhook のイベントの一覧の4か所を突き合わせたもので、ほかの資料に書かれている可能性はあります。作例の企画と金額は説明のための架空のものです。図の分け方は当社の整理です。