Messaging APIとは？LINEでできること・料金の通数カウントと実装手順を解説

Messaging APIという語は一般名詞としても使われますが、日本語で検索されるMessaging APIは、ほぼLINEヤフーがLINE公式アカウント向けに提供するAPIを指します。この記事はそのLINEのMessaging APIを対象に、できることの全体像、料金に直結する通数カウントの仕様、チャネル作成からWebhookの署名検証までの実装手順を、公式ドキュメントと料金ページの記述だけで整理します。

費用を分けるのは配信量そのものではありません。どの送信APIを使うかです。応答メッセージ（Reply API）は無料メッセージ通数にカウントされない、という一点を設計段階で外すと、月額固定費を上げる必要のない要件でもプラン変更を迫られます。

まとめ

先に結論だけ示します。根拠と例外は以降の各章で扱います。

• Messaging APIは、ボットサーバーとLINEプラットフォームがHTTPS・JSONでやりとりする仕組みです。ユーザーの送信をWebhookイベントとして受け取り、応答を返します。
• 送れるメッセージタイプは11種（テキスト、テキスト（v2）、スタンプ、画像、動画、音声、位置情報、クーポン、イメージマップ、テンプレート、Flex Message）。クイックリプライは全タイプ共通の付加機能です。
• 通数にカウントされるのはプッシュ・マルチキャスト・ブロードキャスト・ナローキャストの4系統だけで、応答メッセージ（Reply API）はカウントされません。問い合わせ応答型のボットなら無料のコミュニケーションプランのままでも成立します。予約リマインドを送る場合の通数の見積もりは予約管理システムのLINE連携と通知コストを整理した記事で試算しています。
• 通数は宛先の人数で数えます。1リクエストにメッセージオブジェクトを複数入れても通数は増えません。
• 料金プランは3種類で、コミュニケーション0円（200通）、ライト5,000円（5,000通）、スタンダード15,000円（30,000通・超過分は従量課金）。いずれも税別です。
• Webhookを処理する前に署名検証を行ってください。受信した生のリクエストボディを一切加工せずHMAC-SHA256にかけます。

Messaging APIの定義とボットサーバーを介した双方向通信

LINE Developersの「Messaging APIの概要」は、このAPIを「ユーザー個人に合わせた体験をLINE上で提供するボットを作成できる」ものと定義しています。リクエストはHTTPSでJSON形式により送信されます。管理画面から手作業でメッセージを配信する機能ではなく、自社のサーバー側プログラムがLINEと通信するための入口。そう捉えると、後述の料金仕様まで一貫して理解できます。

Webhookを起点とする3ステップの通信フロー

公式ドキュメントが示す通信の流れは3段階です。第一に、ユーザーがLINE公式アカウントにメッセージを送信します。第二に、LINEプラットフォームからボットサーバーのWebhook URLへWebhookイベントが送信されます。第三に、ボットサーバーがWebhookイベントを確認し、LINEプラットフォームを通じてユーザーに応答する、という順序です。

起点はユーザー側の操作であり、ボットサーバーが常時LINEを監視するのではありません。この「イベントを受け取ってから動く」性質はWebhook一般の設計思想そのものです。仕組み自体に不慣れならWebhookとは？読み方・仕組み・APIとの違いを実際のHTTPリクエストで解説を先に読むと、以降の署名検証やリトライの話が具体的につかめます。

LINE公式アカウント・チャネル・ボットサーバーの役割分担

Messaging APIを使うには、LINE公式アカウントと、それに紐づくMessaging APIチャネルが必要です。LINE公式アカウントはユーザーから見える窓口、チャネルはLINE Developersコンソール上の開発単位で、チャネルシークレットとチャネルアクセストークンの発行元になります。ボットサーバーは自社で用意するものです。

無料メッセージ通数はLINE公式アカウント、レート制限はチャネルに紐づきます。同じLINE公式アカウントへの呼び出しでも、チャネルが異なればレート制限は独立して適用される、と公式リファレンスは明記しています。開発環境と本番環境でチャネルを分ける設計は、この点でも理にかなっています。

送信できる11種のメッセージタイプと4系統の送信API

「何ができるか」は、送れるメッセージの型と、誰に送るかを決める送信APIの2軸で決まります。混同されやすいのですが、この2つは独立していて、たとえばFlex Messageを応答メッセージでもブロードキャストでも送れます。

メッセージタイプ11種と用途の対応

迷ったらまずテンプレートメッセージで足ります。ボタン、確認、カルーセル、画像カルーセルの4種が用意されていて、定番の分岐はここで組めるため、いきなりFlex Messageに手を出すとJSONの記述量だけが増えます。Flex Messageが要るのは、商品カードや予約票のように既存テンプレートの枠に収まらない情報設計が必要なときです。構造の組み方はLINE Flex Messageの基本構造と通常メッセージにはない視覚表現の強みで扱っています。なお、選択肢を吹き出しの下に並べるクイックリプライは独立したタイプではなく、どのメッセージタイプにも付けられる共通機能です。

応答・プッシュ・マルチキャスト・ブロードキャスト・ナローキャストの選び分け

一斉配信系だけ桁が違います。ブロードキャストとナローキャストは毎秒ではなく毎時60リクエストで、全体配信を細かく分割して連投する設計はここで詰まります。

応答メッセージには、ほかにない制約が2つあります。Webhookイベントで受け取った応答トークンは一度しか使えず、Webhookを受信してから1分以内に使う必要があります。1分を超えた場合の動作は保証されません。再送されたWebhookに含まれる応答トークンも受信から1分以内なら使えますが、イベント発生から20分が経過していれば使えません。1リクエストで送れるメッセージオブジェクトは最大5つです。

公式ドキュメントは「時間制限に依存した実装をしないように」と注意しています。外部APIへの問い合わせ結果を待ってから返答する設計では、応答トークンが先に切れます。処理に時間がかかる場合、まず使えるのはローディングのアニメーション表示です。公式も、返答に時間がかかるときに待機を視覚的に伝える手段として案内しています。それでも間に合わないなら、先に短い応答を返して結果をプッシュメッセージで送る二段構えにしてください。ただしプッシュに切り替えた瞬間から通数の課金対象になります。

送信以外にできること

公式の「Messaging APIでできること」は送信系だけではありません。実装計画に影響する順に挙げます。

• ユーザープロフィールを取得する：表示名やユーザーIDを取り、自社の会員データベースと突き合わせる起点になります。
• ユーザーが送ったコンテンツを取得する：送信された画像・動画・音声・ファイルを取り出せます。
• リッチメニューを使う：トーク画面下部の固定メニューをAPIから出し分けます。
• 送信メッセージ数を取得する：当月の上限目安・利用状況に加え、応答・プッシュ・マルチキャスト・ブロードキャスト別の送信済み件数も取得できます。
• アカウント連携を使う：LINEのユーザーIDと自社サービスのアカウントを紐づけます。
• グループトークに参加する：グループや複数人トークにボットを参加させます。
• ビーコンを使う：LINE Beaconの検知をトリガーに動かします。

逆に、入力フォームのような画面表現はMessaging APIの守備範囲外です。その用途はLIFFが担います。

料金プランと通数カウント：Reply APIが無料枠を消費しない理由

Messaging API単体に料金はありません。費用が発生するのは、紐づくLINE公式アカウントの料金プランに設定された無料メッセージ通数を、どの送信方法で消費するかという形です。

3プランの月額固定費と無料メッセージ通数

アカウント開設時はコミュニケーションプランに設定されます。ライトプランやスタンダードプランを使うなら、開設後にプラン変更が必要です。追加メッセージを送れるのはスタンダードプランだけで、単価は配信数に応じた段階制になっています。公式が示す20万通配信の例では、5万通×3円、5万通×2.8円、10万通×2.6円で合計55万円です。この単価は2026年10月1日に改定が予告されていますので、見積もり時は必ず公式の料金ページで最新の単価表を確認してください。

オプションはプランと独立して契約できます。チャット履歴の保存期間を6か月から5年に延ばすチャットProオプションが月3,000円（税別）、任意の文字列でIDを取得できるプレミアムIDが月100円または年1,200円（いずれも税別）です。

通数にカウントされる送信方法とされない送信方法

ここが料金設計の中心です。LINE Developersの料金ページは、カウントされる送信方法としてプッシュメッセージ、マルチキャストメッセージ、ブロードキャストメッセージ、ナローキャストメッセージの4つを挙げ、カウントされない送信方法として応答メッセージを挙げています。LINEヤフー for Businessの料金ページも同様に、LINEチャットの送受信、応答メッセージ、あいさつメッセージ、Messaging APIのReply APIを課金対象外としています。

通数の数え方にも仕様があります。メッセージ通数は送信対象となった人数でカウントされます。メッセージオブジェクトを4件指定したプッシュメッセージを5人のトークルームへ1回送った場合、カウントされるのは5通。1回のリクエストで指定したメッセージオブジェクトの件数は通数に影響しません。ブロックしているユーザーIDや存在しないユーザーIDを宛先に含めても、実際に届かないためカウントされません。

実務上の帰結は明確です。ユーザーからの問い合わせに答えるだけのFAQボットなら、応答メッセージだけで組めるため無料のコミュニケーションプランで運用できます。逆に、在庫入荷やリマインドのような能動的な通知が主目的なら、友だち数がそのまま毎月の通数になります。友だち3,000人に月2回のリマインドを送るだけで6,000通に達し、ライトプランの5,000通を超えます。見積もるべきは配信回数ではなく、配信回数と友だち数の積です。

無料メッセージ通数を超過したときの挙動はプランで異なる

挙動はプランによって分かれるので、ひとまとめに覚えないでください。コミュニケーションプランとライトプランは追加メッセージを送れないため、無料通数を使い切った時点でエラーレスポンスが返り、当月の配信が止まります。超過分がそのまま課金される動きにはなりません。

スタンダードプランは違います。無料の30,000通を超えた分は追加メッセージとして従量課金され、あらかじめ設定した追加メッセージ数の上限目安を超えたところで配信が停止します。公式が「上限数はあくまで目安」と断っているとおり、連続配信などの配信方法によっては上限を超えて配信されることもあります。上限目安を0に設定していても、利用状況に応じて追加メッセージ料金が発生する場合があるとも明記されています。

当月の状況はAPIで取れます。GET https://api.line.me/v2/bot/message/quota が当月に送信できるメッセージ数の上限目安、GET https://api.line.me/v2/bot/message/quota/consumption が当月の利用状況を返します。配信バッチの前にこの2つを突き合わせて残量を確認する処理を入れておけば、途中まで送れて途中から落ちる中途半端な配信を避けられます。

チャネル作成からWebhook接続までの実装手順

着手の順序は、LINE Developersコンソールでプロバイダーとチャネルを作る、チャネルアクセストークンを発行する、ボットサーバーを立ててWebhook URLを登録する、署名検証を実装する、の4つです。

コンソールでのチャネル作成とWebhook URL登録の設定項目

最初にLINE公式アカウントを開設し、LINE Developersコンソールでプロバイダー（開発主体の単位）を作り、その下にMessaging APIチャネルを作成します。チャネルを作ると［チャネル基本設定］タブにチャネルシークレットが、［Messaging API設定］タブにチャネルアクセストークンの発行欄が現れます。

ボットサーバーを公開したら、［Messaging API設定］タブにWebhook URLを登録し、Webhookの利用をオンにします。同じ画面の［検証］ボタンを押すと、LINEプラットフォームから疎通確認のWebhookが送信されるので、ボットサーバー側のログで受信を確認してください。あわせて、管理画面側の応答メッセージ（自動応答）をオフにしておかないと、ボットの返答と定型文が二重に届きます。

チャネルアクセストークン4種類の有効期間と選択基準

動作確認の段階では、コンソールからボタン1つで出せる長期トークンが手軽です。ただし長期トークンは有効期限がなく、漏れたときの影響が止まりません。本番はv2.1かステートレスに寄せてください。v2.1はJWTで生成するためセキュリティを強化でき、有効期間を最大30日の範囲で自由に決められます。ステートレスは15分で失効し発行数に制限がなく、公式ドキュメントも「チャネルを使用するたびに発行することを想定して設計されています」と書いています。

逆にv2.1と短期トークンは、使うたびに再発行してはいけません。有効期間内は同じものを繰り返し使う前提で、短時間に大量発行してLINEプラットフォームの動作に影響を与えると判断された場合、発行を一時的に制限されることがあります。トークンを毎リクエスト取り直す実装は、この2種類では設計ミスです。

HMAC-SHA256による署名検証と生ボディを壊す失敗パターン

Webhook URLに届くPOSTリクエストは、LINEプラットフォーム以外から送られた可能性があります。公式ドキュメントは、Webhookイベントオブジェクトを処理する前に署名を検証するよう明示的に求めており、Messaging API開発ガイドラインでも検証を推奨しています。送信元のIPアドレスは開示されていないため、アクセス制御ではなく署名検証でセキュリティを担保する設計です。

LINEプラットフォームはWebhookイベントを入力データ、チャネルシークレットをハッシュ鍵としてHMAC-SHA256で署名を生成し、x-line-signatureヘッダーに入れて送ります。受け取る側は同じ計算をして一致を確認します。以下は、公式ドキュメントが検証手順の例として公開しているチャネルシークレットとリクエストボディ、署名をそのまま使った実装です。Python 3.14.6で実行し、標準出力がTrueになることを確認しています。

import base64, hashlib, hmac

CHANNEL_SECRET = "8c570fa6dd201bb328f1c1eac23a96d8"  # 実運用では環境変数から読み込む

def verify(body: bytes, signature: str) -> bool:
    mac = hmac.new(CHANNEL_SECRET.encode("utf-8"), body, hashlib.sha256).digest()
    return hmac.compare_digest(base64.b64encode(mac).decode("utf-8"), signature)

signature = "GhRKmvmHys4Pi8DxkF4+EayaH0OqtJtaZxgTD9fMDLs="
raw = b'{"destination":"U8e742f61d673b39c7fff3cecb7536ef0","events":[]}'
print(verify(raw, signature))  # True

要点はrawがバイト列であることです。署名検証は受信したリクエストボディの文字列をそのまま入力にします。検証前にパースしたり、読みやすく整形したり、エスケープ文字を解釈したりすると、第三者による改ざんと区別できなくなり検証は失敗します。同じ内容のJSONでも、整形すればバイト列が変わるためです。

# 上のコードに続けて実行する
import json

pretty = json.dumps(json.loads(raw), indent=2).encode("utf-8")
print(verify(pretty, signature))  # False

この処理を同じ環境で実行するとFalseが返ります。内容は等価でも検証は通りません。WebフレームワークによってはリクエストをJSONとして自動的にデシリアライズするため、生ボディを別途取り出す実装が必要です。ボットサーバーの手前に置いたプロキシやロードバランサーがヘッダーやボディを書き換えていないかも、署名が合わないときの確認先になります。文字エンコーディングがUTF-8以外になっていないかも、公式が挙げる失敗要因のひとつです。

レート制限の実値と429が返る4つの原因

レート制限はチャネル単位かつエンドポイントごとに適用されます。公式リファレンスが示す帯域は次のとおりです。

• リンク済みリッチメニューの一括置き換え・解除: 3リクエスト/時
• ブロードキャスト、ナローキャスト、各種統計情報の取得、Webhookエンドポイントの検証: 60リクエスト/時
• オーディエンスの作成・更新系: 60リクエスト/分
• リッチメニューの作成・削除: 100リクエスト/時
• Webhookエンドポイントの設定・取得: 1,000リクエスト/分
• リッチメニューの配列取得: 10リクエスト/秒
• ローディングのアニメーション表示: 100リクエスト/秒
• マルチキャスト、メンバーシップ関連、クーポン関連: 200リクエスト/秒
• 短期のチャネルアクセストークン発行: 370リクエスト/秒
• 上記以外のエンドポイント（応答・プッシュを含む）: 2,000リクエスト/秒

毎時と毎秒が同じ表に混在している点が事故のもとです。リッチメニューの一括置き換えに至っては毎時3回しか呼べません。

制限方式は、一定時間ごとに一括リセットされるものではなく、トークンバケット方式をベースに設計されています。消費が補充を上回る状態が続くとバケット内のトークンが不足し、その状態のリクエストが429で弾かれます。時間が経てば補充され、送信可能な数は徐々に回復します。「毎秒ちょうど上限まで投げれば通る」わけではなく、瞬間的なバーストが先にバケットを空にする点に注意してください。

適用範囲にも癖があります。URLが同じでもHTTPメソッドが異なれば別のエンドポイントとみなされる一方、URL中のパラメータやリクエストボディの内容は区別されず、呼び出し元のIPアドレスの違いも区別されません。サーバーを増やして分散させても、同一チャネルからの呼び出しである限り制限は共有されます。

そして429の原因は1つではありません。公式のステータスコード表は、APIコールのレート制限超過、同時処理数の制限超過、無料メッセージ通数の超過、追加メッセージ数の上限目安の超過という4つを挙げています。前2者は時間をおけば回復しますが、後2者は月が変わるかプランを変えるまで回復しません。区別はエラーメッセージで付きます。レート制限超過ならThe API rate limit has been exceeded. Try again later.、通数系ならYou have reached your monthly limit.です。この文字列で分岐し、通数系なら即座にリトライを打ち切って運用者へ通知してください。両者を同じリトライループに入れると、月末に無限リトライを回すことになります。

ややこしいのは、公式が「当月に配信できるメッセージ数がまだ残っていてもYou have reached your monthly limit.が返される場合があります」と注記している点です。ナローキャスト配信中に残数が一時的に枯渇し、並行して送った別のメッセージが失敗する挙動が実際に記載されています。残数を根拠に「このエラーは出ないはず」と決め打つ実装は避けてください。

Messaging APIを採用しない判断になる条件

LINEの利用者数を根拠に「まずMessaging APIを」と勧める記事は多いのですが、要件によっては採用しないほうが早く安く済みます。判断が分かれるのは次の2つの場合です。

1つ目は、能動的な通知が主目的で、友だち数が多く、内容が定型の場合。友だち1万人に月4回の通知を送るなら4万通で、スタンダードプランの無料枠3万通を超えて追加メッセージ料金が乗ります。同じ告知をメールで送るコストと比較して、LINEでなければならない理由が開封率だけなら、費用対効果は再計算する価値があります。

2つ目は、入力フォームや会員情報の表示など、リッチな画面表現が中心の場合です。Flex Messageで無理に画面を組むより、LINEアプリ内でWebアプリを動かすLIFFのほうが素直に作れます。判断材料はLIFFとは？LINEアプリ内で動くWebアプリの仕組みと開発手順を実装目線で解説とLINEミニアプリとは？仕組み・LIFFとの違い・開発費用から導入判断まで解説にまとめています。

逆に、問い合わせ対応の自動化が目的なら迷わず採用してよい領域です。対応件数が増えても配信費用が増えない課金構造は、ほかのメッセージング基盤にはあまりない特性で、有人対応の削減効果がそのまま損益に乗ります。方式そのものの選定はAIチャットボットの作り方｜生成AI＋RAG・ノーコード・受託開発の方式選定と実装手順で扱っています。

よくある質問

Messaging APIは無料で使えますか？

API自体の利用料はありません。費用が発生するのはLINE公式アカウントの料金プランの無料メッセージ通数を超えたときだけです。開設時に設定されるコミュニケーションプランは月額0円で200通まで送れます。しかも応答メッセージ（Reply API）は通数にカウントされないため、ユーザーからの問い合わせに答えるだけのボットであれば、0円のまま運用できます。

Messaging APIとLINE公式アカウントの違いは何ですか？

LINE公式アカウントがユーザーから見える窓口そのもので、Messaging APIはその窓口を自社プログラムから操作するためのインターフェースです。管理画面のLINE Official Account Managerからも配信はできますが、会員データベースと連動した個別配信や、受信内容に応じた自動応答はMessaging APIを使わないと組めません。両者は代替関係ではなく、Messaging APIはLINE公式アカウントを前提に動きます。

応答メッセージとプッシュメッセージはどちらを使うべきですか？

ユーザーの発言に反応する場面では応答メッセージを使ってください。対話の文脈が保たれるうえ、通数も消費しません。ただし応答トークンはWebhook受信から1分以内かつ1回しか使えないため、外部システムへの問い合わせで時間がかかる処理には向きません。待ち時間が短ければローディングのアニメーションで間をつなぎ、それでも足りなければ短い応答を先に返して結果をプッシュメッセージで送ります。

友だち全員への配信は何通としてカウントされますか？

ブロードキャストメッセージは、送信対象となった人数分がカウントされます。友だち3,000人へ1回配信すれば3,000通です。1リクエストにメッセージオブジェクトを複数入れても通数は増えません。なお、ブロックしているユーザーや存在しないユーザーIDには実際に届かないため、通数にはカウントされません。ブロードキャストのレート制限は60リクエスト/時なので、分割配信で回避しようとすると別の壁に当たります。

Webhookの署名検証はSDKを使わずに実装できますか？

できます。チャネルシークレットをハッシュ鍵としてリクエストボディをHMAC-SHA256にかけ、Base64エンコードした値をx-line-signatureヘッダーと比較するだけです。注意点は、検証前にボディを一切加工しないこと。JSONのパースや整形、エスケープ文字の解釈を挟むと必ず失敗します。各言語のLINE Messaging API SDKを使えばこの手順は関数1つで済みます。

関連記事

• LINE Flex Messageの基本構造と通常メッセージにはない視覚表現の強み
• LIFFとは？LINEアプリ内で動くWebアプリの仕組みと開発手順を実装目線で解説
• LINEミニアプリとは？仕組み・LIFFとの違い・開発費用から導入判断まで解説
• Webhookとは？読み方・仕組み・APIとの違いを実際のHTTPリクエストで解説
• AIチャットボットの作り方｜生成AI＋RAG・ノーコード・受託開発の方式選定と実装手順