LINEのInvalid reply tokenを調べる｜期限・使用済み・処理時間の確認順

Invalid reply tokenが返ったときは、同じ応答トークンで送信を繰り返す前に、いつ受け取り、すでに誰かが使ったかを調べます。処理をもう一度動かしても、使用済みや期限の問題は解消しません。

この記事はMessaging APIの応答メッセージを対象にしています。チャット管理画面でスタッフが返信する操作とは別です。送信方式の全体像はMessaging APIの送信方法で確認できます。

応答トークンは、あとで何度も使うためのIDではない

公式リファレンスの応答トークンは、一度だけ使用でき、Webhook受信後1分以内に使う必要があると説明されています。1分を超える動作は保証されません。ネットワークの遅れなどでも使用可能な時間は変わるため、期限ぎりぎりを前提にした設計を避けます。

たとえば、問い合わせを受けてから商品検索や文章生成を順番に実行し、最後に応答する処理では、外部処理の待ち時間が送信を遅らせます。通常の処理時間だけでなく、混雑時や外部サービスが遅いときも確認してください。「いつも数秒で終わる」だけでは、長く待つ相談の扱いが決まっていません。

応答トークンの確認順。Webhookの受信時刻と送信試行を並べ、使用済みか、重複処理か、待ち時間が長かったかを確認する。トークンは一度のみ、受信後1分以内にできる限り早く使う。時間の限界まで待つ設計は避け、結果を返す経路を別に決める。

図：送信前の待ち時間と、使用済みの確認を分けています。1分間の利用を保証するタイマーではありません。

応答APIの400エラーには、無効な応答トークンだけでなく、メッセージの形式が不正な場合もあります。エラーの本文と、どのAPIを呼んだかを合わせて読みます。

確認の記録は、次のように分けると追いやすくなります。

記録する項目	判断したいこと
Webhookの受信時刻	受信してから送信を試すまで、どこで待ったか
イベントの識別子と処理済み記録	同じイベントを別の処理も受け付けていないか
送信の試行時刻・結果	最初の応答が成功していないか、後続だけが失敗していないか
処理段階の所要時間	キュー・検索・外部API・文章生成のどこが遅いか

実際の応答トークン、認証情報、問い合わせの全文を調査用の共有表へ貼る必要はありません。識別に必要な範囲を制限し、トークンを保存する場合も開発環境の適切な管理の下で扱います。

公式には、再送されたWebhookの応答トークンにも使用条件があります。再受信後1分以内でも、元のトークンを使用済みの場合や、イベント発生から20分経過した場合は使用できません。

再送を「新しい問い合わせが来た」と扱うと、最初の返信が成功していたのに別の返信を用意することがあります。まず同じイベントの処理履歴と応答結果を照合してください。イベントを一度だけ処理する仕組みはWebhookの再送と重複対策で整理しています。

通信のタイムアウトで最初の結果が分からない場合も、同じトークンを何度も使えば届くと考えないようにします。APIリクエストの再試行とWebhookの再送は別の問題です。プッシュ送信の再試行についてはリトライキーの使い方を確認してください。

在庫確認や担当への照会など、すぐ答えが出ない相談があります。その場で受付を伝える設計を選ぶなら、実際に受け付けた範囲と、次に何を確認するかを短く知らせます。受付の返答で応答トークンを使ったあと、同じトークンで結果を送る設計にはしません。

後からプッシュメッセージなどで結果を返す場合は、宛先、送信できる条件、通数と送信結果の扱いを別に確認します。単にプッシュへ置き換えるだけでは、返信漏れを防げません。結果を返す仕事を誰が確認するか、失敗したらどこに残すかまで決めます。

お客様が知りたいのは内部のトークンの事情ではなく、相談が受け付けられ、答えが返ってくるかどうかです。技術上のエラーを直す確認と、お客様への返答が残っている確認を、同じ担当が見渡せる状態にしておきましょう。

※仕様の確認日：2026年10月8日。制限は公式資料に基づき、調査記録と受付・結果を分ける手順は設計上の提案です。