AIでLINE運用｜LINE Harnessで重複配信を防ぐシナリオの作り方

AIでLINE運用を組むとき、シナリオを増やすだけでは十分ではありません。この記事は一般論だけでなく、LINE Harnessのコード、DBスキーマ、イベント処理を確認し、実際にタグ、自動化、シナリオ条件を組み替えた内容を基にしています。

実際の設定変更は2026年6月19日に行い、記事化にあたってLINE Harness OSSの公開リポジトリを2026年7月21日に再確認しました。リンク先は、仕様変更後も記事の根拠を追えるよう、確認した公開OSSコミットへ固定しています。

サービス資料、無料特典、無料相談などの導線が複数あると、1人のユーザーが短期間にいくつも選ぶことがあります。古いシナリオを抑える仕組みがなければ、似た案内が重なり、LINEがしつこく見えてしまいます。

対策の基本は、タグを「履歴」と「現在地」に分けることです。

過去の行動は分析用の履歴として残し、いま優先するフローと関心サービスだけを現在地タグとして最新行動に合わせて入れ替えます。古いシナリオが残っていても、現在地が一致しなければ次の配信を送らない設計にします。

このページで確認できることは、次の5つです。

• LINE Harnessのどの仕様が重複配信に影響するか
• message型ボタン単体とmessage_received自動化の違い
• 履歴タグと現在地タグの役割分担
• URLタップだけで切り替えられないときの代替フロー
• 古いシナリオを配信条件で抑える方法

まず使える：LINEの重複配信を点検するAIプロンプト

以下は、既存のLINE運用をAIと点検するときの開始用プロンプトです。リポジトリや設定ファイルをAIが読める環境を想定しています。

このプロンプトだけで本番設定が自動的に安全になるわけではありません。最初は読み取りだけで現状を整理し、変更案を人間が確認してから設定を変えてください。

あなたはLINE Harnessを使ったLINE公式アカウントのCRM・ステップ配信設計を点検するアシスタントです。

目的:
資料請求、無料特典、無料相談など複数の導線があるLINE運用で、
古いシナリオと新しいシナリオが重複して送られる原因を特定し、
履歴を消さずに最新行動を優先する設計案を作ってください。

最初に渡す情報:
- LINE Harnessリポジトリ: [パス]
- 対象シナリオ一覧: [資料 / 特典 / 相談など]
- 現在のタグ一覧と用途: [公開してよい範囲]
- シナリオ開始イベント: [リッチメニュー / URL / フォーム / メッセージなど]
- 配信条件: [各ステップの条件]
- 困っている重複例: [ユーザー行動の順番と届いた配信]

進め方:
1. まず読み取りだけで、tracked_links、entry_routes、rich menuのaction、automations、scenario_stepsの関係を一覧化する。
2. uri、message、postback、message_receivedの各経路で、タグの追加、削除、シナリオ開始ができる場所を確認する。
3. 過去の行動を残す履歴と、いま優先する導線を示す現在地を分ける。
4. 現在地タグが同じ軸で複数付く経路を洗い出す。
5. 新しい行動時に、古い現在地を外してから新しい現在地を付ける案を作る。
6. 古いシナリオが残る場合は、配信直前に現在地を確認して送らない条件を提案する。
7. 連続タップ、再訪、フォーム送信、配信予約済みのケースを含むテスト項目を作る。

制約:
- パスワード、アクセストークン、APIキー、認証コード、顧客データを会話へ貼らせない。
- 現時点の公式ドキュメントと、対象環境の実装を分けて確認する。
- 確認済み事実、観測結果、仮説、環境依存の調整を明確に分ける。
- 本番DB更新、権限変更、デプロイ、公開、削除は、変更表を示して人間の承認を得るまで実行しない。
- 実装にない機能や成果数値を推測しない。

最初の回答では、次だけを返してください:
- 現状確認チェックリスト
- 足りない入力
- 履歴と現在地の仮分類
- 推奨する点検順序
- 人間だけが行う作業

設定変更はまだ実行しないでください。

LINE Harnessとは

LINE Harnessは、LINE公式アカウントの配信・顧客管理・自動化を扱える、オープンソースのLINE CRMです。

ステップ配信、友だち・タグ管理、リッチメニュー、トラッキングリンク、IF-THEN自動化などを1つの運用基盤で扱えます。MCP ServerとSDKも公開されているため、AIにリポジトリの仕様を確認させながら、シナリオの作成・更新や運用状況の確認を進められる点が特徴です。

この記事ではLINE Harnessの機能全体ではなく、複数の資料・特典・相談シナリオが並行するときに、最新の行動を優先して重複配信を抑える設計に絞って解説します。

LINE Harnessの導入方法や、LINE Developers・LIFF・Webhook・Cloudflareの接続関係から確認したい方は、次の記事を先にご覧ください。

LINE Harnessで先に理解する3つの仕様

今回の設計で重要だったのは、同じ「ボタンを押す」操作でも、LINE Harness内部で通る経路が異なることです。検証時点の実装を整理すると、次のようになります。

message型ボタン自体はタグを付け替えない

ここは特に誤解しやすい点です。LINE Harnessのリッチメニューでmessage型を選んだとき、ボタンに設定できるのは送信テキストです。ボタンそのものにremove_tag、add_tag、start_scenarioを持たせるわけではありません。

公開OSSのリッチメニュー編集画面を見ると、message型の入力欄は送信テキストです。

ユーザーがボタンを押すと、そのテキストがLINEへ送られ、message_receivedイベントが発火します。そこで、キーワード完全一致の自動化を別に用意します。

message型ボタンを押す
↓
指定テキストが送信される
↓
message_received自動化が完全一致で反応する
↓
remove_tag → add_tag → start_scenario

したがって、正確な説明は「message型ボタンでタグを付け替える」ではなく、message型ボタンを入口にしたmessage_received自動化でタグを付け替えるです。

コード上でも、テキスト受信後にmessage_receivedを発火する処理と、完全一致条件およびremove_tag・add_tag・start_scenarioの実行は別の処理です。

なお、検証した実装ではpostbackは自動返信の照合後に処理を終え、message_received自動化は発火しません。表示上似ていても、現在地を入れ替える入口としてそのまま代用しないでください。

tracked linkは付けられるが、外せない

tracked linkには、クリック記録、1つのタグ追加、シナリオ開始の設定があります。一方、remove_tag用の設定欄や、複数アクションを自由に並べるactions欄はありません。また、tracked linkのタグ追加はmessage_received自動化を経由しません。公開OSSのクリック処理でも、タグ追加とシナリオ開始はありますが、タグ削除はありません。

そのため、資料URLをクリックした瞬間に、設定だけで古い現在地をすべて外すことはできません。tracked linkはクリック履歴や関心履歴を残す役割に寄せ、現在地の入れ替えはmessage_received側へ置きます。

シナリオ行が残っても、送信条件で抑えられる

LINE Harnessでは、進行中のシナリオ参加行がDBに残ることがあります。ただし、各ステップにはtag_existsやtag_not_existsに相当する条件を設定できます。対応する条件は、公開OSSの配信時条件の一覧と評価処理でも確認できます。

現在地が一致しないときはそのステップを送らず、次へ進めるか完了させます。これは古いシナリオを即時キャンセルする機能ではなく、ユーザーへ見える重複配信を抑える設計です。

LINE Harnessで重複しないシナリオを作る手順

ここからは、LINE Harnessで実際にシナリオを作る人向けの手順です。管理画面だけで作れる基本部分と、AI・MCPで補う設定を分けます。

手順1：シナリオを作る前に「開始」と「終了」を1行で決める

最初に、各シナリオを次の形式で書き出します。

シナリオ名: ECサービス資料フォロー
開始: 「EC運用代行の資料を受け取る」というmessageを受信
現在地: active_flow = service_material
関心: active_service = ec
終了: 別の現在地へ移った、または全ステップ完了

「誰に、何を、いつ送るか」だけでなく、「何が起きたら送らなくなるか」まで決めるのがポイントです。

手順2：管理画面で基本シナリオを作る

管理画面のシナリオ配信から、新規シナリオを作ります。

1. トリガーを選ぶ。今回のようにmessage_received自動化から明示的に開始するならmanualを選ぶ。
2. 配信方式を選ぶ。毎日指定時刻ならabsolute_time、登録からの経過時間ならelapsed、前ステップからの待ち時間ならrelativeを使う。
3. シナリオ名と説明を入れる。
4. ステップごとに、順序、配信時刻、テンプレートまたは本文、到達タグを設定する。
5. まだ本番ユーザーへ流さず、テスト用の友だちで内容と時刻を確認する。

公開OSSのシナリオ作成画面では、配信方式とトリガーを選びます。更新APIも配信方式の後変更を拒否するため、迷ったまま作らず、先に時刻基準を決めます。

手順3：message_received自動化で現在地を入れ替える

次に、自動化画面でイベントをmessage_receivedにし、条件とアクションを設定します。以下は構造を理解するための例で、タグIDとシナリオIDは自分の環境の値へ置き換えます。

{
  "conditions": {
    "keyword_exact": "EC運用代行の資料を受け取る"
  },
  "actions": [
    { "type": "remove_tag", "params": { "tagId": "<旧フローのタグID>" } },
    { "type": "remove_tag", "params": { "tagId": "<旧サービスのタグID>" } },
    { "type": "add_tag", "params": { "tagId": "<資料フローのタグID>" } },
    { "type": "add_tag", "params": { "tagId": "<EC関心のタグID>" } },
    { "type": "start_scenario", "params": { "scenarioId": "<資料フォローのシナリオID>" } }
  ]
}

actionsは配列の上から1件ずつ実行されるため、先に古い現在地を外し、その後で新しい現在地を付け、最後にシナリオを始めます。

ただし、1つのactionがエラーになっても、残りのactionは続けて実行され、成功と失敗が混在するとログはpartialになります。削除済みの参照先や不正なパラメータが混じっていても後続処理まで進む可能性があるため、テストでは「シナリオが始まった」だけでなく、自動化ログがsuccessで、全actionが成功したことを確認します。

また、同じmessage_receivedに一致する有効な自動化が複数あれば、先頭の1件だけでなく、それぞれが評価されます。ボタンの送信テキストは導線ごとに重複させず、公開前に同じkeyword_exactを持つ自動化がないか確認します。

条件はkeywordよりkeyword_exactを優先します。部分一致だと、通常の会話に同じ語句が含まれただけで現在地が切り替わる可能性があるためです。

手順4：各ステップに「送ってよい現在地」を設定する

ここが重複配信を抑える要所です。各ステップへ次の条件を設定します。

conditionType: tag_exists
conditionValue: <このシナリオの現在地タグID>
nextStepOnFalse: null

公開OSSでは、基本シナリオをまとめて作るcreate_scenarioと、既存ステップへ条件を追加できるmanage_scenariosのupdate_stepが分かれています。

AIへ依頼するときは、次のように指示します。

まずmanage_scenariosのgetで対象シナリオと全ステップを読み取ってください。
変更案として、各ステップへ以下を付ける差分表を作ってください。
- conditionType: tag_exists
- conditionValue: <現在地タグID>
- nextStepOnFalse: null

まだ更新せず、対象scenarioId、stepId、変更前、変更後を提示してください。
私が承認した後だけupdate_stepを実行し、最後にgetで再取得して検証してください。

公開OSSの管理画面では、通常のステップ編集欄に順序、時刻、テンプレート、本文、到達タグはありますが、確認したコミットでは配信条件の入力欄はありません。ステップ編集画面の実装で見つからない場合は、MCPのmanage_scenariosまたはAPIを使います。

手順5：1ステップ1条件の制約を考慮する

LINE Harnessのシナリオステップが持つconditionTypeとconditionValueは1組です。たとえば「資料フロー中、かつ、ECに関心あり」の2条件を同じステップへ直接ANDで置く形ではありません。

どのタグを1条件に選ぶかは、シナリオの単位で決めます。

今回のように「特典や相談へ移ったら資料フォローを止める」が主目的なら、active_flowを優先します。ECからSNSへ切り替えたときにもEC側を止めたいサービス別シナリオなら、active_serviceを使います。

2軸の一致が必須なら、「資料フロー × EC」のような組み合わせ現在地タグを1つ用意するか、コード側に複数条件ポリシーを追加します。

手順6：連続行動でテストする

単体のシナリオが届くだけでは合格ではありません。少なくとも次の順番をテストします。

最後に、友だちのタグ、自動化ログ、シナリオ参加状態、送信ログを一緒に確認します。画面上のタグだけ見て終わると、古いシナリオの参加行や条件スキップを見落とします。

LINE Harnessで詰まりやすい症状と確認先

シナリオ以外の運用（複数アカウント・BAN検知・配信方式）は運用編で扱っています

この切り分け順なら、「メッセージの内容が悪い」のか、「シナリオが始まっていない」のか、「始まっているが条件で抑制された」のかを分けて確認できます。

結論：LINE Harnessでは履歴を残し、現在地だけを自動化で入れ替える

LINEの重複配信を抑えるには、行動情報を1種類のタグへ詰め込まないことが重要です。

履歴には、資料への関心、特典受け取り、フォーム送信、リンククリックなどを残します。

現在地には、「サービス資料のフォロー中」「特典案内中」「特典受け取り後」「無料相談中」といったフローと、EC、SNS、AI導入などの関心サービスを持たせます。

新しい導線が選ばれたら、同じ軸の古い現在地を外してから、新しい現在地を付けます。

なぜLINEのステップ配信が重複するのか

導線ごとにシナリオを作ると、各シナリオは自然に始められます。

しかし、ユーザーは1本の導線だけを進むとは限りません。

サービス資料を見る
↓
別サービスの資料も見る
↓
無料特典を受け取る
↓
無料相談へ進む

新しいシナリオを始める処理だけがあり、古い関連シナリオを外す、または抑える処理がなければ、複数のフォローが並行します。

これはLINE固有の課題ではありません。一般的なMAでも、ワークフローの登録解除や抑制、終了条件を使って重複を避けます。

HubSpotでは、条件に応じたワークフローからの登録解除や抑制を設定できます。Customer.ioでも、コンバージョンやフィルター条件を満たした人をキャンペーンから退出させる終了条件があります。

• HubSpot：ワークフローの登録・登録解除設定
• Customer.io：キャンペーンの終了条件

LINE運用でも、「次に何を送るか」だけでなく、「どの古いフォローを送らないか」を同時に設計する必要があります。

履歴タグと現在地タグをどう分けるか

タグの命名より先に、役割を決めます。

履歴に残す情報

履歴として残す候補は、次の通りです。

• 資料ボタンを選んだ
• 特典を受け取った
• 相談フォームへ進んだ
• フォームを送信した
• 特定のリンクをクリックした

履歴は複数あっても問題ありません。過去の関心や行動経路を分析するための情報だからです。

現在地として1つに絞る情報

現在地は、配信制御に使います。

現在地が同じ軸で複数付くと、複数の配信条件を同時に満たします。そこで、新しい現在地を付ける前に、同じ軸の古い現在地を外します。

図のように、最新行動を中心に「残す履歴」「1つに絞る優先フロー」「1つに絞る関心サービス」「送信を止める配信条件」を分けると、運用ルールを説明しやすくなります。

LINE Harnessで最新行動をどのイベントに置くか

現在地を入れ替えるには、タグを外せるイベントが必要です。

今回検証したLINE Harness環境では、クリック追跡リンクやLINE流入リンクから、タグを付けたりシナリオを始めたりできました。一方、リンクのDB設定だけでは、複数の現在地タグを外す処理を持てませんでした。

そこで、リッチメニューのmessage型ボタンから送られるテキストと、それを受けるmessage_received自動化を切り替え地点にしました。

LINE公式のMessaging APIでは、リッチメニューのメッセージアクションを使うと、ユーザーからのメッセージに対応するイベントがBotサーバーへ送られます。

• LINE Developers：リッチメニューを試す

message_receivedを起点にすれば、手元の自動化では次の処理を順に実行できました。

古い現在地タグを外す
↓
新しい現在地タグを付ける
↓
新しいシナリオを始める

重要なのは、message型ボタン単体がこの処理を行うのではないことです。また、これは検証時点のLINE Harness実装に基づく結果であり、すべてのLINE運用ツールに共通する仕様でもありません。アップデート後は、ボタン設定、イベント発火、自動化アクションを再確認してください。

URL流入では「受け取る」の1タップを挟む

記事や広告からLINEへ入った瞬間に、古い現在地を外せない場合があります。

そのときは、流入直後に特典を自動配布するのではなく、「無料特典を受け取る」のようなメッセージ送信型ボタンを1回押してもらいます。

記事からLINEへ流入
↓
特典案内を表示
↓
「無料特典を受け取る」をタップ
↓
古い現在地を外す
↓
特典受け取り後の現在地を付ける
↓
特典配布とフォローを開始

1タップ増えることはデメリットです。一方、特典受け取りでは自然な意思確認になり、運用側も最新行動を確定できます。

古いシナリオを配信条件で止める

現在地タグを入れ替えても、古いシナリオの実行行が残ることがあります。

そこで、古いシナリオの各ステップに「現在地が一致しているか」という条件を置きます。

たとえば、EC資料のフォローは「関心サービスがECであること」、特典案内は「優先フローが特典案内中であること」を条件にします。

ユーザーが別の導線へ進むと、古い現在地が外れます。古いシナリオが次の実行時刻を迎えても、条件を満たさないため送られません。

この方法は、シナリオ自体を強制終了する仕組みではありません。完全なキャンセルやタイマーの再起動が必要なら、シナリオのカテゴリと上書きポリシーをコード側で持つ設計を検討します。

AIに確認させること、人間が決めること

AIは、実装上できることを洗い出す作業に向いています。

AIが実装を読めても、ユーザー体験の優先順位は自動では決まりません。

「資料を見た後に特典へ進んだ人へ、どちらの案内を優先するか」「相談へ進んだ後に資料確認を送るか」といった判断は、運用方針として人間が決めます。

実装前後のチェックリスト

実装前

• 並行して走り得るシナリオを一覧化した
• 履歴と現在地を分けた
• 現在地の軸ごとに許容するタグ数を決めた
• 各イベントでタグを追加・削除できるか確認した
• 古いシナリオを抑える条件を決めた
• 本番変更前に、変更対象とロールバック手順を確認した

実装後

• サービス資料から別サービス資料へ移るテストをした
• サービス資料から特典へ移るテストをした
• 特典案内中に無料相談へ移るテストをした
• 現在地が同じ軸で複数付いていないことを確認した
• 古い配信が条件不一致で止まることを確認した
• 履歴やクリック情報が消えていないことを確認した
• 認証情報、顧客情報、内部IDをログや記事へ出していないことを確認した

よくある失敗

履歴タグを消してしまう

重複を止めるために過去のタグまで消すと、分析やセグメントに使える情報を失います。削除するのは現在地に限定します。

URLクリックやmessage型ボタンだけで全部を切り替えようとする

LINE Harnessのtracked linkではタグ追加やシナリオ開始はできても、複数タグの削除はできません。また、message型ボタン単体にもタグ操作はありません。ボタンから送られたテキストをmessage_received自動化へつなぎ、必要なら自然な確認タップを挟みます。

古いシナリオが残ることを見落とす

新しい現在地を付けただけでは、古いシナリオが送信を続ける可能性があります。古いシナリオ側にも現在地の条件を置きます。

AIに本番変更まで一気に任せる

AIには、読み取り、関係整理、変更案、テスト設計を任せやすい一方、本番DB更新、権限変更、配信開始、削除は人間の承認を挟むべきです。

まとめ

LINE Harnessを使ったAIでのLINE運用で重複配信を防ぐには、最新行動の優先順位をタグで表現します。

過去の行動は履歴として残し、いま優先するフローと関心サービスだけを現在地として入れ替えます。リンクだけで現在地を切り替えられない場合は、メッセージ送信型のタップを意思確認として使います。

古いシナリオを完全に削除できなくても、配信直前に現在地を確認すれば、最新行動と合わない案内を抑えられます。

AIは実装と設定の関係を確認する役、人間はどの行動を優先するかを決める役。この分担で、LINE運用を効率化しながら、誤配信や過剰なフォローを減らしやすくなります。