「FAXと電話で受けている卸の注文を、そろそろWeb化したい」——製造業・メーカー・問屋から最も多く寄せられる相談です。しかしBtoBのEC化は、BtoCサイトを作るのとはまったく別の作業になります。BtoBで実装すべきは「見た目」ではなく「取引条件」だからです。取引先ごとに違う掛け率、締め請求、与信限度、ロット単位——これらをどう設計するかで、プロジェクトの成否と費用が決まります。本記事では、ShopifyでBtoB・卸売サイトを構築する際の要件、実現方法の選択肢、そしてShopifyを選ぶべきでないケースまでを実務ベースで整理します。
BtoB ECとは何か
この一文が、BtoB構築のすべてを規定します。BtoCサイトは価格が1つですが、BtoBサイトでは同じ商品に取引先の数だけ価格が存在し得ます。この構造をカートがどう扱えるかが、BtoB ECの技術的な中心論点です。
BtoB ECには3つの目的がある
目的①：受注業務の省人化
FAX・電話・メールで受けた注文を手作業で基幹システムへ転記する作業をなくす。BtoB EC化の投資対効果が最も明確に出る領域で、多くの案件はここが主目的です。転記ミスによる誤出荷の削減効果も含まれます。
目的②：取引先の利便性向上
24時間発注可能、在庫状況の即時確認、過去の発注履歴からの再注文。取引先の担当者の手間を減らすことが、取引継続の理由になります。営業が動かなくても発注が入る状態を作ります。
目的③：新規取引先の開拓
Webから卸取引の申し込みを受け付ける。従来は営業が足で開拓していた領域を、サイトで受動的に獲得する設計です。この目的がある場合、サイトの見せ方（BtoC的な要素）も必要になります。
この3つのうちどれが主目的かで、作るべきものが変わります。①が主目的なら既存取引先向けの受発注システムで十分ですが、③が入ると商品カタログの見せ方や申込フローの設計が必要になり、要件は一段複雑になります。最初にここを確定させてください。
用語解説
| 用語 | 意味 |
|---|---|
| 掛け率 | 小売価格に対する卸価格の比率。「掛け率60%」なら定価1万円の商品を6千円で卸す。取引先の規模や取引量で個別に設定されるのが一般的。 |
| 締め請求 | 都度決済ではなく、月末などに一定期間の取引をまとめて請求する方式。BtoB取引では標準的で、これが実装できないと商習慣に合わない。 |
| 与信限度額 | 取引先ごとに設定する未回収リスクの上限。この額を超える発注をシステム側で止める仕組みが必要になる場合がある。 |
| 最小発注単位（MOQ） | Minimum Order Quantity。「1ケース12個単位」「最低発注金額5万円以上」など。BtoBでは個数単位の販売を許さないケースが多い。 |
| 顧客タグ（Shopify） | 顧客に付与するラベル。BtoB実装では、このタグで取引先グループを分け、価格や表示を出し分ける設計がよく使われる。 |
| カタログ（Shopify） | 特定の顧客グループに、特定の商品と価格だけを見せる機能。上位プランで提供されるBtoB向けの中核機能。 |
| ドラフトオーダー | 店舗側が管理画面で作成する注文。見積書の発行や、電話で受けた注文の代理入力に使われる。 |
なぜBtoBのEC化は進まないのか（業界構造）
BtoC EC化はほぼ完了した一方、BtoBは今なおFAXが現役です。これには合理的な理由があります。
構造①：取引条件が属人化している
「A社は掛け率60%だが、大口のときは58%」「B社は昔からの付き合いで特別扱い」——こうした条件が営業担当の頭の中にしかない状態では、システムに落せません。EC化の前に条件の棚卸しが必要になります。
構造②：発注側が変化を望まない
取引先の担当者にとって、FAXは慣れた手段です。「Webにしたので今日から使ってください」で移行は進みません。発注側にメリットがある設計と、丁寧な移行支援がなければ、作っても使われません。
構造③：基幹システムとの連携が重い
受注データは最終的に基幹システムへ流れる必要があります。この連携部分が、BtoB EC構築で最も費用と期間を要する工程であり、多くのプロジェクトが躊躇する理由です。
構造④：BtoC向けカートでは実装が重い
取引先別価格、締め請求、与信——これらはBtoC前提のカートには存在しない概念です。無理に実装すると個別開発の塊になり、費用が跳ね上がります。ここが最大の落とし穴です。
逆に言えば、構造①（条件の棚卸し）と構造②（取引先の移行設計）は、システムではなく事業側の課題です。ここを制作会社任せにするプロジェクトは、ほぼ確実に停滞します。
BtoB ECに必要な要件一覧
BtoBサイトで検討すべき要件です。自社に必要なものだけを選び、不要なものは「対象外」と明記してください。全部を実装しようとすると、費用は青天井になります。
📋 価格・取引条件まわり
- 取引先別価格／同一商品に対し、取引先ごとに異なる価格を表示・適用する
- 掛け率設定／定価に対する率で設定するか、商品ごとに個別価格を持つか
- 数量割引／発注数に応じた段階的な価格変動（10個以上で5%引等）
- 最小発注単位・最低発注金額／ケース単位、ロット単位、金額下限
- 取引先別の取扱商品制限／A社には見せるがB社には見せない商品の制御
- 価格の非表示／ログイン前は価格を見せない（BtoBでは必須要件になることが多い）
📋 決済・請求まわり
- 掛け払い（請求書払い）／都度決済ではなく後払い。BtoBの標準的な支払い方法
- 締め請求／月末締め翌月末払いなど、取引先ごとに異なる支払サイクル
- 与信限度額の管理／限度額超過時の発注制御、アラート
- 請求書・納品書の発行／書式、送付方法（PDF・郵送・電子帳簿保存法対応）
- インボイス制度対応／適格請求書の要件を満たした書式
📋 アカウント・権限まわり
- 会員登録の審査制／申込を受けてから、審査を経て承認する運用フロー
- 1社複数アカウント／同じ取引先の複数担当者がそれぞれログインする
- 承認フロー／担当者が発注し、上長が承認してから確定する二段階発注
- 担当営業の紐付け／取引先ごとに自社の担当営業を表示する
📋 業務・連携まわり
- 基幹システム連携／受注データの連携方向、頻度、対象項目
- 在庫の即時反映／リアルタイムか、1日1回のバッチか
- 見積書の発行／Web上での見積依頼と回答フロー
- 再注文機能／過去の発注履歴からワンクリックで再発注
- CSV一括発注／大量品目をまとめて発注する取引先向け
- 代理注文／電話で受けた注文を、自社側で代理入力する
⚠️ 費用を跳ね上げる3つの要件
この一覧のうち、実務上とりわけ費用に効くのは①与信限度額の管理、②承認フロー（二段階発注）、③基幹システムとのリアルタイム連携の3つです。いずれも標準機能では対応できず、個別開発かそれに近い実装が必要になります。
逆に言えば、この3つが本当に必要かを最初に問い直すことが、最大のコスト削減策です。「与信は営業が目視で確認する」「承認は社内ルールで運用する」「基幹連携は1日1回のCSVで足りる」——この判断ができるだけで、費用は大きく変わります。要件を減らす判断も、設計の一部です。
ShopifyでBtoBを実現する3つの方法
Shopifyには、BtoB要件を実装する経路が複数あります。どれを選ぶかで費用が数倍変わるため、ここは必ず理解しておいてください。
| 方法 | 仕組み | 向いているケース | 注意点 |
|---|---|---|---|
| ① 顧客タグ＋テーマ実装 | 顧客にタグを付け、Liquidで価格や表示を出し分ける | 取引先グループが数種類、価格パターンが単純 | 取引先ごとの個別価格には向かない。グループ数が増えると破綻する。 |
| ② BtoB向けアプリ | 卸売機能を提供するアプリを導入する | 標準的なBtoB要件、開発費を抑えたい | 月額費用が継続発生。アプリ仕様の制約を受け、細かい要件に合わない場合がある。 |
| ③ 上位プランのBtoB機能 | Shopifyが提供するBtoB向け機能群（カタログ・会社アカウント等）を使う | 本格的な卸売、取引先数が多い | 上位プランの契約が前提。プラン料金が大きく上がる。 |
| ④ ストア分離 | BtoC用とBtoB用でストアを分け、在庫等を連携する | BtoCとBtoBの両方を本格運用する | ストアが2つになるため運用が二重化。ただし要件の衝突を避けられる。 |
選択の判断基準
実務では、次の順で判断していきます。
- 取引先ごとに価格が違うか、グループで括れるかグループで括れる（例：一次卖60%、二次卖70%、直販店80%）なら①か②で足ります。取引先ごとに完全に個別なら③以上が必要です。ここが最初の分岐点です。
- 掛け払い（請求書払い）が必須か必須なら、決済の仕組みを別途設計する必要があります。都度決済で運用できる取引先が多いなら、実装は大幅に軽くなります。取引先に確認する価値のある論点です。
- 取引先の数は何社か数十社なら運用でカバーできる部分が多く、数百社を超えると自動化しないと運用が破綻します。社数は実装方針を決める最も具体的な変数です。
- BtoCも同じサイトでやるか両方やるなら、ストア分離（④）を必ず検討リストに入れてください。1サイトで両立させる実装は、想像以上に複雑になります。
- 基幹システムとの連携はどこまで必要か受注データを流すだけか、在庫・価格マスタも同期するか。同期方向が双方向になると、難易度は跳ね上がります。
【独自視点】BtoB ECの本当の難所は、システムではなく「移行」である
ここが、他のBtoB EC記事があまり触れていない部分です。
私たちがBtoB案件で最も時間を使うのは、実装ではありません。取引先に実際に使ってもらうまでの移行設計です。そして、失敗するプロジェクトのほとんどは、システムではなくここで失敗しています。
「作ったのに使われない」が起きる理由
BtoB ECには、BtoCにはない構造的な難しさがあります。使うのは自社の顧客ではなく、取引先の担当者だという点です。
この人にとって、発注方法の変更は業務手順の変更を意味します。FAXなら手元の用紙に書いて送るだけだったものが、IDとパスワードを管理し、Webにログインし、画面操作を覚える作業に変わります。その人の業務は増えるのに、メリットは発注先である自社側にある——これがBtoB EC移行の本質的な非対称性です。
移行が進む設計
取引先側に明確な利点を用意する。在庫の即時確認、過去履歴からの再発注、24時間発注可能、Web発注限定の条件。「手間が減る」「便利になる」が実感できれば、移行は自然に進みます。
移行が止まる設計
自社の省人化だけを目的にする。「FAXは今月で終了します」と一方的に通知する。取引先にとっては手間が増えるだけなので、抵抗が起き、結果としてFAXが並存し続けます。
移行を成功させる3つの実務
実際に移行率が上がったプロジェクトに共通する打ち手は、次の3つです。
第一に、FAXを即座に止めないこと。並行期間を最低3か月は取ります。強制すると関係が悪化し、最悪の場合は取引そのものを失います。移行はお願いする立場だと理解してください。
第二に、上位10社を個別に支援すること。取引先が100社あっても、売上の大半は上位数十社が占めているはずです。全社に均等な案内メールを送るより、上位10社に営業が同行して初回発注を一緒に操作するほうが、移行率は圧倒的に高くなります。ここは人海戦術が正解です。
第三に、Web発注に具体的な利点を付けること。Web発注限定の価格条件、Web限定商品、優先出荷など。「便利だから使ってください」ではなく「Webのほうが得だから使う」状態を作れば、移行は加速します。この条件設計は、システムではなく経営判断の領域です。
「ECは戦術ではなく設計で決まる」
ボトルシップが一貫して掲げている考え方です。BtoB ECほど、この思想が試される領域はありません。
どのアプリを使うか、どのプランを契約するかは戦術です。しかし「どの取引条件をシステム化し、どれを運用で吸収するか」「取引先にどうやって移ってもらうか」という設計は、一度決めると後から変えるコストが極めて大きい。特に取引先との関係は、一度こじれると回復に年単位の時間がかかります。
だからこそ、BtoB EC構築では実装の前に、取引条件の棚卸しと移行計画を終わらせておくことが決定的に重要です。この2つが終わっているプロジェクトは、実装がスムーズに進み、稼働後の定着率も高くなります。逆にここを飛ばしたプロジェクトは、立派なシステムができあがった後で「誰も使わない」という最悪の結果を迎えます。
関連する支援メニュー
- ECサイト構築支援｜BtoB要件の設計から実装、基幹連携までを一貫して担当します。
- ECコンサルティング｜取引条件の棚卸し、移行計画の策定、投資対効果の試算を支援します。
- EC運用代行｜商品マスタの整備、受注対応、取引先サポートの実務を巻き取ります。
- 物流支援｜ケース単位出荷、混載、直送など卸売特有の物流要件を整理します。
構築の実務ステップ
取引条件の棚卸し
全取引先の掛け率、支払条件、最小ロット、特別対応を一覧化します。この作業は制作会社にはできません。営業担当へのヒアリングが必要で、たいてい「例外」が大量に出てきます。ここで例外を整理・統合できるかが、後の実装費用を左右します。
システム化する条件と、運用で吸収する条件の切り分け
棚卸しした条件を「システムで自動化する」「運用でカバーする」「この機会に廃止する」の3つに仕分けます。すべてをシステム化しようとすると費用が爆発します。年に数回しか発生しない例外は、運用で処理するほうが合理的です。
実現方法の選定と見積もり
顧客タグ方式、アプリ、上位プラン、ストア分離のどれを採るかを決めます。この時点で複数社に見積もりを依頼しますが、STEP 1と2の成果物を渡さないと、見積もりは意味のある数字になりません。
構築と基幹連携
実装と並行して、基幹システム側の改修も進みます。基幹側のベンダーとの調整期間を必ず見込んでください。ここを甘く見積もると、EC側が完成しても連携待ちで稼働できません。
上位取引先でのテスト運用
いきなり全社公開せず、協力的な取引先3〜5社で実際に運用します。この段階で必ず想定外の使われ方が見つかります。本番公開前に発見できれば、修正コストは桁違いに小さくなります。
段階的な移行と定着
上位取引先から順に移行を進めます。FAXは並行稼働させたまま、Web発注率を毎月測定します。移行率が上がらない取引先には、理由を個別にヒアリングしてください。多くの場合、システムの問題ではなく説明不足です。
投資対効果をどう試算するか
BtoB EC化は、BtoCと違って「売上を増やす」施策とは限りません。多くの案件で主効果はコスト削減とミス削減です。稟議を通すには、この効果を数字で示す必要があります。試算の型を示します。
| 効果区分 | 計算式 | 試算のコツ |
|---|---|---|
| 受注入力工数の削減 | 月間受注件数 × 1件あたり入力時間 × 時給 × Web移行率 | 1件5分でも月500件なら約42時間。最も確実に効く項目で、稟議の中心に据える。 |
| 問い合わせ対応の削減 | 月間の在庫・納期問い合わせ件数 × 対応時間 × 時給 | 在庫をWebで見せるだけで電話が減る。営業の時間が空く効果は見落とされやすい。 |
| 誤出荷・誤請求の削減 | 年間の転記ミス件数 × 1件あたり損失額 | 返品送料、再出荷、信用低下。金額化しにくいが実は大きい。過去のトラブル記録から拾う。 |
| 受注可能時間の拡大 | 営業時間外の発注件数 × 平均単価（増加分） | 24時間発注可能になることで拾える注文。控えめに見積もるのが無難。 |
| 新規取引先の獲得 | Web経由の新規申込数 × 成約率 × 年間取引額 | 目的③がある場合のみ。読みにくいので稟議の主軸にはしないほうが安全。 |
実務上、受注入力工数の削減だけで投資回収の説明がつくかどうかが、プロジェクトを進めるべきかの実質的な判断基準になります。月間受注件数が少ない事業者は、他の効果を積み上げても回収に時間がかかりすぎます。まず自社の月間受注件数と、1件あたりの処理時間を測ってください。この2つの数字がないまま構築に進むプロジェクトは、途中で必ず「本当にやる意味があるのか」という議論に戻ります。
⚠️ 試算に必ず入れるべき「隠れコスト」
効果だけでなく、稼働後に継続的に発生するコストも試算に入れてください。①アプリや上位プランの月額、②取引先からの操作問い合わせ対応（初期は想像以上に多い）、③商品マスタと価格マスタのメンテナンス工数、④基幹連携のエラー対応。
特に③は見落とされがちです。BtoBでは商品マスタの正確性が受発注の正確性に直結するため、誰がいつマスタを更新するかを運用設計に必ず含めてください。ここが曖昧なまま稼働すると、古い価格で発注が入り、請求時に揉めるという事故が起きます。マスタ更新の担当者と頻度は、要件定義書に明記すべき項目です。
Shopifyを選ぶべきでないケース
⚠️ 次に該当する場合、BtoB専用カートや業務システムを検討してください
①取引先ごとに完全に個別の価格体系がある／グループで括れず、数百社それぞれに個別価格を持つ場合、Shopifyでの管理は現実的ではありません。
②複雑な与信管理・債権管理が必要／与信限度、滞留債権の管理、督促フローまで含むなら、販売管理システムの領域です。
③受発注が商談を伴う／都度見積もり、仕様調整、納期交渉が発生する取引は、カートではなく商談管理の仕組みが適します。
④BtoCを一切やらない／完全にBtoB専業なら、Bカートなど専用カートのほうが標準機能で要件を満たせる可能性が高く、総額も抑えられます。
⑤取引先が10社以下／システム化の投資対効果が出ません。共有スプレッドシートや受注フォームで十分なケースがほとんどです。
よくある誤解
誤解①「BtoCサイトに卸機能を足せばいい」
BtoCとBtoBは求められる設計が根本的に違います。1サイトで両立させると、どちらも中途半端になりやすい。ストアを分けたほうが安く早いケースは珍しくありません。
誤解②「今の取引条件を全部そのまま再現する」
属人的な例外をすべてシステム化すると費用が爆発します。EC化は取引条件を整理・統一する好機です。この機会に例外を減らす交渉をすべきです。
誤解③「作れば取引先が使ってくれる」
最も多い失敗です。取引先にとっては手間が増えるだけという非対称性を理解し、利点の設計と個別支援をセットで用意しなければ、FAXは減りません。
誤解④「基幹連携は後から追加すればいい」
連携は後付けが最も高くつく領域です。データ構造の前提が変わるため、作り直しに近い作業になります。連携の有無は最初に決めてください。
誤解⑤「BtoBは見た目を作り込まなくていい」
新規取引先の獲得が目的に含まれるなら、商品の見せ方は重要です。ただし既存取引先向けの受発注が主目的なら、見た目より操作性と速度を優先すべきです。
誤解⑥「掛け払いは必ず必要」
商習慣としては標準ですが、全取引先に必須とは限りません。新規の小口取引先はカード決済で運用し、既存の大口のみ掛け払いという設計で、実装を軽くできる場合があります。
よくある質問（FAQ）
Q1. BtoBサイトの構築期間はどれくらいかかりますか？
要件の複雑さで大きく変わりますが、取引条件の棚卸しから稼働まで、標準的には6〜12か月を見込みます。実装そのものは2〜4か月程度でも、その前の条件整理に1〜2か月、基幹システム連携に2〜3か月、テスト運用と移行に3か月以上かかるためです。「3か月で作りたい」という要望は、たいてい条件整理か移行期間を省略することになり、稼働後の定着で失敗します。
Q2. 取引先ごとの価格は、何社くらいまでShopifyで管理できますか？
価格の持ち方によります。グループ単位（一次卸・二次卸など数種類）で括れるなら、社数が数百でも運用可能です。一方、取引先ごとに完全個別の価格を持つ場合は、社数が数十を超えたあたりから管理が現実的でなくなります。判断の目安は社数ではなく「価格パターンの数」です。まず自社の価格パターンが何種類あるかを数えてください。
Q3. FAX発注をゼロにできますか？
実務上、ゼロにできるケースは稀です。高齢の担当者や、社内システムの都合でWebが使えない取引先は一定数残ります。目標はゼロではなく、Web発注率を高めることに置いてください。上位取引先の移行が進めば、件数ベースでは残っていても、業務工数の削減効果は十分に得られます。残ったFAX分は代理注文機能で自社側が入力する運用にすれば、データは一元化できます。
Q4. 既存の基幹システムを変えずに導入できますか？
可能ですが、連携方式の選択肢が基幹側の仕様に制約されます。APIが用意されていればリアルタイム連携ができますが、CSVの取り込み・書き出ししか対応していない基幹システムも多く、その場合は1日数回のバッチ連携になります。バッチでも実務上は問題ないケースがほとんどですが、在庫の即時反映を取引先に約束する場合は成立しません。基幹側のベンダーに連携方式を早い段階で確認してください。
Q5. BtoCとBtoBを1つのShopifyストアで運用できますか？
技術的には可能ですが、要件が複雑になるほど推奨しにくくなります。ログイン状態で価格や商品の出し分けをする実装は、SEO・キャッシュ・カート挙動などで想定外の問題が起きやすい領域です。BtoBの取引先数が多い、条件が複雑、両方を本格運用するといった場合は、ストアを分けて在庫と受注データだけを連携する構成のほうが、構築費・運用負荷ともに軽くなることが多くあります。
まとめ
この記事の要点
- BtoB ECとは、取引先ごとに異なる価格・支払条件・発注単位を保持したままWeb上で受発注を完結させる仕組み。BtoCの「同一価格で不特定多数に売る」設計とは根本的に異なる。
- 目的は3つ——受注業務の省人化、取引先の利便性向上、新規開拓。どれが主目的かで作るべきものが変わるため、最初に確定させる。
- 費用を跳ね上げるのは、与信管理・承認フロー・リアルタイム基幹連携の3つ。この3つが本当に必要かを問い直すことが最大のコスト削減策。
- Shopifyでの実現方法は4つ——顧客タグ＋テーマ実装、BtoB向けアプリ、上位プランのBtoB機能、ストア分離。取引先ごとの価格がグループで括れるかが最初の分岐点。
- 本当の難所はシステムではなく移行。取引先の担当者にとっては手間が増えるだけという非対称性があるため、利点の設計と個別支援がなければFAXは減らない。
- 移行成功の3原則——FAXを即座に止めない、上位10社を個別に支援する、Web発注に具体的な利点を付ける。
- Shopifyを選ぶべきでないケースもある。完全個別価格、複雑な債権管理、商談を伴う取引、BtoB専業、取引先10社以下——いずれも別の選択肢を検討すべき。
100文字要約：BtoB ECとは取引先ごとに異なる条件を保持したままWeb受発注を完結させる仕組み。費用は与信・承認・基幹連携で決まり、成否は取引先の移行設計で決まる。実装より条件棚卸しが先。
