LINEのreplyTokenが期限切れ？遅い応答で二重送信を防ぐ方法
LINE Messaging APIのreplyTokenは一度しか使えず、Webhookの受信後1分以内に使用する必要があります。それ以降の利用は保証されません。AI生成やキュー待ちで応答が遅れた場合、同じトークンを繰り返し送信したり、タイムアウト直後に自動でプッシュ送信へ切り替えたりしないでください。まず「まだ使っていないトークン」と「送信したが結果が不明な応答」を区別します。
要点
- 応答トークンは短時間の応答機会であり、宛先IDや再利用可能な認証情報ではありません。
- Webhookの再送は、独立した2回目の応答機会を作りません。
- 送信タイムアウトは結果不明を意味し、未送信の証拠ではありません。
- プッシュ送信は宛先条件とメッセージ数の計算が異なる別操作です。トークンの更新ではありません。
LINEの応答トークンの仕様
Messaging APIリファレンスのPOST /v2/bot/message/replyは、イベントのreplyTokenとmessages配列を使います。トークンは一度だけ使用でき、できるだけ早く使う必要があります。LINEは有効期間が変更される可能性も示しているため、期限ぎりぎりまで待つ設計は避けてください。
「確認しています」と即座に返すだけでもトークンは消費されます。後から完成した回答に同じトークンは使えません。送信ガイドでは1回の応答リクエストに最大5個のメッセージオブジェクトを指定できますが、同じトークンで5回リクエストできるという意味ではありません。
| 値 | 役割 | 代わりにならないもの |
|---|---|---|
| チャネルアクセストークン | チャネルのAPIリクエストを認証する | 新しい応答トークン |
replyToken | イベントのきっかけとなった操作に応答する | 恒久的なユーザーの宛先 |
| 宛先識別子 | 条件を満たすプッシュ送信先を指定する | 応答操作を再利用する権限 |
LINE MINI Appの通知を扱っている場合は、先にサービスメッセージとMessaging APIの比較を確認してください。サービス通知トークンは別のAPI仕様に属します。
フォールバックの前に失敗箇所を切り分ける
以下はアプリケーション側の推奨確認項目であり、新しいLINEエラーコードではありません。
| 確認できた事実 | 調べる境界 | 安全な次の対応 |
|---|---|---|
| Webhook受信から長時間後にワーカーが開始した | キュー待ち、生成の遅延 | 古いトークンに依存せず、遅延送信を別途判断する |
| 別ワーカーがすでに成功応答を受け取った | 一度限りのトークンを消費済み | 重複ジョブを止める |
| リクエスト送信後にHTTPがタイムアウトした | 受理されたか不明 | 不明状態を残し、同じ回答を即座にプッシュしない |
| 同じWebhookが再び届いた | 重複受信 | 元イベントの処理状態と送信状態を確認する |
| 新着イベントでも応答に失敗する | 本文、チャネル認証情報、トークン選択、その他のAPIエラー | 実際のレスポンスを調べ、すべてを期限切れと判断しない |
受信時刻、ワーカー開始時刻、送信時刻、HTTPステータス、過去の成功有無を記録します。トークンや認証ヘッダーを一般ログに残さず、短時間の処理に必要な間だけ保護された領域に保持してください。
1回のエラーだけでは、別ワーカーがすでに回答を送ったかどうかは分かりません。チャネルアクセストークンを再発行しても、使用済みの応答トークンは復活しません。
Webhook再送はトークン更新サービスではない
LINEの受信ガイドによると、再送時もWebhookイベントIDと応答トークンは変わらず、deliveryContext.isRedeliveryが変わります。アプリケーションではチャネル識別子とwebhookEventIdを組み合わせて重複を検出します。
リファレンスでは、再送Webhookの受信後1分以内にも応答トークンを使用できます。ただし、すでに使用済みの場合や、イベント発生から20分が経過した場合は使えません。これは復旧時の限定的な扱いであり、予約送信の猶予期間でも、Webhookを意図的に拒否する理由でもありません。
イベントを永続化し、時間のかかる処理とは切り離して受信確認を返します。重複Webhookは既存ジョブを参照し、AI生成と送信をもう一度開始しないようにします。送信状態も永続化してください。受信の重複排除だけでは、ワーカー停止後に再実行される送信ジョブを保護できません。
長い処理を始める前に応答経路を決める
短時間で完成する回答は、1つのワーカーが担当して速やかに応答します。応答期限を超える可能性がある処理は、「先に受付メッセージを返し、後で結果を送る」か「完成後に結果だけ送る」かを先に決めます。
推奨するアプリケーション設計は次のとおりです。
- イベントの処理権を一度だけ取得する。 チャネルと
webhookEventIdを1つの業務操作に関連付け、一意制約やトランザクションで複数ワーカーの独立送信を防ぎます。 - 送信方法の決定を保存する。 即時応答と後続プッシュを区別します。受付の返答は完了した応答であり、トークンの予約ではありません。
- 結果を正確に記録する。 未実行、受理済み、拒否、結果不明をローカル状態として分けます。これらはアプリケーションの名称で、LINEレスポンスのフィールドではありません。送信後のプロセス停止でも結果不明になり得ます。
- 遅延送信を判定する。 回答が今も必要か、担当者がすでに返答していないか、宛先が現在のプッシュ条件を満たすかを確認します。先行送信の結果が不明なら、明示的な判断を必要とします。
- プッシュを新しい操作として保存する。 独立したリクエストと保護策を使います。プッシュ送信は前の応答結果を変更しません。
LINEの料金説明では、応答メッセージはプランのメッセージ数にカウントされず、プッシュメッセージはカウントされます。フォールバックでも同じ計算になると考えず、適用プランを確認してください。
対応するプッシュ再試行は、X-Line-Retry-Keyガイドを参照してください。公式の再試行ドキュメントが挙げる対象はpush、multicast、narrowcast、broadcastであり、replyは含まれません。replyにこのヘッダーを追加しても、期限の延長や、後続プッシュと先行応答の重複排除にはなりません。
UnifyPortの応答仕様とは分けて扱う
UnifyPortの非公式インターフェースは、接続したメッセージングアカウントを使う別経路です。LINE公式アカウントの応答トークンを修復する機能ではありません。テキスト送信リファレンスはPOST /v1/messagesにaccount_id、to、messageを渡します。プロバイダー対応表ではLINEのテキスト送信を扱いますが、トークンを使う引用返信操作は現在WhatsAppのみです。
LINEのreplyTokenをUnifyPortのreply_to.reply_tokenに入れないでください。名前が似ていても互換性はありません。保存した正規化イベントへの通常返信では、仕様に沿ったアカウントと会話識別子を使い、実際の送信結果を確認します。APIをまたぐ冪等性やトークン復旧を意味するものではありません。
送信元がLINE公式アカウントである必要があるなら、公式Messaging APIを使い続けます。送信結果が不明なときに、接続アカウントの身元を変えて自動再送するのは安全な代替策ではありません。
よくある質問
期限切れのLINE応答トークンは更新できますか？
更新可能なアクセストークンとして扱わないでください。条件に合う新しいイベントには応答機会があり、再送には上記の限定ルールがあります。どちらも同じ業務回答を無制限に再試行する仕組みではありません。
受付メッセージと最終回答に同じトークンを使えますか？
使えません。最初に受理された応答でトークンを消費します。後続の回答は別途計画し、プッシュの宛先条件とメッセージ数を確認してください。
応答のタイムアウトはすべてプッシュに切り替えるべきですか？
いいえ。応答がすでに受理されている可能性があり、自動プッシュで重複するおそれがあります。結果不明を保持し、明示的なフォールバック方針を設けます。
次のステップと出典
LINE Messaging APIリファレンスに照らして、遅い応答フローを1つ見直してください。重複配信、2ワーカーの競合、受付後の遅延回答、HTTPレスポンス消失をローカルのモックで検証します。これは推奨テストであり、本番実績の報告ではありません。別の接続アカウント経路を使う場合は、UnifyPortのテキスト送信仕様から確認してください。
公式資料の確認日：2026-10-04。
メッセージ連携を安定したプロダクトパイプラインへ。
まずは 1 つの API で送信を始め、標準イベントですべての inbound メッセージを業務システムへ戻しましょう。