マルチテナント SaaS アプリケーションを構築する：設計から実装までの完全ガイド

Notion、Slack、または Figma のようなアプリはどのように構築されているのでしょうか。これらのマルチテナント SaaS アプリケーションは使用が簡単に見えますが、自分で構築するとなると？それはまた別の話になります。

私が最初にその複雑なシステムを構築することを考えたとき、私の心は爆発しました：

• ユーザーは複数のサインインオプションを必要とします（メール、Google、GitHub）
• 各ユーザーは複数の組織を作成し、所属することができます
• 各組織内の異なる権限レベル
• 特定のメールドメイン向けの自動参加を要求するエンタープライズ組織
• センシティブ操作のための MFA 要件
• ...

「ボス、製品デザインについて2週間後に話しましょう。今、泥濘にはまっています。」

しかし、実際に取り組み始めると、それほど気が重いものではないことに気づきました。

私はこれらすべての機能を備えたシステムを2時間未満で作成しました！

私は、このようなシステムを基礎から設計し、実装する方法を正確に示します。そして、2025年に現代のツールと適切なアーキテクチャアプローチを使用すれば、それがいかに簡単であるかを驚くことでしょう。

この記事の最後に完全なソースコードが用意されています。それでは始めましょう！

私たちはマルチテナントモデルで設計された AI ドキュメント管理 SaaS プロダクトである DocuMind から始めます。

DocuMind は、個々のユーザー、小規模企業、エンタープライズをサポートするように設計された AI ドキュメント管理 Saas プロダクトです。

プラットフォームは、組織内の自動要約生成、重要なポイント抽出、インテリジェントなコンテンツ提案などの強力な AI 機能を提供します。

SaaS 認証と承認に必要な機能は何ですか？#

まず、必要な要件を確認しましょう。必要な機能は何ですか？

マルチテナント アーキテクチャ#

マルチテナントアーキテクチャを実現するには、organization と呼ばれるエンティティレイヤーが必要です。複数のワークスペースにアクセスできる単一のユーザープールを想像してください。各 organization はワークスペースを表し、ユーザーは割り当てられた役割に基づいて異なるワークスペース（organiztions）にアクセスしながら単一のアイデンティティを維持します。

それは認証プロバイダーで広く使用される機能です。アイデンティティ管理システムの組織は、SaaS アプリのワークスペース、プロジェクト、またはテナントに対応します。

メンバーシップ#

メンバーは、組織内のアイデンティティのメンバーシップステータスを示すために使用される一時的なコンセプトです。

たとえば、サラが彼女のメール [email protected] を使用してあなたのアプリにサインアップします。彼女は異なるワークスペースに属することができます。サラが ワークスペース A の一部であるが ワークスペース B の一部でない場合、彼女は ワークスペース A のメンバーと考えられますが ワークスペース B のメンバーではありません。

役割と権限の設計#

マルチテナントアーキテクチャでは、ユーザーは特定の permissions を持つ roles が必要です。 権限は、read: order や write: order のような具体的なアクションを定義する詳細なアクセス制御です。それらは特定のリソースに対してどのアクションが実行可能かを決定します。

役割は、マルチテナント環境においてメンバーに割り当てられる権限のセットです。

これらの役割と権限を定義し、それからユーザーに役割を割り当てる必要があります。場合によっては、これには自動化されたプロセスが含まれることがあります。例えば：

1. ア organization に参加するユーザーは自動的に メンバー 役が付与されます。
2. ワークスペースを最初に作成するユーザーは自動的に admin 役が割り当てられます。

サインアップとログインの流れ#

ユーザーにとって使いやすく安全な登録および認証プロセスを確保します。基本的なサインインおよびサインアップオプションを含めます：

1. メールとパスワードによるサインイン：電子メールとパスワードでの従来のログイン方法。
2. パスワードレスサインイン：メール確認コードを使用して簡単かつ安全にアクセス。
3. アカウント管理：ユーザーが電子メール、パスワード、その他の詳細を更新可能なアカウントセンター。
4. ソーシャルサインイン：Google や GitHub のようなクイックログインオプション。
5. 多要素認証 (MFA)：Duo などの認証アプリでのログインを許可することでセキュリティを強化します。

テナント作成と招待#

マルチテナント SaaS アプリでは、ユーザーフローの主な違いはテナント作成とメンバー招待をサポートする必要があることです。このプロセスは製品のアクティベーションと成長において重要な役割を果たすため、慎重な計画と実行が必要です。

考慮すべき典型的な使用フローの例として以下のようなものがあります：

これらはほぼすべての SaaS アプリで見られる一般的なシナリオです。それらを参考にして製品およびデザインチームにインスピレーションを与えたい場合は、必要に応じて独自のフローを作成してください。

技術アーキテクチャとシステム設計#

すべての製品要件を理解したら、実装に進みましょう。

認証戦略を定義する#

認証は難しそうです。ユーザーは次のことを求めます：

• メール & パスワードによるサインアップ/ログイン
• Google/Githubによるワンクリックサインイン
• パスワードを忘れたときのリセット
• エンタープライズ顧客向けチーム全体のログイン
• ...

これらの基本機能を実装するだけでも、開発には数週間かかる可能性があります。

しかし今や、これらを自ら構築する必要は全くありません！

最新の認証プロバイダー（今回は Logto を選びます）はこれらの機能をすべてパッケージ化して私たちに提供しています。認証フローは簡単です：

数週間の開発から15分のセットアップに。 Logto は私たちのためにすべての複雑なフローを処理してくれます！統合ステップについては後で実装セクションで取り上げます。今は DocuMind のコア機能を構築することに集中できます！

マルチテナントアーキテクチャを確立する#

組織システムは、ユーザーが複数の組織を作成し参加できるようにします。コア関係を理解しましょう：

このシステムでは、各ユーザーは複数の組織に所属でき、各組織は複数のメンバーを持つことができます。

マルチテナントアプリでのアクセス制御を有効にする#

役割ベースのアクセス制御 (RBAC) は、マルチテナント SaaS アプリケーションのセキュリティとスケーラビリティを確保するために重要です。

マルチテナントアプリでは、権限と役割の設計は通常一貫しています。これは製品設計に由来するからです。たとえば、複数のワークスペースで、通常は管理者役とメンバー役があります。Logto はそれに次ぐ認証プロバイダーとして次のような組織レベルの役割ベースアクセス制御設計を持っています：

1. 統一された権限定義: 権限はシステムレベルで定義され、すべての組織に一貫して適用され、維持しやすく一貫した権限管理を確保します。
2. 組織テンプレート: 組織テンプレートを通じた事前定義された役割と権限の組み合わせは、組織の初期化を簡素化します。

権限関係は以下のようになります：

各ユーザーが各組織内で自分の役割を持つ必要があるため、役割と組織の関係はユーザーに割り当てられた役割を反映する必要があります：

組織システムおよびアクセス制御システムを設計しましたので、今度は製品構築を始めましょう！

テックスタック#

私は初心者に優しい、移植性のあるスタックを選びました：

1. フロントエンド: React (Vue/Angular/Svelte に簡単に移行可能)
2. バックエンド: Express (シンプルで直感的な API)

なぜフロントエンドとバックエンドを分けるのですか？それは明確なアーキテクチャを持ち、学びやすくスタックの切り替えが簡単だからです。そして認証プロバイダーとして Logto を例として使用します。

次のガイドでは ここのパターンはすべてのフロントエンド、すべてのバックエンド、すべての認証システムに対応します。

アプリに基本的な認証フローを追加する#

これが最も簡単なステップです。私たちはただ私たちのプロジェクトに Logto を統合する必要があります。そして私たちのニーズに基づいて Logto コンソールでユーザーのログイン / 登録方法を設定できます。

アプリに Logto をインストールする#

まず、Logto Cloud にログインします。アカウントがない場合は無料で登録できます。開発用テナントを作成します。

テナントコンソールで、左の「アプリケーション」ボタンをクリックします。それから React を選択して私たちのアプリケーションを作成し始めます。

ページのガイドに従ってください。 Logto の統合を約 5 分で完了できます！

私の統合コードはこちらです：

便利なテクニックはこちら：私たちのログインページは「サインイン」と「登録」ボタンの両方を持っています。「登録」ボタンは直接 Logto の登録ページに遷移します。これは Logto の first screen 機能を通じて機能します。これはユーザーが最初に見る認証フローのステップを決定します。

製品が多くの新規ユーザーを期待する場合、登録ページをデフォルトに指定できます。

ログインをクリックすると、Logto ログインページに移動します。ログイン（または登録）が成功すると、おめでとうございます！あなたのアプリに最初のユーザー（あなた）ができました！

ユーザーをサインアウトする場合は、useLogto フックから signOut 関数を呼び出します。

サインインとサインアップ方法をカスタマイズする#

Logto コンソールで左メニューから「サインイン エクスペリエンス」をクリックします。次に「サインアップとサインイン」タブをクリックします。 このページでは、Logto のログイン / 登録方法を設定するための指示に従ってください。

そしてサインインフローは次のようになります：

多要素認証を有効にする#

Logto を使用すれば、MFA の有効化は簡単です。Logto コンソールで「多要素認証」ボタンをクリックします。次に多要素認証ページで有効にします。

そして MFA フローは次のようになります：

すべてがとてもシンプルです！わずか数分で複雑なユーザー認証システムをセットアップしました！

マルチテナント組織体験の追加#

今や最初のユーザーがいます！しかし、このユーザーはまだどの組織にも所属していませんし、どの組織も作成されていません。

Logto は、組み込みでマルチテナンシーサポートを提供します。Logto で任意の数の組織を作成することができます。各組織には複数のメンバーを持つことができます。

各ユーザーは Logto から組織情報を取得できます。これにより、マルチテナンシーサポートが有効になっています。

ユーザーの組織情報を取得する#

Logto からユーザーの組織情報を取得するために、次の2つの手順を実行します:

Logto Config で組織情報へのアクセスを宣言します。これは適切な scopes と resources を設定することで実現します。

Logto の fetchUserInfo メソッドを使用してユーザー情報を取得し、組織データを含めます。

これらの手順を完了した後、サインアウトして再度サインインする必要があります。これは要求されたスコープとリソースを変更したために必要です。

現時点では、まだ組織を作成していません。ユーザーもどの組織に属していないため、ダッシュボードには「まだ組織がありません」と表示されるでしょう。

次に、ユーザーのために組織を作成し、その組織に追加します。

Logto のおかげで、複雑な組織関係を構築する必要はありません。ただ Logto で組織を作成し、ユーザーをそれに追加するだけです。Logto が私たちの代わりにすべての複雑さを処理してくれます。組織を作成する方法は2つあります：

1. Logto コンソールで組織を手動で作成する
2. Logto Management API を使用して組織を作成する。特に、ユーザー自身が組織（ワークスペース）を作成できるように設計された SaaS フローの場合。

Logto コンソールで組織を作成する#

Logto コンソールの左側にある「組織」メニューボタンをクリックします。組織を作成します。

これで最初の組織ができました。

次に、この組織にユーザーを追加します。

組織の詳細ページに移動します。メンバータブに切り替えます。「+ メンバーを追加」ボタンをクリックします。左側のリストから登録ユーザーを選択します。右下の「Add members」ボタンをクリックします。これでユーザーがこの組織に追加されました。

アプリページを更新します。ユーザーが組織に属していることが表示されます！

ユーザー主導の組織作成体験を実装する#

コンソールで組織を作成するだけでは不十分です。あなたの SaaS アプリはエンドユーザーが自分でワークスペースを簡単に作成・管理できるフローを持つ必要があります。この機能を実装するには、Logto Management API を使用します。

ガイダンスとして、Logto との API 通信を設定するための Interact with Management API ドキュメンテーションを確認してください。

組織認証インタラクションフローを理解する#

組織作成フローを例として取り上げましょう。組織作成プロセスは次のように機能します：

このフローには2つの重要な認証要件があります：

1. バックエンドサービス API の保護:
   • フロントエンドからの我々のバックエンドサービス API へのアクセスには認証が必要
   • API エンドポイントはユーザーの Logto アクセストークンの検証により保護されている
   • 認証されたユーザーのみがサービスにアクセスできることを保証する
2. Logto Management API へのアクセス:
   • バックエンドサービスは Logto Management API を安全に呼び出す必要がある
   • Interact with Management API のガイドに従って設定する
   • マシンツーマシン認証を使用してアクセス資格を取得する

バックエンド API を保護する#

まず、組織を作成するための API エンドポイントを我々のバックエンドサービスに作成しましょう。

我々のバックエンドサービス API は認証されたユーザーのみ許可します。Logto を使用して我々の API を保護する必要があります。また、現在のユーザー情報（ユーザー ID など）を知る必要があります。

Logto の概念（および OAuth 2.0）では、我々のバックエンドサービスはリソースサーバーとして動作します。ユーザーはフロントエンドからのアクセストークンを持って DocuMind リソースサーバーにアクセスします。リソースサーバーはこのトークンを検証し、有効であれば要求されたリソースを返します。

我々のバックエンドサービスを表す API リソースを作成しましょう。

Logto コンソールへ移動します。

1. 右の「API リソース」ボタンをクリックします。
2. 「API リソースを作成する」をクリックします。ポップアップで Express を選びます。
3. 「DocuMind API」を API 名に記入します。「https://api.documind.com」を API 識別子として使用します。
4. 作成をクリックします。

この API 識別子 URL について心配しないでください。これは Logto 内でのあなたの API に対する一意の識別子です。実際のバックエンドサービス URL と関連するものではありません。

API リソースを使用するためのチュートリアルを見ることができるでしょう。あなたはそのチュートリアルに従うこともできますし、以下のステップに従うこともできます。

POST /organizations エンドポイントを保護する requireAuth ミドルウェアを作成しましょう。

このミドルウェアを使用するには、次の環境変数が必要です:

• LOGTO_JWKS_URL
• LOGTO_ISSUER

あなたの Logto テナントの OpenID 設定エンドポイントからこれらの変数を取得してください。https://<your-tenant-id>.logto.app/oidc/.well-known/openid-configuration にアクセスします。返される JSON 内に必要な情報が見つかります：

これで POST /organizations エンドポイントに requireAuth ミドルウェアを使用します。

これで POST /organizations エンドポイントが保護されました。有効な Logto アクセストークンを持つユーザーのみがそれにアクセスできます。

今後私たちのバックエンドサービス API にトークンを持って正しくアクセスすることができるようになりました。このミドルウェアはユーザー ID も提供してくれるため、ユーザーを組織に追加するときに役立ちます。

フロントエンドコードで、Logto config にこの API リソースを宣言します。識別子をリソース配列に追加します。

以前と同様に、Logto 設定を更新した後に再度ログインする必要があります。

ダッシュボードで、組織を作成するときに Logto アクセストークンを取得します。このトークンを使用して我々のバックエンドサービス API にアクセスします。

これで DocuMind バックエンドサービス API に正しくアクセスすることができます。

Logto Management API の呼び出し#

Logto 管理 API を使用した組織作成の実装を行います。

Logto へのアクセス トークンは、前述のフロントエンドからバックエンド サービスへのリクエストと同様に、バックエンド サービスから Logto へのリクエストに必要です。

Logto では、マシンツーマシン認証を使用して、アクセス トークンを取得します。 Interact with Management API を参照してください。

Logto コンソールでアプリケーションページに移動します。マシンツーマシン アプリケーションを作成し、"Logto Management API access" ロールを割り当てます。トークンエンドポイント、App ID、および App Secret をコピーします。これをアクセス トークン用に使用します。

これでこの M2M アプリケーションから Logto Management API のアクセス トークンを取得することができます。

このアクセストークンを使用してLogto管理 API を呼び出します。

我々はこれらの管理APIを使用します：

• POST /api/organizations: 組織を作成する (参考： Create organization API reference)
• POST /api/organizations/{id}/users: 組織にユーザーを追加する (参考： Add users to organization API reference)

Logto Management API を通じて組織作成を今や実装しました。そして私たちは組織にユーザーを追加することもできます。

この機能をダッシュボードでテストしましょう。

そして「組織作成」をクリックします

作成完了！

次のステップは組織へのユーザーの招待です。しかし、我々のチュートリアルでこの機能をまだ実装しません。既に Management API の使用方法を知っています。このブログ記事に従うことでこの機能を容易に実装できます：How we implement user collaboration within a multi-tenant app。

マルチテナント アプリへのアクセス制御の実装#

さて、次に進むのは、組織アクセス制御です。

達成したいことは以下の通りです：

• ユーザーは自分自身の組織リソースにのみアクセス可能である：これは Logto の organization token を通じて実現できます
• ユーザーは組織内で特定の役割（異なる権限を持つ）を持ち、認可されたアクションを実行する：これは Logto の組織テンプレート機能を通じて実装できます

これらの機能をどのように実装すればよいかを見てみましょう。

Logto オーガニゼーショントークンの使用#

前述の Logto アクセストークンと同様に、Logto は特定のリソースに対応するアクセストークンを発行し、ユーザーはこのトークンを使用してバックエンドサービス内の保護されたリソースにアクセスします。それに対して、Logto は特定の組織に対応するオーガニゼーショントークンを発行し、ユーザーはこのトークンを使用してバックエンドサービス内の保護された組織リソースにアクセスします。

フロントエンド アプリケーション内で、Logto の getOrganizationToken メソッドを使用して特定の組織にアクセスするためのトークンを取得できます。

ここで organizationId はユーザーが所属する組織の id です。

getOrganization または他の組織の機能を使用する前に、Logto config に urn:logto:scope:organizations スコープおよび urn:logto:resource:organization リソースが含まれていることを確認する必要があります。これは以前に宣言していますので、ここでは繰り返しません。

組織ページで、組織トークンを使用して組織内のドキュメントを取得します。

この実装において注意すべき重要な点は2つあります：

1. getOrganizationToken に渡される organizationId が現在のユーザーに属さない組織 ID の場合、このメソッドはトークンを取得できません。これによりユーザーは自分の組織にのみアクセスできることが保証されます。
2. 組織リソースを要求するときには、アクセス トークンの代わりにオーガニゼーショントークンを使用します。なぜなら組織に属するリソースに対しては、ユーザー権限制御ではなく組織権限制御を使用したいからです（このことは GET /documents API を後で実装するときにより理解できます）。

次に、私たちのバックエンドサービスに GET /documents API を作成します。 POST /organizations API を保護するために使用された API リソースと同様に、組織固有のリソース インジケーターを使用して GET /documents API を保護します。

まず requireOrganizationAccess ミドルウェアを作成して組織リソースを保護します。

次に requireOrganizationAccess ミドルウェアを使用して GET /documents API を保護します。

このようにして、組織トークンを使用して組織リソースへのアクセスを実装しました。バックエンドサービス内で、組織 ID に基づいてデータベースから対応するリソースを取得できます。

一部のソフトウェアは組織間でデータの隔離を必要とします。さらに関する議論と実装については、ブログ投稿： Multi-tenancy implementation with PostgreSQL: Learn through a simple real-world example を参照してください。

組織レベルの役割ベースアクセス制御設計を実装する#

組織トークンを使用して組織リソースへのアクセスを実装しました。次に、RBAC を使用した組織内ユーザー権限制御の実装を行います。

DocuMind には2つの役割があると仮定しましょう：管理者と協力者。

管理者はドキュメントを作成しアクセスできますが、協力者はドキュメントへのアクセスのみ可能です。

したがって、私たちの組織にはこれら2つの役割が必要です：管理者と協力者。

管理者は両方の read:documents と create:documents 権限を持っていますが、協力者は read:documents 権限のみ持っています。

• 管理者
  • read:documents
  • create:documents
• 協力者
  • read:documents

ここで Logto の組織テンプレート機能が役立ちます。

組織テンプレートは、すべての組織に対して適用されるアクセス制御モデルの青写真です：それは一貫してすべての組織に適用される役割と権限を定義します。

なぜ組織テンプレートなのか？

スケーラビリティは SaaS 製品の中で最も重要な要件のひとつです。つまり、あるクライアントでの機能がすべてのクライアントにおいても機能するべきです。

Logto コンソール > 組織テンプレート > 組織権限に移動して read:documents と create:documents という2つの権限を作成しましょう。

その後、組織役割タブで AdminとCollaborator という2つの役割を作成し、それらのロールに対応する権限を割り当てます。

このように、各組織のために RBAC 権限モデルを作成しました。

次に私たちは組織詳細ページに移動し、メンバーに適切な役割を割り当てます。

このようにして私たちの組織ユーザーには役割ができました！これらの手順を Logto Management API を通じて実現できます：

さて、ユーザー権限を確認することによってユーザー権限制御を実装することができます。

我々のコード内でユーザーの組織トークンに権限情報を持たせ、その権限をバックエンドで確認します。

フロントエンドコード内の Logto config で、組織内でユーザーが要求する権限を宣言する必要があります。read:documents と create:documents 権限を scopes に追加します。

通常通り、これらの構成を有効にするためにユーザーで再度ログインしてください。

次に、私たちのバックエンドの requireOrganizationAccess ミドルウェアでユーザー権限の検証を追加します。

次に POST /documents API を作成し、この requireOrganizationAccess ミドルウェアを requiredScopes 構成で使用して以前の GET /documents API を保護します。

このようにユーザー権限を確認することによってユーザー権限制御を実装しました。

フロントエンド内で、組織トークンをデコードすることにより、または Logto の getOrganizationTokenClaims メソッドを呼び出すことによりユーザーの権限情報を取得することができます。

ページ要素をユーザー権限に基づいて制御するには、クレーム内のスコープを確認します。

マルチテナント アプリの機能をさらに追加する#

ここまでで、マルチテナント SaaS システムでの基本的なユーザーおよび組織機能を実装しました！ただし、各組織に対してログインページブランディングのカスタマイズ、特定のドメインメールを持つユーザーの自動追加、およびエンタープライズレベルの SSO 機能の統合など、まだカバーしていない機能がいくつかあります。

これらはすべて即時使用可能な機能であり、Logto ドキュメンテーションからこれらの機能に関する詳細情報を見つけることができます。

まとめ#

初めのうちはどれだけ圧倒されるように感じたでしょうか？ユーザー、組織、権限、エンタープライズ機能…それは登るべき無限の山のように見えました。

しかし、成し遂げたものを見てください：

• 複数のサインインオプションおよび MFA サポートを備えた完全な認証システム
• 複数のメンバーシップをサポートする柔軟な組織システム
• 組織内での役割ベースのアクセス制御

そして最も良い部分は？車輪を再発明する必要はありませんでした。現代のツール（例えば Logto）を活用することで、何か月もの開発時間が数時間に縮まりました。

このチュートリアル用の完全なソースコードがこちらで入手できます：Multi-tenant SaaS Sample。

2025 年の現代開発の力を体験しました - 構造と格闘することなく独自の製品機能に集中することができます。今こそ素晴らしいものを構築する時です！

Logto のすべての機能 - Logto Cloud から Logto OSS まで - Logto ウェブサイト で探索するか、Logto cloud に今日サインアップしましょう。