LINEのボタンを押しても返信されない？ポストバックの受信・処理・表示を確認

LINEのボタンを押しても返事がないときは、ボタンの表示、選択結果の受信、受信後の処理、返信の送信を分けて調べます。ポストバックは、押されたボタンに設定した情報をWebhookでサーバーへ渡す仕組みです。ボタンを置くだけで、その内容に沿った回答まで自動で作られるわけではありません。

この記事はMessaging APIを使う制作・運用担当者向けです。管理画面のキーワード応答とは処理の入口が違うため、設定場所を取り違えないことから始めます。

ボタン名・処理用データ・会話に残る文章は役割が違う

ポストバックの公式仕様では、dataがサーバーへ返す文字列です。displayTextは、タップ時にユーザー側のメッセージとしてトークへ表示する文章です。ボタンの見た目を表すlabelだけを読み、処理内容まで判断しないようにします。

• ボタンのラベル：例は「予約を変更する」。相手が何を選ぶのかを示します。
• 処理用の data：例は action=change_reservation。受信側で、この値を処理する条件があるか確かめます。
• トークに残す displayText：例は「予約変更について相談したいです」。選択内容を相手も担当も見返せるようにします。
• 受信後に送る返信：例は「変更したい日付を教えてください」。次に何をすればよいかを相手へ返します。

これらは実装の説明例であり、LINEやLIFEが標準でこの返信を提供するという意味ではありません。displayTextがトークに見えても、予約情報の更新や担当への引き継ぎが完了した証拠にはなりません。

図は確認する順番です。トークへの表示とサーバー側の受け付けは別で、受信後の処理と返信は実装が必要です。予約変更の文言は架空の運用例です。

図解画像を開く（保存用）

同じボタンを一度押し、止まった場所を確認する

承認されたテストアカウントで対象のメッセージを開き、時刻と押したボタンを控えます。実顧客のメッセージや受信JSON全体を調査資料へ転載する必要はありません。

まず、制作側で指定したアクションの種類を確認します。postbackならポストバックイベント、messageならメッセージイベント、uriならURLを開く動作です。ボタンの文言が同じでも、受信する情報や処理は同じとは限りません。種類の違いは公式のアクション一覧で照合できます。

次に、受信側がpostbackのイベントを扱っているか確認します。テキストのメッセージだけ処理する実装では、ボタンを押した選択が処理対象に入らないことがあります。受信そのものが見当たらなければ、Webhookが届かないときの確認順へ進みます。

受信できている場合は、postback.dataの値と処理の条件を比較します。表示ラベルの変更とは別に、処理用の文字列が変更されていないか、以前に送ったボタンの値も受け付ける必要があるかを確認します。古いボタンからの操作を受け付けられないなら、案内を返して現在の入口へ移れるようにするのが運用上の対策です。

最後に、返信を作成したか、LINEへの送信が成功したかを別々に確認します。ポストバックイベントには応答できますが、返信処理の実装が必要です。応答トークンのエラーがある場合はInvalid reply tokenの確認方法を使い、ボタン設定の問題と混ぜずに調べます。

「選んだ」と「受け付けた」が分かる会話を残す

相手が無反応に見える画面で何度も押さなくて済むように、選択した内容と次にすることをトークへ残します。たとえば予約変更なら、希望日を聞く段階で「変更が確定しました」と書かないことが大切です。

架空の案内例は「予約変更のご相談ですね。変更したい日付を教えてください。空き状況を確認してご案内します」です。即時確認できない運用なら、実際に対応できる範囲で、誰が確認するか・結果を返す手順を決めます。未提供の有人対応や回答時間を約束する文言は足しません。

引き継ぐ担当者にも同じ選択が伝われば、相手に最初から説明し直してもらう手間を減らせます。クイックリプライの公式ガイドも、選択結果を後から確認できるよう、会話へ残す実装を案内しています。

公開前には「ボタンを押す→選択が会話に残る→必要な処理が行われる→次の案内が届く」を一続きで試します。受信ログの成功だけで、相手への案内まで完了したと扱わないことが確認の要点です。