🎉
# 4.3 Django 標準の権限の考え方
認証(Authentication)と認可(Authorization)は業務システムの基盤となる仕組み。
Django には標準で「ユーザー・グループ・パーミッション」の仕組みが備わっており、シンプルな認可機能ならすぐに導入できる。
この記事では Django 標準の権限の仕組み を整理する。
1. 認証と認可の違い
-
認証(Authentication)
ユーザーが「誰なのか」を確認する仕組み
→ ログインフォーム、パスワード認証、2FA など -
認可(Authorization)
ユーザーが「何をできるのか」を制御する仕組み
→ 「受注は閲覧できるが削除できない」といったアクセス制御
Django 標準の権限機能は、このうち「認可」を担う。
2. Django 標準の権限の構成要素
User
- Django 標準のユーザーモデル
- 拡張可能(カスタムユーザーモデルを作るプロジェクトも多い)
Group
- 権限のまとまり(ロールのようなもの)
- 例:
sales_manager,accounting,admin - ユーザーは複数のグループに所属可能
Permission
-
「どのモデルに対して何ができるか」を表現する
-
Django は各モデルごとに自動で以下を生成する
add_xxxchange_xxxdelete_xxxview_xxx
3. 権限の付与方法
-
ユーザーに直接割り当て
- 個別ユーザーにパーミッションを設定
-
グループにまとめて割り当て
- 代表的な方法
- グループに権限を付与 → ユーザーをそのグループに所属させる
4. 実際の使い方
管理画面での設定
Django 管理画面から「ユーザー」「グループ」を開くと、チェックボックス形式で権限を割り当てられる。
コードでの判定
# 個別権限の判定
if request.user.has_perm("order.view_order"):
# 閲覧OK
# グループ経由で付与された権限も反映される
if request.user.has_perm("order.change_order"):
# 編集OK
デコレータで制御
from django.contrib.auth.decorators import permission_required
@permission_required("order.view_order", raise_exception=True)
def order_list(request):
...
5. 実際に困るポイント
Django 標準の権限はシンプルで分かりやすい一方で、業務システムでは次のような課題が出やすい。
-
モデル単位の粒度が大きすぎる
- 「受注は閲覧できるけど承認はできない」といった細かい制御が難しい
-
管理画面から設定するのが煩雑
- ユーザー数や部署が多いと管理不能になりやすい
-
UI が現場ユーザー向きではない
- システム管理者以外が使うのは現実的でない
6. AI活用のポイント
権限まわりの設計は「画面要件」「業務フロー」と密接に関わるため、最初から正解を出すのは難しい。
-
AIでできること
- User / Group / Permission のモデル拡張サンプルを提示させる
-
has_perm判定やデコレータ利用のコード雛形を生成させる - 「部署単位で権限を切るには?」といった拡張方針のアイデア出し
-
注意点
- 実際に業務システムへ組み込むと「メニューの制御」「ボタンの非表示」「API 側の認可判定」など フロント・バック両面の調整が必要
- AI が書いたコードは一見通るが、F5 リロードや別ルートからの遷移で効かないケース がよくある
- 本番データではユーザー数・部署数が多いため、運用性(誰が権限を管理するのか)まで設計しないと管理不能になる
👉 したがって、AI は「初期実装のたたき台」や「拡張方針の参考」として活用しつつ、実業務の要件でテストして調整することが必須。
まとめ
- Django 標準の権限機能は 「ユーザー」「グループ」「パーミッション」 の3要素で構成される
- モデル単位の CRUD 権限を簡単に付与できる
- シンプルなシステムや小規模案件なら十分便利
- ただし業務システムでは 細かい権限制御が難しく、管理も煩雑になりがち
- AI を活用して雛形やアイデアを得つつ、最終的には 実運用のフローに合わせて検証・調整する姿勢が重要
次回は、こうした課題を解決するために 自前でロールや権限モデルを設計して管理した方法 を紹介する。
Discussion