業務システムを開発するとき、意外と難しいのが「誰が、どの情報を、どこまで操作できるようにするか」という権限設計です。
例えば顧客管理システムでも、
- 営業担当者は自分の顧客だけ編集できる
- 営業部長は部署全体の顧客を閲覧できる
- 経理担当者は請求情報だけ確認できる
- システム管理者はユーザーや権限を変更できる
といった違いがあります。
こうした権限を管理する代表的な考え方が、RBAC（Role-Based Access Control：ロールベースアクセス制御）です。
RBACでは、ユーザー一人ひとりに直接権限を設定するのではなく、
ユーザー
↓
ロール
↓
権限
という構造でアクセス制御を設計します。
例えば「営業担当」というロールに「顧客の閲覧・登録・編集」という権限を設定し、営業担当者へそのロールを割り当てます。
結論からいうと、RBAC設計で重要なのは、単に「管理者・一般ユーザー」というロールを作ることではありません。
業務上の役割を整理し、必要最小限の権限をロールへ割り当て、将来的に運用しやすい粒度で設計することが重要です。
この記事では、RBACの基本から、業務システムにおける具体的な設計手順、権限マトリクスの作り方、よくある失敗まで解説します。
RBACとは
RBACとは「Role-Based Access Control」の略で、日本語では「ロールベースアクセス制御」と呼ばれます。
ユーザーごとに個別の権限を設定するのではなく、「ロール」と呼ばれる役割に権限をまとめ、そのロールをユーザーへ割り当てる方式です。
例えば営業管理システムに、
- 営業担当
- 営業マネージャー
- 経理担当
- システム管理者
という4つのロールがあるとします。
営業担当ロールには、
- 顧客閲覧
- 顧客登録
- 顧客編集
- 案件登録
- 案件編集
という権限を設定します。
営業マネージャーロールには、
- 顧客閲覧
- 顧客登録
- 顧客編集
- 案件閲覧
- 案件編集
- 売上集計閲覧
などを設定します。
実際のユーザーには、
田中さん → 営業担当
佐藤さん → 営業担当
鈴木さん → 営業マネージャー
という形でロールを割り当てます。
この構造にすることで、ユーザーが増えても一人ずつ大量の権限を設定する必要がなくなります。
RBACの基本構造
RBACを理解するには、次の3つを分けて考えることが重要です。
ユーザー
システムを利用する人です。
例えば、
- 山田太郎
- 佐藤花子
- 鈴木一郎
など、実際の利用者を指します。
ロール
ユーザーが業務上どのような役割を持つかを表します。
例えば、
- 営業担当
- 営業マネージャー
- 経理担当
- 人事担当
- システム管理者
などです。
権限
システム上で実行できる操作です。
例えば、
- 顧客を閲覧する
- 顧客を登録する
- 顧客を編集する
- 顧客を削除する
- 請求情報を閲覧する
- ユーザーを管理する
などです。
基本構造は次のようになります。
ユーザー
↓
ロールを割り当てる
↓
ロール
↓
権限を割り当てる
↓
各機能を利用できる
この「ユーザーと権限を直接結び付けない」という点がRBACの重要な特徴です。
なぜ業務システムでRBACが必要なのか
小規模なシステムでは、
- 管理者
- 一般ユーザー
の2種類だけでも運用できることがあります。
しかし、利用者が増えたり、扱う情報が増えたりすると、それだけでは不十分になります。
例えば顧客管理システムで、一般ユーザー全員にすべての情報を見せてしまえば、
- 他部署の顧客情報
- 契約金額
- 利益率
- 個人情報
- 経営管理情報
まで閲覧できる可能性があります。
反対に、権限を厳しくしすぎると、
「必要な情報を毎回管理者に確認しなければならない」
という状態になり、業務効率が下がります。
権限設計では、
業務を行うために必要な権限を与えながら、不要な権限は与えない
というバランスが重要です。
この考え方は「最小権限の原則」と呼ばれます。
RBACを導入するメリット
RBACを適切に設計すると、主に4つのメリットがあります。
1．権限管理がしやすくなる
100人のユーザーへ、それぞれ10個の権限を直接設定すると管理が複雑になります。
RBACなら、
「営業担当」というロールを作り、
- 顧客閲覧
- 顧客登録
- 顧客編集
という権限を設定しておけば、営業担当者へ同じロールを割り当てるだけで済みます。
人事異動があった場合も、
営業担当
↓
営業マネージャー
のようにロールを変更することで対応できます。
2．権限設定ミスを減らしやすい
ユーザーごとに個別設定すると、
「Aさんにはこの権限を付けたが、Bさんには付け忘れた」
といった設定ミスが起きやすくなります。
RBACでは、同じ業務を担当するユーザーへ同じロールを割り当てられるため、権限のばらつきを抑えやすくなります。
3．組織変更に対応しやすい
部署異動や昇格が発生した場合も、ロールを変更することで権限を更新できます。
例えば、
営業担当
↓
営業部長
へ異動したときに、ユーザーへ付与された権限を一つずつ変更する必要がありません。
4．権限を説明しやすくなる
監査やセキュリティ確認の際にも、
「このユーザーには営業マネージャーロールが設定されているため、この権限を持っています」
と説明できます。
ユーザーごとにバラバラな設定を行うより、権限体系を把握しやすくなります。
RBAC設計で重要な「対象」と「操作」
RBACを設計するときは、「何に対して」「何ができるか」を分けて考えると整理しやすくなります。
例えば顧客管理の場合、
対象：
- 顧客
- 案件
- 見積
- 契約
- 請求
- ユーザー
操作：
- 閲覧
- 登録
- 編集
- 削除
- 承認
- 出力
という構造です。
権限名にすると、
- customer:read
- customer:create
- customer:update
- customer:delete
- invoice:read
- invoice:approve
- user:manage
といった形になります。
このように「対象 × 操作」で整理すると、後から機能が追加された場合も拡張しやすくなります。
RBACの設計方法を7ステップで解説
では、実際にRBACをどのように設計すればよいのでしょうか。
おすすめなのは、いきなりロール名を決めるのではなく、業務から順番に整理する方法です。
ステップ1．利用者を洗い出す
まず、システムを利用する人を整理します。
例えば営業管理システムなら、
- 営業担当
- 営業部長
- 経理担当
- 経営者
- システム管理者
などです。
ここでは、実際の個人名ではなく「業務上の役割」を洗い出します。
ステップ2．システム内の対象データを整理する
次に、システムで管理する情報を整理します。
例えば、
- 顧客
- 案件
- 見積
- 契約
- 売上
- 請求
- ユーザー
- マスターデータ
などです。
システムの機能一覧や画面一覧がある場合は、それを利用すると整理しやすくなります。
ステップ3．必要な操作を整理する
それぞれのデータに対して必要な操作を洗い出します。
一般的には、
- 閲覧
- 登録
- 編集
- 削除
があります。
CRUDと呼ばれる、
- Create：作成
- Read：参照
- Update：更新
- Delete：削除
を基本に考えると整理しやすいでしょう。
ただし業務システムでは、それだけでは足りない場合があります。
例えば、
- 承認
- 差し戻し
- CSV出力
- PDF出力
- インポート
- ステータス変更
- 請求確定
- 入金確定
など、業務固有の操作もあります。
ステップ4．権限マトリクスを作る
利用者と操作を整理したら、権限マトリクスを作ります。
例えば次のような形です。
| 機能 | 営業担当 | 営業部長 | 経理 | 管理者 |
|---|---|---|---|---|
| 顧客閲覧 | ○ | ○ | ○ | ○ |
| 顧客登録 | ○ | ○ | × | ○ |
| 顧客編集 | ○ | ○ | × | ○ |
| 顧客削除 | × | ○ | × | ○ |
| 案件閲覧 | ○ | ○ | △ | ○ |
| 見積作成 | ○ | ○ | × | ○ |
| 請求閲覧 | × | ○ | ○ | ○ |
| 請求確定 | × | × | ○ | ○ |
| ユーザー管理 | × | × | × | ○ |
この表を作ることで、
「誰が何をできるのか」
を関係者間で確認しやすくなります。
要件定義の段階で作っておくと、開発後の認識違いも減らせます。
ステップ5．ロールを定義する
権限マトリクスを基にロールを作ります。
例えば、
営業担当
- 顧客閲覧
- 顧客登録
- 顧客編集
- 案件閲覧
- 案件登録
- 案件編集
- 見積作成
営業部長
営業担当の権限に加えて、
- 部署全体の案件閲覧
- 顧客削除
- 売上集計閲覧
経理担当
- 顧客閲覧
- 契約閲覧
- 請求閲覧
- 請求編集
- 請求確定
- CSV出力
システム管理者
- ユーザー管理
- ロール管理
- マスター管理
- システム設定
などです。
ステップ6．ユーザーにロールを割り当てる
設計したロールを実際のユーザーへ割り当てます。
例えば、
山田さん → 営業担当
佐藤さん → 営業担当
鈴木さん → 営業部長
田中さん → 経理担当
という形です。
ここで重要なのが、「一人のユーザーが複数ロールを持てるか」を決めることです。
例えば小規模企業では、
「営業部長でありながらシステム管理者でもある」
ということがあります。
複数ロールを許可する場合は、権限をどのように統合するかも設計する必要があります。
ステップ7．運用ルールを決める
RBACは、システムを実装しただけでは完成しません。
運用ルールも重要です。
例えば、
- 誰がロールを変更できるのか
- 入社時に誰が権限を付与するのか
- 異動時に誰が変更するのか
- 退職時にいつ無効化するのか
- 定期的に権限を確認するのか
などです。
特に注意したいのが退職者や異動者の権限です。
昔の権限が残ったままになる「権限の棚卸し漏れ」は、セキュリティリスクにつながります。
RBAC設計の具体例｜顧客・案件管理システム
もう少し具体的に考えてみましょう。
次のような顧客・案件管理システムを想定します。
管理する情報
- 顧客
- 案件
- 見積
- 契約
- 請求
- ユーザー
利用者
- 営業担当
- 営業部長
- 経理担当
- 管理者
この場合、次のようなRBACを設計できます。
営業担当ロール
できること：
- 自分の顧客を閲覧
- 顧客を登録
- 自分の顧客を編集
- 自分の案件を登録・編集
- 見積を作成
できないこと：
- 請求確定
- ユーザー管理
- 他部署の案件削除
営業部長ロール
できること：
- 自部署の顧客を閲覧
- 自部署の案件を閲覧・編集
- 見積を承認
- 売上情報を閲覧
経理担当ロール
できること：
- 契約情報を閲覧
- 請求情報を作成
- 請求を確定
- 入金情報を登録
- 会計用CSVを出力
管理者ロール
できること：
- ユーザー管理
- ロール管理
- マスター管理
- システム設定
このように業務ごとに整理します。
RBACだけでは解決できない「データ範囲」の問題
RBAC設計でよくある誤解が、
「営業担当にはcustomer:readを付ければ完成」
と考えてしまうことです。
実際には、
「どの顧客を読めるのか」
まで考えなければならない場合があります。
例えば営業担当者にcustomer:read権限があっても、
- 全顧客を閲覧できる
- 自分の担当顧客だけ閲覧できる
- 自部署の顧客だけ閲覧できる
では意味が大きく異なります。
つまり、
「何ができるか」
だけではなく、
「どのデータに対してできるか」
というスコープの設計が必要です。
例えば、
営業担当
→ 自分の案件だけ
営業部長
→ 自部署の案件
経営者
→ 全社の案件
という違いです。
このような条件が増えると、単純なRBACだけでは表現しにくくなることがあります。
RBACとABACの違い
アクセス制御について調べていると、ABACという言葉も出てきます。
ABACは「Attribute-Based Access Control」の略で、ユーザーやデータなどの属性を利用してアクセスを判断する方式です。
RBACでは、
「営業部長だから閲覧できる」
という考え方です。
ABACでは、
「営業部に所属していて、対象案件の部署コードと一致しており、案件ステータスが進行中であれば編集できる」
というように、複数の属性を条件にできます。
簡単に比較すると次のようになります。
| 項目 | RBAC | ABAC |
|---|---|---|
| 判断基準 | ロール | 属性・条件 |
| 設計 | 比較的分かりやすい | 複雑になりやすい |
| 運用 | しやすい | 条件管理が必要 |
| 柔軟性 | 中程度 | 高い |
| 向いているケース | 一般的な社内システム | 条件が複雑なアクセス制御 |
多くの業務システムでは、まずRBACを基本として設計し、必要な部分だけ条件を追加する方法が分かりやすいでしょう。
RBAC設計でよくある失敗
RBACは仕組み自体はシンプルですが、設計を誤ると運用が複雑になります。
1．「管理者」と「一般ユーザー」しか作らない
最初は簡単でも、利用部署が増えると権限が不足します。
例えば、
一般ユーザー
という1つのロールでは、
- 営業
- 経理
- 人事
- マネージャー
の違いを表現できません。
実際の業務上の役割に合わせて設計することが重要です。
2．ユーザーごとに例外権限を追加する
RBACを採用しているにもかかわらず、
「山田さんだけこの権限を追加」
「佐藤さんだけ削除権限を追加」
という個別設定が増えることがあります。
これを続けると、最終的に誰が何をできるのか分からなくなります。
例外が増えた場合は、
「新しいロールが必要なのではないか」
と見直すことが重要です。
3．ロールを細かく作りすぎる
逆に、
- 営業A
- 営業B
- 営業C
- 営業東京
- 営業東京リーダー
- 営業東京リーダー代理
のようにロールを大量に作ると管理が難しくなります。
「ロール爆発」と呼ばれるような状態にならないよう、役割とデータ範囲を分けて設計できないか検討しましょう。
4．画面表示だけでアクセス制御する
非常に重要なのがこの点です。
例えば、
「削除ボタンを画面から隠したので削除できない」
だけでは十分ではありません。
APIへ直接リクエストすれば削除できる状態であれば、アクセス制御として不十分です。
権限チェックは、
フロントエンド
＋
バックエンド
の両方を考える必要があります。
特に重要な処理は、必ずサーバー側で認可を確認する設計が必要です。
5．退職・異動時の運用を考えていない
RBACは導入時だけでなく、運用が重要です。
例えば、
営業部
↓
人事部
へ異動したのに営業ロールが残っていれば、不要な顧客情報を閲覧できてしまいます。
そのため、
- 入社
- 異動
- 昇格
- 休職
- 退職
など、人事イベントと権限変更を連動させる必要があります。
【コピペ用】RBAC設計チェックリスト
業務システムのRBACを設計するときは、次の項目を確認してみてください。
利用者
- システムを使う部署：
- 利用する役職：
- 外部ユーザーの有無：
- 管理者の種類：
管理対象
- 顧客：
- 案件：
- 契約：
- 請求：
- 個人情報：
- マスターデータ：
- その他：
必要な操作
- 閲覧：
- 登録：
- 編集：
- 削除：
- 承認：
- CSV出力：
- 帳票出力：
- インポート：
- その他：
データ範囲
- 自分のデータのみ：
- 自部署：
- 自拠点：
- 全社：
- 特定条件のデータ：
運用
- ロールを付与する担当者：
- 異動時の変更担当：
- 退職時の無効化方法：
- 定期的な権限確認：
- 操作ログの保存：
これらを整理すると、必要なロールと権限が見えやすくなります。
RBACのデータベース設計はどう考える？
Webシステムとして実装する場合、RBACは一般的に複数のテーブルで管理します。
代表的には、
- users
- roles
- permissions
- user_roles
- role_permissions
という構造です。
例えば、
users
→ ユーザー情報
roles
→ 営業担当、経理、管理者など
permissions
→ customer:read、customer:updateなど
user_roles
→ どのユーザーがどのロールを持っているか
role_permissions
→ どのロールがどの権限を持っているか
を管理します。
ユーザーとロール、ロールと権限を中間テーブルで結び付けることで、複数ロールや複数権限にも対応しやすくなります。
ただし、実際のデータベース設計はシステム規模や要件によって異なります。
単純なシステムで過剰に複雑な権限モデルを導入すると、逆に保守しにくくなるため注意が必要です。
権限は画面単位ではなく業務操作単位でも考える
権限設計では、
「顧客画面を表示できる」
だけで考えると不足する場合があります。
例えば顧客画面の中に、
- 基本情報を見る
- 基本情報を変更する
- 契約金額を見る
- 個人情報を見る
- CSVを出力する
- 顧客を削除する
という複数の操作があります。
そのため、
「画面を見られるか」
だけではなく、
「その画面で何をできるか」
まで整理することが重要です。
特に個人情報や金額情報を扱う業務システムでは、より慎重な設計が必要です。
RBAC設計は要件定義の段階で行う
権限設計を開発終盤まで後回しにすると、大きな手戻りにつながる場合があります。
例えば開発後に、
「営業担当者は自分の案件だけ見られるようにしてください」
という要件が追加されたとします。
すでにすべての案件を取得する前提で、
- API
- SQL
- 画面
- CSV出力
- 集計処理
を実装していた場合、広い範囲の修正が必要になる可能性があります。
そのため、要件定義では最低でも、
- 誰が利用するか
- 何を閲覧できるか
- 何を変更できるか
- どの範囲のデータを扱えるか
を整理しておくことが重要です。
RBACに関するよくある質問
RBACとは簡単にいうと何ですか？
ユーザーの「役割」に応じてアクセス権限を管理する方式です。
例えば「営業担当」という役割に顧客閲覧・編集権限を設定し、営業担当者へその役割を割り当てます。
RBACのロールは役職と同じですか？
必ずしも同じではありません。
役職ではなく、システム上の業務責任を基準にすることが重要です。
例えば同じ「課長」でも、営業部と経理部では必要な権限が異なるため、別ロールになることがあります。
一人に複数のロールを設定してもよいですか？
システムの要件によりますが、複数ロールを許可する設計は一般的に可能です。
ただし、複数ロールを持った場合の権限統合ルールを明確にしておく必要があります。
RBACだけで部署ごとの閲覧制限もできますか？
単純なロールだけでは、「営業担当は自分の案件だけ」という条件を十分表現できないことがあります。
ロールに加えて、担当者ID、部署ID、拠点IDなどを利用したデータスコープ制御を組み合わせる方法があります。
管理者にはすべての権限を持たせてもよいですか？
システムによります。
システム管理者と業務管理者を分離したほうがよいケースもあります。
例えば、ユーザー設定は変更できても顧客の機密情報までは閲覧できない管理者を設ける、といった設計です。
RBACは小規模なシステムにも必要ですか？
ユーザーが数人しかおらず、全員が同じ操作をするのであれば、複雑なRBACは不要な場合があります。
ただし、将来的な利用者増加や部署展開が想定される場合は、最初から一定の拡張性を持たせておく方法もあります。
hiro-dev-labではRBACを含む業務システムの権限設計から相談できます
業務システムでは、画面や機能だけでなく、
「誰が、何を、どこまで操作できるのか」
を正しく設計することが重要です。
特に、
- 顧客情報
- 従業員情報
- 契約情報
- 請求情報
- 売上情報
- 個人情報
などを扱うシステムでは、権限設計がシステム全体の安全性や使いやすさに影響します。
hiro-dev-labでは、業務システム・Webシステム開発の観点から、
- 現在の業務フローの整理
- 利用者・部署・役職の整理
- 要求整理
- 要件定義
- RBAC・権限設計
- 権限マトリクスの作成
- 画面一覧・機能一覧の整理
- データベース設計
- API設計
- Webシステム開発
など、必要な段階から相談できます。
「管理者と一般ユーザー以外にどんな権限が必要か分からない」
「部署・役職・担当者ごとの閲覧範囲をどう設計すればよいか迷っている」
「既存システムの権限が複雑になりすぎている」
といった段階でも、まず現在の業務と利用者を整理することで適切な権限モデルが見えてきます。
RBAC設計では、ロールを増やすこと自体が目的ではありません。
業務に必要な権限を整理し、必要最小限のアクセスを、分かりやすく継続的に管理できる仕組みを作ることが重要です。