Web受発注システムの権限設計：担当者・取引先に何をどこまで許すか

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

B2B EC-COLUMN

担当者と取引先が増えて「誰が何を変えられるか」説明できなくなったとき、まず何を決めるか

Web受発注システムに担当者や取引先が増えていくと、誰が注文を登録・変更・取消できるのか、誰が価格や取引先の情報を見られるのかを、すぐには説明できなくなります。
このとき見直せるのは、権限の決め方です。
権限を機能の名前で決めるのをやめ、注文の流れ（登録・承認・変更・取消・確認・閲覧）と、見せる情報に結び付けて決め直します。
権限は必要最小限から付与し、少数の役割で足りない場面にだけ金額別の承認を足します。
取引先は社内とは別の基準で狭く始め、入退社や異動のたびに見直します。
設定できる細かさは製品によって違うため、最後は自社製品の仕様で確かめます。

権限が曖昧だと何が起きるか

権限が曖昧なまま運用していると、困りごとは操作ミスより先に「説明できないこと」として表れます。
たとえば取引先から「うちの注文の数量を変えたのは誰か」と問われたとします。
注文を変更できる人が営業事務、営業担当、前任者のアカウントまで広がっていれば、答えを探す範囲もそれだけ広くなります。
誤発注に気づいても、まず誰の操作だったかを絞り込むところから始めることになります。

見えすぎの問題も同じ構造です。
取引先ごとに違う単価や掛け率を、その取引先を担当しない社員まで見られる状態は、悪意がなくても情報が外へ出る経路になります。
退職者や異動者のアカウントが残っていれば、本人や本人以外の誰かがそれを使う余地も残ります。

こうした不安は、受発注の仕組みに限った話ではありません。
IPAの「情報セキュリティ10大脅威 2026」では、組織向けの脅威として「サプライチェーンや委託先を狙った攻撃」が2位、「内部不正による情報漏えい等」が7位に選ばれています¹。
ただし、この順位は組織全般の脅威を選考会の投票で並べたもので、受発注システムでの被害件数を示すものではありません。
取引先とつながる経路と、社内の人による不正や持ち出しが、公的にも重く見られている、という位置づけとして受け取るのが妥当です。

IPAの「組織における内部不正防止ガイドライン」は、基本方針・資産管理・技術的管理・職場環境・事後対策などの観点ごとに、具体的な対策を整理しています²。
2022年の第5版では、雇用の流動化で退職者が増えることのリスクを下げるための人的管理の対策が追記されました²。
担当者の入れ替わりで、誰がどの権限を持っているのか分からなくなる悩みは、この追記の背景とも重なります。

注文の流れと見せる情報を一覧にする

最初に決めるのは、設定画面のどの項目を触るかではありません。
自社の注文が誰の操作でどう進むのかを、一覧にすることです。
権限の項目は製品ごとに名前も区切りも違います。
設定画面から考え始めると、製品の分け方に自社の業務を合わせることになりがちです。

一覧の縦には、注文に対する操作を並べます。
並べるのは、登録、承認、変更、取消、確認（受注内容や出荷の確認）、閲覧の6つです。
横には、見せる情報を並べます。
単価や掛け率、取引先の連絡先や与信に関わる情報、他の取引先の注文など、見てよい人が限られるものを洗い出します。

そのうえで、各マスに「社内の誰に許すか」と「取引先の誰に許すか」を書き込みます。
空欄のまま埋まらないマスや、「たぶん全員」としか書けないマスが、いま説明できなくなっている箇所です。
この一覧は公的な様式ではなく、権限を決め直すための作業の提案です。
以降の判断は、すべてこの一覧を土台にします。

▼ 図の内容を文字で読む

1. 注文の流れと見せる情報を一覧にする
2. 各マスに社内と取引先の誰に許すかを書き込む
3. 空欄や「たぶん全員」のマスを洗い出す

注文の流れのどの操作に、誰の権限を分けて持たせるか

登録・承認・変更・取消・確認・閲覧に分ける

一覧ができたら、操作ごとに「誰に持たせるか」を決めます。
それと同じくらい大事なのが、「誰に同時に持たせないか」です。
中心になるのは、注文を登録した人が自分で承認しないという分け方です。
登録と承認が同じ人に集まっていると、入力の誤りに本人以外が気づく機会がありません。
意図的な水増しや架空の注文も、一人で完結してしまいます。

変更と取消は、登録より慎重に扱う価値があります。
登録した内容は承認の段階で一度見直されます。
一方、確定後の変更や取消は、承認を経ずに金額や数量を書き換える経路になりやすいからです。
たとえば営業事務の担当者が、取引先から電話で数量の変更を受け、確定済みの注文を直接書き換えたとします。
すると、承認者が見た内容とは違う内容で出荷が進みます。
確定後の変更では承認をやり直す、変更の理由を記録させる、と決めておけば、あとから経緯をたどれます。

確認と閲覧は、操作の権限とは分けて考えます。
出荷担当が受注内容を確かめるには、注文を見る必要があります。
しかし、単価や取引先の与信情報まで見る必要がない場面は少なくありません。
「注文を見られる」と「価格を見られる」を同じ権限にまとめている製品なら、どちらを優先するかを業務の側で決めることになります。

登録者と承認者を分けるのは、この記事が勧める設計上の考え方です。
法令や公的な指針がこの形を一律に求めているという意味ではありません。
また、分けられるかどうかは、製品に承認の機能があるか、承認者を登録者とは別に指定できるかで決まります。

「許可したものだけ」の考え方

権限の付け方には、二つの方向があります。
一つは、すべてできる状態から困る操作を外す方向です。
もう一つは、何もできない状態から必要な操作を足す方向です。
どちらを選ぶかで、漏れの出方が変わります。
前者では、新しい機能や画面が追加されたときに外し忘れると、その機能がそのまま使えてしまいます。
後者なら、足し忘れた操作は使えないため、業務の側から「これができない」と声が上がり、漏れに気づけます。

製品の仕様にも、後者の考え方を採るものがあります。
B2B向けのEC基盤であるAdobe Commerce B2Bでは、権限を許可か拒否のどちらかで指定し、明示的に許可していないものはすべて拒否されます⁵。
権限のない画面を開くと、「Access Denied」と表示されます⁴。
同じ製品では、権限の単位として、販売（注文の購入や閲覧）、見積、注文承認、会社プロファイル、会社ユーザー管理、会社クレジットが分かれています⁴。

これは受発注専用の製品ではなく、一つの製品で権限をここまで分けている例です。
自社のシステムに同じ項目があるとは限りません。
項目の名前が同じでも、含まれる範囲が違うこともあります。
自社製品の設定画面では、一覧の各操作がどの権限項目に当たるのかを、一つずつ対応させていきます。
対応する項目が見つからない操作は、業務の手順で補う対象として残しておきます。

▼ 図の内容を文字で読む

1. 注文の登録
2. 承認（登録者とは別の人）
3. 受注の確定・出荷の確認
4. 確定後の変更・取消（理由を記録し承認をやり直す）

社内担当者と取引先で、見せる情報と操作できる範囲をどう変えるか

社内と取引先で付与の基準を変える

取引先のユーザーにも、社内担当者と同じ一覧で同じように権限を付ければよい、と考えたくなるかもしれません。
ただ、付与の基準は分けたほうが整理しやすくなります。
社内担当者には、自分の業務に必要な範囲を許します。
取引先には、その取引先自身の取引に必要な最小の範囲を許します。

基準を分ける理由は、許した範囲の外側に何があるかにあります。
社内担当者が担当外の取引先の注文を見られても、情報がすぐ社外へ出るわけではありません。
一方、取引先のユーザーが他社の注文や他社向けの単価を見られる状態は、その時点で情報が社外へ出ています。
同じ「見えすぎ」でも、取引先の側で起きたものは取り戻せません。
そのため取引先には、狭く始めて必要に応じて広げる順番が向いています。

取引先のアカウントが侵入の入口として狙われることも、範囲を狭くする理由になります。
前の節で触れたとおり、サプライチェーンや委託先を狙った攻撃は、組織向けの脅威の上位に置かれています¹。
取引先のパスワードが漏れたときに見られる情報は、そのアカウントに許した範囲で決まります。
範囲が狭ければ、見られる情報もそれだけ限られます。

取引先ごとの価格や在庫、他社の情報をどの単位で分けて見せられるかは、製品によって違います。
自社製品で、取引先ごとの見え方をどこまで分けられるかは、仕様として確かめておく必要があります。
分けられない場合の補い方は、最後の節で扱います。

取引先側の管理者を誰が担うか

取引先の担当者が多くなると、そのユーザーの追加や削除をすべて自社で引き受けるのは負担になります。
そこで、取引先の側に管理者を置く方式があります。
その会社のユーザーは、取引先自身に管理してもらう形です。

Adobe Commerce B2Bでは、取引先の会社ごとに会社管理者がいます⁴。
会社管理者は、既定ですべての権限を持つスーパーユーザーとして扱われます⁴。
会社管理者は、ロール（役割ごとに権限をまとめた設定）を作り、その会社のユーザーに割り当てます⁴⁵。
既定で用意されているロールは「Default User」で、内容は変更できます⁴。
製品のロールの例も示されています⁴。
上位の購買担当は販売と見積の操作をすべて使え、会社プロファイルなどは閲覧のみです⁴。
補助の購買担当は、見積を使った注文と閲覧ができます⁴。

この方式を採る場合、自社が決めておくことは二つあります。
一つは、取引先側の管理者を誰にするかです。
取引先の窓口担当の個人に任せるのか、取引先の情報システム部門に任せるのかで、管理者本人の退職や異動に誰が気づけるかが変わります。
もう一つは、取引先側の管理者がどこまで権限を広げられるかです。
取引先が自社内のユーザーを増やせるとしても、そのユーザーが見られる価格や注文の範囲は、自社の側で上限を決めておきます。

取引先の管理者がロールを自由に作れる製品か、自社が用意したロールから選ぶだけの製品かによって、上限の決め方は変わります。
前者なら、取引先の管理者がどこまで権限を組み合わせられるかを確認します。
後者なら、自社が用意するロールの中身そのものが上限になります。

▼ 図の内容を文字で読む

• 社内担当者
  • 自分の業務に必要な範囲を許す
  • 担当外の情報が見えても社内にとどまる
• 取引先のユーザー
  • その取引先自身の取引に必要な最小の範囲
  • 狭く始めて必要に応じて広げる
• 取引先側の管理者
  • その会社のユーザーの追加や削除を担う
  • 見られる価格や注文の上限は自社が決める

役割別の権限で足りる場合と、金額・取引先別の制限や承認分離が要る場合

少数のロールから始める

権限を細かく分けるほど、誤った操作や見えすぎは減らしやすくなります。
その代わりに、人を追加するたびに多くの項目を設定することになり、設定の誤りそのものが増えます。
細かさには、業務への影響と運用の負担という二つの代償が伴います。

そこで、まず少数のロールを作り、人にはロールを割り当てる形から始めます。
Adobe Commerce B2Bの開発者向け資料でも、多くの場合は少数のロールで必要な権限の組合せを賄える、と説明されています⁵。
何個で足りるかは業務によって違います。
最初の一覧で、許す操作と情報の並びが同じになる人をまとめれば、自社のロールの候補が見えてきます。

受注側の社内であれば、「受注入力」「受注承認」「出荷確認」「閲覧のみ」のような区切りが考えられます。
ここで大切なのは、個人ごとに例外の権限を足さないことです。
特別な権限を持つ人が増えるほど、誰が何をできるのかは再び説明しにくくなります。
例外が必要になったら、その人に権限を足すのではなく、新しいロールが要るのかを考えます。

金額別の承認を足す条件

少数のロールでは防げない場面が出てきたら、そこで初めて細かい制限を足します。
典型的なのは、同じ「注文を登録できる人」でも、少額の注文と高額の注文で、誤りや不正が起きたときの損失の大きさが違う場合です。
すべての注文に承認を求めると、日常的な少額の注文まで承認待ちで止まります。
承認者の確認も、形だけになりやすくなります。

金額によって承認の段階を変える仕組みを、機能として用意している製品もあります。
Adobe Commerce B2Bの発注書の説明には、次のような設定例が示されています⁶。
ある金額未満は自動で承認し、一定の範囲は特定の承認者、さらに高額な注文は複数の承認者を必要とします⁶。
役職の高いユーザーが作成した発注書は自動で承認する、という例外の例もあります⁶。
この承認ルールは、権限を持つ取引先（買い手）側の利用者が設定する仕組みです⁶。
受注側の自社から見れば、取引先の社内で注文がどう承認されるかは、取引先側の管理者の設定次第ということになります。

この例の金額は変数で示されているだけで、目安となる金額は書かれていません⁶。
どこで線を引くかは、自社で決めることになります。
考え方としては、その金額の注文が誤っていたとき、あるいは不正だったときに、自社が受け止められる損失の大きさを基準にします。
取消や返品で元に戻せる注文と、受注生産のように取り消しにくい注文とでは、同じ金額でも線の位置が変わってよいはずです。

業務への影響と運用の負担の二つで比べると、判断の分かれ目が見えてきます。
承認を足せば、承認者が不在のときに注文が止まり、待ち時間という影響が出ます。
金額や取引先ごとの条件を増やせば、条件の保守と、なぜその条件なのかを説明し続ける負担が増えます。
この二つを抑えたいなら、少数のロールにとどめます。
金額別の承認を足すのは、高額の誤りが実際に業務を揺るがしうる場合で、承認の待ち時間を受け入れる価値があるときです。
取引先や拠点ごとに操作や閲覧の範囲を絞る制限も、同じ二つの軸で考え、必要になった場面にだけ足します。
なお、ロールと金額別の承認の組合せは一つの製品で確かめられた例で、他の製品に同じ機能があるとは限りません。

▼ 図の内容を文字で読む

• 少数のロールで割り当てる
  • 許す操作と情報の並びが同じ人をまとめる
  • 個人ごとに例外の権限を足さない
• 金額別の承認を足す
  • 受け止められる損失の大きさで線を引く
  • 承認者不在で注文が止まる影響を受け入れる
• 取引先・拠点別の制限を足す
  • 必要になった場面にだけ足す
  • 条件の保守と説明の負担を見込む

ID管理・認証・操作ログで、権限設計をどう支えるか

権限・認証・ログの役割の違い

権限をどれだけ丁寧に決めても、それだけでは守れないことがあります。
権限設計が決めるのは、「この人に何を許すか」です。
「いま操作しているのが本当にその人か」を確かめるのは認証です。
「誰がいつ何をしたかを、あとからたどれるか」を支えるのは操作ログです。

たとえば発注担当者のパスワードが漏れれば、権限の設計が正しくても、別人がその権限の範囲で注文を登録できてしまいます。
このとき被害を抑える助けになるのが、パスワードに加えて別の確認手段を求める多要素認証のように、本人確認を強める仕組みです。
また、登録と承認を分けていても、承認者が中身を見ずに承認し続けていれば、分けた意味は薄れます。
そうした状態に気づけるのは、誰がどの注文を登録し、誰がいつ承認したかを記録した操作ログを見返したときです。

IPAの内部不正防止ガイドラインは、資産管理や職場環境と並べて、技術的管理を対策の観点の一つに置いています²。
人や手順の決めごとだけでは足りず、技術的な仕組みで支える必要がある、という整理として読めます。
中小企業向けには「中小企業の情報セキュリティ対策ガイドライン」の第4.0版があり、経営者編と実践編で構成されています³。
このガイドラインは、個人事業主や小規模事業者を含む中小企業での利用を想定しています³。
担当者が数人の会社でも、組織としての対策を考える手がかりになります。
認証やログについての具体的な対策の項目は、各ガイドラインの本文で確かめてください。

製品ごとに確かめたいのは、次の三点です。
どの操作がログに残るか、ログを誰がどの範囲で見られるか、取引先のユーザーにも多要素認証を求められるか、です。
ログが残っていても、管理者しか見られない、変更前の内容が残らない、といった違いによって、あとから追える範囲は変わります。

入退社・異動・取引先の変更のたびに、権限をどう見直し続けるか

見直しの節目

権限は、設定した日がいちばん正確です。
その後は、人の入れ替わりのたびに実態とずれていきます。
ずれが生じる節目は、おおむね次のとおりです。

<ul><li>社内の入社</li><li>社内の異動・担当替え</li><li>社内の退職</li><li>取引先の追加</li><li>取引先側の担当者の交代</li><li>取引の終了</li></ul>

このうち見落とされやすいのは、異動と取引先側の担当者の交代です。
入社と退職は、人事の手続きと結び付けやすい節目です。
一方、異動では前の部署の権限を外し忘れ、新しい権限だけが足されがちです。
これが重なると、在籍の長い人ほど多くの権限を抱える状態になります。
取引先側の担当者の交代は、取引先が知らせてくれなければ、自社からは見えません。

節目ごとの見直しを補う手段として、定期的な棚卸しもあります。
棚卸しは、実際の設定と最初の一覧を照合する作業です。
頻度の目安は、ここでは示しません。
人や取引先の入れ替わりの多さに合わせて、自社で決める項目です。

退職・異動時の手順案

節目ごとの作業は、個人ではなくロールに結び付けておくと迷いが減ります。
人に直接権限を足していると、退職のときに「この人が何を持っていたか」を一つずつ調べることになります。
ロールで付けていれば、外すべきものがロールの割当てとしてそのまま見えます。

手順の案は次のとおりです。

<ol><li>人事の入退社・異動の連絡が、受発注システムの管理者にも届くようにする</li><li>異動では、新しいロールを付ける前に、前の業務のロールを外す</li><li>退職では、退職日にアカウントが停止されたことを管理者が確かめ、確かめた日を記録する</li><li>取引先には担当者が替わったら知らせてもらうよう依頼し、取引が終了したら自社側でその取引先のユーザーを止める</li><li>停止や変更のあと、その人やその取引先のアカウントで新しい操作が記録されていないかを操作ログで見る</li></ol>

ロールそのものを整理するときは、製品の仕様にも注意が要ります。
Adobe Commerce B2Bでは、ユーザーが割り当てられているロールは削除できず、ユーザーのロールは会社ユーザーの編集画面で変更します⁴。
つまり、使わなくなったロールを片付けるには、先にそのロールのユーザーを別のロールへ移す必要があります。
他の製品についても、ロールの変更がすでに割り当てられた人へすぐ反映されるのか、作り直しが要るのかを事前に確かめておけば、見直しの手間を見積もりやすくなります。

▼ 図の内容を文字で読む

1. 入退社・異動の連絡を受発注システムの管理者にも届ける
2. 異動では新しいロールを付ける前に前の業務のロールを外す
3. 退職では退職日にアカウントの停止を確かめ、確かめた日を記録する
4. 取引先には担当者の交代を知らせてもらい、取引終了で自社側のユーザーを止める
5. 停止や変更のあと、操作ログで新しい操作が記録されていないかを見る

導入済みシステムの機能で足りないときの代替策と、製品仕様の確かめ方

運用で補う方法

一覧と製品の権限項目を対応させていくと、対応する項目のない行が残ることがあります。
登録者と承認者を分けられない、取引先ごとに価格の見え方を分けられない、変更の履歴が残らない、といった行です。
製品を替えるかどうかを決める前に、業務の手順で補えるかを考えます。

承認の機能がない場合は、承認を別の手順で行う方法があります。
たとえば、一定の条件に当たる注文は、システム上で確定する前に上長が内容を確認し、確認したことを社内の記録に残す決まりにします。
ただし、システムが確定を止めてくれるわけではないため、確認を飛ばしても登録はできてしまいます。
そこで、確認の記録と確定済みの注文をあとから突き合わせる担当を決めておきます。
この担当がいないと、手順は形だけになります。

取引先ごとの見え方を分けられない場合は、見せる情報の側を変える方法が考えられます。
取引先ごとに違う単価はシステムに載せずに別の経路で伝える方法や、取引先単位で閲覧できる帳票を分ける方法などです。
どちらも手作業が増えます。
取引先の数が増えても回り続けるかどうかは、小さく試してから広げるほうが確かめやすくなります。

ここで挙げた補い方は、効果を検証済みのものではありません。
誰が何を確認するかを決めたうえで、一定期間試してみます。
そのあいだに、承認待ちで注文が滞らないか、記録やログで経緯をあとからたどれるかを見て、続けるかどうかを判断します。

ベンダーに確認する4項目

製品で何ができるかは、ベンダーへの問い合わせで確かめるのが確実です。
ただ、「権限設定はできますか」と聞いても、「できます」という答えだけで終わりやすく、判断の材料になりません。
最初の一覧を手元に置き、次の4項目を具体的に聞きます。

<ul><li>ロールの数と粒度：ロールをいくつまで作れるか、注文の登録・承認・変更・取消・確認・閲覧を別々に許可できるか</li><li>金額・取引先・拠点による制限：金額で承認を分けられるか、取引先や拠点ごとに操作や閲覧の範囲を絞れるか</li><li>取引先アカウントの管理者：取引先側でユーザーを追加できるか、その場合に自社が範囲の上限を決められるか</li><li>操作ログ：どの操作が記録されるか、変更前の内容が残るか、誰が見られるか</li></ul>

回答を受け取ったら、一覧の各行に当てはめます。
製品の設定でできる行、運用で補う行、どちらでも難しい行に分けると、製品を替えるべきか、いまの製品のまま手順を整えるべきかの判断材料になります。

設定の方法による違いにも注意が要ります。
Adobe Commerce B2Bでは、管理画面で親の権限を変えると、その下の権限にも変更が及びます⁵。
一方、APIで設定する場合は、各権限を個別に指定する必要があります⁵。
画面からの設定と、他のシステムからの一括設定とで結果が変わりうるなら、取引先のユーザーをまとめて登録する前に確かめておく価値があります。

ここまでに挙げた製品の例は、権限をここまで細かく分けられる製品もある、という参考にとどまります。
自社のシステムでどこまでできるかは、自社製品の仕様書とベンダーの回答で判断します。

▼ 図の内容を文字で読む

• 製品の設定でできる行
  • 権限項目と一覧の操作を一つずつ対応させる
• 運用で補う行
  • 確認の記録と確定済みの注文を突き合わせる担当を決める
  • 取引先ごとに閲覧できる帳票を分けるなど、小さく試す
• どちらでも難しい行
  • 製品を替えるかどうかの判断材料にする

注文の流れと見せる情報の一覧は自社で作れます。ただ、それを自社製品のどの設定に当てはめ、どこを業務の手順で補うかは、製品の仕様と業務の両方を見ないと決めにくい部分です。

作成中の一覧をもとに、どの行を製品の設定で分けられそうか、どの行に運用の手順や追加の確認が必要かを整理する際の論点を確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
権限の土台	注文の流れ（登録・承認・変更・取消・確認・閲覧）と見せる情報の一覧
操作の分け方	登録した人が自分で承認しない。確定後の変更・取消は承認をやり直す
付け方の既定	何もできない状態から、必要な操作だけを足す
取引先	その取引先自身の取引に必要な最小の範囲から始め、範囲の上限は自社が決める
細かさ	少数のロールから始め、防げない場面にだけ金額別の承認や取引先・拠点別の制限を足す
支える仕組み	認証で本人を確かめ、操作ログで経緯をたどる
見直し	入社・異動・退職・取引先の変更のたびに、ロール単位で付け外しする
製品の確認	ロールの数と粒度、金額・取引先・拠点の制限、取引先アカウントの管理者、操作ログ

権限は一度決めて終わりではありません。取引先の追加や担当者の交代のたびに、新しい判断が出てきます。 見直しの節目ごとの手順や、ベンダーへの確認項目が自社の状況に足りているかを確かめられます。

よくある質問

取引先のユーザーを追加できる人は、自社の誰に限るべきか

自社側で取引先のユーザーを追加できる人は、取引先管理の責任者など少数に絞り、追加を申し出る人と実際に設定する人を分けておくと、誰がなぜ追加したかを説明しやすくなります。
取引先側の管理者にユーザーの追加を任せる場合でも、そのユーザーが見られる価格や注文の範囲の上限は、自社が決めておきます。
取引先側の管理者がどこまで権限を組み合わせられるかは、製品によって違います。

承認者が不在のとき、注文を止めずに済ませる方法はあるか

代わりに承認できる人を、あらかじめ承認のロールに含めておく方法があります。
このとき、代理の承認者が登録者本人にならないようにします。
また、金額によって承認を分けられる製品なら、受け止められる損失の範囲の少額の注文を自動承認にすれば、承認待ちで止まる注文を減らせます⁶。
代理承認の機能があるかどうかは、製品の仕様で確かめてください。

退職者のアカウントは、いつまでに停止を確認すればよいか

この記事では、退職日にアカウントが停止されたことを管理者が確かめ、その日付を記録する方法を提案しています。
停止が遅れた日数のぶんだけ、本人や他人がそのアカウントを使える余地が残るためです。
業務の引き継ぎで必要な場合も、アカウントを残すのではなく、後任者のロールを付け替えて対応します。

小規模で担当者が数人でも、役割を分ける必要はあるか

数人でも、登録した人とは別の人が承認すれば、入力の誤りに本人以外が気づく機会ができます。
ただし、全員が兼務している体制で全件に承認を求めると、注文が止まりやすくなります。
その場合は、高額の注文だけ承認を求める、操作ログを定期的に見返す、といった形で負担を抑えます。
IPAの中小企業向けガイドラインも、小規模事業者を含む中小企業での利用を想定しています³。

取引先ごとに価格を見せ分けられない製品では、どう運用で補うか

取引先ごとに違う単価はシステムに載せずに別の経路で伝える方法や、取引先単位で閲覧できる帳票を分ける方法が考えられます。
どちらも手作業が増えるため、取引先の数が増えても回るかどうかを小さく試してから広げます。
手作業で伝えた価格とシステム上の注文の金額を、誰が突き合わせるかも決めておきます。

権限の見直しは、誰が・どの資料で行えばよいか

資料は二つあると進めやすくなります。
一つは、注文の流れと見せる情報の一覧です。
もう一つは、製品から取り出せるユーザーとロールの割当ての一覧です。
システムの管理者だけでは業務上その権限が必要かどうかを判断しにくいため、受発注業務の責任者も照合に加わります。
取引先のユーザーについては、取引先管理の責任者が確認します。

1. 1　出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026」（2026年）
2. 2　出典：独立行政法人情報処理推進機構（IPA）「組織における内部不正防止ガイドライン」第5版（2022年）
3. 3　出典：独立行政法人情報処理推進機構（IPA）「中小企業の情報セキュリティ対策ガイドライン」第4.0版（2026年）
4. 4　出典：Adobe「Company Roles and Permissions（Adobe Commerce B2B）」（2026年閲覧）
5. 5　出典：Adobe「Manage company roles（Adobe Commerce B2B REST API）」（2026年閲覧）
6. 6　出典：Adobe「発注書（B2B チュートリアル）」（2026年閲覧）