LINEのWebhookは1か所にしか届かない｜配信ツールとCRM連携の両立のさせ方

LINE公式アカウントの Messaging API で、友だち追加やメッセージを受け取る Webhook URL は、1つのチャネルに1つしか設定できません。配信ツールがすでにそこを受けているアカウントで顧客管理（CRM）ともつなぐには、受け手を1つに決めてそこから CRM へ渡すか、CRM の側は LINEログインや LINEミニアプリの別のチャネルで受けるか、受け手を CRM の製品に替えるかを選びます。分かれ目は、CRM に会話や友だち追加まで入れたいのか、LINE で名乗った人とユーザーIDを結ぶだけでよいのか、です。

当社は LINE公式アカウントの運用と、LINE とほかのシステムとの連携を支援している会社です。この話を今書くのは、CRM・MA の製品の LINE の設定手順に、Webhook URL を自社の製品に向けるよう書いているものがあり、配信ツールが受けているアカウントでその手順を進めると、その時点からツールに Webhook が届かなくなるからです。ツールと製品のどちらが優れているかではなく、1つしかない受け口を誰が持つかを、つなぐ前に決めておく話として書きます。受け口の作りの細部（署名・再送・順序）は「Salesforce と LINE をつなぐ：何を・どの向きで・誰のIDで流すか」と「LINE × Slack連携」に、つなぎ方の種類と費用は「LINEと今の顧客管理をつなぐ3つの作り方と、費用が決まる所」に書いたので、ここでは受け手がすでに埋まっているときの分け方に絞ります。

例は1つに決めて通します。架空の会社「みどり設計」は、LINE公式アカウントの配信に LINE配信ツールを使っていて、LINE Developers コンソールの Webhook URL にはツールの URL が入っています。そこへ、LINE で届く問い合わせと、LINE で名乗ったお客様を、社内の顧客管理にも入れたい、という話が出た、という設定です。会社名は、A の節で触れる当社のデモ（社内チャンネルへの転送）と同じ架空のものです。

Webhook URL の欄は1つ。製品をつなぐ手順が、その欄を書き換える

LINE Developers の「よくある質問」は、Webhook URL に複数のボットサーバーのエンドポイントを設定できるか、という問いに、できない、1つの Messaging API チャネルにつき1つだけ、と答えています（よくある質問）。設定する場所は、LINE Developers コンソールのチャネルの［Messaging API設定］タブにある［Webhook URL］です。HTTPS で、自己署名の証明書は使えず、［検証］を押すとイベントの入っていない（events が空の）リクエストが届きます（ボットを作成する・Webhook URLを検証する）。

製品をつなぐ手順も、この欄を書き換えます。CRM・MA の製品の公式の手順を見ると、LINE をつなぐ途中で、製品が示す URL を LINE の Webhook URL に貼るよう書いているものがあります。手順に書かれている Webhook の扱いを、製品ごとに並べると次のとおりです。

Salesforce・Dynamics 365・Braze と Treasure Data の取り込みは、手順どおりにつなぐと、その時点で Webhook の送り先が製品の側に変わります。LINE のプラットフォームが送るのは Webhook URL に入っている1か所だけなので、それまで受けていた配信ツールには、友だち追加もメッセージも届かなくなります。配信ツールのどの機能がこの Webhook を使っているかはツールごとに違い、この記事からは言えないので、確かめる相手と項目は後の「誰に何を確かめるか」の図にまとめました。表に無い製品も、手順の中に Webhook URL の欄が出てくるかどうかが手がかりになります。ただし Messaging API には Webhook URL を設定する API もあり、チャネルの情報を渡した製品が、手順に書かずに設定することもありえます（Messaging API リファレンス「WebhookエンドポイントのURLを設定する」）。製品をつないだ後は、［Messaging API設定］タブの Webhook URL を開いて、向き先が変わっていないかを確かめます。

あいさつメッセージと応答メッセージは、LINE Official Account Manager で設定する自動の返事で、Messaging API のチャネルを作った時点では有効になっています。LINE Developers も、Messaging API で初めてボットを作るときはオフにしておくよう勧めています。LINE Official Account Manager であいさつメッセージを設定していれば、製品の手順でこれをオフにした時点で、友だち追加時のあいさつも送られなくなるので、配信の担当と一緒に決めます。

先に決めるのは、CRM に何を入れたいか

Webhook で届くのは、LINE公式アカウントで起きた出来事です。1対1のトークでは、メッセージ、送信取消、フォロー（友だち追加とブロック解除）、フォロー解除（ブロック）、ポストバックなどのイベントが届きます（メッセージ（Webhook）を受信する）。一方、LINE で名乗ったお客様を顧客管理の誰かと結ぶだけなら、Webhook は要りません。LINEログインや LINEミニアプリで本人がログインしたときに受け取るユーザーIDを、顧客の行に書けば足ります。

そこで、どの形にするかの前に、みどり設計が CRM に入れたいものを3つに分けます。1つ目は問い合わせの会話そのもの（誰が、いつ、何と送ったか）で、これはメッセージイベントでしか届きません。2つ目は友だち追加とブロックの記録で、フォローとフォロー解除のイベントで届きます。3つ目は、LINE で名乗った人と顧客管理の人の結び付けで、会員登録やフォームの回答のときにログインで受け取るユーザーIDで足ります。1つ目か2つ目を CRM に入れたいなら、Webhook を誰かと分け合う A か、受け手を替える C になり、3つ目だけなら B で足ります。

今の友だち全員のユーザーIDが要るだけなら、もう1つ道があります。友だち追加したユーザーの一覧を取得するエンドポイントで、友だち全員のユーザーIDを取得できます。ただし、使えるのは認証済アカウントかプレミアムアカウントだけです（ユーザーIDを取得する）。一覧は取った時点の友だちで、いつ誰が追加したかの出来事ではなく、特定の人がどの経路で友だち追加したかも Messaging API では確かめられません（よくある質問）。

A 受け手を1つにして渡す：渡す側が引き受ける3つのこと

A は、Webhook URL を1か所にしたまま、そこで受けたイベントを CRM にも渡す形です。CRM に入れられるものは3つの形の中でいちばん広く、会話も、友だち追加・ブロックも、名乗った人の結び付けも入ります。受け手を持つのは、配信ツールが受けたままツールの機能で CRM へ渡すなら配信ツールの会社で、自社で中継を置いて Webhook URL を中継に向け、中継から配信ツールと CRM の両方に渡すなら自社です。

受け口一般の作り（署名の検証、保存してすぐ200を返すこと、重複と順序の扱い）は「LINE × Slack連携」と「Salesforce と LINE をつなぐ」に書きました。ここでは、1か所で受けて2つの宛先に渡すときに、受け手が代わりに負うことを3つに絞ります。

1つ目は、本文と署名を変えずに渡すことです。LINE は、本文をチャネルシークレットで HMAC-SHA256 にかけた署名を x-line-signature ヘッダーに入れて送り、受け手は本文の文字列を変えずに同じ計算をして比べます。公式は、ボットサーバーの手前で Webhook を変更した、JSON を整形した、などを署名が合わないよくある失敗に挙げています（Webhookの署名を検証する）。中継の先の配信ツールが署名を確かめる作りなら、中継はちょうどこの「手前」に当たるので、届いた本文と x-line-signature をそのまま渡します。

2つ目は、宛先ごとの送り直しです。LINE の再送は既定で無効で、［Webhookの再送］を有効にし、かつ受け手が200番台を返さなかったときだけ行われます（メッセージ（Webhook）を受信する）。LINE から見える受け手は中継だけなので、中継が200を返したあとで CRM への送信が失敗しても、LINE はもう送り直しません。中継は受けたイベントを保存しておき、失敗した宛先にだけ送り直します。

3つ目は、応答する宛先を1つに決めることです。メッセージやフォローのイベントに付く応答トークンは一度しか使えず、Webhook を受けてから1分以内に使う必要があります（Messaging API リファレンス「応答トークン」）。配信ツールと CRM の両方が応答する作りだと、後から使った方は送れません。みどり設計なら、友だち追加のあいさつや自動の返事は配信ツールが応答し、CRM はイベントを記録するだけにします。CRM の画面から担当者が返すときは応答ではなくプッシュメッセージになり、プッシュメッセージは通数に数えられます（Messaging APIの料金）。

受け手が1か所で受けて転送し、転送先で返した返信が LINE に戻る、という A の形は、架空の会社・データで作った当社のデモで触れます。転送先は CRM ではなく社内のチームチャットのチャンネルです。

枠の中はスクロールできます。画面いっぱいで試すときは別のタブで開く。

デモの中で LINE の仕様に当たるのは、Webhook の再送が既定で無効で、有効にしたときだけ200番台を返さなかったイベントが再送されることと、再送でもイベントIDが同じことです。担当者を決めてから返す作りは、デモの画面にあるとおり運用ルールの一例です。

B 別のチャネルで受ける：LINEログイン・LINEミニアプリは同じプロバイダーに

B は、Webhook URL は配信ツールのままにして、CRM の側は LINEログインか LINEミニアプリのチャネルで受ける形です。CRM に入るのは、名乗った人と LINE のユーザーIDの結び付けです。みどり設計なら、問い合わせのフォームや会員登録の画面に LINEログインを付け、本人がログインしたときに受け取るユーザーIDを、フォームの回答と一緒に顧客管理に書きます。LINE の中でこうした画面を開くなら LIFF（LINE Front-end Framework。LINEヤフーが提供するウェブアプリの基盤）を使い、LIFF のアプリは LINE Developers コンソールで LINEログインのチャネルに追加します。新しく作るなら LINEミニアプリとして作るよう公式は勧めていて、LINEミニアプリも LIFF の上で動くウェブアプリです（LIFFアプリをチャネルに追加する・LINEミニアプリとは）。

この形で欠かせないのが、チャネルを置くプロバイダーです。プロバイダーは LINE Developers に登録するサービスの提供者で、会社としてサービスを提供するなら会社の名前で作り、その配下に Messaging API や LINEログインのチャネルを作ります。LINE のユーザーIDは、同じ人でもプロバイダーごとに違う値になり、同じプロバイダーの中ならチャネルの種類にかかわらず同じ値になります。LINEログインのチャネルを LINE公式アカウントの Messaging API チャネルと同じプロバイダーに置けば、ログインで受け取ったユーザーIDが、配信ツールが持っている友だちのユーザーIDと同じ値になり、CRM の顧客と配信の相手を同じIDで結べます。別のプロバイダーに置くと値が一致せず、ユーザーIDで同じ人だと確かめることはできません（ユーザーIDを取得する・LINE Developersコンソールの概要）。

プロバイダーを切り替えるとユーザーIDがどう変わるかは、当社のデモで確かめられます。架空の教室と会社のデータで作ったもので、みどり設計とは別の架空の名前です。

枠の中はスクロールできます。画面いっぱいで試すときは別のタブで開く。

デモの中で LINE の仕様に当たるのは、ユーザーIDがプロバイダーごとに違い、同じプロバイダーならチャネルの種類によらず同じ、という点です。同意画面は文言を公式にそろえた簡素なイメージで、LINE の実際の画面ではありません。ログインで受け取れる項目と同意の細部は「LINEログインで取得できる情報」にまとめています。

プロバイダーは後から変えられません。LINE Official Account Manager で作った LINE公式アカウントで Messaging API を使い始めるときにプロバイダーを選び、一度選ぶと別のプロバイダーに変えることも、Messaging API との連携を解くこともできません。作ったチャネルも、後から別のプロバイダーへは移せません。公式は、チャネルとプロバイダーを別々の個人や企業が管理している場合などを、特に注意が要るケースとして挙げています。プロバイダーの配下に新しいチャネルを作れるのは、そのプロバイダーの Admin 権限を持つ開発者です（Messaging APIを始めよう・LINE Developersコンソールの概要・権限を管理する）。B を選ぶなら、みどり設計の Messaging API チャネルがどのプロバイダーにあり、その Admin 権限を誰が持っているかを最初に確かめます。

同じプロバイダーに置くと、ログインのときに LINE公式アカウントの友だち追加を勧める「友だち追加オプション」も使えます。LINEログインのチャネルに LINE公式アカウントをリンクし、認可 URL に bot_prompt を付けると、同意画面（aggressive を指定したときは同意画面の後の画面）に友だち追加のオプションが出ます。リンクできるのは同じプロバイダーに属する LINE公式アカウントで、1つの LINEログインのチャネルに1つです。リンクする操作には、LINEログインのチャネルの Admin 権限と、LINE公式アカウントの管理者権限の両方が要ります。オプションを出したときは、ログイン後のコールバック URL に friendship_status_changed が付き、ログインのときに友だち追加かブロック解除をしたかが分かります。今友だちかどうかは、友だち関係を取得する API の friendFlag で分かります（LINEログインしたときにLINE公式アカウントを友だち追加する）。CRM は Webhook を使わずに、この2つをログインの時点で受け取れます。

代わりに負うことは2つあります。会話と、友だち追加・ブロックのイベントは、LINE公式アカウントの Messaging API チャネルに設定した Webhook URL に届くものなので、Webhook URL を配信ツールのままにする B では、CRM には届きません。もう1つ、同じプロバイダーでユーザーIDが同じになっても、複数のサービスで取った LINEユーザー情報を自由に結び付けて共通に使ってよい、という意味ではありません。LINEユーザーデータポリシーは、プロバイダーが複数のサービスで取得した LINEユーザー情報を結び付けて共通に使うことを原則禁止していて、プロバイダーページを公開し、所定の条件を満たした場合に共通の利用ができる、と公式の Tips が説明しています（プロバイダー設計の基本）。配信と CRM を同じ会社の同じサービスとして使うのか、別のサービスとして使うのかも、あわせて決めておきます。

C 受け手を CRM の製品に替える：手放すものを先に数える

C は、CRM・MA の製品の LINE の機能を手順どおりに使い、Webhook URL を製品に向ける形です。CRM に入るのは製品の LINE の機能が受ける範囲で、受け手を持つのは製品です。会話の受付を CRM の画面で行いたい、製品の機能で LINE の会話を担当者に割り振りたい、という目的なら、製品の手順に沿ってこの形になります。代わりに、配信ツールの機能のうち Webhook で受けたイベントを使うものには、向きを変えた時点からイベントが届かなくなります。切り替える前に、手放す機能と、代わりにどこで同じことをするかを数えます。

会話の窓口を、配信用とは別の LINE公式アカウントに分ける考え方もあります。Webhook URL は Messaging API のチャネルごとに1つなので、別のアカウントなら別の受け手を持てます。ただし友だちはアカウントごとに別で、お客様には友だち追加をもう一度お願いすることになります。問い合わせ専用の窓口として分けても困らないかで決めます。

みどり設計に当てはめると、配信ツールを使い続けたまま問い合わせの会話も顧客管理に入れたいので、A から考えます。配信ツールに CRM へ渡す機能があればそれを使い、無ければ自社で中継を置く、という順です。

誰に何を確かめるか

A・B・C のどれにするかは、みどり設計の中だけでは決めきれません。配信ツールの会社、CRM の製品の会社（か販売パートナー）、自社の LINE の管理者、連携を作る開発の担当に、それぞれ確かめることがあります。

CRM が kintone の場合の LINE のつなぎ方は「kintone と LINE の連携」に、Salesforce の場合の ID の結び方と受け口の作りは「Salesforce と LINE をつなぐ」にあります。

最初に、Webhook URL の向き先とプロバイダーの持ち主を見る

製品やツールを比べる前に、LINE Developers コンソールで LINE公式アカウントの Messaging API チャネルを開き、［Messaging API設定］タブの Webhook URL が誰の URL か、［Webhookの利用］と［Webhookの再送］が有効かを見てください。続けて、そのチャネルがどのプロバイダーの配下にあり、そのプロバイダーの Admin 権限を自社の誰が持っているかを確かめます。

Webhook の受け手をどこに置くか、LINEログインのチャネルをどのプロバイダーに置くかの決め方や、中継の設計は、当社のLINE運用・伴走支援でご相談いただけます。

仕様と画面の名前は、2026年10月14日に LINE Developers のドキュメント・リファレンス・よくある質問・Tips を開いて確かめたものです。CRM・MA の製品の手順の表は、同じ時期に Salesforce ヘルプ、Microsoft Learn、Braze、Treasure Data、Zoho ヘルプ、Adobe Experience League の公式の手順のページを開き、LINE の Webhook URL をどう扱っているかを読み比べて作りました。表に挙げた製品の LINE の機能の契約・エディションと、配信ツール・拡張ツールの個別の機能は扱っていません。