◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- LINEで注文を受ける費用は、公式アカウントのプラン料金(月額0円・5,000円・15,000円、税別)と、注文を取り込んで在庫や請求とつなぐ費用の2層に分かれる。
- 通数を増やすのは自社から送り始める連絡で、Messaging APIの応答メッセージは数えられず、プッシュなどは送信対象の人数分が数えられる。
- 受発注サービスの費用は1社の料金例でも初期50〜150万円・月14〜40万円と幅があり、同じ会社の目安とも食い違うため、自社の条件を伝えた見積もりで確かめる。
- 連携が不要で注文が少なければ公式アカウント中心、転記をなくしたいならサービスか個別開発を、取引先側の操作も含めて同じ軸で比べる。
- 0円のプランで数社と試し、通数と転記の手間を測ってから、上位プランへの変更か見積もり依頼かを決める。
目次

LINEで注文を受ける費用は「LINE側」と「注文を処理する側」に分かれる
電話で聞き取った注文を伝票に書き写し、FAXの数字を読み直す。
そこへ取引先から「LINEで頼みたい」と言われても、月にいくらかかるのかが分からなければ稟議は進みません。
LINE公式アカウントの費用はプランで決まり、月額0円・5,000円・15,000円(税別)の3段階です1。
ただし、届いた注文を取り込んで在庫や請求へつなぐ仕組みは別の費用で、条件によって大きく変わります。
費用をこの2層に分け、自社の通数と連携の要否を当てはめたうえで、0円のプランを使って少数の取引先から試すのが確実な進め方です。
注文対応の負担が月額の問いになる場面
取引先がLINEのトークで「明日の納品分、Aを10ケース」と送ってきたとします。
受注側では、その文面を誰かが読み、受注台帳や販売管理の画面へ品目と数量を打ち込み、在庫を確かめてから出荷の手配へ回します。
電話がLINEに変わっても、この流れのうち変わるのは注文が届く入口だけです。
そのため「月額いくらか」という問いには、二つの答えが含まれます。
一つはLINE公式アカウントという入口を使うための料金で、もう一つは届いた注文を取り込み、在庫や請求とつなぐための費用です。
前者はLINEヤフーが公開しているプラン表で決まります。
後者は自社でどこまで自動にしたいかで変わり、転記を社内の手作業で続けるなら追加の支払いは生じない一方、受発注の専用サービスを使えば、1社の料金例だけでも月14万〜40万円という幅があります4。
稟議でこの二つを一つの「月額」として並べると、数千円の話と数十万円の話を同じ土俵で比べることになり、判断を誤りやすくなります。
費用を二つの層に分けて見ると、どこに支払いが発生し、どこに社内の手間が残るのかが見えてきます。
LINE公式アカウントの3プラン
LINE側の費用は、LINE公式アカウントの料金プランで決まります。
2026年10月時点の表示では、プランは次の3つです1。
- コミュニケーション:月額0円、無料メッセージ200通、追加配信は不可
- ライト:月額5,000円(税別)、無料メッセージ5,000通、追加配信は不可
- スタンダード:月額15,000円(税別)、無料メッセージ30,000通、超えた分は従量課金
アカウントを開設した時点ではコミュニケーションプランが適用され、ライトやスタンダードを使うには開設後にプランを変更します1。
つまり最初の月額は0円から始まり、上位プランへ切り替えたときに初めて固定費が発生します。
プランの違いは、月額の固定費と、その中に含まれる無料メッセージの通数です。
受注の仕組みとして見ると、プランを分けるのは受け取る注文の数ではなく、自社から送るメッセージの数になります。
どの送り方が通数に数えられるかは次の節で扱いますが、取引先の数がそのままプランを決めるわけではない点を押さえておくと、見積もりの読み違いを防げます。
LINE単体でできることと別に要ること
LINE公式アカウントを外部のシステムとつなぐ入口が、Messaging APIです。
APIは、システム同士をつなぐための接続口のことです。
Messaging APIは無料で始められ、使える無料メッセージの数は公式アカウントの料金プランによって異なります2。
APIを使う場合も、LINE側の費用はプラン料金と通数の枠で考えることになります。
取引先が送ったメッセージは、Webhookという仕組みで自社が用意したサーバー(ボットサーバー)へ届けられます2。
Webhookは、出来事が起きたときに指定した送り先へ自動で知らせる仕組みです。
取引先が送った画像や動画、音声、ファイルも取得でき、トーク画面に表示するリッチメニューも設定できます2。
ただし、ここで示されているのは送受信やファイル取得といった機能で、受注台帳への登録や在庫の引き当て、請求書の作成までを行う機能ではありません。
Webhookで受け取った文面を品目と数量に分け、販売管理へ書き込むのは、受け取ったサーバー側の処理です。
取得できるファイルは一定期間後に自動で削除されるため2、取引先が注文書を写真で送ってくる運用なら、その画像を自社側へ保存する手当ても必要になります。
LINEだけで済むのは、注文が文字で届き、取引先とやり取りできるところまでです。
その先の転記をなくしたいなら、受発注のサービスを使うか、自社で開発するかという、注文処理側の選択が加わります。
▼ 図の内容を文字で読む
- 取引先がLINEのトークで注文を送る
- LINE公式アカウントで受け取る(LINE側:プラン料金と通数)
- 文面を読み取り品目と数量に分ける(注文処理側:手作業・サービス・開発)
- 販売管理・在庫・請求へ反映する(注文処理側)
▼ 図の内容を文字で読む
- コミュニケーション
- 月額0円・無料メッセージ200通・追加配信不可(開設時のプラン)
- ライト
- 月額5,000円(税別)・無料メッセージ5,000通・追加配信不可
- スタンダード
- 月額15,000円(税別)・無料メッセージ30,000通・超過分は1通約3円からの従量課金
出典:LINEヤフー株式会社「LINE公式アカウント 料金プラン」(2026年10月閲覧時点、日本向け、税別表示)
取引先数と注文件数で、LINEのメッセージ料金はどう変わるか
通数に数えられる送り方と数えられない送り方
通数に数えられるかどうかは、メッセージの送り方で決まります。
Messaging APIの料金説明では、プッシュ、マルチキャスト、ブロードキャスト、ナローキャストという送り方が通数に数えられ、応答メッセージ(reply)は数えられません3。
応答メッセージは、届いたメッセージへの返信として送るものです。
それ以外の、自社の側から送り始める送り方が、数えられる側に入ります。
受注の流れに置き換えると、取引先が「Aを10ケース」と送ってきて、それに「承りました」と応答する分は通数を減らしません。
一方、翌日になって自社から「本日出荷しました」と知らせる、あるいは取引先全員へ休業日の案内を送るといった連絡は、数えられる側に入ります。
もう一つの決まりは、通数が送信対象の人数で数えられることです3。
1回の送信で30人に送れば30通で、届かなかった宛先は数えられません3。
取引先が1社でも、発注担当者と店長の2人がつながっていれば、一斉案内は2通として数えられます。
取引先の社数ではなく、つながっている人数で数える点が、試算でずれやすいところです。
なお、ここでの数え方はMessaging APIで送るメッセージについての説明です。
管理画面から手で返信する運用を考えている場合は、その送り方がどう扱われるかをLINEヤフーの料金プランの表示で確かめておくと、試算の前提がずれません。
スタンダードの追加配信と従量課金
無料の通数を超えたときの扱いは、プランで大きく違います。
追加のメッセージを従量課金で送れるのはスタンダードだけで、コミュニケーションとライトでは無料通数を使い切ると追加の配信ができません1。
スタンダードの追加分は1通約3円(税別)からで、配信数によって単価が変わります1。
受注の連絡でこの違いが効いてくるのは、月の途中で無料通数が尽きた場面です。
ライトで5,000通を使い切ると、その月は数えられる送り方での連絡が送れなくなります。
休業日の案内なら翌月に回せても、出荷連絡や欠品の知らせを通数のかかる送り方で送っていると、取引先への連絡そのものが止まります。
余裕の少ないプランを選ぶなら、どの連絡を応答で返し、どの連絡を通数のかかる送り方で送るかを分けておくことが、費用だけでなく連絡の途切れを避けるうえでも大切です。
スタンダードの追加分は、超えた通数に約3円を掛けるとおおよその入口が分かります。
ただし単価は配信数で変わるため、この掛け算は確定額ではなく、桁をつかむための目安にとどまります。
3万通という無料枠を受発注の連絡だけで超えるかどうかは、自社の数字を当てはめると見えてきます。
自社の通数を試算する
通数の試算は、誰に、月に何回、数えられる送り方で送るかの掛け算で組み立てます。
受け取る注文の件数ではなく、自社から送り始める連絡の数を数えるのが要点です。
仮に、LINEでつながる取引先が60社あり、1社あたり平均2人とつながっているとします。
月2回、全員に休業日や新商品の案内を送れば、120人×2回で240通になり、コミュニケーションプランの200通を超えます。
これに加えて注文ごとに出荷連絡をプッシュで送り、注文が月300件あれば300通が加わって540通です。
この場合はライトの5,000通に収まります。
同じ60社でも、出荷連絡は送らず、届いた注文への応答だけで受付を済ませ、一斉案内を月1回・各社の担当者1人に絞れば60通で、0円のプランに収まります。
反対に、取引先ごとにつながる人が多く、毎日の在庫案内を全員へ送る設計にすると、数字は一気に膨らみます。
プランを決めるのは取引先の数そのものより、どの連絡を誰に送る設計にするかです。
この試算は送り方を仮に置いた計算で、実際の通数は運用してみないと確定しません。
だからこそ、最後の節で扱うように、少数の取引先で試して実際の通数を数えることに意味があります。
▼ 図の内容を文字で読む
- 応答メッセージ(reply)
- 届いたメッセージへの返信。通数に数えない
- プッシュ・マルチキャスト
- 自社から送り始める連絡。送信対象の人数分を数える
- ブロードキャスト・ナローキャスト
- 送信対象の人数分を数える。届かない宛先は数えない
出典:LINEヤフー株式会社「LINE Developers Messaging API 料金(メッセージ通数)」(Messaging APIで送るメッセージが対象)
▼ 図の内容を文字で読む
- 自社から送り始める連絡を書き出す(出荷連絡・一斉案内など)
- 届いた注文への応答で済む受付確認は数えない
- 連絡ごとに送る相手の人数と月の回数を掛ける
- 合計をプランの無料通数(200通・5,000通・30,000通)と比べる
LINE公式アカウント・受発注サービス・個別開発のどれが合うか
比較の軸をそろえる
ここまでで分かったLINE側の費用に、注文処理側の費用を重ねます。
受け方は大きく、LINE公式アカウントを中心に手作業で受ける、受発注に特化したサービスを使う、Messaging APIを使って自社向けに開発する、の三つに分けられます。
比べるときは月額だけでなく、初期費用、注文の取り込み方、在庫や請求との連携、取引先側の操作という同じ軸でそろえると、何に対して払う費用なのかがずれません。
表の受発注サービスの欄にある金額は、TS-BASEという1社の料金例です4。
料金は基本システムとオプションの組み合わせで構成され、示されているのは受注プランと受注+出荷プランの6件で、金額が変わる条件やLINE連携についての説明はありません4。
LINEで受発注を行う場合の相場ではなく、受発注の仕組みそのものに払う費用はLINEのプラン料金と桁が違うことがある、と読むための材料です。
個別開発の費用は、何を作るかで決まるため、表では見積もりで確かめる項目にしています。
LINE側のプラン料金は開発した場合も同じようにかかり、その上に開発と運用の費用が乗る、という構造だけは先に押さえておけます。
条件別の選び方
連携が要らず、注文がそれほど多くない場合は、LINE公式アカウントを中心にした受け方が候補になります。
注文が文字で残るので、電話の聞き取りを書き起こす手間や、聞き間違いを確かめ直す手間は減らせます。
一方で、トークを読んで受注台帳や販売管理へ打ち込む転記は残ります。
転記の量よりも聞き間違いや営業時間外の電話に困っているなら、この方法で困り事の一部は解消に向かいます。
販売管理や在庫、請求との連携が要る場合は、受発注サービスか個別開発のどちらかになります。
品目が多く、注文が毎日まとまって届き、転記そのものが業務を圧迫しているなら、転記をなくす仕組みに費用をかける理由が出てきます。
既製のサービスは機能が決まっている分、自社の販売管理とつながるか、LINEから注文を受けられるかを最初に確かめる必要があります。
料金例を示したTS-BASEの料金ページにも、LINE連携についての説明はありません4。
個別開発は、自社の注文の形や連携先に合わせて作れる一方、受け取った内容を処理するサーバーを自社側で用意することが前提です2。
取引先の操作をどう設計するかも、自社で決めることになります。
自由な文面で送ってもらえば取引先は楽ですが、品目や数量を読み取る処理が難しくなります。
メニューなどで送り方の形を決めれば読み取りは安定しますが、取引先には新しい操作を覚えてもらうことになります。
どれが優れているかではなく、転記をどこまで減らしたいか、取引先にどこまで操作をお願いできるかで、合う方法が変わります。
個別開発は見積もりで何を確かめるか
個別開発の見積もりは、作る範囲を言葉にできていないと比べようがありません。
Messaging APIで分かっているのは、取引先のメッセージがWebhookで届き、画像やファイルも取得できるところまでで2、その先は開発会社が作る部分です。
依頼の前に、次の点をどう考えているかを伝えられるようにしておくと、見積もりの前提がそろいます。
- 受け取った注文の文面を、品目・数量・納品日にどう分けるか(自由な文面か、決まった形で送ってもらうか)
- 注文書の画像やファイルを、自動削除の前にどこへ保存するか
- 販売管理・在庫・請求のどれへ、どの方法で書き込むか
- 受付確認や出荷連絡を、応答で返すか、通数に数えられる送り方で送るか
- サーバーの運用や障害時の対応を誰が担い、月にいくらかかるか
最後の項目は見落とされやすい部分です。
開発費は一度払えば終わりに見えますが、受信を受け持つサーバーは動かし続ける必要があり、LINE側のプラン料金もこれとは別にかかります2。
見積もりでは、初期の開発費、毎月の運用費、LINEのプラン料金を分けて書いてもらうと、他の方法と同じ軸で並べられます。
| 比較の軸 | 公式アカウント中心 | 受発注サービス | 個別開発(Messaging API) |
|---|---|---|---|
| 月額 | LINEのプラン料金 0円/5000円/15000円(税別) | 1社の料金例で14万〜40万円(LINE連携の記載なし) | LINEのプラン料金と運用費(運用費は見積もりで確認) |
| 初期費用 | プラン表は月額のみ。設定は社内作業 | 1社の料金例で50万〜150万円 | 見積もりで確認 |
| 注文の取り込み | トークを読んで手作業で転記 | 見積もりで確認 | Webhookで受信し自社サーバーで処理 |
| 在庫・請求との連携 | 別作業として残る | 見積もりで確認 | 開発範囲による(見積もりで確認) |
| 取引先側の操作 | 送り方を事前に決めて試行で確認 | 見積もりで確認 | 設計による(見積もりで確認) |
月額以外にかかる初期費用・設定・取引先への周知の負担
初期費用の幅
月額だけを比べると、受発注の仕組みにかかる費用の大きさを見誤ります。
TS-BASEの料金例6件では、初期費用は50万円から150万円、月額は14万円から40万円の幅があります4。
初期費用は50万円、67万円、63万円、95万円、150万円、150万円で、同じサービスの中でも3倍の開きがあります。
1年目にかかる額で見ると、差はさらにはっきりします。
最も低い例(初期50万円・月14万円)は1年で218万円、最も高い例(初期150万円・月40万円)は630万円です。
LINE公式アカウントのスタンダードを1年使っても15,000円×12か月で18万円(税別)なので1、LINE側の費用と注文処理側の費用は桁が異なることがあると分かります。
ただし、この幅が何によって生じているのかは料金ページに書かれていません4。
受注プランか受注+出荷プランかの違いはあっても、取引先数や注文件数、オプションの構成といった条件は示されていないため、自社がどの例に近いかは判断できません。
あくまで1社の料金例で、LINE経由の受発注の相場として使える数字ではない点は押さえておく必要があります。
目安と実例が食い違うときの読み方
同じ竹田印刷は、受発注システムの選び方を解説する記事で、SaaS型のコストの目安を示しています5。
SaaS型は、ソフトウェアを自社で持たずにインターネット経由で利用する形のことです。
記事の表では初期30〜50万円・月10〜20万円とされ、本文では「導入までに50万円程度、毎月の運用に20万円程度」と書かれています5。
いずれも「竹田印刷調べ」で、企業規模などの前提は記載されていません5。
この目安と、同じ会社の料金ページの例を並べると食い違いがあります。
料金例の月額は14万〜40万円、初期費用は50万〜150万円で4、目安の上限を超える例が含まれています。
また、どちらも同じ会社の資料なので、二つがそろって相場を裏づけているとも読めません。
食い違う理由は資料からは読み取れませんが、判断への影響ははっきりしています。
目安の数字を稟議の予算に置くと、実際の見積もりがその2倍になったときに説明がつかなくなります。
目安は、受発注の仕組みには数十万円単位の費用がかかり得るという桁感をつかむところまでにとどめ、金額そのものは自社の条件を伝えた見積もりで確かめるのが安全です。
見積もり依頼時の確認項目
複数の会社から見積もりを取るときは、同じ条件を伝えないと、金額の差が条件の差なのか価格の差なのか区別できません。
依頼の前に、次の条件を書き出しておくと比べやすくなります。
- LINEで注文を受ける取引先の数と、1社あたりのつながる人数
- 月の注文件数と、扱う品目の数
- 注文の届き方(自由な文面か、写真の注文書か、決まった形式か)
- 連携したい先(販売管理・在庫・請求・出荷)と、いま使っているシステム
- 受付確認・出荷連絡・一斉案内のどれを、どの頻度で送るか
見積もりを受け取ったら、初期費用に何が含まれるか、LINE公式アカウントのプラン料金が含まれているか、取引先側に何をしてもらう必要があるかを並べて見ます。
特に最後の点は、各社の説明を受けないと分からない部分です。
取引先に自社のアカウントとつながってもらうだけで済むのか、新しい操作を覚えてもらうのかで、導入の手間は受注側の設定作業だけでは終わりません。
取引先へ案内する前に、受注側で決めておきたいこともあります。
どのアカウントに送ってもらうか、注文の書き方をどこまでそろえてもらうか、何時までの注文を当日扱いにするか、受付の確認がどの形で返ってくるか、の四つです。
これが決まらないまま案内すると、取引先ごとに送り方がばらばらになり、読み取りと問い合わせの手間がかえって増えることがあります。
案内の文面は、取引先の担当者が最初の1件を迷わず送れるかどうかを基準にすると、内容を絞りやすくなります。
▼ 図の内容を文字で読む
- 解説記事の表(竹田印刷調べ)
- SaaS型の目安 初期30〜50万円・月10〜20万円
- 解説記事の本文
- 導入までに50万円程度・毎月の運用に20万円程度
- 料金ページの料金例6件
- 初期50〜150万円・月14〜40万円(目安の上限を超える例を含む)
出典:株式会社竹田印刷「Webの受発注システムの選び方とコストの目安」(2026年更新、竹田印刷調べ、前提条件の記載なし)、同「TS-BASE 受発注 料金ページ」(2026年10月閲覧時点、受注プラン/受注+出荷プランの料金例6件)
費用に見合うかを導入前に確かめ、小さく試す手順
導入前に数える3つの数字
費用に見合うかを判断するには、比べる相手が要ります。
LINE側の料金や見積もりの金額が高いか安いかを決める基準になるのは、いまの受注の数字です。
導入前に、次の三つを1か月ほど数えておくと判断の土台になります。
- 注文の件数:電話・FAX・メールそれぞれで、月に何件届いているか
- 受付と転記の時間:1件を受けてから販売管理などへ入力し終えるまで、どれくらいかかっているか
- ミスの件数:聞き間違いや転記ミスによる訂正・再出荷が、月に何件あったか
件数は通数の試算と見積もり依頼の両方に使い、時間とミスは費用と比べる側の数字になります。
転記に月何時間かかっているかが分かれば、受発注サービスの月額がその手間に見合うかを、社内で同じ単位で話せるようになります。
LINEに切り替えて時間やミスがどれだけ減るかは業務の中身によって違うため、自社で測った値で判断することになります。
0円プランから少数の取引先で試す
LINE公式アカウントは、開設時点ではコミュニケーションプランで、月額0円、無料メッセージ200通から始まります1。
この枠を使えば、固定費をかけずに小さく試せます。
試す相手は、LINEでの注文を求めてきた取引先など、数社に絞るのが現実的です。
受付は届いた注文への応答で返し、通数に数えられる一斉案内は控えれば、200通の枠でも運用を確かめられます。
期間中は、届いた注文の件数、自社から送った通数、トークを読んで転記するのにかかった時間、書き方の違いによる問い合わせの回数を記録しておきます。
この試行で分かるのは、費用以上に運用の実際です。
取引先が品番で書くのか商品名で書くのか、写真で送ってくるのか、締め時刻を守れるのかといった点は、実際に受けてみないと見えません。
一方で、200通の枠は追加ができないため1、出荷連絡まで送ると試行の途中で枠が尽きることがあります。
試せる範囲は、取引先の協力と、応答中心で受けられるかどうかに左右されます。
上位プラン・連携サービスへ進む判断
試行の記録がそろったら、二つの方向で判断します。
一つはLINE側のプランです。
取引先を広げたときの通数を、試行で実際に送った通数から見積もり、200通に収まらなければライト、5,000通を超える見込みならスタンダードを検討します1。
もう一つは注文処理側です。
試行した数社だけでも転記の時間が負担になっていて、取引先を広げればその分増えると見込まれるなら、受発注サービスや開発の見積もりへ進む理由になります。
そのときは、試行で分かった注文の届き方や件数を、見積もり依頼の条件としてそのまま使えます。
反対に、転記の時間が許容できる範囲に収まり、困っていたのが聞き間違いや営業時間外の電話だったと分かれば、公式アカウント中心の受け方を続け、必要に応じてプランを上げるだけで足りる場合もあります。
どちらに進むにしても、0円の段階で測った数字があれば、稟議で「月額いくらで、何が変わるか」を自社の言葉で説明できます。
▼ 図の内容を文字で読む
- いまの受注を数える
- 注文の件数・受付と転記の時間・ミスの件数
- 0円のプランで数社と試す
- 受付は応答で返し、無料200通の枠で運用する
- 通数と手間を記録する
- 送った通数・転記の時間・書き方による問い合わせ
- 次の一手を決める
- プランの変更か、受発注サービスや開発の見積もりか
出典:LINEヤフー株式会社「LINE公式アカウント 料金プラン」(2026年10月閲覧時点、開設時はコミュニケーションプラン・無料200通・追加配信不可)
LINE側の料金は表で分かっても、自社の注文の流れのどこに転記が残り、どこまで連携が要るかは、料金表を見比べるだけでは決めにくいためです。
取引先の数や送る予定の連絡、いまの転記の流れをもとに、必要になりそうなプランの見当と、見積もり依頼に書くべき条件を一緒に整理できます。無料相談で要件を整理する
要点の整理
| 軸 | 基準 |
|---|---|
| LINE側の月額 | 公式アカウントのプランで決まる(0円・5,000円・15,000円/月、税別) |
| 通数を増やすもの | 自社から送り始める連絡。応答メッセージは数えず、プッシュなどは送信対象の人数分 |
| 無料通数を超えたとき | 追加配信できるのはスタンダードのみ(1通約3円からの従量課金) |
| 注文処理側の費用 | 連携の要否で方法が分かれ、金額は自社条件での見積もりで確かめる |
| 目安の扱い | 1社の目安と料金例は食い違うため、相場としては使わない |
| 始め方 | 0円のプランで数社と試し、通数と転記の手間を測ってから判断する |
試行で通数や転記の時間を測っても、その数字から上位プランで足りるのか、受発注サービスや開発へ進むべきかは、比べる相手の条件がそろわないと判断しにくいためです。 測った数字を見積もり依頼の条件に置き換え、複数の見積もりを同じ軸で読み比べる際の確認点を整理できます。
よくある質問
LINE公式アカウントの無料プラン(コミュニケーション)だけで注文を受けることはできますか。
取引先からのメッセージを受け取り、応答で受付を返す使い方なら、月額0円のコミュニケーションプランでも始められます。
無料メッセージは200通で、超えた分の追加配信はできないため1、出荷連絡や一斉案内を多く送る運用では上位プランが必要になります。
また、トークを読んで販売管理などへ入力する転記は、このプランでも手作業で残ります。
取引先から届く注文への返信は、メッセージ通数に数えられますか。
Messaging APIの応答メッセージ(reply)は通数に数えられません3。
一方、プッシュやマルチキャストなど自社から送り始める送り方は、送信対象の人数分が数えられます3。
管理画面から手で返信する運用の場合は、その扱いをLINEヤフーの料金プランの表示で確かめておくと安心です。
スタンダードプランで無料の3万通を超えると、追加はどう課金されますか。
スタンダードでは超えた分が従量課金になり、1通約3円(税別)からで、配信数によって単価が変わります1。
コミュニケーションとライトには従量課金がなく、無料通数を使い切ると追加の配信ができません1。
Messaging APIを使うと別料金がかかりますか。
Messaging APIは無料で始められ、使える無料メッセージの数は公式アカウントの料金プランで異なります2。
ただし、取引先のメッセージを受け取って処理するサーバーは自社側で用意する前提なので2、その開発費や運用費はLINEの料金とは別に見込む必要があります。
受発注サービスの見積もりを依頼するとき、最初に伝えるべき条件は何ですか。
LINEで注文を受ける取引先の数とつながる人数、月の注文件数と品目の数、注文の届き方、連携したい先といま使っているシステム、送る予定の連絡の種類と頻度です。
同じ条件で複数社に依頼すると、金額の差が条件の差か価格の差かを見分けやすくなります。
あわせて、LINEから注文を受けられるかどうかも最初に確かめておくと、比べる前提がそろいます。
取引先にLINEを使ってもらうために、事前に何を決めておけばよいですか。
どのアカウントに送ってもらうか、注文の書き方をどこまでそろえてもらうか、何時までの注文を当日扱いにするか、受付の確認がどの形で返ってくるか、の四つを決めておくと案内がぶれません。
決めないまま始めると、取引先ごとに送り方がばらばらになり、読み取りと問い合わせの手間が増えることがあります。
- 1 出典:LINEヤフー株式会社「LINE公式アカウント 料金プラン」(2026年)
- 2 出典:LINEヤフー株式会社「LINE Developers Messaging API 概要」(2026年)
- 3 出典:LINEヤフー株式会社「LINE Developers Messaging API 料金(メッセージ通数)」(2026年)
- 4 出典:株式会社竹田印刷「TS-BASE 受発注 料金ページ」(2026年)
- 5 出典:株式会社竹田印刷「Webの受発注システムの選び方とコストの目安」(2026年)