> ## Documentation Index > Fetch the complete documentation index at: https://auth0.generaltranslation.app/llms.txt > Use this file to discover all available pages before exploring further. # アーキテクチャ（B2B） > Auth0テナントアーキテクチャの構成方法がB2B IAMの実装に及ぼす影響を説明します。 アプリケーションを理解することは、ニーズを満たすためにAuth0をどのように活用できるかを理解する上で重要な鍵となります。経験上、当社で最も成功しているお客様は、提案された（または多くの場合、既存の）アーキテクチャの視覚化から開始し、これを作業を進める際の参照の基礎としています。アプリケーションが組織内でどの位置付けにあるかを理解することも重要です。Auth0の[アカウントとテナント](/docs/ja-JP/ja-jp/get-started/auth0-overview/create-tenants)は、Auth0資産のグループ化と構造化の基盤を形成しており、[シングルサインオン（SSO）](/docs/ja-JP/ja-jp/authenticate/single-sign-on)、集中管理されたユーザー[プロファイル管理](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/business-to-business/profile-management)、統合された請求などと統合するために、既存のAuth0導入を活用する必要がある場合があります。 ### ベストプラクティス 複数のアプリケーションがあって、SSOを活用する必要がある場合、次に進む前に[「シングルサインオンの実装方法」](https://auth0.com/learn/how-to-implement-single-sign-on/)のトレーニングガイダンスを確認することをお勧めします。 アーキテクチャのランドスケープに事前に時間を投資すれば、長期的に見て利益をもたらすことがわかっています。また、機能やワークフローを検討する際には、考慮すべきことが数多くあります。 * Auth0がユーザーにWebページを表示する必要がある場合、URLはどのようなものであるべきか。 * SDLC（ソフトウェア開発ライフサイクル）をサポートするには、Auth0をどのように構成すればよいか。 * Auth0テナントが契約に適切に関連付けられていることを確認するにはどうすればよいか。 * 組織内にAuth0と統合する他のプロジェクトがある場合、何を考慮すればよいか。特に、自身のドメイン、または別のドメインのユーザーを対象としたプロジェクト（たとえば、従業員だけが使用するアプリケーション）です。 * 顧客の組織の構造やドメインをAuth0のデプロイメントに対してどのように合わせることができるか。 多くの場合、組織は複数のドメインのユーザーにサービスを提供します。顧客、従業員、関連会社が最も頻繁に利用しますが、通常、交差することはほぼありません。たとえば、従業員が顧客と同じアプリケーションを使用することはなく、その逆も同様です。場合によっては、ドメイン内をさらに分割する必要がある場合もあります。たとえば、接続されていない異なる製品を使用する顧客をグループに分ける場合などです。Auth0は、ユーザーと関連するコラテラルを分離する方法を提供しており、これについては、「[テナントプロビジョニング](#tenant-provision)」でさらに詳しく記載されています。独立したテナントをプロビジョニングする必要がある場合、[既存のAuth0アカウントにそのテナントを関連付けることで](#tenant-association)、組織の契約しているサブスクリプションレベルの利点を最大限に活用することができます。 ### ベストプラクティス たとえば、会社に、顧客、パートナー、従業員といった複数のユーザーグループに対応するためのID要件があることは、珍しいことではありません。アーキテクチャを設計する際に別のプロジェクトまたは将来の要件を検討するようにしてください。 さらに、ソフトウェア開発ライフサイクル（SDLC）の一部として、一連のプロセスと手順を確立することはおそらく間違いないでしょう。そのため、Auth0テナントのプロビジョニングに関する[SDLCサポート](#sdlc-support)ガイダンスも確認することをお勧めします。 顧客向けアプリケーションでは、一般的に[OpenID Connect（OIDC）](/docs/ja-JP/ja-jp/authenticate/protocols/openid-connect-protocol)が最も頻繁に使用されるプロトコルです。OIDCは、ユーザーに対して表示されるブラウザーURLを使ったWebベースのワークフローを利用します。Auth0 OIDCサポートの一環としてそのまま使えるクライアント向けのURLはAuth0のブランディングになっていますが、ユーザーの懸念を生じさせないために、Auth0の[カスタムドメイン](#custom-domains)機能を使って会社のブランディングに統一させることをお勧めします。 ### ベストプラクティス 組織内にAuth0を使用するグループが他にもあるケースがあります。弊社の顧客の中には、ユーザーコミュニティ別に個別の部署を設けてサービスを提供している会社も少なくありません。こういった要素を早い段階で特定して意思決定に反映させれば、後でコストが生じるような判断を防ぐことができます。 顧客組織の一部またはすべてが独自のカスタムURLを必要とする場合、または組織のブランド化されたカスタム同意ページが必要なソーシャルプロバイダーを使用している場合は、それらの組織に対して個別のAuth0テナントを作成することをお勧めします。詳細については、「[複雑な組織向けのテナントプロビジョニング](#tenant-provision-for-complex-organizations)」をご覧ください。
## テナントプロビジョニング
すべてはAuth0テナントから始まります。ここはAuth0の使用を構成する場所であり、[アプリケーション](/docs/ja-JP/ja-jp/get-started/applications)や[接続](/docs/ja-JP/ja-jp/connections)、[ユーザープロファイル](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/business-to-business/profile-management)などのアセットが定義、管理、保存される場所です。Auth0テナントへのアクセスはAuth0 [Dashboard](/docs/ja-JP/ja-jp/get-started/auth0-overview/dashboard)を通じて行われ、Dashboardを通じて追加の関連テナントを作成することもできます。複数のAuth0テナントを作成できるため、さまざまなユーザードメインを分離し、[Software Development Life Cycle（ソフトウェア開発ライフサイクル）](#sdlc-support)（SDLC）のサポートもします。 テナント名は、変更できず、削除したものを再利用することもできません。Auth0テナントを作成する前に慎重に名前を決めてください。 ユーザードメインに関して必要な分離レベルを決定することは重要なステップであり、ブランディング要件と合わせて、運用環境で必要なAuth0テナントの数を決定するのに役立ちます。[SDLCがサポートするテナント](#sdlc-support)の完全なスイートを作成することを推奨しています。そのため、管理する必要のあるAuth0テナントの数が急速に増加する可能性があります。したがって、運用のための複数のAuth0テナントを作成する前に慎重に検討する必要があります。また、最終的な決定を下す前に「[ブランディング](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/business-to-business/branding)」をご確認ください。
### 複雑な組織のテナントプロビジョニング
ほとんどの場合、顧客の組織に個別のAuth0テナントをプロビジョニングする必要はありません。新しい[Organization機能](/docs/ja-JP/ja-jp/manage-users/organizations/organizations-overview)の導入により、これはさらに簡単になりました。ただし、特定の状況では、これはセットアップの複雑さを軽減するのに役立つ場合があります。たとえば、次の場合には、ベストプラクティスとして顧客の組織に別のAuth0テナントをプロビジョニングすることをお勧めします。 * 顧客組織に、組織に固有のカスタムログインURLが必要な場合。これは通常、組織が共通のログインURLを使用する代わりに独自のバニティーURLを持つことを許可している場合にのみ当てはまります。Auth0は、1つのテナントにつき1つのカスタムドメインをサポートします。 * 顧客組織がログインにソーシャルプロバイダーを使用する場合。この場合、組織は、組織のブランド化されたソーシャルプロバイダー用のカスタム同意ページを持つことが望ましいとされることが多いです。 以上のどちらかの状況に該当する場合は、上記の基準に当てはまる組織ごとに個別のAuth0テナントを作成することをお勧めします。 複数のAuth0テナントを維持するシステムは、複雑になるため、絶対に必要でない限り行わないでください。
## テナントの関連付け
お客様の[テナントがすべてAuth0の契約に基づいており](/docs/ja-JP/ja-jp/get-started/auth0-overview/create-tenants/child-tenants)、同じ機能を持つことを確認するために、すべてのテナントを会社のアカウントに関連付けてください。テスト用に独自のサンドボックスを作成したい開発者が他にいる場合は、それらの開発者にも同じ権限が付与されるように、お持ちのアカウントにそれらの開発者を関連付けてください。これを行うには、Auth0の担当者または[Auth0サポートセンター](https://support.auth0.com)にご連絡ください。
## カスタムドメイン
Auth0テナントをセットアップすると、そのテナントにアクセスするためのURLの形式は`https://{yourTenant}.auth0.com`になります。[カスタムドメイン](/docs/ja-JP/ja-jp/customize/custom-domains)（バニティーURLとも呼ばれる）を提供することは、ブランディング要件をサポートするための重要な要素になるだけでなく、さらに重要なこととして、セキュリティ上の利点ももたらします。 * 一部のブラウザーでは、デフォルトで、[共有ドメインがない場合、デフォルトでiFrameでの通信が困難になります](/docs/ja-JP/ja-jp/troubleshoot/authentication-issues/renew-tokens-when-using-safari)。 * [バニティーURLがある場合](https://auth0.com/blog/introducing-custom-domains-preview-with-auth0/)、URLを模倣するにはバニティーURLを作成する必要があるため、ドメインのフィッシング詐欺が難しくなります。たとえば、カスタムドメインを使用すると、独自の証明書を使用して「拡張認証」を取得できるため、フィッシングがより困難になります。 1つのAuth0テナントに許可されるカスタムドメインは1つのみです。これは、Auth0のテナントがユーザーの「ドメイン」を意図しているためです。複数のバニティーURLが必要な場合は、ユーザーのドメインが複数あるはずですので、複数のテナントを使用してください。 また、カスタムドメイン名は、これが資格情報を入力する適切な場所であるという確信をユーザーに与える必要があります。したがって、環境間で一貫したテストを確実に行うために、早い段階ですべての環境でカスタムドメインを作成することをお勧めします。**資格情報を入力するときに、疑わしいURLを探すようにユーザーをトレーニングすることが非常に重要です。** ### ベストプラクティス Auth0テナント用のカスタムドメイン（または`CNAME`）を作成し、開発用にも1つ作成して、`CNAME`を適切に管理しているかを確認してください。たとえば、`login.mycompany.com`を`mycompany-prod.auth0.com`にマッピングする`CNAME`を作成できます。 ほとんどの場合、顧客は複数の製品またはサービスブランドにわたって認証を行うための集中型ドメインの戦略を採用したときに最も成功しています。この戦略により、ユーザーに一貫したUXが提供され、運用環境で複数のAuth0テナントを展開および維持する際の複雑さも軽減されます。異なるブランドに対して複数のドメインの使用を検討している場合は、実装を開始する前に「[ブランディング](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/business-to-business/branding)」のガイダンスをご参照ください。
## SDLCサポート
どの会社にも何らかの形のソフトウェア開発ライフサイクル（SDLC）があり、開発プロセス全体を通じてその戦略に従うのが普通です。たとえば、アプリケーション自体をテストするのと同様の方法で、Auth0との統合をテストできる必要があります。したがって、[SDLCをサポートするためにAuth0テナントを構築すること](/docs/ja-JP/ja-jp/get-started/auth0-overview/create-tenants/set-up-multiple-environments)が重要です。そのためのテナントレイアウトに関連するベストプラクティスに関しては、顧客が通常従う一貫したパターンがあります。
環境 サンプルテナント名 説明
開発 company-dev 主に開発作業が行われる共有環境
QA/テスト company-qaまたはcompany-uat 変更内容の正式なテストを行う環境
運用 company-prod 運用環境のテナント
場合によっては、変更をテストするために複数のsandbox（例：**company-sandbox1** 、**company-sandbox2** ）を作成することも考えられます。これにより、運用環境を損なうことなくテストを行うことができます。これが、デプロイメントスクリプトなどをテストする場所になるかもしれません。 ### ベストプラクティス 実装のプロジェクトニーズに合わせてダウンロードしてカスタマイズできる[「実装チェックリスト」](/docs/ja-JP/ja-jp/architecture-scenarios/checklists)も活用できます。 エンタープライズサブスクリプションをご利用の場合は、SDLCをサポートするテナントのセットアップが正しく[サブスクリプションにリンク](/docs/ja-JP/ja-jp/get-started/auth0-overview/create-tenants/child-tenants)されていることを確認してください。そうすれば、各テナントで一貫して同じ機能セットが有効化されます。
## プロジェクト計画ガイド
当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。 [B2B IAM Project Planning Guide](http:///assets.ctfassets.net/cdy7uua7fh8z/63F0WOPJdVzsPMxV1Xvp8x/7a329487c5e890d8e820f6a48983b46a/B2B_Project_Planning.pdf)
## 複数Organizationアーキテクチャ（マルチテナント機能）
B2Bプラットフォームの多くが顧客のOrganizationを何らかの形で分離・ブランディングし、これがIDおよびアクセス管理（IAM）システムをさらに複雑にしています。この問題でお困りであれば、当社がそのような環境に合ったガイダンスとベストプラクティスをご紹介していますので、時間を割いてお読みになることをお勧めします。 [複数Organizationアーキテクチャ](/docs/ja-JP/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture)