法人向けEC 価格階層の作り方:取引先別・グループ別・数量別の卸値を選ぶ判断軸

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

B2B EC-COLUMN

取引先ごとに違う卸値が、見積とExcelで回らなくなるとき

取引先が増えるたびに掛け率の一覧が枝分かれし、数量で変わる単価や一社だけの特別価格が、見積書とExcelに散らばっていく。
法人向けECに載せようとして、誰にどの卸値を見せるかで手が止まっていませんか。
価格階層は、会社別・取引先グループ別・数量別の3つの単位で組み立てます。
どれを主にするかは、掛け率がいくつのランクに収まるか、一社ごとの特例がどれだけあるかで決まります。
そのうえで卸値を見せる相手の絞り方と、改定をどこで反映するかを決めれば、出し分けを仕組みに載せられます。
価格が重なったときの表示の決まりは基盤ごとに違うため、自社の価格表で表示を試し、一部の取引先と商品から始めるのが現実的です。

見積・価格表の更新が追いつかない場面

たとえば、メーカーの営業管理担当が、代理店向けの標準掛け率、チェーン本部と結んだ個別の契約価格、ケース単位で注文したときの値引きを、一つのExcelで管理しているとします。
最初は列が数本でも、取引先が増えるたびに「この会社だけこの品番は別単価」という行が足され、見積書はその表を見ながら作ることになります。
表そのものは正しくても、どの行が最新か、誰がいつ直したかは表の外にしか残りません。

困るのは価格改定のときです。
基本価格を変えたら、掛け率の列を計算し直し、個別契約の行を一つずつ確かめ、取引先ごとに価格表を作り直して送ります。
注文がメールやFAXで届くと、受注担当は表から単価を引いて注文書の金額と照らし合わせます。
特例の行を一つ見落とせば標準の掛け率で請求してしまい、取引先からの問い合わせで初めて気づくことになります。

法人向けECに載せると、買い手の担当者がログインして自分向けの単価で注文するため、受注のたびに単価を引き直す作業は減らせます。
その代わり、これまで担当者が表を見ながら判断していた「この会社は特例」「この数量なら値引き」を、注文より前にルールとして設定しておく必要があります。
法人向けECの基盤には、個店・代理店・チェーン店といったバイヤーごとに卸価格や商流を設定する機能を説明しているものがあります⁵。
ただし、どんな単位で価格を持てるか、重なったときにどの価格が出るかは基盤ごとに違い、Excelの表をそのまま写せるとは限りません。

ECで先に決める4点(単位・価格・表示・更新)

出し分けをECに載せるときに決めることは、次の4点です。

<ul><li>誰に：価格を分ける単位(会社別・取引先グループ別・数量別)</li><li>いくらで：固定額で持つか、基本価格からの割引率で持つか</li><li>どう見せるか：卸値を見せる相手と、見せない相手</li><li>どう変えるか：改定や特例をどこで反映するか</li></ul>

この4点は前の決定が次の前提になっています。
単位が決まらないと、価格を固定額で持つか割引率で持つかが決められません。
見せる相手の制限は、どの単位で価格を割り当てたかによって設定の仕方が変わります。
改定の手間は、結局のところ価格を何件持っているかで決まります。
先に基盤の管理画面を触りながら考えると、画面にある項目に合わせて価格表を組み替えることになり、自社の取引条件のどこを曲げたのかが後から分からなくなります。

▼ 図の内容を文字で読む

1. 基本価格を変える
2. 掛け率の列を計算し直す
3. 個別契約の行を一つずつ確かめる
4. 取引先ごとに価格表を作り直して送る

価格階層の単位は3つ:顧客別・グループ別・数量別の違い

顧客(会社)別の契約価格

会社別の契約価格は、取引先一社ごとに商品の単価を持つ方式です。
法人単位で販売価格を管理する基盤の説明では、同じ商品Aを代理店Cへ1,100円、代理店Fへ1,200円で販売する設定が例として示されています⁵。
交渉の結果がそのまま価格になるので、個別契約の多い取引ではいちばん素直な表し方です。

Shopifyの法人向け機能では、商品の取り扱い可否と価格をカタログとしてまとめ、会社や拠点に割り当てます¹。
2026年時点の公式ヘルプでは、会社や拠点への直接割当ができ、カタログ数に上限がないのはPlusプランで、Basic・Grow・Advancedでは有効なカタログが3つまでとされています¹。
取引先ごとにカタログを作る運用を考えているなら、まずプランの条件が効いてきます。

Adobe Commerceの法人向け機能では、共有カタログで会社向けの価格を固定額か割引率で設定します³。
固定額を入れた場合は、基本価格と入力した値の低い方が最終的な価格になります³。
つまり契約価格は基本価格からの値下げとしては表せても、基本価格より高い単価を固定額で付けることはできません。

会社別は取引先ごとに正確な価格を出せる一方、持つ価格の件数は取引先数と商品数の掛け算で増えていきます。

取引先グループ別の掛け率

取引先グループ別の掛け率は、代理店ランクや業態ごとに取引先をまとめ、グループごとに基本価格からの掛け率を決める方式です。
Excelで「Aランクは基本価格の何掛け」と管理しているなら、この方式に近い形をすでに持っています。
一社ずつ価格を持たないので、掛け率を一つ変えれば同じグループの取引先すべてに反映できます。

基盤上では、Shopifyなら同じ条件の取引先に共通の価格を持つカタログを割り当てる、Adobe Commerceなら共有カタログに割引率を設定する、という考え方で表すことになります¹³。
Adobe Commerceの割引率は、基本価格からの比率として設定できるので、掛け率の発想とそのまま対応します³。
一方、Shopifyで有効なカタログが3つまでのプランを使う場合、ランクが3つを超える、あるいはランクとは別に特例用のカタログも持ちたいとなると、数が足りなくなります¹。

数量・ロット別の段階価格

数量・ロット別の段階価格は、一度に注文する数量に応じて単価を下げる方式です。
ケース単位で注文すれば単価が下がる、一定数以上はさらに下がる、といった条件をEC上の単価に直接反映します。

Shopifyでは、数量ルールで1注文あたりの購入数を制限でき、ボリューム価格で同じ注文の中の数量に応じた価格差を付けられます²。
Adobe Commerceでは、共有カタログ内の商品ごとに最小数量と、固定額か割引かを指定して段階価格を設定でき、段階は複数置けます³。

見落としやすいのは、どちらも「一回の注文の数量」で価格を変える仕組みとして説明されている点です。
年間の購入実績や過去の注文の累計で掛け率を変えている取引なら、数量別の段階価格ではなく、実績に応じて取引先のグループを見直す運用で表す方が自然です。
社内で「数量条件」と呼んでいるものが、注文ごとの数量なのか、累計の実績なのかを先に分けておくと、設定画面で迷わずに済みます。

基盤ごとの実現方法の比較表

3つの基盤の違いを、同じ商品の価格を会社別・数量別にどう変えられるか、という軸で並べると次のようになります。

表で判断が分かれるのは、価格が重なったときの扱いと、プランによる上限の2行です。
会社別の価格を持てること自体はどの基盤でも説明されていますが、グループの価格・特例・数量段階を同時に使ったときにどの価格が出るかは同じではありません。
上限は各提供者のプランの条件であり、契約内容や時期によって変わります。
個別に確認とした欄は、その機能がないという意味ではなく、参照した説明ページの範囲では扱われていないという意味なので、選定時に提供者へ直接たずねる項目になります。

▼ 図の内容を文字で読む

• 会社別
  • 取引先一社ごとに商品の単価を持つ
  • 件数は取引先数と商品数の掛け算で増える
• グループ別
  • 取引先をまとめ、基本価格からの掛け率を決める
  • 掛け率を一つ変えれば同じグループに反映できる
• 数量別
  • 一回の注文の数量に応じて単価を下げる
  • 年間の購入実績はグループの見直しで表す

自社の取引条件から方式を選ぶ

取引先数と例外の多さで選ぶ

方式を選ぶ材料は、手元の価格表にすでにあります。
取引先ごとの価格を「標準の掛け率のどれか」と「それ以外の例外」に分けてみると、自社の価格がどの単位で動いているかが見えてきます。

<ul><li>大半の取引先が少数の掛け率ランクに収まり、例外が一部の商品に限られる：グループ別を主にし、例外だけを会社別で持つ</li><li>取引先の数が少なく、一社ごとに条件がばらばら：会社別の契約価格を主にする</li><li>同じ取引先でも注文数量で単価が変わる：上のどちらかに、数量別の段階価格を重ねる</li></ul>

分かれ目になるのは、例外がどれだけ出るかです。
グループ別は管理が軽い反面、例外が増えるたびに「グループの価格」と「その会社だけの価格」が二重に存在することになります。
例外の行がランクで決まる行より目立つようになると、グループに分けた意味が薄れ、会社別で持つのと手間が変わらなくなります。
これは管理の件数と例外の出やすさから考えた選び方で、どの方式が効果的かを測ったものではありません。
同じ業種でも、商流や交渉の仕方によって向く方式は変わります。

方式を併用するときの優先順位

グループ別に会社別の特例や数量の段階を重ねると、同じ商品に複数の価格が当たる場面が出てきます。
このとき、どの価格が表示されるかは基盤によって決まり方が違います。

Shopifyでは、同じ商品に複数のカタログが価格を付けていると、最も安い価格が表示されます¹。
取引先にとって不利な価格が出ないという意味では分かりやすい決まりです。
ただ、ある会社だけ小口配送などの事情で標準より高い単価を設定していても、その会社に別の安いカタログも割り当たっていれば、高い方の特例は表示されません。
特例は「より安くする」方向には効きますが、「より高くする」方向には、カタログの割り当て方そのものを分けないと効かないということです。

Adobe Commerceでも、固定額の契約価格は基本価格と入力値の低い方になるため、基本価格を上回る特例は付けられません³。
一方で、会社別に設定した価格とグループ向けの価格が重なったときにどちらが優先されるかは、価格設定の公式ページには一般的な決まりとして書かれていません。
どちらが表示されるかは、実際の設定で確かめるまで決め打ちしない方が安全です。

二つの基盤を並べて分かるのは、重なったときの決まりが基盤ごとに違い、しかもどちらも安い方に寄りやすい作りだということです。
そこで、自社の価格表からランク価格だけの商品、特例のある商品、数量段階のある商品を数点ずつ選び、テスト用の取引先アカウントで表示される価格をExcelの想定価格と並べてみると、ずれの出る組み合わせが分かります。
そのずれが、その基盤で設定の工夫が要るところです。
他の基盤で同じ結果になるとは限らないため、この照合は比較している基盤ごとに行うことになります。

▼ 図の内容を文字で読む

1. ランク価格だけ・特例あり・数量段階ありの商品を数点ずつ選ぶ
2. テスト用の取引先アカウントで表示を見る
3. Excelの想定価格と並べる
4. ずれの出る組み合わせを確かめる

卸値を見せる相手を制限する:ログイン・承認・非会員の扱い

ログインと承認で見せる相手を絞る

価格を細かく出し分けるほど、見せるつもりのない相手に見えてしまったときの影響は大きくなります。
価格表をメールで個別に送っていた頃と違い、ECでは価格がいつでも閲覧できる場所に置かれるため、誰がどの価格にたどり着けるかを設定の段階で決めておく必要があります。

Shopifyのカタログは、どの顧客がどの商品と価格にアクセスできるかを制御する仕組みとして説明されています¹。
EC-Rider B2Bでは、アカウントはログインするユーザーで、管理権限や承認権限を持たせられ、注文は承認待ち・受注待ち・出荷待ち・出荷済みの4つの状態で管理されます⁵。
価格の出し分けをログインした会社やアカウントに結び付け、注文が確定する前に承認という確認点を置ける作りです。

ログインしていない訪問者に卸値をどう扱うかは、別の問題として考えます。
商品情報は公開したまま価格だけを隠したい場合、上で触れた公式の説明だけでは、標準の設定で実現できるかまでは判断できません。
基盤やプランによってはアプリの追加や画面の改修が必要になる場合もあるため、選定時には「ログアウトした状態で何が見えるか」を具体的な画面で提供者に示してもらうのが近道です。

一覧・検索・カートで価格が漏れないかの確認

設定ができたら、実際の画面で価格が漏れないかを試します。
商品詳細ページで正しく隠れていても、一覧や検索結果など別の画面に価格が残る可能性があるためです。

試すときは、ランクの違う取引先を想定したテスト用アカウントを2つ以上用意し、同じ商品を同じ数量で見比べると違いが分かりやすくなります。
一つのアカウントだけで確認すると、自分に見えている価格が正しいことは分かっても、他の取引先に何が見えているかは分かりません。
承認を挟む運用なら、承認する側の画面にどの価格が表示されるかも合わせて見ておくと、社内の確認の流れまで含めて点検できます。

▼ 図の内容を文字で読む

• ログインした取引先
  • 価格の出し分けを会社やアカウントに結び付ける
  • 注文の確定前に承認を置ける
• ログインしていない訪問者
  • 価格だけ隠せるかは標準の設定では判断できない
  • ログアウトした状態で何が見えるかを画面で示してもらう
• 設定後の画面確認
  • ランクの違うテスト用アカウントを2つ以上用意する
  • 一覧・検索・カート・通知メールまで見比べる

価格改定と個別特例を維持する運用

掛け率改定を1か所で済ませる設計

価格階層を運用し続ける負担は、価格を何件持っているかでほぼ決まります。
会社別の契約価格は、取引先数と商品数の掛け算で件数が増えます。
たとえば約3,800種類の製品を扱う日東電工CSシステム株式会社のような品数の規模で考えると⁶、取引先ごとに全品目の価格を持つ設計では、取引先が一社増えるたびに3,800件前後の価格を用意する計算になります。
同社が取引先別の価格を実際にどう管理しているかは事例では触れられておらず、ここでは品数の規模を考えるための目安として挙げています。

グループ別の掛け率なら、改定はランクの掛け率を変えるか、基本価格を変えるかのどちらか1か所で済みます。
会社別で持つ価格をランクで表せない例外だけに絞っておけば、改定のたびに見直す行は例外の数までに収まります。

価格の持ち方も改定の手間に効きます。
Adobe Commerceのように固定額と割引率を選べる場合、割引率で持った価格は基本価格からの比率なので、基本価格を変えればそれに合わせて動きます³。
固定額は基本価格と入力値の低い方が最終価格になるため、基本価格を上げても固定額の契約価格はそのまま残り、基本価格を固定額より下げたときだけ基本価格が適用されます³。
値上げの改定で個別契約の価格も上げるつもりなら、固定額の行は一件ずつ直すことになります。

改定日をどう扱うかも運用の分かれ目です。
Shopifyでは、カタログの状態変更をロールアウトとして予約できますが、会社や拠点に直接割り当てたカタログはその予約に追加できず、予約できるのは市場向けに作成したカタログに限られます¹。
取引先別のカタログで「来月1日から新価格」としたい場合は、その日に誰がどの順で切り替えるかを、仕組みの外で手順として決めておく必要があります。

基幹システム連携の確認観点

ECに価格を載せると、価格の正本がどこにあるかという問題が出てきます。
基幹システムの価格マスタを正とするなら、そこで改定した価格をECへ移す作業が発生し、ECで注文を受ければ、その受注を基幹へ入力し直す作業が発生します。
この二方向の転記を手で行っていると、ECにしたことで、価格を直す場所と受注を入力する場所がむしろ増えてしまいます。

EC-Rider B2Bの導入事例では、日東電工CSシステム株式会社が導入を検討する際、基幹システムとの連携が可能な点が判断材料の一つとされています⁶。
この事例では価格階層や取引先別価格の仕組みは語られていないため、連携で価格の転記がどう変わったかまでは分かりません。
ただ、既存の業務システムを抱えた会社がEC化を考えるとき、連携の可否が選定の論点になることを示す一例ではあります。

連携を考えるときに整理しておきたいのは、次のような点です。

<ul><li>価格の正本を基幹とECのどちらに置くか</li><li>掛け率・特例・数量段階を、基幹側でどの単位で持っているか</li><li>改定を反映する頻度とタイミング</li><li>ECで受けた注文の単価を、基幹側の価格と照らし合わせる仕組みがあるか</li></ul>

一括での価格更新や連携の方式は基盤ごとに異なり、ファイルで取り込むのか、システム同士を直接つなぐのかによって、改定のたびに人が触る作業の量が変わります。
基幹側の価格の単位とECの単位がずれていると、つなげても変換の処理が別に必要になります。
方式を選ぶ段階で両方の単位を並べておくと、連携の設計で手戻りが起きにくくなります。

▼ 図の内容を文字で読む

• 割引率で持つ価格
  • 基本価格からの比率なので基本価格に合わせて動く
• 固定額で持つ価格
  • 基本価格と入力値の低い方が最終価格になる
  • 値上げでは固定額の行を一件ずつ直す
• 取引先別の改定日
  • 直接割り当てたカタログは改定の予約に追加できない
  • 切り替えの誰が・どの順でを仕組みの外で決める

価格差を付けるときの法的な注意と、小さく始める手順

『不当に』差別的な対価とは

取引先によって価格を変えること自体が問題にならないか、気になる方もいるはずです。
公正取引委員会が示す不公正な取引方法の一般指定第3項は、「不当に、地域又は相手方により差別的な対価をもって、商品若しくは役務を供給し、又はこれらの供給を受けること」を挙げています⁴。

条文には「不当に」という限定が付いており、相手によって価格が違うことがそれだけで該当すると読める書き方ではありません。
一方で、どのような場合が「不当」に当たるかは、この条文だけからは読み取れません。
具体的な価格差が問題になるかどうかは取引の実態によって判断が変わるため、迷う場合は独占禁止法に詳しい専門家に相談するのが確実です。

実務の側でできるのは、価格差の理由を条件で説明できる形にしておくことです。
注文数量、契約期間、取引形態、物流の負担のように、なぜその取引先がその価格なのかを条件として書き出せれば、社内で価格を決める根拠になり、取引先から問い合わせがあったときにも説明しやすくなります。
グループ別の掛け率で階層を組む作業は、この条件を整理する作業とほとんど重なります。
ただし、条件を整理したことで法的な問題がないと保証されるわけではありません。

一部の取引先・商品から試す流れ

設計が固まったら、全取引先・全商品を一度に切り替えるより、範囲を絞って始める方が、ずれを見つけたときに直しやすくなります。
次のような順で進めると、Excelと見積で回している今の業務を止めずに移れます。

最初の取引先は、標準のランクに収まり特例が少なく、注文がある程度の頻度である相手が向いています。
特例の多い大口取引先から始めると、最初から例外処理の設計に時間を取られ、仕組みそのものが自社に合っているかの判断が遅れます。
商品も、注文の多い定番品から始めると、ECで計算された単価と見積の単価を照らし合わせる機会を早く得られます。

切り替え直後は、ECの注文と従来の見積・受注を並行させ、ECの単価をExcelの想定価格と照らし合わせる期間を設けます。
ずれが出なくなってから、取引先と商品を広げていきます。

EC-Rider B2Bの導入事例では、日東電工CSシステム株式会社が2017年2月から段階的に導入を検討し、2018年4月に法人向けのテープ販売サイトを開始しています⁶。
1社の経緯であり、段階的に進めれば必ずうまくいくことを示すものではありません。
それでも、既存の取引を抱えたままEC化を進めた例として、検討から公開までにどの程度の期間を見込むかを考える参考にはなります。

▼ 図の内容を文字で読む

• 書き出す条件
  • 注文数量・契約期間
  • 取引形態・物流の負担
• 整理の使い道
  • 社内で価格を決める根拠になる
  • 取引先から問い合わせがあったときに説明しやすい
• 整理しても残る限界
  • 法的な問題がないと保証されるわけではない
  • 迷う場合は独占禁止法に詳しい専門家に相談する

価格を会社別・グループ別・数量別のどれで持つかは、自社の取引先と特例の実際の価格表を並べないと決めきれず、基盤の設定に置き換えたときにどう表示されるかも試すまで分かりません。

バイヤーごとの卸価格を法人単位で設定する仕組みに、自社の掛け率表と特例を当てはめた場合の持ち方や、ログインと注文承認の流れをどう組めるかを確かめられます。無料相談で要件を整理する

要点の整理

価格の単位	大半が少数のランクに収まるならグループ別を主にし、例外だけ会社別。取引先が少なく条件がばらばらなら会社別
数量条件	注文ごとの数量なら段階価格、累計の実績ならグループの見直しで表す
併用時の表示	基盤ごとに決まりが違う。代表的な組み合わせをテスト用アカウントで想定価格と照合する
見せる相手	ログイン・承認に結び付け、一覧・検索・カート・通知まで2つ以上のアカウントで見比べる
改定の運用	会社別の価格は例外に絞る。固定額は値上げ時に個別修正が要る。価格の正本を基幹とECのどちらに置くか決める
価格差の説明	数量・契約・取引形態などの条件で理由を書き出す。個別の適否は専門家に相談

基幹システムの価格マスタや受注の流れと合わせて設計しないと、ECにしても価格を直す場所と受注を入力する場所が残ります。 基幹システムとの連携を前提に、どちらを価格の正本にするか、どの取引先と商品から小さく始めるかを具体的に相談できます。

よくある質問

取引先ごとに卸値が違うのは独占禁止法上の問題になりますか。

取引先によって価格を変えること自体が、直ちに問題になると読める規定ではありません。
一般指定第3項は「不当に」差別的な対価で供給することを不公正な取引方法として挙げています⁴。
何が不当に当たるかは個別の事情で判断されるため、価格差の理由を数量や契約条件で説明できる形にしておき、判断に迷う場合は専門家へ相談してください。

会社別価格とグループ別価格を併用したとき、どの価格が表示されますか。

基盤によって違います。
Shopifyでは同じ商品に複数のカタログが価格を付けていると最も安い価格が表示されます¹。
Adobe Commerceでは固定額の契約価格は基本価格と入力値の低い方になりますが³、会社別とグループ向けの価格のどちらが優先されるかは、実際の設定で表示を確かめる必要があります。

ログインしていない人には卸値を見せない設定は標準機能でできますか。

基盤とプランによります。
Shopifyのカタログは顧客ごとにアクセスできる商品と価格を制御しますが¹、ログインしていない訪問者に価格を隠すことまで標準で足りるかは、カタログの説明だけでは判断できません。
アプリや改修が必要かどうかを、商品一覧や検索結果の画面も含めて提供者に確かめてください。

掛け率を一括で変更するには、どの方式が向いていますか。

取引先をグループにまとめ、基本価格からの割引率で持つ方式が向いています。
割引率で持った価格は基本価格の変更に合わせて動きますが、固定額で持った価格は、値上げの際に一件ずつ直すことになります³。
ファイルでの一括更新や基幹システムとの連携の対応は基盤ごとに異なるため、選定時に確認が必要です。

数量別の段階価格と、会社別の契約価格は同時に使えますか。

基盤によっては組み合わせられます。
Adobe Commerceは共有カタログの中で商品ごとに段階価格を設定でき³、Shopifyはカタログに数量ルールとボリューム価格を設定できます²。
どちらも同じ注文の中の数量で価格を変える仕組みなので、累計の購入実績で変える条件は別に考えます。
重なったときの表示は、自社の価格で試して確かめてください。

既存の見積・受注の流れから段階的に切り替えるには、どの取引先から始めればよいですか。

標準の掛け率ランクに収まり特例が少なく、注文がある程度の頻度である取引先から始めると、ECの単価と見積の単価を照らし合わせやすくなります。
特例の多い大口取引先は、仕組みが自社に合っていると確かめてから移す方が、例外設計に時間を取られずに済みます。

1. 1　出典：Shopify「Shopify Help Center:B2B catalogs」(2026年閲覧)
2. 2　出典：Shopify「Shopify Help Center:Quantity rules and volume pricing」(2026年閲覧)
3. 3　出典：Adobe「Adobe Commerce:Set shared catalog pricing and structure」(2026年閲覧)
4. 4　出典：公正取引委員会「不公正な取引方法(一般指定)」(2026年閲覧)
5. 5　出典：株式会社フライトソリューションズ(EC-Rider)「EC-Rider B2B 販売組織・法人・アカウント管理」(2026年閲覧)
6. 6　出典：株式会社フライトソリューションズ(EC-Rider)「EC-Rider B2B 導入事例(日東電工CSシステム株式会社)」(2018年)