user、staff、admin、ownerは、すべてロールとして登録すべきですか？

すべてを同じロール列へ入れる必要はありません。userは認証された本人、staffはmemberの画面表示名、adminとownerは組織運営上の役割として分けます。さらに、店長や査定員などの業務担当はCapability Profileへ分離すると、プロダクトごとの名前の揺れを抑えながら実務上の違いを表せます。

各管理者が配下のスタッフを作れる設計は、どう表現しますか？

個人にひもづく子userではなく、OrganizationへのMembership招待として表現します。標準ではownerがadminとmemberを、adminがmemberを招待します。memberは原則招待不可とし、必要な場合だけmember_inviterを付与します。作成者は監査用に残しますが、権限上の親にはしません。

外部のシステム開発会社にはSuperadminアカウントが必要ですか？

保守用アカウントは必要ですが、常時万能なSuperadminは推奨しません。開発会社をservice_provider組織として分離し、対象顧客、理由、有効期限を持つSupport Sessionで一時アクセスさせます。標準は読み取り専用とし、なりすましはせず、支援者本人の操作として監査ログへ残します。

メニューを非表示にすれば権限制御として十分ですか？

十分ではありません。メニュー非表示は利用者への案内であり、リクエストの改変やAPI直接呼び出しを防げません。UIに加え、APIまたはBFFで招待・承認などの業務条件を確認し、データベースのRLSでOrganizationとScopeを行単位に強制します。Policyがない場合は拒否するDefault Denyが基本です。

小規模なMVPでも、すべての権限テーブルが必要ですか？

最初からすべての設定画面や中間テーブルを作る必要はありません。ただし、User、Organization、Membership、Governance Roleを混ぜないことは重要です。業務担当が一種類ならCapability Profileを固定値にし、複数所属がなければ切替画面を省略できます。概念の境界を保ったまま、必要な実装だけに絞ります。

なぜプロダクトごとにロール設計で迷うのか——22の権限定義を調べて作った共通設計

新しいプロダクトのロール設計で、user、staff、admin、superadminの違いを毎回考え直していませんか。

「管理者の配下にスタッフを作れるようにしたい」。要件は同じなのに、あるプロダクトではadminとstaff、別のプロダクトではowner、manager、user。同じような立場なのに名前が違い、逆に同じadminという名前でも、できることが違います。

そのまま開発を進めると、代理店や支店が増えるたびにロールを追加することになります。気づけば、メニューの表示条件とデータベースの権限制御がずれ、誰が誰を招待できるのかも曖昧になります。

AIで開発速度が上がるほど、この問題は小さくなりません。むしろ初期設計の揺れが、速い実装によって一気にコードへ広がります。AIセミナーは入口。でも入口で止まっている会社が多すぎる。実務で価値を出すには、AIに何を作らせるかだけでなく、毎回ぶれない設計の型を持つ必要があります。

研修やツール導入だけでは業務が変わらない理由は、AI研修をやっても成果が出にくい本当の理由でも整理しています。権限設計は、その「実務へ落とす仕組み」の一つです。

そこで、株式会社IIWAYO.TECHで扱っている既存プロダクトを横断し、13個のRLS権限マトリクスと、さらに9個のロール列挙定義、合計22モデルを実際に調べました。机上で「理想のRBAC」を考えたのではありません。いま動いている設計が、どこで揺れ、どこで再利用できないのかを確認したうえで、共通形を作りました。

結論は、固定すべきなのはロール名の長い一覧ではない、ということです。

固定すべきなのは、次の関係です。

User × Organization Context × Membership × Governance Role × Capability Profile × Permission × Scope × Condition

日本語にすると、こうなります。

人 × 操作中の組織 × 所属 × 組織運営上の立場 × 業務上の担当 × 許可された操作 × 対象範囲 × 実行条件

ロール設計をUser、Organization Context、Membership、Governance Role、Capability Profile、Permission、Scope、Conditionの8要素へ分離した図 ▲ ロール名の一覧を固定するのではなく、人・組織・所属・役割・担当・操作・範囲・条件の関係を固定します。

この8要素を分けるだけで、userなのかstaffなのかという名前の迷いと、権限を柔軟にした結果のセキュリティ低下を、同時に減らせます。

4つのロールだけでは足りない理由

最初に考えがちなのは、superadmin / admin / tenant / userの4つへ統一する案です。分かりやすく見えますし、小さなシステムでは実際に動きます。

ただし、この4語は種類の違うものを混ぜています。

userはログインする人です。tenantは利用組織です。adminは組織内の役割です。superadminは、自社運営者なのか、外部開発会社なのか、緊急保守用なのかが分かりません。

人、組織、所属、役割を同じ列に入れると、あとから次の質問に答えられなくなります。

同じ人が二つの会社に所属したら、ロールはどちらのものか
本部の管理者は、支店のデータを自動的に見られるのか
店長でありながら施術者でもある人を、どのロールにするのか
外部開発会社は、全顧客データを常時見られるのか
adminが作成したstaffを、別のadminが管理できるのか
最後のownerが自分を削除したら、誰が組織を管理するのか

ロール数を4つに減らすこと自体が問題なのではありません。異なる概念を4つの単語へ押し込めることが問題です。

Userは役割ではなく、本人を表す

共通設計の最初のルールは、userをロール名にしないことです。

Userは認証された本人です。Supabase Authでいえばauth.usersに対応する、ログイン主体です。氏名や表示名などのプロフィールは持ちますが、「どの会社で何ができるか」はUserだけでは決まりません。

同じ人が、自社では管理者、取引先では閲覧者、別のプロジェクトでは担当者ということは普通にあります。そのため、権限はUserに直接一つだけ付けず、UserとOrganizationを結ぶMembershipへ付けます。

この分離は、単なる正規化ではありません。ログイン後に「いま、どの組織として操作しているか」を明示できるようになります。OpenFGAの組織コンテキストに関する公式モデリング例でも、ユーザーと組織の関係を持ち、組織の文脈に応じてアクセスを判定する考え方が示されています（OpenFGA: Organization Context Authorization）。

Organizationは境界であり、tenantは種類の一つ

次に、会社、代理店、店舗、部署などをOrganizationとして扱います。

すべてを無理に同じ業務名称へする必要はありません。画面では「会社」「代理店」「店舗」と表示してよいのですが、権限モデル上はOrganizationという共通境界を持たせます。

IIWAYO AuthZ Coreでは、組織の種類を最低限、次の三つに分けます。

organization kind	意味	例
`service_provider`	システム提供・保守を担う組織	株式会社IIWAYO.TECH
`platform`	サービスや事業全体を運営する顧客企業	メーカー、本部、事業運営会社
`tenant`	プラットフォームを利用する顧客組織	代理店、加盟店、店舗、法人顧客

ここで重要なのは、tenantを人のロールとして使わないことです。テナントはデータ境界を持つ組織です。そのテナントに所属する人が、owner、admin、memberのいずれかになります。

親会社と子会社、一次代理店と二次代理店の関係は、Organization同士のRelationshipで表します。親子関係があるからといって、親が子の全データを無条件で読めるようにはしません。組織構造とデータ閲覧権限を分けるためです。

Membershipが「誰がどこに所属するか」を持つ

Membershipは、UserとOrganizationの関係です。

最低限、次の情報を持ちます。

user_id
organization_id
governance_role
status
valid_from / valid_until
invited_by

複数所属を許可するなら、同じUserに複数のMembershipがあって構いません。画面上では操作中のOrganization Contextを必ず選び、すべての権限判定でそのコンテキストを使います。

invited_byは監査情報です。「この人を招待した人の配下だから、その人にだけ管理される」という認可ルールにはしません。作成者を権限上の親にすると、管理者の退職や異動でツリーが壊れるからです。

人の管理権限は、組織に対する役割と明示的な権限で決めます。

組織運営の役割はowner、admin、memberに固定する

プロダクト間で固定するGovernance Roleは、原則として次の三つです。

role	組織運営上の意味	標準でできること
`owner`	組織の最終責任者	所有権移転、管理者任命、組織設定、請求・契約に関わる最終操作
`admin`	日常運営の管理者	メンバー招待、運用設定、担当割当、通常の管理操作
`member`	通常の所属者	割り当てられた業務の実行

読み取り専用利用者が多数必要なプロダクトだけ、viewerを追加候補にします。ただし、まずはmemberに読み取り系Capability Profileを付けて表現できないか検討します。

ここでstaffを標準ロールにしない点が重要です。

スタッフという言葉は、利用者には分かりやすい一方で、権限上の意味が曖昧です。ある製品のstaffは受注を編集でき、別の製品のstaffは閲覧だけ、さらに別の製品では店長までstaffに含まれます。

そこで、データベース上の標準値はmemberに固定し、画面の表示名だけを「スタッフ」「担当者」「従業員」「メンバー」へ変えます。

つまり、staffはDisplay Labelです。認可ロジックの語彙ではありません。

店長、査定員、施術者はCapability Profileで表す

owner、admin、memberだけでは、業務上の違いを表現できません。

しかし、ここでstore_manager、assessor、stylist、shipping_staffをGovernance Roleへ足し始めると、プロダクトごとにロール一覧が増殖します。

そこで、業務担当はCapability Profileとして分けます。

たとえば店舗運営システムなら、次のようになります。

Governance Role: member
Capability Profile: stylist
Permission: reservation.update
Scope: assigned
Condition: 予約日時の変更期限内

同じ人が店長兼施術者なら、Governance Roleはadmin、Capability Profileはstore_managerとstylistの二つを持てます。

これで「管理者だから全業務ができる」という誤った結合を避けられます。組織運営の権限と、現場業務の権限を別々に変更できます。

Permissionはresource.actionで書く

Permissionは、できる操作をresource.actionで表します。

例は次の通りです。

member.invite
member.role_change
order.read
order.update
price.approve
commission.update
audit.read

画面名やメニュー名ではなく、業務上の資源と操作で書くのがポイントです。メニュー構成が変わっても権限定義を使い続けられます。

NISTのRBAC解説でも、ロールをユーザーと権限の間に置き、ロール階層や職務分離を含めて管理する考え方が整理されています（NIST: Role Based Access Control FAQ）。

ただし、ロールだけでは「自分の案件だけ」「所属店舗だけ」「承認前だけ」を表せません。そのためScopeとConditionを分離します。

Scopeが「どこまで」を決める

標準Scopeは、次の五つから始めます。

scope	対象範囲
`self`	自分自身のデータ
`assigned`	自分に割り当てられた案件・顧客・予約
`unit`	所属部署、店舗、チーム
`org`	操作中の組織全体
`support_target`	承認された支援セッションの対象組織

たとえば、order.readを持っていても、Scopeがassignedなら担当注文だけです。orgなら組織全体です。

この分離によって、同じPermissionを複数ロールで再利用できます。メニュー単位で権限テーブルを作るより、変更時の影響を追いやすくなります。

Conditionが「その時点で実行してよいか」を決める

Conditionは、時刻、状態、金額、本人確認レベルなどの実行条件です。

例を挙げます。

下書き状態の申請だけ編集できる
承認済みの価格はownerでも直接変更できない
一定額を超える操作は別の承認者が必要
重要な権限変更では再認証を求める
支援セッションは有効期限内だけ使える

NISTのABACは、主体、対象、操作、環境などの属性を用いて認可を評価するモデルです（NIST SP 800-162）。IIWAYO AuthZ Coreは、すべてを自由な属性式にするのではなく、理解しやすいRoleとPermissionを軸にしながら、ScopeとConditionを必要な場所へ追加する形です。

柔軟性は持たせますが、権限付与者が任意の式を書ける仕組みにはしません。自由度が高すぎる認可は、設定画面を使う人が安全性を判断できなくなるからです。

「配下のstaffを作れる」を委譲ルールへ変換する

「各ロールは、その配下のstaffや子userを作れるようにしたい」という要望は、画面要件ではなく委譲ルールとして定義します。

標準は次の通りです。

ownerは、同一組織のadminとmemberを招待・任命できる
adminは、同一組織のmemberを招待できる
memberは、標準では誰も招待できない
招待業務を任せる場合だけ、member_inviter Capability Profileを付け、memberだけ招待できる
親Organizationのowner/adminは、許可された場合だけ子Organizationを作り、その初期ownerを招待できる
子Organization作成は、親Organizationのデータ閲覧権限を自動付与しない

配下にスタッフを作れるという要件を、作成者、付与可能ロール、対象範囲、実行条件の4段階で判定する委譲フロー ▲ 「親だから何でもできる」とせず、誰が・何を・どこまで・いつ付与できるかを委譲ルールとして判定します。

大切なのは、「自分が作ったユーザー」という所有関係を認可に使わないことです。

招待は組織に人を所属させる操作です。作成者個人の子ユーザーを作る操作ではありません。この違いを明確にすると、担当者交代や複数管理者でも破綻しません。

招待時には、招待できるRoleの上限もサーバー側で確認します。adminがリクエストを書き換えてownerを作れないようにします。UIのプルダウンからownerを隠すだけでは不十分です。

最後のownerを消してはいけない

ownerには、一般的なロール変更とは別の不変条件があります。

組織には必ず1人以上の有効なownerが必要です。そのため、最後のownerは次の操作をできません。

自分をadmin/memberへ降格する
自分のMembershipを削除する
自分を無効化する

ownerを交代する場合は、「新ownerを任命してから旧ownerを降格する」という所有権移転フローを用意します。二つの更新を一つのトランザクションとして扱い、途中でownerがゼロにならないようにします。

地味なルールですが、初期開発で抜けやすく、運用開始後に直すと影響が大きい部分です。

外部開発会社のアカウントは必要。ただしSuperadminにはしない

私たち株式会社IIWAYO.TECHのような外部開発会社が、保守や問い合わせ対応のためにログインする場面はあります。そのため、運用アカウント自体は必要です。

しかし、superadminという常時万能なロールを一つ作る設計にはしません。

superadminには、少なくとも三つの意味が混ざりやすいからです。

サービス提供会社の責任者
日常運用を行うオペレーター
顧客問い合わせに対応するサポート担当

この三者は、必要な権限もリスクも違います。

共通設計では、株式会社IIWAYO.TECHをservice_provider Organizationとして登録し、その中で次の役割を使います。

Governance Role	画面表示	想定用途
`owner`	System Owner	提供会社の最終責任、重要設定、緊急統制
`admin`	System Operator	日常運用、監視、契約された管理作業
`member`	System Support	問い合わせ対応、限定的な調査

内部の標準Roleは同じowner/admin/memberです。組織種別と画面表示によって意味を明確にします。

外部支援者がどこまで判断と実装を担うかという違いは、CTO顧問・外部CTO・開発伴走の違いでも整理しています。契約上の立場とシステム上の権限を、同じsuperadminへ押し込まないことが重要です。

顧客データを見るときはSupport Sessionを発行する

System Supportが顧客組織を調査するときは、常時アクセスではなくSupport Sessionを使います。

Support Sessionには、最低限次を記録します。

対象Organization
問い合わせ番号または承認根拠
調査理由
開始時刻と有効期限
実行者
読み取り専用か、承認済み修復操作か
実行した操作の監査ログ

標準は読み取り専用です。顧客画面には「現在、サポートアクセス中」と分かる表示を出します。有効期限が切れれば自動でアクセスできなくなります。

支援中でも、価格承認、返金承認、コミッション変更、メンバー招待、ロール変更、所有権移転はできません。修復が必要な場合は、対象操作を限定した別ワークフローとして承認します。

顧客になりすましてログインするImpersonationも標準では使いません。操作主体が顧客本人に見えると、監査ログの意味が壊れるからです。支援者のUser IDと対象Organizationを両方記録し、誰が何の理由で行ったかを残します。

また、Supabaseのservice_roleキーやインフラ管理者権限を、アプリのSystem Supportアカウントと混ぜてはいけません。service roleはRLSを迂回できるため、バックエンドの限定された処理だけで使い、ブラウザへ出しません。外部開発会社のログインアカウントと、インフラ秘密情報は別物です。

メニューを隠すだけでは権限にならない

画面でメニューを非表示にすることは、使いやすさのために必要です。しかし、それだけでは認可になりません。

利用者は、ブラウザからAPIを直接呼んだり、リクエストのRoleやOrganization IDを書き換えたりできます。そのため、最終的なデータアクセスはデータベースとサーバー側で拒否する必要があります。

PostgreSQLのRow-Level Securityは、行ごとにSELECT、INSERT、UPDATE、DELETEの可否を制御できます。RLSを有効にし、適用可能なPolicyがなければ原則拒否になる仕組みです（PostgreSQL 18: Row Security Policies）。

Supabaseも、公開スキーマのテーブルへRLSを有効化し、Policyでアクセス条件を定義する運用を案内しています（Supabase: Row Level Security）。

IIWAYO AuthZ Coreでは、次の三層をそろえます。

UI: 権限がない操作を見せない、または理由付きで無効化する
API/BFF/Edge Function: 高リスク操作、状態遷移、招待上限、職務分離を検証する
Database RLS: 対象OrganizationとScopeを行単位で強制する

メニューの表示制御だけではAPI経由でデータへ到達できる一方、RLSとサーバー判定ではデータアクセス自体を拒否できることを比較した図 ▲ UIは操作を案内し、APIは業務ルールを検証し、データベースが最後の境界を強制します。

UIは案内役、APIは業務ルール、RLSは最後のデータ境界です。どれか一つだけではなく、役割を分けて重ねます。

権限判定は毎回同じ順番で行う

判定順も共通化します。

有効なSessionか
Userが対象Organizationへ有効なMembershipを持つか
操作中のOrganization Contextが明示されているか
Governance RoleまたはCapability ProfileからPermissionが得られるか
Scope内の対象データか
状態、期限、金額などのConditionを満たすか
明示的なDenyや職務分離ルールに違反しないか
必要なら再認証し、Audit Eventを記録したか

複数の許可がある場合でも、明示的なDenyと職務分離を優先します。

たとえば、価格を作成する権限と承認する権限の両方を持っていても、「自分が作成した価格を自分で承認できない」というConditionを置けます。Role名だけでは表せない業務統制です。

データモデルは役割ごとにテーブルを増やさない

新しい担当種別が増えるたびに、admins、staffs、managers、assessorsという人物テーブルを増やす設計は避けます。

標準の中心テーブルは次の通りです。

profiles: Userのプロフィール
organizations: 組織とorganization kind
organization_units: 部署、店舗、チーム
organization_relationships: 親子、代理店、委託など組織間関係
memberships: UserとOrganizationの所属、Governance Role
capability_profiles: 業務担当の定義
membership_capability_profiles: 所属と業務担当の関連
permissions: resource.actionの定義
role_permissions: Governance RoleからPermissionへの対応
profile_permissions: Capability ProfileからPermissionへの対応
invitations: 招待、期限、招待可能Role
support_sessions: 支援対象、理由、TTL、モード
audit_events: 権限変更と重要操作の証跡

この構造なら、査定員や施術者などの担当が増えても、UserやMembershipの基本形を変えずに済みます。

ただし、すべての小規模プロダクトで全テーブルを最初から実装する必要はありません。概念は共通化し、MVPでは必要な部分だけ使います。

単一組織で業務担当が一種類なら、Capability Profile用の画面を作らず固定設定でも構いません。複数所属がなければOrganization Context切替画面も不要です。それでも、UserとRole、Organizationを同じ列へ潰さないことが重要です。あとから拡張するときの境界を残せます。

匿名案件で見えた「階層」と「権限」の違い

今回の整理で特に分かりやすかったのが、メーカー、一次代理店、二次代理店、各社スタッフ、製品を購入する一般顧客が登場する販売管理システムです。

最初は、メーカー管理者、メーカースタッフ、代理店管理者、代理店スタッフ、顧客という五つのRoleへ整理できそうに見えました。

しかし、実際には次の論点がありました。

一次代理店の下に二次代理店を作る
一人が複数代理店へ所属する可能性がある
メーカー側の価格・料率・承認権限は代理店へ渡せない
外部開発会社が問い合わせ対応でログインする
一般顧客は管理組織の階層外にいる

これを一つのRole列だけで表すと、階層と担当と顧客区分が混ざります。

共通設計へ写すと、次のようになります。

旧来の呼び方	Organization	Governance Role	Capability Profile / Actor Type
メーカー管理者	platform	owner/admin	maker_governance
メーカースタッフ	platform	member	maker_operations
代理店管理者	tenant	owner/admin	agency_governance
代理店スタッフ	tenant	member	agency_operations
一般顧客	組織Membershipの外	なし	external customer
IIWAYO支援担当	service_provider	member	system_support + Support Session

一次代理店と二次代理店はRoleの上下関係ではありません。二つのOrganizationのRelationshipです。一次代理店が二次代理店を作れることと、二次代理店の受注をすべて見られることも別Permissionです。

一般顧客もuserという内部Roleにはしません。ログインUserではありますが、Organizationを運営するMembershipとは別のActor Typeです。自分の製品登録や問い合わせだけをself Scopeで操作します。

この分解によって、既存の画面表示は大きく変えず、裏側の認可だけを一貫させられます。

22モデルを見て分かった、名前より危険な三つのずれ

既存定義を横断して感じたのは、名称の不一致だけなら検索と置換で直せるということです。危険なのは、同じ名前の背後にある意味のずれです。

一つ目は、Organization境界のずれです。

あるプロダクトではtenant_id、別ではcompany_id、さらに別ではagency_idがデータ境界になっていました。名称が違うこと自体より、どのテーブルで必須なのか、親組織が子組織を見られるのかが暗黙になっていることが問題でした。

二つ目は、RoleとPermissionのずれです。

adminなら全操作可能という実装と、adminでも価格変更不可という実装が混在すると、共通UIや機能カタログを再利用できません。Governance Roleの意味を固定し、製品固有の差はCapability ProfileとPermissionへ出す必要があります。

三つ目は、画面とRLSのずれです。

メニューを隠しているから安全だと思っていても、RLSがOrganizationを確認していなければ直接クエリで読めます。逆に、RLSだけが厳しく画面が理由を説明しなければ、利用者には不具合に見えます。

共通設計は、データベースだけのテンプレートではありません。要件、画面、API、RLS、監査、テストで同じ語彙を使うための契約です。

初期開発で必ず決める質問

新しいプロダクトでは、Role名を考える前に次の質問へ答えます。

組織境界

データを分離するOrganizationは何か
service_provider、platform、tenantのどれが存在するか
一人の複数Organization所属を許すか
親子Organizationはあるか
親が子のデータを見るPermissionは本当に必要か

人と担当

Governance Roleはowner/admin/memberで表せるか
staffは画面表示名として扱えるか
製品固有の担当をCapability Profileへ分けたか
外部顧客や応募者を内部Membershipへ混ぜていないか
バッチやAIエージェントを人のRoleへ混ぜていないか

委譲

ownerは誰を招待できるか
adminはmemberだけを招待できるか
memberに招待権限が必要なら、明示的なProfileにしたか
子Organizationを作れる人と、子データを読める人を分けたか
最後のownerを保護したか

支援と監査

外部開発会社のOrganizationを分離したか
Support Sessionに対象、理由、TTLがあるか
読み取り専用を標準にしたか
Impersonationを避け、実行者を記録しているか
Role変更、招待、重要操作をAudit Eventへ残すか

強制場所

UIだけでなくAPIとRLSで拒否するか
RLSはDefault Denyになっているか
service_roleをブラウザへ出していないか
cross-tenantの否定テストがあるか
自己昇格、最後のowner、期限切れSupport Sessionをテストするか

この質問へ先に答えれば、画面を作り始めてから「staffとは誰か」を議論する回数が減ります。

既存プロダクトは一気にRole名を変えなくてよい

すでに運用中のプロダクトで、Role enumを一括変更するのは危険です。RLS、Edge Function、画面条件、通知、監査ログ、テストが同じ文字列を参照している可能性があるからです。

移行は、次の順で進めます。

現在のRoleと実際のPermissionを棚卸しする
各RoleをOrganization kind、Governance Role、Capability Profileへ写像する
現行Roleを互換ラベルとして残し、新モデルから意味を導出する
RLSとAPIをOrganization ContextとMembership基準へ移す
cross-tenant、自己昇格、最後のownerを否定テストする
画面表示を新しい共通語彙へ段階的に合わせる
参照がなくなってから旧Role enumを廃止する

先ほどの匿名案件なら、既存のmaker_adminやagency_staffをすぐ削除しません。maker_adminをplatform.owner/admin + maker_governanceへ、agency_staffをtenant.member + agency_operationsへ写像します。

既存挙動を守りながら、次の開発から共通設計へ寄せます。

共通化とは、巨大な権限エンジンを作ることではない

権限設計を入念に考えると、すべてを設定可能にしたくなります。Role作成画面、Permission編集画面、条件式ビルダー、階層継承設定まで作れば、どんな製品にも対応できそうです。

しかし、初期開発の目的は権限管理製品を作ることではありません。

共通化するのは、概念、命名、判定順、守るべき不変条件です。製品の要件が固定されているなら、RoleとPermissionの対応はコードやマイグレーションで固定して構いません。

管理画面から自由にPermissionを書き換えられる機能は、必要性が確認できたときだけ作ります。価格や料率、個人情報、承認に関わるPermissionほど、固定ロールとサーバー側検証の方が安全です。

「何でも設定できる」ことと、「安心して運用できる」ことは同じではありません。

迷わないために固定するもの、製品ごとに変えるもの

最後に、境界を明確にします。

毎回固定するものは次です。

Userは本人であり、Roleではない
Organizationはデータと運営の境界
UserとOrganizationはMembershipで結ぶ
Governance Roleはowner/admin/memberを基本にする
staffはDisplay Label
業務担当はCapability Profile
操作はPermission、範囲はScope、状態はCondition
招待は個人の子user作成ではなく、Organizationへの所属作成
最後のownerを守る
外部開発会社はservice_providerとして分離し、Support Sessionで対象を限定する
UI、API、RLSの三層で同じ判断を強制する

製品ごとに変えるものは次です。

Organization kindの表示名
Capability Profileの種類
Permissionの業務語彙
Scopeの対象列と所属単位
Conditionの業務ルール
誰が子Organizationを作れるか
どの操作に再認証や二者承認が必要か

ロール名を毎回考えるのではなく、固定枠へ製品固有の業務を当てはめます。

この型の価値は、設計書がきれいになることだけではありません。AIや開発者へ「admin画面を作って」と曖昧に指示する状態から、「tenant.adminはmemberを招待できる。ただしownerを任命できない。agency_operationsはassigned scopeの注文を更新できる」と、検証可能な指示へ変えられます。

初期開発で迷う時間を減らし、あとから権限を足すときも、セキュリティを崩さない。

それが、22の権限定義を調べて作ったIIWAYO AuthZ Coreの狙いです。

自社のロールを共通形へ整理したい方へ

新規プロダクトの権限設計や、既存システムのRole・RLS整理で迷っている場合は、現在のRole一覧と組織構造から、この共通形への写像を一緒に整理できます。

株式会社IIWAYO.TECHでは、画面上のメニューだけでなく、Membership、Permission、Scope、RLS、API、監査、否定テストまでを一つの設計として確認します。AI時代のシステム開発支援として、設計段階から整理したい方はご相談ください。