EC-CUBEで会員限定商品を販売する際に、商品・価格をどこまで見せるか、誰に購入を許可するかを整理します。元記事の画面例をもとに、会員登録やログインの案内、BtoB-ECの承認条件、導入前の確認点を解説します。
会員限定販売は、公開範囲と購入条件を決めるところから
ECサイトで「この商品は会員の方だけが購入できます」と案内する方法があります。商品を広く紹介しながら購入時には会員登録を求める、取引を承認した法人へ卸商品を販売するなど、目的に応じた運用が考えられます。
ただし、「会員限定」という言葉だけでは、必要な機能は決まりません。未ログインでも商品説明や価格を見られるのか、登録すれば誰でも購入できるのか、承認された取引先だけが対象なのかによって、画面と処理の両方が変わります。
「何を見せるか」と「誰が購入できるか」を分けて決めることが出発点です。会員登録の促進を重視する場合と、契約上の商品・価格を限られた相手にだけ見せる場合では、適した公開範囲も異なります。
購入だけを制限する方式と、価格・商品を隠す方式の違い
会員限定商品の見せ方には、次のような設計例があります。表は一般的な整理であり、すべてのEC-CUBEに標準設定だけで実現できる機能を示すものではありません。利用中のバージョン、テーマ、プラグインと、必要な条件を照合します。
| 方式 | 商品情報 | 価格 | 購入と主な用途 |
|---|---|---|---|
| 購入だけを会員限定にする | 公開する | 公開する | ログインし、必要な条件を満たす会員が購入。商品を広く紹介したい場合の候補。 |
| 価格と購入を会員限定にする | 公開する | 対象会員にだけ表示する | 承認や契約条件を満たす会員が購入。商品カタログを公開する卸売サイトなどで検討。 |
| 商品情報から会員限定にする | 対象会員にだけ表示する | 対象会員にだけ表示する | 閲覧・購入の両方を制限。取引先限定商品や会員専用カタログなどで検討。 |
サイト内の一部の商品だけを会員限定にすることと、サイト全体をログイン必須にすることも別です。通常商品はゲスト購入を残し、限定商品だけ会員登録を求める設計も考えられます。混在させる場合は、カートに両方が入ったときの購入方法を決めます。
サイト全体の公開方式については、EC-CUBEで会員制クローズドサイトを作るの記事でも紹介しています。本記事では、商品単位の公開範囲と購入条件を中心に考えます。
画面例:商品と価格は公開し、ログイン後に購入する
下の図は、元記事で紹介していた会員限定商品の画面例です。ログイン前にも商品画像・商品名・価格を表示し、購入部分には会員限定であることと、会員登録・ログインへの案内を出しています。

この例は「購入だけを会員限定にする」方式です。商品そのものを非公開にしたり、価格を隠したりする例ではありません。また、法人審査や会員ランクの判定まで実装されていることを、この図から確認できるわけではありません。
新たに導入する際は、見た目を切り替える処理に加え、購入操作を受け付ける側でも対象会員かを確認します。ログイン前後の表示と、実際に購入できる条件を一致させることが必要です。
「ログイン済み」と「購入資格がある」を分ける
登録会員全員が対象か、条件を満たす会員だけか
登録を完了した会員全員に販売するのであれば、その状態とログインを確認します。一方、法人審査、会員ランク、取引先との契約、過去の購入などを条件にする場合は、ログイン済みかどうかだけでは判断できません。
例えば「法人会員に販売する」という要望でも、会社名を入力すれば対象になるのか、運営側が取引を承認した法人だけなのかで意味が変わります。購入できる条件を、運営担当者が同じ判断をできる言葉で定義します。
購入履歴を条件にする場合も、注文した時点、入金後、発送後のどこで資格を付与するか、キャンセルや返品があった場合にどうするかを決めます。これらは条件付き販売を追加する場合の設計事項であり、元記事の実装済み仕様として紹介しているものではありません。
承認待ち・利用停止・期限切れを区別する
BtoB-ECでは、会員登録を受け付けても、審査が終わるまでは契約価格や限定商品を見せない運用があります。「登録申請の受付」と「取引開始」を分け、承認待ちの間に閲覧・購入できる範囲を定めます。
契約終了、会員資格の期限切れ、取引停止が発生した場合には、いつから新たな閲覧・購入を止めるかも必要です。すでにログイン中の会員や、限定商品をカートに入れたままの会員にも、新しい状態を反映できるようにします。
購入できない理由と、次に必要な操作を伝える
商品を公開する方式では、購入ボタンだけを消すと、在庫切れなのか、販売終了なのか、会員限定なのかが分かりません。「この商品は会員限定です。ログイン後にご購入いただけます」など、実際の条件に合う説明を表示します。
審査がある場合は「登録後すぐに購入できます」と案内せず、「会員登録後、取引審査の完了後にご利用いただけます」など、必要な手続きを伝えます。承認済みの会員、承認待ちの会員、対象外の会員では、表示する案内も分けます。
ログインや会員登録を終えた後には、対象商品やカートへ戻れるようにすると、商品を探し直す手間を減らせます。メール確認や承認が必要な場合も含め、ログイン・会員登録後に元のページへ戻す導線を整理します。戻り先への移動で、必要な確認を省略してはいけません。
通常商品と限定商品が同じカートに入る場合は、会員登録を求めるのか、限定商品を外せばゲスト購入を続けられるのかを案内します。どの商品が理由で購入できないのかを示し、ほかの商品まで理由なく消さないようにします。
商品自体を非公開にする方式では、対象外の人へのエラー画面に商品名・価格を出さないことも確認します。誰に何を公開する方針なのかによって、案内に含めてよい情報も変わります。
表示を隠すだけでなく、サーバー側で購入条件を確認する
商品表示・カート追加・注文確定で条件をそろえる
CSSやJavaScriptで価格やボタンを隠すだけでは、購入資格の制御にはなりません。商品詳細へのアクセス、カート追加、購入手続き、注文確定など、それぞれの処理で現在の会員と対象商品の条件を確認します。
OWASPのアクセス制御に関する資料でも、リクエストごとの権限確認と、ブラウザー側だけの判定に依存しないことが説明されています。URLを知っていることや、ボタンを押せたことだけで購入を許可しない設計にします。
再注文、商品一覧からの追加、クイック注文、CSV一括注文、外部連携などを導入している場合は、それらも確認対象です。商品詳細では購入できないのに、別の入口からは注文できてしまう状態を防ぎます。
条件を満たさない場合や、資格を確認する処理に失敗した場合の扱いも決めます。確認できないまま注文を通すのではなく、利用者へ再確認や問い合わせの方法を案内します。
価格・商品情報が別の場所から出ないかを確認する
価格を隠す場合は、画面上の文字だけでなく、HTML、構造化データ、APIの応答、商品データの配信などに対象外の価格を含めていないかを確認します。商品を非公開にする場合は、検索結果、関連商品、お気に入り、閲覧履歴、画像・資料の直接URLも対象です。
CDNやページキャッシュを利用している場合は、会員向けの商品・価格が別の利用者へ配信されないよう、キャッシュの対象と共有範囲を確認します。ログインしたかどうかだけでなく、会員ごとに条件が異なる場合も考慮します。
検索エンジン向けのnoindexやrobots.txtは、会員の閲覧権限を判定する仕組みではありません。Googleの公開範囲に関する説明でも、noindexを指定した内容へ直接アクセスできることが示されています。非公開にしたい情報は、認証と権限確認によって保護します。
BtoB-ECでは、取引先・価格・管理業務を合わせて設計する
取引先限定の商品を販売する場合は、条件を会社単位で管理するのか、担当者アカウント単位で管理するのかを決めます。同じ会社の担当者でも発注できる商品が異なるなら、その違いを扱える必要があります。
会社への所属変更、担当者の追加・退職、契約内容の変更があったときに、誰が資格を更新するかも整理します。更新を管理画面で行うのか、基幹システムや販売管理システムと連携するのかによって、必要な機能が変わります。
購入資格と取引先別価格も別の条件です。購入を許可された商品について、現在の取引先の価格・掛率・ロット・在庫を確認します。以前カートへ入れた価格や、過去の注文条件をそのまま使えるとは限りません。
商品を新規登録・複製したときや、CSVで一括更新するときの初期値にも注意します。限定商品として登録したつもりが、公開商品になっていないかを確認できるようにします。条件を変更した担当者と変更内容を記録しておくと、問い合わせ時の確認にも役立ちます。
取引停止後も過去の注文や請求情報を確認できるようにするかなど、既存取引の照会と新規購入の制限も分けて決めます。サイト全体の運用は、BtoB-EC・卸売サイト構築の検討時に合わせて整理すると進めやすくなります。
公開前に確認したい会員状態と操作
対象会員が購入できることに加え、対象外の利用者が意図した範囲を超えて閲覧・購入できないことを確認します。以下は、サイトの仕様に合わせて具体化する確認例です。
| 状態・操作 | 確認すること |
|---|---|
| 未ログインで商品を開く | 選んだ公開方式に合う商品・価格・登録案内になり、購入条件を満たさないまま注文できない。 |
| 承認済み・対象外の会員で開く | ログイン状態だけで一律に許可せず、会員ごとの条件を反映する。 |
| 登録直後・メール確認前・承認待ち | 利用開始前に限定情報や購入を許可せず、次に必要な手続きを案内する。 |
| カート追加後に資格や価格を変更 | 購入手続き・注文確定時に現在の条件を再確認し、続行できない理由を案内する。 |
| 通常商品と限定商品を同時に購入 | ログインの要否、対象外商品の扱い、ゲスト購入へ戻る方法が仕様と一致する。 |
| 直接URL・再注文・外部連携から操作 | 別の入口でも同じ購入条件を適用し、非公開の商品・価格を返さない。 |
| ログアウト・会員切り替え・共有端末 | 以前の会員に許可された情報や資格が、次の会員へ引き継がれない。 |
確認時には、会員種別と商品種別の組み合わせを用意し、通常の購入導線も試します。導入後にプラグインを追加したり、認証や再注文の機能を変更したりした場合も、関連する入口を再確認します。
会員限定にする価値と、登録の手間を両方考える
会員限定販売は、会員向けの商品や取引条件を提供する方法になります。利用者にとって登録する理由が明確であれば、サービスの理解や継続利用につながる可能性があります。
一方、理由が分からないまま会員登録を求めると、購入を見送られることもあります。「会員限定」と表示するだけで、優良顧客化や客単価の上昇が保証されるわけではありません。登録の手間に見合う内容を伝えることが必要です。
導入後は、登録開始から完了までの流れ、承認待ちの状況、限定商品の購入状況、関連する問い合わせを確認します。新規会員数だけで判断せず、対象のお客様が迷わず購入でき、運営側が条件を管理できているかを見ます。
よくある質問
商品や価格は公開したまま、購入だけを会員限定にできますか?
そのような設計が可能です。未ログイン時には商品・価格と会員登録の案内を表示し、ログイン後に購入条件を満たす会員へ購入を許可します。実現方法は、利用中のバージョン、テーマ、プラグイン、既存の購入処理を確認して決めます。
会員限定商品と、会員制クローズドサイトは同じですか?
同じとは限りません。一部の商品だけ購入を会員限定にする方式もあれば、商品や価格を会員にだけ見せる方式もあります。サイト全体をログイン必須にするか、商品単位で制限するかを、公開範囲と購入条件に分けて決めます。
BtoB-ECで、承認した法人だけが購入できるようにできますか?
取引承認の状態を購入条件として管理する設計が可能です。登録申請と承認完了を分け、会社・担当者のどちらを単位にするか、承認待ち・取引停止時に何を閲覧・購入できるかを決めます。必要なカスタマイズは既存の会員管理によって異なります。
購入ボタンを隠すだけで、会員限定販売にできますか?
ボタンの非表示だけでは不十分です。カート追加や注文確定などを処理するサーバー側でも、現在の会員と商品の購入条件を確認します。再注文や外部連携など、別の入口からも同じ条件を適用する必要があります。
カートに入れた後で、会員の資格がなくなった場合はどうしますか?
購入手続きや注文確定時に現在の資格を再確認し、条件を満たさない商品の注文を止めます。利用者には理由と次の操作を案内します。通常商品も入っている場合の続行方法や、すでに確定した注文の扱いは別途運用として決めます。
会員と商品の条件に合う販売方法を整える
会員限定商品を導入する際は、商品・価格の公開範囲、購入資格、登録から利用開始までの流れを決めます。表示の切り替えと購入処理をそろえ、資格の変更や別の注文経路まで確認することが大切です。
サンクユーでは、現在の会員管理と販売方法を確認し、運用に合うEC-CUBEの構築・カスタマイズをご提案します。対象商品、購入できる会員、公開したい情報を具体的に整理するところからご相談いただけます。
EC-CUBEの会員限定販売をご相談ください
購入だけを会員限定にしたい、卸価格を承認済みの取引先にだけ見せたい、商品ごとに販売先を分けたいなど、公開範囲と購入条件に合わせて対応内容を整理します。
投稿者プロフィール

- CEO
- 株式会社サンクユー 代表取締役CEO。
基幹システムとECをつなぎ、受発注業務の最適化を支援する専門家。
関西大学卒業後、東証プライム上場のゼネコンにて人事総務を経験。
その後システムベンダーへ転職し、IBM AS/400環境における金融・物流・販売管理・経理・人事など、企業の基幹業務を支えるシステム開発に従事する。
プログラマからプロジェクトマネージャーまでを経験し、台湾・台北駐在として銀行システム構築プロジェクトにも参画。
この経験を通じて、「システムの質は要件定義の質に比例する」という思想を確立。
業務理解を起点としたシステム設計を強みとする。
その後、クレジット決済代行会社にて、決済システムの再構築や銀行連携、ECサイト構築を担当。
あわせて組織改革にも携わり、20名から60名規模への組織拡大を実現(退任時:常務取締役)。
2008年に株式会社サンクユーを創業、2010年に法人化。
現在は、基幹システムとECの両領域に精通した知見を活かし、BtoB企業における受発注業務のデジタル化・効率化を支援。
特に、FAX・電話・メールなどアナログ業務のEC化や、基幹システムとの連携を前提とした業務設計を得意とする。
単なるECサイト構築にとどまらず、業務フローの整理・要件定義・システム設計まで一貫して関与し、「現場で使われる仕組み」を実現することを重視している。
NTTレゾナント「goo Search Solution」にてEC関連コラムを執筆。
ECマーケティングレポート | goo Search Solution
■趣味・関心領域
BMW / WRC / ロードバイク / RIZIN / UFC / 大相撲
David Bowie / blur / MUSE / The Rolling Stones / XTC
機動戦士ガンダム(富野由悠季)
ベルセルク / 頭文字D / 進撃の巨人 / ジョジョの奇妙な冒険 / あしたのジョー
Mission: Impossible / Memento / ワイルド・スピード / ソナチネ
LOST / Game of Thrones / FRINGE / The Mentalist
上岡龍太郎 / ダウンタウン









