LINEのローディング表示で待ち時間を伝える｜表示条件と返答を残す設計

LINEのトークで返答の準備に少し時間がかかるとき、Messaging APIのローディング表示を使えます。ただし、表示を始めたことと、問い合わせを解決したことは別です。表示が消えたあとも結果が返せるように、処理と案内を設計します。

予約の確認、商品検索、回答の準備など、数秒の空白で「送れなかったのかな」と不安になる場面が対象です。LINE公式アカウントの手動チャットに、ここで説明するAPIの処理が自動で付くという案内ではありません。

トークを開いている人に見せる機能

公式のローディング表示の説明では、ユーザーと公式アカウントの1対1のトークへ表示でき、グループトークや複数人トークは対象外です。

表示は、ユーザーが対象のトークを開いているときに限られます。閉じているときにリクエストしても通知されず、その後にトークを開いた人へ表示が持ち越されるわけではありません。待っている人へ確実に受け付けた内容を伝えたい場合、アニメーションだけへ任せないようにします。

図：短い待機の表示と、最後まで返答する仕事を分けています。202応答だけでは相手の画面に表示された確認になりません。

APIリファレンスでは、loadingSecondsは5秒刻みの5〜60秒から選び、省略時は20秒です。指定した時間が過ぎるか、表示中に公式アカウントからメッセージが届くと消えます。対応するLINEアプリの条件も公式資料で確認します。

リクエストが受け付けられるとHTTP 202が返りますが、相手がトークを開いていない場合など、202でも実際には表示されない条件があります。202を「お客様が待機表示を見た」と記録しないでください。

表示中にもう一度リクエストすると、終了までの時間は後から指定した値に上書きされます。ただし、何度も延長することを、相談の進捗を伝える方法にはしません。処理が遅い原因や、長くなるときの次の案内を別に決めます。

担当者への照会など、すぐ結果が出ない仕事なら、短い表示で待たせ続けるより、受け付けた内容と次に確認することを文章で伝えます。返答の見込みを案内する場合は、実際に守れる範囲で決めてください。

たとえば「在庫を確認します。確認でき次第、このトークへ結果をお送りします」という説明を使うなら、結果を返す担当と送信条件まで用意します。これは架空の案内例であり、LIFEが常時有人対応を提供するという主張ではありません。

AIで文章を用意している場合も、お客様にとって必要なのは、相談を受け付けてもらい、次にどうなるかが分かることです。「AI処理中」を大きく見せることを優先せず、回答が出ないときや確認が必要なときの案内を設計します。分からないことを、待機表示の裏で処理済みにしないようにします。

システム側には、受付時刻、処理の状態、結果の送信結果、確認する担当を分けて残します。アニメーションは短い画面上の表示なので、その有無を業務の完了状態にしないことが大切です。

試験は許可したテスト先で行い、API応答と実際の端末表示を別に確認します。このページの図は説明用であり、実機への送信テストの完了を示していません。

人への引き継ぎまで必要なら、AIチャットから人へつなぐ条件も確認してください。短い待ち時間を見せる機能を導入するだけでなく、一通の相談を最後まで扱える状態を作ります。

※仕様の確認日：2026年10月8日。表示条件は公式資料に基づき、待ち時間の案内と業務記録は設計上の提案です。