LINEサービスメッセージとは:使うべき場面とWebhook受信に分ける場面
LINEサービスメッセージは、LINE MINI App内でユーザーが行った操作に対して、確認やリマインドなどユーザーが知るべき情報を通知する機能です。一般的なLINE Messaging APIのpush、自由文のチャットボット返信、カスタマーサポート用の受信箱とは別物です。予約確認のような通知には向いていますが、ユーザーからの問い合わせを受けて振り分ける用途ではWebhook受信レイヤーを分けて考えるべきです。
要点
- LINE公式ドキュメントでは、service messagesはLINE MINI Appのユーザー操作に対する通知機能として説明されています。
- 送信には、審査済みのservice message templateとservice notification tokenが必要です。
- 公式ドキュメントは予約完了や前日リマインドを例に挙げ、1つの予約操作につき最大5件のservice messagesを送れると説明しています。
- LINEの問い合わせ、サポート振り分け、LINEとWhatsAppやZaloなどの統合キューには、inbound webhookの設計が必要です。
- 公式機能の比較は LINE Service Messages vs Messaging API を、トークン実装は notification tokenガイド を参照してください。
LINEサービスメッセージとは何か
LINE Developersの説明では、service messagesはLINE MINI Appの機能で、MINI App上の特定のユーザー操作への応答または確認として、ユーザーが知るべき情報を通知します。重要なのは「LINEでメッセージを送れるか」ではなく、「MINI App内の操作に紐づいているか」です。
そのため、これはトランザクション通知に近い機能です。日本ではLINEが顧客接点の中心になることが多いため、予約、注文、来店前リマインドなどには便利です。一方で、ユーザーが質問を返す、写真を送る、担当者に引き継ぐ、といったサポート会話には別の受信設計が必要です。
公式の送信フロー
LINEの公式フローは次の3段階です。
- LINE Developers Consoleで、LINE MINI App channelにservice message templateを追加する。
- templateをLY Corporationの審査に通す。
- ユーザー操作後にservice notification tokenを発行し、そのtokenでservice messageを送信する。
同じ公式ドキュメントでは、templatesはLY Corporationが提供するものから選択し、1つのLINE MINI App channelにつき最大20個のservice message templatesを設定できると説明されています。つまり、テンプレートは単なるAPI payloadではなく、プロダクト文言、運用、審査を含む設計要素です。
| 判断項目 | Yes | No |
|---|---|---|
| MINI App内のユーザー操作に紐づく通知か | service messagesを検討 | 別のメッセージ経路を検討 |
| LINE MINI App channelがあるか | templateとtokenを準備 | 最初の実装としては重い可能性 |
| 内容が審査テンプレートに収まるか | 提出してテスト | 通知設計を見直す |
| ユーザー返信をサポートに回す必要があるか | inbound webhookを追加 | 単方向通知で十分 |
チャットUIテンプレートとの違い
LINE Messaging APIにもtemplate messagesがあります。公式ドキュメントでは、buttons、confirm、carousel、image carouselなどが説明されています。confirm templateは2つのボタンを持ち、quick repliesは対応メッセージに最大13個の返信ボタンを表示できます。
これらはLINE Official Accountの会話UIです。service messagesはLINE MINI Appの通知機構で、template審査とnotification tokenの流れを持ちます。「LINEサービスメッセージとは」という検索意図に対する短い答えは、ユーザー操作後に送る審査済みMINI App通知であり、汎用のチャットテンプレートではない、ということです。
Webhook受信レイヤーを使う場面
ユーザーが返信する、別の質問をする、またはLINE以外にWhatsApp、Zalo、Telegram、TikTok、Xも扱う場合、課題は送信ではなく受信になります。イベントを受け取り、署名を検証し、保存し、担当者やAIワークフローへルーティングする必要があります。
UnifyPortのAPI referenceでは、LINEを含む複数プロバイダーで標準化された message.received イベントを定義しています。event envelopeには id、type、provider、account_id、occurred_at、data が入り、メッセージ情報は data.conversation、data.sender、data.message に分かれます。Webhook deliveryは signing_secret とHMAC-SHA256で検証できます。詳細は standard webhook events を参照してください。
{
"id": "evt_2f9c1a4b7e",
"type": "message.received",
"provider": "line",
"account_id": "acc_8c21d0",
"occurred_at": "2026-06-08T12:34:56Z",
"data": {
"conversation": { "id": "line_user_123", "type": "user" },
"sender": { "id": "line_user_123", "type": "user", "name": "Jordan Lee" },
"message": {
"id": "msg_10472",
"text": "予約時間を変更できますか?",
"direction": "inbound",
"sent_at": "2026-06-08T12:34:55Z"
}
}
}
service messageは操作を確認するもの、webhook intakeは会話を受けるものです。
判断ルール
MINI App操作に紐づき、審査テンプレートに収まり、サポート受信箱にならない通知ならLINE service messagesを使います。LINEや複数チャネルのメッセージを受け取り、分類し、ルーティングすることが主目的なら、署名付きWebhook受信レイヤーを使います。
公式LINE機能の比較は LINE Service Messages vs Messaging API から始めてください。受信側を作る場合は、webhook event reference を開き、まずendpointを登録します。
FAQ
LINE service messagesとMessaging API pushは同じですか?
同じではありません。service messagesはLINE MINI Appの機能で、ユーザー操作とtemplateに紐づきます。Messaging API pushはLINE Official Accountのメッセージ送信面です。
service messagesでユーザー返信を処理できますか?
service message自体は通知機構です。返信を受けてサポートに流すなら、inbound webhook queueを別に用意します。
MINI App channelに設定できるtemplatesの数は?
LINE公式のservice-messageドキュメントでは、1つのLINE MINI App channelにつき最大20個のservice message templatesを設定できると説明されています。
2026-08-27に確認した公式情報
- LINE Developers: Sending service messages
- LINE Developers: Message types
- LINE Developers: Use quick replies
- LINE Developers: Re-review after updating your verified MINI App
メッセージ連携を安定したプロダクトパイプラインへ。
まずは 1 つの API で送信を始め、標準イベントですべての inbound メッセージを業務システムへ戻しましょう。