> ## Documentation Index
> Fetch the complete documentation index at: https://docs-staging-feat-init-gt-translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> B2B IAM 実装のローンチ前に実施する テナント チェック。

# テナント チェック (B2B)

このセクションでは、テナント で確認すべき設定項目の一覧を説明します。これは開発中に定期的に、また問題が見つかった場合に修正する時間を確保できるよう、ローンチの十分前にも実施してください。

<h2 id="general-tenant-check">
  一般的なテナントの確認
</h2>

<h3 id="tenant-preparation-check">
  テナント準備チェック
</h3>

ソフトウェア開発ライフサイクルを支えられるようにテナント環境が設定されており、Dev、Test、Prod の各テナントが明確に分離されていることを確認してください。これにより、ローンチ後も継続する開発作業が本番環境に悪影響を及ぼすのを防げます。

どの企業にも何らかの形のソフトウェア開発ライフサイクル (SDLC) があり、開発プロセス全体を通してその戦略に沿う必要があります。たとえば、アプリケーション自体をテストするのと同じように、Auth0 との連携もテストできる必要があります。そのため、[SDLC を支えられるように Auth0 テナントを構成する](/docs/ja-jp/get-started/auth0-overview/create-tenants/set-up-multiple-environments)ことが重要です。その際のテナントレイアウトに関するベストプラクティスとしては、お客様が一般的に採用している一貫したパターンがあります。

| 環境     | テナント名の例                            | 説明                   |
| ------ | ---------------------------------- | -------------------- |
| 開発     | **company-dev**                    | 開発作業の大半を行う共有環境       |
| QA/テスト | **company-qa** または **company-uat** | 実施した変更を正式にテストするための環境 |
| 本番     | **company-prod**                   | 本番テナント               |

場合によっては、開発環境に影響を与えずに変更をテストできるよう、1 つ以上のサンドボックス (例: **company-sandbox1**、**company-sandbox2**) を作成することもあります。こうした環境は、デプロイスクリプトなどのテストにも利用できます。

<Info>
  <h3 id="best-practice">
    ベストプラクティス
  </h3>

  ダウンロードして実装プロジェクトのニーズに合わせてカスタマイズできる [実装チェックリスト](/docs/ja-jp/get-started/architecture-scenarios/checklists) も活用できます。
</Info>

<h3 id="tenant-association-check">
  テナントの関連付けの確認
</h3>

[すべてのテナントが Auth0 の契約に関連付けられ](/docs/ja-jp/get-started/auth0-overview/create-tenants/child-tenants)、同じ機能を利用できるようにするには、すべてのテナントが貴社のアカウントに関連付けられていることを確認してください。各開発者がテスト用に独自のサンドボックスを作成する場合も、同じ権限を利用できるよう、それらを貴社のアカウントに関連付けるようにしてください。これを行うには、Auth0 の担当者または [Auth0 Support Center](https://support.auth0.com/center/s/) にお問い合わせください。

<h3 id="specify-production-tenant">
  本番テナントを指定する
</h3>

Auth0 が本番テナントを認識できるようにするには、Support Center で「production」フラグを設定して、必ず[本番テナントを設定](/docs/ja-jp/get-started/auth0-overview/create-tenants/set-up-multiple-environments#set-the-environment)してください。

<h3 id="tenant-production-check">
  テナント本番チェック
</h3>

Auth0 には、多くの一般的なエラーを検出するための [Production Check](/docs/ja-jp/deploy-monitor/pre-deployment-checks) 機能があります。ローンチ前にこのチェックを実行し、レポートで指摘された事項に対処しておく必要があります。

さらに、自動では確認できない項目については、[ベストプラクティス構成に関するアドバイス](/docs/ja-jp/deploy-monitor/pre-deployment-checks/production-checks-best-practices) も確認してください。

<h3 id="tenant-settings-check">
  テナント設定の確認
</h3>

<h4 id="tenant-settings">
  テナント設定
</h4>

問題が発生した際にユーザーがサポートの受け方を把握できるよう、ロゴ、サポートメール、サポート URL を設定する際は、Auth0 の [テナント設定](/docs/ja-jp/get-started/tenant-settings) の推奨事項に必ず従ってください。あわせて、<Tooltip tip="シングルサインオン（SSO）: ユーザーが1つのアプリケーションにログインすると、他のアプリケーションにも自動的にログインできるようにするサービスです。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=SSO">SSO</Tooltip> のセッションタイムアウト設定と、本番テナントにアクセスできる Dashboard の Admin 一覧も確認しておくとよいでしょう。

<h4 id="error-page-customization">
  エラーページのカスタマイズ
</h4>

ユーザーによる対話型のワークフロー (例: サインアップやログイン) の実行中に問題が発生すると、Auth0 は内部的に何が問題なのかを示すエラーメッセージを表示します。ただし、デフォルトのメッセージはやや分かりにくく、特にエンドユーザーにとってはそうです。エンドユーザーには、あなたが補足できる文脈情報が不足していることが多いためです。そのため、不足している文脈に応じた情報をユーザーに直接伝えられるよう、[エラーページをカスタマイズする](/docs/ja-jp/customize/login-pages/custom-error-pages)ことをお勧めします。さらに、エラーページをカスタマイズすれば、Auth0 ではなく自社のブランドを表示できるだけでなく、次に何をすべきかについて役立つ情報もユーザーに提供できます。たとえば、FAQ へのリンクや、貴社のサポートチームまたはヘルプデスクへの連絡方法などを含めることができます。

<Info>
  <h3 id="best-practice-2">
    ベストプラクティス
  </h3>

  標準では、Auth0 が提供するエラーページをカスタマイズするためのユーザーインターフェースは用意されていませんが、設定には [Management API の Tenant Settings エンドポイント](https://auth0.com/docs/api/management/v2#!/Tenants/patch_settings)を使用できます。別の方法として、独自のエラーページを作成してホストできる場合は、Auth0 がホストするページの代わりに、そのページへユーザーをリダイレクトするよう Auth0 を設定することもできます。
</Info>

<h4 id="legacy-feature-flags-off">
  レガシー機能フラグをオフにする
</h4>

古くからあるテナントでは、[テナント設定のAdvancedタブ](/docs/ja-jp/get-started/tenant-settings)で複数のレガシー機能フラグが有効になっている場合があります。このタブの「Migrations」セクションでいずれかのトグルがオンになっている場合は、現在の利用状況を確認し、レガシー機能から移行する計画を立ててください。

<h4 id="delegated-admin-extension">
  Delegated Admin Extension
</h4>

本番テナントにアクセスできるユーザー一覧を確認する際は、[Delegated Admin Extension](/docs/ja-jp/customize/extensions/delegated-administration-extension) で指定されているユーザーも忘れずに確認してください。

<h3 id="custom-domain-naming-set-up">
  カスタムドメイン名の設定
</h3>

デフォルトでは、テナントに関連付けられた URL には、その名前と、場合によってはリージョン固有の識別子が含まれます。たとえば、米国のテナントの URL は `https://example.auth0.com` のようになり、ヨーロッパのテナントでは `https://example.eu.auth0.com` のような形式になります。[カスタムドメイン](/docs/ja-jp/customize/custom-domains) を使用すると、組織 のブランドに合った名前を使って、ユーザーに一貫した体験を提供できます。

<Warning>
  1 つの Auth0 テナントに適用できるカスタムドメイン名は 1 つだけです。そのため、独立したドメイン名でのブランディングがどうしても必要な場合は、複数の Auth0 テナントを本番環境にデプロイする[アーキテクチャ](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/architecture)が必要です。
</Warning>

さらに、<Tooltip tip="カスタムドメイン: 特別な、または独自ブランドの名前を持つサードパーティのドメイン。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Custom+Domain">カスタムドメイン</Tooltip>機能を使うことで、証明書管理プロセスを完全に制御できます。デフォルトでは Auth0 が標準の SSL 証明書を提供しますが、カスタムドメインを設定すれば、Extended Validation (EV) SSL 証明書などを使用して、訪問者により大きな安心感を与えるブラウザベースの視覚的な संकेतを提供できます。

一般に、認証には一元化されたドメインを使用するお客様が、最も高い成果を上げています。これは特に、その企業が複数の製品やサービスブランドを提供している場合に当てはまります。一元化されたドメインを使用することで、エンドユーザーに一貫したユーザー体験を提供できるだけでなく、Auth0 で複数の本番テナントを維持する必要も最小限に抑えられます。

<h2 id="application-and-connection-settings-check">
  アプリケーションと接続設定の確認
</h2>

各接続設定は、[接続設定のベストプラクティス](/docs/ja-jp/authenticate/connection-settings-best-practices)に照らして確認する必要があります。

また、すべての接続が適切であり、本番テナントに実験用の接続が残っていないことも確認してください。そうした接続があると、不正アクセスを招くおそれがあります。

<Tooltip tip="Security Assertion Markup Language（SAML）: パスワードを使わずに 2 者間で認証情報をやり取りできる標準化されたプロトコル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=SAML">SAML</Tooltip> 接続を使用している場合は、接続が SAML リクエストに署名するよう設定することがベストプラクティスです。

<h2 id="page-customization-check">
  ページのカスタマイズ確認
</h2>

Auth0 の<Tooltip tip="Universal Login: アプリケーションは、ユーザーのアイデンティティを確認するために、Auth0 の認可サーバーでホストされている Universal Login にリダイレクトされます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=universal+login">Universal Login</Tooltip>ページ、パスワードリセットページ、または Guardian の<Tooltip tip="多要素認証 (MFA): SMS で送信されるコードなど、ユーザー名とパスワードに加えて認証要素を使用するユーザー認証プロセスです。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=multi-factor+authentication">多要素認証</Tooltip>を使用している場合は、エンドユーザーに表示されるページが適切にカスタマイズされていることを確認してください。

<h3 id="universal-login-page">
  Universal Login Page
</h3>

[Universal Login](/docs/ja-jp/authenticate/login/auth0-universal-login) は、ユーザーを認証するための推奨される方法であり、その中心となるのがログインページです。ログインページは、組織 のブランディング要件 に合わせてカスタマイズできます。

<Info>
  <h3 id="best-practice-3">
    ベストプラクティス
  </h3>

  Universal Login ページをカスタマイズするには、[ページテーマ](/docs/ja-jp/customize/login-pages/universal-login/customize-themes) を変更できるほか、動的な [ページテンプレート](/docs/ja-jp/customize/login-pages/universal-login/customize-templates) を作成することもできます。

  [クラシックログイン](/docs/ja-jp/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/classic-experience) を実装し、ログインページのスクリプトをカスタマイズする場合は、バージョン管理を利用することを強くおすすめします。これを行うには、[deployment automation](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/deployment) または [alternative strategies](/docs/ja-jp/customize/login-pages/classic-login/version-control) のいずれかを使用して、スクリプトを Auth0 テナントにデプロイしてください。
</Info>

<h3 id="password-reset-page">
  パスワードリセットページ
</h3>

[Password Reset](/docs/ja-jp/customize/login-pages/classic-login/customize-password-reset-page)ページは、ユーザーがパスワードを変更する際に使用され、ログインページと同様に、組織固有のブランディング要件を反映するようにカスタマイズできます。

<h3 id="guardian">
  Guardian
</h3>

多要素認証のページは、[Universal Login 設定](https://manage.auth0.com/#/login_settings)セクションで Universal Login のブランディングオプションを調整することでカスタマイズできます。

さらに細かくカスタマイズする必要がある場合は、組織固有の UX 要件に合わせて、[HTML コンテンツ全体](/docs/ja-jp/secure/multi-factor-authentication/customize-mfa/customize-mfa-classic-login)をカスタマイズすることもできます。

<h2 id="authorization-check">
  認可の確認
</h2>

Auth0 の認可機能を使用している場合は、付与されているすべての権限を必ず見直し、本番環境に適した認可設定になっていることを確認してください。

<h2 id="api-configuration-check">
  API設定の確認
</h2>

<h3 id="access-token-expiration">
  アクセストークンの有効期限
</h3>

本番環境の各APIに対して適切な設定になっていることを確認するため、[APIアクセストークンの有効期限設定](/docs/ja-jp/get-started/apis/api-settings)を再確認してください。

<h3 id="api-offline-access">
  API のオフラインアクセス
</h3>

アプリケーションが<Tooltip tip="リフレッシュトークン: ユーザーに再度ログインを求めることなく、更新されたアクセストークンを取得するために使用されるトークン。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=refresh+tokens">リフレッシュトークン</Tooltip>を要求しない場合は、これをオフにしてください。

<h3 id="access-token-signing-algorithm">
  アクセストークンの署名アルゴリズム
</h3>

署名鍵の露出を最小限に抑えるため、[API アクセストークンの署名アルゴリズム](/docs/ja-jp/get-started/applications/signing-algorithms) は、HS256 ではなく RS256 に設定することを推奨します。

<h3 id="api-access-token-validation">
  API アクセストークンのバリデーション
</h3>

カスタム API がある場合は、それらが受け取った[アクセストークンを十分にバリデーション](/docs/ja-jp/secure/tokens/access-tokens/validate-access-tokens)してから、その中の情報を使用していることを必ず確認してください。

<h2 id="api-scopes">
  API スコープ
</h2>

いずれかの API に対してマシンツーマシンの呼び出しを行うアプリケーションがある場合は、その API に指定されているスコープを見直し、いずれも本番環境に適切であることを確認してください。詳しくは、[クライアントクレデンシャルグラント](/docs/ja-jp/get-started/applications/update-grant-types) に関するドキュメントを参照してください。

<h2 id="email-templates-customized">
  メールテンプレートのカスタマイズ
</h2>

Auth0 では、ユーザーへの通知や、安全なアイデンティティ管理に必要な機能 (たとえば、メールアドレスの確認、アカウントの復旧、ブルートフォース対策) のためにメールを広く利用しており、そのためのテンプレートが複数用意されています。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  メールテンプレートをカスタマイズする前に、[メールプロバイダー](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/operations#email-provider-setup)を設定してください。
</Callout>

デフォルトでは、使用されるメールテンプレートには標準的な文言と Auth0 のブランディングが含まれています。ただし、これらのテンプレートはほぼあらゆる要素を設定できるため、希望する文言やユーザー体験を反映させたり、優先言語やアクセシビリティ設定などを変更したりできます。

メールテンプレートは、[Liquid 構文](/docs/ja-jp/customize/email/email-templates/use-liquid-syntax-in-email-templates)を使用してカスタマイズします。ユーザーの設定に基づいてテンプレートをカスタマイズしたい場合は、ユーザーのプロファイルにある[メタデータ](/docs/ja-jp/manage-users/user-accounts/metadata)に加えて、特定のアプリケーションのメタデータにもアクセスできます。

<h2 id="attack-protection-configured">
  攻撃対策の設定
</h2>

認証システムが重要なのは、<Tooltip tip="悪意のある攻撃者: 害を及ぼす意図を持って、事業や環境に脅威をもたらす存在（個人または集団）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=bad+actors">悪意のある攻撃者</Tooltip>が、本来アクセス権のないアプリケーションやユーザーデータにアクセスするのを防ぐためです。こうした攻撃者がシステムにアクセスするまでの間には、できるだけ多くの障壁を設けるべきです。そのための最も簡単な方法の 1 つが、Auth0 の[攻撃対策](/docs/ja-jp/secure/attack-protection)が正しく設定されていることを確認することです。少し時間を取ってこのトピックに関するガイダンスを確認し、ご利用の環境で正しく機能していることを確かめてください。

<Info>
  <h3 id="best-practice-4">
    ベストプラクティス
  </h3>

  異常検知は Auth0 によってバックグラウンドで処理され、製品にとって非常に有効なセキュリティ機能になります。これを利用する場合は、ユーザーへのメール配信を有効にする前に、[メールプロバイダー](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/operations#email-provider-setup)を設定し、[メールテンプレート](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/branding#email-template-customization)を構成しておいてください。
</Info>

<h2 id="project-planning-guide">
  プロジェクト計画ガイド
</h2>

推奨する戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドをご用意しています。

[B2B IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/63F0WOPJdVzsPMxV1Xvp8x/7a329487c5e890d8e820f6a48983b46a/B2B_Project_Planning.pdf)