LINE Messaging APIの料金｜課金されるのは4つのAPIだけ。通数の数え方と減らし方

LINEのMessaging APIは、呼び出すこと自体にリクエスト単位の利用料がかかりません。請求として立つのは、APIから送ったメッセージがLINE公式アカウントの「メッセージ通数」に算入され、契約プランの月額料金と追加メッセージ料金として跳ね返る分です。つまりAPI経由の費用を左右するのは料金表よりも、どの送信APIを、誰に、何回呼ぶかという実装の側にあります。この記事では、課金対象になるAPIの区別、通数の数え方、そして通数を増やさない実装の型を、LINE Developersと LINEヤフー for Business の公式ドキュメントにもとづいて整理します。

この記事でわかること

• 課金される4つのAPI： Messaging API経由で通数がカウントされるのはプッシュ・マルチキャスト・ブロードキャスト・ナローキャストの4つだけで、応答メッセージ（Reply）は0円です。
• 通数の正しい数え方： 数えるのはリクエスト数ではなく「送信対象になった人数」です。メッセージオブジェクトを5つ詰めても1通、逆に5人のグループへ1回送れば5通になります。
• 開発者だけが踏む2つの罠： ナローキャスト配信中の通数「予約」で別のPushが失敗すること、そして本番Pushでの試し打ちで無料通数が溶けること。どちらも回避策があります。

結論｜Messaging APIのAPI利用に別料金はない

Messaging APIには、リクエスト1回いくらという課金がありません。費用はLINE公式アカウントの契約プランに乗ります。

LINE Developersの公式ドキュメントは「Messaging APIは無料ではじめられます」と明記したうえで、「毎月、一定数のメッセージを無料で送信できます。無料メッセージ通数は、LINE公式アカウントの料金プランによって異なります」と続けています。開発者向けに別建ての従量プランが用意されているわけではなく、APIから送ったメッセージは、その公式アカウントのプランに含まれる無料メッセージ通数を消費します。無料通数を超えた分は、プランによっては追加メッセージ料金として請求されます。

したがって、開発者が握れる変数は2つしかありません。どの送信APIを使うかと、1回の送信で何人を対象にするかです。単価を交渉することはできませんが、この2つは設計で決められます。

なお、ここで「無料」と言っているのはMessaging APIの呼び出しについてです。LINEプラットフォーム上のすべてのAPI・サービスが無料という意味ではありません。たとえばLINE通知メッセージは法人向けの申込が必要な別サービスで、送信された通知には利用料金がかかります。LINE MINI Appのアプリ内課金にもサービス手数料があります。これらはMessaging APIの利用料ではないため、本記事では扱いません。

「公式アカウントの料金」と「APIの料金」は同じ財布

LINE公式アカウントの料金とMessaging APIの料金は別物ではなく、同じ無料通数を食い合う1つの財布です。

管理画面（LINE Official Account Manager）から一斉配信を打っても、Messaging APIからプッシュメッセージを送っても、減るのは同じ月間の無料メッセージ通数です。開発チームがBotの通数だけを見ていると、マーケ担当が管理画面から流した配信で枠が尽きている、という食い違いが起きます。逆も同じです。

プランそのものの比較（3プランの月額、初期費用、支払方法、月の途中でのプラン変更ルール、認証済アカウントの扱いなど）は、運用担当者向けに別記事へまとめてあります。プラン選びから知りたい場合はLINE公式アカウントの料金プランと2026年10月の改定内容を先に読んでください。この記事は、そこから先の「実装で通数がどう動くか」だけを扱います。

Messaging API経由で通数カウントされるのは4つだけ｜Replyは0円

Messaging APIから送るメッセージのうち、通数としてカウントされるのは4種類です。応答メッセージは対象外です。

公式の「Messaging APIの料金」に書かれている区分はきわめて単純で、プッシュメッセージ・マルチキャストメッセージ・ブロードキャストメッセージ・ナローキャストメッセージの4つがカウント対象、応答メッセージ（Reply）はカウントされない、というものです。この線引きが、そのままコストの設計図になります。

※これは「Messaging APIから送信した場合」の分類です。LINE Official Account Managerからの通常配信・絞り込み配信・ステップ配信も、別途メッセージ通数にカウントされます。反対に、あいさつメッセージ・応答メッセージ・LINEチャットでの送受信はカウント対象外です。管理画面側の機能まで含めた課金対象の一覧は、LINEヤフー for Business の案内が正となります。

実装の観点で言い換えると、境界は「ユーザーが先に何かしたか」にあります。ユーザーの発言やタップに紐づくWebhookを起点に返すReplyは0円で、こちらの都合で送り出すものは課金される、という並びです。

1通の数え方｜「リクエスト数」ではなく「送信対象になった人数」

メッセージ通数は、APIを呼んだ回数ではなく、そのメッセージの送信対象となった人数で数えられます。

公式の表現は「メッセージ通数は、メッセージの送信対象となった人数でカウントされます」です。1行ですが、見積りが桁でずれるかどうかはここで決まります。実際、X上でいちばん多く見かける誤解が「無料の200通＝200回APIを呼べる」というもので、友だちが20人いれば10回で枯れることに送ってから気づく、という投稿が並びます。

メッセージオブジェクトは1リクエストに5つまで、それでも1通

1回のリクエストにメッセージオブジェクトを最大5つまで載せられますが、通数は増えません。

吹き出しを分けて読みやすくしても、通数の計算には効きません。効くのは対象人数と呼び出し回数だけです。逆に言えば、2回に分けて送っているものを1リクエストにまとめれば、通数はそのぶん減ります。管理画面の一斉配信が吹き出し3つまでなのに対し、APIでは5つまで置けるので、まとめられる余地はAPIのほうが広いことになります。

グループ・複数人トークは実際に送信された人数分

グループトークや複数人トークへの送信は、1件ではなく参加している人数分としてカウントされます。

LINE DevelopersのFAQには具体例が載っています。「メッセージオブジェクトを複数件（例：4件）指定したプッシュメッセージを、複数人数（例：5人）がいるグループトークまたは複数人トークに1回送った場合、カウントされるメッセージ通数は5通です」。4件×5人で20通にはならず、かといって「グループ1件＝1通」にもなりません。人数だけが効きます。

グループを相手にするBotでこれが効いてくるのは、参加人数を自分で決められないからです。40人のグループに月15回通知を出すと、それだけで600通になり、無料の200通どころかライトプランの5,000通も現実的な射程に入ってきます。人数の多いグループにどう制限をかけるかは、実装に入る前に決めておく設計事項です。

配信できなかったユーザーはどう数えられるか

ブロック中のユーザーや存在しないユーザーIDへの送信は、メッセージ通数としてカウントされません。

これは料金計算の仕様の説明であって、無効なIDを意図的に送信対象へ含めることを勧めるものではありません。実務上は、リクエストの成否やレート制限、エラー処理の都合からIDの掃除は必要です。数えられないから放置してよい、という話にはなりません。

この仕様が効いてくるのは、見積りと実績が合わないときの説明です。マルチキャストで1,000件のユーザーIDを投げたのに `totalUsage` が1,000増えていない、という場面では、まずブロック済みのユーザーが含まれていた可能性を疑うことになります。

無料でどこまで使える？実装別の料金シミュレーション

無料で送れるのは月200通からで、実装の型によって同じ規模でも通数は10倍以上変わります。

日本のLINE公式アカウントの無料メッセージ通数は、コミュニケーションプラン（月額0円）が200通、ライトプラン（月額5,000円・税別）が5,000通、スタンダードプラン（月額15,000円・税別）が30,000通です。追加メッセージを送れるのはスタンダードプランだけで、初期費用はかかりません。プランの詳細はLINE公式アカウントの料金プランの解説にまとめてあります。

問題は「自分のBotがどこに落ちるか」です。実装の型ごとに月間通数を並べると、次のようになります。

同じ「友だち100人が毎日使うBot」でも、Replyだけで完結させれば0通、後追いの通知を1回足すだけで月3,000通です。費用を分けているのは規模ではなく、送信の起点をユーザー側に置けているかどうかだということが、この表から読み取れます。

「200通＝APIを200回呼べる」ではない

無料の200通は、APIを200回呼べる枠ではなく、延べ200人に届けられる枠です。

友だちが20人いるアカウントで全員に通知を送ると、1回の配信で20通です。200通の枠は10回で終わります。友だちが100人なら2回です。個人開発でLINE Botを立ち上げた人が「200通って少なすぎ」「一ヶ月もたんのか」と書くのは、この計算に送ってから気づくためです。

グループが相手ならさらに倍率がかかります。前述のとおりカウントは参加人数分なので、4人のグループへの通知は1回4通です。コミュニケーションプランは「配信の枠」ではなく「チャットと自動応答で使うプラン」だと考えたほうが、設計を誤りません。

Replyだけで回すBotは通数0で成立する

ユーザーの発言に返すだけのBotなら、利用者が何人いても通数の課金は発生しません。

応答メッセージはカウント対象外なので、問い合わせ応答・FAQ・診断・検索といった「聞かれたら答える」タイプのBotは、友だちが100人でも1,000人でも月額0円のコミュニケーションプランで動きます。通数が生まれるのは、こちらから話しかけた瞬間です。

逆に言えば、無料枠に収めたいときに最初に見るべきは「本当にこちらから送る必要があるのか」です。次のセクションで扱うとおり、送っている内容の多くは、ユーザーが見に来る形に置き換えられます。

無料通数を超えたら何が起きるか

追加メッセージを買えるのはスタンダードプランだけで、他のプランでは送信そのものが止まります。

コミュニケーションプランとライトプランは追加メッセージを送れません。上限に達すると配信できなくなり、APIからは You have reached your monthly limit. というエラーレスポンスが返り、メッセージは送信されません。エラーになるだけで、勝手に課金されて送られることはない設計です。

月中に足りなくなった場合、スタンダードプランへ上げれば追加メッセージで配信を継続できます。止まって困る通知（予約リマインドや業務連絡）をライトプランの枠ぎりぎりで運用しない、というのが実装側の判断になります。

通数を増やさない実装パターン

単価は選べないので、コストに効くのは通数そのものを減らす実装だけです。境界は送信の起点にあります。

ここまで見てきたとおり、課金されるかどうかを分けているのは「ユーザーが先に何かしたか、こちらから送り出したか」です。この境界を意識して設計を組み替えると、機能を削らずに通数だけを落とせます。

返せるものはReplyで返す｜応答トークンは一度だけ

ユーザーの発言やタップに紐づく返答は応答メッセージで返せば0円ですが、使える条件は厳しめです。

応答メッセージにはWebhookイベントに含まれる応答トークンが必要で、このトークンは一度しか使えません。有効期限もあり、公式ドキュメントは「Webhookを受信してから1分以内に使用する必要があります。1分を超える場合の使用については、動作は保証されません」としたうえで、時間制限に依存した実装をせず、できるだけ早く使うよう求めています。ネットワーク遅延などで実際の猶予は変動するため、1分をタイムアウト設計の保証値として扱わないのが安全です。

Webhookが再送された場合も、元のWebhookに含まれる応答トークンをすでに使っていれば使えません。イベントの発生から20分が経過している場合も同様です。設計の原則は単純で、顧客が何か言ったあとに、すぐ1回で返し切ることです。

逐次返信にするとPushに漏れる

回答が長いこと自体は課金理由になりません。問題は、1つの応答トークンで複数回に分けて送れないことです。

応答メッセージも1回のリクエストに最大5つのメッセージオブジェクトを載せられるので、内容が長いだけならReplyで足ります。詰まるのは、生成の途中経過を刻んで出したり、処理の完了を後から知らせたりする設計です。2回目以降の送信には応答トークンが残っていないため、プッシュメッセージを使うことになり、そこから課金が始まります。

生成AIを組み込んだBotでこれが顕在化します。実際にX上でも「Reply Tokenを使うと無料でユーザーに返信できるのはすごく良心的。ただ1回しか使えないから、AIのようにストリーミング返信しようとするとPushメッセージを使わないといけない」という声が出ています。ストリーミング風に見せる設計を採るなら、その分は通数を前提に見積もる——ここが判断の分かれ目です。

定常的な案内はリッチメニューに置く

毎回同じ内容を配信しているなら、リッチメニューに常設したほうが通数はかかりません。

リッチメニューはトーク画面の下部に常に表示され、タップされたときの反応は応答メッセージ側で返せます。何回タップされても通数は増えません。メニュー・料金表・アクセス・FAQ・予約導線といった「いつも同じ内容」は、配信で押し込むよりも置いておくほうが読まれ方も安定します。

「定期的に配信しないと忘れられる」という前提で毎週の案内を流している場合、その配信が友だち数ぶんの通数を毎回消費していることになります。通知の必要があるのは期限つきの情報と、その人だけに関係する情報で、残りは常設に寄せられないかを先に検討する価値があります。

LIFFからの通知をPushにしない

LIFF内の処理だけでは応答トークンが手に入らないため、素直に組むと完了通知がPushになります。

LIFFアプリの中でフォーム送信や決済を完了させても、それはWebhookイベントではないので応答トークンは発行されません。そのままBotから「受け付けました」を送ると、プッシュメッセージとして課金されます。予約フォームや申し込みフォームをLIFFで作ると、申し込み1件につき最低1通が確定する、という構造です。

回避策は、ユーザー自身にメッセージを送ってもらい、そのWebhookを起点にReplyで返すことです。LIFFには liff.sendMessages() があり、ユーザー自身の発言としてトークへメッセージを送信できます。テキストなどではそのメッセージに対してWebhookが発生するため、それを受けて応答メッセージで返せば通数はかかりません。ただしFlexメッセージやテンプレートメッセージを liff.sendMessages() で送った場合はWebhookが送られないため、この手は使えません。実装前に、どのメッセージタイプでWebhookが発生するかを確認してください。

なお、この設計に切り替えて「Botから送るメッセージを4割程度削減できた」と報告している開発者もいます。これは公式が保証する数値ではなく、あくまで実装事例として参考にしてください。

全員配信をやめる

ブロードキャストは友だち数がそのまま通数になるため、絞り込むだけで通数は直接減ります。

全員に送る必要が本当にあるかを問い直すと、多くの配信は対象を絞れます。ナローキャストで属性やオーディエンスによって絞る、マルチキャストで対象のユーザーIDだけに送る、という2つが基本の手です。1,000人の友だちのうち200人にしか関係しない案内を全員へ流していれば、毎回800通を捨てていることになります。

どう絞るか、どのセグメントを作るかという配信設計そのものは、運用側の話題になります。プラン側からの考え方は料金プランの記事で扱っている配信コストの抑え方を参照してください。

いま何通使ったかをAPIで見る｜ただし「使用量」は2種類ある

通数はAPIで取得できますが、取れる数字が2系統あり、意味が違うので混ぜると請求と合いません。

よく使われるのは quota 系と delivery 系です。前者はアカウント全体の枠と消費を返し、後者はMessaging APIの各エンドポイント経由の送信実績を返します。前者には管理画面から送った分も含まれ、しかも概算値です。「APIから何通送ったか」を知りたいときに quota/consumption を見ると、マーケ担当が管理画面から流した配信まで数えてしまいます。

残枠の監視に使うのは quota と quota/consumption の差分、実装の内訳を見るのは delivery/*、と用途を分けるのが正解です。取得は次の1本で足ります。

curl -s -X GET https://api.line.me/v2/bot/message/quota/consumption \
  -H "Authorization: Bearer {channel access token}"
# => {"totalUsage":1234}

なお totalUsage は概算値です。請求額の確定値として扱わず、枠が尽きそうかどうかの早期警戒に使うのが実務的な位置づけになります。

開発中に無料通数を溶かさない

メッセージオブジェクトの動作確認は、本番のPushではなく検証用のエンドポイントで行えます。

Messaging APIには、実際に送信せずにメッセージオブジェクトの妥当性だけを検証するエンドポイントがあります。POST /v2/bot/message/validate/reply、/validate/push、/validate/multicast、/validate/narrowcast、/validate/broadcast の5本です。検証されるのは messages プロパティの値が有効かどうかで、それ以外のプロパティは検証されません。Flexメッセージの組み立てを試すたびに本番へPushする、という開発の仕方をやめられます。

もうひとつ効くのが上限目安の設定です。当月に送信できるメッセージ数の上限目安を設定しておけば、超えた時点でエラーが返って送信されません。テストコードのループが暴走したり、宛先の指定を誤って全友だちに送ってしまったりしたときに、被害を頭打ちにできます。開発者がいちばん恐れているのはテスト枠の消費よりも誤爆一斉送信のほうで、そちらへの備えとしても意味があります。

残数があるのに送信が失敗する｜ナローキャストの「予約」

ナローキャストの配信中は通数が一時的に予約されるため、残枠があるのに別の送信が失敗します。

公式リファレンスの説明では、メッセージの送信開始から実際に送信される件数が確定するまでの間、当月に配信できるメッセージの残数に対して送信予定のメッセージ数が予約された状態になります。予約される通数は、リクエストで指定する target reach や max、upToRemainingQuota といった条件によって変わります。

この予約で残数が埋まっている間に別のメッセージを送ると、You have reached your monthly limit. が返って送信に失敗します。月末に大きなナローキャスト配信を走らせている裏で、予約リマインドや業務通知のPushが静かに落ちる——という事故が、これで起きます。残枠を見ても原因がわからないため、切り分けに時間がかかるタイプの障害です。

対策は単純で、大量配信と、止まってはいけない業務通知の時間帯をずらすことです。同時に走らせない運用ルールを決めておけば、実装側で複雑なリトライを組む必要はありません。

課金とは別の壁｜代表的なレート制限

通数が残っていても叩けない上限があります。監視や大量配信の設計はこちらに縛られます。

レート制限はエンドポイントごとに設定されています。代表的なものを並べると、次のようになります。

実装で効いてくるのは1行目です。配信数の取得が60リクエスト/時ということは、「使用量を毎分ポーリングして監視する」という設計が成立しません。残枠の監視は時間単位に落とすか、送信側でカウントを持つ必要があります。

マルチキャストの200リクエスト/秒は、以前の2,000リクエスト/秒から引き下げられた値です。古い実装や記事を参照していると、ここで詰まります。なお上の表は代表的な値で、ほかに100リクエスト/秒や370リクエスト/秒といった個別の設定もあります。実装前に該当エンドポイントのリファレンスを確認してください。

2026年10月の追加メッセージ料金改定（日本のみ）は開発者に効くか

追加メッセージが月5万通までなら支払額は変わりません。効くのは月数十万通を投げている規模です。

LINEヤフー for Business は、2026年10月1日から追加メッセージ料金を改定すると告知しています。対象は日本のみで、台湾・タイのアカウントには適用されません。改定後の単価は20万通まで1通3円、20万通を超えた分は1通2.5円（税別）の2段階です。

現行は通数帯ごとの逓減テーブルで、最初の5万通が3.0円、5万〜10万通が2.8円、10万〜20万通が2.6円と下がっていく形です。公式の例では20万通の配信が550,000円になります。最初の5万通はどちらも3円なので、追加5万通までのアカウントは改定前後で支払額が変わりません。逓減が効いていた5万通より上の帯が、実質的な値上げになります。

個人開発や受託で作るBotの大半は、そもそもスタンダードプランの無料30,000通の範囲か、その少し上です。この改定を自分ごととして構えるべきなのは、すでに追加メッセージを毎月数万通買っている規模だけと考えて差し支えありません。改定前後の総額比較は料金プラン記事の新旧比較表にまとめてあります。

上限引き上げ申請時の最大値は630万通→359万通へ

単価より先に効く可能性があるのが、上限引き上げ申請が承認された場合の最大値の変更です。

追加メッセージには上限があり、標準の制限値を超えて設定したい場合は引き上げの申請をします。この申請が承認された場合の最大値が、現行の630万通から359万通へ変わります。すでに359万通を超える上限が設定されているアカウントは、2026年10月に359万通へ引き下げられます。359万通を超える設定が必要な場合は、認定セールスパートナーへの相談ルートが案内されています。

実装側で気にすべきなのは、上限目安の値をコードの前提に置いている場合です。GET /v2/bot/message/quota の value をハードコードした閾値と比較しているような実装は、2026年10月に前提が変わる可能性があります。取得した値をそのまま使う形にしておけば影響はありません。

通数課金を前提にしない設計へ

配信でリーチを買う設計のままだと、打ち手が「通数を削る」しか残りません。

ここまでの話を一段引いて見ると、通数の悩みは「LINEを一斉配信の道具として使っている」ことから生まれています。単価は選べず、削れる通数にも限りがあるため、配信量に依存した設計はどこかで頭打ちになります。

一方で、予約の受付、来店前後のやり取り、1対1のチャット、自動応答は、仕様上0円で回る領域です。ユーザーが先に動く行動に価値の置き場を移すと、通数を増やさずに再来や継続をつくれます。Botの役割を「お知らせを配る」から「用事を済ませてもらう」へ寄せる、という設計変更です。

私たちが提供しているLINE連携の仕組みも、この考え方に立っています。配信の量ではなく、予約・顧客情報・リマインドといった業務側の動線をLINE上に置くことで、通数を増やさずに来店サイクルを回す形です。実装を自前で組む場合でも、外部のサービスに載せる場合でも、「送る回数を増やさずに成立するか」を先に確かめておくことをおすすめします。

よくある質問

Messaging APIの料金について、実装前によく聞かれる6つに答えます。

Q. Messaging APIの利用料はいくらですか？

A. API呼び出しそのものに、リクエスト単位の利用料はありません。かかるのはLINE公式アカウントの月額プラン料金と、無料メッセージ通数を超えた分の追加メッセージ料金です。初期費用もかかりません。

Q. 無料の200通は、APIを200回呼べるということですか？

A. いいえ。通数は送信対象になった人数で数えます。友だちが20人いれば1回の配信で20通なので、200通の枠は10回で終わります。

Q. 1回のリクエストに吹き出しを5つ入れたら5通ですか？

A. 1通です。1リクエストにメッセージオブジェクトを最大5つまで載せられますが、通数に影響するのは送信対象の人数だけです。

Q. グループトークに送ると何通になりますか？

A. 参加している人数分です。公式FAQでは、4件のメッセージオブジェクトを5人のグループトークへ1回送った場合、カウントは5通と説明されています。

Q. ライトプランで5,000通を使い切ったらどうなりますか？

A. ライトプランは追加メッセージを送れないため、配信が止まります。APIからは You have reached your monthly limit. が返り、メッセージは送信されません。継続するにはスタンダードプランへの変更が必要です。

Q. 2026年10月の改定で自分のBotは値上がりしますか？

A. 追加メッセージが月5万通までなら変わりません。改定は日本のみが対象で、20万通まで1通3円、超過分が1通2.5円（税別）になります。実質的な値上げになるのは、逓減が効いていた5万通超の帯です。

まとめ

Messaging APIの費用は、料金表ではなく「どのAPIで何人に送るか」で決まります。

押さえるべきことは4つです。

• 課金されるのは4つのAPIだけ。 プッシュ・マルチキャスト・ブロードキャスト・ナローキャスト。応答メッセージは0円です（管理画面からの配信は別途カウントされます）。
• 数えるのは人数。 メッセージオブジェクトを5つ詰めても1通、5人のグループへ1回送れば5通です。
• ReplyとリッチメニューとLIFFの設計で、通数は大きく変わる。 応答トークンは一度だけ・受信後すみやかに、が前提条件です。
• 実測は2系統を区別して見る。 quota/consumption は管理画面分も含む概算、delivery/* はAPI経由の内訳です。

そのうえで、開発中は validate 系エンドポイントで試し打ちをやめ、上限目安を設定して誤爆に備える。ナローキャストと業務通知の時間帯を分ける。この2つを足せば、料金でも障害でも慌てずに済みます。プラン選びから確認したい場合はLINE公式アカウントの料金プランと2026年10月の改定内容を、無料で返せる自動応答の作り方はLINEの自動返信（応答メッセージ）の設定方法をあわせてご覧ください。

参考：LINE Developers「Messaging APIの概要」「Messaging APIの料金」「メッセージを送信する」「Messaging APIリファレンス」「LIFF APIリファレンス」「よくある質問」／LINEヤフー for Business「LINE公式アカウントの料金プラン」「スタンダードプラン追加メッセージ 価格テーブル」「【重要】LINE公式アカウント 追加メッセージ料金改定のお知らせ」（いずれも2026年8月時点の内容）。