Feature / Auth 05

FW 管理側 公開側

ロール権限

管理者、担当者、閲覧者、承認者などの役割ごとに操作範囲を分けます。

ロール権限は、利用者を役割ごとに分け、画面表示、登録、編集、削除、承認、出力などの操作範囲を管理するための機能です。Roundtableでは「どんな役割があるか」「各役割が何を見て、何を変更できるか」「公開側や顧客ポータルにも同じ考え方を使うか」を先にそろえると、発注者、実装者、AIに指示する人が同じ前提で権限設計を進められます。

管理者、担当者、閲覧者、承認者のロールごとに操作範囲を設定する画面例

この機能でできること

管理者、担当者、閲覧者、承認者、店舗管理者、顧客担当などのロールを定義し、各ロールに許可する画面、ボタン、データ範囲、承認操作、CSV/PDF出力を分けられます。利用者にはロールを割り当て、所属や担当範囲と組み合わせて、業務に必要な操作だけを使える状態にします。

役割ごとに「見える」「変更できる」「承認できる」を分けるための基本設計です。 ユーザー管理、画面アクセス制御、レコード権限制御、操作ログと合わせると、誰がどこまで扱えるかを運用中も説明しやすくなります。

よくある利用場面

管理者と担当者を分ける 管理者は設定変更やユーザー管理まで行い、担当者は自分の案件登録、編集、対応履歴の更新に限定します。
閲覧者や承認者を用意する 閲覧専用ユーザーは内容確認だけ、承認者は申請や見積の承認だけを行えるようにします。
公開側ポータルの利用範囲を分ける 顧客、代理店、店舗担当など、ログイン後に見えるメニューや操作できるデータを役割ごとに変えます。

プロンプト例

ロール名、対象ユーザー、許可する画面、許可する操作、データ範囲、初期ロール、権限変更できる人をまとめて伝えると、実装範囲が明確になります。

プロンプト 管理側にロール権限を追加してください。ロールは管理者、担当者、閲覧者、承認者の4種類にし、管理者は全操作、担当者は案件の登録・編集、閲覧者は参照のみ、承認者は承認ボタンだけ実行できるようにしてください。ユーザー管理画面では各ユーザーにロールを設定できるようにし、権限外のボタンは表示しないか実行時に拒否してください。ロール変更は操作ログに残してください。

この機能を使うときのポイント

ロールの数細かく増やしすぎると運用が難しくなるため、最初は管理者、担当者、閲覧者、承認者など代表的な役割に絞ります。
操作単位画面閲覧、追加、編集、削除、承認、CSV出力、設定変更など、制御したい操作を具体的に分けます。
データ範囲ロールだけで足りない場合は、所属部署、店舗、担当者、顧客との関係で見えるレコードを絞ります。
変更できる人誰がロールを付与、変更、解除できるかを決め、権限変更の履歴を確認できるようにします。

この機能を実装するときのコツ

実装では、ロール名だけで判定を散らさず、画面、操作、データ範囲に対する許可を共通関数や設定で確認できる形にします。画面側でボタンを隠すだけではなく、保存、削除、承認、出力などの実行関数でも権限を確認します。公開側ポータルで使う場合も、ログイン中ユーザーのロールと対象レコードの関係をサーバー側で確認し、URLを直接開かれても権限外データを返さない構成にします。テストでは、各ロールで表示されるメニュー、押せるボタン、直接アクセス、CSV/PDF出力、ロール変更履歴を分けて確認します。