LINE Webhookの再送と重複対策｜同じ相談を二重処理しない設計
文・小川 靖人元LINE社員・LIFE合同会社 代表この記事の結論
LINE Messaging APIのWebhook再送を有効にする前に確認したい、イベントIDによる重複検出、順序のずれ、受信記録と業務処理の分離、障害時のテストを解説します。
最終更新：2026年10月6日
LINEのWebhook再送は、受信に失敗したイベントを受け取り直すための仕組みです。再送をオンにするだけで、取りこぼしや二重処理を防げるわけではありません。同じイベントが届いても、問い合わせを二件作ったり、同じ予約操作を繰り返したりしない設計が必要です。
設定前に、受信記録、業務処理、返信をどこで確定するかを確認してください。以下は実装を検討するための設計例であり、LINEが外部システムの処理を代わりに管理する機能ではありません。
再送の対象と、保証されないことを確認する
LINE DevelopersのWebhook受信ガイドでは、再送を有効にしていて、受信サーバーが200番台を返さなかった場合に再送されると案内されています。初期設定では無効です。回数や間隔は公開されておらず、確実な再送も保証されません。
同じガイドは、イベントが重複したり、届く順番が発生順と変わったりする可能性も示しています。重複の確認にはwebhookEventId、発生時刻の確認にはtimestampを使います。deliveryContext.isRedeliveryは再送かどうかを示しますが、重複検出の代わりにはしないでください。
外部の注文APIが失敗しても、Webhook受信側がすでに200番台を返していれば、その業務処理をLINEが再実行してくれるとは限りません。受信に対する再送と、自社システム内の処理の再試行を分けます。
受信してすぐ200を返す前に、記録を残せるかを見る
応答を速く返すために、受信後の処理を別の実行枠へ渡す設計はあります。ただし、記録や処理の引き渡しに失敗したまま成功を返すと、そのあとで相談が失われる可能性があります。
一例として、次の順番を検討できます。
- 未変更のリクエスト本文で署名を検証する
- 検証済みのイベントを、イベントIDとともに永続的な受信記録へ保存する
- 保存できたイベントを後続処理へ渡し、受信の応答を返す
- 後続処理の成功・失敗を、受信記録とは別に管理する
署名の確認方法は、公式のWebhook署名検証ガイドが根拠です。本文を加工したり、JSONとして読み込んで再生成したりする前に検証します。署名を確認できないリクエストで、顧客情報の更新や予約操作を実行しないようにしてください。
保存する内容は、後続処理に必要な範囲と保存期間を決めます。調査ログに問い合わせ本文や秘密値を無条件に出力する必要はありません。イベントID、処理状態、エラー種別などで状況を追えるかを検討します。
図：同じ相談を二重処理しない。細かな条件と例外は、本文で確認してください。
「既に受信した」と「処理が終わった」を区別する
重複したイベントが届いたとき、最初の処理はまだ途中かもしれません。イベントIDが存在するだけで処理済みと判断せず、受信済み、処理中、処理成功、再試行待ちなどの状態を分けます。
| 届いたときの状態 | 設計上の扱いの例 |
|---|---|
| 同じIDの記録がない | 一度だけ受信記録を作り、処理対象にする |
| 同じIDが処理中 | 二つ目の処理を並行実行しない |
| 同じIDが処理成功 | 同じ業務操作を繰り返さない |
| 同じIDが失敗・再試行待ち | 決めた再試行担当が、記録に沿って再開する |
記録を読むだけの重複チェックは、二つの受信が同時に来ると競合することがあります。保存先の一意制約や、処理を引き受ける際の排他制御など、同時実行でも一度だけ確定する方法を実装側で確認します。
さらに、同じイベントで複数の作業を行う場合は、注文更新は成功したが、担当通知は失敗した、という途中状態も残します。すべて最初からやり直すと、成功済みの操作を繰り返してしまうためです。外部サービスに再試行のための識別子や仕様がある場合は、そのサービスの公式資料で条件を確認してください。
到着順だけで顧客の状態を上書きしない
「受付」「取消」などのイベントが順序を変えて届く場合、後から届いた古いイベントで、取り消した状態を受付へ戻してはいけません。発生時刻と現在の状態を確認し、どの状態からどの状態へ進めるかを業務ごとに決めます。
時刻を並べ替えれば、すべての問題が解決するわけでもありません。別システムで行われた変更や、同じ時刻の処理なども考慮し、判断できないものは確認待ちとして残します。顧客への返信や確約が関わる変更は、状態の食い違いを検出したときの担当を決めておきます。
有効化の前に、障害の途中から試す
LINE Developersコンソールでは、対象チャネルのMessaging API設定でWebhookの利用と再送を確認します。運用中の設定を切り替える前に、テスト環境で次の場面を試してください。
- 同じイベントIDを二回、続けて受け取る
- 同じイベントIDを二つの処理で同時に受け取る
- 受信を保存したあと、業務処理の途中で停止する
- 業務操作が成功したあと、成功記録の直前で停止する
- 新しいイベントのあとに、古いイベントを受け取る
確認するのはHTTPの成功だけではありません。問い合わせや注文への変更が一度だけ行われたか、失敗した作業を再開できるか、手動確認が必要なものを一覧で拾えるかを見ます。実際のお客さんへの配信や注文操作を、重複テストの対象にしないでください。
API全体の位置づけは、Messaging APIの基礎で確認できます。再送は障害対策の一部分です。受け取った一通を最後まで処理できたかを、自社側でも追える状態にしてください。