法人向けSaaSを作ると、ほぼ確実に顧客企業から求められるのが「組織としての管理機能」です。管理者がメンバーを招待できること、メンバーごとに使える機能を変えられること、退職者のアカウントを止められること、そして誰がいつ何をしたかを後から確認できること。どれも本体の機能ではありませんが、これがないと情報システム部門やセキュリティ担当者の確認を通らず、導入が進みません。
設計の要点は、①「組織」「ユーザー」「所属（どの組織にどの立場で属しているか）」を別々のデータとして持つ、②権限はユーザーに直接付けず、ロールを介して付ける、③招待は「所属の作成」として扱い、メールアドレスの確認と期限を持たせる、④重要な操作は最初から監査ログに残す、の4点です。この4点を最初の版から押さえておけば、細かな機能は後から追加しても作り直しにはなりません。
この記事では、法人向けSaaSの組織管理機能について、データの持ち方、ロールの決め方、招待の流れ、監査ログに残す項目、よくある失敗とチェックリストを、設計パターンとして整理します。SaaSの企画・開発を担当するプロダクトマネージャーやエンジニア、開発会社に発注する担当者に向けた内容です。
法人向けSaaSに組織管理機能が必要な理由
個人向けのサービスであれば、1人のユーザーが1つのアカウントを持てば十分です。法人向けSaaSでは、契約するのは企業であり、使うのはその企業の複数の従業員です。このずれから、次のような要求が生まれます。
- 契約や請求は企業単位で行い、利用者は企業の中で増減する
- 管理者が、自社のメンバーを自分で追加・削除できる
- 経理担当者は請求書だけ、現場担当者は業務画面だけ、といった役割に応じた使い分けが必要
- 退職や異動のたびに、運営会社に連絡せずにアカウントを止めたい
- 情報漏えいや誤操作があったとき、誰の操作かを追跡できる必要がある
- 1人の担当者が、複数の企業（たとえば本社とグループ会社、あるいは支援先の複数企業）に所属することがある
これらに応えるのが、組織管理・権限・招待・監査ログの機能群です。顧客企業ごとのデータの分け方そのものはSaaSのマルチテナント設計で扱っているので、この記事では、テナントの中での「人と権限」の扱いに焦点を当てます。
組織・ユーザー・所属・ロールのデータ設計
最初に決めるべきなのは、データの持ち方です。よくある失敗は、ユーザーのデータに「所属企業」と「権限」を直接持たせてしまうことです。こうすると、1人が複数の企業に所属するケースや、企業ごとに違う権限を持つケースに対応できません。
おすすめは次の4つを分けて持つ構造です。
| データ | 表すもの | 主な項目 |
|---|---|---|
| 組織（テナント） | 契約の単位となる企業 | 組織名、契約プラン、状態、設定（パスワードポリシー、SSOの有無など） |
| ユーザー | ログインする個人 | メールアドレス、氏名、認証情報、状態 |
| 所属（メンバーシップ） | ユーザーがどの組織にどの立場で属しているか | 組織、ユーザー、ロール、状態（招待中・有効・停止）、参加日 |
| ロール | 権限のまとまり | ロール名、許可される操作の一覧、組織独自のロールかどうか |
ユーザーは「人」、所属は「その人とある組織との関係」です。1人のユーザーが複数の所属を持てるようにしておくと、グループ会社をまたぐ利用や、支援会社の担当者が複数の顧客企業を担当するケースに自然に対応できます。ログイン後に所属が複数ある場合は、組織を選んでから画面に入る流れにします。
権限は所属に紐づくロールで判断します。この考え方はRBAC（ロールベースアクセス制御）と呼ばれ、ユーザーに個別の権限を直接付けるより管理しやすく、監査の説明もしやすくなります。
部署やチームを持つかどうか
組織の中に部署やチームといった単位を持つかどうかは、慎重に判断すべき論点です。「部署ごとに見えるデータを分けたい」という要望はよくありますが、部署の階層、兼務、異動の扱いまで含めるとデータ構造と権限の判定が一気に複雑になります。
最初の版では、組織の中は平らな構造にしておき、データの閲覧範囲を分けたい要望が具体的になった段階で、「プロジェクト」や「ワークスペース」といった、業務に即した単位を追加するのが無理のない進め方です。部署の階層をそのままシステムで表現するより、業務上の単位で区切る方が、顧客企業にとっても運用しやすいことが多いです。
ロールの決め方：最初は少なく、操作単位で定義する
ロールの数は、最初は3つ程度から始めるのがおすすめです。よくある構成は次のとおりです。
| ロール | できること | 想定する人 |
|---|---|---|
| オーナー | 契約・請求の管理、組織の削除、すべての操作 | 契約責任者（1組織に1〜2人） |
| 管理者 | メンバーの招待・停止、ロールの変更、組織設定、すべての業務データの操作 | 情報システム担当、現場の責任者 |
| メンバー | 業務データの閲覧・作成・編集 | 一般の利用者 |
ここに、顧客の要望に応じて「閲覧のみ」「請求担当」などを追加していきます。重要なのは、ロールの名前ではなく「許可される操作」を単位にして定義しておくことです。たとえば「メンバーの招待」「請求書の閲覧」「データの一括出力」「データの削除」といった操作を一覧にし、ロールは操作の組み合わせとして定義します。
こうしておくと、後から「管理者だけどデータの一括出力はさせたくない」といった要望が出たときに、新しいロールを追加するだけで対応できます。逆に、画面のあちこちに「管理者なら表示する」という判定を直接書いてしまうと、ロールを増やすたびに全画面の修正が必要になります。
権限設計の具体的な手順は管理画面の権限設計でも詳しく紹介しています。
顧客企業が独自のロールを作れるようにするか
大企業向けのSaaSでは「自社でロールを自由に作りたい」という要望が出ます。これは操作単位での定義ができていれば実現できますが、設定画面が複雑になり、顧客側の設定ミスによる問い合わせも増えます。最初は運営側が用意した固定のロールで提供し、要望が複数の顧客から出た段階で、上位プランの機能として提供するのが一般的な進め方です。
招待とメンバー停止の流れを設計する
招待は、管理者が新しいメンバーを組織に加えるための機能です。単に「アカウントを作る」のではなく、「招待中の所属を作り、本人がメールアドレスを確認して参加する」流れにするのが安全です。
基本の流れは次のとおりです。
- 管理者が、招待するメールアドレスとロールを入力する
- システムは、そのメールアドレスとロールを持つ「招待中」の所属を作成し、招待用の一意なトークンと有効期限を発行する
- 招待メールを送る。メールには組織名と招待者名、参加用のリンクを記載する
- 招待された人がリンクを開くと、既存ユーザーならログイン、新規ならアカウント作成の画面に進む
- ログインまたはアカウント作成の後、招待時のメールアドレスと一致することを確認し、所属を「有効」にする
- 参加したことを管理者に通知し、監査ログに記録する
この流れの中で決めておくべき論点がいくつかあります。
- 有効期限：招待リンクを無期限にすると、転送されたメールから第三者が参加できてしまうおそれがあります。数日程度の期限を設け、期限切れの招待は再送できるようにします
- メールアドレスの一致：招待されたアドレスと違うアドレスのアカウントで参加できるかどうか。原則として一致を求め、例外は管理者の承認を必要にします
- ドメインの制限：組織の設定で、特定のドメインのメールアドレスだけを招待できるようにする機能は、法人顧客から求められることが多い機能です
- ユーザー数の上限：料金プランでユーザー数に上限がある場合、招待中の人数を含めるかどうかを決めます。含めないと、上限を超えて招待が承諾される事態が起き得ます
- 招待の取り消し：送信済みの招待を取り消す操作と、その記録
招待以外のメンバー追加の方法
組織の規模が大きくなると、1人ずつ招待するのでは手間がかかります。次のような追加方法を、顧客の規模に応じて段階的に用意します。
- 一覧ファイルの取り込みによる一括招待
- 特定ドメインのメールアドレスを持つ人が、招待なしで参加申請できる機能
- SSO（シングルサインオン）を使った初回ログイン時の自動参加
- 企業のID管理システムとの連携による、入社・退職に合わせた自動追加・停止
SSOやID管理システムとの連携は、大企業から強く求められる一方で、実装と検証の手間も大きい機能です。どの段階の顧客を対象にするかに応じて、提供時期を決めましょう。
メンバーの停止・削除と退職者の扱い
招待と同じくらい重要なのが、メンバーを外すときの扱いです。退職者のアカウントが残り続けることは、顧客企業にとって重大なリスクです。
| 操作 | 意味 | 作ったデータの扱い |
|---|---|---|
| 停止 | ログインできなくするが、所属の記録は残す | そのまま残る。作成者名も表示される |
| 組織から外す | 所属を削除する。ユーザー自体は他の組織で使い続けられる | 組織に残る。作成者は「退出したユーザー」などと表示 |
| ユーザー削除 | 個人のアカウント自体を削除する | 個人情報の扱いに注意し、組織のデータは残す設計が一般的 |
業務データの作成者や担当者として退職者が紐づいていることは多く、ユーザーを物理的に削除すると、データの整合性が崩れたり、履歴が追えなくなったりします。原則は「停止」と「組織から外す」で対応し、個人のアカウント削除は本人の申請や規約に基づく手続きとして別に扱います。個人情報の削除や保持期間の扱いは、法令や利用規約に関わるため、専門家と確認のうえで決めてください。
また、退出したメンバーが担当していた業務データを、別のメンバーに引き継ぐ機能もあると、管理者の手間を減らせます。
監査ログに残す項目と見せ方
監査ログは、「誰が、いつ、どこから、何に対して、何をしたか」を後から確認するための記録です。アプリケーションの不具合調査用のログとは目的が違い、顧客企業の管理者やセキュリティ担当者が見るものです。
最初の版から記録しておきたい操作は次のとおりです。
- ログイン・ログアウト・ログイン失敗
- メンバーの招待・参加・停止・削除
- ロールの変更
- 組織設定の変更（パスワードポリシー、SSO設定、ドメイン制限など）
- データの一括出力・一括削除
- 契約プランや請求先の変更
- 運営会社による代理ログインや設定変更
記録する項目は、日時、操作者、操作者の所属組織、操作の種類、対象（どのユーザー、どのデータ）、変更前と変更後の値、接続元の情報です。運営会社の担当者が顧客の組織に代理でログインして操作した場合は、そのことが分かるように記録するのが重要です。
監査ログは後から書き換えられないように、通常の業務データとは分けて保存し、アプリケーションからは追記だけができるようにします。保存期間は、顧客企業の要求や契約に合わせて決めます。
見せ方としては、組織の管理者向けに、期間・操作者・操作の種類で絞り込める一覧画面と、ファイルでの出力機能を用意しておくと、セキュリティチェックの際にも説明しやすくなります。最初の版で画面を作る余裕がない場合でも、記録だけは始めておくべきです。記録していない期間のログは、後から作れないからです。
具体的な場面で考える：グループ会社で使われる業務SaaS
架空の例で考えます。ある業務SaaSは、ユーザーに所属企業とロールを直接持たせる設計で作られていました。中小企業が顧客の中心だったうちは問題ありませんでしたが、あるグループ企業から「本社の管理部門の担当者が、グループ各社の組織を横断して管理したい」という要望が届きました。
既存の設計では、1人のユーザーは1つの組織にしか所属できません。担当者は組織ごとに別のメールアドレスでアカウントを作るしかなく、パスワード管理が煩雑になるうえ、退職時に全アカウントを漏れなく止められるか不安が残ります。
このSaaSは、ユーザーと所属を分離する改修を行いました。既存のユーザーデータから所属のデータを作成し、ログイン後に組織を選ぶ画面を追加し、すべての権限判定を「ユーザーのロール」から「現在選んでいる組織での所属のロール」に置き換えました。権限判定が画面ごとに直接書かれていたため、改修範囲は全画面に及び、テストにも時間がかかりました。
最初から所属を分けて持ち、権限判定を一か所に集約していれば、この要望には組織選択の画面を追加するだけで応えられたはずです。
よくある失敗と避け方
権限の判定が画面ごとに散らばっている
「この画面は管理者だけ」という判定を画面ごとに書くと、ロールを追加したときに修正漏れが起き、本来見えてはいけない画面が見えてしまいます。権限の判定は「この所属は、この操作を許可されているか」を返す一か所の仕組みに集約し、画面と処理の両方でそれを使います。画面のボタンを隠すだけで、処理側で判定していないケースも多いので注意が必要です。
招待リンクに期限や照合がない
招待リンクが無期限で、誰でも開けば参加できる状態だと、メールの転送や誤送信で第三者が組織に入れてしまいます。期限と、招待先のメールアドレスとの照合を入れておきます。
最後の管理者を外せてしまう
管理者が自分自身のロールを変更したり、最後の管理者を停止したりすると、誰も組織を管理できなくなります。組織に最低1人のオーナーまたは管理者が残るように、操作を制限します。
監査ログを後回しにする
監査ログは「顧客に求められてから作ればよい」と後回しにされがちですが、記録していない過去の操作は後から追えません。画面は後回しにしても、記録は最初から始めます。
運営会社の操作が記録されない
サポートのために運営会社の担当者が顧客の組織に入って操作することはよくありますが、それが記録されていないと、顧客からの信頼を損ないます。代理ログインは、顧客の許可を得る仕組みと記録をセットで設計します。
設計チェックリスト
- ユーザーと所属が分かれており、1人が複数の組織に所属できる
- 権限はロールを介して付与し、ロールは操作の一覧として定義されている
- 権限判定が一か所に集約され、画面と処理の両方で使われている
- 招待に有効期限、メールアドレスの照合、取り消しの機能がある
- ユーザー数の上限と招待中の人数の扱いが決まっている
- 最後の管理者を外せないようになっている
- 停止・組織からの退出・ユーザー削除の違いと、作成データの扱いが決まっている
- 監査ログに残す操作と項目が決まっており、追記のみで保存される
- 運営会社による代理ログインが記録される
- SSOやID管理連携をいつ提供するかの方針がある
よくある質問
Q. 最初の版から細かい権限設定を用意すべきですか？
最初の版では、オーナー・管理者・メンバー程度の少ないロールで十分なことが多いです。ただし、ロールを操作単位で定義し、権限判定を一か所に集約する設計だけは最初から行っておくと、後からロールを追加するのが容易になります。
Q. 監査ログはどのくらいの期間保存すればよいですか？
顧客企業の社内規程や業界の慣行、契約内容によって求められる期間が異なります。想定顧客のセキュリティ担当者に確認し、プランによって保存期間を変える方法もあります。法令上の保存義務が関わる場合は、専門家に確認してください。
Q. SSOには最初から対応すべきですか？
大企業を主な対象にするなら、早い段階での対応が求められることがあります。一方、中小企業が中心であれば、メールアドレスとパスワード、二要素認証で始め、要望が具体的になってから対応する方が効率的です。外部の認証サービスを使えば、SSO対応の負担を軽くできる場合があります。
Q. 部署ごとにデータの閲覧範囲を分けたいという要望にはどう応えればよいですか？
部署の階層をそのまま再現するより、プロジェクトやワークスペースといった業務上の単位を作り、その単位ごとにメンバーを割り当てる方式の方が、運用も実装もシンプルになることが多いです。要望の背景にある業務を確認したうえで、単位を決めましょう。
Otsumuに相談できること
想定顧客が中小企業中心で、ロールも少なく、外部の認証サービスを使って組織管理を組み立てられる場合は、この記事のチェックリストを参考に自社のエンジニアで設計・実装を進められます。データの持ち方と権限判定の集約さえ押さえておけば、細かな機能は顧客の声に合わせて段階的に追加できます。
一方で、大企業やグループ企業への導入が控えていて、SSOや監査ログ、セキュリティチェックシートへの対応が求められている場合や、既存のSaaSで権限判定が画面ごとに散らばっていて改修が難しくなっている場合は、設計の見直しから外部の力を借りた方が、手戻りを減らせます。
Otsumuは、自らも事業を手がける立場から、顧客企業に求められる管理機能のどこまでを今作るべきかを、事業の優先順位と合わせて整理し、設計・開発・運用改善まで一気通貫で支援しています。SaaS開発のページで支援の内容を紹介しています。
「この顧客の要望に今応えるべきか」「既存の権限設計をどう直すか」といった段階の相談も歓迎しています。まずは30分の無料相談でお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01