> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.generaltranslation.app/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>

、「[ログ](/docs/ja-JP/ja-jp/deploy-monitor/logs)」をお読みください。

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

`api_limit`イベントは、特定のレート制限バケットでレート制限を超過すると即座にトリガーされます。1分経っても同じレート制限バケットでレート制限が超過したままの場合には、2つ目のログが作成されます。別のレート制限バケットでレート制限が超過した場合には、新たに`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（パブリックパフォーマンスバーストのみ）
</div>

`appi`ログは、パブリックパフォーマンスバーストアドオンのある顧客テナントがサステイン時のAuthentication API要求のレート制限である100 RPSを超過し、48時間のバースト割り当ての15分ブロックを消費するとトリガーされます。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ライブラリー](https://auth0.com/docs/libraries#mgmt)のエラーページを参照してください。

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

エラーページ応答は、エンドユーザーにHTMLコンテンツを表示するエンドポイントに対して送信されます。テナントに（Auth0がホストする）汎用ページの使用が構成されている場合には、応答制限が超過すると、Auth0は予期されるページではなく、エラーページを表示します。  テナントに[カスタムのエラーページ](/docs/ja-JP/ja-jp/customize/login-pages/custom-error-pages)の使用が構成されている場合には、クエリ文字列パラメーターの`error_description`に関連エラーを含めて、エラーページのURLにユーザーがリダイレクトされます。  詳細については、[影響を受けるエンドポイント](/docs/ja-JP/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/authentication-api-endpoint-rate-limits#affected-endpoints)と[JSONエラー](/docs/ja-JP/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>

テナント要求がレート制限を受けていると思われ、その理由を知るのに手助けが必要な場合には、[サポートセンター](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``RPS`（固定ウィンドウ）

この情報から以下が分かります。

* 持続的レート制限は固定ウィンドウで`100RPS`です。
* 固定ウィンドウのため、要求のバケットは毎秒補充されます。

API応答では以下のXヘッダーを受け取ります。

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

以下のことが分かります。

* テナントがそのAPIに対する要求数1000中の950をすでに使用し、要求数が補充されるまでに残っている要求数は50のみである
* 新しい要求数が`1675452600`秒後（2023年2月3日7:30:00 PM UTC）に補充される
* そのときに新たに1つの要求が追加される

このため、上記よりも速いレートで要求を行っていると、レート制限を受けることになります。  どのくらい早い時期にレート制限を受けるのかは、持続制限をどのくらい超過しているのかとバースト制限に依存します。

<div id="examples-of-how-rate-limits-are-enforced">
  ## レート制限を受ける仕組みの例
</div>

<div id="requests-per-second-example">
  ### RPSの例
</div>

Auth0が`/ratelimitexample`という新しいAPIの提供を開始し、以下のレート制限があるとします。

* バースト制限：5件の要求
* 持続的レート制限：10RPS。

要点：

* APIは5つの要求トークンから始まり、それが上限で、これはバースト制限と同じです。
* 固定ウィンドウを使用して、10個のトークンを保持したバケットが1秒ごとに補充されます。 新しいトークンがバケットに追加され、各秒の「頭」でバケットを補充します。

レート制限のシナリオ例

<Frame>
  <img src="https://mintcdn.com/generaltranslationinc/fJ7FJkQ9-WdlT49P/docs/images/ja-jp/cdy7uua7fh8z/30m5xST81Db6mROVGCV5Bj/061a580560dc5878175bca229a316f9d/Examples_of_how_rate_limits_are_enforced_-_Page_1.png?fit=max&auto=format&n=fJ7FJkQ9-WdlT49P&q=85&s=b30f12c4ba023ff015e53369979e425f" alt="" width="2666" height="1020" data-path="docs/images/ja-jp/cdy7uua7fh8z/30m5xST81Db6mROVGCV5Bj/061a580560dc5878175bca229a316f9d/Examples_of_how_rate_limits_are_enforced_-_Page_1.png" />
</Frame>

このシナリオでは以下が起きます。

* T0 - T1秒：  エンドユーザーが最初の1秒で6つの要求を行います。  バースト制限と同等の5つの要求は`200`応答を受信します。  6つ目の要求は、バケットに要求トークンが残っていないため`429`エラーを受信します。
* T1秒 - T2秒：  固定ウィンドウのアルゴリズムにより要求トークンのバケットが満たされます。その結果、7つ目から11つ目の要求は成功し、12つ目の要求でバケットが空になり、`429`エラーとなります。
* T2秒 - T3秒：  再びトークンバケットが補充されて、次の要求（13）で`200`応答を受信します。

<div id="requests-per-minute-example">
  ### RPMの例
</div>

Auth0が`/ratelimitexample2`という新しいAPIの提供を開始し、以下のレート制限があるとします。

* バースト制限：  5件の要求
* 持続的レート制限：  6RPM。

要点：

* APIは5つの要求トークンから始まり、バースト制限と同じです。
* 固定ウィンドウを使用して、6個のトークンを保持したバケットが1分ごとに補充されます。 新しいトークンがバケットに追加され、毎分の「頭」でバケットを補充します。

レート制限のシナリオ例

<Frame>
  <img src="https://mintcdn.com/generaltranslationinc/pgNtkB0vi40DIRw0/docs/images/ja-jp/cdy7uua7fh8z/PhtwGBwS9PfEpNQbPeA1o/964dbb486e1c46ae17fdf6767bdde9ca/Examples_of_how_rate_limits_are_enforced_-_Page_1__1_.png?fit=max&auto=format&n=pgNtkB0vi40DIRw0&q=85&s=905b096a1a94ff784b7d53a433649091" alt="" width="2666" height="1020" data-path="docs/images/ja-jp/cdy7uua7fh8z/PhtwGBwS9PfEpNQbPeA1o/964dbb486e1c46ae17fdf6767bdde9ca/Examples_of_how_rate_limits_are_enforced_-_Page_1__1_.png" />
</Frame>

このシナリオでは以下が起きます。

* T0 - T+1分：  エンドユーザーが最初の1分で6つの要求を行います。 バースト制限と同等の5つの要求は`200`応答を受信します。  6つ目の要求は、要求トークンが残っていないため`429`エラーを受信します。
* T+1分 - T+2分：  固定ウィンドウのアルゴリズムにより要求トークンのバケットが満たされます。その結果、7つ目から11つ目の要求は成功し、12つ目の要求でバケットが空になり`429`エラーとなります。
* T+2分：再びトークンバケットが補充されて、次の要求（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呼び出しを行う正確な数は、以下のいくつかの構成に応じて異なります。

* 認証エクスペリエンス（新しいユニバーサルログイン、クラシックログインなど）
* 認証フロー（ログイン、サインアップ、パスワード変更など）
* 認証フロータイプ（ユーザー名/パスワードを介したログイン、ソーシャルログインを介したログイン、既存の認証トークンがすでに存在するときのログインなど）

以下に、よくある顧客の構成とAPIの使用に対する影響についていくつか説明します。

<div id="universal-login">
  ### ユニバーサルログイン
</div>

[Auth0のユニバーサルログイン](/docs/ja-JP/ja-jp/authenticate/login/auth0-universal-login)には、認可サーバーの重要な機能であるログインフローが備わっています。ユーザーがアプリケーションにアクセスするために本人確認を行う必要がある場合は、ユニバーサルログインにリダイレクトし、Auth0に認証プロセスを処理してもらうことができます。

<table class="table">
  <thead>
    <tr>
      <th>認証フロー</th>
      <th>フローの種類</th>
      <th>Authentication APIエンドポイントへの要求数</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>ログイン</td>
      <td>ユーザー名/パスワードのチャレンジ\*</td>
      <td>5</td>
    </tr>

    <tr>
      <td>ログイン</td>
      <td>サードパーティIDプロバイダー（ソーシャルや職場のログインなど）</td>
      <td>6</td>
    </tr>

    <tr>
      <td>ログイン</td>
      <td>Auth0の認証セッション存在</td>
      <td>1</td>
    </tr>

    <tr>
      <td>サインアップ</td>
      <td>ユーザー名/パスワードの使用</td>
      <td>6</td>
    </tr>
  </tbody>
</table>

<div id="modifiers">
  #### 修飾子
</div>

特定の認証構成では基準の要求数が変わります。これらの調整は追加のセキュリティ対策や認証フローに依存します。

<table class="table">
  <thead>
    <tr>
      <th><strong>修飾子</strong></th>
      <th><strong>説明</strong></th>
      <th><strong>追加の要求</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><strong>ID First</strong></td>
      <td>資格情報を要求する前にユーザーを識別します。</td>
      <td>+2</td>
    </tr>

    <tr>
      <td><strong>MFA</strong></td>
      <td>多要素認証を追加します。</td>
      <td>1要素あたり+2</td>
    </tr>

    <tr>
      <td><strong>OTP</strong></td>
      <td>認証のワンタイムパスワードです。</td>
      <td>+2</td>
    </tr>

    <tr>
      <td><strong>エンタープライズログイン</strong></td>
      <td>エンタープライズ接続（例：SAML、OIDC、LDAP）を通して認証します。</td>
      <td>+1</td>
    </tr>

    <tr>
      <td><strong>クライアント資格情報</strong></td>
      <td>マシンツーマシン認証に使用されます。アクションが使用される場合でも例外なく適用されます。</td>
      <td>+1</td>
    </tr>
  </tbody>
</table>

\*組み合わせて使用されるものはすべて全体の要求数に追加されます。

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

[クラシックログイン](/docs/ja-JP/ja-jp/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/classic-experience)はAuth0がホストするログインエクスペリエンスで、カスタマイズにJavaScriptを使用します。クラシックログインの実装はアプリで直接認証を埋め込むより複雑性が低く、クロスオリジン認証の危険を回避するのに役立ちます。

<table class="table">
  <thead>
    <tr>
      <th>認証フロー</th>
      <th>フローの種類</th>
      <th>要求数</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>ログイン</td>
      <td>ユーザー名/パスワードのチャレンジ</td>
      <td>8</td>
    </tr>

    <tr>
      <td>ログイン</td>
      <td>サードパーティIDプロバイダー（ソーシャルや職場のログインなど）</td>
      <td>8</td>
    </tr>

    <tr>
      <td>ログイン</td>
      <td>Auth0の認証セッション存在</td>
      <td>2</td>
    </tr>

    <tr>
      <td>サインアップ</td>
      <td>ユーザー名/パスワード</td>
      <td>8</td>
    </tr>
  </tbody>
</table>

<Warning>
  カスタムデータベースを構成している場合は、必ず上記それぞれの認証フローに追加のAuthentication API呼び出しを2つ追加しておきます。詳細については、「[カスタムデータベース接続](/docs/ja-JP/ja-jp/authenticate/database-connections/custom-db)」を参照してください。
</Warning>

<div id="modifiers">
  #### 修飾子
</div>

以下の要素ではクラシックログインの要求数が増加します。

<table class="table">
  <thead>
    <tr>
      <th><strong>修飾子</strong></th>
      <th><strong>説明</strong></th>
      <th><strong>追加の要求</strong></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><strong>SMS認証のみ</strong></td>
      <td>SMSを最優先の認証方法として使用する場合です。</td>
      <td>+7</td>
    </tr>

    <tr>
      <td><strong>ネイティブソーシャルログイン</strong></td>
      <td>ネイティブのソーシャルプロバイダー（Google、Facebookなど）を使用したログインです。</td>
      <td>+1</td>
    </tr>

    <tr>
      <td><strong>リダイレクト</strong></td>
      <td>認証中の追加のリダイレクトは要求数に加算されます。</td>
      <td>+1</td>
    </tr>
  </tbody>
</table>