RBAC（ロールベースアクセス制御）とは
RBAC（ロールベースアクセス制御）とは、システムの利用者一人ひとりに直接権限を設定するのではなく、「管理者」「承認者」「一般スタッフ」といった役割（ロール）に権限をまとめ、そのロールを利用者に割り当てることで、誰が何をできるかを管理する方式です。
平易に言えば「肩書きごとに持てる鍵束を決めておく」やり方です。新しく人が入ったら、その人に合う鍵束を渡すだけで済みます。異動のときは鍵束を取り替えます。
英語の Role-Based Access Control の頭文字で、「アールバック」と読みます。
仕組み・ポイント
RBACは、利用者・ロール・権限の三つを分けて考えるのが基本です。
| 要素 | 意味 | 例 |
|---|---|---|
| 利用者 | システムにログインする人 | 営業部の佐藤さん（架空） |
| ロール | 業務上の役割 | 営業担当、営業マネージャー、経理、システム管理者 |
| 権限 | 操作の単位 | 顧客の閲覧、見積の作成、見積の承認、請求データの出力 |
権限は「対象（何に）」と「操作（何をする）」の組み合わせで定義すると整理しやすくなります。たとえば「見積」に対する「閲覧・作成・編集・削除・承認」といった具合です。これを表にしたものを権限マトリクスと呼び、設計時の打ち合わせ資料として非常に役立ちます。
権限マトリクスのイメージは次のようなものです（架空の例）。
| 権限 | 営業担当 | 営業マネージャー | 経理 |
|---|---|---|---|
| 見積の作成・編集 | できる | できる | できない |
| 見積の承認 | できない | できる | できない |
| 請求データの出力 | できない | 閲覧のみ | できる |
このように表で並べると、「経理は見積を見られなくてよいのか」「マネージャー不在時の承認は誰がするのか」といった、文章だけでは見落としがちな論点が浮かび上がります。
RBACだけでは表しにくいのが「自分の担当顧客だけ」「自部署のデータだけ」といった範囲の制限です。これはロールとは別に、データの所有者や所属部署で絞り込む条件を組み合わせて実現します。条件の種類が多くなる場合は、利用者や対象の属性で判定するABAC（属性ベースアクセス制御）の考え方を取り入れることもあります。
実務での使い方・具体例
ある卸売業の会社が、受発注と在庫を管理する社内の管理画面を作る場面を考えます。利用者は営業、倉庫、経理、役員の数十名です。
設計は次の順で進めます。
- 現場の業務を洗い出し、誰がどの画面で何をしているかを一覧にする
- 似た操作をする人をまとめてロールの候補を作る（多くても数種類から始める）
- ロール × 権限のマトリクスを作り、現場の責任者に確認してもらう
- 「承認は作成者本人にはさせない」など、業務ルールに由来する制約を書き出す
- 権限の変更履歴と、権限を使った重要操作を監査ログに残す
ここで大切なのは、ロールを組織図そのままにしないことです。部署名でロールを作ると、組織変更のたびにシステム側も直すことになります。「何をする人か」でロールを定義し、部署はデータの範囲を絞る条件として別に持つと、変化に強くなります。
社内の認証基盤とSSO（シングルサインオン）で連携している場合は、認証基盤のグループとロールを対応づけ、入社や異動の手続きだけで権限が切り替わるようにする設計もよく使われます。
よくある誤解と注意点
- ロールが増えすぎる：例外のたびに新しいロールを作ると、数十種類に膨れて誰も全体を把握できなくなります。例外は個別の追加権限として扱うなど、ルールを先に決めます。
- 画面を隠すだけでは制御にならない：ボタンを非表示にしても、APIを直接呼べば操作できてしまう作りは危険です。権限の判定は必ずサーバー側で行います。
- 最初から細かく作り込みすぎる：運用が始まる前に完璧な権限体系を作ろうとすると、使われない設定が増えます。少ないロールで始め、実際の運用を見て調整します。
- 全員を管理者にしてしまう：立ち上げ時に「とりあえず全員に管理者ロール」を渡すと、後から絞るときに業務が止まる心配から手を付けられなくなります。最初から必要最小限の権限で始める「最小権限」の原則を守ります。
- 棚卸しをしない：異動や退職で不要になった権限が残り続けるのはよくある問題です。定期的に利用者とロールの一覧を確認する運用を組み込みます。
関連用語
- 監査ログ：権限の変更や重要操作を記録し、後から追えるようにする仕組み
- SSO（シングルサインオン）：認証基盤のグループ情報をロールに結びつけることが多い
- マルチテナント：SaaSではテナント単位でロールを管理する
- ワークフローシステム：承認権限の設計がRBACと密接に関わる
- 実践記事：管理画面の権限設計：ロールと操作範囲を決める実務的な手順
Otsumuに相談できること
管理画面や業務システムの権限設計は、現場の業務と社内ルールを理解していないと決められません。業務の洗い出しから権限マトリクスの作成、運用しやすい権限管理画面の実装まで一緒に進めます。詳しくは管理画面開発をご覧ください。
「今の権限設定が複雑になりすぎて誰も分からない」といった見直しのご相談も、30分の無料相談でお受けしています。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01
この用語に関連する開発メニューは、認証・SSO・権限管理の開発です。
- ログインから権限まで一貫して設計
- 外部認証サービスの活用も中立に判断
- 組織・テナントの分け方を先に整理