LINE Messaging APIとWebhookの仕組み｜外部サービス連携の始め方と注意点

「LINEに送られた内容をスプレッドシートへ記録したい」「予約状況を調べて、自動で返信したい」。こうした仕組みを作る際に登場するのが、Messaging APIとWebhookです。

Messaging APIは、LINE公式アカウントと自分のシステムをつなぐためのAPIです。その連携の中で、メッセージの受信などを自分のサーバーへ知らせる仕組みがWebhookです。受信後に何を調べ、どこへ保存し、どう返信するかは、アプリ側で設計します。

この記事では、LINE公式アカウント・Messaging API・Webhookの役割から、外部サービスとの連携手順、返信や再送で間違えやすい点までを整理します。仕様に関する説明は、2026年10月17日時点の公式ドキュメントを基にしています。

１．LINE公式アカウント・Messaging API・Webhookの違い

最初に、それぞれの役割を分けて考えましょう。利用者が見るトーク画面と、その裏側で動くプログラムは、別の場所にあります。

LINEのWebhookでは、ユーザーのメッセージ送信や友だち追加などに応じて、登録したURLへHTTP POSTリクエストが届きます。自分のサーバーが何度も「新しいメッセージはありますか」と問い合わせる方式とは異なります。

ただし、Webhookを設定しただけで、予約管理やデータ保存が完成するわけではありません。通知の内容を受け取った後の処理を、自分のアプリや連携サービスで用意する必要があります。

２．メッセージを受信して返信するまでの流れ

例えば、利用者がLINE公式アカウントへ「営業時間」と送ったとします。サーバーがその内容を確認し、管理している営業時間を返信する流れは、次のようになります。

WebhookへのHTTP応答と、トークへの返信を区別する

Webhookの受信処理でHTTP 200を返すことと、利用者へメッセージを送ることは別です。HTTP応答は、LINEから自分のサーバーへ届いた通信に対する応答であり、それだけではトーク画面に文章は表示されません。

利用者へ返信するには、別途、Messaging APIの応答メッセージ送信を呼び出します。「Webhookの検証は成功するのに返信が来ない」という場合は、受信と送信を分けて確認しましょう。

３．Messaging APIとWebhookを使い始める手順

手順１：公式アカウントでMessaging APIを有効にする

LINE公式アカウントを用意し、LINE Official Account ManagerからMessaging APIの利用を有効にします。その後、LINE Developersコンソールで、作成されたMessaging APIチャネルを確認します。

古い解説には、LINE DevelopersコンソールからMessaging APIチャネルを直接作成する手順が載っている場合があります。現在は公式アカウント側から有効にする流れなので、公式ドキュメントと照合してください。

途中で選択する「プロバイダー」は、チャネルを管理する企業や開発者などのまとまりです。後から別のプロバイダーへ変更できないため、個人の試作用と組織の本番用を区別し、管理する主体を確認して選びましょう。

手順２：Webhookを受け取る実行環境を用意する

Webhook URLには、LINEからアクセスできるHTTPSの受信先が必要です。ここでいうサーバーは、自分で機器を購入するという意味ではなく、クラウド上のアプリ実行環境やサーバーレス環境なども含みます。

必要なのは、POSTリクエストを受け取り、ヘッダーと本文を確認し、処理を実行できる環境です。紹介ページを表示するだけの静的ホスティングとは、必要な機能が異なります。

手順３：秘密情報をサーバー側で管理する

Messaging APIの実装では、似た名前の情報を使い分けます。特に、チャネルシークレットとチャネルアクセストークンを混同しないようにしましょう。

秘密情報は公開リポジトリや、ブラウザへ配信するJavaScriptに含めません。実行環境のシークレット管理機能などから読み込み、ログやスクリーンショットへ写り込まないようにしてください。

手順４：Webhook URLを設定し、実際のトークで確認する

LINE DevelopersコンソールでWebhook URLを登録し、検証したうえで「Webhookの利用」を有効にします。検証ではイベント一覧が空のリクエストも届くため、メッセージが必ず１件入っている前提で実装しないようにします。

疎通確認ができたら、テスト用の公式アカウントへ実際にメッセージを送り、受信・処理・返信を確認してください。管理画面の応答メッセージも有効な場合は、ボットからの返信と重複しないよう役割を整理します。

４．Webhookを処理する前に、署名を検証する

公開したWebhook URLには、LINE以外からもリクエストが届く可能性があります。そのため、送られてきたJSONをそのまま信用して、データ保存や返信を実行してはいけません。

LINEのWebhookでは、リクエストヘッダーの「x-line-signature」と、受信した本文、チャネルシークレットを使って署名を検証します。公式SDKを利用する場合も、受信データを正しく渡しているか確認してください。

署名検証には、受信時の本文を変更せずに使います。JSONを読み取った後に整形し直した文字列では、空白や改行などが変わり、正しいリクエストでも検証に失敗する場合があります。

署名がない場合や一致しない場合は、業務処理を進めません。また、署名が正しいことと、その利用者に予約の変更権限などがあることは別なので、業務上の権限確認も行います。

５．応答メッセージとプッシュメッセージを使い分ける

「今届いた操作への返信」と「後から送る通知」では、使う送信方法が異なります。受信したreplyTokenを保存しておけば、いつでも返信できるという仕組みではありません。

応答トークンは一度だけ使用でき、公式仕様ではWebhook受信後１分以内に使う必要があります。ネットワーク状況などの影響もあるため、期限ぎりぎりを前提にせず、可能な限り早く使用します。

外部処理に時間がかかる場合は、先に受付を伝え、完了後に別の方法で通知する設計を検討します。その際も、プッシュ送信の対象条件を満たすか確認し、ユーザーIDを持っているだけで誰にでも送れるとは考えないでください。

送信方法によって、通数の扱いが変わる

現在の公式説明では、応答メッセージは料金プランのメッセージ通数にカウントされず、プッシュメッセージなどはカウント対象です。一方、サーバー、データベース、連携サービスなどの費用は別に確認する必要があります。

「APIを使えば、すべて無料で送信できる」という意味ではありません。通知の回数と対象人数を整理し、契約プランの上限や最新の料金条件を確認しましょう。

６．外部サービス連携は、小さな処理から作る

最初から予約、会員管理、通知をまとめて実装すると、どこで失敗しているか分かりにくくなります。まずは固定の返信、その次に外部データの取得、最後に保存や更新という順で範囲を広げると、動作を切り分けやすくなります。

例：LINEで学習記録を受け付ける

ここでは、「数学を30分勉強した」という記録を受け付ける学習用アプリを考えます。以下は設計を説明するための例であり、実際に運用した事例ではありません。

1. 受信する：Webhookの署名を検証し、テキストメッセージか確認する。
2. 内容を確認する：科目と学習時間を読み取り、不足や不正な値があれば入力方法を案内する。
3. 保存する：対象ユーザー、日時、科目、時間を、必要な範囲で記録する。
4. 結果を伝える：保存の成功を確認してから、登録した内容を返信する。

この例なら、自由な長文を理解する機能より、まず「数学 30」のように入力形式を決めた方が確認しやすくなります。保存に失敗したときに「記録しました」と返信しないことも重要です。

会員情報と結び付ける場合は、LINEの表示名だけで本人を判断しません。既存サービスへのログインなどを使ったアカウント連携を設計し、どの会員の情報を扱ってよいかを確認します。

画面で入力する方が分かりやすい場合もある

日付、時間帯、複数の選択肢を入力する場合は、トークで何往復もするより、Webフォームを開く方が使いやすいことがあります。入力画面を提供するLIFF・LINEミニアプリと、メッセージを扱うMessaging APIを組み合わせる方法もあります。

「トークで何でも完結させる」と決めず、利用者が迷わず操作できる方法を選びましょう。入力画面、保存処理、通知を分けると、それぞれに必要な機能を整理できます。

７．再送・処理遅延・二重返信への対策

同じWebhookが届いても、二重登録しない

通信の問題やWebhookの再送により、同じイベントを複数回受け取る可能性があります。受信のたびに行を追加する実装では、学習記録や予約が二重に登録されるおそれがあります。

イベントを識別する「webhookEventId」を使い、同じイベントによる処理が重複しないよう管理します。並行して受信した場合も考え、データベースの一意制約などを組み合わせて、確認と登録の間に二重処理が起きないようにします。

また、「受信済み」と「保存完了」は別の状態です。受信済みにした直後に処理が失敗する場合もあるため、未処理・処理中・完了・失敗などを管理し、再開できる方法を用意してください。

重い処理を、Webhookの応答まで待たせない

時間のかかる外部処理は、キューなどへ受け渡し、Webhookの受信処理から分離する方法があります。ただし、後で処理できる形で受け付ける前に成功応答を返すと、途中で停止した際に処理が失われる可能性があります。

非同期にした後の失敗は、自分のシステム側で検知・再試行できるようにします。Webhookの再送は業務処理の完了を保証する機能ではなく、受信順序がイベントの発生順序と異なる場合もあります。

不具合は、受信・処理・送信に分けて調べる

ログには、イベントID、処理段階、成功・失敗、APIの応答など、調査に必要な情報を残します。アクセストークンや会話全文を無条件に記録せず、保存期間と閲覧できる担当者も決めてください。

８．LINE連携でよくある質問

Webhook URLは、利用者が開く予約ページのURLですか？

用途が異なります。Webhook URLはLINEから通知を受け取るためのサーバー側の窓口であり、予約ページは利用者が画面を操作するためのURLです。同じアプリの中に用意する場合も、処理を分けます。

Webhook URLを複数登録して、別々のサービスへ送れますか？

Messaging APIチャネルに設定できるWebhookエンドポイントは一つです。複数の処理へつなぐ場合は、受信先で振り分ける構成などを設計します。既存の連携サービスを利用している場合は、URLを変更する前に影響を確認してください。

スプレッドシートへ記録することはできますか？

ボットサーバーから、スプレッドシート側のAPIなどを利用して記録する構成にできます。LINEへの接続とは別に、保存先への認証・権限、入力値の確認、二重登録や書き込み失敗への対策が必要です。

キーワードへの定型返信だけでもAPI開発が必要ですか？

まず、LINE公式アカウントの管理画面で設定できる応答機能が、目的を満たすか確認しましょう。外部データに応じた返信、保存処理、利用者ごとの処理などが必要になった段階で、Messaging APIによる連携を検討できます。

９．最初は「受信して一度返信する」ところから始める

LINE連携では、利用者の操作をWebhookで受け取り、アプリ側で必要な処理を行い、Messaging APIで結果を届けます。この流れを分けて理解すると、開発する範囲も、不具合を調べる場所も明確になります。

まずはテスト用アカウントで、署名を検証して定型文を一度返信するところまで確認してください。その後、外部データの取得、保存、通知へと段階的に広げ、各段階で失敗時の動作も確かめていきましょう。

参考資料

• LINE Developers：Messaging APIの概要
• LINE Developers：Messaging APIを始めよう
• LINE Developers：ボットを作成する
• LINE Developers：メッセージ（Webhook）を受信する
• LINE Developers：Webhookの署名を検証する
• LINE Developers：Messaging APIリファレンス・応答メッセージを送る
• LINE Developers：Messaging APIの料金