使いやすいSaaSの権限設計【2026年最新】役割を撤廃しアカウントごとの権限に変えた実例

社内システムやSaaSを作っていて、いちばん揉めるのが権限まわりの画面です。機能そのものは動いているのに「誰に何を見せるのか」が決められず、リリース直前まで仕様が揺れる。運用が始まってからも「この人にレポートだけ見せたい」「この顧客のぶんだけ任せたい」という追加要望が止まりません。

当社では広告運用のレポートを自動生成するSaaSを自社開発しています。最初は「オーナー／マネージャー／メンバー」という3段階の役割で権限を分けていましたが、運用してみると役割の名前が誰にも伝わらず、設定ミスも起きました。そこでオーナーだけを特別扱いし、それ以外は全員同格にして、アカウントごとに機能権限を割り当てる形へ作り直しました。

この記事では、その過程で分かったことを、画面の作り方（UI）とサーバー側の守り方（セキュリティ）の両面からまとめます。段階的な役割をやめる判断、わかりやすさのための2段構えの設定画面、そして権限の自己昇格を止めるルールの書き方まで、他のシステムでも使える形で整理しました。

「マネージャー」「メンバー」が伝わらない3つの理由

権限の画面を作るとき、開発側はほぼ必ず役割（ロール）から設計します。データとしても扱いやすく、実装も早い。ところが使う側は、役割では考えていません。

1. 役割名は組織の言葉、権限は画面の言葉

「マネージャー」と書かれていても、それが自社システムの中で何をできる人なのかは名前からは分かりません。当社の画面には最初、こんな説明が出ていました。

マネージャー：他のメンバーの権限を変えられる。どの顧客・案件を見せるかの割り当てが主な役割です。

この文を読んだ本人から出た言葉が「概念がよく分からない」でした。実際、社内の役職とシステムの役割は一致しません。役職が課長でも、システム上はレポートだけ見れば十分な人がいます。逆に、アルバイトでも入稿作業のために編集権限が必要になります。組織の肩書きを権限の名前に借りると、必ずこのズレが出ます。

2. 役割に「おまけの特権」が付いてしまう

当社の実装では、マネージャーは「他人の権限を変えられる」役割として足しました。ところがコードでは、オーナーと同じ扱いで権限チェックを素通りさせていました。

// 修正前：マネージャーは機能ごとの権限を見ずに全部通していた
const isPrivileged = role === "owner" || role === "admin" || role === "manager";

つまり「メンバー管理を任せたい」だけで追加した役割なのに、実際には顧客情報を除くすべての機能が開いていました。画面には機能ごとの権限を設定するスイッチが並んでいるのに、マネージャーに対しては1つも効いていない。設定した人の意図と、システムの挙動が食い違っている状態です。役割は一度作ると「その役割なら、まあこれも許していいか」で権限が付着していきます。

3. 役割が増えるほど例外が掛け算で増える

運用していると、役割の枠に収まらない要望が次々と来ます。当社で実際に出たものだけでも、こうなります。

• 顧客に渡す、レポートを見るだけのアカウント（管理画面のトップすら見せたくない）
• 制作だけを担当し、広告の数値は見るが予算は触らせないアカウント
• 媒体APIのデータ取得だけ止めたいアカウント（操作ミスで同期を連打されると費用がかかる）
• 特定の案件だけ任せたい外部パートナーのアカウント

これを役割で表現しようとすると「閲覧マネージャー」「制作メンバー」「同期なしメンバー」と役割が増え続けます。役割の数は、機能の数と組織の都合の掛け算で増えるので、どこかで必ず破綻します。

ロールベース（RBAC）と権限ベース、どちらで作るか

権限の設計方式は、大きく分けて次の3つです。

それぞれの実装方法はNext.js RBAC完全ガイドとNext.js ABAC完全ガイドで詳しく扱っています。認可そのものの考え方はNext.js 認可完全ガイドが入口になります。

教科書的にはRBACが基本形です。ただしRBACが機能するのは「役割が安定している」ことが前提で、社内システムやBtoBのSaaSでは、その前提がしばしば成り立ちません。1社ごとに体制が違い、同じ会社でも半年で担当が変わります。

判断の目安はこうです。役割の種類を書き出してみて、3つを超えても説明が1行で書けるならRBAC、書けないなら権限ベース。当社は「オーナー」「マネージャー」「メンバー」の3つですでに説明できなくなっていたので、権限ベースに寄せました。

オーナーだけ特別にして、残りは全員同格にする

作り直した後の構造は、次のように単純です。

• オーナー：そのワークスペース（アカウント）を作った本人だけ。課金も設定も含めて何でもできる。1つのワークスペースに1人
• 運営管理者：当社側の保守用。画面からは付与できず、データベースを直接触らないと作れない
• それ以外：全員同じ立場。できることは、そのアカウントに付いた権限だけで決まる

そして「できること」を、はっきり2つの軸に分けました。

1. 何ができるか：機能ごとに「不可 / 閲覧のみ / 編集できる」の3段階（レポート、案件、クリエイティブ、予算、キーワード、メンバー管理など）
2. どのデータに対してか：担当する顧客と案件の割り当て（複数選択）

この2軸に分けたことで、画面の説明が1行で書けるようになりました。「選んだ顧客・案件の範囲で、ここで決めた操作ができます」。役割の名前を覚える必要がなくなり、設定した内容がそのまま挙動になります。

副作用として権限の説明文が短くなったのも効果がありました。役割があると「この役割は権限設定に関係なく全機能を扱えます。ここでの設定は役割をメンバーに変えたときに効きます」といった、例外を説明する長い注記が必要になります。例外をなくせば、注記も消えます。

「メンバー管理」も1つの機能権限にする

役割を撤廃するとき、最後に残る問題が「他人の権限を変えられる人」をどう表すかです。これはメンバー管理という機能の権限として扱えば足ります。閲覧だけなら一覧が見える、編集まで許せば権限と担当を変えられる、削除まで許せばアカウントを止められる。ほかの機能とまったく同じ形にできます。

ここを役割に戻したくなる気持ちは分かりますが、戻すと「権限を変えられる人は、ついでに全部できる」という元の問題がそのまま復活します。

わかりやすさは「簡易」と「詳細」の2段構えで作る

機能ごとの権限に分解すると、こんどは項目が増えます。当社の場合、機能は15個あり、それぞれ3段階、加えてデータ取得と制作フローのオン・オフがあります。全部を1画面に並べると、追加するたびに全項目を考えなければならず、これも使いにくい。

そこで設定画面を2段構えにしました。

簡易：名前の付いた4つの型から選ぶ

• レポート閲覧者：レポートを見るだけ。ダッシュボードも出さず、ログイン後はレポート一覧が開く。顧客に渡すアカウント向け
• プロジェクト閲覧者：担当範囲をひととおり見られるが、作成・編集はできない。媒体データの取得もしない
• プロジェクト運用者：見る・作る・直すができる（削除はできない）。データ取得も可
• プロジェクト管理者：顧客情報を除く全機能を削除まで扱え、メンバーの追加・権限変更もできる

大事なのは、このプリセットをデータとして保存していないことです。保存しているのは機能ごとの権限だけで、プリセットは「その組み合わせに名前を付けたもの」として扱います。画面側では、いま設定されている権限がどのプリセットと一致するかを判定して選択状態を表示します。

この作りにすると、プリセットを後から足しても既存アカウントに影響が出ません。逆にプリセットを保存値にしてしまうと、プリセットの定義を変えた瞬間に過去のアカウントの権限が黙って変わります。あとから地雷になる設計なので避けました。

詳細：機能ごとに自分で組む

型に当てはまらない人のために、機能ごとの設定も残します。切り替えはURLのクエリ（?perm=custom）に持たせて、リロードしても同じ画面が開くようにしました。設定作業は往復が多く、ブラウザの戻る・再読み込みで状態が消えるとやり直しになるためです。

簡易に戻したときに、型から外れた設定が残っていたら、いちばん近い型に寄せます。どちらでもない中途半端な表示を残さないほうが、迷いが減ります。

入力の順番を「人の考える順」に合わせる

もうひとつ効いたのが、追加画面の順番です。元は「名前・メール → 役割 → 機能権限 → 所属顧客 → 担当案件」の順でした。これを次に変えました。

1. 基本情報（名前・メールアドレス・パスワード）
2. 顧客（複数選択）
3. 案件（複数選択。顧客を選ぶと自動でチェックが入り、任せない案件だけ外す）
4. 権限（簡易 / 詳細）

人は「誰の、どの案件を任せるか」を先に決めてから「その中で何をさせるか」を考えます。先に権限を決めさせると、範囲が分からないまま強さを選ぶことになり、迷ったぶんだけ強い権限を選びがちです。範囲を先に確定させてから操作の強さを選ぶと、必要以上の権限を渡しにくくなります。

各セクションは開け閉めできるようにし、閉じているときは状態を1行で出します（「3社を選択中」「12件を選択中」「プロジェクト運用者」）。ここで1つ注意点があります。必須入力を含むセクションを折りたたむと、ブラウザの入力チェックが働かなくなります（要素が存在しないため）。送信時に足りない項目があれば、そのセクションを開き直してエラーを出す処理を入れておかないと、ボタンを押しても何も起きない画面になります。

使えない機能は「隠す」か「理由を書いて止める」か

権限の画面では、そのワークスペースでは使えない機能が出てきます。当社の場合、顧客情報の登録・編集はオーナー専用にしているため、ほかのアカウントには開けません。

選択肢は2つあります。項目ごと隠すか、「不可」で固定して理由を書くか。当社は理由を添えて固定する方を選びました。隠すと「顧客の権限はどこで設定するのか」と探し回ることになり、問い合わせが増えます。行に「オーナー専用」と出し、その下に「顧客の登録・編集はオーナーだけが行えます。メニューにも出ません」と書いておけば、探す時間がなくなります。

同じ考え方で、自分が所属していない組織の選択肢も出しません。顧客側の担当者としてログインしている人の画面に、当社（運営側）を指す「自社」という選択肢が並んでいた時期があり、これは紛れもなく分かりにくさでした。選べない・選ぶべきでないものは、最初から並べないほうが親切です。

画面だけで制限しても、権限は守られない

ここからはセキュリティの話です。権限の分かりやすさを整えても、判定が画面の中だけなら意味がありません。ブラウザの開発者ツールやAPIを直接叩けば素通りします。当社はNext.js＋Firebase（Firestore / Cloud Functions）で作っているので、次の3か所に同じ条件を書いています。

1. 画面：メニューやボタンの出し分け
2. Firestoreセキュリティルール：データの読み書き
3. Cloud Functions：アカウント発行などサーバー処理

条件が3か所にあると必ずズレます。ズレを前提に、判定は共通の関数に集約し、片方だけ直さないことをドキュメントに明記しました。Firebase Authenticationでの認証実装はNext.js Firebase Authentication完全ガイド、認証と認可の落とし穴はNext.jsの認証・認可セキュリティ実装ガイドで扱っています。

自分の権限を自分で書けないようにする

権限ベースにすると、最大の事故は自己昇格です。アカウント情報のドキュメントに権限が入っているので、本人がそれを書き換えられると、どんな権限でも手に入ります。

対策はルールの1行です。メンバー管理の権限を持つ人であっても、自分自身のドキュメントは管理経路で書けないようにします。

// Firestore セキュリティルール（抜粋）
allow update: if canManageMembers()
  // オーナー以外は自分自身のドキュメントをこの経路で触れない
  && (isOwnerRole() || request.auth.uid != userId)
  && resource.data.ownerUid == workspace()
  // 運営管理者の付与・解除はクライアントからは不可
  && (request.resource.data.role == resource.data.role
      || (request.resource.data.role != "admin" && resource.data.role != "admin"));

本人がプロフィール（名前・メールアドレス）を直すのは別の経路にして、変更できるフィールドを列挙で縛ります。権限・所属・ワークスペースIDはその列挙に入れません。

送られてきた役割を信用しない

アカウントを発行するサーバー処理では、リクエストに含まれる役割をそのまま保存してはいけません。当社の実装は常に一般アカウントとして作るように固定し、古い画面が強い役割を送ってきても昇格させません。付けるのは機能権限だけです。

あわせて、呼び出した人がメンバーを追加してよいかをサーバー側でも確認します。画面で隠しているから大丈夫、は通用しません。

未設定の既定値を「全部オフ」にする

権限のフィールドが無いアカウントをどう扱うかは、意外と事故の元です。キーが無いときは不可（オフ）に寄せるのが原則です。「未設定なら全部許可」にすると、機能を追加した瞬間に、既存の全アカウントへその機能が開きます。

当社は、権限の項目そのものが無い古いアカウントだけ既定値を当て、権限はあるのに特定のキーだけ無い場合は不可として扱っています。画面に表示している内容と実際の挙動を一致させるためです。

一覧の取得を絞り込みごと縛る

Firestoreのルールは「返ってくる全ドキュメントがルールを通る」必要があるため、一覧の取得は絞り込み条件を付けることが前提になります。オーナーはワークスペース単位で全件、それ以外は担当する顧客で絞ったクエリしか通らないようにしておくと、権限の穴がクエリの形で表現できます。

既存ユーザーを壊さずに移行する

すでに運用中のシステムで役割をやめるときは、移行の順番が肝心です。当社は次の順で進めました。

1. 新しく作れないようにする：画面から役割の選択を外し、新規アカウントは全員一般として発行する
2. 既存の役割は一時的に残す：古い役割が付いたアカウントは、移行が済むまで従来どおり通す分岐を1か所だけ残す
3. 保存のタイミングで移す：そのアカウントの権限を保存したとき、役割を一般に書き換えて権限だけで動くようにする
4. 移行後に分岐を消す：古い役割のアカウントが残っていないことを確認してから、互換コードを削除する

この順にしないと、移行の瞬間に権限が足りなくなった人がログインできても何も触れない状態になります。互換の分岐を1か所に閉じ込め、どこで消すかをコメントに書いておくのがコツです。消す予定を書いていない互換コードは、たいてい何年も残ります。

権限設計で確認したい項目

• 役割の説明を1行で書けるか。書けない役割は、権限に分解する候補
• 「何ができるか」と「どのデータに対してか」が分かれているか
• 権限の名前が、組織の肩書きではなく画面の操作で書かれているか
• 設定した内容と実際の挙動が一致するか（役割が権限を素通りしていないか）
• 本人が自分の権限を書き換えられないか
• サーバー処理が、送られてきた役割をそのまま保存していないか
• 権限が未設定のときの既定値が、不可に寄っているか
• 使えない機能を、理由とともに示しているか
• 設定の順番が、範囲（誰の・どのデータ）→操作の強さ になっているか
• 権限を変えたとき、何が見えなくなるかを画面で伝えているか

よくある質問

役割（ロール）は完全にやめるべきですか

いいえ。役割が安定していて種類が少ないなら、RBACのほうが設定は速く済みます。やめる判断は「役割の説明が1行で書けなくなったとき」「役割に例外的な特権が付き始めたとき」です。当社はオーナーという1つだけは残しました。課金と最終的な責任の所在は、権限に分解できないためです。

権限の項目が多すぎて選べないと言われます

項目を減らすのではなく、型（プリセット）を数個用意して、詳細設定は開かなくても完了できるようにします。現場で使われる型は、たいてい3〜5個に収束します。運用が始まってから、実際に設定された組み合わせを集計して型を決め直すと精度が上がります。

顧客に渡す閲覧専用アカウントはどう作りますか

当社は「レポート閲覧者」という型にして、ほかの機能とデータ取得・制作フローを全部オフにしています。重要なのはログイン後の着地点も変えることです。権限だけ絞って管理画面のトップに着地させると、使えないメニューが並んだ画面を見せることになります。見られる画面が1つなら、そこへ直接着地させます。

監査ログはどこまで必要ですか

権限を分散させると「誰がいつ誰の権限を変えたか」が追えなくなります。少人数のシステムでも、権限変更とアカウント発行・停止の履歴だけは残しておくと、トラブル時の調査が早く終わります。全操作のログを取る前に、この2種類から始めるのが現実的です。

まとめ

権限まわりの作りにくさは、技術よりも言葉の問題から始まります。組織の肩書きを借りた役割名は、使う人に伝わらないまま、コードの中で特権を抱え込んでいきます。当社はオーナーだけを特別扱いし、ほかは全員同格にして、アカウントごとに機能権限を割り当てる形へ切り替えました。設定した内容がそのまま挙動になるので、説明文が短くなり、設定ミスも減りました。

そのうえで、分かりやすさは型（簡易）と機能ごとの設定（詳細）の2段構えで作り、範囲を先に・操作の強さを後に決める順番にします。守りの側は、画面・データベースのルール・サーバー処理の3か所に同じ条件を書き、本人が自分の権限を書けないようにしておく。この2つを押さえておけば、あとから機能が増えても権限の設計は崩れません。

業務システムやSaaSの権限設計は、最初の1画面で決まった構造が数年残ります。設計の見直しや作り直しでお困りのことがあれば、システム開発の進め方や業務標準化の考え方とあわせて、おこじょデザインシステムにご相談ください。