役割と権限：ビジネス事例でわかりやすく

実際の問題：見せてはいけないデータが見えてしまうこと

職場での「データ漏えい」は退屈に見えることが多いです。サポート担当が顧客プロフィールを開くと支払い履歴が全部見える。クライアントがログインして「クレームなら20%オファー」などの内部メモや、請求書の実コストとマージンを見つける。パスワードを盗まれたわけではありません。アプリが単に間違ったものを見せてしまったのです。

ほとんどの漏えいは事故です。権限が後回しにされ、新しい画面が急いでリリースされたり、テスト用の「十分だった」古いロールをコピーしたりしてしまう。すると小さな変更――テーブルに新しいフィールドを追加するだけ――がいつの間にか全員に見えるようになります。

だからこそ、役割と権限はアプリの一等市民であるべきで、後付けのチェックボックスではいけません。多くの小規模ビジネスは最終的に同じ4つの役割になります：オーナー（Owner）、マネージャー（Manager）、スタッフ（Staff）、クライアント（Client）。

目標は簡単です：各人が業務に必要なものだけを見て、それ以外は見えないようにすること。画面だけでなく、裏で扱うデータも含めてです。

特に AppMaster のようなノーコードプラットフォームで素早く作る場合は、この点がより重要です。スピードは強みですが、アクセス設計を後回しにすると内部メモや価格ルール、他の顧客の記録を誤って公開してしまいやすくなります。

役割、権限、スコープ：シンプルな定義

役割と権限は、アプリ内で誰が何をできるかを決めるルールです。

• 役割（role） はオーナーやマネージャー、スタッフ、クライアントのような職務ラベルです。
• 権限（permissions） はそのロールが許される具体的な操作です。

アクセスレベル はこれらのルールが実際にどう作用するかの結果です。同じ「スタッフ」でも、ある人は返金を承認できるためアクセスレベルが高い、ということはよくあります。

ミスを防ぐ確実な方法は最小権限から始め、その人が日常業務をこなすために必要なものだけを追加することです。誰かが請求書を編集することがないなら、"念のため" 編集権を与えないでください。アクセスを追加するのは後からでも簡単ですが、データ漏えいを元に戻すのは大変です。

多くの権限は「表示」「作成」「編集」「削除」といった少数のアクションと、CSV出力や承認のような高リスクな操作に集約されます。

スコープ は別の問いに答えます：「どのレコードにそれが適用されるか？」ということです。ある人は請求書を見られても、自分のものだけで全員のものは見られない、という具合です。

典型的なスコープのパターン：

• 自分のレコード（自分が作成した、あるいは割り当てられたもののみ）
• チームや拠点（支店、部署、プロジェクト単位）
• 会社全体（ビジネス全体の全レコード）

営業担当は自分の見積と見積の作成はできても顧客リストをエクスポートできないかもしれません。セールスマネージャーはチーム全体の見積を見て割引を承認できます。オーナーはすべてを見て会計向けのレポートをエクスポートできます。

オーナー、マネージャー、スタッフ、クライアントが通常必要とするもの

多くのアプリは同じ4つのグループに落ち着きます。詳細は変わってもパターンは同じです。役割と権限を最初にクリアにしておけば、あとで「なぜ彼らがそれを見られるのか」という気まずい瞬間を避けられます。

オーナー は通常、ビジネス全体のあらゆる情報を見る必要があります。請求、セキュリティ設定（パスワードルールや MFA など）、誰がいつ何を変更したかを確認する監査履歴も含みます。

マネージャー は管理者すべてにはしないまでもチームを運営するための権限が必要です。部署内のすべてを確認でき、行為を承認でき（割引、返金、休暇、コンテンツ変更等）、レポートを閲覧できます。スタッフ招待やパスワードリセットなどの限定的な管理操作は必要な場合がありますが、請求情報やグローバルなセキュリティ設定へのアクセスは不要です。

スタッフ は日々の業務を速やかに行えるけれどリスクは小さくするべきです。安全なデフォルトは「自分に割り当てられたものだけ」です。サポート担当は自分のチケットだけ、配車担当はその日のルートだけ、営業は自分のリードだけを見ます。エクスポートや一括ダウンロードはデフォルトでオフにし、本当に必要な時だけ有効にします。

クライアント は複数人がアカウントを共有していても自分たちのデータのみを見られるべきです。依頼作成、請求書支払い、プロフィール更新などの限定的な操作は許可しますが、内部メモやスタッフのコメント、内部ステータスは隠します。

多くのビジネスで機能するデフォルトのセット：

• オーナー: 請求、セキュリティ、監査ログを含むすべて
• マネージャー: チームデータ、承認、レポート、限定的なユーザー管理
• スタッフ: 割り当てられたレコードのみ、エクスポート不可、管理設定不可
• クライアント: 自分のレコードのみ、内部メモ不可、限定操作

画面だけでなくデータの種類ごとにアクセスを分ける

多くのチームは画面単位で権限を設定します。「スタッフは注文ページを開けるがクライアントは無理」といった具合です。それは役に立ちますが、本当のリスクを見落とします。同じデータは検索、コメント、通知、エクスポート、添付ファイルにも現れます。

まずはメニューではなくデータ領域をリストアップしてください。影響が大きい領域は顧客連絡先、注文と配送状況、請求書と支払い状況、給与や人事メモ、内部メモや分析などです。

次に各ロールが各データに対して何をできるかを決めます：表示、作成、編集、削除、承認、共有など。ここでフィールド単位のルールが重要になります。同じオブジェクトでも公開ビューと内部ビューが必要なことが多いです。

例：注文（Order）には顧客名、配送先、価格、内部マージン、「クレーム多い、割引して対応」などの内部メモが入るかもしれません。クライアントは配送先とステータスだけ見て、マージンや内部メモは絶対に見せない。マネージャーは全フィールドを見て割引を承認できる。スタッフは配達に必要なフィールドだけ見て、財務情報は見ない、という具合です。

ファイルと添付は特に注意してください。契約書、身分証、領収書、スクリーンショットはフォームフィールドより敏感な情報を含むことが多いです。誰がアップロードできるか、誰がダウンロードやプレビューできるか、添付が親レコード（請求書等）と連動するか個別ルールにするかを決めてください。

最後に、エクスポートや一括操作を「表示の延長」として扱わないでください。CSV/PDF へのエクスポート、一括添付ダウンロード、一括ステータス変更（承認、キャンセル、返金）、一括メッセージ送信（メール/SMS/Telegram）、レコード再割当などは明示的に制御します。

事例 1：営業と請求アプリ

小さなサービス業を想像してください：オーナーがプロジェクトを販売し、マネージャーが作業を監督し、スタッフが仕事をこなし、クライアントが見積を承認して請求書を支払う。問題を避ける最速の方法は、誰もログインする前に役割と権限を合意しておくことです。

まずお金まわりを固めます。価格は利益より広く見せても良いが、理由（マージン等）は限られた人だけにします。一般的なルールは：スタッフは請求すべき額を見られるが、なぜその価格にしたかは見ない、です。技術者は請求書の明細を説明するためにラインアイテムを見る必要があるかもしれませんが、内部マージン、仕入れコスト、獲得のために与えた特別割引は見る必要がありません。

顧客データも別のホットスポットです。多くのチームは複数の人に連絡先の閲覧を許可したいが、編集はごく一部に限定すべきです。そうしないと請求用メールが個人メールで上書きされてしまい、請求書が経理に届かなくなります。

多くのチームでうまく機能するシンプルな設定：

• オーナー: マージンや割引履歴を含むすべてを見て支払いステータスを変更できる
• マネージャー: 見積や請求書を作成し、割引を承認し、顧客連絡先を編集できる
• スタッフ: 割り当てられた顧客情報と請求書の明細は見られるが、価格ルールの編集やマージンは見られない
• クライアント: 自分の見積と請求書のみを見て支払いや変更依頼ができる

高リスクな操作は締めておきます。請求書を支払済みにする、返金を発行する、支払い方法を変更するなどはオーナー（または信頼された財務ロール）に限定すべきです。

事例 2：内部メモを持つサポートデスク

サポートデスクは一見シンプルです：顧客がメッセージを送り、チームが返信し、チケットがクローズされる。しかし同じチケットビューを全員で使うと問題が起きます。一つの設定ミスでクライアントが内部メモ、タグ、スタッフのパフォーマンス統計を見てしまうことがあります。

小規模な EC 事業で共有のサポート受信箱を想像してください。チケットには顧客メッセージ、注文詳細、配送状況、内部メモ（「不正の可能性あり、IDを確認」や「VIP、優先対応」）が含まれるかもしれません。内部コンテキストはチームには役立ちますが、顧客に見せてはなりません。

敏感なデータを守るための分離例：

• クライアント: 自分のメッセージ、公開されるステータス更新、最終的な解決のみを見られる。内部タグやスタッフ専用のメモは不可。
• スタッフエージェント: 顧客メッセージと問題解決に必要な顧客データ（注文履歴など）を見られる。内部メモやタグを追加できる。
• マネージャー: スタッフが見るものすべてに加え、再割当や SLA のオーバーライドが可能。
• オーナー/管理者: 事業全体の全チケットとハイレベルなレポートを閲覧できる。

クライアントの個人情報（PII）にも注意が必要です。サポートは電話番号や住所を必要とすることがありますが、毎回、全てのチケットで表示する必要はありません。良いルールは：ワークフローで必要なときだけ敏感フィールドを表示すること。例えば「配送問題」を選択したときだけ住所を表示し、チケットクローズ時には再び隠す、などです。

内部の指標は顧客体験から切り離してください。「初回応答時間」「エージェントスコア」「法務へエスカレーション」などはスタッフとマネージャーのビューだけに属します。

事例 3：オペレーションと配送追跡

倉庫とフィールドチームが配達を回している場面を想像してください。ある人がルートを計画し、別の人がピッキングし、ドライバーがストップを完了する。間違った詳細を見せると不便なだけでなく顧客住所や価格、内部メモが漏れる危険があります。

各グループが日々必要とする情報を分けることから始めてください。

スタッフ（ピッカーやドライバー） はタスクに集中した表示が必要です。ドライバーはアプリを開くと今日の担当ジョブだけが順序付きで見え、停止順、連絡先、配達指示だけが見えるべきで、全顧客リストや他のドライバーのジョブを閲覧できてはいけません。シフトをカバーする場合は、マネージャーがジョブを再割当する仕組みを用意して幅広いアクセスを与えないようにします。

マネージャー は運用全体を把握する必要があります。チーム全体のスケジュール、在庫数、遅延や失敗配達、破損、署名漏れなどの現状を見られるべきです。例外処理のためにジョブ再割当、ルート分割、在庫調整の承認などのツールも必要です。

クライアント は最小限の表示：自分の配送状況だけ。ETA の確認、配達の証明、"配達中" や "遅延" といった更新を受け取ることは可能ですが、他の顧客や1日のルートマップ、内部の例外ノートは見せないでください。

ここでは割り当てと顧客アカウントでデータをスコープするのが簡単な方法です。例えば Delivery Job レコードは（1）割り当てられたスタッフ、（2）マネージャー、（3）その注文に結びついたクライアントだけが読める、という具合です。

手順：役割と権限の設計方法

まずユーザーグループに分かりやすい名前を付けます。「Owner」「Manager」「Staff」「Client」は良い出発点ですが、会社の運用に合っていることが前提です。各グループについて成功の定義を一文で書いてください。例：「マネージャーは給与を見ずに仕事を割り当てチームのパフォーマンスを確認できる」。

次にアクションをデータ領域にマップします。まず画面ではなくどんなデータがあるかを考えてください。紙に簡単なグリッドを作るだけで十分です：

• ロールとデータ領域（顧客、注文、請求書、チケット、レポート）を列挙する。
• 各ロールについて必要な操作（表示、作成、編集、承認、エクスポート）を書き出す。
• 各操作のスコープ（自分、チーム、全体）を決める。
• 「チーム」を明確に定義する（支店、地域、プロジェクト、直属の部下など）。
• 「決して許さない」項目をマークする（例：クライアントは内部メモを見ない）。

その後に実際のタスクでドラフトをテストします。「注文を作る」「チケットを解決する」「レポートをダウンロードする」といった一般的なフローを実際に辿ってみてください。もしタスクをこなすために広いアクセスを与える必要があるなら、たとえば「合計を表示できるがエクスポートはできない」のような欠けている権限を追加する必要があります。

金銭や敏感な変更が関わる場合は承認を追加してください。スタッフが請求書を下書きできても、送信や承認はマネージャーのみができる、という具合です。スタッフが配送先を編集できても、銀行情報の変更はオーナーの承認が必要、などです。

偶発的なデータ漏えいを招くよくあるミス

小規模チームでの多くのデータ漏えいはハッキングではありません。アプリが業務に必要以上のアクセスを誰かに与えてしまうことで起きます。権限は一度設定して終わりにせず定期的に見直す必要があります。

よくあるパターン：セットアップのために誰かに「管理者」権限を与えたままにする。急いで終わるとそのアクセスは残ります。数週間後、その人が顧客リストをレポート用にエクスポートしてしまい、機密データがスプレッドシートに置かれる――ということが起きます。

繰り返し出るミス：

• 問い合わせ対応を減らすために「Admin」をデフォルトロールにする
• 制限なしに広いエクスポート（顧客、連絡先、払い戻し、請求書）を許す
• シフトチームでログインを共有し、誰が何を見たか分からなくする
• 主要な画面は保護しても、モバイルビュー、PDF、メール通知、添付ファイル、自動入力フォームなどの脇道を忘れる
• 退職者のオフボーディングをしないでアクセスが残る

脇道が最も厄介です。画面からは契約書を見えなくしていても、誰かが同じ契約書の PDF をメールで受け取っていたら意味がありません。モバイルレイアウトで隠したはずのフィールドが表示されることもあります。

現実的な対処は、エクスポートやダウンロードを別個の権限として扱うことです。リストが必要ならフィルタされたビューを与えて、フルエクスポートは与えない、という選択肢を用意してください。

実際に本番ユーザーを招待する前の簡単チェック

本番で誰かを招待する前に、人は間違ったボタンをクリックしたり画面を共有したりファイルをダウンロードしたりするものだと想定してください。事前の数チェックで後の大変さを防げます。

デフォルトを決めます。新しいユーザー作成時は最低権限のロールに自動で入るようにし、金銭、エクスポート、管理設定にはアクセスしないようにします。追加が必要な場合は意図的に変更するプロセスを用意します。

次にクライアント体験を第三者の視点でテストします。クライアントは URL を変えたり検索したりフィルタを使っても他のクライアントのレコードを見られてはいけません。簡単なテストは、クライアントA としてログインしてクライアントB を名前や請求書番号、サポートチケット ID で探せるか試すことです。

多くの漏えいを見つける5つの速いチェック：

• 敏感フィールドはデフォルトで隠す（給与、コスト/マージン、個人ID、内部メモ）
• エクスポートと一括操作をロックする
• 誤操作のコストが高いところに承認を入れる（返金、支払い、役割変更）
• スコープがどこでも強制されているか確認する（画面、検索結果、API レスポンス）
• 誰がいつ何を変えたか監査できるようにする（ロール更新や支払い操作を含む）

「事故テスト」をやってください。チームメンバーにスタッフアカウントで実際のタスクを完了してもらい、同じタスクをクライアントアカウントで試します。クライアントが内部価格を見られる、全顧客リストをダウンロードできる、返金を発生させられるなら権限が広すぎます。

現実的なシナリオ：スタッフとクライアントが同じアプリを使う場合

よくある要求はこう始まります：クライアントが「ステータスを確認できる」ポータルを欲しがるが、スタッフも同じシステムで作業している。役割と権限がはっきりしていないと、ポータルが内部メモや他のクライアントの注文、スタッフ専用の価格を露出してしまいます。

印刷を請け負う会社を例にします。1つの注文が見積から生産、配送、請求までアプリ内で進むとします。

各ロールの見るべき内容は次の通りです：

• オーナー: 利益、スタッフのパフォーマンス、すべてのクライアントアカウントを含む全情報
• マネージャー: チームの全注文、内部メモ、割引や返金の承認権限
• スタッフ: 割り当てられた注文のみと次の作業ステップ、作業に必要な連絡先情報
• クライアント: 自分の注文のみ、高レベルのステータス（承認済み、製造中、出荷済み）、配達証明、支払うべき請求書

モデルを壊す2つのエッジケース：

1つ目、マネージャーが一時的に別チームをカバーする場合。彼らをオーナーに切り替えないでください。代わりに「チームB の注文に対するアクセスを7日間だけ付与する」などの時限スコープを追加し、カバー終了後に自動で期限切れにします。

2つ目、VIP 顧客が「もっと見せてほしい」と言う場合。より多くのコンテキストは与えても、より多くの生データは与えないでください。拡張されたタイムラインや専用のメッセージスレッドを見せる一方で「支払遅延」や「再印刷の理由」などの内部メモはスタッフ専用のままにします。

役割は変わるので、アクセスは一度設定して終わりではなく定期的に見直すものと扱ってください。誰かが役割を変えるときは権限を積み増すのではなく、不要になった権限を削除してから新しい職務に最低限必要な権限だけを追加します。

次のステップ：明確なアクセス方針を作って実装する

小さく始めてください。まず最も重要なワークフローを1つ選びます（例：「請求書を作成して支払いを受ける」や「サポートチケットを記録して返信する」）。その単一のフローのために役割と権限を定義し、そこから広げていきます。

ルールを1つの簡単な表にまとめ、それを生きたドキュメントとして扱ってください：ロール、できること、できないこと、そして制限（「自分のレコードのみ」「自分の拠点のみ」など）。誰かが「スタッフは顧客の電話番号を見られる？」と聞いたら、その表が秒で答えるようにします。

実用的なローアウト手順：

• 最初のワークフロー用に表をドラフト（Owner, Manager, Staff, Client）
• 各ルールを特定のデータ（フィールド含む）とアクション（表示、編集、エクスポート、削除）にマップする
• 各ロールのデモアカウントを作り実際のタスクをエンドツーエンドでテストする
• 少人数で公開し、驚きがなければ展開する
• 四半期ごと、組織変更（新マネージャー、新チーム、新ベンダー）の直後にもアクセスを見直す

AppMaster（appmaster.io）上で構築しているなら、ロールをデータモデルやビジネスロジックと並行して計画すると、Web・モバイル・API エンドポイント全体で一貫したルールが適用しやすくなります。

今日、最初のアクセス表を1つワークフローで作って試してみてください。その一歩でほとんどの偶発的なデータ漏えいを防げます。