WEB受発注システムの月額費用はどう決まる？多拠点導入前に確認すべきこと

◆監修・編集責任者　小園 将隆　2026年9月19日

B2B EC-COLUMN

WEB受発注システムの月額費用は何で決まるのか

WEB受発注システムの月額費用は、拠点数そのもので決まるとは限らず、利用形態とサーバー構成、必要な機能要件を含めたシステム全体の構成で決まる形があります。自社が公開している料金では、システムの土台となるベースエンジン利用料が最小構成で月額170,000円から¹、標準的な利用を想定したモデルケースのASP利用料金が月額260,000円です¹。この形の場合、拠点が一つ増えるたびに月額が機械的に積み上がるわけではない一方、拠点が増えることで同時利用や必要機能が変われば、その変化が構成を通じて月額に反映されます。多拠点導入の総額を出すときは「拠点あたりいくらか」を尋ねる前に、その見積もりで金額が動く変数が拠点数なのか、アカウント数なのか、構成なのかを特定してください。この記事が当てはまるのは、店舗や事業所ごとに発注担当者を置き、本部が一括して契約と支払いを行うチェーン本部の場合です。各拠点が個別に契約する前提であれば課金の単位そのものが変わるため、後半の試算の考え方はそのままでは使えません。

サーバー構成・要件によって決まる基本料金

月額費用を問い合わせると「拠点あたり◯円」という単価が返ってくることを期待しがちですが、料金表が拠点単価で組まれているとは限りません。
自社が公開している料金では、ベースエンジン利用料が最小構成で月額170,000円から¹、モデルケースのASP利用料金が月額260,000円と示されています¹。
ここで「最小構成」と「モデルケース」という前提の言葉が分かれている点が重要です。
同じ製品でも、前提に置く構成が違えば月額の水準は変わるため、金額だけを並べて比べると実態を見誤ります。

ASPとは、ベンダー側が用意した環境をネットワーク経由で利用する提供形態を指します。
ベースエンジンとは、受発注の処理を担うシステムの土台部分のことで、その利用料が最小構成で月額170,000円からという形で示されています¹。
つまり月額の中身は、どの提供形態を選ぶか、その上にどれだけの構成と機能を載せるかで決まる積み上げになっています。
この積み上げの構造を理解しないまま他社の提示額と比べると、前提の違う数字を同じ土俵に乗せてしまいます。

構成に含まれる要素は、サーバーの台数と性能、冗長化の有無、保管するデータ量、基幹システムや販売管理システムとの連携本数などです。
BtoBの受発注は、締め日の前後や週明けの朝など、特定の時間帯に発注が集中する性質があります。
拠点が増えれば同じ時間帯に操作する人数も増えるため、処理の余裕を確保する目的で構成の見直しが必要になる場面があります。
これが「拠点数が月額に効く経路」ですが、効き方は比例ではなく、ある規模を超えたときに構成として反映されるという段差のある動き方になります。

拠点数だけを基準とした課金ではない

見積書を読むときに最初に特定すべきなのは、金額そのものではなく「何が増えたら金額が動くのか」という変数です。
受発注システムの課金単位として使われる考え方には、拠点数を単位とするもの、利用者アカウント数を単位とするもの、取引先数を単位とするもの、そして構成と機能要件を単位とするものがあります。
この四つは併用されることもあり、月額は構成で決まるが利用者アカウントの上限だけは別枠、といった組み合わせも起こります。
変数を特定しないまま総額を出そうとすると、掛け算の式そのものが間違っているという事態になります。

経営層から問われるのは、たいてい「全店に入れたら月額はいくらになるのか」という一点です。
課金の変数が構成であれば、本部が一括で契約する限り、拠点が増えても月額の本数は一本のままという読み方ができます。
一方でアカウント数が変数であれば、拠点数ではなく各拠点に何人の発注担当者を置くかが総額を左右します。
同じ「多拠点導入」でも、拠点を数えるのか人を数えるのかで説明の組み立てが変わるため、社内で説明する前に変数を確定させておく価値があります。

注意したいのは、拠点数に応じて段階的に単価が変わるプランがあるかどうかについて、自社の公開料金ページでは記載を確認できなかった点です。
確認できていない以上、「拠点数が増えれば段階的に上がるはずだ」とも「何拠点でも同額のはずだ」とも決めつけることはできません。
公開情報で分かるのは、最小構成とモデルケースという二つの前提における月額の水準までです¹。
そこから先は見積もりの場で、拠点数と月額の関係を条件つきで明示してもらう必要があります。

拠点数が増えると月額費用はどう変わるのか

自社事例に見る料金レンジ（月額17万円〜26万円）

公開されている二つの金額は、単価表としてではなく「幅」として読むのが実務的です。
ベースエンジン利用料の最小構成が月額170,000円から¹、ASP利用料金のモデルケースが月額260,000円¹という二点が示されているため、標準的な導入はこの水準の間に収まりやすいと読めます。
ただし最小構成の側には「から」という表記が付いており、下限を示す値であって固定額ではありません。
経営層に最初の目安を伝える段階では、単一の数字ではなくこの幅と、幅が生まれる理由をセットで示すほうが後の修正が少なくなります。

幅を生んでいるのは拠点数そのものではなく、構成と要件の差です。
多拠点で運用する場合に必要になりやすいのは、拠点ごとの権限設定、拠点別の価格や取引条件の出し分け、配送先の管理、拠点単位での締めや集計、拠点ごとの帳票出力といった機能です。
これらは「拠点が増えたから追加する」のではなく「多拠点で運用するから最初から必要になる」性質のもので、拠点が十でも数十でも要件としては同じように発生します。
したがって、多拠点導入の費用は拠点数に沿って伸びるというより、多拠点運用に踏み切った時点で一段上の構成になる、という捉え方のほうが実態に近くなります。

この理解に立つと、経営層への説明も変えられます。
「一店舗あたり月額いくら」という形で説明すると、店舗数が増えるたびに費用が増えるという前提が独り歩きします。
そうではなく、多拠点運用に必要な構成を一本の月額として提示し、その構成で何拠点まで対応できるのか、どの条件を超えたら構成の見直しが必要になるのかを併記する形が実態に合います。
確定額は要件定義を経てからになるため、この段階では幅と前提条件を示すところまでが正確な報告です。

拠点数と料金が連動する契約か、個別要件による契約かの違い

契約の形は、大きく二つの考え方に分かれます。
一つは拠点数や利用者アカウント数に単価を掛ける連動型で、増えた分だけ月額が上がるため予測はしやすい反面、全店展開したときの総額が大きく膨らみます。
もう一つは構成と要件で月額が決まる要件型で、契約後に拠点を追加しても原則として月額は動かず、構成の見直しが必要になった時点で改めて調整する形になります。
自社の公開料金は、最小構成とモデルケースという構成基準の示し方をしており¹、要件型の読み方と整合します。

どちらが有利かは、拠点数の絶対値と増加ペースで決まります。
拠点が多く、今後も出店で増えていく計画があるなら、拠点追加のたびに月額が上がらない要件型のほうが総額を抑えやすく、予算の組み立ても安定します。
逆に、まず数拠点で試して効果を見てから判断したいという段階では、小さく始められる連動型のほうが初期の負担は軽くなります。
自社がどちらの局面にいるのかを先に決めておくと、見積もり比較の軸がぶれません。

見分ける手がかりは見積書の中にあります。
単位の欄が「拠点」や「ID」になっていれば連動型、「式」や「一式」で構成名が併記されていれば要件型の可能性が高くなります。
あわせて、拠点を追加したときに月額が変わる条件、変わらずに使える範囲の上限、上限を超えた場合の扱いの三点を書面で確認してください。
ここまで押さえたうえで、次に初期費用が拠点ごとにかかるのかを確かめます。

初期費用は拠点ごとにかかるのか

初期費用の課金単位を見積書で確認する

初期費用については、金額も、拠点ごとに課金されるのかどうかも、公開されている料金ページでは確認できませんでした。
ここは推測で埋めずに、見積依頼の必須確認項目として扱うのが安全です。
確認すべきなのは総額よりもまず課金単位で、「一式」なのか「拠点あたり」なのか「作業工数の積み上げ」なのかによって、拠点が増えたときの増え方がまったく変わります。
月額の課金単位と初期費用の課金単位は別々に設計されていることがあるため、片方を確認しただけで両方を判断しないでください。

初期費用に含まれることの多い作業は、要件定義、環境の構築、既存データの移行、商品マスタや取引先マスタの登録、基幹システムとの連携開発、そして利用者への教育です。
このうち拠点数に応じて作業量が増えやすいのは、拠点別の設定、拠点ごとのマスタ整備、利用者教育の三つです。
したがって初期費用が「拠点あたり課金ではない」と言われても、拠点が増えれば工数が増えて初期費用の総額が動く、という経路は残ります。
課金単位と作業量の両方を確認して初めて、拠点数が初期費用に与える影響を見通せます。

拠点を追加したときに費用が動く場面

段階的に導入する計画であれば、第一期の初期費用だけでなく、第二期以降の拠点追加時にかかる費用を先に確認しておく必要があります。
費用が動きやすいのは、利用者アカウントの発行、拠点別マスタの追加、権限設計の変更、拠点別の価格表や帳票の追加、追加拠点への教育といった場面です。
これらが初期費用に含まれるのか、追加作業として都度見積もりになるのか、あるいは月額に含まれるのかは契約ごとに異なります。
「あとで追加すればよい」と考えていた作業が都度見積もりだった場合、全店展開時の総額が当初の試算から大きくずれます。

この食い違いを防ぐ実務的な方法は、見積依頼の時点で展開シナリオを文書で渡すことです。
第一期に何拠点、第二期に何拠点、最終的に全店という時間軸を示し、それぞれの時点での月額と、その時点で発生する一時費用を分けて提示してもらいます。
シナリオを渡さずに「全店導入の見積もり」とだけ依頼すると、ベンダーごとに想定する展開速度が違うため、比較できない見積もりが並びます。
ここまでで課金単位と一時費用の確認ができたので、次は自社の数字を当てはめて総額を試算します。

月額費用は拠点数の掛け算ではなく、利用形態とサーバー構成、多拠点運用に必要な機能要件の積み上げで決まる形があります。公開されている水準は最小構成で月額170,000円から¹、モデルケースで月額260,000円です¹。自社の総額を出すには、この幅を出発点に、課金の変数と一時費用の扱いを見積もりで確定させる作業が必要になります。

拠点数と月額の関係は公開情報だけでは確定できず、自社の拠点数や同時利用の見込みを前提に置いて初めて水準が見えてきます。構成で月額が決まる料金体系を実際に運用している提供元であれば、その前提の置き方から具体的に相談できます。

現在の拠点数と出店計画、拠点あたりの発注担当者数を伝えたうえで、月額が構成のどこで動くのか、どの条件を超えたら見直しが必要になるのかを確かめられます。無料相談で要件を整理する

見積もりを比べる前に確認する項目

見積依頼から契約までに確認していく時間の流れに沿って並べています。

• 月額の金額が動く変数はどれか（利用形態・サーバー構成・機能要件・アカウント数・拠点数のどれか）

• 提示された月額が最小構成の下限なのか、標準的なモデルケースなのか

• 拠点を追加したときに月額が変わる条件と、変わらずに使える範囲の上限

• 初期費用の課金単位と、第二期以降の拠点追加にかかる一時費用の扱い

• 見積もりの前提に置かれた取引先数・データ量・基幹システムとの連携本数

• 契約期間、解約時の条件、料金改定の取り決めと見積もりの有効期限

すでに候補が一社か二社に絞られている場合は、初期費用の課金単位と契約期間の条件を先に確認すると、比較のやり直しを減らせます。

自社に当てはめて試算し、契約前に確かめる

確認する項目	見積書で見るところ	記載がないときの確かめ方

自社の月額総額はどう試算するか

試算の前に固定する前提

試算は数字を掛け合わせる前に、前提を文書で固定するところから始めます。
固定すべきなのは、現在の拠点数と出店計画を含めた将来の拠点数、各拠点に置く発注担当者の人数、取引のある仕入先や取引先の数、締め日前後の同時利用の見込み、そして連携する基幹システムの本数です。
これらはいずれも、課金の変数になりうる項目か、サーバー構成の前提になる項目です。
前提を固定せずに各社へ依頼すると、各社が独自の前提を置いて見積もるため、金額差が構成の差なのか前提の差なのか分からなくなります。

前提のうち、社内で数字を出しにくいのが同時利用の見込みです。
厳密な予測は難しいため、締め日や週明けなど発注が集中する時間帯を特定し、その時間帯に操作する人数の最大値を概算で置く形で十分です。
この概算を各社に同じ条件として渡すことが、比較可能な見積もりを得る条件になります。
前提が揃えば、金額差はそのまま構成と要件の差として読めるようになります。

レンジで置いてから絞り込む

前提が固まったら、まず公開されている水準をレンジの起点に置きます。
最小構成のベースエンジン利用料が月額170,000円から¹、モデルケースのASP利用料金が月額260,000円¹という二点を、下限側と標準側の目安として扱います。
多拠点運用では拠点別の権限や価格の出し分けといった要件が加わるため、最小構成の下限をそのまま自社の見込み額として使うのは危険です。
社内向けの初期報告では、標準側を中心に置き、要件定義で増減しうる旨を添える形が現実的です。

総額の出し方も、課金の変数に合わせて変えます。
構成で決まる要件型であれば、本部一括契約の月額は原則として一本であり、「拠点数×単価」という式は使いません。
アカウント数が変数であれば、拠点数ではなく発注担当者の総数を積み上げます。
どちらの式を使うのかを見積書で確定させたうえで計算しないと、桁の違う結論を経営層に報告することになります。

年額と複数年の総額で示す

経営層が判断に使うのは月額そのものよりも、年度予算に載る年額と、投資判断の期間に対応した複数年の総額です。
月額に加えて初期費用、拠点追加時の一時費用、運用開始後の保守や追加作業の見込みを並べ、年額換算と複数年の合計まで出してください。
このとき、確定している金額と、前提を置いて見込んだ金額を分けて示すことが重要です。
分けずに一つの表にまとめると、後から金額が動いたときに試算全体の信頼が失われます。

試算が崩れやすい要因も、あらかじめ注記しておきます。
取引先の数が想定を超えて増えた場合、EDIなど外部との連携を後から追加する場合、繁忙期の同時利用が想定を上回った場合、そして業態の異なる拠点が加わって要件が分岐する場合です。
この四つは、いずれも構成の見直しにつながりうるため、再見積もりの引き金として契約前に共有しておく価値があります。
要因を先に共有しておけば、実際に金額が動いたときも想定の範囲内として説明できます。

確認する項目	見積書で見るところ	記載がないときの確かめ方
月額の課金単位	単位の欄が「式」か「ID」か「拠点」か	拠点を追加したとき月額が変わるかを条件つきで書面回答してもらう
提示額の前提	最小構成かモデルケースかの記載	前提の構成内容と、その構成で対応できる範囲を明示してもらう
利用者数の上限	アカウント数や同時接続の記載	上限の有無と、超えた場合の扱いを確認する
連携の範囲	基幹システムとの連携本数の記載	連携一本あたりの扱いが月額側か一時費用側かを確認する
再見積もりの条件	構成変更に関する記載	どの条件を超えたら再見積もりになるかを列挙してもらう

契約前に確認すべき点

公開情報で確認できないことを先に一覧化する

契約条件のうち、最低契約期間や無料で試せる期間といった取り決めについては、公開されている料金ページでは確認できませんでした。
初期費用の金額と拠点ごとの課金の有無、拠点数に応じた段階的な料金プランの有無についても同様に、公開情報からは確認できていません。
これらは金額そのものよりも総額への影響が大きい項目であり、口頭の説明ではなく見積書または契約書の条文として残す必要があります。
確認できていない項目を一覧にして先方に渡し、そのまま回答欄として埋めてもらう進め方が、抜け漏れを防ぐうえで確実です。

価格の時点と有効期限を確認する

公開されている料金ページには価格の発行年や改定時期の明記がなかったため、本記事では2026年時点で表示されていた価格として扱っています¹。
社内の稟議資料に金額を載せる際は、いつ時点の価格なのかを必ず併記してください。
あわせて見積書側にも、価格の基準時点と有効期限、契約後の料金改定に関する取り決めを記載してもらいます。
稟議が長期化する案件では、審議の途中で見積もりの有効期限が切れ、条件が変わるという事態が実際に起こります。

料金改定の条項は、要件型の契約ほど確認の価値があります。
拠点追加で月額が動かない契約であっても、改定条項によって別の経路で月額が変わる可能性が残るためです。
改定の通知時期、改定の上限や算定根拠、改定時に契約を見直せるかどうかを確認しておくと、複数年の総額の精度が上がります。
ここまで確認したうえで契約に進めば、経営層に示した試算と実際の支払いのずれを小さく保てます。

確認する項目	見積書で見るところ	記載がないときの確かめ方
最低契約期間	契約期間と更新の条項	期間の定めと中途解約時の扱いを条文で明示してもらう
試用や無料期間	利用開始前の期間に関する記載	評価目的の利用が可能か、その条件と費用を確認する
初期費用の課金単位	初期費用の内訳と単位	一式か拠点あたりかを明記し、拠点追加時の扱いを併記してもらう
価格の基準時点	見積書の作成時点と有効期限	有効期限と、期限後に条件が変わる場合の取り扱いを確認する
料金改定	改定に関する条項	通知時期と算定根拠、改定時に契約を見直せるかを確認する

要点の整理

軸	基準
月額の決まり方	拠点数ではなく、利用形態・サーバー構成・機能要件の積み上げで決まる形がある
公開されている水準	ベースエンジンは最小構成で月額170,000円から、ASPはモデルケースで月額260,000円
拠点追加の影響	比例ではなく、同時利用や要件の変化を通じて構成に反映される
初期費用	金額と拠点別課金の有無は公開情報で確認できず、課金単位を見積書で確認する
契約条件	最低契約期間や無料期間は公開情報で確認できず、条文と価格の基準時点を書面で確認する
社内報告の形	単一の金額ではなく、前提つきの幅と年額・複数年の総額で示す

初期費用の課金単位や契約期間の条件は公開情報では確認できない項目であり、書面で条件を示せる相手に直接確認するのが最短です。展開シナリオを前提にした見積もりであれば、第二期以降の一時費用まで含めて整理できます。 段階導入の時間軸を渡して、各時点の月額と一時費用、再見積もりになる条件、価格の基準時点と有効期限を一つの見積書として確かめられます。

よくある質問

拠点数が二倍になったら、月額費用も二倍になりますか。

課金の変数によって答えが変わります。利用形態やサーバー構成、機能要件で月額が決まる契約であれば、本部が一括で契約している限り拠点が増えても月額が自動的に倍になることはありません。ただし同時に操作する人数やデータ量が増えて構成の見直しが必要になれば、その時点で月額が変わります。一方、拠点数やアカウント数に単価を掛ける契約であれば、原則として増えた分だけ上がります。まず見積書の単位の欄を確認してください。

経営層への報告に、公開されている料金をそのまま使ってよいですか。

目安としては使えますが、前提を必ず添えてください。公開されている値はベースエンジン利用料が最小構成で月額170,000円から¹、ASP利用料金がモデルケースで月額260,000円¹であり、いずれも特定の前提に対する金額です。多拠点運用では拠点別の権限や価格の出し分けといった要件が加わるため、下限の値をそのまま自社の見込み額にすると後で乖離します。幅として示し、確定は要件定義後になる旨を併記するのが安全です。

一部の店舗から先に導入して、後から全店に広げると費用面で不利になりませんか。

契約の形によります。構成で月額が決まる契約であれば、最初から多拠点運用に必要な要件を含めた構成にしておくことで、後の拡大時に大きな変更を避けやすくなります。注意が必要なのは一時費用のほうで、第二期以降の拠点追加にかかる設定作業や教育が初期費用に含まれるのか、都度見積もりになるのかで総額が変わります。展開シナリオを時間軸で示し、各時点の月額と一時費用を分けて提示してもらってください。

ベンダーごとに提示額が大きく違うのは、何が原因ですか。

多くの場合、前提の違いが原因です。想定する拠点数や同時利用の人数、取引先数、基幹システムとの連携本数が各社で異なれば、同じ機能でも構成が変わり金額も変わります。比較したい場合は、これらの前提を自社側で文書化して全社に同じ条件で渡してください。前提を揃えたうえで差が残る場合は、その差が構成の差なのか、含まれる作業範囲の差なのかを内訳で確認します。

料金表に載っている価格は、いつ時点のものとして扱えばよいですか。

公開ページに発行年や改定時期の明記がない場合は、閲覧した時点の表示価格として扱い、資料にもその旨を記載してください。本記事では2026年時点の表示価格として扱っています¹。稟議に使う金額は公開ページではなく見積書の値を基準にし、見積書には基準時点と有効期限、契約後の料金改定に関する取り決めを記載してもらうことをおすすめします。

1. 1　出典：株式会社イーシー・ライダー「料金プラン・費用｜BtoB EC受発注システム EC-Rider B2B II」（2026年）　経路