◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- BtoB通販サイトの権限は、社内の役割で分けるものと、取引先の会社単位・担当者単位で分けるものの二種類に分かれる
- 操作は見る権限・作る権限・決める権限の三つに分け、決める権限を誰が持つかを説明できる状態にする
- 受注ステータスの区分が権限を止める場所になるため、承認の段があるかどうかを先に確かめる
- 権限の設定は受注前・受注時・出荷前の三つの関門に割り当てると、抜けている場所が見える
- 退職・異動・担当者交代でアカウントを閉じる段取りと操作の記録を書面にすれば、取引先のチェックシートに答えられる
目次
BtoB通販サイトの『権限』とは具体的に何を指しますか
BtoB通販サイトで問われる『権限』は、社内の担当者に与えるものと、取引先のユーザーに与えるものの二つに分かれます。前者は受注・承認・管理といった役割ごとに操作できる範囲を区切るもの、後者は取引先ごとに見える価格や発注できる条件を区切るものです。取引先のチェックシートが確かめたいのは、この二つを別々に設計し、誰にどの権限を与えたかを記録して見直しているか、という一点です。IDとパスワードさえ知っていれば注文も価格の変更もできてしまう状態は、そのどちらも設計されていないことを示しています。自社に当てはめるときは、いきなり機能を探すのではなく、社内側と取引先側のそれぞれについて「誰が何をできるか」を紙に書き出すところから始めます。書き出した一覧と、いま使っているシステムが持つ設定項目を突き合わせれば、追加設定で足りるのか、仕組みごと見直す必要があるのかが分かれます。
見る権限・作る権限・決める権限の三つに分けて考えます
権限という言葉は範囲が広く、そのまま考えると手が止まります。BtoB通販サイトの場合は、見る権限・作る権限・決める権限の三つに分けると整理が進みます。
見る権限は、価格表や在庫数、過去の取引履歴など、画面に表示してよい情報の範囲です。作る権限は、見積や注文を新しく起こす操作です。決める権限は、注文を承認する、取引条件を変える、商品マスタや価格を書き換えるといった、後戻りしにくい操作です。この三つのうち、取引先のチェックシートが最も細かく問うのは決める権限で、誰がその操作を持っているかを説明できる状態が求められます。
IDとパスワードを知っていれば価格の変更までできてしまうという状態は、見る権限しか想定していない入口に、決める権限が同居していることを意味します。まずは自社のサイトで、この三つがそれぞれ誰に開いているかを確かめます。
受注の流れの区切りが、そのまま権限の境目になります
権限の境目をどこに引くかは、受注の流れが教えてくれます。BtoB向けのシステムには、「承認待ち」「受注待ち」「出荷待ち」「出荷済み」といった4つの受注ステータスで注文を管理する作りがあります1。
この区切りは、そのまま操作を止める場所になります。担当者は注文を承認待ちまで進められるが、そこから先へ動かせるのは承認者だけ、という線の引き方です。ステータスが分かれていないシステムでは、注文を起こした人がそのまま出荷まで通せてしまうため、権限を分ける場所そのものが存在しません。権限設定を検討するときは、機能の名前より先に、注文がいくつの段階を通るかを確かめます。
自社のサイトでどこに線を引けるかが見えてくると、次に問題になるのは、その線を社内の担当者と取引先のユーザーで別々に引く必要があるかどうかです。
社内の担当者と取引先の権限は分けるべきですか
社内は役割で、取引先は会社と担当者の二段で分けます
分けます。同じ『権限』でも、社内と取引先では分けるための物差しが違うためです。
社内は役割で分けます。受注担当は注文の登録と内容の確認まで、承認者は金額や条件を見て注文を先へ進めるところまで、管理者はアカウントの発行と価格マスタの変更まで、といった具合です。一人で運用している場合でも、役割の欄を分けておけば、担当者が増えたときや引き継ぐときに設定を作り直さずに済みます。
取引先は二段で分けます。上の段は会社単位で、どの価格表を見せるか、どの商品を出すか、どこまで発注を許すかを決めます。下の段は取引先の担当者単位で、発注までできる人と、見積や在庫を見るだけの人を分けます。この二段を分けておかないと、取引先の新しい担当者にアカウントを渡すたびに、価格表の設定まで触ることになります。
社内の役割と取引先の設定を一つの仕組みに混ぜてしまうと、片方を直すたびにもう片方の確認が必要になり、結局は誰も触らない設定が残ります。最初から別々の一覧として持つほうが、あとの手間が少なくなります。
退職や異動でアカウントを閉じる段取りを決めます
外部からの不正アクセスと並んで問われるのが、社内に残ったままのアカウントです。退職した社員のIDが生きている、異動した担当者に承認の権限が残っている、といった状態は、権限を細かく設計していても効き目を打ち消します。
同じことは取引先側でも起きます。取引先の担当者が交代しても、前任者のIDが使えるままになっていれば、誰が発注したのかを後から説明できません。取引先ごとに、担当者の追加と停止を誰が申請するかを決めておきます。
段取りとして決めるのは、停止を申請する人、停止する時点、そして棚卸しの周期の三つです。人事の連絡を受けた時点で停止し、周期を決めて全アカウントを一覧で見直す。この手順を文書にしておけば、チェックシートの回答欄にそのまま書けます。
権限を置く場所は、受注前・受注時・出荷前の三つに整理できます
なりすまし発注を防ぐ実務では、受注前・受注時・出荷前という3つの関門に統制を置く考え方が示されています2。権限の設定も、この3つの関門に割り当てて考えると、抜けている場所が見えます。
受注前は、アカウントを開くところの統制です。取引先の申し込みを誰が確認して発行するか、社内の役割を誰が割り当てるかが該当します。受注時は、注文が入った瞬間の統制です。金額や数量の条件で承認待ちに止める、届け先の変更を担当者の権限から外す、といった設定が入ります。出荷前は、出す直前の統制です。承認を通った注文かどうかを確かめ、誰が承認したかを記録として残します。
三つの関門に割り当ててみると、自社がどこから手を付けるべきかも決まります。
BtoB通販サイトの権限は、社内の役割で分けるものと、取引先の会社・担当者で分けるものの二種類です。見る・作る・決めるの三つに操作を分け、受注前・受注時・出荷前の関門にそれぞれ割り当て、閉じる段取りまで文書にすれば、取引先のチェックシートには自社の言葉で答えられます。
社内の役割と取引先の二段の区分を書き出したところで、その線をいま使っているシステムの設定でどこまで引けるのかは、自社だけでは判断がつきにくいところです。
手元の一覧を持ち込めば、追加設定で埋まる項目と、仕組みとして持っていない項目のどちらに当たるかを、画面の設定項目に照らして確かめられます。無料相談で要件を整理する
権限の見直しに着手する順番
発注が進む流れに沿って、受注前・受注時・出荷前という統制の関門の並びで整理しています。
- 受注前：社内と取引先の全アカウントを一覧にし、使われていないものを閉じる
- 受注前：受注担当・承認者・管理者の役割を決め、それぞれの操作範囲を書き出す
- 受注時：金額や数量の条件を決め、その条件に当たる注文を承認待ちで止める
- 受注時：取引先ごとに見せる価格表と商品を設定し、担当者単位の可否を分ける
- 出荷前：誰が承認し誰が出荷を指示したかを、記録から追えるようにする
この並びのうち、どこまでを今のシステムが担えるかは、機能の型ごとに確かめます。
今のシステムは権限管理に対応していますか
| 点検の型 | 取引先に説明できる状態 |
|---|---|
| 役割の型 | 人ではなく役割に操作範囲が結び付いている |
| 承認の型 | 条件に当たる注文が自動で止まる |
| 記録の型 | 誰がいつ何をしたかを後から追える |
| 防御の型 | 外部からの不正なアクセスを入口で止める手立てがある |
誰にどの操作を許すかを、人ではなく役割で定義できますか
| 確かめる項目 | 対応していない場合の見え方 |
|---|---|
| 役割の追加 | 権限がアカウントごとの個別設定になっている |
| 操作範囲の割り当て | 画面単位でしか制限できず、金額や価格の変更を分けられない |
| 取引先側の二段管理 | 会社単位の設定と担当者単位の設定が一つになっている |
条件を決めて注文を止められますか
| 確かめる項目 | 対応していない場合の見え方 |
|---|---|
| 承認の段階 | 受注ステータスに承認待ちの段が無い1 |
| 止める条件 | 金額や数量で自動的に止める設定が無い |
| 承認者の指定 | 誰が承認したかが注文に残らない |
誰がいつ何をしたかを後から追えますか
| 確かめる項目 | 対応していない場合の見え方 |
|---|---|
| 操作ログ | ログイン記録はあるが、価格や取引条件の変更履歴が残らない |
| アカウントの履歴 | 発行と停止の記録が台帳側にしか無い |
| 書き出し | チェックシートに添える一覧を画面から出せない |
外部からの不正なアクセスを入口で止める手立てがありますか
| 確かめる項目 | 対応していない場合の見え方 |
|---|---|
| 入口の対策 | ID・パスワード以外に確かめる仕組みが無い |
| 対策の内訳 | 5つのセキュリティ対策のように、講じている対策を項目として説明できない3 |
| 設定の維持 | 対策の設定を誰が見直すか決まっていない |
要点の整理
| 軸 | 基準 |
|---|---|
| 権限の種類 | 見る・作る・決めるの三つに分けて書き出す |
| 分ける対象 | 社内は役割で、取引先は会社単位と担当者単位の二段で分ける |
| 止める場所 | 受注前・受注時・出荷前の三つの関門に割り当てる |
| 閉じる段取り | 退職・異動・担当者交代の連絡を受けた時点で停止し、周期を決めて棚卸しする |
| 説明の材料 | 操作の記録と、権限設定の運用ルールを書面にしたもの |
取引先へ提出する回答は、機能があるかどうかではなく、どの関門で何を止めているかを自社の言葉で書く必要があり、その組み立てには実際の設定を見ながらの確認が要ります。 受注前・受注時・出荷前のどこに承認と記録を置けるか、退職や担当者交代のときにアカウントをどう閉じるかを具体的に決め、チェックシートの回答に使える形にできます。
よくある質問
権限は細かく分けるほど安全ですか
細かさより、説明できるかどうかが先です。役割を増やしすぎると、誰も実態を把握できないまま設定だけが残り、退職者のアカウントを閉じる作業も追いつかなくなります。受注担当・承認者・管理者のように、社内で実際に分かれている役割の数から始め、運用しながら足りない分を足すほうが続きます。
エクセルの台帳でアカウントを管理していれば十分ですか
台帳は棚卸しの道具として役に立ちますが、それだけでは操作を止められません。台帳に「承認者」と書いてあっても、システム側で誰でも注文を先へ進められるなら、権限は分かれていないことになります。台帳とシステムの設定が一致しているかを、周期を決めて突き合わせます。
取引先のチェックシートには何を書けばよいですか
本文で整理した内容がそのまま材料になります。社内の役割区分と取引先側の二段の区分、受注前・受注時・出荷前のどこで操作を止めているか、退職や担当者交代のときに誰がいつアカウントを閉じるか、操作の記録が残るか。この四つを書面にしておけば、設問の言い回しが変わっても当てはめて答えられます。
今のシステムが権限管理に対応していない場合はどうしますか
まず、追加設定で埋められる項目と、仕組みの作りとして持っていない項目を分けます。役割の追加や承認の条件は設定で足りることがありますが、受注ステータスに承認の段が無い場合や、操作の記録が残らない場合は、運用の工夫では埋められません。埋められない項目を一覧にして、乗り換えの判断材料にします。
- 1 出典：株式会社フライトソリューションズ「販売組織・法人アカウント管理（EC-Rider B2B Ⅱ 機能紹介）」（2026年） 経路
- 2 出典：株式会社フライトソリューションズ「卸売の取り込み詐欺・なりすまし発注を防ぐ実務」（2026年） 経路
- 3 出典：株式会社フライトソリューションズ「安心・安全なセキュリティ（EC-Rider B2B Ⅱ 機能紹介）」（2026年） 経路
画像の出典元
- オフィスの自席で納品書とノートパソコンを見比べる日本人の会社員／画像：生成AI（自社）
- Explore the sprawling cityscape of Los Angeles from above, s／Photo by RDNE Stock project on Pexels
- 30代前半の日本人女性が自宅での注文をしている場面／画像：生成AI（自社）
- 30代前半の日本人女性が搬入口での台車の移動をしている場面／画像：生成AI（自社）
