マーケティングオートメーションサービス LINE活用機能仕様書

— LINE公式アカウント × LIFF による識別済みリードの継続接点基盤 —

目次

1. はじめに
2. 発想の転換 — LINEをBtoBで使うための3つの考え方
3. LINEプラットフォームの前提知識
4. システム全体像
5. 機能要件 第I部 — 接続・識別基盤(F-25〜F-28)
6. 機能要件 第II部 — 体験・シナリオ(F-29〜F-32)
7. 機能要件 第III部 — 統制・分析(F-33〜F-35)
8. ユースケース別シナリオ設計
9. 計測仕様
10. 画面仕様(追加)
11. データベース設計(追加)
12. API設計(追加)
13. 非機能要件
14. 法令・コンプライアンス
15. 段階導入計画
16. 今後の検討事項
17. 出典

1. はじめに

1.1 背景

v1.2 と v2.0 で、本システムの獲得チャネルは次の5系統に広がった。

これらに共通して残っている穴が 「実名を取得したあと、商談化までの数週間〜数か月をどう繋ぐか」 である。

v2.0 の F-20(コンテンツゲートとナーチャリング)は、この期間をメール配信で埋める設計になっている。しかし現実には次の問題が起きる。

LINE公式アカウントは、この4点をすべて改善しうる。東急ストアの公表事例では、同一施策に対して開封率 76.4%(メール 16.0%)、クリック率 24.7%(メール 3.9%)という差が出ている(出典: LINEヤフー導入事例)。開封タイミングも約20%が即時、約80%が当日中である。

1.2 目的

本書は、以下を目的とした LINE 活用機能を定義する。

1. 識別済みリードとの継続接点 — 実名を取得した個人と、商談化までの期間をLINEで繋ぐ
2. 即時性の獲得 — ウェビナー・展示会・見積依頼など、分単位の速さが価値になる場面を機能化する
3. プル型の窓口化 — リッチメニューとLIFFで「相手が来たときに答える」導線を常設し、配信を増やさずに接点を維持する
4. 既存チャネルとの統合計測 — LINEの反応を F-23(チャネル横断アトリビューション)に統合し、メール・フォーム・LPと同じ土俵で比較する

1.3 v1.2 / v2.0 との関係

• v1.2(F-01〜F-10)、v2.0(F-11〜F-24)は変更しない。本書の機能はすべてその上に積む
• v1.2 の tracking_code(F-09)を LINE友だち追加の識別キーとしても使う。これが本書全体の前提である
• v2.0 の F-14(LP行動計測)のイベントスキーマを LINE イベントにも拡張して使う
• v2.0 の F-23(アトリビューション)に LINE を1チャネルとして追加する
• v2.0 の F-24(コンプライアンス・ガードレール管理)に LINE 固有のガードレール G-16〜G-27 を追加する

1.4 スコープ

含むもの

• LINE公式アカウント(Messaging API)による配信・応答・リッチメニュー
• LIFF(LINE Front-end Framework)によるLINE内Webアプリ(申込・診断・予約・配信設定)
• 友だちと自社企業マスタ(companies / contacts)のID連携
• LINE行動の計測とチャネル横断アトリビューションへの統合
• 配信通数・ブロック率のガバナンス機能
• 上記に伴うコンプライアンス管理

含まないもの

• LINE広告(LINE Ads)の運用。友だち追加広告(CPF)は BtoB でのターゲティング精度が低く、費用対効果が見込めないため本書では機能化しない(4.4項に判断根拠を記す)
• LINEミニアプリの認証済申請・アプリ内課金。将来検討事項(16章)とする
• LINE通知メッセージ(電話番号ベースの配信)。当社の取得データと適合しない
• LINEのトーク内容そのものを解析するAI機能(LINE公式の有料オプションを利用する場合を除く)

1.5 用語定義(追加分)

2. 発想の転換 — LINEをBtoBで使うための3つの考え方

「LINEでマーケティングをする」という要望をBtoB受託開発の文脈にそのまま持ち込むと、BtoCの成功パターンをなぞって失敗する。本章はその理由と、代わりに何を設計するのかを先に述べる。以降の機能要件はすべてこの3つの考え方から導かれている。

2.1 なぜ「LINEで新規リードを集める」は当社では成立しないのか

LINEはBtoCで極めて強い。しかし当社がやろうとしているBtoB受託開発の新規獲得に対しては、次の4つの構造的な壁がある。

結論: LINEを新規リード獲得チャネルとして使ってはならない。当社にとってのLINEは「まだ会ったことのない人を集める場所」ではなく、「すでに接点のある個人と、即時性が価値を持つ場面で繋がるための回線」である。

2.2 中核アイデア① — 友だちを増やさない。「識別済み友だち」だけを増やす

一般的なLINEマーケティングのKPIは「友だち数」である。当社ではこれを採用しない。

未識別の友だち(誰か分からない友だち)は、当社にとって資産ではなくコストである。

したがって本仕様では、友だち追加の導線を必ず tracking_code 付きにする(F-26)。既存のメール・フォーム・LP・ウェビナー申込のいずれかを通過した人だけが友だちになる設計とし、追加された瞬間に company_id の解決を試みる。

設計上の要点: 主要KPIは「友だち数」ではなく 「識別済み友だち数」 と 「識別率」。ダッシュボード(S-28)ではこの2つを最上位に置き、友だち総数は副次指標として小さく表示する。

2.3 中核アイデア② — 「送る」のをやめる。課金構造がメールと真逆である

メール営業(F-08)では、送信コストは実質ゼロに近い。SendGrid の従量課金は1通あたり0.1円未満であり、「とりあえず送る」が経済的に成立していた。

LINEでは、この前提が完全に反転する。

つまり LINE では「押し出す(push)ほど高くつき、引き込む(pull)ほど安い」。これは通数カウントの規則そのものに現れている。

(出典: LINEヤフー「料金プラン」/ LINE Developers「Messaging APIの料金」)

この非対称性を最大限に使うのが本仕様の設計方針である。

1. 定期的な一斉配信(メルマガのLINE版)は作らない
2. 常設の価値はリッチメニューとLIFFに置く。ここは何度見られてもコストゼロ
3. こちらから送るのは「相手のアクションへの応答(reply)」と「相手が待っている通知(リマインド)」だけ
4. push を使うのは、識別済み友だちに対する個別・少数配信に限る

概算すると、識別済み友だち500人・月2回のセグメント配信(平均対象100人)であれば 月200通。コミュニケーションプラン(月額0円)の無料枠内に収まる。BtoBで友だち数が小さいことは、LINEにおいてはむしろ経済的な優位である。

2.4 中核アイデア③ — ブロックは不可逆。だから「送らない権利」を相手に渡す

メールの配信停止は、こちらのDBで管理する状態である。相手が気を変えれば再開できる。

LINEのブロックは、こちらからは一切解除できない。 ブロックされた友だちには何を送っても届かず(通数もカウントされない)、識別済み友だちであっても回線は永久に失われる。ID連携で積み上げた資産が一瞬で消える。

業界横断のブロック率実測値(ソーシャルPLUS調査、友だち数1,000未満を除外)は次のとおり。

友だち数別では、5,000人未満で約22%、50万人以上で40%超と、規模が大きくなるほどブロック率は上がる。量的に集めるほど質が劣化する構造である。一方、丁寧に運用した事例(東急ストア)は友だち17万人でブロック率11.1%に収まっている。

ブロック理由の第1位は「情報配信の頻度が多すぎるから」26.5%(モビルス調査、655名)である。

設計上の要点: ブロックを「離脱率」として事後に眺めるのではなく、発生前に機能で抑える。 1. 配信頻度をユーザー自身に選ばせる(F-29 の配信設定LIFF)。「全部止める(=ブロック)」しか選択肢がない状態を作らない 2. 頻度上限をシステムで強制する(F-33)。1人あたり週1通、月4通を既定の上限とし、超過する配信は管理画面で送信ボタンが押せない 3. ブロック確率の高い友だちを配信対象から機械的に外す(F-33)。無反応が続く友だちに送り続けることは、通数を捨ててブロックを買う行為である

2.5 3つの考え方のまとめ

この3つはいずれも「LINEをメールの代替として使わない」という一点に帰着する。LINEはメールを置き換えるものではなく、メールが届かない層と、メールでは間に合わない場面を埋める補完チャネルである。

3. LINEプラットフォームの前提知識

本章は仕様ではなく、以降の設計の根拠となるLINE側の制約の整理である。数値はすべて2026年8月19日時点のLINEヤフー公式ドキュメントに基づく。

3.1 料金プラン

追加メッセージ単価(スタンダードのみ・税別)

重要: コミュニケーションプランとライトプランは無料枠を超えると送信できなくなる(追加購入不可)。当社の想定規模ではコミュニケーションプラン(0円)から開始し、識別済み友だちが1,000人を超えた段階でライトプランへ移行する。この判定は F-33 の配信予算ガードが自動で警告する。

3.2 通数のカウント規則

通数 = 送信リクエストの数 × 送信対象の人数

• 吹き出し(メッセージオブジェクト)の数は通数に影響しない。1リクエストで最大5吹き出しまで送れる
• 公式アカウントマネージャーからの配信は最大3吹き出し、Messaging API は最大5メッセージオブジェクト
• ブロック中のユーザー、削除済みアカウントへの配信はカウントされない

カウントされないもの(2.3項再掲): 応答メッセージ、あいさつメッセージ、LINEチャットの送受信、Reply API。

設計への反映: 「1回の配信で5吹き出しまで無料で使える」ため、1通に情報を詰め込む設計が経済的に正しい。テキスト+画像+ボタン+カルーセルを1リクエストにまとめる。

3.3 配信種別

共通の制約

• 1リクエストあたりメッセージオブジェクト最大5つ
• テキストメッセージ最大5,000文字
• replyToken は短時間で失効する。Webhook受信後は即座に応答する設計とする

設計上の判断: セグメント配信は narrowcast ではなく multicast を既定とする。理由は、当社は contacts テーブルに業種・企業規模・アプローチ履歴を既に持っており、LINE側のオーディエンス(性別・年代・OS・エリアしか使えない)より精度が高い絞り込みができるため。narrowcast は最小送信対象の制約(オーディエンスは50件以上)もあり、当社の規模では使いにくい。

3.4 レート制限

チャネル単位 × エンドポイント単位で適用される。超過時は 429 Too Many Requests。トークンバケット方式。

設計上の最重要制約: リッチメニューの一括リンクは 3 req/時。ステータス変化に応じてリッチメニューを切り替える設計(F-28)では、一括APIではなくユーザー単位のリンクAPI(制限緩め)を使い、変更をキューで平準化する必要がある。統計取得系が 60 req/時 であることから、LINE側の統計APIをリアルタイムに叩く設計にはできない。日次バッチで取得し、リアルタイム指標は自前計測(F-34)で持つ。

3.5 Webhook と署名検証

• 主なイベント: message / follow(友だち追加) / unfollow(ブロック) / postback / unsend / join / leave / memberJoined / videoPlayComplete / accountLink
• LINEプラットフォームはチャネルシークレットを鍵とした HMAC-SHA256 で署名し、x-line-signature ヘッダーに設定する
• 検証は生のリクエストボディ文字列に対して行う。パース・整形・デシリアライズを検証前に行ってはならない
• 文字コードは UTF-8 を維持する

設計への反映: Cloudflare Workers 実装では request.clone().text() で生ボディを保持し、crypto.subtle で HMAC-SHA256 を計算して定数時間比較する。署名検証に失敗したリクエストは 401 を返し、本文をログに残さない(G-20)。

3.6 チャネル構成と userId

• userId は プロバイダーごとに異なる値が発行される
• 同一プロバイダー配下であれば、LINEログインチャネルと Messaging APIチャネルで同じ userId が割り当てられる
• 異なるプロバイダーでは同一ユーザーでも値が異なるため、他社と突合できない

設計上の最重要制約: LIFF(LINEログインチャネル)で取得した userId を使って Messaging API で push 配信するには、両チャネルが同一プロバイダー配下でなければならない。プロバイダー設計は後から変更できないため、構築の最初の手順で確定させる(F-25)。

3.7 リッチメニュー

タブ切替はリッチメニューエイリアス + richmenuswitch アクションで実装する。エイリアスIDを固定しておけば、紐づくリッチメニューの実体だけを差し替えられる(アクション定義を変えずに中身を更新できる)。

3.8 LIFF

スコープ

設計への反映: LIFF から取得した userId は必ずIDトークンをサーバー側で検証してから信用する。クライアントが送ってきた userId をそのまま信じる実装は、他人へのなりすまし配信を許すことになる(G-19)。

3.9 LINE公式の標準機能を使わない理由

公式アカウントマネージャーには「ステップ配信」機能があるが、本仕様では自前実装(F-30)とする。

LINE標準の分岐軸(性別・年齢・OS・エリア)はBtoBでは一つも役に立たない。当社が持っている軸で分岐するには自前実装しかない。

4. システム全体像

4.1 機能マップ

4.2 技術構成

v2.0 の技術構成(案A: 部分適用 / 案B: Cloudflare全面移行)いずれでも実装できるよう記述するが、Cloudflareを前提とした場合の推奨構成を以下に示す。

v2.0からの継承: 「生イベントをD1に1件ずつINSERTしない」「配信時にモンテカルロを回さない」という禁止パターンは本書でも有効。加えて 「Webhookの処理を同期で完結させない」 を禁止パターンに追加する(LINEはWebhookのタイムアウトで再送するため、重複処理が起きる)。

4.3 データフロー

[既存チャネル]                 [LINE]                      [自社DB]
メール(F-08) ─┐
フォーム(F-06)─┼→ /r/{tracking_code}
LP(F-13) ─────┘        │
                       ▼
              友だち追加URL(state=tracking_code)
                       │
                       ▼
              LINE: follow イベント ──→ Workers(署名検証)
                                            │
                                            ▼
                                        Queues
                                            │
                       ┌────────────────────┼────────────────────┐
                       ▼                    ▼                    ▼
              line_friends 登録    tracking_code 解決    あいさつメッセージ(無料)
                                       │                        │
                                       ▼                        ▼
                              contact_id / company_id     LIFF(ID連携確認)
                                       │                        │
                                       └──────────┬─────────────┘
                                                  ▼
                                          識別済み友だち
                                                  │
                       ┌──────────────────────────┼──────────────────────────┐
                       ▼                          ▼                          ▼
              リッチメニュー出し分け        シナリオ配信(F-30)         行動計測(F-34)
                  (無料)                    push/multicast              │
                                                  │                     ▼
                                                  └──────────→ F-23 アトリビューション

4.4 LINE広告(友だち追加広告)を採用しない判断根拠

要望としては「LINEを使ったマーケティング」に広告が含まれうるが、本仕様では機能化しない。判断根拠を残す。

CPF 200円 × ブロック考慮 250円で1,000人集めたとして25万円。うち当社のターゲット企業に所属する人は統計的にごく僅かであり、しかも誰なのか分からない(2.2項)。同じ25万円をウェビナー広告(v2.0 F-19)に投じたほうが、実名と企業名が取れる。

再検討条件: 「認証済アカウント取得済み」「識別済み友だちが2,000人を超え、そのうち商談化率が5%以上で安定」の両方を満たした時点で、リターゲティング用途に限り再検討する(16章)。

5. 機能要件 第I部 — 接続・識別基盤(F-25〜F-28)

5.1 F-25 LINEチャネル管理・接続設定

5.1.1 概要

LINE公式アカウント、Messaging APIチャネル、LINEログインチャネル、LIFFアプリの接続情報を一元管理する。プロバイダー設計を誤ると後戻りできないため、本機能は構築の最初に実行する。

5.1.2 プロバイダー・チャネル構成(固定)

プロバイダー: シンオン株式会社                     ← 1つだけ作る。後から変更不可
 ├─ Messaging APIチャネル: シンオン公式アカウント
 │   └─ Webhook URL: https://ma.example.co.jp/line/webhook
 ├─ LINEログインチャネル: シンオン LIFF
 │   ├─ LIFFアプリ: 資料ダウンロード      (Tall)
 │   ├─ LIFFアプリ: ウェビナー申込        (Tall)
 │   ├─ LIFFアプリ: 商談予約              (Full)
 │   ├─ LIFFアプリ: 簡易見積診断          (Full)
 │   ├─ LIFFアプリ: 会社情報の登録/確認   (Compact)
 │   └─ LIFFアプリ: 配信設定              (Compact)
 └─ (将来) LINEミニアプリチャネル

絶対条件: Messaging APIチャネルとLINEログインチャネルは必ず同一プロバイダー配下に作成する。異なるプロバイダーに作ると userId が一致せず、LIFFで識別した相手にpush配信ができない。この失敗は作り直し以外に回復手段がない。

5.1.3 入力

5.1.4 処理仕様

1. シークレットの保存: チャネルシークレット、チャネルアクセストークンは環境設定(F-10)の暗号化ストアに保存する。管理画面では常にマスク表示(****...末尾4桁)し、復号表示は admin ロールのみ・監査ログ必須とする。
2. Webhook URL の検証: 設定後、LINEプラットフォームの検証エンドポイントで疎通確認を行い、結果を画面に表示する。
3. 短期チャネルアクセストークンの自動更新: 有効期限の80%を経過した時点でCronが再発行する。発行上限を超えると既存トークンが無効化されるため、発行は必ず1経路(Cron)に集約し、手動発行を禁止する。
4. 応答設定の整合チェック: 公式アカウントマネージャー側の「あいさつメッセージ」「応答メッセージ」が有効な状態で自前実装も動かすと、二重返信が発生する。設定画面に注意を表示し、どちらで運用するかを明示的に選択させる。本仕様の既定は「公式側の自動応答をすべてOFF、自前実装に一本化」。
5. Webhook URL の単一性: LINEプラットフォームに設定できる Webhook URL は1つのみ。他のLINEツール(Lステップ等)との併用はできないため、既存ツールがある場合は移行計画を先に立てる。

5.1.5 制約

• 応答モード(bot / chat)の排他制約は2022年11月30日に撤廃済みのため、Webhookとチャットは併用できる
• レート制限はチャネル単位で共有される。複数ツールから同一チャネルを叩かない
• チャネルシークレットのローテーションはWebhook署名検証の切り替えを伴うため、無停止では行えない。メンテナンス手順を運用手順書に定義する

5.2 F-26 友だち識別・ID連携

5.2.1 概要

本仕様の中核機能。友だち追加された userId を、自社の contacts.id / companies.id に紐づける。2.2項の「識別済み友だちだけを増やす」を実装で担保する。

5.2.2 識別方式

方式A: tracking_code 経由(推奨・既定)

既存の /r/{tracking_code} リダイレクタ(v1.2 F-09)を拡張し、LINE友だち追加URLへの中継を追加する。

1. メール本文/LP内リンク: https://ma.example.co.jp/r/{tracking_code}?to=line
2. リダイレクタが以下を実行:
   a. tracking_code から contact_id / company_id を解決
   b. 一時トークン link_token を発行(D1に保存、有効期限15分)
   c. LINE友だち追加URL + state に link_token を付与してリダイレクト
      https://line.me/R/ti/p/@xxxxxxx  (state相当はLIFF側で受ける)
3. 友だち追加 → follow イベント受信
4. あいさつメッセージ(無料)で「登録内容の確認」LIFFへ誘導
5. LIFF起動時に link_token を渡し、IDトークン検証済みの userId と結合
6. line_id_links に (userId, contact_id, company_id, 'tracking_code') を登録

技術上の注意: LINEの友だち追加URLには任意のクエリパラメータを安全に引き回す仕組みが公式には用意されていない。したがって follow イベント単体では誰か分からない。本方式では「あいさつメッセージ → LIFF」の1ホップを必ず挟むことで、link_token と userId を確実に結合する。あいさつメッセージは通数無料であるため、このホップにコストは発生しない。

方式B: LIFF先行(ウェビナー申込・資料DL)

申込フォーム自体をLIFFで実装する場合、フォーム送信時点で userId とフォーム入力(会社名・氏名・メール)が同時に手に入る。最も確実な識別方式。

1. LP上の「LINEで申し込む」→ LIFF起動(未友だちなら liff.requestFriendship() で追加を促す)
2. IDトークン検証 → userId 確定
3. フォーム入力 → メールアドレスで contacts を照合(なければ新規作成)
4. line_id_links に (userId, contact_id, company_id, 'liff_form') を登録

方式C: 自己申告(自然流入)

tracking_code も申込情報も無い友だち。あいさつメッセージから「会社情報の登録」LIFFへ誘導し、会社名・氏名・メールを入力してもらう。入力率は低いことを前提とし、未識別のまま3回のリマインドに反応しなければ配信対象から除外する(F-33)。

5.2.3 企業の解決

contact_id が確定すれば company_id は既存のリレーションで解決される。メールアドレスしか無い場合は、v1.2 の企業マスタに対して次の順で照合する。

5.2.4 出力・データ

5.2.5 制約・注意

• 表示名・プロフィール画像は保存しない。LINE User Data Policy により、userId を除くユーザー情報の24時間以上の保存には事前告知が必要であり、友だち情報・グループ情報は24時間以上の保存が禁止されている。表示名は照合の補助にのみ使い、ハッシュ値だけを残す(G-22)
• ブロック(unfollow)されても line_id_links は削除しない。再追加時に同一 userId で戻ってくるため、履歴として保持する。ただし配信対象からは即座に除外する
• userId は当社のプロバイダー配下でのみ有効。外部サービス・広告事業者への提供は行わない(G-23)

5.3 F-27 メッセージ配信エンジン

5.3.1 概要

reply / push / multicast を統一インタフェースで実行し、通数を予算内に収める。送信前に必ずガバナンスチェック(F-33)を通す。

5.3.2 配信要求の構造

5.3.3 処理仕様

1. reply の優先: Webhookイベントに対する応答は必ず reply を使う。replyToken が失効している場合のみ push にフォールバックし、その旨をログに残す(通数が発生するため)。
2. multicast の分割: userId 配列は500件ごとに分割してリクエストする。分割後の各リクエストは Queues に投入し、200 req/秒の制限内で消化する。
3. URLの自動変換: メッセージ本文内のURLは、送信前に /r/{tracking_code} 形式へ書き換える。tracking_code には channel=line、配信理由コード、message_id を含める。これにより F-23 のアトリビューションでLINE経由のクリックが他チャネルと同じ粒度で計測される。
4. 1リクエストへの集約: 通数は吹き出し数に影響されないため、テキスト+画像+ボタンは必ず1リクエストにまとめる。分割送信を検知したらバリデーションエラーとする。
5. べき等性: 配信要求には idempotency_key を必須とし、Queues の再試行で二重送信されないようにする。
6. 失敗時の扱い: 429 はバックオフ後に再試行。400(ブロック済み・存在しないID)は再試行せず line_friends.status を blocked に更新する。

5.3.4 メッセージテンプレート

5.3.5 制約

• 1リクエスト5オブジェクト、テキスト5,000文字を超える定義は保存できない
• broadcast は本エンジンから実行できない(G-17)。全友だち配信が必要な場合は admin が管理画面から二重確認のうえ実行する例外フローとする
• 配信理由コードの無い配信は実行できない

5.4 F-28 リッチメニュー出し分け

5.4.1 概要

リッチメニューは表示もタップも通数無料であり、LINEにおける最大の資産である。相手のステータスに応じて内容を出し分け、「送らずに接点を維持する」を実現する。

5.4.2 メニュー設計

5.4.3 処理仕様

1. ユーザー単位リンクを使う: ステータス変化時に、対象 userId に対してユーザー単位リッチメニューをリンクする。ユーザー単位はデフォルトより優先度が高い。
2. 一括APIを使わない: 一括リンク/リンク解除は 3 req/時 という厳しい制限があるため、大量の切替が必要な場合でも使わない。個別リンクをQueuesで平準化して処理する。
3. エイリアスによるタブ切替: タブは richmenuswitch アクションとリッチメニューエイリアスで実装する。エイリアスIDは menu-{role}-{tab} の命名で固定し、デザイン変更時はエイリアスに紐づく実体だけを差し替える。
4. ステータス変化のトリガー: contacts.status の変更、商談ステータスの変更、最終反応日からの経過日数(日次Cron)で切替を発火する。
5. 切替の遅延を許容する: LINE側の反映には時間がかかる場合がある。切替の完了をユーザー体験の前提にしない(切替直後に「メニューから操作してください」と案内しない)。

5.4.4 制約

• 画像は 2500×1686 または 2500×843、1MB以下、JPG/JPEG/PNG
• タップ領域は最大20、chatBarText は14文字以内
• エイリアスは最大100個。上記5メニュー×2タブ=10個であり十分に余裕がある
• 全エリアを「アクションなし」にはできない

6. 機能要件 第II部 — 体験・シナリオ(F-29〜F-32)

6.1 F-29 LIFFアプリ基盤

6.1.1 概要

LINE内で完結するWebアプリ群。LIFFの利用は通数無料であり、リッチメニューと並んで「送らずに価値を提供する」中核となる。

6.1.2 アプリ一覧

6.1.3 共通処理仕様

1. 初期化: 各ページ遷移で liff.init() を実行する。URLクエリの操作は liff.init() の Promise が resolve した後に行う。
2. 認証: liff.getIDToken() で取得したIDトークンをサーバー側で検証し、userId を確定する。liff.getProfile() の結果をサーバーに送って信用する実装は禁止(G-19)。
3. 未ログイン時: 外部ブラウザで開かれた場合は liff.login() を実行する。LIFFブラウザでは自動ログイン済みのため liff.login() を呼ばない(呼ぶとエラーになる)。
4. 未友だち時: liff.requestFriendship() で友だち追加を促す。追加せずに離脱した場合も、フォーム入力があれば contacts には登録する(メールチャネルでフォローできるため)。
5. 完了後の挙動: 処理完了後は liff.closeWindow() で閉じる。ただし外部ブラウザでは動作保証がないため、閉じられなかった場合の完了画面も用意する。
6. 共有機能: 事例・資料の共有には liff.shareTargetPicker() を使う。ただし送信先・送信人数は取得できないため、共有数をKPIにできない。共有経由の流入は共有時に発行する tracking_code で計測する。

6.1.4 配信設定LIFF(最重要)

2.4項の「送らない権利を相手に渡す」を実装する画面。

設計上の要点: 「停止」を選んだ友だちにも transactional(本人が申し込んだウェビナーのリマインド等)は届ける。ここを一律停止にすると、逆に「申し込んだのに連絡が来ない」という不満が生じる。両者を明確に分離して説明する。

6.1.5 制約

• 1チャネルあたりLIFFアプリは最大30個
• liff.sendMessages() は LIFFブラウザ内でのみ動作する。外部ブラウザ向けの代替導線を必ず用意する
• email スコープは要申請。申請には利用目的を提示する画面のスクリーンショットが必要。申請前提の設計にせず、メールアドレスは自己入力を既定とする
• LIFFブラウザは直近50サービスを保持し、12時間以内の再訪はレジューム、それ以降はリロードされる。状態をブラウザ側にだけ持つ実装は破綻する

6.2 F-30 シナリオ配信(自前ステップ配信)

6.2.1 概要

3.9項の理由により、ステップ配信はLINE標準を使わず自前実装する。LINE・メール・フォームを同一シナリオ内で混在させられることが最大の価値である。

6.2.2 シナリオの構造

シナリオ = 開始条件 + ステップの有向グラフ

ステップの種別:
  - 待機      : 分/時間/日 で指定。絶対時刻指定も可(ウェビナー開始5分前 等)
  - 分岐      : 条件式で経路を分ける
  - 配信      : チャネル(LINE/メール)とテンプレートを指定
  - タグ付与  : contacts にタグを付ける
  - 通知      : 営業担当へSlack/メール通知
  - 終了      : シナリオから離脱

6.2.3 開始条件(トリガー)

6.2.4 分岐条件で使える変数

6.2.5 処理仕様

1. チャネル選択の委譲: 配信ステップは「LINE固定」ではなく「F-32のチャネル選択エンジンに委ねる」を既定とする。相手がLINE識別済みならLINE、そうでなければメールが選ばれる。
2. 配信の直列化: 同一人物が複数シナリオに同時に入ることを許すが、配信は F-33 の頻度上限を必ず通す。上限に達した場合は配信ステップをスキップではなく延期する(既定24時間)。延期が3回続いた場合は破棄しログに残す。
3. 絶対時刻トリガー: 「ウェビナー開始5分前」のような絶対時刻は Cloudflare Workflows または Durable Objects Alarm で実装する。Cron(最短1分)では5分前の精度は担保できるが、Queuesの遅延を見込んで2分前に投入する。
4. 停止条件: 商談化・失注・ブロック・配信停止設定のいずれかが発生した時点で、該当者の全シナリオを即座に停止する。
5. プレビューとテスト送信: 管理者は自分の userId に対してテスト送信できる。テスト送信も通数を消費するため、月間の上限(既定50通)を設ける。

6.2.6 制約

• 1シナリオあたりのステップ数上限 200(実運用は20程度を想定)
• 1人が同時に所属できるシナリオ数の上限 5
• 待機の最短は1分、最長は365日
• 配信ステップのないシナリオ(タグ付与のみ)も許容する

6.3 F-31 チャット一次応答・営業引き継ぎ

6.3.1 概要

友だちからのメッセージに応答する。reply は通数無料であるため、応答は積極的に行ってよい。ここがLINEの費用対効果が最も高い領域である。

6.3.2 応答の階層

6.3.3 処理仕様

1. 受信の即時応答: Webhookは署名検証後すぐに200を返し、処理はQueuesへ流す。ただし replyToken の失効を避けるため、第0層・第1層の応答はWebhookハンドラ内で同期的に返す(処理時間は50ms以内を目標)。
2. AI応答の設計: 第2層は v2.0 の Workers AI / AI Gateway を利用する。応答は社内ナレッジベース(Vectorize)に限定した検索拡張生成とし、ハルシネーションを防ぐ。信頼度が閾値未満の場合は「担当者に確認します」と返して第3層へエスカレーションする。
3. 営業への通知: 第3層へのエスカレーション時、対象 contact_id の担当営業へSlack/メールで通知する。通知には企業名・担当者名・直近の行動履歴・メッセージ本文を含める。
4. 応答時間の管理: 営業時間外は自動でその旨を返し、翌営業日の対応を約束する。応答時間内で15分以上未応答のスレッドは管理画面でアラート表示する。
5. 会話履歴の保持: LINE User Data Policy に基づき、メッセージ本文の保存は業務上必要な期間に限る。既定は90日、その後は要約のみを残して本文を削除する(G-22)。

6.3.4 LINE公式の有料オプションとの関係

LINEヤフーは「AIチャットボット(β)」を提供しており、利用にはチャットProオプション(月額3,000円・税別)が必要。PDF・画像からのQ&A自動生成に対応する。

6.4 F-32 チャネル選択エンジン

6.4.1 概要

同一人物に対して LINE / メール / フォームのどれで連絡するかを決定する。同じ内容を複数チャネルで重複送信しないことが最大の目的。

6.4.2 選択ロジック

入力: contact_id, 配信理由コード, 優先度(transactional/promotional)

1. transactional(相手が待っている連絡)の場合
   → LINE識別済み かつ 未ブロック  → LINE(push)
   → それ以外                      → メール
   ※ 重要度が最高(商談日時変更等)の場合は LINE + メール の併用を許可

2. promotional(こちらからの情報提供)の場合
   → 配信設定が「停止」                        → 送らない
   → 頻度上限に達している(F-33)                → 延期
   → LINE識別済み かつ 直近30日にLINE反応あり  → LINE(multicast)
   → LINE識別済み かつ 直近90日にLINE反応なし  → メール(LINEの通数を温存)
   → LINE未識別                                → メール
   → メール到達不能(バウンス)かつLINE識別済み  → LINE

3. いずれのチャネルも使えない場合
   → フォーム営業(F-06)の候補キューへ(半自動モード)

6.4.3 重複配信の抑止

設計上の要点: LINEを追加したことで「メールも来るしLINEも来る」状態を作ると、両方のチャネルを同時に失う。チャネル選択エンジンは追加機能ではなく、LINE導入の前提条件である。

7. 機能要件 第III部 — 統制・分析(F-33〜F-35)

7.1 F-33 配信ガバナンス・ブロック抑制

7.1.1 概要

通数予算とブロック率を機能で守る。F-27 のすべての配信は本機能のチェックを通過しなければ実行できない。

7.1.2 通数予算ガード

プラン移行の推奨判定

7.1.3 頻度上限

上限に達した配信は延期され、24時間後に再判定される。3回延期された配信は破棄し、その事実を配信ログに残す。

7.1.4 ブロック確率スコアとサプレッション

ブロックは事後に検知しても手遅れである。事前に確率を推定して配信対象から外す。

スコアの入力特徴量

推定方法: 当社の友だち規模では機械学習モデルの学習データが不足するため、初期はルールベースのスコアリングとする。友だち数が1,000を超え、ブロック実績が100件を超えた段階でロジスティック回帰へ移行する。

サプレッション規則

7.1.5 ブロック率の監視

配信直後のブロック急増を検知した場合、同一テンプレートを使う予約配信を自動的に保留し、管理者に確認を求める。

7.2 F-34 LINE行動計測

7.2.1 概要

LINE上の行動を v2.0 F-14 と同一のイベントスキーマで収集し、F-23 のチャネル横断アトリビューションに統合する。

7.2.2 イベント一覧

7.2.3 共通プロパティ(v2.0 F-14 と共通)

{
  "event": "line_link_click",
  "occurred_at": "2026-08-19T10:23:45.123Z",
  "channel": "line",
  "tracking_code": "xxxxxxxxxxxx",
  "company_id": 1234,
  "contact_id": 5678,
  "session_id": "...",
  "properties": { }
}

7.2.4 処理仕様

1. 生イベントは Analytics Engine へ。D1に1件ずつINSERTしない(v2.0の禁止パターン)。
2. 集計は日次。line_daily_stats に日別・配信理由コード別で集約する。
3. LINE公式の統計APIは補助。友だち数・ターゲットリーチ数・ブロック数はLINE側のAPIでしか取れないが、60 req/時の制限があるため日次1回のみ取得する。日中のリアルタイム値は自前計測を正とする。
4. 「開封率」の定義: LINEには厳密な開封の概念がない。LINE側の統計APIが返すインプレッション(吹き出しの表示回数)を開封相当として扱い、メールの開封率とは別指標であることをダッシュボード上に明記する。

7.2.5 アトリビューションへの統合(F-23拡張)

分析上の要点: LINEは「最後の一押し」に現れやすく、ラストタッチ評価だと過大評価される。一方でメールから友だち追加した場合、LINEはメールの下流でしかない。必ずマルチタッチ(F-23の既定モデル)で評価する。

7.3 F-35 LINEコンプライアンス管理

7.3.1 概要

v2.0 F-24 のガードレール管理に、LINE固有のガードレール G-16〜G-27 を追加する。設定ミス・運用ミスが法令違反やアカウント停止に直結する領域を、機能で塞ぐ。

7.3.2 ガードレール一覧

7.3.3 チェックのタイミング

8. ユースケース別シナリオ設計

本章は「何に使うか」を具体化する。2.1項で述べたとおり、LINEが効くのは即時性が価値を持つ場面とすでに接点のある個人に限られる。

8.1 ユースケース一覧と適性

8.2 ウェビナー運用シナリオ(最優先で実装)

v2.0 F-19 のウェビナー機能に、LINEを重ねる。

期待効果: 参加率の改善。ウェビナーの無断欠席は申込者の30〜50%が一般的だが、開始5分前のLINEリマインドはこの層に直接届く(開封の約20%が即時、約80%が当日中)。

8.3 展示会・イベント当日シナリオ

この用途でLINEが強い理由: 名刺交換は「後で連絡が来る」だけだが、LINEはその場で相手の端末に導線が残る。紙の資料を持ち帰らせるより、LIFFで選ばせたほうがDL履歴という行動データも取れる。

8.4 既存顧客サポートシナリオ

設計上の要点: 月次レポートを毎月pushすると年12通×顧客数の通数を消費する。リッチメニューに常設して取りに来てもらうほうが安く、かつメニューのタップが関与度の指標になる。

8.5 採用広報(別アカウント推奨)

営業用の公式アカウントと採用用を分けるべき理由:

• 配信内容が全く異なり、同一アカウントだと双方にとってノイズになる
• 人材業界のブロック率は38.4%と最も高い。営業用アカウントの評価を巻き込みたくない
• 通数予算を分離できる(それぞれコミュニケーションプランで足りる)

ただしアカウントを分けるとプロバイダーが同じでも公式アカウントが別になるため、userId は共通でも友だち関係は別々になる。統合分析は contacts レベルで行う。

9. 計測仕様

9.1 主要KPI

9.2 メールとの比較の注意

ダッシュボードでは開封率をチャネル横断で並べない。CVとCPAだけを横並びにする。

9.3 データ保持

10. 画面仕様(追加)

10.1 画面一覧

10.2 主要画面の補足

S-28 LINEダッシュボード

最上段に置く数字は次の3つのみとする。友だち総数は副次指標として小さく表示する(2.2項)。

┌──────────────┬──────────────┬──────────────┐
│ 識別済み友だち  │  識別率        │  当月通数      │
│    287人      │    82.5%      │  143 / 200    │
│  前月比 +23   │  前月比 +3.1pt │  残 57通       │
└──────────────┴──────────────┴──────────────┘
   友だち総数 348人 / ブロック率 12.4%

S-32 配信作成・予約

送信ボタンを押す前に、以下を必ず画面上で確定表示する。

• 送信対象数と消費通数の見積
• 当月残枠との関係(超過する場合はボタンを押せない)
• 頻度上限に抵触して除外される人数とその内訳
• ブロック確率スコアが高く除外される人数
• ガードレール検証の結果(G-18, G-21, G-24, G-25, G-26)

S-36 チャット

左に会話、右に企業情報・行動履歴を並置する。営業が「誰と話しているか」を分からないまま応答する状態を作らない。未応答15分でアラート。

11. データベース設計(追加)

11.1 ER概要

companies (v1.2) ──1:N── contacts (v1.2)
                              │
                              │ 1:N
                              ▼
                        line_id_links ──N:1── line_friends
                                                   │
                              ┌────────────────────┼────────────────────┐
                              ▼                    ▼                    ▼
                    line_messages         line_richmenu_state    line_preferences
                              │
                              ▼
                    line_message_targets

line_scenarios ──1:N── line_scenario_steps
       │
       └──1:N── line_scenario_enrollments ──N:1── contacts

line_templates ──1:N── line_messages
line_link_tokens
line_daily_stats

11.2 主要テーブル定義

line_friends

索引: status, block_score, last_inbound_at

line_id_links

一意制約: (user_id, is_active) で active は1件のみ

line_preferences

line_messages

line_message_targets

line_richmenu_state

line_scenarios / line_scenario_steps / line_scenario_enrollments

line_daily_stats

11.3 設計方針

• user_id を主キーとし、contacts とは中間テーブル(line_id_links)で疎結合にする。同一人物が複数のLINEアカウントを持つ場合や、連携の誤りを修正する場合に備える
• 本文(body)は NULL 化可能に設計する。パージバッチで本文を消しても行は残る(統計を壊さない)
• billable_count を明示的に持ち、LINE側の請求と突合できるようにする
• v1.2 の方針どおり SQLite / D1 いずれでも動く DDL とし、ORM経由でPostgreSQL移行の余地を残す

12. API設計(追加)

12.1 公開エンドポイント(認証不要)

12.2 管理API(認証必須)

12.3 共通仕様

• 認証・エラー形式は v1.2 / v2.0 に準拠
• POST /api/line/messages は Idempotency-Key ヘッダー必須
• estimate は副作用を持たない。UI は送信ボタンの活性判定にこれを使う

12.4 定期実行(Cron)

13. 非機能要件

14. 法令・コンプライアンス

14.1 特定電子メール法は適用されない

LINE公式アカウントのメッセージ配信は、特定電子メール法の適用対象外である。

同法の「電子メール」は総務省令で定める通信方式に限定されており、その方式は次の2つである。

1. SMTP方式(Simple Mail Transfer Protocol を用いる通信方式 = いわゆるEメール)
2. 電話番号方式(携帯端末に電話番号を宛先として情報を伝達する方式 = SMS等)

LINEのメッセージはいずれにも該当しない。

ただしこれは「何を送ってもよい」という意味ではない。 適用されるのは以下の3層である。

本仕様の方針: 法適用がなくても、オプトイン取得の記録(G-16)、ブロック以外の配信停止導線(G-21)、送信者の明示を特電法と同水準で実装する。ブロックしか停止手段がない設計は、そのままブロック率を押し上げる。

14.2 LINE公式アカウントガイドライン

禁止業種・禁止コンテンツのうち、当社に関係しうるものを抜粋する。

14.3 個人情報保護法とLINE User Data Policy

userId の位置づけ

• userId 単体 → 個人関連情報(個人情報保護委員会の Cookie 等の端末識別子に関する整理に準じる)
• contact_id と紐づけた時点 → 個人情報(容易照合性が成立する)

本仕様では ID連携を前提としているため、userId は最初から個人情報として扱う。プライバシーポリシーに以下を明記する。

• LINEの userId を取得すること
• 取得した userId を自社の顧客情報と紐づけること
• 利用目的(サービスの案内、問い合わせ対応、利用状況の分析)
• 委託の有無と委託先の管理

LINE User Data Policy による追加制約(法令より厳しい)

14.4 令和8年改正個人情報保護法への備え

2026年7月17日に公布された改正個人情報保護法は、公布から2年を超えない範囲内で施行される(施行日は政令で確定。要確認)。LINE活用に直結する改正点は次のとおり。

14.5 外部送信規律(電気通信事業法27条の12)

• 自社の商品・サービスのみを紹介・販売するサイトは原則として対象外。当社のコーポレートサイト・LPは該当しない
• ただし、ユーザー間チャット、口コミ投稿、マーケットプレイス等の機能を持たせると対象になりうる
• LINE Tag 等の計測タグを自社サイトに設置する場合、外部送信規律の直接適用がなくても、取得するCookie ID等は個人関連情報に該当しうるため、外部送信ポリシーページの公表とオプトアウト導線の用意を標準対応とする(G-27)

14.6 景品表示法・特定商取引法

15. 段階導入計画

v2.0 の段階導入(フェーズ0〜4)とは独立に進められる。ただし F-26 の識別は v1.2 F-09 の tracking_code 基盤に依存するため、それが稼働していることが前提。

フェーズL0 — 接続と識別(2〜3週間)

完了条件: 社内メンバー10名で、メール経由の友だち追加が100%識別されること。

フェーズL1 — 常設窓口(2〜3週間)

完了条件: 1通も課金配信をせずに、リッチメニュー経由の資料DLが発生すること。このフェーズの成果は通数ゼロで得られる。

フェーズL2 — 配信とシナリオ(3〜4週間)

完了条件: ウェビナー1回を LINE リマインド付きで実施し、参加率が従来比で改善すること。

フェーズL3 — 計測統合とAI応答(2〜3週間)

完了条件: LINE起点の商談化がアトリビューション上で1件以上按分されること。

フェーズL4 — 拡張(必要になったら)

• 「ウェビナー申込」「商談予約」「簡易見積診断」LIFF の実装
• 既存顧客サポートシナリオ(8.4項)
• 採用広報用の別アカウント(8.5項)
• 認証済アカウントの申請、LINEミニアプリ化の検討

15.1 各フェーズの判断基準

重要: フェーズL1(通数ゼロ)で価値が出ないなら、配信を増やしても価値は出ない。「配信すれば効果が出る」という順序で考えない。

16. 今後の検討事項

17. 出典

LINEヤフー公式 — 料金・プラン

• LINE公式アカウント 料金プラン — https://www.lycbiz.com/jp/service/line-official-account/plan/
• Messaging APIの料金 | LINE Developers — https://developers.line.biz/ja/docs/messaging-api/pricing/
• 今さら聞けない！ Messaging APIの通数カウント方法(2026/5/28) — https://developers.line.biz/ja/tips/2026/05/28/how-to-count-messages/
• LINE公式アカウント 料金プラン改定のお知らせ(2023/6/1) — https://www.lycbiz.com/jp/news/line-official-account/20230601/

LINEヤフー公式 — Messaging API

• Messaging APIの概要 — https://developers.line.biz/ja/docs/messaging-api/overview/
• メッセージを送信する — https://developers.line.biz/ja/docs/messaging-api/sending-messages/
• Messaging APIリファレンス(レート制限を含む) — https://developers.line.biz/ja/reference/messaging-api/
• Messaging API開発ガイドライン — https://developers.line.biz/ja/docs/messaging-api/development-guidelines/
• ボットを作成する — https://developers.line.biz/ja/docs/messaging-api/building-bot/
• line/line-openapi(LINE公式 OpenAPI定義) — https://github.com/line/line-openapi
• 複数のツールからMessaging APIを利用する際に確認したいこと(2026/7/23) — https://developers.line.biz/ja/tips/2026/07/23/using-multiple-api-tools/

LINEヤフー公式 — Webhook・リッチメニュー

• メッセージ(Webhook)を受信する — https://developers.line.biz/ja/docs/messaging-api/receiving-messages/
• Webhookの署名を検証する — https://developers.line.biz/ja/docs/messaging-api/verify-webhook-signature/
• LINE公式アカウントでWebhookとチャットが併用できるようになりました(2022/12/1) — https://developers.line.biz/ja/news/2022/12/01/use-both-chats-and-webhooks/
• リッチメニューの概要 — https://developers.line.biz/ja/docs/messaging-api/rich-menus-overview/
• リッチメニューでタブ切り替えを行う — https://developers.line.biz/ja/docs/messaging-api/switch-rich-menus/
• ユーザー単位のリッチメニューを使う — https://developers.line.biz/ja/docs/messaging-api/use-per-user-rich-menus/
• リッチメニュー マニュアル — https://www.lycbiz.com/jp/manual/OfficialAccountManager/rich-menus/

LINEヤフー公式 — LIFF・ミニアプリ

• LIFFの概要 — https://developers.line.biz/ja/docs/liff/overview/
• LIFF APIリファレンス — https://developers.line.biz/ja/reference/liff/
• LIFFアプリを登録する — https://developers.line.biz/ja/docs/liff/registering-liff-apps/
• LIFF リリースノート — https://developers.line.biz/ja/docs/liff/release-notes/
• LINEミニアプリとは — https://developers.line.biz/ja/docs/line-mini-app/discover/introduction/
• 審査を依頼する(ミニアプリ) — https://developers.line.biz/ja/docs/line-mini-app/submit/submission-guide/
• アプリ内課金の概要 — https://developers.line.biz/ja/docs/line-mini-app/in-app-purchase/overview/

LINEヤフー公式 — 識別・オーディエンス・運用

• ユーザーIDを取得する — https://developers.line.biz/ja/docs/messaging-api/getting-user-ids/
• LINEログインを組み込む — https://developers.line.biz/ja/docs/line-login/integrate-line-login/
• オーディエンスを使う — https://developers.line.biz/ja/docs/messaging-api/using-audience/
• ステップ配信 マニュアル — https://www.lycbiz.com/jp/manual/OfficialAccountManager/step-message/
• 応答設定 マニュアル — https://www.lycbiz.com/jp/manual/OfficialAccountManager/account-settings_response/
• あいさつメッセージを設定する マニュアル — https://www.lycbiz.com/jp/manual/OfficialAccountManager/greeting-message/
• 友だち追加ガイド — https://www.lycbiz.com/jp/manual/OfficialAccountManager/gain-friends/
• 友だち追加広告・LINE広告(友だち追加) — https://www.lycbiz.com/jp/service/line-official-account/cpf/
• 「AIチャットボット(β)」を有料オプションに追加(2025/11/13) — https://www.lycbiz.com/jp/news/line-official-account/20251113/

LINEヤフー公式 — 規約・事例

• LINE公式アカウントガイドライン — https://terms2.line.me/official_account_guideline_jp
• LINE公式アカウント 利用規約 — https://terms2.line.me/official_account_terms_jp?lang=ja
• LINE User Data Policy — https://terms2.line.me/LINE_Developers_user_data_policy?lang=ja
• 配信コンテンツに関する禁止事項 — https://www.lycbiz.com/jp/column/line-official-account/guideline/20240829/
• 【事例】東急ストア — https://www.lycbiz.com/jp/case-study/line-official-account/tokyu/
• 【事例】第一生命 — https://www.lycbiz.com/jp/case-study/line-official-account/daiichiseimei/
• メッセージ配信機能のメリット・効果(開封タイミング) — https://www.lycbiz.com/jp/column/line-official-account/technique/20180426-02/

日本の法令・官公庁

• 個人情報保護委員会｜令和8年 改正個人情報保護法について — https://www.ppc.go.jp/personalinfo/legal/r8kaiseihogohou/
• 個人情報保護委員会｜改正法の公布について(令和8年7月17日) — https://www.ppc.go.jp/news/press/2026/260717/
• 個人情報保護委員会｜Cookie等の端末識別子は個人関連情報に該当しますか — https://www.ppc.go.jp/all_faq_index/faq1-q8-1/
• 個人情報保護委員会｜「容易に照合することができ」に該当する事例 — https://www.ppc.go.jp/all_faq_index/faq1-q1-19/
• 総務省｜外部送信規律 法令・ガイドライン — https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu_00001.html
• 総務省｜外部送信規律FAQ — https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu_00002.html
• 消費者庁｜特定電子メール法 — https://www.caa.go.jp/policies/policy/consumer_transaction/specifed_email
• 消費者庁｜通信販売(特定商取引法ガイド) — https://www.no-trouble.caa.go.jp/what/mailorder/
• 消費者庁｜ステルスマーケティングは景品表示法違反となります — https://www.caa.go.jp/policies/policy/representation/fair_labeling/stealth_marketing/

ベンダー・調査(公式一次情報ではない)

• 株式会社ソーシャルPLUS｜LINE公式アカウントのブロック率調査 — https://blog.socialplus.jp/knowledge/line-block-rate/
• Ligla｜LINE配信頻度の目安 — https://ligla.jp/blog/delivery/frequency/
• L Message｜LINE友だち追加広告(CPF) — https://lme.jp/media/line/friend-ads/
• SFA JOURNAL｜LINE公式アカウントでBtoB集客を成功させる方法 — https://next-sfa.jp/journal/line-marketing/customer-acquisition/

数値の取り扱いについて

• 料金・API仕様・上限値は LINEヤフー公式 に基づく(2026年8月19日時点)
• ブロック率・配信頻度・CPF相場は ベンダー調査 であり、母数・調査手法が開示されていないものを含む。本書では傾向の把握にのみ用い、目標値の設定には当社の実測値を優先する
• BtoB専用の公開ベンチマーク(開封率・CPF・ブロック率)は存在しない。本書に記載した数値はすべてBtoC由来であり、当社の実績で置き換えていく前提とする

改訂履歴