EC-CUBEでカテゴリーの商品を特定会員だけに表示｜公開条件と運用の設計

カテゴリーごとに、商品を見せる会員を分けたい

EC-CUBEをご利用中のお客様から、「あるカテゴリーの商品を、特定の会員だけが購入できるようにしたい」というご要望をいただきました。そこで、カテゴリーと会員の紐づけによって、対象商品の表示を切り替えるカスタマイズを行いました。

たとえば、取引を承認した法人へ業務用の商品群を公開する、特定の契約を結んだ会員へ専用の商材を案内する、といった用途が考えられます。同じ公開条件の商品をカテゴリーにまとめられれば、会員ごとに商品を一つずつ選ぶ運用とは異なる管理方法を取れます。

ただし、カテゴリーは商品の分類にも使われます。「商品を探すための分類」と「閲覧を許可する範囲」が一致するかを先に確認することが大切です。取引先ごとの例外が多い場合は、カテゴリーだけで管理すると条件が複雑になることもあります。

会員限定販売全体の考え方や、商品・価格のどこまでを公開するかについては、EC-CUBEで会員限定商品を販売する際の設計もご覧ください。本記事では、カテゴリー単位の割り当てと運用を中心に解説します。

実装例：カテゴリーと会員を紐づける仕組み

実装の基本は、カテゴリー側に制御の対象かどうかを設定し、会員側に表示を許可するカテゴリーを登録することです。以下の画像は、元記事で紹介したカスタマイズ画面です。すべてのEC-CUBEで同じ項目が標準表示されるという意味ではありません。

カテゴリーに制御フラグを追加する

カテゴリーマスタに「カテゴリ制御」の項目を追加しました。このフラグを有効にしたカテゴリーを、会員ごとの表示制御の対象にします。

フラグが表すのは「このカテゴリーを会員別の制御対象にする」という設定です。誰に公開するかは、次の会員側の設定と組み合わせて判断します。

会員に表示を許可するカテゴリーを登録する

会員マスタには「制御カテゴリ」を追加しました。カテゴリーを選んで登録したり、登録済みのカテゴリーを削除したりできる画面です。

画像には階層を含むカテゴリー名と、登録・削除の操作が表示されています。会員に対象カテゴリーが登録されている場合、そのカテゴリーの商品を表示する仕組みです。

ログイン状態とカテゴリー登録によって表示を切り替える

この表は制御対象のカテゴリーについての説明です。通常カテゴリーの商品まで、すべて非表示にするという意味ではありません。

元記事で確認できるのは、フラグと会員への割り当てによる基本的な表示条件です。複数カテゴリーの判定、親子間の権限継承、購入履歴に応じた自動登録などは、ここから先で整理する設計・確認事項です。

複数カテゴリーと親子階層のルールを決める

EC-CUBE公式のカテゴリ管理マニュアルでは、商品をカテゴリーに紐づけ、カテゴリーに親子の階層を持たせる仕組みが説明されています。この分類構造を公開条件にも使う場合は、条件が重なったときの判定を決めておく必要があります。

一つの商品が複数カテゴリーに属する場合

たとえば、商品が「新商品」と「契約会員向け商材」の両方に属するケースです。「新商品」の一覧から開けば、契約のない会員にも見えてしまう設計では、限定公開の目的を満たせません。どのカテゴリーから探しても、同じ商品には同じ公開条件を適用します。

制御対象カテゴリーA・Bの両方に属する場合も、AかBのどちらかを許可されていれば表示するのか、両方の許可が必要なのかで結果が変わります。通常カテゴリーへの所属だけで制限が外れないようにし、複数の制御条件がある場合の優先順位を仕様にします。

親カテゴリーの許可を子へ引き継ぐか

「業務用商材」の下に「消耗品」「機器」がある場合、親への許可で両方を表示してよいのか、それぞれへの登録が必要なのかを決めます。画面に親子関係が見えていることと、閲覧権限が自動で引き継がれることは別です。

親へ許可した後に新しい子カテゴリーを追加した場合や、カテゴリーを別の親へ移動した場合も確認します。分類を整理しただけのつもりで、取引先へ公開する範囲まで変わることがないようにします。

新規登録・移動・解除時の扱いを決める

商品を複製して登録する、カテゴリーを付け替える、制御フラグを解除する、といった日常の操作でも公開範囲が変わる可能性があります。カテゴリー未設定や割り当て途中の商品を、意図せず一般公開しないための初期状態を決めます。

カテゴリーの削除や統合では、商品だけでなく、会員に登録されている条件への影響も確認します。「削除したカテゴリーに属していた商品はどうなるか」「会員の割り当てをどこへ移すか」を整理してから変更します。

会員への割り当てを、実際の取引ルールに合わせる

BtoB-ECでは、会員登録が完了したことと、その商材の取引を認めたことが一致するとは限りません。審査や契約の確認後に、担当者が対象カテゴリーを登録する運用などが考えられます。

誰が何を確認して登録するかに加え、取引終了、担当者の退職、契約範囲の変更に伴って、いつ割り当てを削除・変更するかも決めます。登録時だけでなく、公開を止める場面まで担当を明確にする必要があります。

同じ会社の複数担当者に共通の商品を見せたい場合は、会社単位で条件を管理するか、会員ごとに登録するかを検討します。会社と担当者の紐づけ、条件の一括反映は追加設計の対象です。元の会員別登録画面が、そのまま会社単位の管理に対応しているとは限りません。

また、「カテゴリーAの商品を購入した人に、カテゴリーBを公開する」といった用途も考えられます。ただし、カテゴリーを手動で割り当てる機能と、購入実績を判定して自動登録する機能は別です。自動化するなら、注文・入金・発送のどの時点を条件とし、キャンセルや返品時にどう扱うかを決めます。

会員数や対象カテゴリーが増える場合は、割り当て状況を一覧で確認する方法、変更履歴、CSVや基幹システムとの連携も検討します。誰が変更できるかと、変更前の状態を確認できるかを含めて、運用に必要な機能を選びます。

表示する場所と、購入できる条件をそろえる

カテゴリー一覧から商品を消すだけでは、商品の公開制限として十分とは限りません。商品名検索、商品詳細の直接URL、関連商品、お気に入り、閲覧履歴など、別の入口でも現在の会員に表示してよいかを確認します。

カテゴリー名やパンくず、検索候補にも公開範囲の検討が必要です。商品は見せなくてもカテゴリー名は公開してよいのか、取引先名を含む分類そのものを隠すのかによって、画面の作り方が変わります。

OWASPのアクセス制御に関する資料でも、権限確認を各リクエストで行い、ブラウザー側だけの判定に依存しないことが示されています。CSSやJavaScriptで隠すだけでなく、情報を返すサーバー側で条件を確認します。非公開の画像・資料やAPIの応答、共有キャッシュも、保護する情報に応じて確認対象にします。

購入も制限する場合は、カート追加、再注文、購入手続き、注文確定でも資格を確認します。会員への割り当てを削除した後、以前開いた画面やカートに残る商品から注文できてしまわないかが確認点です。権限を確認できない場合に、無条件で購入を許可しない扱いも必要です。

過去の注文内容を照会できることと、同じ商品を今また購入できることは分けて考えます。公開範囲の変更後も必要な取引履歴を確認できるようにしつつ、新しい注文には現在の条件を適用します。顧客別価格・掛率・ロット・在庫の確認も、カテゴリーの閲覧許可とは別に必要です。

表示されない理由を、適切な範囲で案内する

ログイン前の利用者には、必要に応じて会員向けサービスの説明やログインへの案内を表示します。ログイン後に権限がない場合は、商品が存在しない場合との見せ方や、問い合わせ先への案内を決めます。非公開の商品名・価格・取引先名を、エラー文で知らせない配慮も必要です。

一方、許可済みの会員が目的の商品へ到達できることも大切です。ログイン後に利用できるカテゴリーを見つけられるか、条件の変更後に表示が更新されるかを確認します。ログイン画面へ案内した場合は、必要な認証と権限確認を済ませたうえで、元のページへ戻す導線も整えます。

導入前に確認したい会員と商品の組み合わせ

対象会員で商品が表示されることに加えて、対象外の会員では表示・購入できないことを確認します。次の表は、サイトの仕様に合わせて具体化する確認例です。

検証には、一般会員、対象カテゴリーを許可した会員、別カテゴリーだけを許可した会員と、それぞれに対応する商品を用意します。対象商品の在庫や販売状態もそろえ、非表示の理由を切り分けられる状態で確認します。

商品数・カテゴリー数・会員数が多いサイトでは、検索や一覧表示への処理時間の影響も確認します。利用中のEC-CUBEのバージョン、テーマ、プラグイン、既存カスタマイズによって対応箇所が変わるため、現状を確認して導入範囲を決めます。

カテゴリーと会員の管理を、継続できる運用にする

カテゴリー単位の商品表示制御では、対象商品をまとめる仕組みと、会員へ許可を割り当てる仕組みの両方が必要です。複数カテゴリーや親子階層の判定、取引条件の変更、購入時の確認までそろえることで、実際の業務に合う運用を設計できます。

サンクユーでは、現在の商品分類や会員管理を確認し、EC-CUBEの構築・カスタマイズをご提案します。取引先ごとに商品・価格・注文条件を整理したい場合は、BtoB-EC・卸売サイト構築もご相談ください。