LINE活用の基礎

LINEクイックリプライが消える理由|回答ボタンを迷わず使える設計にする

小川 靖人文・小川 靖人元LINE社員・LIFE合同会社 代表
この記事の執筆者:元LINE株式会社でLINE公式アカウント活用支援チームの立ち上げを推進し、LINE Green Badge試験問題の作成にも関与。バディカダイレクト元COOとしてLINE中心の販売基盤を構築し、AI接客チャットボット「中野愛作」を開発。詳しいプロフィール →
#LINE公式アカウント#クイックリプライ#Messaging API#問い合わせ対応
この記事は「LINE公式アカウント完全ガイド」の一部です。全体像はこちらから →

この記事の結論

LINEの回答ボタンが消える条件と、選択結果を会話に残す方法を解説。リッチメニューとの使い分け、ボタンがないときの返信手段、導入前の確認順を整理します。

最終更新:2026年10月9日

LINEのクイックリプライは、直前の質問へ答えるための一時的なボタンです。新しいメッセージが送られたり、ボタンがタップされたりすると非表示になるため、いつでも押せる入口として置くものではありません。ボタンが消えたあとも、お客様が普通の文章で回答できる案内を残すと、会話を止めずに済みます。

この記事は、Messaging APIで回答ボタンを組み込む事業者と、その制作担当者向けです。管理画面のチャット定型文を選ぶ操作とは異なります。スタッフが繰り返す返信を用意したい場合は、チャット定型文の使い方を参照してください。

一時的な質問か、繰り返し使う入口かで選ぶ

「ご相談は新規予約ですか、予約の変更ですか」のように、いま届いた相談の種類を聞くならクイックリプライが候補になります。入力の手間を減らし、同じトークで次の質問へ進めるためです。

一方、「予約する」「店舗を探す」を何度も開く入口には、リッチメニューが向きます。短い質問のたびにメニューを切り替える必要はありません。回答ボタンがあることと、回答を受けた後の処理が用意されていることは別なので、先に次の案内を決めます。

LINE Developersの公式ガイドでは、1メッセージにつけられるボタンは最大13個、対応するLINEはAndroid版とiOS版です。上限いっぱいに並べるより、同じ問いに答える少数の選択肢に絞ります。「予約変更」「来週」「担当に相談」を同列に置くと、相談の種類・時期・対応方法が混ざり、何を答えるべきか分かりません。

クイックリプライは今の質問への一時的な回答ボタン。質問を送る、回答を受ける、選択結果を会話へ残す順に設計する。ボタンが消えても文章で答えられる案内を残し、繰り返し使う入口はリッチメニューを検討する。

図:制作前と、回答ボタンが消えた問い合わせの確認に使う手順です。ボタンが消える細かな条件は次の節で確認できます。

図解画像を開く(保存用)

ボタンが消える2つの場面と例外

公式ガイドが示す非表示の条件は次の2つです。

  • ユーザーがボタンをタップする。ただし、カメラ・カメラロール・日時選択・位置情報のアクションは、期待する情報をユーザーが送るまでボタンが残ります。
  • トークルームに新しいメッセージが送られる。送信者は公式アカウントに限りません。新しいメッセージを削除すると、ボタンが再表示されます。

したがって、質問とボタンを送った直後に別の案内を追加すると、お客様が選ぶ前にボタンが消えることがあります。相手の入力によっても表示は変わるため、ボタンが常にある前提の「下のボタンを押してください」だけでは説明が足りません。再表示のためにメッセージ削除を運用の標準手順にするより、最初の質問文に別の答え方を添えます。

以下は架空の運用例です。

ご相談の内容を選んでください。ボタンが表示されていなければ、「新規予約」「予約変更」またはご相談内容を、このトークへ送ってください。

実際に自由入力を受け付け、次の案内や担当への引き継ぎができることを確認してから使います。ボタン以外の回答を受け取っても無反応になるシステムでは、この案内を出すだけでは改善になりません。

選択した内容を、お客様も担当者も確認できるようにする

ボタンには、メッセージ送信、ポストバック、URLを開くなど異なるアクションを設定できます。クイックリプライではリッチメニュー切替アクションを使えません。ボタン名と実行内容を制作担当者へ渡し、見た目だけで選ばないようにします。

メッセージアクションは、指定した文字をユーザーのメッセージとして送ります。ポストバックなどでは、選択結果がトークに自動で投稿されない場合があるため、選択した内容が会話に残る実装を確認します。たとえば「予約変更のご相談ですね。変更したい日付を教えてください」と返せば、相手も引き継ぐ担当者も、何を選んだかを読み直せます。これは実装時の案内例で、自動で提供される返信ではありません。

日時選択で日付を受け取った場合も、それだけで空き枠の確保や予約の成立とはしません。予約システムへの確認が必要なら、予約情報との連携まで分けて設計します。

制作担当者へ渡す確認項目

まず一つの質問について、「問い」「各ボタンのラベルと動作」「回答後の案内」「自由入力時の扱い」を書きます。その後、AndroidとiOSの実際のLINEで、次を確認します。

  1. ボタンを押す前に追送したとき、案内だけで回答できるか。
  2. 各ボタンを押した後、選択内容と次の行動が分かるか。
  3. ボタンを使わず文章で返信したときも、相談が取り残されないか。
  4. 担当が替わったとき、同じ質問をお客様にやり直してもらわずに対応できるか。

回答をしやすくする目的は、配信するボタンを増やすことではありません。お客様が何を相談したいかを受け取り、必要な確認だけを次へ渡すことです。一つの質問を実機で試し、表示されない場面でも会話が続くかを見てから広げてください。

※仕様の確認日:2026年10月9日。対応端末、アクション、非表示条件は上記の公式資料を基準にしています。

この記事に関連するサービス

関連記事