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

# ルール環境のベストプラクティス

> Auth0のルールを構築するためのベストプラクティスについて説明します。

<Warning>
  RulesとHooksのサポート終了（EOL）日は**2026年11月18日** であり、**2023年10月16** 日の時点で作成された新しいテナントは使用できなくなります。Hooksが有効な既存のテナントは、サポート終了までHooksを利用できます。

  今後はActionsに移行して、Auth0の機能を拡張することを強くお勧めします。Actionsを使用すると、豊富な情報やインラインドキュメント、パブリック`npm`パッケージにアクセスして、外部統合を使って全体的な拡張エクスペリエンスを強化することができます。Actionsの詳細については、「[Auth0 Actionsの仕組みを理解する](/docs/ja-jp/customize/actions/actions-overview)」をお読みください。

  当社では、移行の参考資料として、[RulesからActionsへの移行](/docs/ja-jp/customize/actions/migrate/migrate-from-rules-to-actions)と[HooksからActionsへの移行](/docs/ja-jp/customize/actions/migrate/migrate-from-hooks-to-actions)に関するガイドを提供しています。また、専用の「[Actionsへの移行](https://auth0.com/extensibility/movetoactions)」ページでは、機能の比較や[Actionsのデモ](https://www.youtube.com/watch?v=UesFSY1klrI)、その他のリソースを掲載して、円滑な移行をサポートしています。

  RulesとHooksの廃止の詳細については、当社のブログ記事「[RulesとHooksの提供終了について](https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/)」をお読みください。
</Warning>

ルールは一連のJavaScript関数を呼び出して、Auth0のサーバーレスWebtask**コンテナー** のインスタンスで実行します。これに関して、コンテナーとAuth0認証サーバー（ご利用のAuth0テナント）による各種のアーティファクトと共に、特定の環境が提供されます。

## npmモジュール

Auth0のサーバーレスWebtaskコンテナーでは、さまざまな[`npm`](https://www.npmjs.com/)モジュールを利用することができます。npmモジュールはルールのコード実装で総サイズを低減するだけでなく、予め構築された幅広い機能を活用できるようにします。

デフォルトで、公開されているnpmモジュールの広範なリストが、変更することなくそのままで使用できます。このリストは、潜在的なセキュリティ関連の懸念を調査した上でまとめられています。リストを表示するには、「[必要性の判断：Auth0の拡張性](https://auth0-extensions.github.io/canirequire/)」をお読みください。

必要な`npm`モジュールが提供されていない場合には、[Auth0のサポートポータル](https://support.auth0.com/)またはAuth0の担当者までリクエストを提出してください。Auth0がリクエストを検討して、適合性を判断します。プライベートリポジトリで提供されている`npm`モジュールについては、その使用に関して、Auth0は現在サポートを提供していません。リクエストされた場合、新しいパッケージは通常2週間ごとに追加されます。ルールで破壊的変更の原因となるため、既存のパッケージが削除されることはめったにありません。Auth0のパッケージとバージョンは内部レジストリに保管され、`npm`とは同期していない点に注意してください。

`npm`モジュールで外部サービスにアクセスしている場合は、API要求を最小限に抑え、有料サービスへの過剰な呼び出しを控え、送信内容を制限して潜在的なセキュリティ露出を回避してください。詳細については、「[パフォーマンスのベストプラクティス](/docs/ja-jp/troubleshoot/performance-best-practices)」をお読みください。

ルールでモジュールを必須にするときに、バージョンが指定されていない場合、パッケージマネージャーは内部リストで見つかった最初のバージョンを使用します。パッケージマネージャーがデフォルト以外のバージョンを使用するように、バージョンを指定することもできます。そうすることで、ルールコードは、指定されたバージョンでは提供され、デフォルトのバージョンでは提供されていない修正や機能を活用することができます。

## 環境変数

Auth0 Rulesは環境変数に対応しており、グローバルに使用可能な構成オブジェクトを介して使うことができます。構成は読み取り専用として扱い、資格情報やAPIキーなど、外部サービスへのアクセスに使う機密性の高い情報を保管するために使用します。そうすれば、ルールで機密性の高い値をコードに埋め込まなくてすみます。変数にテナント特定の値が定義できるようなるため、ソフトウェア開発ライフサイクル（SDLC）のベストプラクティス戦略に対応させることができます。これにより、ルールの実行テナントに依存して変わる値を、コードの中に埋め込む必要性が軽減されます。

### globalオブジェクト

Auth0のサーバーレスWebtaskコンテナーは、各Auth0テナントに関連付けられているプールからプロビジョニングされます。コンテナーインスタンスはそれぞれ`global`オブジェクトを使用可能にして、コンテナーインスタンス内で実行されるすべてのルールからアクセスできるようにします。`global`オブジェクトはグローバル変数として機能し、情報や関数を定義するのに使用できます。これは、パイプラインインスタンスにかからわず、（コンテナーで実行される）ルール全般に使用することができます。

```javascript lines theme={null}
global.tokenVerify = global.tokenVerify || function(token, secret) {
      /* The 'jwt.verify' function is synchronous, however wrapping with a promise
      * provides for better error management and integration within the logic
      * flow.
      */
      return new Promise(function(resolve, reject) {
      jwt.verify(
    token,
    secret,{
    clockTolerance: 5},
    function(err, decoded) {
      if (err) {
    reject(err);
      } else {
    resolve(decoded);
      }
      });
    });
    };
```

`global`オブジェクトは、ユーザーに特定されない機能性を提供するサードパーティ（ログなど）APIのアクセストークンや、Auth0で定義され、クライアントの資格情報フローで取得される独自のAPIへのアクセストークンなど、コストのかかるリソースのキャッシュにも使用できます。

パイプラインの実行では、ルールを複数回実行することができますが、運用のコンテキストによって異なります。ルールが実行されるコンテキストでは、既存のコンテナーインスタンスがAuth0テナントのプールからプロビジョニングされるか、新たにインスタンス化されます。Webtaskコンテナーの新しいインスタンスでは、`global`オブジェクトがリセットされます。このため、`global`オブジェクト内のすべての宣言には、初期化のプロビジョニング（上の例を参照）も含める必要があります。理想的には、その宣言はできるだけ早期（実行順で早期に実行されるルール内）に行います。

### auth0オブジェクト

`auth0`オブジェクトは、[`ManagementClient`](https://github.com/auth0/node-auth0#management-api-client)の特別に制限されたインスタンス（[Auth0以外のNode.jsクライアントライブラリー](https://github.com/auth0/node-auth0)で定義）で、Auth0 <Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-jp/glossary?term=management-api" tip="Management API: 顧客が管理タスクを実行できるようにするための製品。" cta="用語集の表示">Management API</Tooltip>への限定アクセスを提供します。このオブジェクトは主に、ルール内の`user`オブジェクトに関連付けられたメタデータを更新するの使用されます。

このように制限されているだけでなく（限られた数の`ManagementClient`メソッドを`user`アクセスのみに対応）、`auth0`オブジェクトに関連付けれらたアクセストークンでもスコープが`read:users`と`update:users`に制限されます。通常、ルール内からの実行が推奨される大半の操作では、これで十分になります。ただし、対応している全種類のメソッドと追加のスコープにアクセスする必要がある場合は、別の方法でManagement APIを使う必要があります。

ルール内から別の方法でManagement APIにアクセスするには通常、`ManagementClient`の独立したインスタンスを初期化します。これにより、レート制限ポリシーによる`429`エラー発生時の自動再試行ロジックを含む、すべての現行機能にアクセスすることができます。さらに、デフォルトのスコープのみが必要な場合は、`auth0`オブジェクトに関連付けられたアクセストークンを使って、新しいインスタンスを初期化することもできます。

`context`オブジェクトと同様に、`auth0`オブジェクトには機密性の高い情報が含まれているため、外部またはサードパーティサービスに渡してはなりません。その上、Auth0 Management API にはレート制限に加えて、遅延も関与するため、呼び出す頻度を慎重に考慮する必要があります。`context`オブジェクトについては、「[ルール実行のベストプラクティス](/docs/ja-jp/rules-best-practices/rules-execution-best-practices)」をお読みください。

`auth0`オブジェクト（およびAuth0 Management APIを呼び出す他のメカニズム）は控えめに使用し、例外とエラーの扱いを適切に行い、パイプライン実行の予期しない中断は防くようにしてください。

## もっと詳しく

* [ルールの構造に関するベストプラクティス](/docs/ja-jp/rules-best-practices/rules-anatomy-best-practices)
* [ルールの実行に関するベストプラクティス](/docs/ja-jp/rules-best-practices/rules-execution-best-practices)
* [ルールセキュリティのベストプラクティス](/docs/ja-jp/rules-best-practices/rules-security-best-practices)
* [ルールのテストに関するベストプラクティス](/docs/ja-jp/rules-best-practices/rules-testing-best-practices)
* [エラー処理のベストプラクティス](/docs/ja-jp/troubleshoot/error-handling-best-practices)