Slide 1
Slide 1 text
「技術負債にならない‧間違えない」
権限管理の設計と実装
Kaigi on Rails 2025
@naro143（Yusuke Ishimi）
Slide 2
Slide 2 text
Yusuke Ishimi
2
株式会社プレックス
テックリード
@naro143 @naro143
Slide 3
Slide 3 text
持ち帰っていただきたいこと
● 権限管理の重要性とアンチパターンの理解
● 権限管理の要素を適切に分割することで技術負債と間違いが減らせる
● 具体的な実装例（今後の議論のきっかけになれば幸いです）
3
Slide 4
Slide 4 text
⽬次
● 権限管理の重要性
● よくある実装とアンチパターンと対処法
● 権限管理の要素の整理（Punditを例に）
● 要素を適切に分割したModuleの実装の解説
● 改善後の事業とサービスへの影響
4
ModuleのサンプルはGitHubで公開しています
Slide 5
Slide 5 text
権限管理
5
Slide 6
Slide 6 text
権限管理の例
● 運営アカウントだけ特殊なボタンが表⽰される
● 管理者アカウントだけメンバーを招待できる
● 追加プランの契約ユーザーだけ機能が増える
業務⽀援SaaSだと...
● 管理者アカウントだけお⾦の情報（契約⾦額や給与）が⾒れる
● 外部アカウント（業務委託）は担当のプロジェクトの情報だけ⾒れる（取引先は⾒れ
ない）
6
Slide 7
Slide 7 text
権限管理の例
● 運営アカウントだけ特殊なボタンが表⽰される
● 管理者アカウントだけメンバーを招待できる
● 追加プランの契約ユーザーだけ機能が増える
業務⽀援SaaSだと...
● 管理者アカウントだけお⾦の情報（契約⾦額や給与）が⾒れる
● 外部アカウント（業務委託）は担当のプロジェクトの情報だけ⾒れる
7
権限管理のミス
Slide 8
Slide 8 text
権限管理の例
● 運営アカウントだけ特殊なボタンが表⽰される
● 管理者アカウントだけメンバーを招待できる
● 追加プランの契約ユーザーだけ機能が増える
業務⽀援SaaSだと...
● 管理者アカウントだけお⾦の情報（契約⾦額や給与）が⾒れる
● 外部アカウント（業務委託）は担当のプロジェクトの情報だけ⾒れる
8
給与を公開しちゃった
取引先を公開しちゃった
Slide 9
Slide 9 text
権限管理の例
● 運営アカウントだけ特殊なボタンが表⽰される
● 管理者アカウントだけメンバーを招待できる
● 追加プランの契約ユーザーだけ機能が増える
業務⽀援SaaSだと...
● 管理者アカウントだけお⾦の情報（契約⾦額や給与）が⾒れる
● 外部アカウント（業務委託）は担当のプロジェクトの情報だけ⾒れる
9
サービスへの信頼が下がる
事業への損失が⼤きい
Slide 10
Slide 10 text
権限管理の例
● 運営アカウントだけ特殊なボタンが表⽰される
● 管理者アカウントだけメンバーを招待できる
● 追加プランの契約ユーザーだけ機能が増える
業務⽀援SaaSだと...
● 管理者アカウントだけお⾦の情報（契約⾦額や給与）が⾒れる
● 外部アカウント（業務委託）は担当のプロジェクトの情報だけ⾒れる
10
権限管理のミスは許されない
Slide 11
Slide 11 text
レビューする気持ちで⾒てください
11
Slide 12
Slide 12 text
よくある実装①
12
Slide 13
Slide 13 text
よくある実装②
13
Slide 14
Slide 14 text
よくある実装③
14
Slide 15
Slide 15 text
よくある実装③
15
なんだよ super_admin って...
Slide 16
Slide 16 text
よくある実装③
16
そもそも admin? の判定は
アンチパターン
Slide 17
Slide 17 text
役割は変わり⾏く
17
Slide 18
Slide 18 text
事業やサービスの変化
事業
● ターゲットとする市場（業種）の変化
● ターゲットとする企業規模の変化
● ターゲットとするユーザーの変化
サービス
● 提供する機能の変化
18
Slide 19
Slide 19 text
事業やサービスの変化
事業
● ターゲットとする市場（業種）の変化
● ターゲットとする企業規模の変化
● ターゲットとするユーザーの変化
サービス
● 提供する機能の変化
19
建設業と運送業の
管理者は同じ業務と責務？
Slide 20
Slide 20 text
事業やサービスの変化
事業
● ターゲットとする市場（業種）の変化
● ターゲットとする企業規模の変化
● ターゲットとするユーザーの変化
サービス
● 提供する機能の変化
20
10名と100名の企業の
管理者は同じ業務と責務？
Slide 21
Slide 21 text
事業やサービスの変化
事業
● ターゲットとする市場（業種）の変化
● ターゲットとする企業規模の変化
● ターゲットとするユーザーの変化
サービス
● 提供する機能の変化
21
同じ admin?
Slide 22
Slide 22 text
事業やサービスの変化
事業
● ターゲットとする市場（業種）の変化
● ターゲットとする企業規模の変化
● ターゲットとするユーザーの変化
サービス
● 提供する機能の変化
22
役割に依存した判定は
アンチパターン
Slide 23
Slide 23 text
事業やサービスの変化
事業
● ターゲットとする市場（業種）の変化
● ターゲットとする企業規模の変化
● ターゲットとするユーザーの変化
サービス
● 提供する機能の変化
23
役割の種類も
提供する機能も
増えていく
Slide 24
Slide 24 text
事業やサービスの変化
事業
● ターゲットとする市場（業種）の変化
● ターゲットとする企業規模の変化
● ターゲットとするユーザーの変化
サービス
● 提供する機能の変化
24
だから、権限管理は複雑になる
いつか、技術負債になる
Slide 25
Slide 25 text
リファクタリング
25
Slide 26
Slide 26 text
よくある実装①
26
Slide 27
Slide 27 text
よくある実装①
27
プロジェクトを作成できるのか？
Slide 28
Slide 28 text
よくある実装①
28
プロジェクトを作成できるのか？
わからない...
Slide 29
Slide 29 text
admin? からの卒業
● 役割に依存した実装は、権限が暗黙的になる
○ レビュワーは、常に役割の権限を知らないといけない
○ 判定箇所が散らばり、どのような権限が定義されているのかわからない
● 役割に依存した実装は、変化に弱い
○ 役割の権限が変化した際に、多くの判定箇所を⾒ないといけない
○ 権限の整合性を確認するために、多くの判定箇所を⾒ないといけない
29
Slide 30
Slide 30 text
役割でなく、権限に依存する
30
Slide 31
Slide 31 text
役割でなく、権限に依存する
31
プロジェクトを作成できるのか？
Slide 32
Slide 32 text
役割でなく、権限に依存する
32
Slide 33
Slide 33 text
役割でなく、権限に依存する
33
これだけでも、だいぶ良くなる
Slide 34
Slide 34 text
役割でなく、権限に依存する
34
ここまでが導⼊
Slide 35
Slide 35 text
役割でなく、権限に依存する
35
より深みへ
Slide 36
Slide 36 text
権限管理で⼤事なこと
36
Slide 37
Slide 37 text
間違えない
1. 実装で間違えない
a. 追加、変更をするとき
2. 利⽤で間違えない
a. 処理の中で判定をするとき
3. 理解で間違えない
a. コードリーディングのとき
b. お問い合わせの回答のとき
37
Slide 38
Slide 38 text
間違えない
1. 実装で間違えない
a. 追加、変更をするとき
2. 利⽤で間違えない
a. 処理の中で判定をするとき
3. 理解で間違えない
a. コードリーディングのとき
b. お問い合わせの回答のとき
38
権限はお問い合わせが多い
Slide 39
Slide 39 text
RBACとABAC
39
Slide 40
Slide 40 text
RBACとABAC
RBAC（Role-Based Access Control）
● 運営アカウント
● 管理者アカウント
● 外部アカウント
ABAC（Attribute-Based Access Control）
● 作成者
● 担当者
40
Slide 41
Slide 41 text
RBACとABAC
RBAC（Role-Based Access Control）
● 運営アカウント
● 管理者アカウント
● 外部アカウント
ABAC（Attribute-Based Access Control）
● 作成者
● 担当者
41
役割
条件（役割以外）
Slide 42
Slide 42 text
権限管理を整理する
42
Slide 43
Slide 43 text
具体例で整理
● 「プロジェクトの更新は、管理者か担当者ならできる」
43
Slide 44
Slide 44 text
具体例で整理
● 「プロジェクトの更新は、管理者か担当者ならできる」
● 「対象の、操作は、役割か条件ならできる」
44
Slide 45
Slide 45 text
具体例で整理
● 「プロジェクトの更新は、管理者か担当者ならできる」
● 「対象の、操作は、役割か条件ならできる」
● 「Modelの、CRUDは、RoleかScopeならできる」
45
Slide 46
Slide 46 text
Punditで実装
46
Slide 47
Slide 47 text
Pundit
47
Slide 48
Slide 48 text
Pundit
48
まだパッとわかる
Slide 49
Slide 49 text
Pundit
49
プロジェクトの更新は、
管理者か
マネージャーかつ
担当者か作成者ならできる
外部アカウントは
どんな場合もできない
Slide 50
Slide 50 text
Pundit
50
Slide 51
Slide 51 text
Pundit
51
「通常ユーザーは、プロジェクトの更新ができますか？」と
聞かれたら回答するのに何秒必要ですか？
Slide 52
Slide 52 text
Pundit
52
「通常ユーザーは、プロジェクトの更新ができますか？」と
聞かれたら回答するのに何秒必要ですか？
全部読みましたね？
5~10秒くらいかな
Slide 53
Slide 53 text
Pundit
53
「通常ユーザーは、プロジェクトの更新ができますか？」と
聞かれたら回答するのに何秒必要ですか？
実際のサービスでは
より判定は複雑になる
Slide 54
Slide 54 text
Pundit
54
「通常ユーザーは、プロジェクトの更新ができますか？」と
聞かれたら回答するのに何秒必要ですか？
どうしてパッとわからないのか
Slide 55
Slide 55 text
具体例で整理
● 「プロジェクトの更新は、管理者か担当者ならできる」
● 「対象の、操作は、役割か条件ならできる」
● 「Modelの、CRUDは、RoleかScopeならできる」
55
Slide 56
Slide 56 text
Pundit
56
対象
操作
役割 条件
Slide 57
Slide 57 text
RBACとABAC
RBAC（Role-Based Access Control）
● 運営アカウント
● 管理者アカウント
● 外部アカウント
ABAC（Attribute-Based Access Control）
● 作成者
● 担当者
57
役割
条件（役割以外）
Slide 58
Slide 58 text
Pundit
58
対象
操作
役割 条件
Slide 59
Slide 59 text
Pundit
59
対象
操作
役割 条件
Slide 60
Slide 60 text
Pundit
60
対象
操作
役割 条件
役割と条件を分けよう
Slide 61
Slide 61 text
Pundit
61
対象
操作
役割 条件
つくりました
Slide 62
Slide 62 text
Moduleの設計と実装
62
Slide 63
Slide 63 text
63
Slide 64
Slide 64 text
64
対象
操作 役割
条件
Slide 65
Slide 65 text
65
Project / Manager
def update
assignee? || author?
Slide 66
Slide 66 text
66
なんとなくわかった⼈🙋
Slide 67
Slide 67 text
67
英語と論理演算がわかれば🙆
Slide 68
Slide 68 text
68
どうやって実現しているか
⾒ていきます
Slide 69
Slide 69 text
ざっくり概要
1. 対象と役割から権限のクラスを特定
2. 判定モードの指定
3. 操作名の関数を実⾏
4. 条件の判定
69
Slide 70
Slide 70 text
70
Slide 71
Slide 71 text
71
対象
Modelと1対1
Slide 72
Slide 72 text
72
役割
Userのroleと1対1
Slide 73
Slide 73 text
73
操作
Slide 74
Slide 74 text
74
条件
Slide 75
Slide 75 text
75
対象
役割
操作
条件
Slide 76
Slide 76 text
ここまでの整理
● 対象ごとにディレクトリを作成、役割ごとにファイルを作成
○ 役割と条件を分ける
● 権限のクラスの特定でメタプログラミングを活⽤
○ 権限の変更が容易
● 対象の基底クラスでCRUD以外の操作を追加
○ 対象ごとに異なる操作の拡張に対応
● 対象の基底クラスで条件を定義、条件を論理演算で使⽤
○ 判定は英語と論理演算がわかれば⼗分
○ 対象によって異なる条件の判定に対応
76
Slide 77
Slide 77 text
77
エントリーポイント
Slide 78
Slide 78 text
78
Slide 79
Slide 79 text
使い⽅
1. レコードに対して権限があるかを判定する（recordモード）
79
対象と操作が明⽰されている👍
Slide 80
Slide 80 text
使い⽅
2. 権限があるレコードのみに絞り込む（scopeモード）
80
対象と操作が明⽰されている👍
Slide 81
Slide 81 text
使い⽅
3. 権限の⼀覧を取得する（listモード）
81
主にクライアントに渡して利⽤する
Slide 82
Slide 82 text
82
Context.newして関数を実⾏
Slide 83
Slide 83 text
83
権限のクラスを特定して判定を⾏う
Slide 84
Slide 84 text
84
Slide 85
Slide 85 text
85
Slide 86
Slide 86 text
86
対象と役割から
権限のクラスを特定する
Slide 87
Slide 87 text
87
対象と役割から
権限のクラスを特定する
Slide 88
Slide 88 text
88
Slide 89
Slide 89 text
使い⽅
1. レコードに対して権限があるかを判定する（recordモード）
89
対象と操作が明⽰されている👍
Slide 90
Slide 90 text
90
権限のクラスを
recordモードでnew
Slide 91
Slide 91 text
91
権限のクラスを
recordモードでnew
操作名の関数を実⾏
Slide 92
Slide 92 text
92
Slide 93
Slide 93 text
使い⽅
2. 権限があるレコードのみに絞り込む（scopeモード）
93
対象と操作が明⽰されている👍
Slide 94
Slide 94 text
94
権限のクラスを
scopeモードでnew
Slide 95
Slide 95 text
95
権限のクラスを
scopeモードでnew
操作名の関数を実⾏
Slide 96
Slide 96 text
96
Slide 97
Slide 97 text
使い⽅
3. 権限の⼀覧を取得する（listモード）
97
主にクライアントに渡して利⽤する
Slide 98
Slide 98 text
98
Policy::{対象}で定義されている
対象名を全て取得
Slide 99
Slide 99 text
99
Policy::{対象}で定義されている
対象名を全て取得
権限のクラスを
listモードでnew
Slide 100
Slide 100 text
100
Policy::{対象}で定義されている
対象名を全て取得
権限のクラスを
listモードでnew
権限のクラスで定義されている
全てのpublicメソッドを実⾏
Slide 101
Slide 101 text
ここまでの整理
● 対象ごとにディレクトリを作成、役割ごとにファイルを作成
○ 役割と条件を分ける
● メタプログラミングを活⽤
○ 権限の変更が容易
● 対象の基底クラスでCRUD以外の操作を追加
○ 対象ごとに異なる操作の拡張に対応
● 対象の基底クラスで条件を定義、条件を論理演算で使⽤
○ 判定は英語と論理演算がわかれば⼗分
○ 対象によって異なる条件の判定に対応
101
Slide 102
Slide 102 text
102
権限の基底クラス
Slide 103
Slide 103 text
103
Slide 104
Slide 104 text
104
判定に必要な情報
判定のモード
Slide 105
Slide 105 text
105
操作のデフォルトとしてCRUDを定義
Slide 106
Slide 106 text
106
対象の基底クラス
Slide 107
Slide 107 text
107
Slide 108
Slide 108 text
108
recordモード⽤の条件を定義
Slide 109
Slide 109 text
109
scopeモード⽤の条件を定義
Slide 110
Slide 110 text
110
CRUD以外の操作の追加
Slide 111
Slide 111 text
ここまでの整理
● 対象ごとにディレクトリを作成、役割ごとにファイルを作成
○ 役割と条件を分ける
● 権限のクラスの特定でメタプログラミングを活⽤
○ 権限の変更が容易
● 対象の基底クラスでCRUD以外の操作を追加
○ 対象ごとに異なる操作の拡張に対応
● 対象の基底クラスで条件を定義、条件を論理演算で使⽤
○ 判定は英語と論理演算がわかれば⼗分
○ 対象によって異なる条件の判定に対応
111
Slide 112
Slide 112 text
112
権限の具体クラス
Slide 113
Slide 113 text
113
Slide 114
Slide 114 text
114
対象の基底クラスで定義した条件
を使⽤して判定を表現する
条件がない場合は
Booleanを記述する
Slide 115
Slide 115 text
115
対象の基底クラスで定義した条件
を使⽤して判定を表現する
条件がない場合は
scopeかscope.noneを記述する
Slide 116
Slide 116 text
116
具体的なレコードが必要な場合は
or条件のキーを配列で返す
条件がない場合は
Booleanを記述する
Slide 117
Slide 117 text
117
追加した操作の条件も
同様に記述
Slide 118
Slide 118 text
ここまでの整理
● 対象ごとにディレクトリを作成、役割ごとにファイルを作成
○ 役割と条件を分ける
● 権限のクラスの特定でメタプログラミングを活⽤
○ 権限の変更が容易
● 対象の基底クラスでCRUD以外の操作を追加
○ 対象ごとに異なる操作の拡張に対応
● 対象の基底クラスで条件を定義、条件を論理演算で使⽤
○ 判定は英語と論理演算がわかれば⼗分
○ 対象によって異なる条件の判定に対応
118
Slide 119
Slide 119 text
ざっくり概要
1. 対象と役割から権限のクラスを特定
2. 判定モードの指定
3. 操作名の関数を実⾏
4. 条件の判定
119
Slide 120
Slide 120 text
Q. 問題
120
Slide 121
Slide 121 text
121
Slide 122
Slide 122 text
122
対象
役割
操作
条件
Slide 123
Slide 123 text
123
なんとなくわかった⼈🙋
Slide 124
Slide 124 text
124
明⽇から弊社で
お問い合わせ対応できます
Slide 125
Slide 125 text
使⽤例
125
Slide 126
Slide 126 text
126
readできるprojectsに絞り込む
Slide 127
Slide 127 text
127
readできるprojectsに絞り込む
updateできるprojectか判定
Slide 128
Slide 128 text
128
readできるprojectsに絞り込む
updateできるprojectか判定
権限に依存しているので明⽰的
役割の変化に影響されない
Slide 129
Slide 129 text
129
パッとわかる
パッとわかる
Slide 130
Slide 130 text
130
パッとわかる
Slide 131
Slide 131 text
間違えない
1. 実装で間違えない
a. 追加、変更をするとき
2. 利⽤で間違えない
a. 処理の中で判定をするとき
3. 理解で間違えない
a. コードリーディングのとき
b. お問い合わせの回答のとき
131
Slide 132
Slide 132 text
間違えない
1. 実装で間違えない
a. 追加、変更をするとき
2. 利⽤で間違えない
a. 処理の中で判定をするとき
3. 理解で間違えない
a. コードリーディングのとき
b. お問い合わせの回答のとき
132
間違えない👏
Slide 133
Slide 133 text
良い設計の影響
133
Slide 134
Slide 134 text
事業への影響
● サービスの信頼性が向上した
○ Module導⼊から1年が経過したが、不具合の発⽣件数がゼロ
● 社内からのお問い合わせがゼロになり、開発⽣産性が向上した
○ CSやPdMがGitHubの1次情報を⾒て理解できるようになった
○ エンジニアは質問されたら、全部調べてしまい10分ほど使ってしまう
134
Slide 135
Slide 135 text
クライアント（Next.js）への影響
● RailsだけでなくNext.jsの技術負債も防げている
○ 権限の⼀覧を渡すため、Next.jsも役割でなく権限に依存する実装に⾃然となった
135
Slide 136
Slide 136 text
クライアント（Next.js）への影響
● RailsだけでなくNext.jsの技術負債も防げている
○ 権限の⼀覧を渡すため、Next.jsも役割でなく権限に依存する実装に⾃然となった
136
projectのupdateの権限がない場合は
編集ボタンは表⽰されない
Slide 137
Slide 137 text
クライアント（Next.js）への影響
● RailsだけでなくNext.jsの技術負債も防げている
○ 権限の⼀覧を渡すため、Next.jsも役割でなく権限に依存する実装に⾃然となった
137
projectのupdateの権限がない場合は
編集ボタンは表⽰されない
権限によるUIの制御を
宣⾔的に記述できるようにしている
Slide 138
Slide 138 text
おまけ：Railsから外の世界へ
138
Slide 139
Slide 139 text
Next.jsからRailsへリクエスト
139
データの取得
データの変更
Slide 140
Slide 140 text
Next.jsからRailsへリクエスト
140
Moduleによる判定
recordとscopeモード
Slide 141
Slide 141 text
Next.jsからRailsへリクエスト
141
判定済みのデータ
Slide 142
Slide 142 text
Next.jsからRailsへリクエスト
142
判定済みのデータ
Web Dev Tool でも⾒れない
Slide 143
Slide 143 text
Next.jsの権限管理
143
Slide 144
Slide 144 text
Next.jsの権限管理
144
ユーザーの指定
Slide 145
Slide 145 text
Next.jsの権限管理
145
Moduleによる判定
listモード
Slide 146
Slide 146 text
Next.jsの権限管理
146
権限の⼀覧を渡す
Moduleによる判定
listモード
Slide 147
Slide 147 text
Next.jsの権限管理
147
権限の⼀覧を渡す
Moduleによる判定
listモード
権限によるUI制御
Slide 148
Slide 148 text
Next.jsでの権限管理
148
Slide 149
Slide 149 text
149
Slide 150
Slide 150 text
150
対象
Slide 151
Slide 151 text
151
操作
Slide 152
Slide 152 text
152
操作
具体的なレコードが必要な場合は
or条件のキーの配列
Slide 153
Slide 153 text
153
Slide 154
Slide 154 text
154
権限のクラスを特定
Slide 155
Slide 155 text
155
Slide 156
Slide 156 text
156
権限のクラスを特定
Slide 157
Slide 157 text
157
Slide 158
Slide 158 text
158
ユーザーの管理
Slide 159
Slide 159 text
159
操作のデフォルトとして
CRUDを定義
Slide 160
Slide 160 text
160
Slide 161
Slide 161 text
161
Slide 162
Slide 162 text
162
Slide 163
Slide 163 text
163
条件を定義
Slide 164
Slide 164 text
164
判定がBooleanの場合
Slide 165
Slide 165 text
165
具体的なレコードがない場合
Slide 166
Slide 166 text
166
or条件の判定を⾏う
Slide 167
Slide 167 text
ここまでの整理
● Railsから渡ってきた権限の⼀覧のJSONを使ってMapをつくっている
● そのMapをNext.jsで管理することでNext.jsの権限管理を実現している
● Next.jsでも権限のクラスの定義と特定をしている
● 具体的なレコードが必要な判定はNext.jsで⾏っている
167
Slide 168
Slide 168 text
168
Slide 169
Slide 169 text
169
対象がない場合
Slide 170
Slide 170 text
170
操作がない場合
Slide 171
Slide 171 text
171
具体的なレコードが指定されている場合
Slide 172
Slide 172 text
172
具体的なレコードが指定されていない場合
Slide 173
Slide 173 text
173
Slide 174
Slide 174 text
174
対象と操作が明⽰されている👍
Slide 175
Slide 175 text
175
Slide 176
Slide 176 text
176
権限によるUIの制御を
宣⾔的に記述できるようにしている
Slide 177
Slide 177 text
177
projectのupdateの権限がない場合は
編集ボタンは表⽰されない
権限によるUIの制御を
宣⾔的に記述できるようにしている
Slide 178
Slide 178 text
178
権限によるUIの制御を
宣⾔的に記述できるようにしている
対象と操作が明⽰されている👍
Slide 179
Slide 179 text
179
権限によるUIの制御を
宣⾔的に記述できるようにしている
具体的なレコードが必要な判定に対応
Slide 180
Slide 180 text
180
権限によるUIの制御を
宣⾔的に記述できるようにしている
権限がない場合の表⽰
Slide 181
Slide 181 text
ここまでの整理
● Railsから渡ってきた権限の⼀覧のJSONを使ってMapをつくっている
● そのMapをNext.jsで管理することでNext.jsの権限管理を実現している
● Next.jsでも権限のクラスの定義と特定をしている
● 具体的なレコードが必要な判定はNext.jsで⾏っている
● 権限のMapを活⽤することでNext.jsでも対象と操作が明⽰された間違えないを実現
● 権限によるUIの制御を宣⾔的に記述できるようにしている
181
Slide 182
Slide 182 text
まとめ
● 権限管理を間違えると、事業とサービスへの損失が⼤きい
● 権限管理が技術負債になるのは、役割が事業とサービスの成⻑と共に変化することと
役割に依存した実装が原因
● 権限の実装は、役割（admin?）でなく権限に依存しよう
● 権限管理は、対象と操作と役割と条件の4つに分けられる
● 4つを分割をしたModuleの設計と実装の解説
● 良い設計の事業とクライアント（Next.js）への影響
182
ModuleのサンプルはGitHubで公開しています
Slide 183
Slide 183 text
「技術負債にならない‧間違えない」
権限管理の設計と実装
Kaigi on Rails 2025
@naro143（Yusuke Ishimi）