会員サイトの権限管理｜取引先ごとに表示を変える仕組み

「取引先ごとに、見せる情報を変えたい」。会員サイトの要件定義で必ず出てくる一文です。要件は通っても、実装の段で設計が止まります。権限をどの単位で持たせるかを決めていないためです。

ユーザー1件ずつに閲覧可否を設定する方式でも、取引先が10社のうちは動きます。50社を超えたあたりで、設定作業が追いつかなくなります。

この記事では、会員サイトの権限管理を「取引先（企業）」という単位で組む方法を扱います。仕組みを支える4つの部品、実装パターン4種の比較、配ったあとの運用ルールを整理しました。自社の取引先数と更新頻度から、どの方式を選ぶかを判断できる状態を目指します。

会員サイトの権限管理とは｜単位は個人ではなく取引先

BtoBの会員サイトでは、権限の単位は個人ではなく取引先です。「田中さんだから見られる」のではなく「A社の担当者だから見られる」という構造になります。

アクセス制御（＝誰がどの情報に触れられるかを決める仕組み）の設計は、この単位の違いが出発点です。BtoCの会員サイトとの差は2点あります。

• 契約や取引条件は企業と企業の間で結ばれる。閲覧可否の根拠が、個人ではなく企業側にある
• 1つの取引先に複数の担当者がぶら下がり、その顔ぶれが年単位で入れ替わる

例えば、NDAを締結した取引先にだけ図面データを公開する運用があります。締結の相手は企業なので、先方の担当者が3名から5名に増えても公開範囲は変わりません。BtoB ECの構築事例でも、得意先ごとに商品や単価の表示を変えたい要望が挙げられています（ecbeing｜得意先毎に異なる対応をしたい）。

なぜ取引先ごとに情報を変えるのかは顧客ランク別に価格を出し分ける方法で扱っています。ここでは実装と維持に絞ります。

個人アカウントに権限を直付けすると、何が起きるか

管理画面でユーザーを1件ずつ開き、閲覧できるカテゴリにチェックを入れる。分かりやすく、最初の10社なら破綻しません。

問題は件数です。取引先100社に担当者が平均3名いれば、アカウントは300件。資料カテゴリを1つ追加するたびに、300件を開いて設定し直すことになります。

設定作業そのものが、担当者の業務になります。

あとから追加された担当者だけ設定が漏れる事故も起きます。漏れは「見えてはいけないものが見える」方向にも出ます。

取引先ごとの表示を成り立たせる4つの部品

取引先単位のアクセス制御は、4つのデータが揃って初めて動きます。1つ欠けるだけで、運用は手作業に戻ります。

• 取引先マスタ：企業の属性を持つ台帳。顧客ランク、業種、契約状態、NDAの有無を持たせる
• ユーザーの所属：担当者と企業を結ぶ情報。1人が複数社に所属する代理店も想定する
• ロール：属性の組み合わせから自動で付くラベル。「NDA締結済みかつ製造業」のような条件で定義する
• 公開設定：コンテンツ側で「どのロールに見せるか」を選ぶ仕組み

つまずきやすいのは、取引先マスタとロールはあるのに、公開設定がページ単位でしか持てないケースです。資料を出すたびページを複製することになり、複製は更新されないまま残ります。構築手順の全体像はBtoB会員限定サイトの作り方にまとめています。

実装パターン4種の比較

自社はどこまで自動化すべきか。ここが実装方式の分かれ目になります。

取引先ごとの表示制御は、大きく4方式に分かれます。①に近いほど導入が簡単で運用が重く、④に近いほど初期設計に手間がかかります。次の表は4方式の仕組みと規模感を並べたものです。

選び分けの軸は、取引先の数、権限パターンの数、取引先情報の更新頻度の3つです。取引先が50社を超えるか、権限パターンが5通りを超える見込みなら、①は外れます。

②と④は排他ではありません。②を土台に、例外だけ④で上書きする構成が実務では多くなります。

「役割」だけでは足りず「属性」が要る理由

権限モデルには、役割を単位にするRBAC（役割ベースアクセス制御）と、属性を条件に使うABAC（属性ベースアクセス制御）の2つがあります。

デジタル庁の技術レポートは、クラウド環境ではIDや役割という単一の情報では十分ではなく、リソースの属性情報と環境情報の活用が効果的だと整理しています（デジタル庁｜属性ベースアクセス制御に関する技術レポート）。

会員サイトなら「企業の属性 × 個人の職務」の掛け合わせです。A社に所属し、かつ購買担当のときだけ発注画面を出す。役割だけでは、A社とB社の購買担当を区別できません。

SaaSのマルチテナント設計でも、利用者の所属テナントとリソースの所属を突き合わせ、他社データを遮断する方法が示されています（AWS｜RBACとABACによるマルチテナントアクセスコントロール）。取引先を1テナントと見なす発想です。

得意先マスタと二重管理にしない

会員サイト側で取引先の属性を手入力すると、基幹システムの得意先マスタと食い違います。

マスタが2つある状態は、いずれ必ずずれます。

決めるべきは3点です。どちらを正とするか、同期を日次バッチにするかリアルタイムにするか、同期項目は何か。最低限、顧客ランク・取引停止フラグ・与信区分は会員サイト側へ流し込めるようにします。受注まで扱うなら見積・受注ワークフローの設計とあわせて検討してください。

自社の取引先数と権限パターンで、どの方式が現実的かを整理したい方へ。tovira では、カスタマーポータルの機能と権限設計の考え方をまとめた資料をご用意しています。資料をダウンロードする

配ったあとが本番｜権限のライフサイクル運用

会員サイトの権限管理でつまずくのは、設計より運用の局面です。公開直後は正しくても、半年後には実態とずれます。

総務省の「国民のためのサイバーセキュリティサイト」は、人事異動や退職時の設定見直しと、定期的な棚卸による不要な権限の確認を挙げています（総務省｜アクセス制御・管理）。社内システム向けの記述ですが、取引先が使う会員サイトでも考え方は同じです。

権限は、付与・変更・棚卸し・剥奪という4局面を回し続ける対象になります。

抜けやすいのは剥奪です。付与は申請が来るので動きます。止める側には、申請が来ません。取引が終わった先のアカウントが、そのまま生き続けます。

取引先側の管理者に、自社ユーザーの追加を任せる

先方の人事異動を、こちらが把握するのは無理があります。連絡は来ません。

そこで、取引先ごとに1名「先方管理者」を置き、自社の担当者の追加と停止を任せます。権限の委譲です。入れ替わりが自然に反映され、申請と承認の往復も減ります。

ただし、委譲の範囲には線を引いてください。任せるのは「その企業に所属するユーザーの追加・停止」まで。公開範囲の設定は、サイト運営側が握ります。

棚卸しの頻度と、見る項目

棚卸しは半期に1回、取引先数が多い場合は四半期ごとに実施します。確認する項目は5つです。

• 90日以上ログインのないアカウント
• 取引停止・契約終了した取引先に紐づく、有効なままのアカウント
• 構築時に作ったテスト用アカウント
• 1人に複数のロールが付き、条件が矛盾していないか
• 管理者権限を持つ人数（自社側と取引先側の両方）

IPAの「組織における内部不正防止ガイドライン」は第5版で、退職者増加によるリスクへの対策を追記しています（IPA｜組織における内部不正防止ガイドライン）。退職者は自社からも取引先からも出ます。

公開前に「相手の画面」を見る

新しい製品ページを公開したら、代理店向けの仕切価格が全社に見えていた。誤公開の多くは、設定ミスというより確認手順の不在で起きます。

防ぐ手立ては2つです。

• コンテンツの公開範囲の初期値を「非公開」にし、対象ロールを選んで初めて公開される仕様にする
• 公開前に、対象ロールの画面をそのまま表示するプレビュー（なりすまし表示）で確認する

管理者の画面では、すべてが見えます。だから気づけません。

資料ダウンロード機能のように、ファイル単位で公開範囲が変わる箇所ほど、この確認が効きます。

導入前に決めておく5つのこと

要件定義の段階で社内合意しておくと、ベンダーへの質問がそのまま作れます。論点と担当部門を並べます。

1. 権限の単位（情報システム・営業企画）：企業単位にするか、企業と職務の掛け合わせにするか
2. 公開範囲の初期値（情報システム）：既定を非公開にするか、公開にするか
3. 委譲の範囲（営業企画）：先方管理者にどこまでの操作を許すか
4. 同期元のマスタ（情報システム）：どの得意先マスタを正とし、何をどの頻度で同期するか
5. 監査ログの保存期間（法務・情報システム）：誰が何を閲覧・ダウンロードしたかを、いつまで残すか

この5点が決まっていれば、デモの場で「この設計は実現できますか」と具体的に確認できます。例えばtoviraではユーザーロール機能として、ステータスや企業分類の条件からロールを自動で割り当てる考え方をとっています。カテゴリ全体の位置づけはカスタマーポータルとはをご覧ください。

よくある質問

会員サイトの権限管理は、どこまで細かく設定できますか

製品によって幅があります。「会員／非会員」の2段階しか持てないものから、複数の属性を条件式で組み合わせられるものまで分かれます。必要な粒度は権限パターンの数で決まり、5通りを超えるなら条件式で組める製品を選びます。

1つの取引先に複数の担当者がいる場合、どう管理しますか

担当者を企業アカウントの下にぶら下げ、企業側の属性を全員が継承する構造にします。個人ごとの設定は、購買担当だけ発注できるといった職務差に限定します。企業側と個人側で役割を分ければ、担当者が増えても設定作業は発生しません。

取引先の担当者が退職したら、アカウントはどうすべきですか

速やかに停止します。削除ではなく停止にすると閲覧・ダウンロード履歴が残り、監査に対応できます。退職の連絡は来ない前提で、90日以上ログインのないアカウントを定期的に洗い出してください。

WordPressのプラグインでも取引先ごとの出し分けはできますか

会員限定ページの制御までなら可能です。取引先マスタとの連携、1社複数ユーザーの階層管理、ロールの自動付与まで求めると、複数プラグインの併用と追加開発が必要になります。

権限管理は情報漏えい対策としてどこまで有効ですか

必要最低限のアクセスだけを許可する設計は、被害範囲を絞る効果があります。ただし権限設定だけでは不十分で、認証方式・監査ログ・棚卸しの運用とセットで機能します。

まとめ｜権限の単位を決めることが設計の8割

会員サイトの権限管理は、機能の有無より「どの単位で権限を持つか」で決まります。要点は4つです。

1. 単位は個人ではなく取引先。企業側の属性を、所属する担当者が継承する構造にする
2. 取引先マスタ・所属・ロール・公開設定の4部品が揃って、初めて自動で切り替わる
3. 実装パターンは4種。取引先数・権限パターン数・更新頻度の3つで選び分ける
4. 付与・変更・棚卸し・剥奪の4局面を回す運用ルールを、公開前に決めておく

次に取るべき行動は、自社の取引先数、1社あたりの担当者数、権限パターン数を数えることです。この3つがあれば、方式の議論は具体的になります。

tovira のカスタマーポータルは、取引先の属性から自動でロールを割り当て、製品ページや資料の公開範囲を切り替えます。自社のデータで実現できるかは、実際の管理画面でご確認ください。デモを依頼する

出典

• デジタル庁『ゼロトラストアーキテクチャ適用における属性ベースアクセス制御に関する技術レポート』 digital.go.jp（参照：2026-07-26）
• AWS『RBACとABACによるマルチテナントアクセスコントロール』 docs.aws.amazon.com（参照：2026-07-26）
• 総務省『国民のためのサイバーセキュリティサイト｜アクセス制御・管理』 soumu.go.jp（参照：2026-07-26）
• IPA『組織における内部不正防止ガイドライン』 ipa.go.jp（参照：2026-07-26）
• ecbeing『BtoB課題解決例｜得意先毎に異なる対応をしたい』 ecbeing.net（参照：2026-07-26）