企業間電子商取引（BtoB EC）の初期費用は多拠点でどう変わる？見積もり前に確認すべき項目

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

B2B EC-COLUMN

多拠点のBtoB ECで初期費用が読めなくなる理由と、最初に決めておくこと

見積もりを取ったのに、支店や納品先が複数あるせいで初期費用の総額が読めず、稟議の説明で止まっている。
この場合は、自社のいう「多拠点」が何を指すかを先に決めます。
取引先の納品先なのか、自社の出荷・在庫拠点なのか、請求の単位なのかによって、見積もりの読み方が変わります。
企業間電子商取引（BtoB EC）の公開料金を見ると、初期費用や上限を決めているのは商品SKU数・取引先件数・ユーザー数などです。
拠点数で直接増える料金は見当たりません。
費用が動くのは、拠点の管理や基幹連携が標準機能に入っているか、オプションになるかという部分です。

見積もりで総額が読めなくなる場面

たとえば、取引先からの注文を電話・FAX・メールで受けている会社が、BtoB ECの見積もりを3社に頼んだとします。
依頼の際に「拠点が20か所あります」とだけ伝えたところ、回答の前提が3社で分かれました。
1社は拠点を取引先の件数に含めて料金の区分を選びました。
1社は拠点管理をオプションとして別に見積もり、もう1社は個別開発が必要だと回答しました。
この状態で初期費用の総額を並べても、それぞれの金額が何に対するものかが揃っていません。
そのため、どれが高いのかを判断できません。

この場合、総額が読めない原因は、各社の計算方法よりも手前の「拠点」という言葉にあります。
依頼した側は同じ言葉を使ったつもりでも、受け取った側はそれぞれの製品の作りに合わせて解釈します。
取引先の支店のことなのか、自社の倉庫のことなのか、請求書を分ける単位のことなのか、という解釈です。
解釈が違えば、料金表のどの区分に当てはめるか、標準機能で足りるか、追加の開発が要るかの判断も変わります。
見積もりの金額がばらつくのは、その結果です。

総務省の情報通信白書は、事業者間の電子商取引のEC化率を2023年で40.0%としています⁶。
受発注をWebへ移す取り組みは、すでに一定の広がりがある分野です。
ただ、取引の形が会社ごとに違う以上、移す前に自社の取引の形を言葉にしておく作業は省けません。
拠点が多い会社ほど、その言葉の揃え方が見積もりの比較しやすさに直結します。

『多拠点』の3つの意味（納品先・出荷拠点・請求単位）

BtoB ECの見積もりで「多拠点」と言うとき、指している対象は大きく三つに分けられます。
一つの会社が三つすべてに当てはまることもあります。
自社ではどれに当てはまり、何か所あるのかを先に書き出しておくと、提供元とのやり取りが噛み合います。

一つ目は、取引先の側の拠点です。
取引先A社の本社、工場、各地の支店がそれぞれ注文を出し、納品先も別々という形がこれに当たります。
システムには、取引先ごとに複数の納品先を持たせる必要があります。
支店ごとに価格や支払条件が違うなら、それも拠点の単位で持たせることになります。
製品によっては、拠点を「取引する相手の単位」として扱い、拠点ごとに配送先・請求先・価格・支払条件を設定できる設計になっています⁴。

二つ目は、自社の出荷拠点や在庫拠点です。
たとえば東日本と西日本に倉庫があり、注文ごとにどちらから出荷するかを決めている場合です。
ECの画面に拠点別の在庫を出すのか合計だけを出すのか、出荷指示をどの拠点に送るのかを決める必要があります。
ここは画面の設定だけでは片付かず、在庫を持っている基幹システムや在庫管理の仕組みとのつなぎ方に関わります。

三つ目は、請求や与信の単位です。
取引先の支店ごとに注文は出すが、請求書は本社にまとめて送る形がこれに当たります。
支店ごとに締め日や支払条件が違う形もあります。
この場合は、注文を受ける画面よりも、受注データを請求や会計の処理へ渡すときの項目の持ち方が問題になります。

三つのどれに当たるかで、費用が表れる場所が変わります。
取引先の拠点は、製品の標準仕様で持てるかどうかと、料金区分の数え方に表れやすい部分です。
自社の出荷・在庫拠点と請求の単位は、基幹や会計との連携の範囲に表れやすい部分です。
この区別があると、見積もりの金額を見たときに、どの拠点の要件がどの費用に化けているのかを追えるようになります。

▼ 図の内容を文字で読む

• 取引先の拠点（支店・工場などの納品先）
  • 納品先・価格・支払条件を拠点単位で持てるか（製品の標準仕様）
  • 料金区分の取引先件数にどう数えるか
• 自社の出荷拠点・在庫拠点
  • 拠点別在庫の表示と出荷拠点の指定
  • 基幹・在庫管理との連携の範囲
• 請求・与信の単位
  • 請求先と支払条件の持ち方
  • 請求・会計の処理へ渡す受注データの項目

公開料金で見る初期費用の出方：課金の軸は拠点数ではなかった

初期費用10万円＋月額8.8万円のプランで上限になる項目

実際の公開料金で、初期費用が何によって決まっているのかを見てみます。
EC-Rider Primoのクイックビジネスプランは、初期費用100,000円（税抜）と月額88,000円（税抜）が基本費用です²。
このプランで使える範囲は、商品30,000SKU、取引先10,000件、ユーザー5名と定められています²。
オプション機能と決済代行は別途費用で、支払いはクレジットカード決済のみとされています²。
SKUは、色やサイズまで区別した商品の最小単位のことです。

ここで料金の区分になっているのは、商品の数、取引先の数、使う人の数の三つで、拠点の数は区分に入っていません。
多拠点の会社が気にすべきなのは、自社の拠点構成をこの三つのどれにどう数えるかです。
たとえば、取引先の支店をそれぞれ別の取引先として登録する運用にすると、取引先の件数は支店の数だけ増えます。
一方で、1社の中に複数の納品先を持たせる形で登録できるなら、件数は会社の数のままです。
どちらの登録方法になるかは、製品の仕様と運用の決め方によります。
見積もりの段階で、納品先を取引先1件として数えるのかを確かめておく意味はここにあります。

ユーザー数も同じ考え方で見ます。
拠点ごとに受注を確認する担当者を置く場合、上限の「ユーザー」が誰を指すかによって、プランが足りるかどうかが変わります。
自社の管理画面を使う担当者を指すのか、ほかの利用者も含むのかという点です。
会社によっては、取引先の件数よりもユーザーの人数の方が先に上限に近づきます。
取引先10,000件という数字だけを見て余裕があると判断せず、区分ごとに自社の数を当てはめてみると、どこが窮屈になるかが分かります。

初期費用0円のサービスと、その前提の違い

初期費用が0円のサービスもあります。
卸売向けの受注サービスであるCORECは、受注する側（供給側）の初期費用を0円としています³。
月額は無料プランと、2,980円（税別）のビジネスプランから選ぶ形です³。
ビジネスプランでは、担当者を何名でも追加できるとされています³。

数字だけを並べると、0円と10万円の差に目が行きます。
ただ、CORECの料金は、卸売向けの受注サービスを受注する側が使うときのものです。
自社専用のBtoB ECサイトを構築して取引先に使ってもらう形とは前提が異なります。
そのため、初期費用の差をそのまま安い・高いの比較にはできません。
比べる前に、自社が求めているのが専用の注文サイトなのか、受注の受け口なのかを決めておく必要があります。

多拠点の観点で見ると、担当者を人数の制限なく追加できる点は、拠点ごとに担当者を置く会社にとって数え方の不安が一つ減る条件です。
一方、取引先の複数の納品先や自社の複数倉庫をどう扱えるかは、料金とは別に仕様として確かめる必要が残ります。
初期費用0円という条件と、多拠点の要件を満たすかどうかは、別の軸の話です。

拠点数の課金が見当たらないことの読み方

ここまでの二つの料金ページには、拠点の数に応じて初期費用や月額が増えるという記載はありません。
ただし、これは「多拠点でも費用は変わらない」という意味ではありません。
拠点が増えたことによる費用は、料金表の別の場所に表れます。

一つは、前の項で見た料金区分の数え方です。
納品先を取引先として数えれば取引先件数に響き、拠点の担当者を数えればユーザー数に響きます。
もう一つは、オプションと個別対応です。
受発注システムの費用目安を示した竹田印刷の解説は、SaaSであってもオプションの追加や独自のカスタマイズには別途費用がかかるとしています¹。
拠点ごとの価格、複数の納品先、拠点別の在庫といった要件が標準機能に入っていなければ、この「別途」の部分に入ります。

また、ここで見た料金は、それぞれの製品・プラン・時点の価格です。
2社の金額を平均して相場とみなすことはできません。
片方の上限をもう片方に当てはめることもできません。
見積もりを比べるときに使えるのは、金額そのものよりも「何が区分になっていて、何が別途なのか」という構造の方です。
この構造を押さえておくと、次に見る拠点の仕様の違いが、どの費用に結び付くのかを追いやすくなります。

▼ 図の内容を文字で読む

• 取引先の件数
  • 支店を別の取引先として登録すると、支店の数だけ件数が増える
  • 1社の中に複数の納品先を持たせられれば、件数は会社の数のまま
• ユーザーの人数
  • 拠点ごとに受注の担当者を置くと人数が増える
  • 上限の「ユーザー」が誰を指すかでプランが足りるか変わる
• オプション・個別対応の別途費用
  • 拠点ごとの価格・複数の納品先・拠点別在庫が標準機能に入っていない場合

拠点を管理する仕様は製品で違う：納品先・請求先・拠点別在庫の確認方法

拠点ごとに価格・支払条件を持つ設計の例

取引先の拠点をシステムがどう持つかは、製品ごとに設計が違います。
一つの例として、Shopifyのヘルプは、会社を1つ以上の拠点（ロケーション）をまとめる親組織と位置付けています⁴。
拠点は、B2B取引で販売する相手先の単位として扱われます⁴。
拠点ごとに、税ID、税免除、配送先住所、請求先住所、カタログによる価格、支払条件、連絡先を設定できます⁴。

注文の場面では、複数の拠点にアクセスできる購入者が、ログイン時に購入する拠点を選びます⁴。
選んだ拠点の価格・支払条件・チェックアウトが、その注文に適用されます⁴。
同社ヘルプに記載の上限は、1社あたり拠点10,000件・顧客10,000人、1拠点あたりカタログ25件・顧客50人です⁴。
会社の数には制限がないとされています⁴。
この仕様は同社のB2B機能に対応するプランの範囲のもので、他の製品にそのまま当てはまるものではありません。

この例から分かるのは、「納品先を複数登録できるか」という問いが、実は二つの問いに分かれることです。
一つは、納品先の住所を複数持てるかという問いです。
もう一つは、納品先ごとに価格や支払条件、請求先を変えられるかという問いです。
前者だけなら住所の登録で済みます。
後者が必要なら、拠点が取引条件を持つ単位として設計されているかどうかが分かれ目になります。
自社の取引先で、支店ごとに掛け率や締め日が違うかどうかを先に確かめておくと、どちらの問いを提供元に投げればよいかがはっきりします。

比べると、EC-Rider Primoの紹介ページでは、商品SKUごと・法人ごとの販売価格設定が標準機能として示されています²。
法人単位で価格を変えられることは、このページから確認できます。
同じ法人の中の拠点ごとに価格や納品先を分ける扱いについては、このページには記載がありません。
記載がないことは機能がないことを意味しないため、拠点単位の価格や複数納品先が必要なら、見積もり依頼の質問として明示しておきます。
なお、同じページにある「マルチサイト」は、複数のECサイトを1つの管理画面で運用する機能の説明です²。
言葉は似ていますが、取引先や自社の拠点を管理する話とは別のものです。

拠点別在庫・出荷拠点は個別に確かめる項目

自社の側に複数の倉庫や出荷拠点がある場合は、取引先の拠点とは別の確認が要ります。
ここで見た公開ページからは、拠点別の在庫表示や出荷拠点の指定がどの製品で標準なのかは読み取れません。
そのため、この部分は料金表から推し量るのではなく、自社の運用を書き出して提供元に質問する項目になります。

書き出す内容は、注文の流れに沿って考えると漏れにくくなります。
まず、取引先が注文画面を開いたときに、在庫を拠点別に見せたいのか、全拠点の合計でよいのかを決めます。
次に、注文が入ったときに、どの倉庫から出すかをシステムが決めるのか、受注担当者が決めるのかを決めます。
最後に、出荷が決まったときに、その指示を誰がどのシステムに伝えるのかを決めます。
この三つの場面で、ECの中で完結させたいことと、基幹や在庫の仕組みに任せることを分けておきます。
そうすると、見積もりで「標準」「オプション」「個別開発」のどれになるかを聞きやすくなります。

在庫を基幹システムや在庫管理システムで持っている会社では、拠点別在庫の多くはEC単体の機能ではなく、連携の問題になります。
どの項目を受け渡し、どこから費用が別になるのかは、後の連携の節で扱います。
その前に、拠点の要件が標準で収まらなかったときに導入の形そのものを変えるかどうか、という判断を見ておきます。

▼ 図の内容を文字で読む

1. 取引先が注文画面を開いたとき
   • 在庫を拠点別に見せるか、全拠点の合計でよいか
2. 注文が入ったとき
   • どの倉庫から出すかをシステムが決めるか、受注担当者が決めるか
3. 出荷が決まったとき
   • 指示を誰がどのシステムに伝えるか
   • ECで完結させる部分と、基幹や在庫の仕組みに任せる部分を分ける

SaaS・ハーフスクラッチ・フルスクラッチで初期費用と対応条件はどう違うか

3形態の初期費用・月額の目安表

拠点まわりの要件が製品の標準機能で収まらないと分かったとき、導入の形を変えるという選択肢が出てきます。
竹田印刷の解説は、受発注システムの導入形態を三つに分けて、初期費用と月額の目安を示しています¹。
SaaSは、提供元が用意した仕組みを契約して使う形です。
ハーフスクラッチは、既存の仕組みを土台に必要な部分を開発する形です。
フルスクラッチは、一から開発する形です。

表は同社調べの目安で、対象とした企業の規模や業種は示されていません¹。
同じ解説の本文ではSaaSについて「導入までに50万円程度、毎月の運用に20万円程度かかる想定」とも書かれており、表の幅とは揃っていません¹。
そのため、この数字を自社の予算の根拠にすることはできません。
読み取れるのは、形態が変わると初期費用の桁が変わるという大きさの違いまでです。

前の節で見たEC-Rider Primoの初期費用10万円（税抜）は、この表のSaaSの幅よりも低い位置にあります²。
これは、目安が個々の製品の価格を代表しないことを示す一例です。
どちらが正しいという話ではありません。
稟議では、形態ごとの目安と候補製品の実際の見積もりを混ぜずに示すと、どの数字が何に基づくのかを聞かれたときに答えやすくなります。

拠点要件が標準で足りない場合の分かれ目

形態を選ぶ分かれ目は、拠点まわりの要件のうち、どれだけが個別開発に回るかです。
竹田印刷の解説は、ハーフスクラッチは追加する機能が多いほど費用が高くなる可能性があるとしています¹。
SaaSでも、オプションやカスタマイズには別途の費用がかかります¹。
どの形態を選んでも、拠点の要件を標準の外で実現しようとするほど費用が積み上がるという構造は共通しています。

判断の材料をそろえるには、拠点に関する要件を一つずつ書き出し、候補ごとに回答してもらう方法があります。
回答の欄は「標準で使える」「オプションで対応」「個別開発が必要」の三つです。
たとえば、取引先の支店ごとの価格、複数の納品先、本社一括の請求、倉庫別の在庫引当という四つの要件があったとします。
SaaSの候補で四つとも標準かオプションに収まるなら、形態を変える理由は薄くなります。
反対に、倉庫別の在庫引当のように業務の中核にある要件が個別開発になる場合もあります。
その開発がSaaSの上では難しいと回答されたなら、ハーフスクラッチの見積もりも並べて比べる意味が出てきます。

ここで気を付けたいのは、要件を減らす選択肢も同じ比較の中に載せておくことです。
倉庫の割り当てを受注担当者が決める運用で当面足りるなら、その要件は個別開発から外せます。
外した場合に人の手に何が残るのかと、開発費を払って何がなくなるのかを並べて見ると、形態を上げる理由が費用に見合うかを判断できます。
形態を上げる前に、その要件がシステムで持つべきものか、運用で持てるものかを社内で一度確かめておくと、比較の前提がぶれません。

▼ 図の内容を文字で読む

• 標準で使える
  • SaaSの候補で要件が収まるなら、形態を変える理由は薄い
• オプションで対応
  • オプションの追加には別途の費用がかかる
• 個別開発が必要
  • 倉庫別の在庫引当のように業務の中核にある要件で、SaaSでは難しいなら、ハーフスクラッチの見積もりも並べて比べる
  • 運用で持てる要件なら、要件から外して費用を抑える

基幹・在庫・会計との連携は、拠点追加時の費用がどこで膨らむか

標準CSV連携の範囲

基幹システムとの連携は、多拠点の会社で費用の見通しが立ちにくい部分です。
CSV連携とは、ECで受けた注文などのデータを表形式のファイルに書き出し、基幹システムに取り込むやり方のことです。
逆に、基幹の商品や価格のデータをファイルでECに取り込む使い方もあります。
EC-Rider Primoでは、基幹連携はCSVデータ連携が標準とされています²。

拠点が一つなら、受注データに入れる項目は取引先・商品・数量・納期で足りることもあります。
拠点が増えると、受注データに持たせる項目が増えると考えられます。
どの納品先に届けるのか、どの倉庫から出すのか、どこに請求するのかを、基幹側が読める形で持たせる必要が出てくるためです。
受注担当者が電話やFAXの注文を見ながら基幹に打ち込んでいた作業のうち、CSVで置き換えられるのは、ファイルの列として受け渡せる項目の分です。

たとえば、ECから出したCSVに納品先は入っていても、出荷倉庫の列がなかったとします。
この場合、取引先や商品を打ち直す転記はなくなりますが、取り込んだ後に担当者が倉庫を割り当てる作業が残ります。
倉庫の判断と、割り当てが正しいかの確認は人の手に残ります。
標準のCSVで足りるかどうかは、ECが出せる列と基幹が受け取れる列を突き合わせて初めて判断できます。
見積もり前に、基幹側の取込レイアウト（受け取れる項目の一覧）を用意しておくと、この突き合わせを提供元と同じ資料で進められます。

標準を超える連携がオプション扱いになる点

標準のCSVで受け渡せない項目が出たとき、その部分は追加の費用になります。
EC-Rider Primoでは、標準のCSV連携を超えるシステム連携は、カスタマイズオプションで対応可能とされています²。
竹田印刷の解説も、オプションの追加や独自のカスタマイズには別途費用がかかるとしています¹。
金額は、受け渡す項目の数や基幹側の仕様によって変わります。
そのため、公開されている料金から連携の費用を見積もることはできません。

拠点の追加で費用が膨らみやすいのは、拠点の数そのものより、拠点ごとに受け渡しのルールが違う場合だと考えられます。
たとえば、倉庫Aは自社の在庫管理システムで、倉庫Bは委託先の別の仕組みで在庫を持っているとします。
この場合は連携先が二つになり、それぞれに受け渡しの形を決めることになります。
反対に、拠点が増えても受注データの列に拠点のコードが一つ増えるだけで済むなら、標準のCSVの範囲に収まる可能性があります。

見積もりでは、連携を一括りの「基幹連携費」として受け取らないことが大切です。
標準CSVで受け渡す範囲と、カスタマイズや個別開発で実現する範囲を分けて書いてもらうと、どの拠点要件がいくらに当たるのかが読めるようになります。
データを受け渡す頻度も要件として一緒に伝えます。
1日数回のファイル受け渡しで足りるのか、注文のたびに反映したいのかを書いておくと、提供元の回答の前提がそろいます。

一斉導入か一部拠点からか：見積もり依頼で前提を揃えるチェックリスト

見積もり依頼で揃える前提

ここまでの確認事項を、複数の提供元に同じ前提で伝えられる形にまとめます。
前提が揃っていれば、総額の差が何の違いから来ているのかを読み取れます。
冒頭の例のように「拠点が20か所」とだけ伝えた依頼との違いは、提供元が解釈する余地を残さないことです。

揃える前提のうち、数字で伝えるものは、取引先の件数、商品のSKU数、システムを使う担当者の人数、移行するデータの量です。
取引先の件数は、会社の数と、納品先・請求先の数を分けて書いておきます。
料金の区分が取引先件数で決まる製品では、どちらで数えるかによってプランが変わりうるためです。
分けて書いておけば、提供元の側で自社製品の数え方に当てはめて回答できます。

言葉で伝えるものは、拠点の定義と、拠点ごとに変わる取引条件、連携の範囲です。
先に分けた三つの意味のうち、自社に当てはまるものと、その中身を書きます。
そのうえで、各要件が標準・オプション・個別開発のどれに当たるかを回答欄として設けます。
オプションを追加したときや、上限を超えたときの費用の扱いも、書面で答えてもらいます。
口頭の説明だけだと、後から拠点を追加したときの費用が前提に入っていたのかを確かめられないためです。

無料トライアルや段階導入で確かめること

見積もりの前提を固めるには、実物を触って確かめる方法もあります。
EC-Rider Primoには0円・30日の無料トライアルがあり、商品500SKU、取引先50件、ユーザー5名の範囲で試せます²。
本契約の際には、トライアルで登録したデータを引き継げるとされています²。

30日は長くないため、試す内容を先に決めておく方が使いやすくなります。
多拠点の確認で試したいのは、たとえば次のような点です。
一つの取引先に複数の納品先を持たせたいときに、どう登録することになるか。
法人ごとの価格設定が、自社の掛け率の決め方に合うか。
出力されるCSVの列が、基幹の取込レイアウトと噛み合うか。
取引先50件の範囲で、支店の多い取引先を数社選んで登録してみると、取引先件数の数え方の問題も具体的に見えてきます。

段階導入は、一部の拠点や一部の取引先で運用を始め、要件の漏れを確かめてから広げる進め方です。
全拠点を一度に移すと、拠点ごとの例外的な取引条件が稼働後に見つかったとき、すべての拠点で同時に対応が必要になります。
先に一部で動かせば、例外を見つけた時点で、その要件を標準・オプション・個別開発のどれで扱うかを判断し直す余地が残ります。

ただし、段階導入で費用の総額が下がるとは限りません。
後から拠点や取引先を追加するときに、上限の区分を超えるか、追加の設定や連携に費用がかかるかは、公開されている情報からは分かりません。
段階導入を選ぶなら、拡大する時点の条件まで見積もりに含めてもらうことが前提になります。

稟議で説明するときの整理

費用がデジタル化の課題として挙がりやすいことは、調査にも表れています。
東京商工会議所の調査では、デジタルシフト・DXの課題として「コスト負担」を挙げる中小企業が31.9%で最も多くなりました⁵。
調査は主に東京23区内の中小企業を対象に2024年10〜11月に行われ、回答は1,218社です⁵。
BtoB ECに限らず、DX全般の課題を尋ねたものです。

多拠点のBtoB ECで総額が一つの数字に定まらないときは、無理に一つにまとめるより、費用を確定の度合いで分けて示す方が説明しやすくなります。
一つ目は、公開料金で決まっている基本の初期費用と月額です。
二つ目は、オプション、決済代行、上限を超えたときの費用など、条件次第で加わるものです。
三つ目は、標準を超える連携、拠点要件の個別開発、データ移行など、要件が固まるまで金額が決まらないものです。

このように分けると、稟議で「なぜ総額が確定しないのか」と聞かれたときに答えられます。
拠点の要件のうちこの部分が回答待ちだから、という形で、確定していない理由とそれが決まる条件を示せるためです。
決裁する側にとっても、どの要件を運用に回せば三つ目の費用を減らせるのかを検討する材料になります。
総額の数字を早く出すことより、数字が動く場所を先に見せることが、多拠点の見積もりを社内で扱うときの要になります。

自社の拠点の持ち方が料金区分のどれに数えられ、どこから標準の外に出るかは、製品の仕様を知る提供元でなければ答えにくいためです。

取引先・納品先・自社拠点の構成を伝えると、法人ごとの価格設定や標準のCSV連携で扱える範囲と、カスタマイズオプションになる範囲の切り分けを確かめられます。無料相談で要件を整理する

見積もり依頼書に入れる項目

拠点の定義から件数、取引条件、連携、移行、拡大時の扱いへと、見積もりの前提が決まっていく順に並べています。

• 自社の「多拠点」の意味（取引先の納品先・自社の出荷や在庫拠点・請求や与信の単位）と、それぞれの数

• 取引先の件数（会社の数と、納品先・請求先の数を分けて記載）

• 商品のSKU数と、システムを使う担当者の人数

• 拠点ごとに変わる取引条件（価格・支払条件・締め日・請求先）

• 各要件が標準・オプション・個別開発のどれに当たるか（回答欄を設ける）

• 基幹・在庫・会計との連携範囲（標準CSVで受け渡す項目と、それを超える項目）と受け渡しの頻度

• 移行するデータの量（取引先・商品・価格など）

• オプション追加、上限超過、後から拠点や取引先を増やすときの費用の扱い（書面で回答）

拠点の定義や連携範囲を見直したときは、全項目を同じ前提で依頼し直します。

要点の整理

軸	基準
拠点の定義	取引先の納品先、自社の出荷・在庫拠点、請求・与信の単位のどれに当たるか（複数可）を先に決める
料金区分	公開料金の区分（SKU・取引先・ユーザーなど）に、自社の拠点構成をどう数えるか
拠点の仕様	納品先の住所を追加するだけか、拠点ごとに価格・支払条件・請求先を持つ必要があるか
導入形態	拠点要件のうち、個別開発に回る要件が業務の中核にあるか
連携	ECが出せる列と基幹が受け取れる列が、標準CSVで突き合うか
段階導入	拡大時の上限・追加費用の扱いを、書面の見積もりに含めているか

依頼書の項目を揃えても、自社の基幹の取込レイアウトに標準のCSVが合うかや、トライアルで何を試すかは、実際のデータを見ないと決めにくいためです。 30日の無料トライアルで試す内容や、上限区分（SKU・取引先・ユーザー）での数え方を相談しながら、見積もりの前提を固められます。

よくある質問

多拠点だと初期費用は拠点数に比例して増えるのか。

確認できた料金ページには、拠点の数に応じた料金の記載はありません²³。
たとえばEC-Rider Primoの区分は、商品SKU数・取引先件数・ユーザー数です²。
ただし、納品先を別の取引先として登録すれば取引先件数に響き、拠点ごとの担当者はユーザー数に響きます。
拠点管理が標準機能に入っていなければ、オプションや個別開発の費用にもなります。
拠点数で増えないから費用が変わらない、とは言えません。

取引先の納品先を複数登録できるかは、どこで確認すればよいか。

まず製品のヘルプや仕様書で、二つの点を分けて確かめます。
納品先の住所を複数持てるかと、納品先ごとに価格や支払条件、請求先を変えられるかです。
Shopifyのように、拠点ごとに配送先・請求先・価格・支払条件を設定できると仕様に明記している製品もあります⁴。
公開ページに記載がない場合も、機能がないとは限りません。
見積もり依頼書に質問として書き、標準・オプション・個別開発のどれに当たるかを回答してもらいます。

初期費用0円のサービスと10万円のサービスは、何が違うのか。

金額の差より、前提の違いを見ます。
COREC供給側の初期費用0円は、卸売向けの受注サービスを受注する側が使うときの料金です³。
EC-Rider Primoの初期費用10万円（税抜）は、SKU・取引先・ユーザーの上限があるクイックビジネスプランの料金です²。
自社専用のBtoB ECを構築するのか、受注サービスを使うのかで比較の土台が変わります。
初期費用だけでなく、月額、上限、オプション、多拠点の要件を満たせるかを並べて判断します。

基幹システムと連携すると、初期費用はどの程度上がるのか。

連携費用の水準は、公開されている料金からは示せません。
分かれ目は、標準のCSV連携で足りるかどうかです。
EC-Rider Primoでは、標準のCSV連携を超える連携はカスタマイズオプションとされています²。
ECが出せる列と基幹が受け取れる列を突き合わせると、どの項目が標準の外に出るかが見えます。
見積もりでは連携費を一括りにせず、標準の範囲と追加の範囲を分けて書いてもらいます。

一部の拠点だけで先に始めて、あとから拠点を増やすことはできるか。

一部の拠点や取引先から始め、要件の漏れを確かめてから広げる進め方は選べます。
ただし、後から追加するときに上限区分を超えるか、追加の設定や連携に費用がかかるかは、製品と契約条件によります。
拡大する時点の条件まで見積もりに含め、書面で回答してもらってから決めます。
EC-Rider Primoの無料トライアル（30日・取引先50件など）のデータは本契約時に引き継げるため²、一部の取引先での試行に使えます。

SaaSで足りない場合、スクラッチ開発に切り替える判断はどこでするか。

拠点まわりの要件を一つずつ書き出し、候補のSaaSで標準・オプション・個別開発のどれに当たるかを回答してもらった結果で判断します。
業務の中核にある要件が個別開発になり、SaaSの上では実現が難しいとされた場合に、ハーフスクラッチなどの見積もりを並べる意味が出てきます。
竹田印刷調べの目安では、形態が変わると初期費用の桁が変わります¹。
そのため、その要件を運用で代替できないかも同時に検討します。

1. 1　出典：竹田印刷株式会社（TS-BASE運営）「Webの受発注システムの選び方とコストの目安」（2026年）
2. 2　出典：株式会社フライトソリューションズ「EC-Rider Primo サービス紹介ページ・料金プラン条件」（2026年）
3. 3　出典：ラクーンホールディングス株式会社「COREC（コレック）卸売向けBtoBクラウド受注システム 供給側の料金」（2026年）
4. 4　出典：Shopify「ヘルプセンター B2B：会社とロケーション」（2026年閲覧）
5. 5　出典：東京商工会議所「中小企業のデジタルシフト・DX実態調査 集計結果」（2025年）
6. 6　出典：総務省「令和7年版 情報通信白書」（2025年）