この記事でわかること
「取引先ごとに卸値が違う」「数量に応じて単価を変えたい」「契約価格とキャンペーン価格が併存する」——BtoB-ECでは、価格が一律でないことがあります。EC-CUBEでこうした複雑な価格に対応できるのか、対応するなら何を設計すればよいのか。この記事では、顧客別価格・数量別価格・契約価格などを、EC上でどう設計するかを解説します。
この記事を読むと分かること
- BtoBで価格が複雑になる要因
- EC-CUBEで複雑な価格を実装するときの考え方（標準機能・プラグイン・個別開発の区別）
- 価格設計で整理しておきたいポイント
BtoB-ECのプラットフォーム選び全体については、なぜBtoB-ECにEC-CUBEが向いているのかもあわせてご覧ください。
BtoBで価格が複雑になる要因
BtoB-ECでは、次のような要因で、価格が一律でなくなることがあります。
- 顧客別単価（取引先ごとに異なる価格）
- 数量別価格（数量に応じた単価。数量階段制とも呼ばれます）
- 契約価格
- 期間限定のキャンペーン価格
- 商品グループ別の条件
- 与信条件との連動
BtoBでは、取引先との契約条件や取引量などに応じて価格が変わるケースがあり、一般消費者向けEC（BtoC）とは異なる価格設計が必要になることがあります。なお、BtoCでも、会員価格やセール価格など複数の価格が存在することはありますが、BtoBでは取引先ごとの個別条件が加わる点が特徴です。
EC-CUBEで複雑な価格を実装するときの考え方
EC-CUBEでは、標準機能だけで対応できない価格ルールでも、プラグインや個別カスタマイズによって実装できる場合があります。ここで大切なのは、標準機能でできること、プラグインで対応すること、個別開発が必要なことを、区別して考えることです。
価格ロジックを業務に合わせて設計する
EC-CUBEはオープンソースのため、価格ロジックを業務に合わせて設計できます。顧客属性別の価格、契約単価、数量別価格、条件による分岐などを、要件に応じて実装できます。価格は、単純な「フィールド（項目）」ではなく、「どの条件でどの価格を適用するか」という「ロジック」として捉えることがポイントです。
顧客グループ単位での価格管理（設計例）
顧客別価格を実装する場合の設計例として、次のような構成が考えられます。これはEC-CUBEの標準マスタではなく、要件に応じて設計・追加する例です。
- 顧客グループを管理する仕組み
- 価格を管理するテーブル
- 商品と価格の紐付けの設計
顧客単位、またはグループ単位で価格を持たせることで、BtoBの価格体系に対応できます。どのような単位で価格を管理するかは、取引先の数や、価格ルールの内容によって変わります。データ構造の考え方は、DB構造・Entity設計の解説もご覧ください。
数量別価格（数量階段制）の実装
数量に応じて単価が変わる価格（例：1〜9個は1,000円、10〜49個は900円、50個以上は800円）は、数量の条件を持つ価格の仕組みを設計することで対応できます。数量別価格は、BtoB-ECで採用されることがある価格設計の一つです。
複数価格の優先順位の設計
BtoBでは、通常価格・契約価格・キャンペーン価格など、複数の価格が併存することがあります。このとき重要なのが、どの価格を優先して適用するか、という優先順位のロジックの整理です。たとえば「契約価格 ＞ 数量別価格 ＞ キャンペーン価格」のように、適用ルールを明確にしておく必要があります。ここが整理されていないと、意図しない価格が表示されるなどの問題につながることがあります。
価格設計で整理しておきたいポイント
価格設計は、技術的な実装の前に、業務の整理が必要になる部分です。次のような点を整理しておくことが役立ちます。
- 価格適用の優先順位
- 適用期間の管理
- 基幹システムとの役割分担（どちらで価格を管理するか）
- 管理画面での運用のしやすさ
- 将来の条件追加への対応
価格設計は、技術実装というより、業務設計に近い作業です。何を、どの条件で、どう適用するかを整理することが、出発点になります。
基幹システム連携との整合
価格が複雑な場合、価格データの正本（マスタ）をどこに置くかが論点になります。基幹側で価格を管理するのか、EC側で持つのか、双方向で連携するのか——ここが整理されていないと、価格の不整合が生じることがあります。基幹連携の設計については、基幹・在庫システムを連携する方法で解説しています。
価格設計で注意したいこと
複雑な価格を設計するとき、次のような点に注意が必要です。
- プラグインの積み上げ：複数の価格系プラグインを組み合わせると、ロジックが競合することがあります。プラグインの設計はプラグイン設計の記事もご覧ください。
- 現行業務のそのままの再現：Excelを前提とした価格体系をそのまま再現すると、構造が複雑になることがあります。EC化を機に、ルールを整理することも検討できます。
- 将来の拡張を想定しない設計：顧客の増加や条件の追加を想定しておかないと、後から見直しが必要になることがあります。
EC-CUBEでの価格設計が向いているケース
次のような場合は、EC-CUBEの自由度を活かした価格設計が向いていることがあります。
- 顧客別価格など、標準機能に収まりにくい価格ルールがある
- 営業が都度見積もりを出している
- 基幹システムとの連携が必要
- 業界特有の価格ロジックがある
一方、価格が比較的単純な場合は、SaaS型のプラットフォームで対応できることもあります。価格ルールの複雑さや、必要な連携によって、適した選択肢が変わります。
BtoBの価格設計を、ご相談ください。
「この価格体系はEC化できるのか整理したい」「どこまで自動化できるか知りたい」といった段階からご相談いただけます。現在の価格ルールを伺ったうえで、EC上でどう設計できるかをご提案します。
よくある質問
EC-CUBEの標準機能で、顧客別価格は設定できますか？
EC-CUBEの標準機能には、会員（顧客）ごとに異なる価格を管理する仕組みは含まれていません。顧客別価格を実現する場合は、対応するプラグインを利用するか、価格の対応関係を管理する仕組みを個別に設計・開発することになります。どちらが適しているかは、取引先の数や、価格ルールの内容によって変わります。
数量別価格（数量階段制）は実装できますか？
実装できます。数量の条件（例：10個以上で単価を下げる）を持つ価格の仕組みを設計することで対応できます。ただし、これも標準機能そのままではなく、プラグインや個別カスタマイズによる実装になります。数量の区切りや、他の価格（契約価格など）との優先順位もあわせて整理することが大切です。
契約価格とキャンペーン価格が両方ある場合、どうなりますか？
どの価格を優先して適用するかを、あらかじめ設計しておく必要があります。たとえば「契約価格を優先する」「キャンペーン価格を優先する」など、適用のルールを明確にしておかないと、意図しない価格が表示されることがあります。複数の価格が併存する場合は、優先順位のロジックを整理することが大切です。
価格は、EC側と基幹システムのどちらで管理すべきですか？
要件によって変わります。基幹側で価格を管理してECに連携する方法、EC側で価格を持つ方法、双方向で連携する方法などが考えられます。どこを価格の正本（マスタ）にするかを決めておかないと、価格の不整合が生じることがあります。既存の基幹システムでの価格管理の状況を踏まえて、役割分担を整理することをおすすめします。
まとめ
EC-CUBEでは、標準機能だけでは対応できない複雑な価格ルールも、プラグインや個別カスタマイズによって実装できる場合があります。大切なのは、現在の価格体系をそのままECに再現することではなく、価格ルールを整理し、どの価格を、どの条件で適用するかを設計することです。価格ロジックの設計、優先順位の定義、基幹連携の整理、将来の拡張への備え——これらを事前に整理しておくことが、価格設計で確認すべき範囲を明確にするうえで重要です。
私たちサンクユーは、BtoB-ECの価格設計や、基幹システムとの連携に対応しています。「この価格体系はEC化できるか整理したい」「どこまで自動化できるか知りたい」といった段階から、ご相談いただけます。まずは、現在の価格ルールをお聞かせください。
投稿者プロフィール
- サンクユーのEC-CUBE担当。15年以上にわたりEC-CUBE開発に従事し、2系・3系・4系すべてに精通。難易度の高いカスタマイズや、他社構築サイトの改修・再設計も多数対応しています。
Javaでの業務システム開発を起点に、PHP・Perl・フロントエンド・CMSまで横断的に対応。基幹システム連携や業務フローを踏まえた設計を得意とし、複雑な要件にも柔軟に対応可能です。
ChatGPT CODEXを活用し、開発スピードと品質の両立を実現しています。
