Lステップの API 連携・Webhook 転送で足りるか、自前の Webhook に切り替えるか。判断の基準と切り替えた記録
想定読者は、LINE 連携を実装・運用する技術者です。経営判断の観点 (解約で消えるもの、契約の注意、移行の進め方) は、記事「Lステップを解約する前に確認すること」にまとめています。
「Lステップは使い続けたい。でも、友だち情報を自社のシステムにも持ちたい」「登録した人がどの広告から来たかを、自社のデータベースで追いたい」。LINE 集客をしている会社から、こういう相談をよく受けます。
答えは三つに分かれます。Lステップの API 連携や Webhook 転送で足りる場合、Lステップを残したまま LINE ログインや LIFF で自社のデータベースにデータを入れる場合、そして自前の Webhook に切り替える場合です。境目は一つで、LINE のイベントを最初に受け取るのが Lステップのままでよいか、自社でなければならないかです。
この記事では、まず Lステップ側の連携手段を整理し、どこまでがその範囲で済むかを書きます。そのうえで、私たちが開発を担当している人材紹介会社で、Lステップから自前の Webhook に切り替えたときの手順と、切替で初めて起きた問題を書きます。構成は Cloudflare Workers + D1 + R2 です。
Lステップの連携手段は 3 つあり、向きが違う
公式サイトの説明をもとに整理すると、次の 3 つです。
| 手段 | 向き | 取れるもの・できること | 費用 (公式ページより) |
|---|---|---|---|
| Webhook 転送 | Lステップ → 外部 | 友だち追加やメッセージ受信など、LINE 上の動きを外部 URL へ転送する。Lステップ内部のデータ (タグ・友だち情報) は含まれない | フリープランからオプションで申し込める |
| API 連携 | 外部 → Lステップ | 外部システムから、Lステップ内の友だち情報・タグ・対応マークを作成・取得・更新・削除し、シナリオ配信を開始できる | Webhook 利用中なら月額 5,500 円 (税込) の追加 |
| Webhook アクション | Lステップ → 外部 | Lステップ側のアクションを起点に、登録した URL へ情報を送る | 2025 年後半に追加された機能 |
ポイントは、LINE からのイベントの一次受けは Lステップのままだということです。LINE Messaging API の Webhook URL はチャネルに 1 つしか設定できず (公式ドキュメント)、Lステップを連携した時点で、その 1 枠は Lステップの受信 URL で埋まります。自社のシステムは LINE から直接イベントを受け取れず、Webhook 転送で「Lステップが受けたものを横流ししてもらう」立場になります。転送されるのは LINE 上の動きだけで、形式・タイミング・範囲は Lステップ側の仕様に従います。外部側の実装はサポート範囲外と明記されています。
3 つの手段はどれも、この「1 枠を Lステップが持っている」構造の上に成り立っています。API 連携を足しても、自社が一次受けになるわけではありません。
API 連携で足りるのは、Lステップが主役のままでよいとき
次の 3 つに当てはまるなら、API 連携 (と Webhook 転送) で十分です。
- 配信・タグ・シナリオの主役が、今後も Lステップでよい。 自社システムは「外からタグを付ける」「外部の出来事をきっかけに配信を始める」程度の関わり方で済む。
- Lステップの内部データで困っていない。 友だち情報はツール内にあるが、必要なときに API で取れれば足りる。
- 月額の追加が、自前で作る費用より安い。 受け口を作って保守する工数と比べて、月数千円の追加の方が合理的な規模。
この場合は、自前で Webhook を受ける必要はありません。Lステップの設定と、外部側の小さな連携だけで済みます。
Webhook の枠を取らなくても、LINE ログインと LIFF なら自社 DB にデータを入れられる
Lステップが Webhook の 1 枠を持っていても、自社のデータベースに応募者のデータを貯める方法はあります。LINE ログインと LIFF です。私たちが並走期間に取っていた構成がこれで、Lステップの配信とアンケートはそのまま動かしながら、登録の記録だけを先に自社側へ移しました。
- LINE ログイン (OAuth 2.1 / OpenID Connect)。 案内ページの友だち追加ボタンの先に LINE ログインを挟みます。
bot_prompt=aggressiveを付けると、認可と同時に友だち追加も成立します。コールバックで userId が確定するので、その場で広告のクリック ID や UTM とひも付けて自社 DB に記録できます (登録を広告の成果として送る方法は記事「LINE 登録を広告の成果として測る方法」に書いています)。Webhook には触らないので、Lステップ側は何も変わりません。 - LIFF。 LINE 内で開くページ (入口、診断、アンケート) では LIFF SDK が userId を返します。アクセストークンを API 側で検証して userId を確定し、回答を自社 DB に保存します。応募者から見ると LINE の中で完結し、Lステップのフォームと使い勝手は変わりません。
この方法で取れるのは、自社のページの上で起きたことです。登録とその流入元、診断やアンケートの回答は自社 DB に残ります。取れないのは、トークのメッセージや画像、自社のページを経由しない友だち追加、ブロック、返信といった LINE 側のイベントで、これらは Webhook を受けている Lステップにしか届きません。
API 連携との違いは、データの持ち主です。API 連携は「Lステップの中のデータを外から触る」のに対し、LINE ログインと LIFF は「最初から自社 DB に書く」ので、後で Lステップをやめても記録は残ります。「配信は Lステップでよいが、データは自社に残したい」という段階なら、この構成で止めるのも選択肢です。
足りなくなるのは、LINE のイベントを自社が最初に受け取る必要が出たとき
前の節のとおり、Webhook の 1 枠は Lステップが持っています。Lステップが受けている限り、自社が LINE から直接イベントを受けることはできず、転送された分だけを後追いで受け取ることになります。この枠を自社に移すのが「切替」で、移した瞬間に Lステップ側は受信できなくなります。つまり、一次受けは Lステップか自社のどちらか一方で、両取りはできません。
人材紹介会社では、次の要件が出た時点で「転送では足りない」と判断しました。
- 受信画像の保存。 応募者がトークに送った写真を自社の管理画面で見たい。画像本体は Webhook で受けたメッセージ ID を使って LINE から取得するが、一定期間で消える。転送経由の遅延や欠落があると取れない。
- 自社のページを経由しない友だち追加と、ブロックの把握。 広告経由の登録は LINE ログインで取れますが、QR コードや LINE 内の検索からの友だち追加、ブロック (unfollow) は LINE 側のイベントでしか分かりません。友だちの全体像と離脱を自社 DB で持つには、follow / unfollow を自社で受ける必要があります。
- 返信の検知による業務ステータスの遷移。 応募者から返信が来たら「対応中」に自動で進め、担当者に通知したい。message イベントを自社で直接受ける必要がある。
- 自動応答の内容を自社の DB で決めたい。 アンケート回答済みかどうかで返す内容を変える、といった分岐は Lステップのキーワード応答では組めない。
flowchart LR
subgraph after ["切替後: 一次受けは自社"]
direction LR
line2(["LINE Platform"]) -->|webhook| api["自社 API<br/>(Workers)"]
api --> d1[("D1")]
api --> r2[("R2")]
api -->|reply / push| line2
end
subgraph before ["切替前 (並走中): 一次受けは Lステップ"]
direction LR
line1(["LINE Platform"]) -->|webhook| lstep["Lステップ"]
lstep -->|"Webhook 転送<br/>LINE 上の動きのみ"| ext1["自社システム"]
ext1 -->|"API 連携<br/>タグ・友だち情報"| lstep
user1(["応募者"]) -->|"LINE ログイン / LIFF<br/>自社ページ上の登録・回答"| ext1
ext1 --> d0[("自社 DB")]
end
この構成の切替は、Webhook URL の差し替え 1 回で完了します。そして、差し替えた瞬間から Lステップは一切のイベントを受け取れなくなります。Lステップの自動応答・タグ付け・シナリオ配信は、すべて Webhook に依存しているからです。「半分ずつ」はできません。
切り替えた記録: 棚卸し → 並走 → 切替
一次受けは Lステップか自社のどちらか一方で、切替中に届いたイベントはもう片方には届きません。やり直すと、その間のタグ付けやシナリオが欠けます。だから順番を決めて進めました。
1. Lステップに依存している機能を全部書き出す。 出てきたのは、自動応答 (あいさつ・キーワード応答)、タグ付け、配信シナリオ (登録後の自動フォロー)、アンケートフォーム、リッチメニューの 5 つです。それぞれに移行先を決め、決まらない行があるうちは切り替えませんでした。
2. 並走中に、受け口と移行先を先に作る。 Lステップを動かしたまま、自社 API に Webhook のエンドポイントを実装し、LINE ログイン経由の登録計測、運営向けの管理画面、LIFF のアンケートフォームを順に用意しました。「LINE ログインと LIFF」の節に書いた構成です。この時点では Webhook URL はまだ Lステップのままで、登録の記録と回答だけが先に自社 DB に貯まり始めます。
3. 切替当日の手順。 作業そのものは 1 日でした。
- Messaging API チャネルのチャネルシークレットを Secrets に登録し、API にデプロイする (Login チャネルのシークレットとは別の値)
- 署名を自前で計算したテストイベントを本番の Webhook URL に POST し、200 が返ることを確認する。鍵はこちらにあるので、本物の LINE を待たずに検証できる
- LINE Developers の Messaging API 設定で Webhook URL を自社 API に変更し、「検証」ボタンで疎通を確認する。「Webhook の利用」は ON のまま
- テスト用アカウントからトークに画像を送り、管理画面に表示されることを確認する
この手順 3 の瞬間から、Lステップはイベントを受け取れません。手順 1〜2 を済ませてから 3 に進むのは、そのためです。
4. 切替後に新しい機能を足す。 自動フォローの拡張や提携先向けの画面は、切替の後に積みました。切替と新機能を同時にやると、不具合の原因が切り分けられないからです。
なお、切替前のトーク履歴と受信画像は引き継げませんでした。1:1 トークの履歴を取得する API は存在せず、画像本体も一定期間で LINE 側から消えるためです。自社の受け口に貯まるのは、切替以降に届いた分だけです。
切替で初めて起きること: 友だち追加の Webhook は、登録 API より先に届く
受け口の実装そのもの (署名検証、応答の返し方、冪等化) は LINE の公式ドキュメントと一般的な Webhook の作法で足りるので、ここでは切替で初めて表に出た問題を 1 つだけ書きます。
LINE ログインや LIFF で登録を取っている構成では、切替後に follow イベントも自社に届くようになります。すると、友だち追加 (follow) が登録 API の呼び出しより構造的に先に届きます。友だち追加は LIFF ページの読み込み前に成立するからです。並走中は follow が Lステップに行っていたので起きず、切替で初めて表に出ました。
最初の実装では、Webhook 側が先に友だちの仮行を作り、後から来た登録 API が「既存行あり」と判断して広告の帰属 (クリック ID や UTM) を書かない、という取りこぼしが実際に 2 件起きました。対策は、どちらが先に着いても同じ状態に収束する形にすることです。Webhook が先なら仮行を作り、登録 API が後から来たら仮行を引き取って帰属を書く。登録 API が先なら通常どおり作り、Webhook は既存行に触らない。「片方が行を作り、もう片方が自分の担当フィールドを書く」と決めておけば、到着順に依存しません。
切替前に受け口を作るときは、この到着順を前提に登録の処理を設計しておくと、切替当日に慌てずに済みます。
切替後も取り込めないもの
- 過去の会話。 1:1 トークの履歴を取得する API は無いので、Webhook 有効化後に届いた分だけが貯まります。
- 公式アカウントの管理画面から人が送った返信。 オペレーターの送信は Webhook に配信されません。受信メッセージの記録は相手の発言だけの片側ログになり、「こちらが連絡したか」は自社の API 経由の送信記録しか残りません。
作り直して、一番良くなったこと
一番大きかったのは、すべてのデータを AI で横断して分析できるようになったことです。
切替前は、応募者の情報は Lステップの中、広告の成果は広告の管理画面、ページ上の行動はアクセス解析の中と、データが別々の場所にありました。切替後は、登録と流入元、アンケートの回答、トークの受信、返信、ブロック、追客の送信と反応が、すべて自社の D1 に時系列で残ります。広告の管理データとアクセス解析はそのままですが、自社 DB を軸に突き合わせられるようになりました。
これで、「なぜこの週は登録が減ったのか」「この職種向けの広告は、なぜ登録率が低いのか」といった問いごとに、AI に各データを直接照会させて原因を探す使い方ができます。分析画面を作り込むのではなく、問いが出たときにその場でデータを引いて答える方式です。この会社のマーケティングは、この横断分析で大きく改善しました。具体的な構成と実例は、別の記事で書きます。
Lステップの API 連携や Webhook 転送でも、タグや友だち情報を外に出すことはできます。ただ、トークの受信や返信、ブロックといった LINE 側のイベントを自社 DB に時系列で持てるのは、一次受けが自社にあるからです。横断分析の土台は、ここで決まりました。
判断の基準
| 状況 | 選ぶもの |
|---|---|
| 配信・タグ・シナリオの主役は Lステップのまま。外部から少し操作したいだけ | API 連携 + Webhook 転送 |
| 配信は Lステップのままでよいが、登録の流入元や回答のデータは自社に残したい | LINE ログイン + LIFF で自社 DB に書く (Webhook は Lステップのまま) |
| LINE のイベントを自社が最初に受け取る要件がある (受信画像、自社ページを経由しない友だち追加・ブロック、返信検知、DB に基づく応答) | 自前の Webhook に切り替える |
| 自前にするが、全部を一度に作れない | 並走して受け口と移行先を先に作り、最後に URL を差し替える |
自前にするなら、切替の前に「登録の到着順を前提にした受け口」と「依存機能の移行先の一覧」をそろえてください。切替そのものは 1 回の設定変更ですが、URL を戻しても、切替中に届いたイベントは Lステップに届きません。また、Lステップを解約した後は同じ LINE 公式アカウントで再連携できないので (利用規約)、解約は切替が安定してからにします。ツールのまま使う段階から、最初から自社で作る段階までの判断の全体像は、LINE の集客と顧客管理の仕組みにまとめています。
移行の全体像と、その後に作った集客の仕組みは開発事例に、経営者向けの判断 (解約で消えるもの・残るもの、契約の注意点) は記事「Lステップを解約する前に確認すること」にまとめています。集客のデータが自社の手元にどこまで残っているかは、無料の集客効率AI診断でも確かめられます。
当社では、既製のツールで始めた LINE 集客を、事業の成長に合わせて自社の基盤へ移す開発を、計測・顧客管理・追客の自動化まで一体でご支援しています。お問い合わせフォーム、または LINE 公式アカウントからお気軽にどうぞ。
