顧客向けのWebシステムを作るとき、
「予約完了をLINEで通知したい」
「問い合わせをLINEから受け付けたい」
「Webシステムのステータス変更をLINEへ知らせたい」
「LINE公式アカウントと顧客データを連携したい」
といった要望が出ることがあります。
こうした仕組みで利用できるのが、LINE公式アカウントのMessaging APIです。
Messaging APIを利用すると、LINE公式アカウントと自社のWebシステムを接続し、
- メッセージ送信
- ユーザーからのメッセージ受信
- 自動返信
- 予約・受付
- ステータス通知
- リッチメニュー
- ユーザーごとのメニュー切り替え
- 自社サービスとのアカウント連携
などを実装できます。
LINE公式アカウントでMessaging APIを利用するには、LINE公式アカウントを作成し、Messaging APIを有効化してチャネルを利用する構成になります。ユーザーが友だち追加したりメッセージを送信したりすると、LINE Platformから登録したWebhook URLへイベントが送信されます。
例えば予約システムなら、
ユーザーがWebで予約
↓
予約情報をDBへ保存
↓
LINE API
↓
「7月31日10時に予約を受け付けました」と通知
という連携が可能です。
また、
ユーザーがLINEで「予約確認」と送信
↓
Webhookで受信
↓
自社システムから予約情報を取得
↓
LINEへ返信
という双方向の仕組みも作れます。
ただし、LINE API連携では、
「LINEからメッセージを送る」だけではなく、LINEユーザーと自社システムの顧客をどう紐づけるか
が重要です。
この記事では、LINE公式アカウントAPI連携でできること、通知・問い合わせ・予約への活用方法、Webhook、自社DBとの連携、設計時の注意点まで具体的に解説します。
LINE API連携とは
一般的に「LINE API連携」と呼ばれるものには複数の仕組みがあります。
顧客とのメッセージ送受信やLINE公式アカウント連携で中心になるのがMessaging APIです。
Messaging APIでは、
自社システムからLINEへ
- メッセージ送信
- 通知
- リッチメニュー設定
などを行えます。
LINEから自社システムへ
- メッセージ受信
- 友だち追加
- ボタン操作
などのイベントをWebhookで受け取れます。
そのため、
LINE
↕
Webシステム
↕
データベース
という連携を作ることができます。
LINE NotifyではなくMessaging APIを利用する
以前は、システムからLINEへ簡単に通知する方法として「LINE Notify」が利用されていました。
しかしLINE Notifyは2025年3月31日にサービスを終了しており、2025年4月1日以降はAPIを含むLINE Notifyの機能は利用できません。
LINE公式では、通知用途の代替手段としてMessaging APIの利用を案内しています。
そのため、現在LINE通知を新しく実装する場合は、
「LINE Notifyを使う」
ではなく、
LINE公式アカウント＋Messaging API
を前提に検討します。
古い技術記事ではLINE Notifyを利用したサンプルが残っていることがあるため注意が必要です。
LINE API連携でできること
具体的な活用例を見ていきます。
1．予約完了をLINEで通知する
予約システムとの連携です。
例えば、
ユーザー
↓
Web予約フォーム
↓
7月31日10:00を予約
↓
予約DBへ登録
↓
LINE通知
とします。
LINEには、
「ご予約を受け付けました」
予約日時：7月31日 10:00
場所：○○店
のようなメッセージを送ります。
メールだけで予約通知を行っている場合に、LINEも通知手段として追加できます。
2．予約前日にリマインドする
例えば、
予約日時：7月31日10:00
なら、
7月30日10:00
↓
対象予約を検索
↓
LINE API
↓
予約前日メッセージ
とします。
美容院、クリニック、スクール、イベント、ワークショップなどの予約管理と相性があります。
3．問い合わせをLINEで受け付ける
LINE公式アカウントへユーザーがメッセージを送ると、そのイベントをWebhookで自社サーバーへ受け取れます。Webhookでは署名検証を行い、LINE Platformから送られた正当なリクエストか確認することが公式に求められています。
例えば、
ユーザー：
「商品の返品について相談したい」
↓ Webhook
問い合わせ管理システム
↓ 自動登録
問い合わせID：INQ-00125
チャネル：LINE
ステータス：未対応
という処理ができます。
担当者はLINE管理画面ではなく、自社の問い合わせ管理システムから一元的に対応状況を確認できます。
4．問い合わせへ自動返信する
ユーザーからメッセージを受信した場合、Webhookイベントに含まれるreply tokenを利用して返信できます。
公式仕様ではreply tokenは1回だけ利用でき、受信後できるだけ早く利用する必要があります。
例えば、
ユーザー：
「営業時間は？」
↓ Webhook
システム：
キーワード判定
↓ Reply API
「営業時間は10:00〜18:00です」
と自動返信できます。
さらに、
- FAQ
- データベース検索
- AIチャットボット
などと組み合わせる方法もあります。
5．ステータス変更をLINEへ通知する
業務システム側の状態変化をLINEへ通知できます。
例えば修理受付なら、
受付
↓
修理中
↓
修理完了
↓
受取可能
というステータスがあります。
修理完了時に、
「修理が完了しました。店頭でお受け取りいただけます。」
とLINEへ通知します。
ほかにも、
- 注文受付
- 発送
- 審査完了
- 申請結果
- 作業完了
などに利用できます。
6．支払い・請求の案内を送る
例えば会員管理システムで、
支払期限3日前
↓
対象ユーザー抽出
↓
LINE通知
とします。
ただし、決済情報や個人情報などを通知本文へどこまで含めるかは慎重に設計します。
例えば、
「お支払い期限が近づいています。詳細はマイページをご確認ください。」
とし、詳細はログイン後のWebシステムで確認させる方法があります。
7．LINEから受付番号を確認する
ユーザーが、
「受付状況」
を選択すると、
LINE
↓
Webhook
↓
自社DB検索
↓
現在の状態取得
↓
LINEへ返信
できます。
例えば、
受付番号：R-00125
状態：作業中
完了予定：8月2日
と返信します。
8．リッチメニューから業務システムへ誘導する
LINE公式アカウントでは、トーク画面下部にリッチメニューを表示できます。
例えば、
予約する
予約確認
問い合わせ
マイページ
というメニューです。
リッチメニューから外部の予約ページなどへリンクでき、Messaging APIを利用してユーザー単位で異なるリッチメニューを設定することもできます。
例えば、
未契約ユーザー
サービス紹介
申し込み
問い合わせ
契約ユーザー
予約
利用履歴
マイページ
問い合わせ
のように表示を変える方法があります。
LINE API連携の基本構成
システム構成は次のようになります。
LINEから自社システムへ
ユーザー
↓
LINE公式アカウント
↓
Webhook
↓
自社Webシステム
↓
データベース
自社システムからLINEへ
Webシステム
↓
Messaging API
↓
LINE公式アカウント
↓
ユーザー
この双方向連携を利用します。
LINEからの受付ではWebhookを使う
例えばユーザーが、
「予約変更したい」
とLINEへ送信した場合です。
LINE Platform
↓
Webhook URL
↓
自社システム
へイベントが送信されます。
Messaging APIでは、友だち追加やメッセージ送信などのイベント発生時に、登録済みWebhook URLへHTTPS POSTリクエストが送られます。
自社システムではイベント内容を確認し、
- 自動返信
- 問い合わせ登録
- 予約確認
- 担当者通知
などを実行します。
LINEへ送るメッセージには「Reply」と「Push」がある
LINE API連携では、この違いを理解しておくと設計しやすくなります。
Reply Message
ユーザーの操作やメッセージに対して返信する方法です。
例えば、
ユーザー：
「予約確認」
↓ Webhook
システム：
予約検索
↓ Reply
「7月31日10時に予約されています」
という流れです。
Push Message
自社システム側のタイミングでユーザーへメッセージを送る方法です。
例えば、
予約前日
↓
Push Message
↓
「明日10時から予約されています」
です。
公式仕様ではPush Messageを送信できる対象には条件があり、友だち追加済みユーザーなどが主な対象となります。
そのため、
LINEユーザーIDを知っていれば誰にでも自由に送信できる
という仕組みではありません。
LINEユーザーと自社顧客をどう紐づける？
LINE API連携で特に重要な設計です。
例えば自社システムに、
顧客ID：C00125
氏名：田中太郎
メール：tanaka@example.com
という顧客がいます。
LINE側では別のユーザーIDとして認識されます。
このままでは、
LINEのuserId Aは、自社システムのどの顧客なのか
分かりません。
そこで、
customers
customer_id：C00125
line_accounts
customer_id：C00125
line_user_id：Uxxxxxxxx
のように関連付けます。
名前だけでLINEユーザーと顧客を紐づけない
例えばLINEの表示名が、
「たなか」
だったとしても、それだけで顧客の田中太郎さんと判断するのは危険です。
同姓同名もあり、表示名はユーザーが変更できます。
そのため、
ログイン済みマイページ
↓
LINE連携
↓
本人確認
↓
LINEアカウント紐づけ
などのフローを設計します。
Messaging APIには、自社サービスのユーザーアカウントとLINEユーザーを連携するためのアカウントリンク機能も用意されています。公式の連携トークンは1回のみ利用可能で、有効期間も設定されています。
LINE連携の具体例｜予約管理システム
例えばスクール予約システムを考えます。
初回
ユーザー登録
↓
LINE連携
↓
LINE userIdと顧客IDを紐づけ
予約
Webから予約
↓
予約DB保存
↓
LINEへ予約完了通知
前日
バッチ処理
↓
翌日の予約抽出
↓
LINEへリマインド
キャンセル
ユーザーが予約ページからキャンセル
↓
予約ステータス変更
↓
LINEへキャンセル完了通知
という構成です。
LINEを予約データの保存場所にはせず、
予約データは自社システムで管理し、LINEを通知・受付チャネルとして利用する
のが分かりやすい設計です。
LINE連携の具体例｜問い合わせ管理
例えば顧客からLINEで問い合わせを受け付けます。
LINEメッセージ
↓
Webhook
↓
問い合わせDBへ登録
↓
担当者へ通知
↓
担当者が対応
とします。
問い合わせテーブルには、
問い合わせID
顧客ID
受付チャネル：LINE
内容
担当者
ステータス
受付日時
などを保存します。
これにより、
メール問い合わせ
Webフォーム
LINE
を一つの問い合わせ管理システムへまとめることも可能です。
LINE連携の具体例｜修理・作業受付
例えば修理業務なら、
LINEから受付
↓
受付番号発行
↓
作業担当者が対応
↓
ステータス更新
↓
LINE通知
とします。
例えば、
受付完了
↓
「受付番号R-00125で受け付けました」
作業中
↓
必要なら通知
修理完了
↓
「修理が完了しました」
とできます。
顧客が電話で進捗確認する件数を減らせる可能性があります。
LINE連携の具体例｜会員管理
会員システムなら、
会員DB
↓
LINEアカウント連携
して、
- 更新期限通知
- イベント案内
- 予約確認
- 会員向けページへの誘導
などに利用できます。
ただし、一斉配信と業務通知は分けて設計することが重要です。
LINE連携の具体例｜店舗受付
例えば店舗で、
LINEリッチメニュー
↓
「順番受付」
↓
Web受付画面
↓
受付登録
↓
LINE通知
という仕組みです。
順番が近づいたら、
「あと3組です」
と通知する構成も考えられます。
LINEだけですべてを処理するのではなく、
LINE
＋
Web画面
＋
業務システム
を組み合わせると柔軟に設計できます。
リッチメニューを「業務の入口」にする
LINE連携では、リッチメニューを活用するとユーザーが操作しやすくなります。
例えば、
予約する
予約確認
会員証
問い合わせ
を表示します。
ユーザーは文字を入力しなくても、ボタンから必要な操作へ進めます。
特に一般消費者向けサービスでは、
「予約」と入力してください
より、
[予約する]
ボタンを表示した方が迷いにくくなります。
LINEだけで複雑な入力フォームを作らない
LINE上の会話だけで、
氏名
住所
電話番号
希望日時
コース
オプション
支払方法
をすべて順番に聞くと、入力が長くなることがあります。
その場合、
LINE
↓
「予約する」
↓
Web予約フォーム
↓
入力完了
↓
LINEへ完了通知
とする方が使いやすい場合があります。
つまり、
LINE
- 通知
- 簡単な受付
- メニュー
- 導線
Webシステム
- 複雑な入力
- 詳細確認
- 決済
- 会員情報管理
という役割分担です。
LINE API連携を設計する7ステップ
STEP1｜LINEを使う業務を決める
まず、
- 予約
- 問い合わせ
- ステータス通知
- 会員連絡
など、対象業務を整理します。
STEP2｜通知と受付を分ける
例えば、
通知
予約前日を知らせる。
受付
問い合わせをLINEから受ける。
では必要な処理が異なります。
STEP3｜LINEユーザーと顧客の関係を決める
LINE userIdと、
- customer_id
- member_id
- user_id
などをどう紐づけるか決めます。
STEP4｜Webhookイベントを整理する
例えば、
- メッセージ
- 友だち追加
- ボタン操作
など、業務で必要なイベントだけ処理します。
STEP5｜送信するタイミングを決める
例えば、
予約直後
前日
キャンセル時
作業完了時
などです。
STEP6｜自社システム側へ履歴を残す
例えば、
通知日時
通知種類
送信先
結果
を保存します。
STEP7｜失敗時の運用を決める
例えば、
LINE送信失敗
↓
メールへ切り替える
のか、
管理者へ通知する
のかを整理します。
【コピペ用】LINE API連携設計シート
基本情報
LINE公式アカウント名：
対象サービス：
利用者：
利用目的
通知：
問い合わせ：
予約：
受付：
会員管理：
その他：
LINEから受け取る情報
メッセージ：
友だち追加：
ボタン操作：
その他：
LINEへ送る情報
予約完了：
リマインド：
ステータス変更：
問い合わせ返信：
その他：
顧客連携
自社顧客ID：
LINE userId：
連携方法：
本人確認：
解除方法：
Webhook
URL：
署名検証：
イベント：
ログ：
メッセージ
Reply：
Push：
一斉配信：
リッチメニュー
予約：
問い合わせ：
マイページ：
会員証：
エラー
送信失敗：
Webhook失敗：
再処理：
管理者通知：
Webhookでは署名検証を行う
LINEのWebhook URLは、インターネットからアクセスできるエンドポイントになります。
そのため、
POSTリクエストが来た
↓
LINEから来たと判断
してはいけません。
LINE公式ドキュメントでも、Webhookを処理する前にリクエストヘッダーの署名を検証するよう明示されています。
基本的には、
Webhook受信
↓
署名検証
↓
正しい場合のみ処理
とします。
Webhookでは重い処理を直接行いすぎない
LINE公式ドキュメントではWebhookイベントを非同期に処理することも推奨されています。
例えば、
Webhook受信
↓
AI処理30秒
↓
DB検索
↓
外部API
↓
返信
とすべて同期処理にすると、処理が不安定になる可能性があります。
必要に応じて、
Webhook受信
↓
イベント保存・キュー登録
↓
応答
その後、
非同期処理
という構成を検討します。
Channel Access Tokenを安全に管理する
Messaging APIを呼び出す際はChannel Access Tokenなどの認証情報を利用します。
そのため、
JavaScriptのフロントエンドへ直接埋め込む
といった管理は避けます。
例えば、
ブラウザ
↓
自社バックエンド
↓
LINE API
という構成にします。
秘密情報はサーバー側の環境変数や適切な秘密情報管理基盤で管理します。
LINE送信履歴を自社側にも残す
例えば顧客から、
「予約通知が来ませんでした」
と言われた場合です。
送信履歴がなければ、
- システムが送信しなかった
- APIエラーになった
- 送信したがユーザーが確認していない
などを判断しにくくなります。
そのため、
line_message_logs
customer_id
line_user_id
message_type
sent_at
status
などを保存する方法があります。
LINEメッセージの送信数・料金にも注意する
Messaging APIでは、送信方法によってLINE公式アカウントのメッセージ通数としてカウントされるものと、されないものがあります。
公式ドキュメントでは、Push・Multicast・Broadcast・Narrowcastは料金プラン上のメッセージ数としてカウントされ、Reply Messageはカウント対象外とされています。料金プランや無料通数は変更される可能性があるため、導入時に最新の公式料金を確認することが重要です。
例えば、
登録者10万人へ毎日通知
するサービスと、
予約ユーザーへ月1回通知
するサービスでは、必要な料金設計が大きく異なります。
そのため、
技術的に送れるかだけでなく、月間送信対象人数も確認する
ことが重要です。
通知を送りすぎない
LINEはユーザーが日常的に利用する通知チャネルです。
そのため、
- 予約完了
- 予約前日
- 重要なステータス変更
などは有効ですが、
業務システム内で何か変わるたびにLINE通知
すると、ユーザーにとって負担になります。
通知設計では、
LINEで知らせる必要がある情報だけに絞る
ことが重要です。
LINE通知へ個人情報を書きすぎない
例えば、
氏名
住所
電話番号
契約内容
詳細な医療情報
などをそのままLINEメッセージへ含める必要があるかは慎重に検討します。
例えば、
「ご契約情報が更新されました。マイページからご確認ください。」
と通知し、詳細は認証済みWebシステムへ誘導する方法があります。
LINE API連携でよくある失敗
失敗1｜LINE Notifyの記事を参考にする
LINE Notifyは2025年3月31日にサービス終了しています。
新規実装ではMessaging APIなど現在提供されている仕組みを確認します。
失敗2｜LINE userIdだけで顧客を判断する
自社システムの顧客IDとの紐づけを設計します。
失敗3｜表示名で顧客を特定する
表示名だけでは本人確認になりません。
適切なアカウント連携を行います。
失敗4｜Webhook署名を確認しない
第三者から偽のリクエストを送られる可能性を考えます。
署名検証を行います。
失敗5｜すべての操作をLINE内で完結させる
複雑な入力・契約・決済などはWeb画面へ誘導した方が使いやすい場合があります。
失敗6｜通知履歴を残さない
「送信されていない」という問い合わせを調査できるようにします。
失敗7｜通知回数を考えない
Push Messageなどは料金プラン上の送信数にも関係します。
失敗8｜LINE送信失敗時の業務を考えていない
LINE通知が失敗しても、予約登録そのものまで失敗させる必要があるかは別問題です。
業務処理と通知処理を分離します。
失敗9｜LINEだけを正式データとして扱う
予約・問い合わせ・会員状態などの正式データは、自社システム側で管理する方が整理しやすくなります。
LINEは受付・通知チャネルとして利用します。
LINE API連携に関するよくある質問
LINE公式アカウントから自動でメッセージを送れますか？
Messaging APIを利用してメッセージを送信できます。
返信用のReply Messageや、条件を満たすユーザーへ任意のタイミングで送るPush Messageなどがあります。
ユーザーがLINEで送った内容をWebシステムで受け取れますか？
可能です。
Webhook URLを設定し、ユーザーのメッセージイベントを自社サーバーで受信します。
LINE Notifyは今も使えますか？
利用できません。
LINE Notifyは2025年3月31日に終了しました。公式では代替候補としてMessaging APIが案内されています。
予約完了をLINE通知できますか？
可能です。
予約システム側で予約を確定した後、紐づいたLINEユーザーへメッセージを送る構成にできます。
LINEだけで予約システムを作れますか？
簡単な受付は可能ですが、日時選択、顧客情報、決済、予約変更などが複雑になる場合は、Web予約システムと組み合わせる方が設計しやすいケースがあります。
LINEユーザーと自社の会員を紐づけられますか？
可能です。
Messaging APIには自社サービスのアカウントとLINEユーザーを連携する仕組みも用意されています。
ユーザーごとにリッチメニューを変更できますか？
Messaging APIではユーザー単位でリッチメニューを設定できます。
hiro-dev-labではLINE API連携を含む業務システム設計から相談できます
hiro-dev-labでは、単純にLINE APIへ接続するだけでなく、LINEを現在の業務フローへどう組み込むべきかという段階から相談できます。
例えば、
- LINE公式アカウント連携
- Messaging API
- Webhook
- 自動返信
- 予約完了通知
- 予約リマインド
- 問い合わせ受付
- ステータス通知
- リッチメニュー
- 顧客・会員とのアカウント連携
- LINEとメールの使い分け
- 通知履歴
- Webシステム・データベース連携
- 要求整理
- 業務要件・機能要件整理
- Webシステム設計・開発
などです。
例えば、
予約した顧客へLINEで自動通知したい
LINEから受け付けた問い合わせを管理システムへ登録したい
修理完了を顧客へLINEで知らせたい
LINEユーザーと既存の会員データを紐づけたい
という場合でも、
業務フロー → LINEを使う場面 → ユーザー連携 → Webhook → 自社システム → 通知
の順番で整理できます。
まとめ｜LINE API連携は「LINEだけで業務を完結させる」のではなく「通知・受付の入口」として使う
LINE公式アカウントとMessaging APIを連携すると、
- 予約完了通知
- 予約リマインド
- 問い合わせ受付
- 自動返信
- 作業完了通知
- 会員向け通知
- リッチメニュー
- Webシステムへの誘導
などを実現できます。
基本的な構成は、
LINEからシステムへ
LINE
↓
Webhook
↓
自社Webシステム
↓
データベース
システムからLINEへ
自社Webシステム
↓
Messaging API
↓
LINE
です。
そしてLINE API連携で特に重要なのは、
- 何をLINEで通知するのか
- 何をLINEから受け付けるのか
- LINEユーザーと顧客をどう紐づけるのか
- 詳細入力をLINEとWebのどちらで行うのか
- Webhookを安全に処理するか
- 通知履歴をどう管理するか
- 送信数や料金をどう考えるか
を整理することです。
特に、
LINEは業務データそのものを管理する場所ではなく、顧客との接点として利用する
と考えると設計しやすくなります。
例えば、
LINE
↓
予約する
↓
Web予約システム
↓
予約DB
↓
LINEへ完了通知
という構成です。
通知はLINE、複雑な入力や正式データ管理はWebシステムというように役割を分けることで、利用者にとっても運営側にとっても管理しやすくなります。
「LINEから予約を受け付けたい」
「既存システムの情報をLINEへ自動通知したい」
という場合は、まず現在の業務の中で、
顧客へ知らせるために電話・メール・手作業を使っている箇所
を洗い出すところから始めると、LINE API連携によって改善できる業務を見つけやすくなります。