LINE公式アカウントのWebhookとは

LINE公式アカウントには「Webhook」という仕組みがあります。ユーザーがメッセージを送ったり、友だち追加したりしたとき、その情報を外部のサーバーやサービスに自動で通知する機能です。

MAツール（Lステップ、エルメ、UTAGEなど）を使っている方は、意識せずにこの仕組みを利用しています。LINE公式アカウントの管理画面、あるいはLINE Developersコンソールで「Webhook URL」を設定すると、ユーザーのアクションがそのURLに送信され、MAツール側で自動応答やステップ配信が動く——これがWebhookの基本的な流れです。

ユーザーがメッセージ送信
    ↓
LINE公式アカウント（Messaging API）
    ↓
Webhook URL（MAツールのサーバー）
    ↓
自動応答・ステップ配信などが動作

この仕組み自体は非常にシンプルで、LINE公式アカウントを活用するうえで欠かせない基盤です。

「Webhook URLは1つだけ」という仕様上の制約

ここで知っておきたいのが、LINE Messaging APIの仕様です。

LINE公式アカウント1つにつき、設定できるWebhook URLは1つだけ。

これはLINEプラットフォーム側の仕様であり、設定画面を見ても入力欄は1つしかありません。複数のURLを登録する機能は提供されていないのが現状です。

MAツールだけを使っている場合、この制約はまったく問題になりません。Webhook URLにMAツールのURLを設定すれば、それで完結します。

問題が出てくるのは、Webhook URLの送信先を2つ以上にしたくなったときです。

この制約が困る具体的な場面

Webhookが1つしか設定できないことで、実際にどんな場面で困るのか。よくあるケースを挙げてみます。

ケース1：MAツール＋AI返信を併用したい

MAツールでシナリオ配信や自動応答を運用しつつ、想定外の質問にはChatGPTなどのAIで自動返信したい。ZapierやMakeを使えばAI返信の仕組みは作れますが、Webhook URLはすでにMAツールが使っています。

AI返信用のZapierにWebhookを送ろうとすると、MAツールのURLを外す必要がある。つまり、どちらか一方しか動かせないということになります。

ケース2：メッセージをSlackやチャットツールに通知したい

ユーザーからメッセージが届いたら、社内のSlackチャンネルにリアルタイムで通知を飛ばしたい。スタッフが管理画面を常にチェックしなくても、すぐに対応できるようにするためです。

ただ、Webhook URLはMAツールに設定済み。Slack通知のためにWebhook URLを切り替えると、MAツールが動かなくなります。

ケース3：自社のデータベースにメッセージを蓄積したい

ユーザーとのやり取りを自社のデータベースやスプレッドシートに記録・蓄積して、独自の分析に活用したい。MAツールにもデータは残りますが、もっと自由に加工・集計したいというニーズです。

この場合も、データ受信用のサーバーにWebhookを送る必要がありますが、URLの枠は1つしかありません。

ケース4：複数のMAツールを比較検証したい

新しいMAツールへの乗り換えを検討しているとき、既存のMAツールを動かしたまま、新しいツールにも同じWebhookデータを流してテストしたい。ただ、Webhook URLを切り替えてしまうと、既存の運用が止まります。並行テストができないのです。

解決方法は大きく2つ

Webhookが1つしか設定できない制約をどう乗り越えるか。現実的な解決方法は2つあります。

方法1：自前でプロキシサーバーを構築する

Webhook URLに自分で用意したサーバーを設定し、そのサーバーが受け取ったデータを複数の送信先に転送する——という仕組みを自前で作る方法です。

ユーザーのアクション
    ↓
LINE公式アカウント
    ↓
自前のプロキシサーバー
    ↓         ↓         ↓
 MAツール   Zapier    Slack通知

技術的にはシンプルな構成です。Node.jsやPythonで数十行のコードを書けば、基本的なプロキシは作れます。

ただし、自前で構築する場合は以下の点を考慮する必要があります。

サーバーの運用・保守：24時間稼働するサーバーが必要。障害対応も自分で行う
署名検証の実装：LINEはWebhookリクエストに署名を付与しており、正当性を検証する処理が必要
レスポンス速度の確保：LINEはWebhookの応答に時間制限を設けている。転送先の応答を待ってからLINEに返すと、タイムアウトになる可能性がある
エラーハンドリング：転送先の1つがダウンしていた場合にどう処理するか
SSL証明書の管理：Webhook URLはHTTPS必須

エンジニアがチームにいる場合や、自社でインフラを運用できる体制がある場合は、この方法が柔軟性は最も高いです。

方法2：Webhook転送サービスを使う

自前で構築・運用するのが難しい場合や、そこにリソースを割きたくない場合は、Webhookを複数の送信先に転送してくれるサービスを利用する方法があります。

サーバーの構築・運用・保守をサービス側に任せられるので、設定だけで導入できるのが利点です。LINE公式アカウントのWebhook URLを転送サービスのURLに変更し、転送先のURLを管理画面で登録する——基本的にはこれだけで完了します。

この方法なら、エンジニアでなくても導入できますし、サーバーの運用負荷もかかりません。

L-Proxyを使った解決方法

Webhook転送サービスの一つとして、L-Proxyがあります。LINE公式アカウントのWebhookを最大3つの送信先に同時転送するサービスです。

設定の流れは以下のとおりです。

L-Proxyに登録し、LINE公式アカウントを追加する
転送先のURL（MAツール、Zapier、Slack通知用サーバーなど）を登録する
LINE公式アカウントのWebhook URLを、L-Proxyが発行するURLに差し替える

これで、ユーザーからのメッセージやイベントが、登録した最大3つの送信先に同時に転送されます。

ユーザーのアクション
    ↓
LINE公式アカウント
    ↓
  L-Proxy
    ↓         ↓         ↓
 MAツール   Zapier    Slack通知

L-Proxyは非同期で各送信先に転送を行うため、1つの送信先の応答が遅くてもLINEへのレスポンスには影響しません。署名検証やエラーハンドリングもサービス側で処理されます。

料金はスタータープランが月額980円からで、14日間の無料トライアルがあります。

Webhook転送時に知っておきたい技術的なポイント

自前で構築する場合でもサービスを利用する場合でも、Webhookを複数に転送する際に知っておくべき技術的なポイントがいくつかあります。

署名検証について

LINE Messaging APIは、Webhookリクエストのヘッダーにx-line-signatureという署名を付与します。受信側はこの署名を使って、リクエストが本当にLINEから送られたものかを検証できます。

プロキシで転送する場合、転送先のMAツールが署名検証を行っているケースがあります。転送時にリクエストボディが変わってしまうと署名が一致しなくなるため、ボディをそのまま（改変せずに）転送することが重要です。

応答の返し方について

LINEはWebhookリクエストを送った後、一定時間内にHTTP 200のレスポンスを期待しています。複数の転送先にリクエストを送り、すべての応答を待ってからLINEに返すと、タイムアウトになるリスクがあります。

そのため、転送は非同期で行うのが基本的な設計方針です。LINEにはすぐにレスポンスを返し、各転送先への送信はバックグラウンドで処理する形です。

Reply Tokenの制約

LINEのWebhookイベントにはreplyTokenが含まれていますが、このトークンは1回しか使えません。複数の転送先のうち、最初にReply APIを呼んだサービスの返信だけが送信され、それ以降のreplyTokenの利用は無効になります。

つまり、複数の転送先から同時に返信しようとしても、実際にユーザーに届く返信は1つだけです。この点は、転送先でどのサービスが返信を担当するかを事前に設計しておく必要があります。

まとめ

LINE公式アカウントのWebhookは、仕様上1つしか設定できません。MAツール単体で運用する分には問題ありませんが、AI返信やSlack通知、データ蓄積など複数のサービスと連携したい場合に、この制約が壁になります。

解決方法は、自前でプロキシサーバーを構築するか、L-Proxyのような転送サービスを利用するかの2つ。自社にエンジニアリソースがある場合は自前構築も選択肢ですが、設定だけで導入したい場合はサービスの利用が現実的です。

LINE公式アカウントの活用の幅を広げたいと考えている方は、まずWebhookの制約を理解したうえで、自分の運用に合った方法を検討してみてください。

MAツール × AI返信、両方使いませんか？ → L-Proxyについて詳しく見る