Messaging APIとは。LINE公式アカウントとの関係と導入の判断

Messaging APIは、LINE公式アカウントと自社のプログラムを接続し、メッセージの送受信などを行う仕組みです。例えば、利用者の問い合わせを受けて自社DBを確認する、注文の状態に合わせて案内を送るといった処理を作れます。

ただし、APIを有効にするだけで予約や顧客管理が完成するわけではありません。LINEとの通信を担う部分と、自社の業務を処理する部分を分けて理解すると、必要な開発と費用を判断しやすくなります。本記事は2026年9月8日に確認した公式資料を基にした入門ガイドです。

LINE公式アカウント、チャネル、Botの違い

公式アカウントは、利用者が友だち追加し、メッセージをやり取りする窓口です。Messaging APIは、その窓口をプログラムから使うための機能です。LINE Developers上のチャネルには、通信に必要な設定や認証情報があります。Messaging APIの公式概要

名前	役割	担当者が確認すること
LINE公式アカウント	利用者に見える窓口	名称、運営主体、配信・チャット担当
Messaging APIチャネル	LINEとの接続設定	管理権限、認証情報、Webhook設定
Botのサーバー	受信内容を判断し、必要な処理を行う	稼働、更新、エラー時の対応
業務DB・外部システム	注文・予約・会員などの情報を管理	最新状態、本人の権限、更新方法

一般に「LINE Bot」と呼ばれるものには、サーバー側のプログラムが含まれます。メッセージに応答するだけの小さな処理も、予約DBや管理画面を持つ業務システムもあるため、名前だけで開発範囲は決まりません。

標準機能でできることを先に確認する

同じ文面を配信する、営業時間を案内する、共通の予約ページへリンクするだけなら、管理画面の機能で運用できる場合があります。対象を分ける機能にも標準のオーディエンスやステップ配信があります。

やりたいこと	最初に検討するもの	APIを検討するきっかけ
営業案内を送る	管理画面の配信	外部データに合わせた自動生成が必要
予約ページを見せる	共通リッチメニュー	会員・予約状態ごとに表示を変えたい
よくある質問に答える	応答メッセージ・チャット	自社DBの情報を確認して回答したい
特定の人へ案内する	オーディエンス等	対象の頻繁な更新や個別の時刻が必要
予約を確定する	既存予約サービスとの役割分担	空き枠や変更・取消を業務DBで処理したい

「管理画面では何も自動化できない」「APIならすべてできる」という二択にはしません。機能の比較は標準機能の範囲、詳細な制限はAPIでできること・できないことを参照してください。

受信はWebhook、送信は返信やPushを使う

利用者がメッセージを送るなどすると、LINEから設定したサーバーへイベントが送られます。これがWebhookです。サーバーは受け取った内容を基に、必要な業務処理や返信を行います。Webhook受信の公式ガイド

通信	何のために使うか	設計時の注意
Webhook受信	メッセージや操作等をサーバーへ知らせる	署名、重複、処理時間、障害を扱う
応答メッセージ	受信イベントに対して返信する	応答トークンの使用条件に従う
Push等	必要なタイミングで案内を送る	宛先条件、通数、再試行を確認する

返信は受信したイベントに対するもので、任意の日時まで返信用トークンを保存して使い続ける仕組みではありません。後日の完了案内は、Push等の方式と条件を確認します。公式のメッセージ送信ガイド

Pushは誰にでも送れるわけではなく、友だち等の条件があります。条件外やブロック等ではHTTP 200でも配信されない場合があるため、送信受付を「顧客が読んだ」と扱いません。Pushの公式条件

予約DBが正しい状態を持ち、LINEは結果を知らせる

架空の工具レンタル店で、利用者が「予約内容を確認したい」と操作する例を考えます。サーバーは本人と予約の対応を確認し、予約DBから日時と店舗を取得して、必要な案内を返します。

このとき、トークに以前送った日時を最新情報として扱うと、その後の変更が反映されません。業務DBを正とし、確認するたびに現在の状態を参照する設計が必要です。予約番号を入力しただけで別人の予約を見せないように、本人確認も含めます。

予約の確定と通知の送信も分けます。通知が失敗しても予約自体が成立しているなら、管理画面では「予約確定・通知要確認」のように扱える方が、担当者が判断しやすくなります。詳しい状態の設計はLINE予約受付の記事で説明しています。

導入では現在のチャネル作成手順を使う

現在はLINE公式アカウントを用意し、LINE Official Account ManagerでMessaging APIを有効にする手順が公式に案内されています。古い記事の画面やチャネル作成手順と異なる場合があるため、現行の公式ガイドで設定します。Messaging APIの開始手順

既に外部の配信ツールやBotが接続されている場合は、Webhook設定や認証情報の利用先を確認します。既存設定を上書きして別のツールへ接続すると、現在の自動応答や顧客データ連携が止まる可能性があります。

発注前に整理するのは、アカウントの管理主体、現在の接続先、既存データ、追加したい処理、公開後の保守担当です。自社の管理者が必要な設定へアクセスできる状態にしておくと、委託先変更にも備えられます。

本番運用には、署名と重複の確認が必要

外部から届くWebhookは、LINEから送られた正しい内容か確認します。公式手順では受信した本文とチャネルシークレットを使って署名を検証するため、検証前に本文を整形・変換しないことが重要です。署名検証の公式ガイド

同じイベントが複数回来ることや、処理途中でサーバーが止まることも想定します。二重の予約登録や重複通知を防ぐため、イベントの識別と業務処理の状態を管理します。Webhookの再送があるからすべて自動復旧する、という保証にはしません。Webhook受信時の公式注意事項

これらは「メッセージが一回返った」という確認だけでは分かりません。試作と業務で使える状態を区別し、必要な受入条件を契約に含めます。

APIの費用と、システムを運用する費用を分ける

Messaging APIの利用に当たっては、LINE公式アカウントのメッセージ通数や料金プランを確認します。返信とPush等では通数の扱いが異なりますが、返信がカウント対象外であることを、サーバーや外部サービスも含む無制限・無料の意味にはしません。公式の料金説明

費用の区分	見積で確認するもの
初期開発	会話・画面、DB連携、管理機能、受入確認
LINEの配信	対象人数、回数、通常・臨時通知、プラン
実行環境	サーバー、DB、ログ、監視
外部サービス	予約・顧客管理・AI等の利用条件と従量費
保守・運用	問い合わせ、障害対応、仕様変更、原稿更新

APIの設定作業と業務システムの開発を一つの金額だけで示さず、何を納品し、公開後に誰が何を行うかを確認します。

初めて外注するときの受入確認表

確認する場面	合格の判断
正常な問い合わせ	意図した案内へ進み、必要なら有人へ渡せる
本人以外の予約照会	他人の情報を返さない
同じ操作を繰り返す	同じ予約・処理を重複して作らない
外部DBが停止する	未完了を確定済みと伝えない
通知が成立しない	業務状態と送信状態を分けて確認できる
管理担当が変わる	設定、コード、監視、停止手順へアクセスできる
配信数が増える	費用と上限を担当者が確認できる

まず一つの業務の入口から完了までを書き出し、その途中で人が判断する部分とシステムが処理する部分を分けると、Messaging APIを使う目的が具体的になります。

よくある質問

Messaging APIとLINE公式アカウントは別物ですか？

公式アカウントは利用者に見える窓口で、Messaging APIはその窓口をプログラムから利用する仕組みです。APIを有効にするだけで予約や顧客管理が完成するわけではありません。

標準機能があってもAPI開発は必要ですか？

自社DBの確認、頻繁なデータ同期、個別のタイミングの通知などが必要なら候補になります。共通の案内やリンク、標準オーディエンスで足りる場合は、まず管理画面での運用を検討します。

APIが成功を返したら相手に届いたと判断できますか？

送信方式によっては、ブロック等でHTTP 200でも配信されない場合があります。API受付、業務処理の完了、顧客の確認は別に扱い、必要な確認先を用意します。

Messaging APIは無料で運用できますか？

LINEの配信通数・プランに加え、サーバー、DB、外部サービス、保守などの費用を確認します。返信が通数のカウント対象外でも、システム全体が無制限に無料になるわけではありません。

この記事に関連するサービス

Messaging APIが必要な範囲を、標準機能や既存の予約・顧客管理との役割分担から確認したい方は、LINEアプリ開発のサービスをご覧ください。

LINEアプリ開発のサービス・相談窓口を見る