> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-update-anonymous-sessons-ea.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# B2B のデプロイ自動化

> Deploy CLI または source control extensions を使用して、開発、テスト、本番の Auth0 テナント全体で Auth0 テナント構成のデプロイを自動化し、環境固有の値を安全に管理しながら B2B 環境の一貫性を維持します。

変更管理と[QA](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/quality-assurance)のベストプラクティスを採用することに加え、導入に成功している顧客は、自動化されたデプロイプロセスの一部として Auth0 の構成管理も組み込んでいます。[SDLC support](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/architecture#sdlc-support) の Architecture セクションで説明しているように、開発、テスト、本番の各環境には個別の Auth0 テナントを用意し、それぞれの環境のテナント構成をほぼ同一に保つことが重要です。デプロイを自動化することで、各環境のテナントを同じ構成に保ちやすくなり、環境間の構成差異に起因するバグの発生を抑えられます。

<Tip>
  デプロイ自動化の構成方法にかかわらず、デプロイ前に rules、custom DB scripts、hooks の単体テストを行い、デプロイ後にもテナントに対していくつかの統合テストを実施することをお勧めします。詳細については、[Quality Assurance](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/quality-assurance) のガイダンスを参照してください。
</Tip>

Auth0 では、デプロイ自動化の方法としていくつかの選択肢をサポートしており、必要に応じてそれらを組み合わせて使用することもできます。

* [Auth0 Deploy CLI tooling](/docs/ja-jp/deploy-monitor/deploy-cli-tool) では、既存の Continuous Integration/Continuous Deployment (CI/CD) パイプラインに組み込みやすい、使いやすいスクリプトを利用できます。
* CI/CD パイプラインに直接統合できない場合や、何らかの理由で CI/CD パイプラインがない場合は、Auth0 の [Source Control Extensions](/docs/ja-jp/customize/extensions) を使うことで、設定が容易で保守の手間もほとんどかからない基本的な自動化プロセスを構築できます。

<Warning>
  Deploy CLI Tool と source control extensions は、どちらも破壊的変更を引き起こす可能性があります。自動デプロイの合間に dashboard で直接行った手動変更は失われるおそれがあります。そのため、どちらかを使用する場合は、**すべて**の変更をツールで参照される source control subsystem からデプロイし、手動で変更を加えないようにする必要があります。
</Warning>

各環境では、環境固有の構成も必要になる場合があります。たとえば、Application の <Tooltip tip="Client ID: Auth0 から登録済みリソースに付与される識別値。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Client+ID">Client ID</Tooltip> や <Tooltip tip="Client Secret: Authorization Server に対して認証するためにクライアント（アプリケーション）が使用する秘密情報。クライアントと Authorization Server だけが知るべきものであり、推測されないよう十分にランダムでなければなりません。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Client+Secrets">Client Secrets</Tooltip> は Auth0 テナントごとに異なります。そのため、値をハードコードするのではなく、動的に参照できる仕組みが必要です。Auth0 では、環境固有の構成情報を扱う方法として、次の 2 つのアプローチをサポートしています。

* [テナント固有の変数](#tenant-specific-variables)を使用する
* Auth0 Deploy CLI tool を使用している場合は keyword replacement を使用する

<h2 id="tenant-specific-variables">
  テナント固有の変数
</h2>

Auth0 では、カスタム[拡張機能](/docs/ja-jp/customize/extensions)内から利用できる変数を設定できます。これは、Auth0 テナント用の環境変数のようなものです。開発、テスト、本番の各環境間でコードを移動するたびに変わる参照をハードコードする代わりに、テナントで設定した変数名をカスタム拡張コードから参照できます。これにより、実行時にテナント固有の値が設定された変数をコードから参照できるため、同じカスタムコードを変更せずに異なるテナントで使いやすくなります。

* Actions で変数を使用する場合は、[最初の Action を作成する](/docs/ja-jp/customize/actions/write-your-first-action)を参照して、エディターでシークレットを設定する方法を確認してください
* Rules で変数を使用する場合は、[値を設定する](/docs/ja-jp/customize/rules/configuration)方法を参照してください
* Hooks で変数を使用する場合は、エディターで[シークレットを設定する](/docs/ja-jp/customize/hooks/hook-secrets)方法を参照してください
* Custom DB Scripts で変数を使用する場合は、[設定パラメーター](/docs/ja-jp/authenticate/database-connections/custom-db/create-db-connection#step-3-add-configuration-parametersn#step-3-add-configuration-parameters)を参照してください

<Tip>
  テナント固有の値だけでなく、カスタムコード内に公開すべきでない機密情報を保持するためにも、変数を使用することをおすすめします。カスタムコードを GitHub/Gitlab/Bitbucket/VSTS にデプロイしている場合は、テナント固有の変数を使用することで、リポジトリ経由で機密値が漏えいするのを防げます。
</Tip>

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

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

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

<h2 id="multiple-organization-architecture-multitenancy">
  複数組織アーキテクチャ (マルチテナンシー)
</h2>

多くの B2B プラットフォームでは、顧客ごとに組織の分離やブランディングを何らかの形で実装しており、その結果、Identity and Access Management (IAM) システムが複雑になることがあります。これに該当する場合は、この種の環境に関するガイダンスやベストプラクティスをぜひご一読ください。

[複数組織アーキテクチャ](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture)