はじめに
前回（Part 1）では、モバイルアプリの業界標準に基づいた権限制御の考え方を紹介しました。
今回は、それを支える RBAC（Role-Based Access Control）モデルのデータベース設計とER図 を具体的に解説します。
RBAC モデルとは？
RBAC は次の構成要素で成り立っています：
- ユーザー（users）
- ロール（roles）
- 権限（permissions）
- ユーザーロール対応（user_roles）
- ロール権限対応（role_permissions）
さらに柔軟な運用のため、以下も導入可能です：
- ユーザー個別権限（user_permissions）
- 権限の階層（parent_id によるツリー構造）
テーブル構成
users（ユーザー）
| カラム名 | 型 | 説明 |
|---|---|---|
| id | UUID | 主キー |
| username | VARCHAR | ログイン名 |
| password | VARCHAR | パスワード（ハッシュ） |
| status | TINYINT | 有効/無効 |
| created_at | DATETIME | 作成日時 |
roles（ロール）
| カラム名 | 型 | 説明 |
|---|---|---|
| id | UUID | 主キー |
| name | VARCHAR | ロール名 |
| code | VARCHAR | ロールコード（adminなど） |
| description | TEXT | 説明文 |
| created_at | DATETIME | 作成日時 |
permissions（権限）
| カラム名 | 型 | 説明 |
|---|---|---|
| id | UUID | 主キー |
| code | VARCHAR | 権限コード（例：user:view） |
| name | VARCHAR | 権限名 |
| type | ENUM |
menu, button, api 等 |
| parent_id | UUID | 親権限ID（メニュー階層用） |
| path | VARCHAR | メニューのパス |
| method | VARCHAR | HTTPメソッド（API用） |
| created_at | DATETIME | 作成日時 |
中間テーブル
user_roles
| カラム名 | 型 | 説明 |
|---|---|---|
| user_id | UUID | 外部キー |
| role_id | UUID | 外部キー |
| created_at | DATETIME | 登録日 |
role_permissions
| カラム名 | 型 | 説明 |
|---|---|---|
| role_id | UUID | 外部キー |
| permission_id | UUID | 外部キー |
| created_at | DATETIME | 登録日 |
user_permissions（任意）
| カラム名 | 型 | 説明 |
|---|---|---|
| user_id | UUID | 外部キー |
| permission_id | UUID | 外部キー |
| scope | VARCHAR |
project:123 など範囲指定 |
| created_at | DATETIME | 登録日 |
ER図（Mermaid）
サンプルデータ設計のポイント
permissions.code は前後端で統一すべき識別子
type により、画面 / ボタン / API の判定を柔軟に
parent_id により、メニューの階層化も可能
user_permissions により「特例付与」や「個別スコープ制限」が可能
こんな使い方ができます
| 画面 | 判定キー例 | 説明 |
|---|---|---|
| ユーザー一覧画面 | user:view |
見えるかどうか |
| 編集ボタン | user:edit |
押せるかどうか |
| 削除API | user:delete |
実行できるかどうか |
シリーズリスト
Flutterで作る安全な権限制御【Part 1】業界標準と設計指針のすべて
Flutterで作る安全な権限制御【Part 2】RBACを支えるデータベース設計とER図（Mermaid付き）
Flutterで作る安全な権限制御【Part 3】ページとボタンを権限で制御する実装編（go_router × Riverpod）
Flutterで作る安全な権限制御【Part 4】Flutterアプリの反編譯リスクとセキュリティ対策
Security Flutter obfuscation