BtoB ECの権限・アカウント管理｜設計の要点

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

B2B EC-COLUMN

BtoB ECの権限・アカウント管理とは — 誰が・何を・どこまで・いつまで扱えるかを定める仕組み

BtoB ECの権限・アカウント管理とは、取引先企業の担当者と自社の運用者それぞれに、どの機能を、どのデータの範囲まで、いつまで使ってよいかを役割ごとに定めて運用する仕組みです。個人情報保護法が求める安全管理措置とも関わります^*1。

BtoB EC導入の進め方全体を確認したい場合は、導入の進め方に関する記事もあわせてご確認ください。

BtoB ECで管理が難しくなる3つの理由

一般消費者向けのECと異なり、BtoB ECでは1つの取引先の中に発注する人・承認する人・支払を確認する人が並存します。加えて、自社は取引先の人事異動や退職を把握できません。

さらに、扱うデータには取引先担当者の個人データと、注文や見積といった証憑データの両方が含まれます。この3点が、権限設計をBtoC向けEC以上に複雑にする理由です。

権限設計は法令が求める安全管理措置でもある

個人情報保護法第23条は、個人情報取扱事業者に対し、個人データの漏えい・滅失・毀損の防止その他の安全管理のために必要かつ適切な措置を講じるよう義務づけています^*1。第24条は従業者への監督を、第25条は委託先の監督を、それぞれ求めています^*1。

個人情報保護委員会のガイドライン（通則編）は、技術的安全管理措置として「担当者及び取り扱う個人情報データベース等の範囲を限定するために、適切なアクセス制御を行わなければならない」と定めています^*2。権限設計は機能の設定であると同時に、この要求に応える作業でもあります。

多要素認証やシングルサインオンなどの認証方式、外部からの攻撃への対策は、BtoB ECのセキュリティ対策に関する記事で扱っています。

設計の全体像は5ステップ — 対象の洗い出しから記録・見直しまで

権限・アカウント管理の設計は、大きく5つのステップに分けて進めます。守る対象を洗い出し、役割を定義し、権限マトリクスを作り、アカウントのライフサイクルを決め、最後に記録して見直すという順序です。

ステップ1では、価格・在庫・取引履歴・請求データ・取引先担当者の情報など、守るべき対象を洗い出します。ステップ2では、取引先側と自社側の二層に分けて役割を定義します。

ステップ3では、役割・機能・データ範囲を組み合わせた権限マトリクスを作成します。ステップ4ではアカウントの発行から失効までのライフサイクルを、ステップ5では記録の残し方と見直しの頻度を決めます。

次章以降では、ステップ2（役割の定義）を第3章と第4章で、ステップ3（権限マトリクス）を第5章で、ステップ4（ライフサイクル）を第6章で、ステップ5（記録と見直し）を第7章で、それぞれ実務の観点から扱います。

取引先企業の中の権限は、まず4つのロールから組み立てる

会員登録の審査や公開範囲の設計は、クローズドEC・会員制ECの構築に関する記事で扱っています。本章では、登録後のアカウントにどんな権限を載せるかを扱います。

取引先企業の中の権限設計は、部門構成の実態から積み上げるのではなく、まず最小構成のロールを決めることから始めます。

最小構成は「発注する人・承認する人・支払を見る人・見るだけの人」の4つ

発注担当者・承認者・経理担当・閲覧のみという4つのロールが、取引先側の最小構成です。取引先の組織が小さい場合は、この4ロールをそのまま担当者に割り当てれば足ります。

部門・支店をどう表現するか

1つの法人が複数の部門・拠点を持つ場合、1法人＝1アカウント群では足りません。部門・拠点ごとにロールの組を用意し、上位の管理者ロールが全体を横断して閲覧できる構成にします。

見せる／見せないの線引き

単価・在庫数・他部門の注文履歴・請求書は、見せる範囲を役割ごとに切り分けるべき代表的な項目です。取引先ごとの単価出し分けを実装する具体的な方法は、別記事で扱っています。

承認できる人を権限として定義する

承認フローの段階数や金額の閾値をどう設計するかは別のテーマですが、その各段で誰が承認ボタンを押せるかを権限として定義するのは本テーマの範囲です。承認フローの設計そのものは、別記事で解説しています。

自社側の運用者権限は、内部不正防止ガイドラインが根拠になる

取引先側の権限を整理できても、自社側の運用者権限が緩ければ、権限設計全体の意味が薄れます。自社側の設計は、独立行政法人情報処理推進機構（IPA）のガイドラインが根拠になります^*4。

受注・出荷・マスタ管理・システム管理の4ロールに分ける

自社側の運用者は、受注担当・出荷担当・マスタ管理者・システム管理者の4つに分けて権限を割り当てます。取引先側と同じく、個人単位ではなくロール単位で権限を管理します。

重要情報へのアクセス権限は必要最小限にする

IPA「組織における内部不正防止ガイドライン」第5版は、アクセス権指定の項目で「重要情報へのアクセス権限を付与すべき者を必要最小限とします」と定めています^*4。異動・退職で不要になったIDとアクセス権は、ただちに削除する必要があるとも明記されています^*4。

システム管理者に権限を集中させない

同ガイドラインは、システム管理者の権限管理として「1人のシステム管理者に権限が集中しないように権限を分散します」と述べています^*4。特権を必要とする操作以外では、特権を用いて操作を行わないことも求めています^*4。

内部不正は継続的な脅威として位置づけられている

IPA「情報セキュリティ10大脅威2026」の組織編では、「内部不正による情報漏えい等」が7位に選出され、11年連続11回目の選出となっています^*3。外部からの攻撃だけでなく、権限設計そのものが内部統制の一部であることを示す結果です。

自社の商習慣に合わせてロールと権限範囲を具体的に洗い出すには、自社の数字で確かめるのが近道です。無料相談で要件を整理することもご検討ください。

権限マトリクスは、ロール×機能×データ範囲の表で作る

役割を決めたら、次に権限マトリクスを作ります。縦軸にロール、横軸に閲覧・登録・承認・出力などの機能を置き、セルにデータ範囲を書き込む形式です。

表1　権限マトリクスの記入例（取引先側の最小構成4ロール）

個人ではなくロールに権限を割り当てる

権限は担当者個人ではなく、ロールに割り当てます。この考え方はロールベースアクセス制御（RBAC、役割ごとに操作権限をまとめて管理する方式）と呼ばれ、IPAのガイドラインでも触れられています^*4。個人単位で例外を作ると、退職時に権限を洗い出す手間が増えます。

細かくしすぎないための基準

権限は際限なく細分化できますが、ロールが増えるほど運用の負荷も増えます。例外的な権限が必要になった場合は、ロールを新設する前に、承認を1段挟むことで対応できないかを検討します。

設計時に決めておくと後で救われる項目

データ範囲の既定値、権限の継承ルール、代理設定の可否は、稼働後に追加すると影響範囲の調査に時間がかかります。要件定義の段階で決めておくことが望ましい項目です。

アカウントのライフサイクルは、取引先の退職者にどう対応するかが核心

権限マトリクスを作っても、アカウントを発行したまま放置すれば意味を持ちません。ライフサイクル管理の核心は、取引先の担当者が退職・異動した後の対応です。

原則は「不要になったIDと権限をただちに削除」

IPAのガイドラインは「異動又は退職により不要となった利用者ID及びアクセス権は、ただちに削除しなければならない」と定めています^*4。この原則自体は、権限設計の基本といえます。

BtoB ECではこの原則がそのまま成り立たない

この原則は自社の従業員には適用できますが、取引先企業の担当者には単純に当てはまりません。取引先の中で誰が異動し、誰が退職したかを、売り手は通常知らされないためです。

設計で吸収する3つの手立て

アカウントを共有してはいけない理由

営業所で1つのIDを共有したいという要望は、現場から出やすいものです。不正アクセス行為の禁止等に関する法律第5条は「何人も、業務その他正当な理由による場合を除いては、アクセス制御機能に係る他人の識別符号を、当該アクセス制御機能に係るアクセス管理者及び当該識別符号に係る利用権者以外の者に提供してはならない」と定めています^*5。

この条文には「業務その他正当な理由による場合を除いては」という留保があり、ID共有が一律に禁止されるわけではありません。ただし実務上は、IDを共有すると誰が発注したかの証跡が残らず、誤発注の原因追跡や権限の見直しができなくなります。営業所からの共有IDの要望には、発注者ロールを人数分発行し、承認を1名に集約する設計が現実的です。

記録と証憑データの訂正・削除権限は、電子帳簿保存法の要求と一致させる

権限設計の最後のステップは、記録を残し、定期的に見直す仕組みです。何を記録するかに加え、証憑データを誰が訂正・削除できるかも、この段階で決めておく必要があります。

何を記録するか

ログイン・発注・承認・マスタ変更・権限変更の5つは、最低限記録しておきたい操作です。誰が・いつ・何をしたかを追跡できる状態にしておくことが、内部統制の土台になります。

注文・見積データを誰が訂正・削除できるか

電子帳簿保存法上、電子取引データは規則第4条の要件を満たして保存する必要があります^*6。改ざん防止措置の一つとして、「正当な理由がない訂正及び削除の防止に関する事務処理規程」を定めて備え付け、規程に沿って運用する方法が示されています^*6。

規程で訂正・削除できる者を定める以上、システムの権限設定と規程の記載を一致させる必要があります。規程では削除・訂正の担当者を限定していても、システム側では誰でも削除できる状態になっている、という不一致は避けなければなりません。

定期見直しの回し方

棚卸しの頻度は、少なくとも年1回に加え、組織変更や取引先の入れ替わりのタイミングで実施します。見直した結果は、いつ・誰が・何を確認したかを記録に残します。

参考にできる規格

JIS Q 27002:2024は、アクセス制御に関する管理策を含む情報セキュリティの規格です^*7。米国国立標準技術研究所（NIST）のSP 800-207は、所在地に基づく暗黙の信頼を与えず、アクセスは必要最小限の権限で要求ごとに判断するという、ゼロトラストの考え方を示しています^*8。いずれも日本の法令そのものではありませんが、権限設計の参照先になります。

内製と外部依頼の違い

権限設計を自社だけで内製するには、個人情報保護法などの法令知識、要件定義の経験、システム管理の知識を一体で持つ人材が必要になります。これらを社内で揃えにくい場合、要件定義の段階から外部の専門パートナーに相談することで、自社の商習慣に沿った権限モデルへ落とし込みやすくなります。

まとめ：BtoB EC権限設計の3つの判断軸

本稿では、BtoB ECの権限・アカウント管理を5つのステップに分けて整理しました。要点を3つに集約すると、次の通りです。第一に、取引先企業の中の権限と自社側の運用者権限は、二層に分けて別々に設計する必要があります^*4。第二に、取引先の退職者アカウントへの対応は、委譲・自動失効・棚卸しという3つの手立てで吸収します^*4。第三に、権限設計は法令が求める安全管理措置や改ざん防止措置とも一致させる必要があります^*1*6。権限モデルは後から変更できますが、データ移行や運用調整を伴うことがあるため、要件定義の段階で洗い出しておくことが大切です。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

BtoB ECのアカウントは、取引先1社につき1つでよいのですか。

1社1アカウントでは足りません。取引先企業の中には発注する人・承認する人・支払を確認する人が並存するため、担当者ごとにロールを分けたアカウント設計が必要です^*1。

取引先の担当者が退職したことを、売り手はどうやって知ればよいのですか。

原則として自動的には分かりません。取引先側の管理者にアカウント発行・停止の権限を委ねる、最終ログイン日で自動失効させる、定期的に棚卸しをするという3つの手立てで吸収します^*4。

1つのIDを部署内で共有してもよいのですか。

業務その他正当な理由による場合を除いては、避けるべきです。不正アクセス禁止法第5条は識別符号の提供を制限しており^*5、共有すると誰が発注したかの証跡が残らなくなります。

権限（ロール）はいくつくらいに分けるのが適切ですか。

本記事では、取引先側・自社側とも最小構成として4つのロールを示しています。ロールベースアクセス制御の考え方に沿い、個人単位の例外を増やさないことが、細分化を止める基準になります^*4。

稼働後に権限の設計を変更することはできますか。

変更は可能です。ただし、ロールの再設計はデータ移行や運用調整を伴うことがあるため、要件定義の段階で洗い出しておくことが望ましいといえます。

1. *1　出典：e-Gov法令検索（デジタル庁）「個人情報の保護に関する法律」第23条（安全管理措置）・第24条（従業者の監督）・第25条（委託先の監督）（https://laws.e-gov.go.jp/law/415AC0000000057）
2. *2　出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」平成28年11月（令和8年6月一部改正）
3. *3　出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威2026」（組織編・2026年1月29日公開・2026年5月21日更新）
4. *4　出典：独立行政法人情報処理推進機構（IPA）「組織における内部不正防止ガイドライン」第5版（2022年4月）
5. *5　出典：e-Gov法令検索（デジタル庁）「不正アクセス行為の禁止等に関する法律」第5条（https://laws.e-gov.go.jp/law/411AC0000000128）
6. *6　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和8年7月）
7. *7　出典：一般財団法人日本規格協会「JIS Q 27002:2024」（2024年6月20日改正）
8. *8　出典：NIST（米国国立標準技術研究所）「NIST SP 800-207 Zero Trust Architecture」（2020年8月）