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

> レート制限がかかっているかどうかを判断する方法

# レート制限のユースケース

<div id="discover-when-requests-to-a-tenant-are-rate-limited">
  ## テナントへのリクエストがレート制限されているかを確認する
</div>

顧客の製品が Auth0 によってレート制限されているかどうかを確認する方法はいくつかあります。レート制限が発生する主な原因については、以下を参照してください。

<div id="tenant-logs">
  ### テナントログ
</div>

さまざまなテナントログを購読することで、リクエスト量に関する問題を把握できます。Auth0 でテナントログとオペレーションイベントログがどのように機能するかについては、[Logs](/docs/ja-jp/deploy-monitor/logs) を参照してください。

<div id="api_limit">
  #### api\_limit
</div>

`api_limit` イベントは、認証または <Tooltip tip="Management API: 顧客が管理タスクを実行できるようにするための製品。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Management+API">Management API</Tooltip> のグローバルな レート制限バケット で レート制限 を超過した直後にトリガーされます。別の レート制限バケット で レート制限 を超過した場合は、新しい `api_limit` イベントが生成されます。これにより、どの レート制限 設定によって API 呼び出しがトリガーされているのかを顧客が特定できるため、根本原因を診断するための重要な第一歩となります。

<div id="api_limit_warning">
  #### api\_limit\_warning
</div>

`api_limit_warning` ログは、顧客のリクエスト率が特定のレート制限バケットのリクエストトークンの80%を消費したときに発生します。同じレート制限バケットで、使用されるリクエストトークン数が1分後も80%を超えたままの場合、2つ目の警告ログが生成されます。別のレート制限バケットで80%のしきい値を超えた場合は、新しい `api_limit_warning` ログが作成されます。

<div id="appi-public-performance-burst-only">
  #### appi (Public Performance Burst のみ)
</div>

`appi` ログは、Public Performance Burst アドオンを利用している顧客テナントが、Authentication API の継続的なリクエストのレート制限である 100 RPS を超え、48 時間のバースト割り当てのうち 1 分間分を消費したときにトリガーされます。15 分後に、リクエストレートが再び 100 RPS の継続的なリクエスト制限を超えると、2 件目の `appi` ログがトリガーされます。

<div id="api-responses">
  ### API レスポンス
</div>

Auth0 API のレスポンスでは、超過したレート制限に応じて [HTTP 429 (Too Many Requests)](http://tools.ietf.org/html/rfc6585#section-4) が返されます。これにより、顧客はレート制限の適用状況をリアルタイムで確認できます。ただし、これは Auth0 API と直接やり取りする、顧客が独自に構築したアプリケーションでのみ有用です。

<div id="sdk-error-handling">
  ### SDK のエラー処理
</div>

SDK を使用している場合は、[Management API SDKライブラリ](/docs/ja-jp/libraries#mgmt)のエラーに関するページを参照してください。

<div id="error-pages">
  ### エラーページ
</div>

エラーページのレスポンスは、エンドユーザーに HTML コンテンツを表示するエンドポイントに対して返されます。テナントが汎用 (Auth0 ホスト) ページを使用するように設定されている場合、レスポンス制限を超えると、想定されるコンテンツの代わりに Auth0 がエラーページを表示します。  テナントが [カスタムエラーページ](/docs/ja-jp/customize/login-pages/custom-error-pages) を使用するように設定されている場合、ユーザーは、関連するエラーが `error_description` クエリ文字列パラメーターに含まれたカスタムエラーページ URL にリダイレクトされます。  詳細については、[影響を受けるエンドポイント](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/authentication-api-endpoint-rate-limits#affected-endpoints) および [JSON エラー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/authentication-api-endpoint-rate-limits#json-error) の説明を参照してください。

<div id="find-out-why-a-tenant-is-being-rate-limited">
  ## テナントにレート制限が適用される理由を確認する
</div>

テナントへのリクエストにレート制限が適用されていて、その理由を確認するためのサポートが必要な場合は、[Support Center](http://support.auth0.com) からリクエストを送信してください。  その際、問題が発生したときの完全な生ログを含めてください。

<div id="predict-when-requests-to-a-tenant-will-be-rate-limited">
  ## テナントへのリクエストがレート制限されるタイミングを予測する
</div>

Auth0 は、レート制限ポリシーが設定されたエンドポイントの HTTP レスポンスヘッダーを使用して、現在のレート制限のステータスに関する最新情報を提供します。このステータスは次のように示されます。

* `x-ratelimit-limit`: 利用可能なリクエストの最大数。
* `x-ratelimit-remaining`: バケットに追加のリクエストが補充されるまでに残っているリクエスト数。
* `x-ratelimit-reset`: 追加のリクエストがバケットに加えられる予定時刻を秒単位で示す [UNIX タイムスタンプ](https://en.wikipedia.org/wiki/Unix_time)。

例えば次のようになります。

ある API には、次のレート制限があります。

* バースト制限: `1000`
* 持続レート制限: `100` `requests per second` (固定ウィンドウ)

この情報から、次のことが導き出せます。

* 持続レート制限は、固定ウィンドウで `100 requests per second` です。
* 固定ウィンドウであるため、リクエストのバケットは毎秒補充されます。

API レスポンスで次の x-headers を受け取ったとします。

* `x-ratelimit-limit: 1000`
* `x-ratelimit-remaining: 50`
* `x-ratelimit-reset: 1675452600`

この時点で、次のことがわかります。

* テナントは、その API で許可されている 1000 件のリクエストのうち 950 件を使い切っており、追加のリクエストが加えられるまで残り 50 件しかありません。
* 新しいリクエストは `1675452600`、つまり 2023 年 2 月 3 日 19:30:00 UTC に追加されます。
* その時点で新たに 1 件のリクエストが追加されます

したがって、上記のレートを上回る頻度でリクエストを行っている場合は、レート制限に達すると考えられます。実際にいつレート制限されるかは、バースト制限と、持続制限をどの程度超過しているかによって決まります。

<div id="examples-of-how-rate-limits-are-enforced">
  ## レート制限の適用例
</div>

<div id="requests-per-second-example">
  ### 1 秒あたりのリクエスト数の例
</div>

Auth0 が `/ratelimitexample` という新しい API を、次のレート制限値で開始すると仮定します。

* バースト制限: 5 リクエスト
* 持続レート制限: 1 秒あたり 10 リクエスト。

重要なポイント:

* API は 5 個のリクエストトークンから始まり、これを超えることはありません。これはバースト制限と同じです。
* 10 個のトークンが入るバケットは、「固定ウィンドウ」に従って毎秒補充されます。新しいトークンがバケットに追加され、毎秒の切り替わり時点で満杯になります。

レート制限のシナリオ例:

<Frame>
  <img src="https://mintcdn.com/docs-dev-feat-init-gt-translations/AcBWN86l7cA24wcQ/docs/images/cdy7uua7fh8z/30m5xST81Db6mROVGCV5Bj/34d9638eb7467f02c2d0ecbe87ff0fd8/Examples_of_how_rate_limits_are_enforced_-_Page_1.png?fit=max&auto=format&n=AcBWN86l7cA24wcQ&q=85&s=295a4b69e470655127e79cbd110923b2" alt="" width="2666" height="1020" data-path="docs/images/cdy7uua7fh8z/30m5xST81Db6mROVGCV5Bj/34d9638eb7467f02c2d0ecbe87ff0fd8/Examples_of_how_rate_limits_are_enforced_-_Page_1.png" />
</Frame>

このシナリオでは:

* T0 - T1sec:  エンドユーザーは最初の 1 秒間に 6 件のリクエストを行います。5 件のリクエスト (バースト制限と同数) には `200` レスポンスが返されます。6 件目のリクエストには、バケット内のリクエストトークンが残っていないため、`429` エラーが返されます。
* T1sec - T2sec:  Auth0 は固定ウィンドウアルゴリズムにより、リクエストトークンのバケットを満杯まで補充します。その結果、7 件目から 11 件目までのリクエストは成功し、12 件目のリクエストでバケットが使い果たされるため、`429` エラーになります。
* T2sec - T3sec:  Auth0 は再度トークンバケットを補充するため、次のリクエスト (13) には `200` レスポンスが返されます。

<div id="requests-per-minute-example">
  ### 1 分あたりのリクエストの例
</div>

Auth0 が `/ratelimitexample2` という新しい API を、次のレート制限値で公開したとします。

* バースト制限: 5 件のリクエスト
* 持続レート制限: 1 分あたり 6 件のリクエスト。

重要なポイント:

* API は 5 つのリクエストトークンを持つ状態で開始され、これはバースト制限と同じです。
* 6 個のトークンを保持するバケットは、「固定ウィンドウ」を使用して 1 分ごとに補充されます。新しいトークンがバケットに追加され、毎分の開始時点で満杯まで補充されます。

レート制限のシナリオ例:

<Frame>
  <img src="https://mintcdn.com/docs-dev-feat-init-gt-translations/2eg7X7TgyYFJUdNP/docs/images/cdy7uua7fh8z/PhtwGBwS9PfEpNQbPeA1o/dc2b05c72ef960a19958dbafa0295e70/Examples_of_how_rate_limits_are_enforced_-_Page_1__1_.png?fit=max&auto=format&n=2eg7X7TgyYFJUdNP&q=85&s=6b9a943e2ecd23f169930680073d1b3f" alt="" width="2666" height="1020" data-path="docs/images/cdy7uua7fh8z/PhtwGBwS9PfEpNQbPeA1o/dc2b05c72ef960a19958dbafa0295e70/Examples_of_how_rate_limits_are_enforced_-_Page_1__1_.png" />
</Frame>

このシナリオでは:

* T0 - T+1min: エンドユーザーは最初の 1 分間に 6 件のリクエストを行います。5 件のリクエスト (バースト制限と同数) には `200` レスポンスが返されます。6 件目のリクエストには、利用可能なリクエストトークンが残っていないため `429` エラーが返されます。
* T+1min - T+2min: Auth0 は固定ウィンドウアルゴリズムによりトークンバケットを補充します。その結果、7 件目から 11 件目までのリクエストは成功しますが、12 件目のリクエストでバケットが使い果たされ、`429` エラーになります。
* T+2min: Auth0 は再びトークンバケットを補充するため、次のリクエスト (13 件目) には `200` レスポンスが返されます。

<div id="other-scenarios">
  ### その他のシナリオ
</div>

場合によっては、Auth0 が 1 つの API に対して 2 つのレート制限を設定することがあります。  これは、バースト制限と、サービスの要件に合わせてより細かく調整された持続レート制限を構成するためです。  実際には、最初のレート制限が実効バースト制限となり、2 つ目のレート制限が実効持続レート制限となります。  このシナリオでは、Auth0 は実際のバースト制限と持続レート制限ではなく、実効バースト制限と実効持続レート制限のみを公開します。

<div id="end-user-login-and-signup-api-usage">
  ## エンドユーザーのログインおよびサインアップ API の使用
</div>

認証フローには、ログイン、サインアップ、パスワード変更など、いくつかあります。通常、もっとも一般的なのはログインで、次いでサインアップです。

エンドユーザーがログインすると、Authentication API のエンドポイントに対して複数の API 呼び出しが行われ、エンドユーザーが認可トークンを受け取る権限を持ち、要求したアプリケーションにアクセスできるかどうかが判定されます。

API 呼び出しの正確な回数は、いくつかの設定によって決まります。

* 認証エクスペリエンス (例: 新しい <Tooltip tip="Universal Login: アプリケーションは、ユーザーの本人確認のために、Auth0 の Authorization Server でホストされる Universal Login にリダイレクトされます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Universal+Login">Universal Login</Tooltip> または クラシックログイン)
* 認証フロー (例: ログイン、サインアップ、またはパスワード変更)
* 認証フローの種類 (例: ユーザー名 / パスワードによるログイン、ソーシャルログインによるログイン、既存の認証トークンがすでに存在する場合のログイン)

以下では、一般的な顧客設定のいくつかと、それらが API の使用状況に与える影響について説明します。

<div id="universal-login">
  ### Universal Login
</div>

[Auth0 Universal Login](/docs/ja-jp/authenticate/login/auth0-universal-login) は、<Tooltip tip="Authorization Server: ユーザーのアクセス範囲の定義に関わる中央集権型サーバーです。たとえば、認可サーバーは、ユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=authorization+server">認可サーバー</Tooltip> の重要な機能であるログインフローを提供します。ユーザーがアプリケーションにアクセスするために本人確認を行う必要がある場合は、Universal Login にリダイレクトして、認証処理を Auth0 に任せることができます。

| 認証フロー  | フローの種類                                | Authentication API エンドポイントへのリクエスト |
| ------ | ------------------------------------- | --------------------------------- |
| ログイン   | ユーザー名/パスワード チャレンジ\*                   | 5                                 |
| ログイン   | サードパーティのIDプロバイダー (ソーシャルログインや社内ログインなど) | 6                                 |
| ログイン   | Auth0 の認証セッションが存在する                   | 1                                 |
| サインアップ | ユーザー名/パスワード経由                         | 6                                 |

<div id="modifiers">
  #### 修飾要因
</div>

特定の認証構成では、基本のリクエスト数に補正が加わります。これらの補正は、追加のセキュリティ対策や認証フローによって異なります。

| Modifier               | Description                              | 追加リクエスト   |
| ---------------------- | ---------------------------------------- | --------- |
| **ID First**           | 認証情報の入力を求める前にユーザーを識別します。                 | +2        |
| **MFA**                | 多要素認証を追加します。                             | 1要素ごとに +2 |
| **OTP**                | 認証用のワンタイムパスワード                           | +2        |
| **Enterprise Login**   | エンタープライズ接続 (例: SAML、OIDC、LDAP) を介した認証。   | +1        |
| **Client Credentials** | マシン間認証に使用されます。Actions を使用する場合でも常に適用されます。 | +1        |

\*組み合わせて使用するものは、すべてリクエスト総数に加算されます。

<div id="classic-login">
  ### クラシックログイン
</div>

[クラシックログイン](/docs/ja-jp/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/classic-experience)は、カスタマイズにJavaScriptを利用する Auth0 ホスト型のログイン体験です。クラシックログインの実装は、認証プロセスをアプリに直接組み込むよりも複雑さが少なく、クロスオリジン認証に伴うリスクの回避にも役立ちます。

| 認証フロー  | フロータイプ                                  | リクエスト |
| ------ | --------------------------------------- | ----- |
| ログイン   | ユーザー名/パスワードのチャレンジ                       | 8     |
| ログイン   | サードパーティの IDプロバイダー (例: ソーシャルログイン、職場ログイン) | 8     |
| ログイン   | Auth0 の認証セッションが存在する場合                   | 2     |
| サインアップ | ユーザー名/パスワード                             | 8     |

<Warning>
  カスタムデータベース接続を設定しているお客様は、上記の各認証フローに Authentication API 呼び出しを 2 回追加する必要があります。詳しくは、[カスタムデータベース接続](/docs/ja-jp/authenticate/database-connections/custom-db)を参照してください。
</Warning>

<div id="modifiers-2">
  #### 修飾要因
</div>

以下の要因により、Classic Login のリクエスト数が増加します。

| 修飾要因                        | 説明                                               | 追加リクエスト |
| --------------------------- | ------------------------------------------------ | ------- |
| **SMS Authentication Only** | 認証方法として SMS のみを使用する場合。                           | +7      |
| **Native Social Login**     | ネイティブソーシャルプロバイダー (例: Google、Facebook) を使用したログイン。 | +1      |
| **Redirects**               | 認証中にリダイレクトが追加されると、リクエスト数が増加します。                  | +1      |