業務システムを設計するとき、
「管理者と一般ユーザーだけ分ければよい」
「とりあえず全員が編集できるようにする」
「後から必要になったら権限を追加する」
という形で、権限管理を後回しにしていないでしょうか。
権限管理は、システムの使いやすさだけでなく、
- 情報漏えい
- 誤更新
- 誤削除
- 不正操作
- 承認ルール
- 個人情報の保護
にも関係する重要な設計項目です。
例えば顧客管理システムでも、
営業担当者
→ 自分の顧客を閲覧・編集
営業マネージャー
→ 部署内の顧客を閲覧・編集
管理者
→ 全顧客を管理
経理担当者
→ 請求に必要な項目だけ閲覧
というように、利用者によって必要な操作範囲が異なります。
また、
「画面を見られるか」
だけでは十分ではありません。
実際の権限管理では、
- 閲覧
- 登録
- 編集
- 削除
- 承認
- CSV出力
- ファイルダウンロード
- 設定変更
などを分けて考える必要があります。
権限管理を設計するときの基本は、
誰が・どのデータに対して・何をできるのか
を整理することです。
この記事では、業務システムにおける権限管理の設計方法を、閲覧・編集・承認などの具体例を交えて解説します。
権限管理とは
権限管理とは、システム利用者ごとに、
何を閲覧できるか
何を操作できるか
を制御する仕組みです。
例えば顧客管理システムなら、
一般社員：
顧客情報を閲覧できる
営業担当者：
顧客情報を登録・編集できる
営業管理者：
部下の顧客情報も編集できる
システム管理者：
ユーザーや権限設定も変更できる
という設計があります。
重要なのは、
ログインできることと、すべての情報を操作できることは別
ということです。
認証によって、
「誰なのか」
を確認し、
認可によって、
「その人が何をしてよいのか」
を判断します。
業務システムでは、この認可部分が権限管理に該当します。
権限管理設計の基本は「誰が・何に・何をするか」
権限を整理するときは、次の3つに分けると考えやすくなります。
誰が
- 一般社員
- 営業担当者
- 営業マネージャー
- 経理
- 管理者
何に
- 顧客情報
- 契約
- 請求
- 社員情報
- 申請
- ファイル
何をする
- 閲覧
- 登録
- 編集
- 削除
- 承認
- 出力
例えば、
営業担当者が
自分の担当顧客を
閲覧・編集できる
という形です。
権限管理を検討するときは、単純に、
管理者
一般ユーザー
だけで考えるのではなく、
利用者 × データ × 操作
の組み合わせで整理することが重要です。
権限管理で整理したい主な操作
業務システムでは、少なくとも次の操作を分けて検討します。
1．閲覧
データを確認できる権限です。
例えば社員名簿なら、
一般社員
→ 氏名・所属を閲覧可能
人事担当者
→ 住所・連絡先まで閲覧可能
と分けることがあります。
2．登録
新しいデータを作成できる権限です。
例えば顧客管理なら、
営業担当者
→ 新規顧客登録可能
経理担当者
→ 顧客登録不可
という設計です。
3．編集
既存データを変更できる権限です。
閲覧できても編集できないケースがあります。
例えば、
一般社員
→ 社内規程を閲覧のみ
総務担当者
→ 社内規程を編集可能
などです。
4．削除
データを削除できる権限です。
削除は影響が大きいため、編集権限とは分けて考えることをおすすめします。
例えば、
担当者
→ 編集可能、削除不可
管理者
→ 編集・削除可能
とします。
5．承認
申請や契約などを承認できる権限です。
例えば、
一般社員
→ 申請のみ
課長
→ 課内申請を承認
部長
→ 高額申請を承認
などです。
6．CSV出力・ダウンロード
見落とされやすい権限です。
画面上で1件ずつ閲覧することと、
1万件の顧客情報をCSVで一括出力すること
では、情報持ち出しのリスクが大きく異なります。
そのため、
閲覧可能
≠
CSV出力可能
として分けることがあります。
7．管理設定
例えば、
- ユーザー登録
- 権限変更
- マスタ変更
- システム設定
などです。
通常業務とは分離し、管理者だけに限定する方法があります。
権限設計でよく使われるRBACとは
権限管理では、RBACという考え方がよく使われます。
RBACはRole-Based Access Controlの略で、役割に対して権限を割り当てる方法です。
例えば、
営業担当
- 顧客閲覧
- 顧客登録
- 顧客編集
営業マネージャー
- 顧客閲覧
- 顧客登録
- 顧客編集
- 顧客削除
- CSV出力
管理者
- 全機能
というロールを用意します。
その後、
田中さん
→ 営業担当
佐藤さん
→ 営業マネージャー
とユーザーへロールを設定します。
ユーザーごとに権限を一つずつ設定するよりも管理しやすくなります。
ユーザーごとに権限設定しすぎない
小規模なシステムでは、
田中さんだけ編集可能
佐藤さんだけCSV出力可能
鈴木さんだけ削除可能
という個別設定を作りたくなることがあります。
しかし、利用者が増えると管理が複雑になります。
例えば退職・異動のたびに、
この人には何の権限が付いていたか
を確認しなければなりません。
そのため、基本的には、
- 一般ユーザー
- 担当者
- 管理者
- 承認者
などのロール単位で設計し、例外だけ個別対応する方が管理しやすくなります。
データ範囲の権限も考える
権限管理では、
何の操作ができるか
だけでなく、
どのデータに対してできるか
も重要です。
例えば営業担当者が顧客を閲覧できる場合でも、
パターン1
すべての顧客を閲覧可能
パターン2
自分が担当する顧客だけ閲覧可能
パターン3
自部署が担当する顧客だけ閲覧可能
などがあります。
そのため権限設計では、
- 自分のデータ
- 自部署のデータ
- 全社データ
という範囲も整理します。
権限管理の具体例｜顧客管理システム
例えば顧客管理システムで、次の利用者がいるとします。
- 営業担当
- 営業マネージャー
- 経理
- 管理者
権限を整理すると次のようになります。
| 操作 | 営業担当 | 営業マネージャー | 経理 | 管理者 |
|---|---|---|---|---|
| 顧客閲覧 | 担当分のみ | 部署内 | 全件 | 全件 |
| 顧客登録 | ○ | ○ | × | ○ |
| 顧客編集 | 担当分のみ | 部署内 | × | ○ |
| 顧客削除 | × | × | × | ○ |
| CSV出力 | × | ○ | ○ | ○ |
| ユーザー管理 | × | × | × | ○ |
このような表を作ると、要件定義時に認識を合わせやすくなります。
権限管理の具体例｜申請・承認システム
申請システムでは、
- 申請者
- 承認者
- 管理者
があります。
例えば、
申請者
- 自分の申請を登録
- 自分の申請を閲覧
- 差し戻された申請を編集
承認者
- 自分に回ってきた申請を閲覧
- 承認
- 差し戻し
管理者
- 全申請を閲覧
- 承認ルート設定
- マスタ管理
とします。
さらに、
課長
→ 10万円未満
部長
→ 100万円未満
役員
→ 100万円以上
のように、金額条件によって承認権限を変える場合もあります。
権限管理の具体例｜社員名簿
社員名簿には個人情報を含むため、項目単位で制御するケースがあります。
例えば、
全社員
- 氏名
- 部署
- 社内メール
を閲覧。
管理職
上記に加えて、
- 社内電話
- 所属情報
を閲覧。
人事
さらに、
- 住所
- 個人連絡先
- 入社日
を閲覧・編集。
このように、
同じ社員情報でも、項目によって閲覧範囲を変える
方法があります。
権限管理の具体例｜文書管理システム
文書管理では、
- 文書種類
- 部署
- ステータス
によって権限を変えることがあります。
例えば、
社内規程
全社員：閲覧
総務：編集
管理者：削除
人事文書
一般社員：閲覧不可
人事：閲覧・編集
管理者：管理
契約書
担当部署：閲覧
法務：閲覧・編集
責任者：承認
という設計です。
権限設計を行う7ステップ
STEP1｜利用者を洗い出す
まず、誰がシステムを利用するか整理します。
例えば、
- 一般社員
- 営業
- 営業管理者
- 経理
- 人事
- システム管理者
などです。
STEP2｜業務上の役割を整理する
単に部署を見るのではなく、
何をする人なのか
を確認します。
同じ営業部でも、
営業担当
営業管理者
では必要な権限が異なります。
STEP3｜管理対象を整理する
例えば、
- 顧客
- 案件
- 契約
- 申請
- 文書
- 社員
などです。
STEP4｜操作を洗い出す
各対象について、
- 閲覧
- 登録
- 編集
- 削除
- 承認
- 出力
を整理します。
STEP5｜データ範囲を決める
例えば、
- 自分のみ
- 自部署
- 全社
のどこまで扱えるか決めます。
STEP6｜権限表を作る
ロールと操作を一覧化します。
例えば、
| 機能 | 一般 | 担当者 | 管理者 |
|---|---|---|---|
| 閲覧 | ○ | ○ | ○ |
| 登録 | × | ○ | ○ |
| 編集 | × | ○ | ○ |
| 削除 | × | × | ○ |
| CSV出力 | × | × | ○ |
という表です。
STEP7｜例外ケースを確認する
通常ルールだけでは対応できないケースを確認します。
例えば、
- 代理承認
- 兼務
- 異動
- 退職
- 一時的な権限付与
などです。
ここまで整理すると、システム上の権限要件が明確になります。
【コピペ用】権限管理設計シート
利用者・ロール
一般ユーザー：
担当者：
管理者：
承認者：
その他：
管理対象
顧客：
案件：
契約：
申請：
文書：
社員：
その他：
閲覧
自分のみ：
自部署：
全社：
特定条件：
登録
登録可能なロール：
編集
編集可能なロール：
編集できるデータ範囲：
削除
削除可能なロール：
論理削除：
物理削除：
承認
承認可能なロール：
承認条件：
代理承認：
出力
CSV出力：
PDF出力：
ファイルダウンロード：
管理機能
ユーザー管理：
ロール管理：
マスタ管理：
システム設定：
履歴
ログイン履歴：
閲覧履歴：
編集履歴：
削除履歴：
CSV出力履歴：
承認履歴：
例外
兼務：
異動：
退職：
一時権限：
その他：
権限管理では「閲覧」と「編集」を分ける
権限設計でよくある失敗が、
見られるなら編集もできる
という設計です。
実際には、
閲覧のみ必要
という利用者は多くいます。
例えば経営者が売上データを見る場合でも、売上情報を編集する必要はありません。
そのため、
閲覧
登録
編集
削除
を分けます。
特に削除は影響が大きいため、独立して制御することが重要です。
CSV出力は独立した権限にする
顧客管理や名簿管理では、
CSV出力権限
を軽視しないことが重要です。
例えば画面では、
1ページ50件
しか表示されなくても、CSV出力では数万件を取得できる場合があります。
そのため、
閲覧可能
＋
CSV出力不可
という設定を作ることがあります。
さらに必要に応じて、
- 誰が
- いつ
- 何件
CSV出力したのかログを残します。
削除は「論理削除」も検討する
データを削除するとき、
データベースから完全に消す
方法だけではありません。
例えば、
有効
↓
削除済み
という状態へ変更し、通常画面では表示しない方法があります。
これを論理削除と呼びます。
誤削除から復旧する必要がある場合や、過去履歴を残したい場合に利用されます。
ただし、個人情報などは保持期間や削除要件もあるため、すべてを永続的に残せばよいわけではありません。
業務・法令・社内ルールに応じて決めます。
承認権限は役職だけで決めない場合もある
承認権限というと、
課長
部長
役員
だけで考えがちです。
実際には、
- 金額
- 部署
- 申請種類
- 契約種類
- 担当業務
などによって変わることがあります。
例えば、
10万円未満
→ 課長
10万円以上100万円未満
→ 部長
100万円以上
→ 役員
とします。
この場合、
「部長だからすべて承認できる」
ではなく、
条件に応じて承認可能か判定する
設計が必要です。
権限は画面を隠すだけでは不十分
システム設計では、
権限がない人にはボタンを表示しない
だけで終わらせないことが重要です。
例えば削除ボタンを非表示にしても、APIへ直接リクエストできる状態なら権限制御として不十分です。
そのため、
画面側
権限がない操作を表示しない。
サーバー側
実際にそのユーザーが操作可能か検証する。
という両方が必要です。
権限管理はUIではなく、サーバー側の認可処理を中心に設計する必要があります。
権限変更の履歴も残す
誰にどの権限があるかだけでなく、
誰がいつ権限を変更したか
を残すことも重要です。
例えば、
2026/07/30
管理者A
田中さん
営業担当 → 営業管理者
という履歴です。
特に重要な業務システムでは、
- 権限付与
- 権限削除
- 管理者変更
などの操作ログを残します。
退職・異動時の権限変更も考える
権限設計では、運用も重要です。
例えば社員が異動した場合、
営業1課
↓
営業2課
へ所属だけ変更しても、
営業1課の顧客を閲覧できる権限
が残ってしまう可能性があります。
退職の場合も同様です。
そのため、
入社
↓
権限付与
異動
↓
権限見直し
退職
↓
アカウント無効化
という運用を決めます。
システムが適切でも、権限変更の運用がなければアクセス権が残り続ける可能性があります。
権限設計でよくある失敗
失敗1｜管理者と一般ユーザーだけで設計する
実際の業務では、担当者・管理職・経理・人事など役割が異なります。
利用者の業務からロールを整理します。
失敗2｜ユーザーごとに権限を設定する
利用者が増えると管理できなくなります。
基本はロール単位で設定します。
失敗3｜閲覧できれば編集もできるようにする
閲覧と編集は分けます。
不要な編集権限を与えないことが重要です。
失敗4｜削除権限を全員に与える
誤削除の原因になります。
管理者などへ限定する方法があります。
失敗5｜CSV出力を閲覧と同じ扱いにする
大量のデータを取得できるため、別権限として検討します。
失敗6｜画面側だけで制御する
ボタン非表示だけでは不十分です。
API・サーバー側でも権限判定します。
失敗7｜異動・退職を考えていない
権限を付与する設計だけでなく、変更・削除する運用も必要です。
失敗8｜権限を細かくしすぎる
細かすぎる権限は管理負担になります。
「この項目だけこの人だけ編集可能」といった例外を増やしすぎないことが重要です。
RBACとABACの違い
権限管理について調べると、RBAC以外にABACという言葉を見ることがあります。
RBAC
役割を基準にアクセスを決めます。
例えば、
営業担当
→ 顧客編集可能
という方法です。
ABAC
利用者・データ・環境などの属性を使って判断します。
例えば、
営業担当
かつ
自部署の顧客
かつ
契約中
の場合だけ編集可能、というような考え方です。
一般的な中小規模の業務システムでは、まずRBACを基本にすると設計しやすくなります。
条件が複雑な場合に、データ範囲など追加ルールを組み合わせる方法があります。
権限管理は最小権限から考える
権限管理の基本的な考え方の一つが、
業務に必要な最小限の権限だけ与えること
です。
例えば、
「念のため全部見られるようにする」
ではなく、
この業務をするために何が必要か
から決めます。
営業担当者が顧客情報を更新する必要があるなら編集権限は必要です。
しかし、
ユーザー管理
システム設定
全件CSV出力
まで必要とは限りません。
権限を必要以上に広げないことで、誤操作や情報持ち出しのリスクを減らせます。
権限管理に関するよくある質問
権限は何種類くらい作ればよいですか？
一律の正解はありません。
実際の業務上の役割を基準にします。
細かく作りすぎると運用が複雑になるため、共通する役割をまとめてロール化します。
管理者はすべて操作できるようにするべきですか？
システムによります。
運用管理者と、業務データを管理する人を分ける場合もあります。
例えばシステム管理者でも、人事情報を閲覧する必要がないケースがあります。
閲覧履歴も残した方がよいですか？
扱う情報によります。
機密情報や重要な個人情報などでは、誰が閲覧したか記録する場合があります。
すべての画面で必須というわけではありません。
権限は部署と役職のどちらで決めるべきですか？
業務によります。
部署だけでなく、
- 役職
- 担当業務
- データ所有者
- 承認条件
などを組み合わせる場合があります。
権限管理は後から追加できますか？
技術的には可能ですが、データ構造・画面・APIなど広い範囲へ影響することがあります。
最低限の権限要件は、要件定義段階で整理しておく方が安全です。
hiro-dev-labでは権限設計の整理から相談できます
hiro-dev-labでは、Webシステムの開発だけでなく、誰がどの情報をどこまで操作できるべきかを整理する段階から相談できます。
例えば、
- 利用者・ロールの整理
- 業務フロー整理
- 閲覧範囲の整理
- 登録・編集・削除権限の整理
- CSV出力権限
- 承認権限
- 部署別アクセス制御
- データ範囲設計
- 更新・操作履歴
- 異動・退職時の運用整理
- 要求整理
- 業務要件・機能要件整理
- Webシステム設計・開発
などです。
例えば、
管理者と一般ユーザーだけでは権限が足りない
営業担当者には自分の顧客だけ見せたい
一部のユーザーだけCSV出力できるようにしたい
承認者を金額によって変えたい
個人情報の一部だけ閲覧制限したい
という場合でも、
利用者 → 業務 → データ → 操作 → 権限
の順番で整理できます。
まとめ｜権限管理は「役職」ではなく「業務に必要な操作」から設計する
権限管理を設計するとき、
「管理者・一般ユーザー」
だけで始めると、後から例外が増えやすくなります。
まず、
- 誰がシステムを利用するのか
- どんな業務を行うのか
- どのデータを扱うのか
- 閲覧できる範囲はどこまでか
- 登録・編集・削除できるのか
- 承認できるのか
- CSV出力や管理設定が必要か
を整理します。
その上で、
利用者 × データ × 操作
を権限表として整理します。
例えば、
営業担当
→ 自分の顧客を閲覧・編集
営業管理者
→ 部署内の顧客を閲覧・編集
経理
→ 必要な顧客情報を閲覧
管理者
→ 全件管理
という形です。
さらに、
- CSV出力
- 承認
- 削除
- ユーザー管理
など影響の大きい操作は個別に整理します。
権限管理で重要なのは、機能を細かく分けることではなく、
必要な人へ必要な権限だけを与え、不要な権限を持たせないこと
です。
「誰にどこまで見せればよいか分からない」
「部署や役職によって操作を変えたい」
「承認やCSV出力だけ制限したい」
という場合は、まず利用者ごとに「閲覧・登録・編集・削除・承認・出力」の6項目を表にして整理するところから始めてみてください。