> ## Documentation Index > Fetch the complete documentation index at: https://auth0.com/llms.txt > Use this file to discover all available pages before exploring further. # テナントチェック（B2C） > B2C IAM実装のローンチ前に行うべきテナントチェック。 このセクションでは、チェックすべきテナント内の構成を一覧にして説明します。開発中に定期的に確認し、ローンチ前には十分な時間を確保して問題点を修正できるようにしておく必要があります。 ## 一般テナントチェック ### テナント準備チェック テナント環境がSDLCライフサイクルをサポートするように設定されていること、また開発、テスト、運用のテナントが明確に分離されており、ローンチ後の継続的な開発作業が運用環境に悪影響を与えないことを確認してください。 どの会社にも何らかの形のソフトウェア開発ライフサイクル（SDLC）があり、開発プロセス全体を通じてその戦略に沿って進める必要があります。たとえば、アプリケーション自体をテストするのと同様の方法で、Auth0との統合をテストできる必要があります。[SDLCをサポートするようにAuth0テナントを構成する](https://auth0.com/docs/dev-lifecycle/setting-up-env)ことが重要で、そのためのテナントレイアウトに関連するベストプラクティスに関しては、顧客が通常従う一貫したパターンがあります。 | 環境 | サンプルテナント名 | 説明 | | ------ | -------------------------------- | ---------------- | | 開発 | **company-dev** | 主に開発作業が行われる共有環境 | | QA/テスト | **company-qa**または**company-uat** | 変更内容の正式なテストを行う環境 | | 運用 | **company-prod** | 運用環境のテナント | 場合によっては、開発環境に支障を来すことなく変更をテストできるよう、1つ以上のサンドボックス（例：**company-sandbox1** 、**company-sandbox2** ）を作成することができます。これが、デプロイメントスクリプトなどをテストする場所になるかもしれません。 **ベストプラクティス** 実装のプロジェクトニーズに合わせてダウンロードしてカスタマイズできる[「実装チェックリスト」](/docs/ja-jp/architecture-scenarios/checklists)も活用できます。 ### テナントの関連付けチェック お客様の[テナントがすべてAuth0の契約に基づいており](/docs/ja-jp/get-started/auth0-overview/create-tenants/child-tenants)、同じ機能を持つことを確認するために、すべてのテナントが会社のアカウントに関連付けられていることを確認してください。テスト用に独自のサンドボックスを作成したい開発者が他にいる場合は、それらの開発者にも同じ権限が付与されるように、お持ちのアカウントにそれらの開発者を関連付けてください。これを行うには、Auth0の担当者または[Auth0サポートセンター](https://support.auth0.com)にご連絡ください。 ### 運用テナントを指定する Auth0が運用テナントを認識するように、サポートセンターで「production」フラグを[運用テナントに設定](/docs/ja-jp/dev-lifecycle/setting-up-env#set-the-environment)してください。 ### テナントの運用チェック Auth0は、一般的なエラーを検出するための[運用チェック](/docs/ja-jp/deploy-monitor/pre-deployment-checks)機能を用意しています。この機能を実行し、レポートのエラーをローンチ前にすべて解消・軽減していることを確認する必要があります。 さらに、自動チェックができない項目についても、[構成のベストプラクティスに関するアドバイス](/docs/ja-jp/deploy-monitor/pre-deployment-checks/production-checks-best-practices)を確認してください。 ### テナント設定のチェック #### テナント設定 問題が発生した場合にユーザーがサポートを受ける方法を知ることができるように、URLブランディング、サポートメール、サポートを構成する際には、Auth0[テナント設定](/docs/ja-jp/get-started/tenant-settings)の推奨事項に必ず従ってください。SSOセッションのタイムアウト設定や、運用テナントにアクセスできるダッシュボード管理者のリストも確認する必要があります。 #### エラーページのカスタマイズ インタラクティブなワークフロー（ユーザーサインアップやログインなど）中に問題が発生した場合は、内部の問題を示したエラーメッセージが表示されます。既定のメッセージは、とりわけエンドユーザーにとっては、やや不可解なものです。これは、貴社だけが提供できるコンテキストが不足している可能性があるためです。そのため、不足しているコンテキスト固有の情報をユーザーに直接提供するように、[エラーページをカスタマイズ](/docs/ja-jp/customize/login-pages/custom-error-pages)することを推奨します。加えて、エラーメッセージをカスタマイズすると、Auth0でなく貴社のブランディングを表示できるほか、次に実行すべき操作に関して、ユーザーに有益な情報を提供することができます。この情報には、FAQへのリンク、会社のサポートチームやヘルプデスクへの連絡方法などが含まれます。 ### ベストプラクティス 最初は、Auth0提供のエラーページをカスタマイズするユーザーインターフェイスはありませんが、[「Management APIのテナント設定エンドポイント」](/docs/ja-jp/api/management/v2#!/Tenants/patch_settings)を使用して、構成することができます。または、独自のエラーページを作成してホストできる場合、Auth0がホストするオプションを使用する代わりに、そのページにユーザーをリダイレクトすることも可能です。 #### レガシー機能フラグのチェックと移行 古いテナントをお持ちの場合、[［Tenant Settings（テナント設定）］の［Advanced（詳細設定）］タブ](/docs/ja-jp/get-started/tenant-settings)で、多くのレガシー機能フラグがオンになっていることがあります。このタブの［Migrations（移行）］セクションで有効になっているトグルがある場合は、使用状況を確認し、レガシー機能から移行する計画を立てる必要があります。 #### 委任管理拡張機能 運用テナントにアクセスできるユーザーのリストを確認する際に、[委任管理拡張機能](/docs/ja-jp/customize/extensions/delegated-administration-extension)で指定したすべてのユーザーの確認を行うようにしてください。 ### カスタムドメイン名のセットアップ デフォルトでは、テナントに関連付けられたURLは、その名前と、場合によっては地域固有の識別子を含むことになります。たとえば、米国に基づくテナントのURLは`https://example.auth0.com`に類似したもので、ヨーロッパに基づくテナントのURLは`https://example.eu.auth0.com`に類似したものになります。[カスタムドメイン](/docs/ja-jp/customize/custom-domains)は、組織のブランドと一貫性を持つ名前を使用することで、ユーザーに一貫したエクスペリエンスを提供してくれます。 Auth0テナントでは、それぞれ1つのカスタムドメイン名しか適用できません。そのため、独立したドメイン名のブランディングがどうしても必要な場合は、運用環境に複数のAuth0テナントをデプロイした[アーキテクチャ](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/architecture)が必要となります。 さらに、カスタムドメイン機能を使用することで、証明書管理プロセスを完全に掌握することができます。デフォルトで、Auth0は標準SSL証明書を発行しますが、カスタムドメインを構成する場合は、拡張検証（EV）SSL証明書またはそれに類似するものを使用して、ブラウザーベースの視覚的合図を出します。これによって、訪問者にさらなる安心感を与えてくれます。 一般に、認証に集中型ドメインを使用すると、顧客満足度が一番高くなります。これは、会社が複数の製品またはサービスブランドを提供する場合に特に言えることです。中央集中型のドメインを使用することで、エンドユーザーに一貫したユーザーエクスペリエンスを提供し、Auth0内で複数の運用テナントを維持する必要を最小限に抑えることができます。 ## アプリケーションと接続設定のチェック 各接続設定は、「[接続構成のベストプラクティス](/docs/ja-jp/authenticate/connection-settings-best-practices)」に照らして確認する必要があります。 さらに、すべての接続が適切であり、実験的な接続が運用テナントに残されていないことを確認してください。これにより、認可されていないアクセスを防ぐことができます。 SAML接続を使用する場合、接続を構成してSAML要求に署名することがベストプラクティスです。 ## ページカスタマイズのチェック Auth0のユニバーサルログインページ、パスワードリセットページ、またはGuardianの多要素認証（MFA）を使用する場合は、エンドユーザーに表示されるページが適切にカスタマイズされているか確認する必要があります。 ### ユニバーサルログインページ [ユニバーサルログイン](/docs/ja-jp/authenticate/login/auth0-universal-login)は、ユーザー認証で推奨される方法であり、ログインページの使用を中心にしています。組織のブランディング要件に合わせてログインページはカスタマイズできます。 ### ベストプラクティス ユニバーサルログインページのスクリプトをカスタマイズすることを選択する場合、バージョン制御を活用することを強くお勧めします。この作業に伴うAuth0テナントでのスクリプトのデプロイは、[デプロイメントの自動化](/docs/ja-jp/architecture-scenarios/b2b/deployment)または[代わりのストラテジー](/docs/ja-jp/universal-login/version-control)のいずれかを経由して行ってください。 ### パスワードリセットページ [パスワードリセット](/docs/ja-jp/customize/login-pages/classic-login/customize-password-reset-page)ページは、ユーザーがパスワード変更機能を利用する際に使用され、ログインページと同様に、組織の特定のブランディング要件を反映するようにカスタマイズできます。 ### Guardian 多要素認証（MFA）ページは、[［Universal Login Settings（ユニバーサルログイン設定）］](https://manage.auth0.com/#/login_settings)セクションでユニバーサルログインのブランディングオプションを変更してカスタマイズすることができます。 さらなるカスタマイズが必要な場合は、[HTMLコンテンツの全体](/docs/ja-jp/secure/multi-factor-authentication/customize-mfa/customize-mfa-classic-login)をカスタマイズして、組織に固有なユーザーエクスペリエンス要件を反映させることもできます。 ## 認可のチェック Auth0の認可機能を使用している場合は、認可が運用環境に適していることを確認するために、付与されている権限を再確認してください。 ## API構成のチェック ### アクセストークンの有効期限 [APIアクセストークンの有効期限設定](/docs/ja-jp/get-started/apis/api-settings)が運用環境の各APIに適していることを再確認してください。 ### APIのオフラインアクセス アプリケーションがリフレッシュトークンを要求しない場合は、これがオフになっている必要があります。 ### アクセストークンの署名アルゴリズム 署名鍵の露出を最小化するために、[APIアクセストークンの署名アルゴリズム](/docs/ja-jp/get-started/applications/signing-algorithms)をHS256ではなくRS256に設定することをお勧めします。 ### APIアクセストークンの検証 カスタムAPIがある場合は、受信する[アクセストークンの検証](/docs/ja-jp/secure/tokens/access-tokens/validate-access-tokens)を適切に行ってからその情報を使用していることを確認してください。 ## APIスコープ マシンツーマシンでAPIに呼び出しを行うアプリケーションがある場合は、APIに指定されているスコープを確認して、すべてが運用環境に適切であることを確認してください。詳細については、[クライアント資格情報の付与](/docs/ja-jp/get-started/applications/update-grant-types)に関するドキュメントをお読みください。 ## ルール/フックのチェック ルールが、Auth0が提供している「[ルールのベストプラクティス](/docs/ja-jp/rules-best-practices)」に沿っていることを確認してください。 ## メールテンプレートのカスタマイズ Auth0は、ユーザー通知や、安全なID管理に必要な機能（メール検証、アカウント復旧、総当たり攻撃防御など）を提供するためにメールを幅広く利用しており、これらの用途のテンプレートも多数用意しています。 メールテンプレートをカスタマイズする前に、[メールプロバイダー](/docs/ja-jp/architecture-scenarios/b2c/operations#email-provider-setup)をセットアップしてください。 そのまま使えるメールテンプレートには、標準的な言い回しとAuth0のブランディングが含まれています。しかし、希望する言い回しやユーザーエクスペリエンスを反映するように、これらのテンプレートのほぼすべての側面を構成し、優先的に使用する言語やアクセシビリティオプションなどの項目に変更を加えることができます。 メールテンプレートは、[Liquid構文](/docs/ja-jp/customize/email/email-templates/use-liquid-syntax-in-email-templates)を使用してカスタマイズされます。ユーザーの好みに基づいてテンプレートをカスタマイズしたい場合は、ユーザープロファイル内の[メタデータ](/docs/ja-jp/manage-users/user-accounts/metadata)や特定のアプリケーションメタデータにもアクセスできます。 ## 攻撃防御の構成 認証システムが重要な理由は、悪意のある行為者が権限のないアプリケーションやユーザーデータにアクセスすることを防ぐためです。我々は、悪意のある行為者とシステムへのアクセスの間に、できる限り多くの障壁を配備したいと考えます。最も簡単な方法は、Auth0で[攻撃防御](/docs/ja-jp/secure/attack-protection)を確実に正しく構成することです。そのためにも、このトピックに関するガイダンスを注意して読み、正しく動作していることを確認してください。 ### ベストプラクティス Auth0では異常の検出を水面下で行っており、お客様の製品に優れた安全機能を提供しています。この機能を活用するには、ユーザーへのメール配信を開始する前に、[メールプロバイダー](/docs/ja-jp/architecture-scenarios/b2c/operations#email-provider-setup)のセットアップと、[メールテンプレート](/docs/ja-jp/architecture-scenarios/b2c/branding#email-template-customization)の構成を行ってください。 ## プロジェクト計画ガイド 当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。 [B2C IAM Project Planning Guide](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)