LINE Webhooks は、LINE 公式アカウントに起きたイベントを自社サーバーへリアルタイムに届ける仕組みだ。LINE Bot を作るうえで「ユーザー側で何が起きたか」を受け取る入口にあたる。

受け取れるイベントの幅

通知されるのはメッセージ受信だけではない。テキスト・画像・スタンプといったメッセージに加え、友だち追加・ブロック・アンフォロー、ボタン押下に対応するポストバック、店舗などに置くビーコンの検知まで届く。これらを組み合わせると、友だち追加直後にウェルカムメッセージを送る、ボタン操作で会話を分岐させる、といった自動応答フローが組める。

実装で外せない署名検証

LINE Webhooks を実装するうえで必須なのが署名検証だ。Webhook の URL は公開エンドポイントになるため、リクエストが本当に LINE から来たものかをチャネルシークレットで検証しないと、第三者が偽イベントを投げ込める。サンプルコードでも署名検証が前提になっており、ここを省略してはいけない。

応答タイムアウトという落とし穴

実装でつまずきやすいのが応答の時間制約だ。LINE は Webhook に対して短時間でのレスポンスを期待しており、重い処理を同期的に実行して返答が遅れると、配信失敗とみなされる。AI 応答や外部 API 呼び出しのような時間のかかる処理は、Webhook を受けたら即座に 200 を返し、実処理はキューに逃がす設計が定石になる。

料金と守備範囲

Webhook の受信自体は無料だ。コストがかかるのは応答としてメッセージを送る側で、LINE Messaging API の送信が月間の無料枠を超えると従量課金になる。受信ではなく送信量が課金トリガーだと理解しておく。プッシュメッセージを多用する設計だと、ユーザー数の増加がそのまま送信数の増加に直結し、コストが伸びやすい。

機能は LINE プラットフォーム内に閉じている。LINE と他のメッセージングを横断する統合基盤が欲しいなら、各プラットフォームの Webhook を個別に受けて自前で抽象化する設計が必要になる。

友だち追加とブロックを検知する

メッセージの受信だけでなく、友だち追加（follow）とブロック（unfollow）のイベントも届く。これを取りこぼすと、すでにブロックした相手にプッシュ送信を試みて無駄な課金が発生したり、配信対象数の見積もりが実態と乖離したりする。ユーザーの状態を自社側で正しく保つには、これらのイベントを確実に処理する必要がある。

🟡
ユーザーIDはチャネルごとに異なります

取得できるユーザー識別子は、そのチャネル（公式アカウント）内でのみ有効です。別のチャネルでは同じ人でも異なるIDになります。複数の公式アカウントを運用する場合、同一人物として紐づけるには別の手段（ログイン連携など）が要ります。IDを共通のキーとして設計すると、後から破綻します。

受信内容の保存範囲を決める

ユーザーから送られたメッセージには、氏名や連絡先といった個人情報が含まれうる。すべてを無期限に保存する設計にすると、プライバシーポリシー上の説明責任と、漏えい時の影響が大きくなる。業務上必要な範囲と保持期間を定め、それを超えるものは保存しないか匿名化する方針を、実装前に決めておきたい。