LINEのローディングアニメーションが表示されない?トークとタイミングを確認
LINEのローディングアニメーションは、ユーザーとLINE公式アカウントの1対1トークで、ユーザーがそのトーク画面を開いている場合にのみ表示されます。表示リクエストは POST /v2/bot/chat/loading/start です。別の画面を見ているユーザーに通知は届かず、後からトークを開いても、そのリクエストのアニメーションは表示されません。APIの成功だけでは、ユーザーが見たことを確認できません。
要点
chatIdにはユーザーIDを指定します。グループIDや返信トークンではありません。- 指定時間が過ぎるか、公式アカウントから新しいメッセージが届くと消えます。
- 表示中に再リクエストすると、消えるまでの時間が上書きされます。処理の進捗を伝える機能ではありません。
- アニメーション、webhookへの応答、ジョブ完了、回答の送信は別々に扱います。
ローディングアニメーションが制御するもの
公式の表示ガイドでは、表示時間を 5〜60秒としています。対象は1対1トークで、グループトークや複数人トークは指定できません。
実装では、次の3つの時間を分けてください。
| 時間 | 制御するもの | 証明しないこと |
|---|---|---|
| アニメーションの表示時間 | 視覚的な待機表示の長さ | ワーカーがまだ動いていること |
| アプリケーションのジョブ実行時間 | システムが処理する時間 | ユーザーがトークを見ていること |
| 返信の有効な機会 | 公式の返信操作を利用できるか | アニメーションが見えていること |
アニメーションをジョブ監視に使わないでください。消えたからといってAI処理の失敗とは限りません。表示時間が終了しただけ、あるいは公式アカウントからのメッセージが届いただけかもしれません。
返信そのものが失敗する場合は、LINEの返信トークンと遅い応答の対処ガイドを参照してください。ローディングAPIに返信トークンを延長・更新する仕様は記載されていません。
条件をそろえて1回リクエストする
バックエンドにMessaging APIのチャネルアクセストークンと、対象チャネルの1対1のやり取りで得たユーザーIDを用意します。トークンをブラウザーコードや共有ログに出さないでください。
以下はMessaging APIリファレンスのエンドポイントとフィールドを使ったNode.jsの例です。実際のトークンとユーザーIDを渡してください。実行済みの結合テストではなく、説明用のコードです。
async function showLoading(channelAccessToken, userId) {
const response = await fetch(
'https://api.line.me/v2/bot/chat/loading/start',
{
method: 'POST',
headers: {
Authorization: `Bearer ${channelAccessToken}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({
chatId: userId,
loadingSeconds: 5
})
}
);
if (!response.ok) {
throw new Error(`Loading request failed: ${response.status}`);
}
}
最初のテストでは、ユーザー側のLINEアプリでトークを開いたままにし、表示中は公式アカウントから別のメッセージを送らないようにします。HTTPの結果と、テスターが見た内容は別々に記録してください。HTTP成功は既読通知ではありません。
この関数には再試行や回答送信を含めていません。見た目のフィードバックに失敗しただけで業務ジョブをもう1つ作ったり、用意済みの回答を遅らせたりしないためです。
表示されない・すぐ消える場合の切り分け
| 症状 | 最初の確認 | 推奨する対応 |
|---|---|---|
| グループで何も表示されない | 対象外のトークではないか | グループIDで再試行し続けない |
| ユーザーが別画面にいると表示されない | 対象トークを開いているか | トークを開いて条件をそろえて再テスト |
| 後から開いても表示されない | 遅延通知ではない | 次回表示を約束しない |
| 受付メッセージが届くと消える | 公式アカウントのメッセージは表示を終了させる | テキストの受付通知とアニメーションの順序を決める |
| 想定より長く表示される | 別のリクエストが時間を上書きした可能性 | 全ワーカー・ツールの呼び出しを確認 |
| HTTPリクエストが失敗する | 認証情報、宛先、本文、実際のAPI応答 | UIを変える前にリクエストを調査 |
これは調査の分岐であり、新しいLINEエラーコードではありません。複数ツールが動く構成では、1つのLINE公式アカウントに複数ツールを接続するチェックリストで呼び出しの担当を整理してください。別々のワーカーが同じ表示を更新し続ける設計は避けます。
表示タイマーを業務処理から分離する
推奨するアプリケーション設計は次のとおりです。
- 視覚的なフィードバックに頼る前に、受信した処理要求を検証し、永続化する。
- 回答の判断を1つのジョブに持たせ、対象となる1対1のやり取りで必要な場合だけ短いアニメーションを要求する。
- 実際の処理は独立して実行する。アニメーションの失敗で保存済みの仕事を破棄しない。
- 結果ができたら適切な送信操作で回答する。表示終了まで待つ必要はない。
- 長い処理には明示的な遅延回答ポリシーを用意し、無期限の表示更新ループにしない。
LINEは、表示中の2回目のリクエストで、消えるまでの時間が上書きされると説明しています。これは表示のルールです。サーバー処理の時間を延長したり、返信の機会を予約したりする仕組みではありません。
UnifyPortでできることとできないこと
UnifyPortの非公式インターフェースは、接続したアカウントを利用する別経路です。LINE認証ガイドはQRコード認証を説明しており、公式アカウントにチャネルアクセストークンを設定する手順ではありません。
現在の公開プロバイダー操作一覧には、このローディングアニメーション操作はありません。入力中表示のエンドポイントを想定したり、標準化された送信リクエストへ chatId と loadingSeconds を追加したりしないでください。テキスト送信リファレンスでは、POST /v1/messages に account_id、to、message を指定します。
公式アカウントのこのアニメーションが必須なら、公式Messaging APIを使います。接続アカウントの受信箱では、担当者用の自社画面に処理状態を表示し、文書化された送信機能だけを使ってください。そのローカルな状態表示はLINEトークのアニメーションとは別です。
FAQ
LINEグループでも使えますか?
いいえ。公式アカウントとの1対1トークが対象で、グループや複数人トークは対象外です。
トークを見ていないユーザーに通知されますか?
いいえ。通知は送信されず、後からトークを開いても以前の要求によるアニメーションは表示されません。
loadingSecondsで返信トークンを延長できますか?
そのような仕様はありません。表示タイマーと返信操作を分離してください。
指定した時間より早く消えるのはなぜですか?
公式アカウントから新しいメッセージが届くと終了します。タイマーや他の呼び出しと合わせて確認してください。
次のステップと資料
公式の表示ガイドに沿って条件をテストしてください。UnifyPortを利用する場合は、顧客向けUIを設計する前に操作一覧を確認します。
公式資料の確認日:2026-10-20。
メッセージ連携を安定したプロダクトパイプラインへ。
まずは 1 つの API で送信を始め、標準イベントですべての inbound メッセージを業務システムへ戻しましょう。