2025年5月18日·1分で読めます

内部ツール向け権限マトリクス設計：ロールとスコープ

権限マトリクス設計は、画面や API を作る前にロール、スコープ、例外を可視化しておくことで、後の手戻りやアクセスミスを減らします。

権限マトリクスが解決する課題

内部ツールはチームが日常業務を回すために使うソフトウェアです。管理パネル、オペレーションダッシュボード、サポートコンソール、経理確認画面、承認やデータ修正、顧客対応を助ける小さなアプリなどを想像してください。

これらのツールは機密データや強力な操作に触れます。サポート担当は顧客プロフィールを閲覧する必要があっても、支払いの全情報は見てはいけないかもしれません。経理担当は請求書をエクスポートできてもアカウント設定を編集してはいけないことがあります。オペレーションリードは自分の地域のみ両方できるなど、ケースはさまざまです。

内部ツールは層を重ねて成長するため、権限はすぐに混乱します。新しいロールが生まれ、古いロールは分割され、一時的な例外が積み重なります。「Maria に返金を許可する」「契約業者はノートを見られないようにする」「チームリードは最大 $500 まで承認できる」といった個別対応が増え、ルールが人の頭の中や散在するチケットにしか残らないと、画面と API の乖離やセキュリティギャップが現れます。

権限マトリクス設計は、誰が何をどのデータに対して、どの制限下でできるかを一つの共有マップにすることでそれを解決します。これが UI（どの画面・ボタン・フィールドを表示するか）とバックエンド（誰かが UI をバイパスしてもサーバーが許可するか）双方の真実の源になります。

これは開発者だけのためのものではありません。良いマトリクスはプロダクト、オペレーション、実装者が合意できる作業文書です。AppMaster のようなノーコードプラットフォームで作る場合でも、ロールを設定し、リソースを定義し、画面と生成されるエンドポイントを整合させるためにマトリクスは必須です。

シンプルなマトリクスは以下を助けます：

構築前にルールを明示化する
「特別対応」の混乱を減らす
UI と API の権限を整合させる
アクセス変更を推測なしにレビューできるようにする

重要な用語：ロール、リソース、アクション、スコープ、例外

良い権限マトリクス設計は共通の言葉から始まります。チームが同じ言葉を使えば、後でルールが混乱するのを避けられます。

ロールは通常同じアクセスを必要とする職務ベースのグループです。Support、Finance、Ops、Manager など。ロールは日常の業務内容を表すべきで、役職のシニアリティではありません。1 人が複数のロールを持つことはありますが、なるべく稀にしてください。
リソースは保護対象です。内部ツールでは顧客、チケット、請求書、レポート、連携、設定などが一般的です。リソースは名詞で命名します。これにより後でルールを画面や API エンドポイントに落とし込みやすくなります。
アクションはリソースに対して行える操作です。動詞を一貫させてマトリクスを読みやすくします。典型的なアクションは：
view
create
edit
delete
approve
export
スコープは「どのレコードか？」に答え、ロールを増やさずにアクセス範囲を決めます。スコープは安全か危険かの差になることが多いです。一般的なスコープは：
own（自分が作成または担当するレコード）
team（自分のグループ）
region（自分の地域）
all（すべて）
例外は通常のロール・スコープルールを上書きするものです。例外は一時的（シフトをカバーする）、ユーザー固有（スペシャリストが一つ余分な操作を必要とする）、レコード固有（VIP 顧客レコードをロックする）などがあります。例外は管理された技術的負債として扱い、誰が承認したか、理由、期限を追跡してください。

例：Support 担当はスコープ "team" で「チケットを閲覧」できるが、あるインシデントレビューのために短期間だけ「チケットをエクスポート」する例外が与えられることがあります。AppMaster で構築する場合、こうしたルールはロール、リソース、アクション、スコープを一貫して命名しておけば管理がずっと楽になります。

マトリクスを描く前に決めること

守る対象を合意することから始めます。内部ツールの領域をスクリーンではなくリソースとしてリストアップしてください。1 つの画面に「注文」「返金」「顧客」が表示されていても、それぞれリスクが異なる別のリソースです。

最初にアクションの動詞を標準化してください。小さな言い回しの違いで重複したルールが生まれます（edit と update、remove と delete、view と read）。短く共通のセットを選び、すべてのリソースで守ってください。多くの内部ツールでは view, create, update, delete, approve, export のような単純なセットで足ります。

スコープは会社の実際の考え方に合わせて決めます。スコープが多すぎるとマトリクスが読めなくなり、少なすぎると例外だらけになります。組織構造に合う小さなセットを目指しましょう：

own（自分が作成したレコード）
team（自分のチームのレコード）
location（支店や地域）
all（全て）
none（アクセスなし）

「no（アクセスなし）」のルールも明確にしてください。明示的に禁止するのか、暗黙的に拒否するのか。暗黙的拒否（リストにないものはすべて拒否）は安全で単純です。広範なアクセスがあるが特定の操作だけブロックしたい場合は明示的禁止が有用です（例：「Finance はすべての請求書にアクセスできるが delete は禁止」）。

最後に、エクスポート、削除、支払い、ロール変更、個人データへのアクセスなどのコンプライアンス上重要なアクションは早い段階でマークしてください。これらは追加の承認ステップや詳細なログが必要になることが多いです。例えば、サポートリードは顧客プロフィールを更新できるが、支払い作成やエクスポートには Finance の承認が必要、などです。

AppMaster で構築する場合、これらの決定は後でバックエンドのエンドポイントや Business Process ロジックにきれいにマップされますが、まずマトリクスを明確にしておく必要があります。

ステップバイステップ：権限マトリクスをゼロから作る

画面ではなく人々の業務から始めてください。画面から始めると、今日の UI をコピーして本当のルール（誰が返金を承認できるか、ロック後に誰が顧客レコードを編集できるかなど）を見逃します。

権限マトリクス設計を行う簡単な方法は、タスクからアクセスへの地図として扱い、それを後でアプリに変換することです。

実用的な作成順序

業務タスクを平易な言葉で列挙する。例：「返金を発行する」「顧客のメールを変更する」「先月分の請求書をエクスポートする」。短く現実的に書く。
タスクをリソースとアクションに分解する。リソースは名詞（Invoice, Ticket, Customer）、アクションは動詞（view, create, edit, approve, export）。各リソースのオーナーを割り当てる：端的にエッジケースを説明でき、「これで良い」と言える一人。
安定したチームに基づいてロールを定義する。Support、Finance、Operations、Team Lead のようなグループを使う。頻繁に変わる肩書き（Senior、Junior）は本当にアクセスが変わらない限り避ける。
各ロールがタスクを完了するために必要な最小限のアクセスをマトリクスに埋める。Support が問い合わせ対応のために請求書を閲覧するだけで良ければ、デフォルトで「export」を与えないでください。後から追加はできますが、取り上げるのは習慣を壊します。
スコープは必要な場所だけに追加する。単純な「edit」権限の代わりに「edit own」「edit assigned」「edit all」のようにスコープを付けることで、50 個のロールを作らずに済みます。

例外はマトリクス内の散らかった注記にするのではなく、別のテーブルで管理してください。例外には理由フィールド（コンプライアンス、詐欺リスク、職務分離）と承認者を明確にし、有効期限を設けます。

これが出来たら、AppMaster のようなツールはマトリクスを保護されたエンドポイントと管理画面に変換しやすくなります。

マトリクスを使いやすく保つ構成方法

ドメインをエンドツーエンドでプロトタイプする

拡張する前に、小さな動作するスライスで Support と Finance のフローを検証します。

プロトタイプを試す

権限マトリクスは読みやすくないと役に立ちません。巨大なセルの壁になると誰も使わなくなり、権限が意図したものからずれていきます。

まずドメインごとに分割してください。すべてを一枚にするのではなく、Customers、Billing、Content のように領域ごとにタブを分けます。ほとんどのロールは数個のドメインにしか触らないため、レビューが速くなり誤操作を減らせます。

タブ間で一貫した命名パターンを使ってください。Resource.Action.Scope のようなシンプルなフォーマットは各権限の意味を明確にし、見た目は異なるが同じ動作をする重複を防ぎます。例：Invoice.Approve.Department は Customer.Edit.Own と同じ読み方のパターンです。

エッジケースに当たったら新しいロールを作る衝動に抵抗してください。セルの隣に短い注記を付け、例外がいつ適用されるかを説明します。例：Support は請求書を閲覧できるが、顧客が本人確認をした後に限る。注記は必要な追加 UI ステップを指すこともでき、ロールモデルを変えずに対応できます。

高リスクの権限をフラグ付けしてレビューで目立たせてください。返金、承認、エクスポート、削除などはそのような権限です。セルにマークを付け、二人承認やマネージャー確認など必要な追加チェックを書いておきます。

マトリクスを維持するためにバージョン管理をしてください：

v1, v2, … と日付
オーナー（責任者）
短い変更サマリ
変更のトリガー（新ワークフロー、監査所見）

マトリクスが安定すれば、AppMaster のようなツールで画面やエンドポイントを構築する際に、各ボタンや API アクションが明確な権限名にマップされます。

マトリクスを画面とエンドポイントに変換する

マトリクスは API と UI の両方で現実のルールになる必要があります。まずマトリクス内の各リソース（Tickets, Invoices, Users など）をエンドポイントグループとして扱い、アクションはマトリクスの動詞と一致させます：view, create, edit, approve, export, delete。

API 側では、すべてのリクエストで権限を強制してください。UI のチェックは可読性のために有益ですが、セキュリティにはなりません。隠したボタンは直接 API コールを止めません。

マトリクスを API 権限に翻訳する簡単な方法は、権限名を一貫させ、操作が起きる境界に付与することです：

tickets:view, tickets:edit, tickets:export
invoices:view, invoices:approve, invoices:delete
users:view, users:invite

同じ権限名を UI のゲート（メニュー、ページアクセス、ボタン、フィールド）に使ってください。例えば Support 担当はチケット一覧を見てチケットを開けるが、invoices:approve を持っていなければ「Refund」フィールドは読み取り専用にする、などです。

一覧（list）アクセスと詳細（detail）アクセスは分けて考えてください。存在だけ確認できれば良いが中身は見てはいけない場合があります。つまり一覧結果は限定されたカラムだけを返し、詳細ビューを開くには別の詳細権限や「自分に割り当てられている」等のスコープチェックを要求する、といった設計です。これを早めに決めておかないと、機密データを漏らす一覧画面を作ってしまいます。

最後に、重要なアクションには監査ログをマッピングしてください。エクスポート、削除、承認、ロール変更、データダウンロードは誰が、何を、いつ、どのレコードに対して行ったかを記録するべきです。AppMaster を使えば、エンドポイントロジックや Business Process のフローにこれを組み込めます。

よくあるミスと罠

ロールベースの画面を素早く設計する

スクリーンを書き直さずに、各ロールが見るべきページ・ボタン・フィールドだけを表示します。

UI を構築

最も早く権限マトリクスを壊す方法は、ビジネスではなく UI をモデル化することです。1 つの画面に複数のものが表示され、同じものが複数の画面に出てくることがあります。画面ごとにリソースを定義するとルールが重複し、エッジケースを見逃し、命名の議論に時間を取られてしまいます。

もう一つの罠はロールの増殖です。チームは（Support Level 1、Support Level 2、Support Manager など）どんどんロールを追加しがちですが、スコープを明確にするだけで十分なことが多いです。スコープ（own team、assigned region、accounts you manage など）は新しいロールよりも変化を説明しやすいです。

実際の内部ツールでよく見られるミス：

「view」と「edit」だけ定義して、export、bulk edit、refund、impersonate、change owner などのアクションを忘れる。
一時的な例外を長期のパッチとして使う（「Sam に 1 週間 Finance のアクセスを与える」などが恒常化する）。
UI にボタンを隠しておけば安全だと仮定する。API は依然としてリクエストを拒否する必要がある。
人がチームを移動したときや地域が変わったときに、スコープがどうなるか決めていない。権限は予測可能に更新されるべきで、放置してはダメ。
「admin」を無制限と扱う。管理者にもガードレールが必要なことが多い（例：「ユーザー管理はできるが支払い承認はできない」）。

例外は慎重に扱ってください。便利ですが期限付きかレビュー付きにしておかないと恒常化します。例外が増え続けるなら、ロールやスコープ設計がきれいでないサインです。

短い例：サポートと経理のツールでは、Support は顧客プロフィールを閲覧してチケットを作成でき、Finance は請求書をエクスポートして返金を発行します。ページだけを保護していると、Support が直接エクスポートのエンドポイントを叩けてしまう可能性があります。カスタムコードでも AppMaster のような生成バックエンドでも、ルールはサーバー側に置くべきです。

構築前の簡単チェックリスト

管理と承認を分離する

ユーザー管理とビジネスの重要操作を分離する管理パネルを作成します。

管理画面を作る

権限マトリクスは明確で実行可能なルールになってこそ役に立ちます。最初の画面やエンドポイントを作る前に次を確認してください。

ルールを作ってから UI を作る

デフォルト拒否（明示的に許可されていないものはブロック）を採用してください。これが最も安全なベースラインで、新機能追加時の意外なアクセスを防ぎます。

権限の単一の真実の場所を決めてください。ドキュメント、データベースのテーブル、ノーコード設定のどれに置くかをチーム全員が知っていること。スプレッドシートとアプリで食い違うとバグになります。

コンパクトな事前チェックリスト：

デフォルト拒否がすべての箇所で強制されている（UI ボタン、API エンドポイント、エクスポート、バックグラウンドジョブ）。
各アクションに明確なスコープ定義がある（own record, team, region, all, named subset）。
管理者機能は業務アクションと分離されている（ロール管理は「返金承認」と同じではない）。
機密アクションは強い管理（承認ステップ、ログ、アラート）を要求する。
例外にはオーナーと有効期限がある。

その後、現実的なシナリオでルールを一つ検証してください。例：「サポート担当は自分の地域の注文を閲覧してメモを追加できるが、価格を編集したり返金を発行したりできない。経理は返金を発行できるがマネージャー承認が必要で、すべてログに残る。」一言か二言で説明できなければ、スコープや例外がまだ不明瞭です。

AppMaster を使う場合、これらは画面とビジネスロジック両方の要件として扱ってください。ボタンで操作を隠せても、バックエンドルールだけが強制できます。

例：サポートと経理の内部ツールシナリオ

中規模企業を想定し、Support と Finance が使う内部ツールを考えます。同じ DB に Customers, Tickets, Refunds, Payouts, Settings（テンプレートや連携など）が入っているケースです。単純なログインチェックでは不十分です。

まず次のロールを用意します：

Support Agent：1 つのキューでチケットを処理する
Support Lead：複数キューをサポートし一部アクションを承認する
Finance：金銭に関連する業務を担当
Ops Admin：アクセス管理とシステム設定の責任者

実務的なマトリクス設計は、まずリソースごとのアクションを書き、スコープで絞ることから始まります。

チケットについては、Support Agent は割り当てられたキューのチケットのみ閲覧・更新できます。ノートは追加できるがチケットの所有者は変更できません。Support Lead は Support Agent の権限に加え、自分の地域内でチケットを再割り当てできます。

返金については、Finance が返金を作成・承認できるが金額上限を設けるなど制限があります。Support は返金リクエストを作れるが承認はできません。承認は作成と別のアクションとして明確に分けておくことで、誤って付与されることを防げます。

Payouts と Settings は厳格に：Payouts は Finance のみ閲覧、Settings は Ops Admin のみ変更可能。Support はこれらの画面を見られないようにしておくと誤操作や誘惑を減らせます。

例外ルールを追加します：Support Lead が 2 週間別地域をカバーする。広範なロールを与える代わりに、期限付きのスコープ拡張（Support Lead + Region B、期限付き）をマトリクスに記録します。これだけで権限のコピーより安全です。

AppMaster で構築すれば、このマトリクスが UI に表示されるページとバックエンドの許可を同時に導くので、Payouts や Settings に API を直叩きしても到達できないようにできます。

時間経過でのテストとメンテナンス方法

ロジックで権限を強制する

Business Processes を使って、承認・エクスポート・削除のルールを変更が起きる場所で強制します。

フローを作成

権限は小さく地味な不具合で失敗することが多い：1 つの画面がボタンを隠し忘れる、1 つのエンドポイントがチェックを抜ける、スコープのマッチが広すぎる。権限マトリクスは繰り返し実行できるテストと簡単なメンテナンスルーチンに落とし込むと非常に役立ちます。

まず小さなテストユーザーセットを用意します。数十のアカウントは不要です。各ロールに 1 ユーザー、さらに一般的な例外用に「エッジ」ユーザーを用意します（例：「返金承認権限を持つ Support 担当」）。これらのアカウントはスプリントごとに再利用できるよう安定させます。

次にマトリクスをテストケースに変換します。各ルールについて許可されるパスと拒否されるパスを 1 つずつ書きます。拒否パスは具体的に何が起きるか（エラーメッセージやデータ変更がないこと）を書いてください。

ロール：Support Agent。アクション：Refund。期待：拒否され、明確なメッセージ、データ変更なし。
ロール：Finance。アクション：Refund。期待：許可され、返金レコードが作成され、実行者と理由がログに残る。
ロール：Manager。アクション：View tickets。スコープ：team のみ。期待：チームのチケットは見られるが他チームのチケットは開けない。

同じルールは UI と API の両方でテストしてください。UI がブロックしても API が通してしまえば画面を回避されます。AppMaster を使っているなら、UI ロジックとバックエンドエンドポイントの両方でルールが強制されていることを確認します。

スコープは実データでテストする必要があります。所有権、チーム、地域で異なるテストレコードを作り、別スコープの ID を推測してアクセスできないことを確認します。

最後に、機密アクションで何をログに残すか決めます（返金、エクスポート、ロール変更）。誰が何をいつどこから行ったかを記録し、ログを定期的にレビューし、権限編集や大量エクスポートのような稀な操作にはアラートルールを作ります。

次のステップ：マトリクスから作動する内部ツールへ

権限マトリクスを作業計画として扱い、棚上げしないでください。価値を早く得る最短ルートは、データとプロセスのオーナーと基本を確認することです。

まず短いワークショップ（30 分で十分）をロールの代表者とリソースオーナー（顧客、請求書、支払い、チケットなどの責任者）で行い、ロール、リソース、アクション、スコープを一通り確認し、特別ケースを洗い出します。例外が頻発するならスコープ不足の可能性があります。

次に v1 のマトリクスを草案にしてリソースオーナーとレビューします。実用的に答えられることを重視してください：「Support は請求書を見られるか？」「Finance は顧客情報を編集できるか？」躊躇があるルールはまず平易な言葉で記録し、後で形式化します。

v1 合意後は一つのドメインをエンドツーエンドで作ってみてから拡張してください。データ、ロジック、UI に触れる薄切りのスライス（例：チケッティングや請求承認）を選び、「誰が見られるか、誰が変更できるか、試したときに何が起きるか」を答えられるようにします。

AppMaster を使うなら、生成前にマトリクスを製品の各パートに割り当ててください：

Data Designer：リソースをエンティティ（テーブル）と、スコープに影響するキー項目（team_id、region_id）に整合させる
Business Processes：変更が起きる箇所でルールを強制する（create、update、approve、export）
UI 可視性ルール：ユーザーが実行できない操作は隠し、アクセスが拒否されたときに理由を明示する
Endpoints：各ロールに必要なものだけを公開し、管理者専用操作は分離する

単純な例：Support が作成し Finance が承認する「返金リクエスト」フローを 2 ロールで作る。これがきれいに動けば「Support は 30 分以内のみキャンセル可能」などのエッジケースを追加していけます。

小さな内部ツールを AppMaster で試して早期にロールとフローを検証し、マトリクスから反復的に改善していってください。目的は 20 画面と大量の権限修正が必要になる前に誤解を見つけることです。