第9章 LINE 運用を自動化する

9.1 LINE 公式アカウントは「もう一度来てもらう」道具

LINE 公式アカウントは、一度つながった人にもう一度来てもらうための道具です。新しい人に見つけてもらう役目は動画・検索・広告が持ち、LINE はそのあとを受け持ちます。届くのは友だちになった人だけ。そのかわり、送ったメッセージは相手のスマートフォンの通知に出ます。投稿を見に来てもらう SNS とは、読まれる確率がまるで違います。

裏返すと、やりすぎたときの損失も大きい。SNS ならフォローを外されて終わりですが、LINE ではブロックされ、二度と届きません。配信はいつでも減らせても、ブロックした人は戻ってこない。だから LINE 運用の自動化は「たくさん送る」ではなく、「送る相手を間違えない」方向に効かせます。

店舗型ビジネスでの基本の順番は、動画や SNS で知ってもらい、LINE で再来店・予約につなげる、です。LINE 単体では集客になりません。友だちが増える入口を先に作らないと、送る相手がいないまま設計だけが立派になっていきます。なお「LINE 広告（LINEヤフー広告）」は新しい人に広告を出す別のサービスで、第 5 章「広告運用を自動化する」の範囲です。この章では扱いません。

追う数字は 4 つ。上から下へ、段階的に減っていきます。最後の来店・予約が CV（コンバージョン。成果として数える出来事）です。

友だち数だけを見ないでください。数だけを追うと、来る見込みのない人ばかり集まってブロック率が上がり、配信が届く相手はむしろ減っていきます。純増とブロックは必ず並べて見る。これが最初の約束です。

9.2 オントロジー: 友だち追加を起点にすべてが繋がる

第 2 章「Agent/Skill/MCP/オントロジー入門」で描いたオントロジー（業務に登場するモノと関係を描いた図）を、LINE 運用に当てはめます。姉妹記事の「メッセージ配信」の図を、実装の粒度まで下ろしたものです。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
  SRC["流入経路<br/>key: 経路URL（広告 / 店頭QR / LP / SNS）"] -->|"経由して追加される"| FR["友だち<br/>key: ユーザーID<br/>状態: 有効 / ブロック"]
  FR -->|"持つ"| TAG["タグ・友だち情報<br/>ステージ（排他） / 行動履歴（非排他）"]
  TAG -->|"条件になる"| SEG["セグメント<br/>= タグの条件式"]
  SEG -->|"宛先になる"| MSG["配信<br/>一斉 / ステップ / 出し分け"]
  MSG -->|"反応を生む"| EV["反応<br/>key: 配信 + ユーザーID + 種別"]
  FR -->|"起こす"| EV
  EV -->|"タグを更新する"| TAG
  EV -->|"至る"| CV["CV<br/>key: 予約ID / 注文ID"]
  CV -->|"突き合わせる"| CRM["顧客<br/>顧客DB / 売上の正本"]

箱に入れるのは名詞だけです。「追加する」「送る」といった行為は矢印の名前にし、記録が残るものだけを名詞のエンティティに立てます（「配信する」ではなく「配信」、「反応する」ではなく「反応」）。ブロックはエンティティではなく友だちの状態で、広告の最適化に CV を返す経路は手順の図なので 9.7 節で別に描きます。

一意キーはユーザー ID です。LINE 側が払い出す識別子で、こちらでは振り直せません。運用ツールはこれとは別に自前の内部 ID も持ち、API はどちらでも友だちを指定できます。どちらを正本にするかは先に決めておきます。両方が混ざった表は突合のたびに変換が要り、変換を忘れた行は、エラーも出ないまま値が食い違います。

登録の瞬間に「どこから来たか」を焼き付けます。流入経路ごとに別の追加 URL を発行し、通過した人に経路名のタグが自動で付くようにしておく。後から遡れない情報なので、ここを取り逃すと経路別の効果は永久に分かりません。広告の CV が「友だち追加」である案件では、この 1 手が 9.7 節の計測の土台になります。

タグには 2 種類あります。排他的な「ステージ」（新規 → 既存 → 休眠。1 人 1 つ）と、非排他の「行動履歴」（クーポン利用、LP 閲覧。何個でも付く。LP はランディングページ、広告の受け皿ページのこと）です。設計の時点でどちらの軸かを決めます。排他の軸で 2 つ付いた人が出たら、それは運用が壊れている印です。数えて報告する対象であって、断りなく足す対象ではありません。

ブロックした人は友だち総数から差し引きます。友だち総数はブロックした人を含む数で、配信が届く相手は「有効友だち = 総数 − ブロック」。総数しか出さないダッシュボードでは、ブロックが増えても数字が減らないので、誰も気づけません。

9.3 道具の全体像: 公式 API と運用ツールの API

LINE 運用に関わる道具は 3 層に分かれます。どの層で何ができるかを先に押さえておくと、あとの設計で迷いません。

公式の LINE Messaging API は、自前でボットを作るときの層です。運用ツールを使う案件では、こちらの設定（チャネルやアクセストークン）を触る必要がありません。ツール自身の API キー 1 つで繋がります。

Liny と Lステップは同じ提供元の 2 ブランドで、API は 1 本です。 ベース URL も API リファレンスも、トークンを発行する管理画面のタブ名も共通。だから連携は 1 つで済み、コードに分岐を作りません。どちらの契約かをこちらから判定する手段は無く、判定する必要もありません。違うのはマニュアルの置き場だけで、記事番号は共通、ドメインだけが分かれています（Liny ／ Lステップ）。利用者に見せる文面では必ず両方を名乗り、マニュアルへのリンクも 2 本並べます。片方だけ書くと、もう片方の契約者には「自分の連携は無い」と読めてしまいます。

対応するのは「標準 API」だけです。公開されている API 定義に載っている範囲がそれで、載っていないものは実装しません。「たぶん同じ形だろう」と足した口は、契約によっては 403 が返るだけの口になります。API の利用条件はツール側の契約にあり、こちらには判定材料がありません。条件をコードにもドキュメントにも書き写さず、マニュアルへ送るだけにしておく。写した瞬間に、古い条件がそのまま残り続けます。

最も大事な境界。運用ツールの公開 API に、メッセージを「送る」口はありません。 一斉配信もシナリオ配信も管理画面の機能です。API で自動化できるのは、友だち・タグ・属性の読み書きと、その分析まで。この境界を最初に書く理由は 2 つあります。利用者の期待値（「AI が配信までやる」と思われない）と、設計の制限（送る口を別経路で足さない）です。足すなら、取り消せない外部反映として設計をやり直すことになります。「送れない」ではなく「そもそも API に無い」と伝えます。

9.4 連携を作る: 鍵・ページング・レートリミット・エラー

鍵は案件ごと、サーバー側に閉じる

アクセストークンは運用ツールの管理画面で発行します。表示された文字列そのものが鍵で、メールやチャットに貼って共有した時点で漏れています。案件ごとに登録し、サーバー側で保存します。鍵は LINE 公式アカウント 1 つぶん。複数のアカウントを運用している人が別のアカウントの鍵を貼ると、疎通確認は通ったうえで、別のアカウントの数字が出ます。気づく手段が名前の確認しか無いので、連携後は必ずアカウント名を画面に出します。

この鍵は 1 本で読み取りと書き込みの両方が通ります。タグの付与、対応マーク（対応状況の印。運用ツールの用語）の変更、タグの一括操作まで含みます。だから AI の環境変数に置きません。AI が触れる口は MCP ツール（第 2 章）だけにし、鍵はサーバー側に閉じます。書き込みのツールは、9.6 節のとおりパーミッション（ツールを確認なしで使わせるか、呼び出すたびに人に確認させるかの設定。第 2 章）で確認の対象にします。鍵が環境にあると、確認を通らない経路が 1 本増えてしまいます。

「鍵がある」と「実際に読める」は別です。疎通確認は友だち一覧を 1 件だけ読み、読めたかどうかで判定します。トークンの寿命や更新の仕組みは、この API の定義に書かれていません。失効を推測せず、読めなくなったら「発行し直して貼り替える」と案内します。

ページングはカーソル型で、総件数は返らない

一覧 API はカーソル型です。応答に次ページの印（next_cursor）が入り、それを次の呼び出しに渡して進みます。印が空になったら終端。1 回の取得件数は既定 50、最大 1,000 ですが、大きくして 1 回で済ませようとするより、分割して辿るほうが安定します。

ここで数字が嘘になる仕様が 1 つあります。総件数のフィールドがありません。 「全 N 件中 M 件」は出せず、辿り切って初めて総数を言えます。途中で打ち切ったなら「N 人以上」と書く。ダッシュボードは走査に上限を置き、上限に当たったら「最初の N 件までの集計」と画面に明記します。ゼロで埋めるのも、全件と称するのも嘘になります。もう 1 つ、フォルダの一覧のようにカーソルを持たない口が混ざっています。共通のページャで舐めようとすると、そこで落ちます。

レートリミットは 2 段。判定は本文で行う

上限は 2 段あります。秒間（アカウントごとに 10 リクエスト）と、月間（契約プランごと）です。どちらも 429 で返りますが、次の一手が正反対。秒間超過は数秒待てば戻り、月間超過は翌月まで戻りません。この 2 つを同じ「混み合っています」に畳むと、利用者は待つべきかプランを見直すべきかを決められません。

種別の見分けは応答本文のメッセージで行います。Retry-After ヘッダは月間超過のときだけ付き、値は翌月のリセット時刻ですが、ヘッダの有無で種別を判定しないよう公式が明記しています。

def call(req, tries=3):
    for i in range(tries):
        res = send(req)
        if res.status != 429:
            return res
        if "monthly limit" in res.message:
            raise MonthlyLimit(res.retry_after)   # 待たない。翌月まで戻らない
        sleep(0.5 * (2 ** i))                     # 秒間超過だけ短く待って再試行
    raise RateLimited()

def scan(path, max_pages=20):
    cursor, rows = None, []
    for _ in range(max_pages):
        page = call(get(path, cursor=cursor, limit=200))
        rows += page.data
        cursor = page.next_cursor
        if not cursor:
            return rows, False          # 辿り切った
    return rows, True                   # 打ち切り。「N 件以上」と表示する

全件走査にはページ数の上限を置きます。上限が無いと、友だちの多い 1 案件が月間上限を独占し、同じサーバーに乗る他の案件まで翌月まで読めなくなります。

エラーは「未取得」＋対処法に翻訳する

HTTP のステータスだけで「連携が切れた」と決めません。404 は宛先の ID が無いだけ、403 は権限か契約、401 だけが鍵の問題です。画面に出す対処法もそれぞれ分けます。対処法の文面に、自分たちのコードのファイルパスや内部の名前を混ぜてはいけません。その文面はそのまま利用者の画面に出ます。

API の癖は他にもあります。更新が PUT や PATCH ではなく「POST に ID を付けた形」の API があります。HTTP メソッドから作成か更新かを推し量らず、公式の定義どおりに書きます。「未指定」と「null」で意味が違う項目もあります（フォルダを未指定なら現状維持、null なら未分類へ移動）。両方を「値が無い」に畳むと、名前を変えただけのつもりがフォルダから外れます。

9.5 読み取りで出すもの、出さないもの

出すのは 6 つの数字と 2 つの内訳

ダッシュボードに出すのは、友だち総数、有効友だち、ブロック数、期間内の新規友だち、受信メッセージ数、送信メッセージ数の 6 つと、日ごとの推移（新規友だち・メッセージ）、内訳（タグ別・対応マーク別の友だち数）です。9.1 節の 4 つのうち純増とブロック率はここで読め、配信のクリックと来店は管理画面の分析と予約システムから取ります。

集計 API はありません。「タグ別の人数」も「月別の新規数」も、一覧を辿って自分で数えます。数えるときの約束は 5 つ。

1. 日次集計のタイムゾーンを固定する。 API が返す日時を日付に丸めるところで、地域時刻に固定します。UTC（協定世界時）で切ると、日本時間の朝 9 時までの友だち追加が前日に載ります。
2. 内訳には上限を明記する。 一緒に返せるタグの数に上限（100）があるので、タグ別内訳は「最初の 100 タグまで」と書いて出します。
3. メッセージの向きを足さない。 受信・送信・システム（管理画面にだけ出る記録）の 3 つは数えているものが違います。
4. 「通過」と「追加成立」を混同しない。 流入経路の記録は通過ごとに 1 行です。同じ人が 2 回通れば 2 行なので、人数はユーザー ID で重複を除いてから数えます。
5. 他媒体と合算しない。 LINE の「友だち」は、Instagram のフォロワーとも TikTok の視聴者とも数えているものが違います。

よく聞かれる問いと数え方

現場で繰り返し聞かれる問いは、ほぼ決まっています。集計 API が無いので、どの問いも「どの一覧を、どの条件で取り、何を数えるか」に置き換えてから答えます。

「返事をしていない人」のように意味が 1 つに決まらない問いは、依頼文の側で定義します。次は温泉旅館で、まだ確認していない問い合わせを一覧にする依頼です。

温泉旅館の LINE 公式アカウント（Lステップ を利用）で、お客さんから届いたのに
店側がまだ確認していないメッセージを一覧にしてください。

- 期間: 直近 14 日間（今日を含む。日本時間）
- 対象: お客さんから届いたメッセージだけ。こちらから送ったものとシステムの記録は除く
- 1 人から複数届いている場合は 1 行にまとめ、件数と最初に届いた日時を書く
- 並び順: 最初に届いた日時が古い順
- 本文は先頭 40 文字まで。電話番号とメールアドレスは伏せる
- 一覧を辿り切れなかったら、その旨と「N 件以上」を先頭に書く
- 返信の文面は作らない。タグや対応マークも変えない

出力: 表（表示名 / 件数 / 最初に届いた日時 / 本文の先頭）と、件数の合計。

「未返信の人を出して」とだけ頼むと、「未返信」が 3 通りに読めます。店がまだ見ていない、見たが返していない、店の配信にお客さんが返していない、のどれかです。エージェントはどれか 1 つを選んで数えますが、どれを選んだかが報告に書かれるとは限りません。伏せる指示が無ければ、電話番号の入った本文もそのまま一覧に並びます。

出さないものを先に決める

「増やさないもの」を決めておくと、連携は長持ちします。

• 流入経路の一覧。 取れるのは「この友だちが通った経路」と「この経路を通った友だち」の 2 方向だけで、経路そのものの一覧を返す口がありません。経路ごとの人数を出すには、経路 ID を人が渡すか、友だちを全件走査するしかない。全件走査に切り替えると、1 案件で月間上限を使い切ります。常設の画面には載せず、経路 ID を指定して 1 件ずつ引く口だけを用意します。
• 開封率・クリック率。 公開 API に配信の実績を返す口がありません。取れない指標を 0% と書かず、「管理画面の分析で確認」と書きます。
• 配信。 9.3 節のとおり口が無く、別経路で足しません。
• 案件をまたぐ鍵の共有。 鍵は公式アカウント 1 つぶんで、案件の行が持ちます。

9.6 書き込みはパーミッションで確認する

何が書き込みか、どこで線を引くか

API で書けるのは、友だちへのタグの付与と解除、1 つのタグへの一括付与と一括解除（1 回の件数に上限を置く）、対応マークの設定、タグとタグフォルダの作成・更新、友だち情報の入れ物の作成、共通情報（アカウント全体で使い回す値。営業時間や特典コード）の更新です。どれも運用ツール側の状態を書き換える外部反映なので、書き込みのツールはすべて確認の対象（Claude Code の settings.json では ask、claude.ai のコネクタでは「承認が必要」）にします。確認の対象にしたツールは、エージェントが呼んだその場で、会話を操作している人に確認画面が出て、許可されるまで実行されません。

線を引く基準は「取り消せるか」です。一括付与を間違えても自動では戻りません。同じ範囲に一括解除のツールをもう一度呼ぶことになり、確認画面をもう 1 回通します。タグには削除の口がありません。作りすぎたタグは管理画面での手作業になり、それも消せないので「終了」の接頭辞で畳むことになります。共通情報は配信文面に差し込まれる値なので、変えると次の配信から友だちの目に触れます。取り消せないものほど、確認画面で「何を、誰に、何件」が読める形の引数で呼びます。

確認画面は、ツールを呼ぶたびに 1 回出ます。10 個のタグを作るなら、確認画面も 10 回です。確認画面で許可した呼び出しは、表示された内容のまま 1 回だけ実行されます。だから、先に設計を合意してから呼びます。合意なしに呼ぶと、確認する人が全体像を持たないまま 10 回許可することになり、許可した本人も何を許したのか説明できません。Claude Code の確認画面にある「今後は確認しない」も、書き込みのツールでは選びません。選ぶと許可のルールが保存され、そのツールが ask に入っていなければ、以後は確認なしで実行されます。

実行前に必ず行うこと

1. 既存を見る。 タグ・フォルダ・友だち情報・対応マークの一覧を先に取ります。同名タグを弾く保証は無く、二重に作るとどちらに人が入っているか後から分かりません。
2. 予定を文章で見せて合意を取る。 何を、何件、誰に。5 件以上まとめて作る前には、作成予定の一覧を出します。
3. 命名規則を確認する。 既存タグの付け方が優先。無ければ「軸-値-条件」の形で、基準を名前に入れます（「休眠」ではなく「休眠-90日以上」）。日付は年月で書き、季節語を単独で使いません。1 年後に読めなくなります。
4. 対象人数を数えて伝える。 「取得 → 判定 → 件数と一覧を出す」までを、書き込みのツールを呼ぶ前の dry-run（実際には書かない試走）として扱います。この API に検証だけを行うオプションは無いので、dry-run はこちら側で作ります。

確認画面に出るのは、ツールの名前と引数だけです（第 2 章）。タグの ID と友だちのユーザー ID だけを受け取るツールでは、確認する人は何を許可するのか判断できません。タグを一括で付けるツールには、ID に加えて、人が読める値も引数として受け取らせます。引数は、例えば次のようになります（ユーザー ID の一覧は先頭の 3 件だけ示しています）。

{
  "tag_id": 1203,
  "tag_name": "ライフサイクル-休眠-90日以上",
  "condition": "最終受信が 90 日以上前、かつブロックされていない",
  "target_count": 84,
  "user_ids": ["U1a…", "U2b…", "U3c…"]
}

ツールの側では、書き込む前に 2 つを確かめます。tag_id と tag_name が同じタグを指しているか、target_count と user_ids の件数が一致しているかです。食い違っていたら、書き込まずにエラーを返します。確認画面で読んだタグ名や人数と、実際に書き込む内容がずれないようにするためです。付けたタグを取り消すには、同じ 84 人への一括解除のツールを呼び、確認画面をもう 1 回通します。

タグと友だち情報の設計規則

書き込みのツールを呼ぶ前に、何を作るかを固めます。タグには削除の口が無く、名前の変更も 1 件ずつ確認画面を通ります。作ってから直すより、作る前に揃えるほうが手間がかかりません。

タグは「軸」ごとにフォルダを分ける

軸とは、ライフサイクル・カスタマージャーニー・キャンペーン・流入経路のような、分け方の単位です。

• 1 つの軸を 1 つのフォルダにします。軸をまたぐタグを同じフォルダに混ぜません。
• 新しい軸を足す前に、既存の軸で表せないかを確かめます。タグが増えるほど、管理画面の一覧から目当てのものを探せなくなります。
• 人数を数えてから粒度を決めます。10 人しか入らないセグメントを 6 つ作っても、配信の打ち手にはなりません。取得、数える、粒度を決める、の順です。
• 名前は、上の「実行前に必ず行うこと」で決めた「軸-値-条件」に加えて、次の 4 つを守ります。半角と全角を混ぜない（検索で見つからず、見た目では気づけない）。記号はハイフン程度に絞り、絵文字や空白を入れない。フォルダ名をタグ名の先頭にも書く（名前だけが並ぶ画面がある）。終わったキャンペーンのタグは「終了」を先頭に付けて改名する（消せないので、消したことにしない）。

友だち情報は「入れ物」だけを作る

友だち情報は、友だちごとのカスタム項目です。項目の型は、1 行や複数行のテキスト、選択肢、日付、日時、画像、PDF などから選びます。

• 選択肢の候補が 5 件以下に収まるなら、選択肢型にします。自由入力にすると「カット」と「ｶｯﾄ」のような表記の揺れが生まれ、後から絞り込めません。
• API で作れるのは項目という入れ物までで、各友だちの値は API から書き換えられません。値が入るのは、回答フォーム、経路やボタンに紐づけたアクション設定、管理画面での手入力です。項目を作ったのに値が空のままなのは、この仕様のためです。設計書には「誰が、いつ、どの経路で値を入れるか」を必ず書きます。
• 名前は、画面に出る質問文のつもりで付けます（「最終アクション」より「最後に来店した日」）。数値の項目には単位を入れます（「累計の利用額（円）」）。値は文字列で入るので、単位が無いと桁の読み方が人によって変わります。
• 選択肢の言葉は名詞で揃えます。「はい / いいえ」と「有 / 無」を項目ごとに混ぜません。
• フォルダは、値の入り方で分けます（基本属性、利用履歴、アンケート回答）。誰がいつ埋めるかが同じ項目を 1 つにまとめます。

エージェントに設計を頼むと、次のような設計書が返ってくる形にしておくと、書き込みのツールを呼ぶ前に人が読んで判断できます。

# 駅前の美容室: タグと友だち情報の設計書（案）
tag_folders:
  - folder: ライフサイクル
    exclusive: true              # 1 人 1 つ。進めるときは前のタグを外す
    tags:
      - name: ライフサイクル-新規-30日以内
        rule: 友だち追加から 30 日以内
      - name: ライフサイクル-休眠-90日以上
        rule: 最後の受信から 90 日以上。受信が無ければ追加日で判定
    expected_count: 未集計         # 数えてから確定する
  - folder: 流入経路
    exclusive: false             # 経路のアクション設定で自動付与
    tags:
      - name: 流入経路-LP-ヒーロー
      - name: 流入経路-店頭QR
friend_info:
  - folder: 基本属性
    fields:
      - name: 希望するメニュー
        type: 選択肢
        options: [カット, カラー, パーマ, トリートメント]
        filled_by: 友だち追加の直後に送る回答フォーム
      - name: 最後に来店した日
        type: 日付
        filled_by: 来店時にスタッフが管理画面で入力
confirmations: フォルダ 3 + タグ 4 + 項目 2 = 9 回  # 確認画面が出る回数

設計書に入れた 3 つの列は、どれも後で困る場面を先回りして潰すためのものです。expected_count にわざわざ「未集計」と書かせるのは、人数を数える前の案が確定版に見えてしまうからです。filled_by があれば、値が空のまま残る項目に設計の段階で気づけます。最後の行に確認画面が出る回数を置いたのは、確認する人に全体の量を知ったうえで 1 件目を許可してもらうためです。

パーミッションの設定で外してはいけないこと

書き込みのツールは、Claude Code の settings.json では ask に入れ、claude.ai のコネクタでは「承認が必要」にします。見落としやすいのは、ツールを後から足したときです。ask への追加を忘れると、そのツールだけ確認なしで実行されることがあります。Claude Code の auto モードなら、ask に無いツールを自動の判定が通してしまうこともあります。書き込みのツールの一覧と ask の一覧が揃っているかは、人の注意に頼らずテストで見張ります。

ツールを自分で作っている場合は、提供する側からも確認を外せないようにしておけます。書き込みのツールに確認必須の印（anthropic/requiresUserInteraction）を付けておくと、Claude Code では auto や bypassPermissions のモードでも、allow のルールがあっても、呼び出すたびに確認画面が出ます（第 2 章）。

手元の作業用に CLI があっても、エージェントには使わせません。経路が 2 本になると、同じ操作に確認を通る道と通らない道ができてしまいます。settings.json の deny で CLI のコマンドを止める手もありますが、書き方を変えたコマンドには一致せず、確実ではありません。効くのは、CLI が使う鍵をエージェントに渡さないことです（第 2 章）。

断られたときの振る舞いも先に決めておきます。確認画面で断られたら、別の経路は探させず、断られたことを報告して止まる。スキルにも依頼文にも、この一文を書いておきます。

確認画面で誰がいつ許可したかは、ツールを提供する側には残りません（第 2 章）。だから書き込みのツールの側で、いつ・何を・何件に書き込み、結果がどうだったかを毎回残します。

ここまでをスキルに書く

9.3〜9.6 節の約束は、運用ツールを読み書きするスキル 1 本にまとめられます。配信計画やリッチメニューの設計は別のスキルに分け、このスキルは実データの読み書きだけを受け持ちます。骨子は次のとおりです（書式は第 2 章と同じ）。

---
name: line-crm-data
description: >-
  LINE 運用ツール（Liny / Lステップ）の友だち・タグ・友だち情報・流入経路を
  読み取って集計し、タグの作成や付与を、確認画面を通して行う。
  「先月の新規友だちは？」「ブロック率を出して」「休眠のタグを作って」
  「経路ごとの追加人数」で使う。
  ※配信計画・あいさつメッセージ・リッチメニューの設計は LINE 運用設計のスキル、
  LP の友だち追加ボタンの計測は LP 計測のスキル。
  メッセージの配信はどのスキルでもできない（公開 API に口が無い）。
---
# LINE 運用ツールの友だち・タグ操作

## 守備範囲
- できる: 友だち・タグ・友だち情報・流入経路の取得と集計、タグの作成と付与（確認画面を通す）
- できない: 配信。頼まれたら「API に口が無く、管理画面で人が送る」と答え、宛先のタグ作りまでを引き受ける

## 読み取りの手順
1. 期間を日本時間の ISO 8601 まで落とす
2. タグや経路の ID は一覧から引く。推測しない
3. 次ページの印が空になるまで辿る。上限で止めたら「N 人以上」と書く
4. 集計はこちらで行う。流入経路の人数はユーザー ID で重複を除く
5. 429 の本文が月間上限なら再試行せず、「今月は未取得。翌月に戻る」と報告する

## 書き込みの手順（書き込みのツールは呼ぶたびに確認画面が出る）
1. 既存のタグとフォルダを一覧で確認する
2. 作成・付与の予定（何を・何人に・確認画面は何回）を文章で見せ、合意を取る
3. 1 操作ずつ呼ぶ。引数には ID だけでなく、タグの名前や対象人数など人が読める値も入れる
4. 確認画面で断られたら、別の経路を探さずに、断られたことを報告して止まる

## 縮退先
- 連携が無い: 「連携が未設定」と伝え、タグ設計書・セグメント定義・管理画面での手順を先に出す
- 取れなかった数字: 0 と書かず、「未取得」と理由を書く

スキルを実データの読み書きだけに切ったのは、鍵と確認画面の作法を 1 か所に集めたかったからです。設計は、9.8 節の温泉旅館の例のように運用ツールの無い案件でも要り、鍵が無くても出せます。同じスキルに同居させると、設計を頼んだだけなのに、まず連携の有無が問われてしまいます。description の末尾に配信はどのスキルでもできないと書いたのは、この 1 文が無いと、「配信しておいて」と頼まれたときに設計のスキルとこのスキルのどちらが立つかが依頼ごとに揺れるからです。宛先のタグ作りまでは引き受けると続けたのは、「そもそも API に無い」と伝えたあとも成果物をゼロで終わらせないためです（9.3 節）。

読み取りの規則には共通点があります。案件が変わっても中身は同じで、しかも破ってもエラーが出ません。期間を日本時間の ISO 8601 まで落とさせるのは、UTC で切ると朝 9 時までの友だち追加が前日に載ってしまうからです（9.5 節）。ID を一覧から引かせて推測を禁じたのは、経路には一覧を返す口が無いためです。渡されなければ、エージェントは友だちの全件走査で代わりを探し、1 案件で月間上限を使い切ります（9.7 節）。経路 ID を依頼文の側に持たせるのはこのためです。「N 人以上」と書かせるのは総件数のフィールドが無いからで、ゼロで埋めても全件と称しても嘘になります（9.4 節）。月間上限の 429 で再試行させず「翌月に戻る」と報告させるのは、秒間と月間で次の一手が正反対だからです。同じ「混み合っています」に畳むと、利用者は待つべきかプランを見直すべきかを決められません。

書き込みの手順は、確認画面を押す人が判断できる形で操作を通すためにあります。まず既存のタグとフォルダを見させます。同名タグを弾く保証は無く、二重に作ればどちらに人が入っているか分からなくなり、しかもタグは消せません。予定を文章で見せて合意を取らせるのは、確認画面がツールを呼ぶたびに 1 回出るからです。合意なしに呼ぶと、9.8 節の「休眠のお客さんにタグを付けておいて」の例のように、確認する人は全体像を持たないまま確認画面だけで判断させられます。依頼を 2 通に分けてくれる人ばかりではないので、スキルの側で先に止めておきます。引数に人が読める値を入れさせたのは、確認画面に出るのがツール名と引数だけで、ID の列では何を許可するのか判断できないからです。断られたら別の経路を探さずに止まる、という一文も欠かせません。止めた操作が別の手段で通るなら、確認の意味が無くなります。依頼文に書き忘れた回にも効くよう、スキルにも置きました。期間・経路 ID・休眠の基準のように案件ごとに変わるものは依頼文に残し、変わらない規則だけをスキルに入れる、という分担です。縮退先は、連携が無い案件を「連携が未設定」の 1 文で終わらせず、タグ設計書とセグメント定義までは納品するために置いています。

9.7 友だち獲得の導線と計測

3 つの入口と、LP の CTA

友だちが増える場所は 3 つです。店頭（レジ横・入口・テーブルの QR コードとスタッフの一言）、SNS（プロフィール欄・ストーリーズ・動画の説明文）、特典（登録した直後に使えるクーポン）。「そのうち使える」特典は効きません。関心の無い人を大量に集めると、ブロックが増え、通数で課金される配信費も無駄になります。

LP に置く友だち追加の CTA（Call To Action。押してほしいボタン）には 3 つの約束があります。経路ごとに別の URL を発行する（ヒーロー・料金表・フッターで分ける）、発行された URL を加工しない（経路の判別に使われている）、LP 側のラベルと管理画面の経路名を揃える（後の突合が楽になる）。1 本の URL を全部のボタンに使い回すと、どこから来たのかが永久に分かりません。クリック時には、広告媒体のピクセル（サイトに貼る計測タグ）と解析ツールのイベントを併発させます。

<a class="line-cta" data-source="lp-hero"    href="発行された経路URL（加工しない）">LINE で友だち追加</a>
<a class="line-cta" data-source="lp-pricing" href="発行された経路URL">LINE で友だち追加</a>
<script>
document.querySelectorAll('.line-cta').forEach(el => {
  el.addEventListener('click', () => {
    const source = el.dataset.source;
    if (window.fbq)  fbq('track', 'Lead', { content_name: source });
    if (window.gtag) gtag('event', 'generate_lead', { method: 'line', source });
  });
});
</script>

タグ設計も経路と対で決めます。経路「lp-hero」を通ったら「流入経路-LP-ヒーロー」のタグが自動で付く、という対応表を管理画面のアクション設定に入れます。9.2 節の「登録の瞬間に焼き付ける」の実体はこれです。流入経路分析は使えるプランが限られることがあるので、設計の前に確認しておきます。

クリックの計測を付ける 4 つの形

友だち追加ボタンを押すと、画面は LINE アプリへ移ります。計測タグの送信が終わる前にページを離れると、クリックが記録されないことがあります。付け方は 4 つあり、確実さと使い心地の兼ね合いで選びます。

2 つ目の形は次のように書きます。

document.querySelectorAll('.line-cta').forEach(el => {
  el.addEventListener('click', (e) => {
    if (!window.gtag) return;             // 解析タグが無ければ普通に移動させる
    e.preventDefault();
    const dest = el.href;
    let moved = false;
    const go = () => { if (!moved) { moved = true; location.href = dest; } };
    setTimeout(go, 1000);                 // タグが応答しなくても 1 秒で移る
    if (window.fbq) fbq('track', 'Lead', { content_name: el.dataset.source });
    gtag('event', 'generate_lead', {
      method: 'line', source: el.dataset.source,
      event_callback: go, event_timeout: 800,
    });
  });
});

event_callback（送信が終わったら呼ぶ関数）と event_timeout（その待ち時間の上限。ミリ秒）は、Google タグの公式のパラメータです（パラメータの公式リファレンス）。それとは別に 1 秒の上限を自前で置いているのは、広告ブロッカーなどでタグが応答しないときに、ボタンを押しても何も起きない状態を防ぐためです。

経路名の付け方

経路名は、どこに置いたボタンかが名前だけで分かるように、接頭辞で種類を揃えます。管理画面の経路名と、LP 側のボタンのラベルは完全に一致させます。

季節や期を名前に入れるときは、年も入れます。「spring」だけでは、1 年後にどの春か分からなくなります。

クリック数と追加数は一致しない

LP 側で測れるのは「クリック数」、運用ツール側で測れるのは「友だち追加数」です。両者は必ずずれます。クリックしたが LINE アプリを開かなかった人、開いたが追加を押さなかった人、すでに友だちだった人がいるからです。差分は歩留まりであって、計測の不具合ではありません。KPI（追う数字）は「LP の CV（クリック）」と「LINE の CV（追加成立）」に分け、追加率 = 追加数 ÷ クリック数 を別に持ちます。

もう 1 つ、構造的にできないことがあります。LP のクリックと LINE のユーザー ID は紐づけられません。 LINE アプリへ受け渡された瞬間に Web 側の Cookie（ブラウザに残る小さな記録）が途切れるためで、運用ツールの制約ではなく LINE 全体の仕様です。「誰がクリックしたか」を前提にした設計は提案しません。計測 ID が未発行のときに仮の値を入れることもしません。タグが入っているように見えて何も送っていない状態は、未設置より発見が遅れます。

実際にエージェントへ頼むときは、経路の ID・期間・重複の扱い・クリック数の出どころを依頼文に書きます。9.5 節のとおり経路の一覧を返す口は無いので、ID を渡さないと、エージェントは友だちの全件走査で代わりを探します。次は駅前の美容室を例にした依頼です。

駅前の美容室の LINE 公式アカウント（Liny を利用）について、
流入経路ごとの友だち追加数をまとめてください。

対象の経路（ID は管理画面の流入経路分析で確認済み）:
- 1021: LP のヒーローのボタン
- 1022: LP の料金表のボタン
- 1023: 店頭レジ横の QR コード
- 1024: Instagram のプロフィール欄
期間: 2026-08-01 00:00 〜 2026-08-31 23:59（日本時間）

数え方:
- 通過の記録は 1 回ごとに 1 行なので、人数はユーザー ID で重複を除いて数える
- 2 つ以上の経路を通った人は各経路で 1 人ずつ数え、重複した人数を別に書く
- 期間中にブロックした人も追加人数に含め、うちブロック済みの人数を別の列に出す
- LP の 2 経路には、解析ツールのクリック数（generate_lead イベント）を並べて追加率を出す。
  クリック数は私が CSV で渡す。渡していない経路は「未取得」と書く

やらないこと:
- 経路 ID を推測しない。上の 4 つ以外の経路は扱わない
- 友だちの全件走査はしない（今月の API 上限を使い切るため）
- 経路ごとの人数を合計して「LINE 経由の総追加数」としない

出力: 経路ごとに 1 行の表（経路名 / 追加人数 / うちブロック済み / クリック数 / 追加率）と、
「一言でいうと」から始まる 3 行の説明。

一方、「LINE の流入経路ごとの友だち数を出して」という 1 行だけの依頼では、経路 ID も期間も重複の扱いも決まっていません。エージェントは経路の一覧を取ろうとして失敗したあと、全友だちを走査して月間上限を使い切るか、通過の行数をそのまま人数として報告します。どちらの場合もエラーは出ず、それらしい数字だけが返ります。

上の依頼に「やらないこと」の 3 行を入れたのは、できない操作と足してはいけない数字を先に書いておけば、エージェントが別の手段を探しにいかないからです。

追加率がおかしいときの切り分け

追加率が極端に低いとき、あるいは経路によって大きく違うときは、手前から順に確かめます。

1. 経路 URL。 管理画面で経路の URL を開き直し、ボタンのリンク先と 1 文字ずつ一致するかを見ます。経路 A の URL を経路 B のボタンに貼る取り違えは、ここで見つかります。
2. クリックの計測。 ボタンを押し、広告媒体のピクセルの確認ツールと、解析ツールのデバッグ画面で、イベントが送られたかを見ます。同じタブで移る形なら、送信の前に移動していないかも確かめます。
3. 追加の計測。 テスト用の自分の LINE アカウントで、経路 URL から友だち追加します。管理画面の流入経路分析で該当の経路が 1 増えるか、経路のタグが付いたかを見ます。反映には数分かかることがあります。
4. 突き合わせ。 同じ期間（1 週間など）で、クリック数と追加数を並べます。差の理由の候補は、すでに友だちだった人の再クリック、ブロックしていた人の解除（別に数えられる）、ボットや連打による重複クリックです。

追加率の「業界の目安」として出回っている数字は、出典の確かなものが見当たりません。他所の数字と比べず、同じ LP の先週と比べます。

URL やプランがそろっていないとき

実装の前に決めることは 6 つあります。経路の数と分け方の単位（ボタンごと、LP ごと、広告ごと）、経路 URL（管理画面で発行して受け取る。こちらでは発行できない）、経路ごとに自動でタグを付けるか、クリック時にイベントを送る媒体、ボタンの文言と位置の一覧、そして契約のプランで流入経路分析が使えるか、です。そろっていないときも、実装を止めません。

• 経路 URL がまだ無い。 ボタンの位置・クラス・経路のラベルまで決めた実装を先に作り、URL の場所は空けて「ここに管理画面で発行した URL を貼る」と書きます。仮の URL は入れません。
• プランが流入経路分析に対応していない。 経路ごとの内訳はあきらめ、LP 側のクリック数で「LP から何件送ったか」までを出します。何が測れて何が測れないかは、表にして渡します。

ここまでのボタンの付け方と、数字が合わないときの扱いを手順書にすると、次のようになります。書式は第 2 章と同じで、骨子なので、使うときはこの節の規則を足してください。

---
name: line-cta-tracking
description: >-
  LP の友だち追加ボタンを、流入経路ごとに分けて計測できる形で実装する。
  「LINE 友だち追加の計測」「経路ごとに集計したい」
  「クリック数と友だち追加数が合わない」で使う。
  ※LP 自体の作成と計測タグ全般は LP 生成のスキル（第 4 章）。
---
# 友だち追加ボタンの計測

## 手順
1. **経路ごとに別の URL を発行してもらう**（こちらでは発行できない）
2. 発行された URL を**加工せず**ボタンに貼る
3. LP 側のラベルと管理画面の経路名を完全に揃える
4. クリック時に計測のイベントを送る。**送信前にページを離れない工夫**を入れる
   （別タブで開く / 完了を待って移る。待つ場合も上限時間を自前で置く）
5. 経路名は接頭辞で揃える（ページ内の位置 / 広告 / SNS / メール / 店頭）。
   季節や期を入れるときは**年も入れる**

## 守ること
- クリック数と友だち追加数は**必ずずれる**。差分は歩留まりであって不具合ではない。
  KPI を 2 つに分け、追加率を別に持つ
- 「誰がクリックしたか」を前提にした設計を提案しない（構造的に紐づかない）
- 計測番号が未発行のときに**仮の値を入れない**。空けて「ここに貼る」と書く

## 縮退先
- 経路別の集計が契約プランで使えない → LP 側のクリック数までを出し、
  **何が測れて何が測れないかの表**を添える

この手順書が持つのは、ボタンの実装の形と、数字が合わないときの読み方だけです。経路 URL は管理画面でしか発行できず、追加数は運用ツール側の数字なので、どちらも扱いません。LP 自体の作成と計測タグ全般を第 4 章の手順書へ送ったのも同じ理由で、この手順書に固有なのは経路ごとの URL と、LINE アプリへ移る直前のクリックの残し方に限られます。description に「クリック数と友だち追加数が合わない」を入れたのは、この訴えが必ず来るからです。守ることに「必ずずれる」と書いておけば、エージェントは歩留まりを不具合として直しにいかず、KPI を 2 つに分けます。

手順の先頭に「発行してもらう」「加工しない」を置いた理由は、経路の判別が URL そのもので行われている点にあります。1 本の URL を使い回すと、どこから来たのかは後から遡れません（9.2 節）。発行された URL への付け足しが許されるかは公式に確認できていないので、既定は加工しない側に固定しました。送信前にページを離れない工夫と、自前の上限時間は対で入れています。計測タグの送信が終わる前に LINE アプリへ移るとクリックが記録されず、かといって完了を待つだけだと、広告ブロッカーでタグが応答しないときにボタンが何も起きなくなるからです。依頼する人がここまで書くことはまず無いので、手順書が持ちます。「誰がクリックしたか」を前提にした設計を提案させないのは、LINE アプリへ渡った瞬間に Web 側の Cookie が切れるのが LINE 全体の仕様だからです。仮の値を禁じたのは、タグが入っているように見えて何も送っていない状態が、未設置より発見が遅れるからです。縮退先は、契約のプランで流入経路分析が使えない案件でも実装を止めず、LP 側のクリック数までを出し、何が測れて何が測れないかの表を添えるために置きました。経路の数と分け方・URL・送る媒体・ボタンの位置・プランは案件ごとに変わるので、依頼文が持ちます。

広告の CV が「友だち追加」であるとき

姉妹記事で触れた「運用ツールに、なぜ広告連携があるのか」を、実装の言葉にします。広告主は Meta 広告の CV を「友だち追加」にしたい。ところが追加が起きるのは LINE アプリの中で、広告主のサイトではありません。サイトに置いたタグでは検知できず、ブラウザ側の計測はトラッキング防止でも欠けます。だから、サーバー側から CV を返す道が要ります。Meta のそれが Conversions API（CAPI。広告主のサーバーから Meta へ成果を送る API）です。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
  AD["広告クリック<br/>URL に fbclid が付く"] --> LP["LP<br/>クリックIDを保持"]
  LP -->|"CTA クリック"| PX["ブラウザ: ピクセルの Lead<br/>event_id を採番"]
  LP -->|"経路URL"| APP["LINE アプリ<br/>Web の Cookie はここで切れる"]
  APP --> FR["友だち追加<br/>経路タグが付く"]
  FR --> VISIT["追加後の予約・来店<br/>予約システム / 店頭"]
  VISIT --> SRV["自社サーバー<br/>ハッシュ化・event_id"]
  SRV -->|"CAPI"| META["Meta<br/>event_id が同じなら 1 件に"]
  PX --> META

実装で押さえる点は 4 つで、いずれも執筆時点の公式ドキュメントで確認できます。

1. 重複排除。 ブラウザのピクセルと同じ成果をサーバーからも送るなら、event_id とイベント名をブラウザ側と一致させます。Meta は一致するものを 48 時間の窓で 1 件に畳みます（重複排除の公式説明）。採番はサーバー任せにせず、呼び出し側に必須で指定させます。値が揃わなければ二重計上です。
2. クリック ID の保持。 広告クリックで URL に付く fbclid は、ブラウザではクリック ID のクッキーに保存され、サーバーから送るときは fbc という項目で渡します。組み立ての形式は顧客情報パラメータの公式説明に定義があります。
3. ハッシュ化。 メールアドレスと電話番号は SHA-256（一方向のハッシュ関数）で送ります。正規化の規則が決まっていて、電話番号は記号と先頭のゼロを除き、国番号を含めます。国番号をサーバーで補うと、海外の番号が日本の番号として送られます。
4. 鍵の置き場。 受信口の鍵をブラウザの JavaScript に書きません。ページのソースを見れば誰でも読めるので、任意の成果を送り込まれます。送信は必ずサーバー（LP のバックエンド、予約システム、タグマネージャのサーバーサイド）から行います。

未確認事項が 1 つあります。追加成立の瞬間を広告側へ返すには「この友だちは、どの広告クリックから来たか」が要りますが、クリック ID を友だち追加の経路にまたがって運ぶ手段は、運用ツールの公開 API では確認できていません。経路の通過記録にはクエリパラメータが残る項目があるので、設計上は経路 URL にクリック ID を載せる道が考えられます。ただし発行された URL への付け足しが許されるかは、執筆時点で公式に確認できていません。「できる」とも「できない」とも断定せず、管理画面で経路を 1 つ発行し、パラメータを付けて自分で通過し、記録に残るかを試すのが最短です。確認できるまでは、返す CV を「追加後の予約・来店」（自社の予約システムで起きる出来事）に置きます。広告主が本当に最適化したいのは友だち追加ではなく、その先の来店や購入のはずです。

9.8 配信設計: 型と数値の扱い

配信そのものは管理画面で行いますが、設計は自動化の入力です。AI に運用設計書を書かせるなら、型を渡します。

目的とファネル、あいさつ、リッチメニュー

目的は 1 アカウント 1 つに絞ります。再来店（飲食・美容）、予約（宿泊・美容）、情報到達（自治体）。KPI は 9.1 節の 4 つを上から順に追います。

あいさつメッセージは、友だち追加の直後に自動で送られ、課金対象外で、最大 5 吹き出しまで使えます（LINEヤフー公式の解説）。関心がいちばん高い瞬間に届く、いちばん読まれる場所。型は 3 ブロックです。何者で何をどのくらいの頻度で送るか、このアカウントでできること（予約・クーポン）、友だち限定の初回特典、の順に並べます。

リッチメニューはトーク画面の下に常設されるボタンで、配信と違って何度でも見られます。予約・メニューと料金・場所と営業時間・クーポン・問い合わせだけを置き、期間限定の告知は置きません。終わったあと、まず直し忘れます。ボタンは多くても 6 つ。デフォルト表示を ON にします。非表示のまま放置は典型的な事故です。

業種ごとのあいさつとリッチメニュー

あいさつメッセージとリッチメニューの中身は、業種でおおよその型が決まっています。飲食と美容は公式の解説の例に沿ったもの、宿泊と自治体は同じ構成を当てはめたものです。

リッチメニューは、次の順で決めます。

• 目的を 1 つ決めてから、分割数とデザインを決めます。 訴求を絞るなら、3 分割程度の大きなボタンのほうが押しやすくなります。
• サイズはテンプレートどおりに作ります。 管理画面のテンプレートは、大（2500×1686 ピクセル）と小（2500×843 ピクセル）の 2 種類です（執筆時点の公式マニュアル）。
• よく押される位置は、自分のアカウントで確かめます。 「左上がよく押される」説と「右下がよく押される」説があり、公開されている情報の結論が一致していません。管理画面の分析では、ボタンの領域ごとのクリック数を確認できます（期間中のクリックが 20 人未満だと表示されません）。
• 切り替えと出し分けを区別します。 表示期間を指定して、キャンペーン用から通常用へ自動で切り替えるのは標準機能でできます。友だちの属性やタグで人ごとに違うメニューを出すには、Messaging API（ユーザーごとにリッチメニューを紐づけられる）か運用ツールが要ります。
• よくある失敗は 3 つです。 詰め込みすぎて余白が無い、写真の上に細い白文字を載せて読めない、ボタンの間隔が狭くて押し間違える。

配信で使う形式も、役割で選びます。

リッチメニューの設計を頼むときは、目的・使う機能・サイズ・比べ方を依頼文に書き、画像を作る前の指示書までにします。

駅前の美容室の LINE 公式アカウントで使う、リッチメニューの設計案を 2 つ作ってください。
画像は作らず、デザイナーに渡す指示書までにします。

前提:
- 目的は予約（1 つに絞る）。予約は外部の予約サイトで受けている
- 標準機能だけを使う。人ごとの出し分けはしない
- 大きいサイズ（2500×1686 ピクセル）のテンプレートを使う
- 期間限定の告知はメニューに置かない（配信で送る）

作ってほしいもの:
- 案 A: 6 分割。予約 / 空き状況 / メニューと料金 / スタッフ / クーポン / アクセス
- 案 B: 3 分割。予約を大きく置き、残りの 2 つはメニューと料金 / アクセス
- 各ボタンの文言（8 文字以内）、リンク先、その位置に置いた理由
- 2 案を 2 週間ずつ入れ替え、管理画面の分析で予約ボタンのクリック数を比べる手順
- 「左上がよく押される」のような位置の通説は、根拠として使わない

「おしゃれなリッチメニューを作って」とだけ頼むと、目的が決まらないまま、思いつくボタンが 6 つ並びます。期間限定の告知が入ることも多く、終わったあとも残り続けます。比べ方が書かれていないので、作ったあとに良し悪しを判断する材料も残りません。

月次計画、ステップ配信、セグメント配信

月次配信計画の初期値は、週 1〜2 回、1 配信 1 テーマ、1 行目（通知に出る部分）の 15〜20 文字に限定感と特典を凝縮、です。ブロック理由の筆頭は「配信が多すぎる」。頻度を上げる提案には、ここを先に思い出してください。

配信文面の型

文面にも、仕様と型があります。

• 仕様。 テキストは 1 吹き出し 500 文字まで、通常の配信は 1 回 3 吹き出しまでです（執筆時点の公式マニュアルと公式の解説）。読みやすい分量は、トーク画面 1 画面に収まる 200〜300 文字とする解説が多く見られます。こちらは通説です。
• 1 行目。 通知とトーク一覧に出るのは、1 つ目の吹き出しの冒頭です。型は 3 つあります。期限や限定を先に書く（「今週末まで」）、悩みに寄り添う問いかけ（「雨の日の予定、決まっていますか」）、得になる内容を先に書く（「500 円引きのクーポンが届きました」）。
• CTA。 1 配信に 1 つにします。「詳しくはこちら」ではなく「空き状況を見る」「クーポンを使う」のように、押したあとに起きることを書きます。期限も添えます。
• トーン。 Instagram など既存の SNS の口調と揃えます。自治体や企業向けのアカウントでは、絵文字を控えます。
• 配信の時刻。 公式の解説では、受け取ってすぐに開くのが約 2 割、その日のうちに開くのが約 8 割です（LINEヤフー公式の解説）。来店や予約をしてほしい時刻から逆算して送ります。業種ごとの推奨時刻は解説によって違うので、最初は仮説として置き、実績で確かめます（飲食の昼なら、お昼を決める前の時間帯など）。
• 比べ方。 文面・画像・時刻のうち、1 回に変えるのは 1 つだけにします。2 つ同時に変えると、どちらが効いたのか分かりません。

配信文の作成を頼むときは、テーマ・分量・1 行目・CTA・口調を指定します。

駅前の焼き鳥店の LINE 公式アカウントで、来週火曜の 17:30 に送る配信文を作ってください。

- テーマは「平日限定の 1 杯サービス」の 1 つだけ。ほかの告知は入れない
- 吹き出しは 2 つまで。本文は合計 250 文字以内
- 1 行目は 20 文字以内。期限・限定・特典のどれかを入れた案を 3 つ出す
- CTA は「席の空きを見る」の 1 つだけ。リンクは（予約ページ）と書いておく
- 絵文字は 2 個まで。店の Instagram と同じ口調（です・ます、くだけすぎない）にする
- 開封率やクリック率の見込みの数字は書かない

「来週の配信文を作って」とだけ頼むと、新メニューと営業時間の変更とクーポンが 1 通に入り、1 行目は「こんにちは」から始まりがちです。通知に出る部分で用件が伝わらないので、開かれる前に読み飛ばされます。

ステップ配信と、標準機能の境界

ステップ配信（追加日を起点に、決めた順で自動で送る配信）の共通の型は 3 層です。追加直後の特典、中期（1 週間〜2 か月）の再来店促進、休眠（3〜6 か月）の掘り起こし。休眠の掘り起こしは「効くが劇的ではない」前提で期待値を置きます。セグメント配信（条件で絞って送り分ける配信）を含め、標準機能とツールの境界は次のとおり。まず標準で始め、来店回数のセグメントや予約日起点のリマインドが必要になった段階でツールを検討します。

ステップ配信の設計を頼むときは、起点、来店や再訪の周期、標準機能か運用ツールか、を依頼文に入れます。そのうえで「設定は人が行う」と明記します。成果物は、管理画面へ入力するための設計表です。

温泉旅館の LINE 公式アカウントで使う、ステップ配信の設計表を作ってください。
配信の設定は私が管理画面で行います。あなたは設定しないでください。

前提:
- 友だちは約 1,200 人。ほとんどが宿泊した人か、予約サイトから来た人
- 目的は再訪の予約（1 つに絞る）。再訪の周期は 1 年前後
- 使っているのは LINE 公式アカウントの標準機能だけ。運用ツールは未導入
- 配信は多くても月 2 回まで。宣伝ばかりにしない

作ってほしいもの:
- 追加直後 / 宿泊後 / 休眠（半年〜1 年）の 3 層で、ステップごとに
  「起点からの日数・送る内容（1 テーマ）・通知に出る 1 行目（20 文字以内）・CTA」の表
- 各ステップが標準機能で作れるか（待ち時間は日数指定で 1〜30 日、1 ルート 10 ステップまで）を判定する列
- 標準機能で作れないもの（予約日や宿泊日を起点にするもの）は表から外し、
  「運用ツールが要るもの」として別に一覧にする
- 数値の目安を書くときは出典と取得日を付ける。出典の無い「業界平均」は書かない

出力: 表 1 枚と、運用ツールが要るものの一覧。

「ステップ配信を作って、設定までお願い」とだけ頼むと、2 つのことが起きます。1 つは周期の取り違えです。再訪が 1 年前後の旅館に、飲食店向けの「7 日後・30 日後」の型がそのまま当てはめられます。もう 1 つは、エージェントが設定の手段を探し始めることです。配信の口は API に無いので設計表を出すのが正しい結果ですが、依頼が「設定まで」なので、どこまでできたのかが曖昧な報告になりがちです。

標準機能で作れるかを判定する列を足しておくと、運用ツールを導入するかどうかの判断材料も、設計表と同時に手に入ります。

業種ごとの周期と、セグメントの軸

ステップ配信の時期とセグメントの軸は、業種の来店周期で決まります。次の表は業界の解説記事で共通して見られる型で、宿泊と自治体は公開された事例が少ないため仮説です。

店舗型ビジネスで最も効くのは来店回数の軸ですが、標準機能では表せません。標準機能の絞り込みには人数の条件もあります。属性で絞るにはターゲットリーチ（ブロックを除いた、配信が届く人数）が 100 人以上必要で、絞り込んだ後が 50 人未満だと配信できません（公式マニュアル）。友だちの少ない立ち上げ期は、全員への配信から始めることになります。

セグメントを定義するときは、使えない場合の扱いまで 1 か所に書いておきます。

segment: 2 回目の来店のお誘い（駅前の焼き鳥店）
with_tool:                       # 運用ツールがある場合
  conditions:
    - 来店回数: 1 回               # 友だち情報。スタッフが来店時に入力
    - 最後の来店から: 20〜40 日
  exclude:
    - ブロック済み
    - 直近 7 日に配信を受けた人
standard_only:                   # 標準機能だけの場合
  conditions:
    - 友だち期間: 30〜60 日         # 来店回数の代わり。精度は落ちる
  if_under_50: 絞り込み配信はできない。全員への配信に含める
expected_count: 数えてから確定する

タグで切るセグメント

ツールでのセグメントは「タグの集合」です。条件に合う人を自動で入れ続ける動的セグメントの API は無く、作れるのは「取得 → 判定 → タグ付与」という、その時点のスナップショットだけ。だからタグ名に基準を書き、切り直す前提で設計し、「常に最新」とは説明しません。よく使う型は 4 つあります。ライフサイクル（新規-7日以内 ／ 既存-アクティブ ／ 休眠-90日以上。境界の日数は来店周期で案件ごとに決める）、カスタマージャーニーのステージ（排他。進めるときは前のステージを外す）、エンゲージメント（直近 30 日の返信の有無で切る。開封率は API で取れないので、取れない指標で層を切らない）、A/B テストの群分け（分け方を再現できる規則で記録し、判定基準を配信前に固定する）。

タグでセグメントを切る依頼は、書き込みを含むので 2 回に分けます。1 通目で設計と人数を出させ、内容に合意してから、2 通目で作成と付与を頼みます。1 通目は次のような形です。

駅前の美容室の Lステップ で、しばらく来ていないお客さんに再来店を促すためのタグを設計してください。
今回は設計と人数の確認までです。タグの作成や付与はまだしないでください。

前提:
- 来店の周期は 1〜2 か月。90 日以上来ていない人を休眠とみなしたい
- 来店の記録は Lステップ に無い。代わりに「最後にこちらへメッセージを送ってきた日」で判定する
- 一度もメッセージを送ってきていない人は、友だち追加の日で判定する
- 既存のタグと命名規則を先に一覧で確認し、それに合わせる

出してほしいもの:
1. 作るタグの一覧（フォルダ / タグ名 / 判定の条件）。タグ名には基準を入れる
   （例: ライフサイクル-休眠-90日以上）
2. 各タグに入る人数。ブロックした人は除く。一覧を辿り切れなかったら「N 人以上」と書く
3. 作成と付与の手順（何を、何人に、確認画面が何回出るか）
4. このタグは付けた時点の状態を表し、自動では更新されないことの説明

やらないこと:
- 購買回数や購買額で判定しない（データが無い。推定で埋めない）
- 開封率で層を切らない（API で取れない）

設計を確認して合意したら、2 通目で作成と付与を頼みます。書き込みのたびに確認画面が出ることと、断った操作をどう扱うかも、依頼の中で先に伝えておきます。

設計どおりに進めてください。
1. フォルダ「ライフサイクル」を作る
2. そのフォルダに「ライフサイクル-休眠-90日以上」を作る
3. 1 通目で数えた 84 人に、このタグを一括で付ける
それぞれ確認画面が出るので、私が内容を見て許可します。断ったものは、別の方法で実行しないでください。
付け終わったら、付けた人数と、1 通目で数えた人数との差を報告してください。

「休眠のお客さんにタグを付けておいて」という 1 通だけの依頼だと、休眠の基準が決まっていません。エージェントは一般的な目安で日数を決め、合意を取らないまま付与のツールを呼びます。確認する人は、条件も人数も前もって知らないまま、確認画面だけを見て判断することになります。9.6 節で書いたとおり、付与を取り消すには、一括解除でもう 1 回確認画面を通すことになります。

キャンペーンをタグで追う

期間を決めたキャンペーンも、タグで追います。最初に役割を分けます。

エージェントの報告に「配信しました」と書かせません。実際にしたのは宛先のタグの用意までです。

状態のタグは積み上げにします。 1 つのキャンペーンに 1 つのフォルダを作り、進んだ段階ごとにタグを 1 つ置きます。成約した人は対象者でもある、という非排他の付け方にすると、各タグの人数を割るだけで歩留まりが出ます。段階は 4 つまでを目安にします。細かく刻むほど付け忘れが増え、数字が実態から離れます。

フォルダ: 2026秋-平日連泊プラン
  2026秋-対象者
  2026秋-反応あり
  2026秋-予約済み
  2026秋-宿泊済み

数えるときの約束は 4 つです。

1. 対象者の重複を除く。 「新規」と「常連」の両方の条件に当てはまる人を 2 回数えると、対象者が実際より多く見えます。
2. 反応は配信日時から拾う。 配信日時より後に届いた受信メッセージのうち、対象者の分だけを残します。配信日時は依頼者から受け取り、推測しません。推測で切ると、前のキャンペーンの反応が混ざります。これは「配信のあとに連絡をくれた人」であって、「この配信に反応した人」とは限りません。報告にもそう書きます。回答フォームや経路の記録のほうが、根拠としては強くなります。
3. 未応募の人は 1 回の取得で出す。 対象者タグと応募済みタグを結合して 1 回で取り、差を取ります。2 回に分けると、その間に応募した人にリマインドが届きます。
4. 終わったら後片付けをする。 タグは消せないので「終了」を先頭に付けて改名し、数字はレポートとして残します。タグの一覧は、時間がたつほど探しにくくなります。

結果の集計は、次のように頼みます。

温泉旅館の「2026秋-平日連泊プラン」の結果をまとめてください。
配信は 10 月 3 日 18:00（日本時間）に、私が管理画面から対象者タグ宛てに送りました。

- 使うタグ: 2026秋-対象者 / 2026秋-反応あり / 2026秋-予約済み
- 3 つのタグを 1 回の取得で結合して数える。辿り切れなかったら「N 人以上」と書く
- 反応率と予約率は、どちらも対象者の人数で割る
- 10 月 3 日 18:00 以降に届いたメッセージの送り主のうち対象者だけを数え、
  「配信後に連絡をくれた人（この配信への反応とは限らない）」として別の行に出す
- 開封率とクリック率は API で取れないので、「管理画面の分析で確認」と書く
- 予約済みなのに反応ありのタグが付いていない人がいたら、人数を書く

出力: 「一言でいうと」から始まる 3 行と、段階ごとの人数と率の表。

最後の確認は、積み上げのはずのタグが積み上がっていない人を探すためのものです。付け忘れがあると、反応率より予約率のほうが高いという、ありえない表になります。

数値の扱い原則

一次データと通説を区別します。ブロック率は、LINEヤフー公式が公開した社内データと調査会社の大規模調査という一次性の高いデータが 2 系統あり、執筆時点ではいずれも 30% 台です。ここを基準線にし、大きく超えたら配信頻度・セグメント精度・獲得経路を見直します。一方、出回っている「開封率 55%」「クリック率 30%」の業界平均は一次ソースが特定できず、相互引用が疑われます。正直なところ、この手の数字は探せば探すほど出どころが薄くなります。他所の平均と比べず、自分のアカウントの先月と比べる。数値には出典と取得日を添えます。管理画面の分析は配信から 14 日間の集計で、結果数が少ないと伏せられます。立ち上げ期は配信別の分析が出ないことを先に伝えておきます。

管理画面の「開封」の定義も確かめておきます。いずれかの吹き出しが画面に 100% 表示された時点で 1 回と数え、同じ人を重複しては数えません。トークルームを開かずに既読になった場合は数えません。結果が 1〜19 件のとき、開封は「0」、それ以外の指標は「ー」と表示されます（公式マニュアル）。この「0」は、開封した人がいなかったという意味ではありません。

段階ごとに追う数字を変える

追う数字は、アカウントの段階で変えます。立ち上げたばかりのアカウントで売上を追っても、数字が小さすぎて判断できません。

ID 連携は、自社の会員 ID と LINE のユーザー ID を結びつけることです（公式の LINE ログインなどで行います）。結びついた人は、予約や購入の記録と配信の反応を突き合わせられます。後から増やしにくい数字なので、立ち上げの段階から案内を始めます。

事例を使うときの約束

提案や企画で「他社ではこう効いた」を示すときは、事例の選び方と書き方を決めておきます。

• 同じ業種で、近い規模の事例を 2〜3 件選びます。大手チェーンの数字は、友だち数の桁が違うので参考になりません。
• 成果の数字は、複数の施策を合わせた結果であることが多いです。「この施策を含む運用で」と書き、施策だけの効果と断定しません。
• 出典の種類を書き分けます。公式の事例ページ、母数を明記した調査、代理店やツール会社の自社ブログ、の 3 つです。後ろの 2 つはそう明記します。
• 効果の小さかった事例も探します。たとえば解説記事で紹介された美容室グループの事例では、半年以上来店の無い約 670 人に配信して、1 週間で再来店したのは 5 人（約 0.7%）でした。休眠の掘り起こしに過大な期待を置かないための材料になります。

温泉旅館への提案に使う、LINE 公式アカウントの活用事例を 3 件集めてください。

- 業種は宿泊施設。客室数 30 室前後の規模に近いものを優先する
- 各事例に、施策・成果の数字・出典 URL・取得日・出典の種類
  （公式の事例 / 母数のある調査 / 企業のブログ）を書く
- 成果は「この施策を含む運用で」と書き、施策だけの効果と断定しない
- 数字の根拠が示されていない事例は、その旨を書き、残すか外すかを私に聞く
- 効果が小さかった事例やうまくいかなかった事例が見つかれば、1 件含める

「LINE の成功事例を集めて」とだけ頼むと、業種の違う大手の事例と、根拠の書かれていない数字が並びがちです。出典の種類が書かれていないので、提案書に載せてよい数字かどうかを後から 1 件ずつ調べ直すことになります。

運用設計書は 1 枚にまとめる

運用設計書は 1 枚に収めます。

# LINE 運用設計書: <案件名>
- 目的: 再来店 / 予約 / 情報到達（1 つ）
- KPI: 友だち純増 __人/月・ブロック率 __%以下・LINE 経由予約 __件/月
- 友だち獲得導線: 店頭 / SNS プロフィール / 動画の説明文 / 特典の内容
- あいさつメッセージ: 3 ブロックの内容
- リッチメニュー: 分割数と各ボタン・優先 CTA
- 月次配信計画: 頻度・時間帯・テーマ一覧
- ステップ / セグメント: 層の構成・セグメント軸・ツール要否
- 計測: 月次で見る指標と見直し基準（出典・取得日付き）

この節の型は、依頼のたびに書かずに済むように、運用設計の手順書 1 本にまとめておきます。設計表を出すだけで、管理画面の設定も配信もしない手順書です。友だちやタグの実データの読み書きと、LP 側の計測は別の手順書に任せ、こちらは型だけを持ちます。

---
name: line-playbook
description: >-
  LINE 公式アカウントの運用を設計する（友だち獲得の導線・あいさつメッセージ・
  リッチメニュー・月次の配信計画・ステップ配信・セグメント）。
  「LINE の運用を設計して」「配信文を書いて」「リッチメニューを作って」
  「ブロック率を下げたい」で使う。
  ※友だち・タグの実データの読み書きはデータ操作のスキル、LP 側の計測は CTA 計測のスキル。
  **配信の実行はどのスキルでもできない**（公開 API に口が無い）。人が管理画面から送る。
---
# LINE 運用の設計

## 手順
1. 目的を 1 つに絞る（再来店 / 予約 / 情報到達）
2. 追う数字を 4 つ並べる（友だちの純増・ブロック率・配信のクリック・来店や予約）。
   **純増とブロックは必ず並べて見る**
3. あいさつメッセージを 3 ブロックで書く
   （何者でどの頻度で送るか / ここでできること / 友だち限定の初回特典）
4. リッチメニューは常設の導線だけを置く（期間限定の告知は入れない）。
   ボタンは多くても 6 つ
5. 配信は週 1〜2 回、1 配信 1 テーマ 1 CTA。1 行目に期限か特典を入れる
6. ステップは 3 層（追加直後 / 中期 / 休眠）。
   **標準機能で作れるかを判定する列を必ず付ける**

## 守ること
- 配信の設定はしない。成果物は管理画面へ入力するための**設計表**
- 来店周期は業種で変わる。他業種の型（「7 日後・30 日後」）をそのまま当てはめない
- 開封率・クリック率の見込みを書かない（公開 API で取れない）
- 出典の無い「業界平均」を使わない。自分のアカウントの先月と比べる

この手順書が設計表を出すところで止まるのは、配信の口が公開 API に無いからです（9.3 節）。守ることの先頭に「配信の設定はしない。成果物は設計表」と置いたのにも理由があります。「ステップ配信を作って、設定までお願い」と頼まれると、エージェントは設定の手段を探し始め、どこまでできたのかが曖昧な報告になりがちです。description の太字で配信の実行はどのスキルでもできないと繰り返したのは、「配信文を書いて」がこの手順書の検索語だからです。文面を書いた流れで送るところまで期待されるのを、依頼の段階で断っておきます。

手順の先頭で目的を 1 つに絞らせるのは、「おしゃれなリッチメニューを作って」のような目的の無い依頼が実際に来るからです。思いつくボタンが 6 つ並ぶのを、手順書の側で止めます。純増とブロックを必ず並べて見る、を太字にしたのは 9.1 節の最初の約束そのもので、友だち数だけを追うとブロック率が上がり、届く相手が減っているのに誰も気づけません。期間限定の告知をリッチメニューに入れない、1 配信 1 テーマ 1 CTA で 1 行目に期限か特典を入れる、週 1〜2 回から始める。この 3 つは、終わった告知の直し忘れ、「こんにちは」で始まって開かれる前に読み飛ばされる 1 行目、配信の多すぎによるブロック、という失敗を防ぐ規則で、依頼文に毎回書かせないために手順書へ入れています。標準機能で作れるかの判定列を必ず付けさせると、運用ツールを導入するかどうかの判断材料が設計表と同時に手に入ります。他業種の型を当てはめないと書いたのは、再訪 1 年前後の旅館に飲食店向けの「7 日後・30 日後」がそのまま入る取り違えが起きるからです。来店周期のような案件ごとの値は依頼文に残し、手順書は層の構成だけを持ちます。開封率・クリック率の見込みと出典の無い業界平均は禁じました。公開 API に配信の実績を返す口は無く、出回る「開封率 55%」「クリック率 30%」も一次ソースが特定できません。書かせれば、それらしい数字が設計表に残ります。

9.9 繰り返す分析は定期実行に登録する

「毎朝タグを付け直したい」「毎週セグメントを更新したい」は、必ず出てくる要望です。ここでスキルの中にループを組みません。エージェントの実行は 1 回で終わり、次の実行に前回の状態は残りません。履歴が要るなら、成果物・データベース・スプレッドシートといった外の永続先から取り直します。

置き場は 2 つです。時刻起点は定期実行（毎週月曜 9 時にセグメントを切り直す案を作る、毎月 1 日に先月の新規とブロックをまとめる）、条件起点はトリガー（ブロック率が基準線を超えたら通知する）。混ぜません。実行は正時だけで、分は選ばせません。定期実行には確認画面に答える人がいないので、確認が必要な書き込みは断られます（第 2 章）。定期実行は読み取り・集計・下書きまでにし、タグの付け直しのような書き込みは、人が会話しているときに確認画面を通して行います。置き場の設計そのものは第 11 章「全体最適を考える」で扱います。

自動で動いたものは必ず通知に残します。通知先が無い自動化は有効にできない形にし、見送った回も理由を残す。「昨日から動いていない」と「上限で見送った」が画面から区別できないと、次の一手が正反対になります。

定期実行への登録を頼むときも、時刻・まとめる範囲・書き込みの有無・通知先を 1 通に書きます。前回の値をどこから読むかも指定します。次の実行に前回の状態は残らないためです。

毎月 1 日の 9:00（日本時間）に、先月の LINE の数字をまとめる定期実行を登録してください。

- まとめる数字: 新規友だち、ブロック数、有効友だち、最終受信から 90 日以上たった人の数
- 休眠の人数はタグで数えず、実行した時点の一覧から数える
- 前月との比較を付ける。前月の値は先月のレポートから読み、見つからなければ「比較なし」と書く
- 読み取りだけにする。タグの付け直しはこの定期実行に含めない
- 結果は Slack の #line-report チャンネルに送る。取れなかった数字は 0 にせず「未取得」と理由を書く

「読み取りだけにする」と書いたのは、書き込みを含めると、確認画面に答える人がいない定期実行では断られるからです。タグの付け直しは、人が会話の中で頼み、確認画面を通して行います。休眠の人数をタグで数えず「その時点で数える」と指定した理由は、タグの性質にあります。タグは付けた時点の状態なので、付け直さないまま数えると、先月以前の判定がそのまま数字に残ります。

9.10 メールも構造は同じ

メール配信は、9.2 節の図の 2 箇所を差し替えるだけで同じ形になります。深入りはしませんが、対応表を置いておきます。

メールは API で送れるぶん、承認の重要度が上がります。「送信」は取り消せない外部反映で、自動化の成熟度を Lv4（AI が下書き、人が承認）から Lv5（例外だけ人に上がる）に上げてはいけない領域です。

章のまとめ

• LINE は「もう一度来てもらう」道具で、ブロックは戻らない。自動化は「送る相手を間違えない」方向に効かせる
• オントロジーの一意キーはユーザー ID。登録の瞬間に流入経路を焼き付け、タグは排他のステージと非排他の行動履歴に分ける
• 運用ツールの 2 ブランドは API が 1 本なので連携も 1 つ。標準 API の範囲だけ実装し、契約条件は書き写さない
• 公開 API に配信の口は無い。自動化できるのは友だち・タグ・属性の読み書きと分析まで、と先に書く
• 総件数は返らず、レートリミットは 2 段。「N 件以上」「最初の N 件までの集計」と明記し、月間超過は再試行しない
• 書き込みのツールはパーミッションで確認の対象にする。取り消せない操作ほど、対象人数を数え、設計を合意してから呼ぶ
• LP のクリックと追加成立は別の CV。広告へ CV を返す道は CAPI で、重複排除・クリック ID・ハッシュ化・鍵の置き場の 4 点を押さえる
• 繰り返す分析は定期実行へ。通知先が無い自動化は有効にしない
• タグは軸ごとのフォルダで作り、友だち情報は「誰がいつ値を入れるか」まで設計する。キャンペーンは積み上げの状態タグで歩留まりを出す
• 文面は 1 配信 1 テーマ 1 CTA。リッチメニューの位置の通説や他社事例の数字は、自分のアカウントの実測で確かめる

演習

1. 自分の LINE 公式アカウント（無ければメール配信）について、9.2 節の図を描き直してください。各ノードが実在するか、つまりどの管理画面・API・データベースに対応するかを書き添えます。対応先の無いノードが、これから作るものです。
2. 使っている運用ツールの API リファレンスを開き、「総件数」「レートリミットの種別」「配信の口」の 3 つを確かめてください。無いものを「無い」と書いた表が、そのまま連携の仕様書の第 1 版になります。
3. 友だち追加ボタンのある LP を 1 枚選び、経路ごとの URL とタグの対応表を作ってください。クリック数と追加数を 1 週間並べて、追加率を出します。
4. 直近のキャンペーンを 1 つ選び、状態のタグ（対象者・反応あり・応募・成約など）の設計と、API では取れない指標の一覧を作ってください。取れない指標をどの画面で確認するかも書き添えます。

次の章へ

LINE 運用の話はここまでです。次の第 10 章「営業活動を自動化する」では、第 8 章の実査と検知の型を営業に向け、リード発掘・企業調査・アウトリーチ文面の量産・商談準備から CRM 連携までを扱います。