--- title: "第1回 — Auth0 OrganizationでマルチテナントSaaSを実現" description: "B2B SaaS製品を開発する場合、マルチテナントは基本的な要件です。顧客は企業であり、各企業は独自の隔離されたスペースを期待します。初期段階で適切に設計することで、後々の大きな苦労を回避できます。 " authors: - name: "Felix Colaci" url: "https://auth0.com/blog/authors/felix-colaci/" - name: "Andre Hochstein" url: "https://auth0.com/blog/authors/andre-hochstein/" date: "Oct 9, 2026" category: "Business" tags: ["organizations", "b2b", "b2c"] url: "https://auth0.com/blog/jp-multi-tenant-saas-apps-with-auth0-organizations-part-one/" --- # 第1回 — Auth0 OrganizationでマルチテナントSaaSを実現 >本記事は「[Multi-Tenant SaaS Apps with Auth0 Organizations — Part 1](https://auth0.com/blog/multi-tenant-saas-apps-with-auth0-organizations-part-one/)」を翻訳した記事です。 架空の急成長中のクラウドネイティブなプロジェクト管理SaaSプラットフォームである**FlowGrid**を紹介します。多くの現代のスタートアップと同様に、FlowGridの初期の成功はProduct-Led Growth(PLG)によって牽引されました。個人ユーザーや小規模チームは、基本的なパスワードやソーシャルログインを使用して、個人または仕事用のメールアドレスでサインアップしました。運用はシンプルで、ユーザーベースは成長していました。 しかしその後、FlowGridは転換点を迎えました。営業チームが、Fortune 500に名を連ねる**Acme Corp**(別の架空の企業)という初めての主要な見込み客を獲得したのです。AcmeのCISOはFlowGridに最後通牒を突きつけました。 FlowGridのリードアーキテクトは、自社開発のカスタム`users`テーブルが、エンタープライズシングルサインオン(SSO)、ドメインルーティング、マルチテナント認可の負荷に耐えきれず崩壊しそうになっていることに気づきました。 FlowGridは、B2Bブログ記事シリーズ全体を通して架空の企業として登場します。シリーズでは、Auth0を使用してB2B SaaSエクスペリエンスを保護することに関連するすべての事項を網羅します。エンタープライズオンボーディング、SaaSマルチテナントアーキテクチャ、認可などが含まれます。 [**Auth0 Organizations**](https://auth0.com/blog/how-to-enable-self-service-identity-management-b2b-saas/)は、まさに直面している課題に対するソリューションです。全5回のシリーズの第1回となる本記事では、以下の内容について説明します。 * Auth0 Organizationsとは何か * B2CおよびB2Bのユースケースにおけるログインフローの仕組み * ユーザーを適切なアイデンティティプロバイダーにルーティングする方法 * 組織レベルで認可をモデル化する方法 ## What Are Auth0 Organizations and When to Use Them エンタープライズ契約を獲得するには、データとアクセスの分離を証明する必要があります。Auth0 Organizationsは、SaaS製品内の隔離されたワークスペースであるテナントを表します。企業、ワークスペース、または顧客アカウントなどが該当します。 各Organizationには独自の設定があります。 * **メンバー:** 特定のOrganizationに属するユーザー。 * **Connections:** Organizationが使用するアイデンティティプロバイダー(Google Workspace、Okta、Microsoft Entra ID、Auth0独自のデータベースなど)。 * **メタデータ:** テナント設定用の任意のキーバリューストア。 * **ロールと権限:** Organizationのメンバーシップ専用にスコープされたアクセス制御。 ### When to use Auth0 Organizations ユーザーが企業の一員としてログインし、企業のコンテキストによってユーザーを分離する必要がある場合は、Organizationsを使用します。典型的な指標は以下のとおりです。 * 独自のIdPを使用したSSOを希望するエンタープライズ顧客がいる。 * ユーザーが複数のテナントに属する可能性がある(2つの異なるクライアントで働く請負業者など)。 * グローバルなユーザーロールとは別に、テナントレベルのアクセス制御が必要である。 Auth0 Organizationsは適切なB2Bアイデンティティを実装するために必要なすべての機能を提供するため、製品チームは長い実装サイクルを省略し、適切な[エンタープライズ対応](https://auth0.com/blog/enterprise-readiness-is-not-what-you-support)をすぐに利用できます。 ### When not to use Auth0 Organizations すべてのユーザーがテナントコンテキストを持たない個人である純粋なB2Cアプリでは、Organizationsは必要ない場合があります。消費者向けのフィットネスアプリにはOrganizationsは不要ですが、チーム向けに販売されるプロジェクト管理ツールには必要です。 ## Supporting Self-Service and Enterprise Customers at Once FlowGridは、セルフサービスユーザーとエンタープライズ層の両方を1つのコードベースでシームレスにサポートする必要があります。認可リクエストの`organization`パラメーターは、B2CとB2Bのログイン動作の分岐点となります。 ### B2C with no organization parameter ユーザーはOrganizationコンテキストなしでUniversal Loginを通過します。FlowGridのフリーミアム層、個人のサインアップ、企業アカウントがプロビジョニングされる前のトライアルに最適です。 ### B2B with an organization parameter `organization`を渡すと、Auth0はログインエクスペリエンス全体をOrganizationにスコープします。 * Organizationで有効になっているConnectionsのみが利用可能です。 * 設定されている場合、ブランディング(ロゴ、色)はOrganizationを反映します。 * 生成されたトークンには`org_id`および`org_name`クレームが含まれます。 不透明なIDの代わりに、Organizationの名前スラッグとして`organization`を渡せます。アプリのルーティングからログインURLを構築する場合に便利です(例: `acme.yourapp.com` → `organization=acme`)。 ### Inviting a user into the Organization ユーザーをOrganizationに招待すると、Auth0は招待チケットを生成します。受信者がリンクをクリックしてサインアップまたはログインを完了すると、自動的にOrganizationに移動します。招待では、フロー全体を通して`organization`パラメーターが保持されます。シリーズの後半では、System for Cross-domain Identity Management([SCIM](https://auth0.com/docs/authenticate/protocols/scim))などのエンタープライズグレードのプロトコルに焦点を当てます。 ## How Does Auth0 handle Home Realm Discovery? Acme Corpの従業員がFlowGridにアクセスする場面を想像してください。AcmeのITポリシーではパスワードが厳格に禁止されています。ユーザーがログインページでメールアドレスを入力した際、どのIdPに送信するかを判断する必要があります。これが[Home Realm Discovery(HRD)](https://auth0.com/docs/get-started/architecture-scenarios/business-to-business/authentication#home-realm-discovery)です。 Auth0はConnectionレベルでHRDを処理します。OrganizationでConnectionが有効になっている場合、Auth0はメールのドメインを使用してユーザーをConnectionに自動的にマッピングします。機能を使用するには、Authentication Profileを[Identifier First](https://auth0.com/docs/authenticate/login/auth0-universal-login/identifier-first#configure-identifier-first-authentication)に設定する必要があります。 **フロー。** 1. ユーザーがUniversal Loginでメールアドレスを入力します。 2. Auth0は、ドメインがアクティブなOrganization(Organizationが事前に選択されていない場合はすべてのOrganization)で有効になっているConnectionと一致するかどうかを確認します。 3. 一致が見つかった場合、Auth0はパスワード画面をスキップしてエンタープライズIdPに直接リダイレクトします。 4. エンタープライズが一致しない場合は、デフォルトのConnection(データベース、ソーシャルなど)にフォールバックします。 Enterprise Connection Discovery on Universal Login 多くのB2Bアプリでは、テナント固有のURL(例: `acme.yourapp.com`)を使用して、ユーザーがログイン画面を見る前にorganizationパラメーターを事前に入力します。Auth0は確認すべきOrganizationをすでに把握しているため、HRDの信頼性が高まります。 HRDにより「どのようにログインすればよいか」というサポートチケットが不要になり、CISOを満足させるエンタープライズグレードのログインエクスペリエンスを提供します。 ## Tenant Context Switching Pattern FlowGridには、Acme CorpとGlobexの両方のプロジェクトを管理する代理店コンサルタントがいます。複数のOrganizationに属するユーザーには、ログアウトせずにコンテキストを切り替える方法が必要です。 Auth0は特定のOrganizationにスコープされたトークンを発行します。アクセストークンの`org_id`クレームは、どのテナントコンテキストがアクティブであるかをAPIに伝えます。テナントを切り替えるには、ユーザーは異なる`org_id`を持つ新しいトークンを必要とします。 異なる`org_id`を含む新しいトークンを発行するには、「organizationパラメーターありのB2B」セクションですでに説明したように、`organization`パラメーターを使用します。 サイレント認証が失敗した場合(セッションの有効期限切れなど)、表示されるリダイレクトにフォールバックします。ユーザーは、ターゲットOrganizationに事前スコープされたログイン画面に移動します。 ## Mapping Tenants to Data Auth0 Organizationsをアプリケーションのデータモデルにマッピングするには、大きく分けて2つのパターンがあります。 ### One Auth0 Organization per app tenant (recommended for B2B) 各顧客企業は1つのAuth0 Organizationを取得します。アプリケーションデータベースは、すべてのテナントスコープデータの外部キーとして`org_id`を保存します。 **例。** ```shell App Tenant: Acme Corp └── Auth0 Org: orgpageviews_abc123 ├── Members: [alice@acme.com](mailto:alice@acme.com), [bob@acme.com](mailto:bob@acme.com) ├── Connection: Acme's Okta (SAML) └── Metadata: { plan: "enterprise", region: "us-east" } ``` Hierarchy View 無駄のない分離、わかりやすい認可、特定のOrganizationのすべてのデータを簡単にクエリできる環境を提供します。 ### Shared Auth0 Organization with custom claims (not recommended) 一部のプラットフォームでは、Organizationsを使用する代わりに、Actionsを介してカスタムクレームにテナントコンテキストをエンコードします。機能しますが、アプリケーション層に複雑さを押し付けることになります。Organizationsがすでに提供しているものを再発明している状態です。特定の理由がない限り、避けてください。 ## Tokens, Scopes, Roles, and Claims ユーザーがOrganization内で認証されると、認可が重要になります。FlowGridは、ユーザーがAcmeでは*Admin*であり、Globexでは単なる*Viewer*であることを保証する必要があります。 ### Organization-level roles Auth0では、ユーザーが持つ可能性のあるグローバルロールとは別に、Organization内のユーザーにロールを割り当てられます。ロールは権限に解決され、権限はアクセストークンのクレームとして表示されます。ただし、トークンがOrganizationのコンテキストで発行された場合に限ります。 ### Organization claims in tokens デフォルトでは、APIでRole-Based Access Control([RBAC](https://auth0.com/docs/get-started/architecture-scenarios/business-to-business/authorization#role-based-access-control-rbac))が有効になっている場合、Organizationで認証されたトークンには`org_id`と権限クレームが含まれます。APIは`org_id`を使用してデータクエリをスコープし、権限を検証して操作を制御します。 ### Auth0 Actions for custom claims Auth0 Actions([Post-Login flow](https://auth0.com/docs/customize/actions/explore-triggers/post-login#post-login))を使用して、`event.organization.metadata`から直接、Organization固有のメタデータ(プラン層、リージョン、機能フラグなど)でトークンを強化します。リクエスト時にManagement APIへの余分なラウンドトリップを回避できます。 ## What Is Next? 本記事では、Organizationsとは何か、ログインフローの仕組み、HRD、テナントアーキテクチャ、Organizationスコープの認可など、コアとなるメカニズムについて説明しました。基礎となる部分です。 パート2では、運用面についてさらに深く掘り下げます。 * [セルフサービスSSO](https://auth0.com/docs/authenticate/enterprise-connections/self-service-enterprise-configuration#self-service-enterprise-configuration) * [My Organization API](https://auth0.com/docs/api/myorganization) * Management APIラッパーをゼロから構築することなく、製品の管理インターフェイスを通じて[エンタープライズ顧客が独自のユーザーとConnectionsを管理](https://auth0.com/blog/delegation-is-a-form-of-respect)できるようにする方法 ## Ready to Level Up Your SaaS Architecture? **開発を止めて、ページビューを体験し始めましょう。** B2Bアイデンティティのインタラクティブなハンズオンマスタークラスである[SaaStart](https://saastart.app/)にアクセスしてください。数分で最初のOrganizationをプロビジョニングし、エンタープライズConnectionsを有効にして、実際のトークンを発行できます。パート2で運用の詳細に飛び込む前に、Auth0を利用したSaaSアプリケーションを体験してください。 まだAuth0アカウントをお持ちでない場合は、[無料で作成](https://a0.to/blog_signup)してください。