LINEの配信を誰が開き、誰が押したかは分かるか｜開封は集計だけ、押した人は自社で記録する

誰が開いたかは分かりません。LINE公式アカウントの配信を誰が開封したかは、LINE Official Account Manager（管理画面）の［分析］、Messaging API の統計、CRMオプションの分析のどれを見ても、人ごとには出てきません。LINE Developers の FAQ も、ユーザーがメッセージを読んだかどうかを確認する方法は Messaging API で提供していない、と答えています（FAQ）。一方、誰が押したかは、作り方しだいで分かります。メッセージのボタンを押した、リンク先のページを開いた、動画を最後まで見た、という反応は、LINE から自社のサーバーに届く出来事にするか、自社のページで本人を確かめる形にしておけば、1人ずつ記録できます。

配信の成果を社内に説明するとき、配信の反応（開封・クリック）を示す画面の数字はどれも人数か回数で、名前の並んだ一覧はありません。反応を人ごとに追いたいなら、何を LINE から受け取り、何を自社の台帳に持つかを、配信を作る前に決めておく必要があります。2026年7月1日には Messaging API で作ったリッチメニューの統計情報も取れるようになりましたが、これも合計と日別の集計です（LINE Developers のお知らせ）。そこで、LINE公式アカウントの運用と、LINE を会員の台帳などほかのシステムとつなぐ仕組みを支援している当社の立場から、LINE から受け取れるものと、自社で持つしかないものを、公式の資料で分けておきます。

この記事では、配信の反応を指標ごとに「人ごとに取れるか」で並べ、押したかを人ごとに残す3つの作りを比べます。開封率・クリック率が何を数え、いつ確定するかは「LINE公式アカウントの分析の見方」に書いています。KPI をどの段に置くかは「LINE公式アカウントのKPIとエンゲージメント」、配信で上乗せされた売上の測り方は「LINE配信で増えた売上の測り方」、どのQRから友だちが増えたかの見方は「「どのQRから友だちが増えたか」を見る方法」に譲ります。

例は1つに決めます。記事の途中に置いた当社のデモと同じ、架空の会社「デモ商会」の配信です。デモ商会は、会員がよく買う商品（キッチン・インテリア・文具）を会員台帳（CRM）に持っています。台帳で「ゴールド会員・最終来店が60日以上前・よく買うのはキッチン」の会員を選ぶと4人で、そのうち LINE と連携している3人に「新作のご案内（会員さま限定）」を送ります。メッセージには「クーポンを見る」のボタンが1つあります。この3人の誰が開き、誰が押したかが、どこまで分かるかを見ていきます。

開封は、どの画面でも人ごとには戻らない

管理画面の［分析］＞［メッセージ配信］にある［開封］は、メッセージを開封した人数で、誰かは出ません。人数が少ないと［開封］は「0」と表示されるので、例の3人への配信なら、3人とも開いていても「0」です（分析 – メッセージ配信）。開封の数え方と「0」の読み方は分析の見方の記事で扱っています。

Messaging API で送る場合は、送り方で統計の取り方が変わります。ナローキャストとブロードキャストは、送信リクエストごとの統計を「ユーザーの操作に基づく統計情報を取得する」エンドポイントで取れ、統計は送信から14日間だけ更新されます（リファレンス）。プッシュとマルチキャストは、ユーザーのプライバシー保護の観点から、通常は開封やURLのタップの統計を取れません。送るときにユニット名（customAggregationUnits）を1つ付けておいた場合だけ、そのユニットにまとめた値が取れます（送信したメッセージの統計情報を取得する）。どちらも、値が20未満の場合と、20以上でもその操作をした実人数が20人未満の場合は null になります。

CRMオプションでも変わりません。LINEヤフーのヘルプは、配信ごとの開封率は確認できるが、どの顧客が開封したかを個別に確認することはできない、と答えています（ヘルプ「どのユーザーがメッセージを開封したか確認できますか？」）。ユーザーリスト配信分析とオートメーション分析では、開封やクリックユーザーの値が10未満だと「-」と表示されます（ユーザーリスト配信分析・オートメーション分析）。

誰が開いたかは見えなくても、開いた人にもう一度送ることはできます。管理画面のオーディエンスの「メッセージインプレッション」は、過去の配信を開封したユーザーを対象にしたもので、配信に使うにはサイズが50以上必要です（オーディエンス）。Messaging API でも、ナローキャストかブロードキャストのリクエストIDを指定してメッセージインプレッションオーディエンスを作れます。作れるのは配信から60日以内で、保存は最大180日です（メッセージインプレッションオーディエンスを作成する）。ただし、オーディエンスの情報として返るのは人数（audienceCount）です（オーディエンスの情報を取得する）。読んだかどうかを人ごとに確かめる方法も、提供されていません。開いた人の名前を営業に渡して連絡する使い方は、開封を起点には組めません。

指標ごとに、4つの置き場所で人ごとに取れるかを並べる

開封のほかの指標も、置き場所ごとに見ていきます。次の表は、LINE Developers のドキュメント・リファレンス・FAQ と、LINEヤフー for Business のマニュアル・ヘルプの原文で、1つずつ埋めたものです。「—」は、その置き場所に当たる機能を公式の資料で確かめられなかったところです。「自社で記録」の列は、Webhook を受けるサーバーと会員台帳を自社に置いた場合です。CRMオプションでできることと足りないことの全体は「CRMオプションでできること・足りないこと」にまとめています。

出典：LINEヤフー for Business の分析 – メッセージ配信・オーディエンス・分析 – リッチメニュー・分析 – 友だち・リッチメッセージ・ユーザーリスト・ユーザーリスト配信分析、LINE Developers の送信したメッセージの統計情報を取得する・プッシュメッセージを送る・ポストバックイベント・動画視聴完了イベント・リッチメニューの統計情報・フォロー解除イベント・友だちのユーザーIDのリスト。

表の「自社で記録」の列では、届いたイベントの送信元のユーザーIDを、会員台帳の会員IDと結んで書き込みます。ただし、ユーザーがプロフィール情報の取得に同意していない場合、Webhook にユーザーIDは入りません。iOS版・Android版の LINE を使う人は利用開始時に同意しており、PC版 LINE だけを使う人は同意できない、とされています（ユーザーのプロフィール情報取得の同意）。ユーザーIDはプロバイダーごとに違う値になるので、Webhook を受ける Messaging API のチャネルと、後で出てくる LIFF のチャネルは同じプロバイダーの下に置きます（ユーザーIDを取得する）。表の「ブロック」の行にある友だちのユーザーIDの一覧は、認証済アカウントで取れます。LINE Developers の同じページは今も「認証済アカウントまたはプレミアムアカウント」と書いていますが、プレミアムアカウントは2026年4月1日に認証済アカウントに統合されました（LINEヤフー for Business のお知らせ「認証バッジおよび識別仕様の変更について」）。今のアカウント種別は、認証済アカウントと未認証アカウントの2つです（アカウント種別、どちらも2026年10月20日に確認）。

例の3人で、台帳に何が戻るかを確かめる

例の配信は、架空の会社・会員・購入の記録で作った当社のデモ「LINE×CRM連携の流れ」で、最後まで進められます。会員台帳には「配信」「開封」「クリック」「来店・購入」の列があり、送ったあとに、どの列が会員ごとに埋まり、どの列が埋まらないかが分かります。

デモでは、クーポンのリンクに会員ごとの識別子を付けて、誰が押したかを台帳に記録する想定にしています。ただ、このデモの送り方は、既定のマルチキャストも、もう1つのオーディエンスを作って送る方法も、3人に同じメッセージを送ります。そのため、会員ごとに違うリンクは実際には付けられません。マルチキャストのまま誰が押したかを残すなら、次の節の作り1か作り2で組みます。

押したかを人ごとに残す3つの作りと、選ぶと変わること

「クーポンを見る」を誰が押したかを残す作りは3つあります。ユーザーIDと会員IDの結び方と、それにかかる費用の決まり方は「LINEと今の顧客管理をつなぐ3つの作り方」に書いています。ここでは3つを、どう記録するか、送り方の条件、LINE 側の集計への影響、気をつける点の順で比べます。

作り1：ボタンをポストバックにする

ボタンのアクションをポストバックアクションにすると、押されたときに、data に入れた文字列（最大300字）を含むポストバックイベントが Webhook で届きます（ポストバックアクション・ポストバックイベント）。イベントの送信元にはユーザーIDが入るので、data に配信の名前とボタンの名前を入れておけば、誰が・どの配信の・どのボタンを・いつ押したかが1件ずつ残ります。メッセージの中身は全員同じでよいので、マルチキャスト・ナローキャスト・ブロードキャストでも使えます。例の配信なら、3人に同じメッセージを送り、届いたイベントのユーザーIDから会員の行を引いて「クリック」に書き込みます。

ポストバックはトークの中で完結するので、クーポンのページを見せたいときは、そのイベントへの応答でリンクやクーポンを返します。管理画面から送るリッチメッセージのアクションは「リンク」「クーポン」「テキスト」で、ポストバックは選べません。「テキスト」は入力したテキストをトークルームに送るアクションなので（リッチメッセージ）、Webhook を受けていれば、ユーザーが送ったメッセージのイベントとして自社のサーバーに届きます（Webhookイベントを受信する）。押した人がトークに文字を送ったように見えるので、送る文言は、押した人が読んで不自然にならないものにします。

作り2：リンク先を LIFF にして、開いた人を確かめる

ボタンのリンク先を LIFF アプリ（LINE の中で開く Web アプリ）の LIFF URL にすると、全員に同じURLを送っても、開いた人を自社のサーバーで確かめられます。LIFF アプリで liff.getIDToken() で取ったIDトークンをサーバーに送り、サーバーで検証すると、IDトークンの sub にユーザーIDが入っています（IDトークンを検証する）。どの配信から開いたかは、LIFF URL のあとにパスやクエリパラメータを付けて分けます。LIFF URL に付けたパス・クエリパラメータ・URLフラグメントは、リダイレクト先のURLにも付くと FAQ に書かれています（FAQ）。

https://liff.line.me/{liffId}/coupon/?campaign=newitem-member

例の配信なら、3人とも同じ上のURLを開き、自社のサーバーには「誰が（sub）」と「どの配信から（campaign）」がそろって届きます。管理画面から送る配信でもリンクに LIFF URL を入れられるので、Messaging API で送る仕組みを持たない場合にも使えます。ただし、管理画面で LINE Tag の利用を始めたアカウントでは、メッセージ配信で設定したすべてのURLが LINE ドメインのリダイレクタを経由し、タップすると必ず外部ブラウザに移る、とマニュアルにあります（トラッキング（計測タグ・LINE Tag））。その場合、LIFF URL は外部ブラウザから開かれることになり、LIFF アプリが LIFF ブラウザで開くとは限りません（LIFFアプリを開く）。外部ブラウザで開いたときは liff.login() でログインしてからIDトークンを取ります（LIFFアプリを開発する）。

公式が警告していることが1つあります。liff.getProfile() などで取ったユーザーのプロフィールを、LIFF アプリからサーバーに送ってはいけません。なりすましなどの攻撃に弱くなるためで、サーバーにはIDトークンかアクセストークンを送り、サーバー側で LINE に問い合わせて確かめます（LIFFアプリおよびサーバーでユーザー情報を使用する）。IDトークンを取るには、LIFF アプリに openid スコープを選び、ユーザーが認可している必要があります（LIFFアプリを開発する）。認可が必要なときは、開く前にチャネル同意画面が出ます。LINE の外で LIFF URL を開いた場合に LIFF ブラウザが開くことは保証されていません（LIFFアプリを開く）。

作り3：人ごとに違うURLを付ける

クーポンのURLに、会員ごとに自社で発行した値を付けて送る作りです。リンク先がふつうの Web ページでも、届いた値で誰が開いたかを記録できます。ただし送る内容が人ごとに変わるので、1回のマルチキャストで全員に送ることはできず、1人ずつ送ります。マルチキャストは複数のユーザーに同じメッセージを送る API で、送り先が1人ならプッシュの利用が勧められています（マルチキャストメッセージを送る）。デモの配信をこの作りにするなら、3人に1通ずつプッシュを送ります。

LINE 側の集計にも影響します。プッシュの統計は、ユニット名を付けて送った場合にだけ取れるユニットごとの統計で、ユニット名を付けなければ開封・タップの統計はそもそも取れません。ユニット名を付けた場合も、clicks はURLごとのタップの回数と人数で、値が20未満なら null になります（ユニットごとの統計情報を取得する）。人ごとにURLが違えば、どのURLも1人分なので、URLごとの数は null になり、使えるのはユニット全体の数字だけになる、と当社は読んでいます。付ける値には LINE のユーザーIDをそのまま使わず、自社で発行した推測しにくい値にしておくと、URLがブラウザの履歴やアクセスログに残っても LINE のユーザーIDは出ません。URLを知った人なら誰が開いても、その会員として記録されることも前提にしておきます。

URLの扱いには、もう1つ条件があります。LINE Tag の利用を始めたアカウントでは、管理画面のメッセージ配信で設定したすべてのURLが LINE ドメインのリダイレクタを経由し、短縮URLサービスを使うとコンバージョンの計測やオーディエンスへの反映が正しく行われないことがある、とマニュアルにあります（トラッキング（計測タグ・LINE Tag））。LINE Tag を使っていない場合と、Messaging API で送った場合のURLの扱いは、公式の資料には見当たりません。付けた値がそのままリンク先に届くかは、後の「確かめる手順」の4で、自社のアクセスログを見て確かめます。

人ごとに記録する前に、利用目的とLINEの決まりを整える

押したかを会員ごとに記録し、それで配信を分けることは、本人の行動や関心を分析することにあたる、と当社は考えます。個人情報保護委員会のガイドライン（通則編）の 3-1-1 は、本人から得た情報から行動・関心などを分析する場合、どのような取扱いが行われているかを本人が予測・想定できる程度に、利用目的を特定しなければならないとしています。具体的に特定している例として、閲覧履歴や購買履歴を分析して、趣味・嗜好に応じた新商品・サービスの広告に使う、という書き方が挙げられています（個人情報の保護に関する法律についてのガイドライン（通則編））。

LINE の側にも決まりがあります。LINEユーザーデータポリシーは、Messaging API や LIFF などを使う事業者に、サービスのプライバシーポリシーを作り、利用を始める前を含めて誰でもいつでも見られるよう公開すること、集める個人情報を通知して同意を求めること、利用目的を特定して必要な情報だけを集めることを求めています。ユーザー識別のための内部識別子（ユーザーID）以外の LINE ユーザー情報を24時間以上保存する場合は、保存することをユーザーに明示し、自社のアカウントと LINE のアカウントを結ぶ場合は、結びつきを解除する機能と退会の機能を用意する、ともあります（LINEユーザーデータポリシー 2.2〜2.4、3.2.3、3.2.10）。

LINE ログインや LIFF の同意画面に出るのは、LINE がプロフィール情報や内部識別子を事業者に渡すことへの認可で、表示される項目は「メインプロフィール情報」「あなたの内部識別子」などです（LINEログインを組み込む）。押したかを記録して配信に使うことは、この画面では伝わらないので、自社のプライバシーポリシーと会員連携の画面で示します。デモの会員連携の画面では「連携すると、購入の内容や会員ランクに合わせたお知らせが、このLINEに届きます。」と出しています。実際の画面では、ここに「メッセージへの反応を記録し、お知らせの内容を分けるために使う」ことまで書いておくと、本人が予測できる形になる、と当社は考えます。LINE ログインで受け取る情報と同意の範囲は「LINEログインで取得できる情報」で扱っています。

配信の絞り方にも決まりがあります。LINE公式アカウント利用規約の第18条（7）は、みなし属性を利用して配信する場合に、配信に接触した利用者の属性を識別する行為を禁止し、属性ごとに別の遷移先を指定することや、遷移先のURLに遷移経路を追跡できる情報を付けることも含まれるとしています（LINE公式アカウント利用規約、改定日2023年10月1日）。みなし属性は、LINE ユーザーが登録した性別・年代・エリア情報と行動履歴をもとに分類した属性です（友だちの属性情報に基づく統計情報を取得する）。この属性で絞った配信で押した人を1人ずつ記録すると、その人がその属性と推定されたことが分かってしまいます。そのため当社は、人ごとに記録する配信では、送り先を自社の台帳の条件（ユーザーIDの指定や、アップロードしたオーディエンス）で決めるのが安全だと考えています。例のデモ商会の配信は、会員台帳のランク・最終来店・よく買う商品で選んでいるので、この形です。判断が分かれる設計は、作る前に LINEヤフーに確かめます。

自分のアカウントで確かめる手順

ここまでの決まりは、自分のアカウントで確かめられます。送る相手は自分と社内の担当者に限り、ふだんの配信とは別に試します。

1. 管理画面の［分析］＞［メッセージ配信］で、少人数に送った配信を開きます。［配信］は実数で、［開封］が「0」になっているかを見ます。
2. Messaging API で送っている場合は、ナローキャスト・ブロードキャストならレスポンスヘッダーにあるリクエストIDで、プッシュ・マルチキャストなら送ったときのユニット名で、統計のエンドポイントを呼びます（下のコマンド）。少人数なら uniqueImpression や uniqueClick が null になるか、clicks が空になります。
3. 作り1・作り2を試すときは、LINE Developers コンソールのチャネルの［チャネル基本設定］タブにある［あなたのユーザーID］で自分のユーザーIDを確かめます（LINE アカウントと連携していないビジネスIDでは表示されません）。自分に送ったメッセージのボタンを押し、ポストバックイベントの source.userId、または LIFF から送ったIDトークンを検証した sub が、その値と一致するかを見ます（ユーザーIDを取得する）。
4. 作り2・作り3でリンクを使うときは、値を付けたURLを自分にだけ送ってタップし、どのブラウザで開いたかと、自社のサーバーのアクセスログに付けた値がそのまま届いているかを見ます。管理画面と Messaging API の両方で送っているなら、両方で試します。

curl -v -X GET 'https://api.line.me/v2/bot/insight/message/event?requestId={requestId}' -H 'Authorization: Bearer {channel access token}'

curl -v -X GET https://api.line.me/v2/bot/insight/message/event/aggregation -H 'Authorization: Bearer {channel access token}' --data-urlencode 'customAggregationUnit={ユニット名}' --data-urlencode 'from=20261001' --data-urlencode 'to=20261031' -G

1つ目はナローキャスト・ブロードキャストの送信リクエストごと、2つ目はユニットごとの統計で、どちらもレート制限は1時間に60リクエストです（ユーザーの操作に基づく統計情報を取得する・ユニットごとの統計情報を取得する）。ユニットごとの統計には送った通数と送信対象の人数が入らないので、開封率の分母は送った側の記録から取ります（送信したメッセージの統計情報を取得する）。

次の配信のボタンを、人数で足りるものと人ごとに要るものに分ける

次の配信を作る前に、メッセージに置くボタンとリンクを並べ、それぞれに「人数で足りるか、人ごとに要るか」を書き込んでみてください。人数で足りるものは管理画面と API の集計で見ます。人ごとに要るものだけ、作り1〜3のどれで記録するか、記録した反応を台帳のどの列に入れ、何に使うかを決めます。何に使うかが決まれば、利用目的の書き方と会員連携の画面の文面も、そこから決まります。記録した反応の差を配信の効果として説明したいときは、配信しない人を残して比べる「LINE配信で増えた売上の測り方」につなげます。サイトでの行動を GA4 で見る方法は「GA4でLINEからの流入を見る方法」にあります。

会員台帳と LINE をどうつなぐか、作り方と費用が決まる所は「LINEと今の顧客管理をつなぐ3つの作り方」に書いています。記録の受け口と台帳の列を、今の会員データに合わせて決めたいときは、当社のLINE運用・伴走支援でご相談いただけます。

画面の名前・数字の決まり・API の仕様は、2026年10月14日に LINE Developers、LINEヤフー for Business のマニュアルとヘルプ、LINE公式アカウント利用規約、LINEユーザーデータポリシー、個人情報保護委員会のガイドライン（通則編）を開いて確かめたものです。