管理画面の権限設計：ロールと操作範囲を決める実務的な手順

管理画面の権限設計は、「役職名からロールを作る」のではなく、「誰が・どのデータを・どこまで操作できるか」を表にしてから、似た行をまとめてロールにするのが最も手戻りの少ない進め方です。最初にロールの名前を決めてしまうと、例外の担当者が出るたびにロールが増え、半年後には誰も全体像を説明できない状態になりがちです。

この記事は、社内向けの管理画面や、取引先・代理店も使う業務システムを発注・企画する立場の方に向けて書いています。権限表（アクセス権限マトリクス）の作り方、ロールへの落とし込み方、データ範囲の制御、承認や代理操作の扱い、運用開始後に権限が崩れないための仕組みまで、開発会社に要件を伝える前に発注側で整理しておくべきことを順番に説明します。

結論を先に言えば、権限設計で決めるべきことは「操作の種類」「データの範囲」「例外の扱い」の三つです。この三つを分けて考えるだけで、ロールの数は驚くほど少なく抑えられ、開発費も運用の手間も小さくなります。

管理画面の権限設計でつまずく3つのパターン

まず、よくあるつまずき方を知っておくと、設計の勘所がつかみやすくなります。

役職とロールを一対一で対応させてしまう

「部長」「課長」「担当者」とロールを作ると、組織変更や兼務のたびにロールの見直しが必要になります。役職は人事上の区分であって、システム上の操作範囲とは必ずしも一致しません。たとえば同じ課長でも、経理の課長は請求データを確定でき、営業の課長はできない、という差があるのが普通です。

画面単位でしか権限を考えていない

「この画面は見られる／見られない」だけで権限を決めると、同じ顧客一覧画面の中で「自分の担当顧客だけ見せたい」「金額の列は隠したい」といった要望に応えられません。画面単位の制御は分かりやすい反面、実務で求められる細かさに足りないことが多いのです。

例外を個別対応で積み上げる

「Aさんだけは特別に削除もできるように」という要望を、その都度ロールを増やしたり、個人に直接権限を付けたりして対応すると、後から誰が何をできるのか追えなくなります。例外は必ず起きる前提で、例外をどう扱うかのルールを先に決めておくことが重要です。

権限は「操作」「データ範囲」「例外」の三層で考える

権限設計を整理しやすくするために、次の三層に分けて考えます。

操作の種類は、システムの機能一覧から自然に洗い出せます。データの範囲は、組織構造や取引先との関係から決まります。例外の扱いは、運用ルールとして決めるものです。

一般にロールベースのアクセス制御は RBAC（ロールベースアクセス制御） と呼ばれ、「ロールに権限をまとめ、ユーザーにロールを割り当てる」仕組みです。RBACは操作の種類を整理するのに向いていますが、データの範囲まで全部ロールで表そうとすると、「東京営業部の担当者」「大阪営業部の担当者」のようにロールが組織の数だけ増えてしまいます。そこで、ロールは操作の種類を表し、データの範囲は所属や担当といった属性で絞る、という役割分担にするのが実務的です。

アクセス権限マトリクスを作る手順

ここからは、発注側で作っておくと開発会社とのやり取りが格段に楽になる「権限表」の作り方を説明します。Excelやスプレッドシートで十分です。

1. 利用者の種類を洗い出す：社内の部署・役割だけでなく、取引先、代理店、外部委託先、システム管理者など、管理画面にログインする可能性のある人をすべて書き出します。「実際の人」ではなく「業務上の立場」で書くのがポイントです。
2. 機能（データの種類）を縦に並べる：顧客、案件、見積もり、請求、商品マスタ、ユーザー管理、システム設定など、管理画面で扱う対象を行にします。画面一覧があれば、そこから拾うと漏れが減ります。
3. 各マスに操作の記号を書く：閲覧はR、作成はC、編集はU、削除はD、承認はA、CSV出力はEのように記号を決め、マスに書き込みます。できない場合は空欄にします。
4. データ範囲を別列で書く：同じ「閲覧」でも、全件なのか自部署だけなのかを列を分けて書きます。「R（自担当）」のように括弧書きでも構いません。
5. 似た列をまとめてロール候補にする：利用者の種類ごとの列を見比べ、操作の記号がほぼ同じ列をまとめます。まとめた結果がロールの候補です。
6. 差分を「例外」として切り出す：まとめきれなかった少数の差分は、ロールを増やすのではなく、追加の権限フラグや期限付き付与で扱えないかを検討します。
7. 現場の責任者に確認してもらう：最後に、表を各部署の責任者に見てもらい、「この人がこれをできないと業務が止まる」「これはできてはいけない」という観点でチェックしてもらいます。

この手順で作った表は、そのまま要件定義書の一部として使えます。要件定義の全体像については 管理画面開発の進め方 もあわせて参考にしてください。

具体例：卸売業の受発注管理画面でロールを決める

ここでは架空の一般例として、取引先からの注文を受け付け、社内で在庫と出荷を管理する卸売業の管理画面を考えてみます。

利用者の種類は、営業担当、営業マネージャー、受注事務、倉庫担当、経理、システム管理者、そして取引先の発注担当者です。最初に権限表を作ると、次のような傾向が見えてきます。

• 営業担当と営業マネージャーは、見られるデータの範囲（自担当か部全体か）と、値引きの承認ができるかどうかだけが違う
• 受注事務は全取引先の注文を見て編集できるが、価格マスタは変更できない
• 倉庫担当は出荷に関する項目だけ編集でき、金額は見えなくてよい
• 経理は請求の確定ができるが、注文内容は閲覧のみ
• 取引先の発注担当者は、自社の注文と請求だけを見られる

ここから、ロールは「営業」「受注事務」「倉庫」「経理」「取引先」「管理者」の六つにまとめられます。営業担当と営業マネージャーは同じ「営業」ロールにし、データ範囲を「自担当」と「部全体」の属性で切り替え、値引き承認は「承認権限あり」のフラグで表します。こうすれば、営業部に新しいチームができても、ロールを増やさずに所属の属性を追加するだけで対応できます。

倉庫担当に金額を見せない、という要件は、画面単位ではなく項目単位の制御が必要です。こうした項目単位の制御は、実装コストが上がる要素の一つなので、本当に必要なのかを最初に確認しておくと見積もりがぶれにくくなります。

この例でもう一つ大事なのは、取引先の発注担当者を「取引先」ロールとして社内ロールから完全に切り離している点です。取引先が使う画面は、社内の受注画面と見た目が似ていても、別の入口と別のロールで管理します。こうしておけば、社内の受注事務に新しい編集権限を足したときに、取引先側の画面で同じ操作ができてしまうといった事故を構造的に防げます。

さらに、権限表を作る過程で「倉庫担当が出荷予定日を変更できないと、欠品時に受注事務へ電話で頼むしかない」といった業務上の詰まりも見つかります。権限設計は、セキュリティのためだけでなく、業務の流れを見直す機会にもなるのです。

ロール設計の判断基準

ロールの数や粒度に正解はありませんが、判断の目安はあります。

特に、社外の利用者（取引先や代理店）は、社内のロールとは明確に分けることをおすすめします。社内ロールの権限を後から広げたときに、意図せず社外の利用者にも影響が及ぶ事故を防げるからです。

また、ロールは少ないほど運用は楽になりますが、一つのロールに権限を詰め込みすぎると「最小権限」の原則から外れていきます。「とりあえず全員に管理者権限を付けておく」状態は、最初は楽でも、退職者のアカウント管理や誤操作の影響範囲という点で必ず問題になります。

データ範囲の制御と、見落としやすい抜け道

操作の権限を正しく決めても、データの範囲制御に抜けがあると意味がありません。設計時に確認しておきたいのは次のような箇所です。

一覧画面以外の経路

一覧画面では自担当の顧客だけが表示されていても、URLの番号を書き換えると他の顧客の詳細画面が開けてしまう、という不具合は典型的です。詳細画面、編集画面、ファイルのダウンロード、CSV出力、検索のサジェスト、集計画面など、データが出てくるすべての経路で同じ範囲制御がかかっている必要があります。

集計値やダッシュボード

個別のデータは見られなくても、部署別の売上合計が見えると、実質的に他部署の数字が分かってしまうことがあります。集計画面を誰に見せるかは、個別データの権限とは別に検討しておくと安全です。

通知メールや添付ファイル

管理画面の中では制御していても、更新通知のメールに詳細が書かれていて、権限のない人にも届いてしまう、というケースもあります。通知の宛先と本文に含める情報も、権限設計の一部として扱いましょう。

API や外部連携

他システムとAPIで連携する場合、連携用のアカウントにどこまでの権限を与えるかも決めておく必要があります。連携用アカウントに全権限を付けてしまうと、連携先のトラブルがそのままこちらのデータに波及します。

承認・代理操作・緊急時の権限をどう扱うか

権限設計で後回しにされがちなのが、承認や代理操作、緊急時の対応です。これらは業務の現実に直結するため、最初から考えておくと運用開始後の混乱が減ります。

承認の権限

「作成した人と承認する人を分ける」のが基本です。同じ人が作成と承認の両方をできると、内部統制上の確認が形だけになります。金額によって承認者を変える場合は、その閾値を権限設計の中で明記しておきます。承認の流れが複雑な場合は、権限設計とは別にワークフローとして整理する方がすっきりします。

代理操作

休暇中の担当者に代わって別の人が操作する場面は必ずあります。代理を認める場合は、「誰が誰の代理として、いつからいつまで」を登録できる仕組みにし、操作の記録には代理であることが残るようにします。担当者のIDとパスワードを共有して代わりに操作する運用は、記録上の責任があいまいになるので避けるべきです。

緊急時の特権

障害対応などで、普段は誰も持っていない強い権限が一時的に必要になることがあります。その場合は、事前に決めた手順で期限付きの権限を付与し、終わったら必ず外す、という運用を決めておきます。誰がいつ特権を使ったかは、操作ログに確実に残すことが前提です。操作ログの設計については 管理画面の操作ログ設計 で詳しく説明しています。

権限設計のチェックリスト

開発会社に要件を渡す前に、次の項目を確認しておくと抜け漏れを防げます。

• 管理画面にログインする可能性のある立場をすべて洗い出したか（社外の利用者、委託先を含む）
• 機能ごとに、閲覧・作成・編集・削除・承認・出力のどれができるかを表にしたか
• データ範囲（全件、自部署、自担当、特定取引先）を操作とは別に整理したか
• 項目単位で隠したい情報（金額、個人情報など）を特定したか
• 詳細画面、CSV出力、ダウンロード、集計画面、通知メールにも同じ制御が必要だと伝えたか
• 作成者と承認者を分ける必要がある業務を特定したか
• 代理操作と緊急時の特権について、付与と解除のルールを決めたか
• 入社・異動・退職時に、誰が権限を変更するかを決めたか
• 権限の棚卸し（定期的な見直し）の頻度と担当を決めたか
• 権限の変更そのものが記録に残るようになっているか

よくある失敗とその避け方

権限まわりの失敗は、リリース直後よりも運用が始まって数か月後に表面化することが多いのが特徴です。

失敗1：全員を管理者にして運用を始める 「最初は人数が少ないから」と全員に最上位の権限を付けると、後から権限を絞るときに「今までできたことができなくなった」という反発が起きます。最初から最小限の権限で始め、必要に応じて広げる方が、運用の摩擦は小さくなります。

失敗2：ロールの意味を誰も説明できない ロール名だけが残り、どのロールに何ができるのかを説明できる人がいなくなるケースです。権限表を要件定義の成果物として残し、権限を変更するたびに更新する運用を決めておきましょう。

失敗3：退職者・異動者のアカウントが残り続ける 人事の情報と管理画面のアカウントが連動していないと、退職者のアカウントが有効なまま残ります。社内のアカウント管理の仕組み（シングルサインオンなど）と連携できるなら検討する価値がありますし、難しい場合でも、定期的な棚卸しを業務として組み込むことが重要です。

失敗4：細かすぎる権限設定画面を作る 「あらゆる権限を画面から自由に設定できるように」という要望は、一見柔軟に見えますが、設定の組み合わせが膨大になり、テストも運用も難しくなります。設定できる範囲はロールの割り当てと少数のフラグに絞り、ロールの定義そのものは開発側で管理する方が、多くの場合は安全です。

失敗5：権限の不具合をテストで確認していない 「できるべきことができるか」は確認しても、「できてはいけないことができないか」の確認が漏れがちです。受け入れテストでは、権限のないユーザーでログインして、URL直打ちやCSV出力を試すテストケースを必ず入れてください。

マルチテナントやSaaSの場合の考え方

自社で使う管理画面ではなく、複数の顧客企業が使うSaaSの管理画面を作る場合は、もう一段階の設計が必要になります。顧客企業ごとにデータを分離したうえで、顧客企業の中での権限（管理者、一般ユーザーなど）を顧客自身が設定できるようにする必要があるからです。

この場合、「自社の運営者が使う管理画面」と「顧客企業の管理者が使う設定画面」は、権限の考え方を分けて設計します。前者は自社の業務に合わせた権限、後者は顧客企業が自分たちの組織に合わせて使える汎用的な権限です。招待や組織管理まで含めた設計は SaaSの組織管理機能の設計 で詳しく扱っています。

よくある質問

Q. ロールはいくつくらいが適切ですか？

業務の種類によるので一概には言えませんが、社内向けの管理画面であれば、操作の種類が本当に違う立場の数だけ用意し、それ以外は属性やフラグで表すのが基本です。ロールの数が利用者の部署数に近づいてきたら、データ範囲をロールで表してしまっていないかを見直すサインです。

Q. 権限の設定画面は最初から作るべきですか？

最初の段階では、ロールの割り当て変更ができれば十分なことが多いです。ロールごとの権限内容まで画面で自由に変えられるようにすると、開発とテストの範囲が大きく広がります。運用してみて変更の頻度が高いと分かってから、設定画面を作り込む判断でも遅くありません。

Q. 既存のシステムの権限がぐちゃぐちゃです。作り直す前に何をすべきですか？

まず現在のユーザーごとに、実際にどの機能を使っているかを洗い出し、今回の手順で権限表を作り直すことから始めてください。ログが残っていれば実際の利用状況も参考になります。現状の権限を正確に把握しないまま新しいシステムに移行すると、移行後に「あの操作ができなくなった」という問い合わせが集中します。

Q. 取引先に管理画面の一部を使ってもらう場合の注意点は？

社内向けとは別のロールにし、データ範囲を「自社の取引に関するものだけ」に厳密に絞ることが前提です。加えて、取引先側の担当者の入れ替わりを誰が管理するのか（自社か、取引先の管理者か）を決めておかないと、退職した担当者のアカウントが残り続ける原因になります。

Otsumuに相談できること

利用者が十人程度で、立場の違いも「管理者」と「一般」くらいしかない管理画面であれば、この記事の手順で権限表を作り、既製の管理画面フレームワークや業務アプリの標準機能で十分に対応できます。外部に頼まず社内で進めて問題ないケースも多いはずです。

一方で、取引先や代理店も使う、部署ごとにデータの見え方を変えたい、承認や代理操作が絡む、既存システムの権限が複雑化していて整理し直したい、といった状況では、業務の理解と技術的な設計の両方が必要になります。権限の抜けは情報漏えいに直結するため、設計とテストの段階で経験のある第三者の目を入れる価値があります。

Otsumuでは、業務のヒアリングから権限表の作成、ロールとデータ範囲の設計、実装、受け入れテストの観点整理まで一貫して支援しています。自ら事業を運営する立場から、「運用し続けられる権限設計」を重視し、必要な機能に絞って短期間で形にします。管理画面の開発全般は 管理画面開発 のページで紹介しています。

権限の整理の段階からでも構いません。現在の状況をお聞きし、どこから手を付けるべきかを一緒に整理しますので、30分の無料相談 をご利用ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01