LIFFのsendMessagesで403が出るとき｜起動元・権限・受付完了を確認

liff.sendMessagesで403エラーが出たら、LINEへのログインだけでなく、LIFFを開いた場所・chat_message.writeの権限・再読込の経路を確認します。このメソッドは、ユーザーの代わりに、LIFFが開かれているトークルームへ送信するための機能です。送信先を自由に指定するサーバーの配信とは別です。

フォームから内容をトークへ送る設計でも、メッセージの送信成功と、注文や問い合わせを業務側で受け付けたことを分けてください。どちらか一方だけを確認して、両方完了と表示しないようにします。

まず、どこからLIFFを開いたかを確認する

liff.sendMessagesの公式仕様には、利用条件として次の三つが示されています。

1対1・グループ・複数人トークから起動したLIFFアプリの、LIFFブラウザ内である。
chat_message.writeスコープが有効である。
「最近使用したサービス」から再読み込みされていない。

条件を満たさない場合、403のuser doesn't grant required permissions yetエラーが発生します。公式にはKeepメモからの起動、Webサイトのリダイレクト経由、ユーザーが権限を認可しなかった場合などの例もあります。

開発用の外部ブラウザでLIFFへログインできたことを、この送信機能の確認済みにはしません。同じURLでも、実際に使うトークから開いた場合と、保存したリンクを別の場所から開いた場合を分けて確認してください。

開いた場所と、同意された権限を調べる

起動元に関する情報はliff.getContextで取得できます。ただし、起動元の情報だけで、権限もそろったとは判断しません。LINE Developersコンソールのスコープ設定と、ユーザーが認可した範囲を照合します。

LIFF間で移動する構成では、移動後のアプリのchat_message.writeが無効になっていないかも確認します。詳しい条件はLIFF間遷移の公式説明にあります。

ユーザーが送信の権限を認可しなかった場合は、その意思をエラーとして押し戻し続けないようにします。入力した内容をどう扱うかを説明し、自社で実際に用意している受付方法へ戻れる案内を出します。代わりに何度も自動送信したり、存在しない連絡先へ案内したりする設計にはしません。

LIFFのsendMessagesの確認図。利用条件は、トークから開いたLIFFブラウザ、chat_message.writeの権限、最近使用したサービスからの再読込ではないことを合わせて確認する。条件に合わない場合は起動経路と権限を調べ、送信成功後も業務の受付結果を別に確かめる。FlexやテンプレートはWebhookが送られない条件にも注意する。

図の条件は全部を確認するもので、一つだけ合えば送信できるという意味ではありません。権限への同意を強制する手順でもありません。

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

sendMessages・共有・サーバーの配信を混ぜない

sendMessagesは、LIFFが開かれているトークへの送信です。相手を選んで共有するshareTargetPicker、サーバーからMessaging APIで行う配信は、それぞれ目的や条件が異なります。

たとえば、問い合わせフォームの入力内容を、現在のトークへユーザーのメッセージとして送る架空の設計なら、sendMessagesの条件を確認します。「友人へ内容を勧める」操作なら、送信先を選ぶ共有を別に検討します。エラーを避けるために、別の機能へ無条件に置き換えて同じ動作と説明しないでください。

共有画面を閉じた結果はshareTargetPickerのキャンセル判定、サーバー配信の成功表示と受信の違いはpushが200でも届かない場合で整理しています。

Promiseの成功と、受付処理の成功を分ける

公式仕様では、メッセージ送信が成功するとPromiseがresolveされ、値は渡されません。失敗した場合はrejectされ、LiffErrorが返されます。

resolveされた後に表示するのは、確認できた送信結果です。自社の受付データベースへの保存や、スタッフの対応開始まで確認していないのに「受付が完了しました」と表示しないようにします。

特に、sendMessagesでユーザーから送ったFlex Messageとテンプレートメッセージでは、Webhookが送られません。見た目の整ったカードを送信できても、そのカードをWebhookで受信して受付する設計なら、処理の前提が合っていません。使用するメッセージの種類と、業務側が受付を記録する経路を確認します。

送信を繰り返しても、記録する経路がなければ解決しません。送信前の入力、送信の結果、受付側の記録を切り分け、再試行時に同じ内容を重複して登録しない確認も必要です。LIFFフォームの二重送信対策と合わせて設計できます。

問い合わせを受けたときに残す確認メモ

403の相談が来たら、起動した場所、使ったLIFFアプリ、権限を確認した範囲、止まった操作を残します。本文や個人情報をログへ丸ごと保存せず、調査に必要な条件を共有します。

お客さんには、何がまだ送信・受付されていないか、次にどの操作をすればよいかを説明します。開発者向けのエラー名だけを見せるより、入力が失われるのか、再入力が必要なのかを判断できる案内を優先してください。送信失敗の調査と、相手への次の案内を同じ記録で追えると、担当者が変わっても説明を繰り返しにくくなります。

※仕様確認日：2026年10月13日。メソッドの条件は公式資料、フォームと受付の説明は架空の設計提案です。