> ## 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.

> Auth0 のレート制限ポリシーについて説明します。

# レート制限ポリシー

Auth0 では、最適なパフォーマンスを維持し、<Tooltip tip="Bad Actors: 悪意を持って危害を加える意図で、ビジネスや環境に脅威をもたらす存在（個人または集団）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=bad+actors">悪意のある主体</Tooltip>、技術的なエラー、または正当であっても過剰なトラフィックから保護するために、サービスの利用を制限しています。最適なユーザー体験を実現できるよう、Auth0 がどのように制限を適用しているかを確認し、アプリケーションを設定することをお勧めします。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  アカウントに適用されるレート制限を確認するには、すべてのレート制限ポリシーを一覧できる [Rate Limit Configurations](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations) を参照してください。
</Callout>

<div id="introduction-to-rate-limits">
  ## レート制限の概要
</div>

Auth0 は、過剰なリクエストからサービスを保護し、サービスの中断や性能低下からお客様を守るために、各種の制限を設けています。

Auth0 では、以下のようなさまざまな制限を監視しており、多くの場合は実際に適用しています。

* 環境へのリクエスト (Private Cloud のみ)
* API または API エンドポイント経由のテナントへのリクエスト
* その他の制限

<div id="environment-request-limits-private-cloud-only">
  ### 環境のリクエスト制限 (Private Cloud のみ)
</div>

Private Cloud では、環境のリクエスト制限は Private Cloud Performance Tier に基づきます。詳しくは、[Private Cloud for AWS](/docs/ja-jp/deploy-monitor/deploy-private-cloud/private-cloud-on-aws) または [Private Cloud for Azure](/docs/ja-jp/deploy-monitor/deploy-private-cloud/private-cloud-on-azure) をご覧ください。

現在、Private Cloud の環境レート制限は、Auth0 製品が SLA を満たせる最大負荷を示しています。ただし現時点で Auth0 が制限の適用と通知を行うのは、環境内の特定のテナントでレート制限を超過した場合のみです。ほとんどの Private Cloud のユースケースでは、お客様は本番テナントを 1 つだけ維持しているため、これは問題になりません。しかし、本番テナントを複数プロビジョニングするユースケースでは、環境内のすべてのテナントにまたがる想定負荷を考慮し、必要に応じて追加の監視を実装する必要があります。

| Feature                                   | Authentication API                                                                                         | All Other APIs (including Management API)                                                                                                             |
| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Tenant Rate Limits                        | すべてのテナントは、その API に対する環境全体の共有グローバル制限を使用しますが、環境のレート制限は厳格な上限です。テナント全体の合計負荷によって環境の制限を超えると、超過分のリクエストはレート制限されます。 | テナントのレート制限はそれぞれ独立して適用され、環境のレート制限は、パフォーマンス低下や SLA への影響の可能性を示すしきい値として機能しますが、テナント レベルで直接レート制限を引き起こすことは**ありません**。                                         |
| Environment Rate Limit Exceeded (Example) | 環境の制限が 1500 rps の場合、Tenant 1 が 1400 rps、Tenant 2 が 900 rps (合計 2300 rps) になると、800 リクエストがレート制限されます。         | 環境の制限が 1500 rps の場合、Tenant 1 が 1400 rps、Tenant 2 が 900 rps (合計 2300 rps) であっても、個々のテナントがレート制限されることは**ありません**が、環境全体ではパフォーマンスの低下や SLA 上の問題が発生する可能性があります。 |

<Warning>
  環境のレート制限を超過すると、Service Level Agreement (SLA) は無効になります。
</Warning>

Private Cloud の負荷テストに関する考慮事項については、[Private Cloud on AWS](/docs/ja-jp/deploy-monitor/deploy-private-cloud/private-cloud-on-aws) および [Private Cloud on Azure](/docs/ja-jp/deploy-monitor/deploy-private-cloud/private-cloud-on-azure) を参照してください。

<div id="tenant-request-limits">
  ### テナントのリクエスト制限
</div>

Auth0 では、テナントに対して実行できるリクエスト数に制限があります。これらの制限は API ごとに設定されており、さらに各 API の特定のエンドポイントごとにも設定されています。

<div id="api-rate-limits">
  #### APIのレート制限
</div>

Auth0 では、APIエンドポイントに関係なく、特定のAPIに対するリクエスト数が制限されます。APIの制限は、次の要因によって異なる場合があります。

* API

  * 認証
  * Management
* テナントの種類 (Production、Development、Staging)
* サブスクリプションレベル (Free、Essential、Professional、Enterprise Public、Private)

たとえば、無料の非本番テナントでは、有料サブスクリプションの本番テナントとは異なる制限が適用される場合があります。具体的なレート制限の設定については、[Rate Limit Configurations](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations)を参照してください。

<div id="user-requests">
  ### ユーザーリクエスト
</div>

1 回のエンドユーザーリクエスト (例: Login や Signup) によって、通常は Authentication API エンドポイントに対して複数の request が発生します。エンドユーザーリクエストと Authentication API の実際の比率は、主に次のような要因によって異なります。

* 認証対象のエンティティ (例: マシン、またはエンドユーザー向けのモバイル / デスクトップ アプリケーション)
* 認証エクスペリエンス (例: 新しい <Tooltip tip="Universal Login: アプリケーションは、ユーザーの本人確認のために、Auth0 の Authorization Server でホストされている Universal Login にリダイレクトされます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Universal+Login">Universal Login</Tooltip> または Classic Login)
* 認証フロー (例: Login、Signup、またはパスワード変更)
* 認証フローの種類 (例: ユーザー名 / パスワードによる Login、ソーシャルログインによる Login、既存の Authentication Token がすでにある状態での Login)

Extensibility を利用している場合は、その設定内容によって、Authentication API だけでなく、<Tooltip tip="Management API: 顧客が管理タスクを実行できるようにするプロダクトです。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Management+API">Management API</Tooltip> への request がさらに増える可能性もあります。
Auth0 の設定が API 使用量にどのような影響を与えるかを見積もる方法については、[レート制限のユースケース](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-use-cases) を参照してください。

<div id="endpoint-rate-limits">
  #### エンドポイントのレート制限
</div>

Auth0 では、API エンドポイントに対するリクエスト数が制限されており、場合によってはエンドポイント操作の回数も制限されます。API エンドポイントの制限は、次の要素によっても異なります。

* API
* テナントの種類
* サブスクリプションレベル

たとえば、無料の非本番テナントには、有料サブスクリプションの本番テナントとは異なる制限が適用されます。

<div id="tenant-request-limits-order">
  ### テナントのリクエスト制限の適用順序
</div>

テナントへのリクエストが行われると、Auth0 はまず API 全体のグローバル制限に照らしてリクエストを評価し、次に特定の API エンドポイントのレート制限に照らして評価します。

<div id="miscellaneous-limits">
  ### その他の制限
</div>

<div id="database-login-limits">
  #### データベースログインの制限
</div>

データベース接続では、Auth0 はユーザーアカウントと IP アドレスに応じて、特定の種類の繰り返しログイン試行を制限します。システム全体の稼働状況を保つため、Auth0 では負荷を軽減するために、ユーザー名とパスワードを使ったログインに対してレート制限を設けています。Auth0 は高度にカスタマイズできるため、サービスの品質低下につながるリスクがあります。原因としては、次のようなものがあります。

* 高負荷のストレステスト
* ベンチマークテスト
* ユーザーが何度もログインすることになる非効率なコード

リクエストには、Auth0 API ごとの各ポリシーに記載されている制限が適用されます。

さらに、同一ユーザーのログインに対するレート制限もあります。1 つの IP アドレスから 1 分間に同じユーザーアカウントへ 20 回ログインが試行されると、レート制限が適用されます。その後は、そのユーザーに対して 1 分あたり 10 回まで試行できます。成功したログイン試行と失敗したログイン試行は、どのような組み合わせでもこの制限の対象としてカウントされます。

<Card title="ユーザーを保護する制限">
  Auth0 の [ブルートフォース対策](/docs/ja-jp/secure/attack-protection/brute-force-protection) と [不審な IP に対するスロットリング](/docs/ja-jp/secure/attack-protection/suspicious-ip-throttling) でもログインやサインアップが制限されることがありますが、これらはレート制限とは別のものです。Auth0 が悪意のある可能性がある異常をどのように検出し、対処するかについて詳しくは、[攻撃対策](/docs/ja-jp/secure/attack-protection) をご覧ください。
</Card>

<div id="sms-message-limits-for-multi-factor-authentication-end-users-only">
  #### 多要素認証のSMSメッセージ制限 (エンドユーザーのみ)
</div>

1時間以内にお使いの端末へ11件以上のSMSメッセージを送信しようとすると、レート制限の超過に関するエラーメッセージが表示されます。

メッセージ送信数の上限を超えた場合は、最初のメッセージ送信リクエストから少なくとも1時間待ってから、次のリクエストを行う必要があります。その後は、さらに1時間経過するごとに1回ずつ追加で試行できます。

<div id="native-social-login-limits">
  #### ネイティブソーシャルログインの制限
</div>

ネイティブソーシャルログインのログインフローのリクエストに適用される制限は、以下の初期条件に基づいてリクエスト本文から識別されます。

| リクエストの種類             | 本文                                                   |
| -------------------- | ---------------------------------------------------- |
| `grant_type`         | `urn:ietf:params:oauth:grant-type:token-exchange`    |
| `subject_token_type` | `http://auth0.com/oauth/token-type/apple-authz-code` |

<div id="public-performance-burst">
  #### Public Performance Burst
</div>

Public Performance Burst オファリングは、既存の Public Cloud デプロイメントを強化する、エンタープライズサブスクリプション向けの add-on です。このオファリングでは、Authentication API のリクエスト上限を、既定のエンタープライズ向けリクエスト上限である 100 RPS の倍率まで、毎月最大 48 時間、動的に引き上げることができます。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  この add-on で拡張されるのは Authentication API のリクエスト上限のみであり、Management API や、Authentication API の範囲外でレート制限が適用されるその他のエンドポイントには適用されません。
</Callout>

現在、Public Performance Burst には 3 種類の倍率 (2x、3x、4x) があり、Authentication API に対してそれぞれ 200、300、400 RPS を毎月最大 48 時間まで利用できます。この 48 時間は 5 分単位で計測され、毎月の許容量から差し引かれるため、毎月 576 回の 5 分枠にわたって、その倍率レベルで API を利用できます。

Authentication API へのリクエスト量が既定の 100 RPS を超えると、毎月の許容量から 5 分枠が差し引かれ、その倍率に応じたレートでトラフィックが許可されます。その時点から連続する 5 分間は、追加の差し引きなしで、その倍率の範囲内にトラフィックを維持できます。

差し引き区間のイベントは、[tenant logs](/docs/ja-jp/deploy-monitor/logs/log-event-type-codes) で監視できます。差し引きが発生するたびに、すでに消費した許容量と残りの許容量に関する情報を含む、対応する `appi` テナントログイベント種別が生成されます。

詳細については、[Rate Limits - Enterprise](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations/enterprise-public) の Authentication API セクションを参照してください。

<div id="private-performance-burst">
  #### Private Performance Burst
</div>

Private Performance Burst オファリング (現在 AWS の 30x および 60x ティアで利用可能) には、月あたり最大 80 時間まで、30x (3,000 RPS) または 60x (6,000 RPS) のバースト (ピーク時) 性能容量が含まれます。バースト性能容量の半分にあたるベース性能容量は、その月の残りの期間利用できます。

言い換えると、30x Private Performance Burst には次が含まれます。

* ベース容量: 月を通して 1,500 RPS
* バースト/ピーク容量: 月あたり最大 80 時間まで 3,000 RPS

認証トランザクションがベースの API リクエスト制限を超えてバーストした場合、月間許容量から 1 時間分が差し引かれます。その時点から連続する 1 時間は、トラフィックを高いレートのまま維持できます。しきい値を再び超えた場合も、同じ方法で追加の差し引きが行われます。

80 時間の許容量を使い切ると、新しい月間許容量が適用されるまで、認証トラフィックにはベース容量までのレート制限が適用されます。

<div id="extensibility-concurrency-limits">
  #### 拡張機能の同時実行数の上限
</div>

システムの可用性とリソースの公平な利用を確保するため、Auth0 では、Actions、Hooks、Rules、カスタムデータベース接続、Extensions、カスタム OAuth2 接続を含むすべての拡張機能において、同時に処理中のリクエスト数を制限しています。同時リクエスト数の上限を超えたテナントでは、処理中のリクエストが完了するまで、新しいリクエストでエラーが発生することがあります。同時実行数の上限は以下のとおりです。

| Subscription                                                            | Concurrency limit (per Tenant) |
| ----------------------------------------------------------------------- | ------------------------------ |
| Public Cloud                                                            | 250                            |
| Tier Dev Private Cloud                                                  | 100                            |
| Private Cloud Basic 100 RPS (1x)                                        | 200                            |
| Private Cloud Performance 500 RPS (5x)                                  | 400                            |
| Private Cloud Performance 1500 RPS (15x)                                | 1200                           |
| Private Cloud Performance 3000 RPS (30x) and 3000 RPS Burst (30x Burst) | 1200                           |
| Private Cloud Performance 6000 RPS (60x) and 6000 RPS Burst (60x Burst) | 1200                           |

同時実行数は、想定される RPS に各リクエストのレイテンシーを掛けることで計算できます。たとえば、2 つの Post-Login Action が関連付けられており、それぞれの実行に 250ms かかり、ログインの合計 RPS が 400 のテナントでは、想定される同時実行数は (2 \* (400 requests / 1 second) \* (.25 seconds / 1 request)) = 200 です。

これらの同時実行数の上限による影響をテナントが受けないようにするには、外部 API の呼び出しなど、長時間実行される可能性がある拡張機能のロジックに、適切なタイムアウトを設定してください。

<div id="rate-limit-algorithm">
  ## レート制限アルゴリズム
</div>

Auth0 では、API に対してレート制限とバースト制限を設定しています。レート制限がシステムで継続的に許容される最大トラフィック量であるのに対し、バースト制限は一定時間内にシステムが許容する短期的な最大トラフィック量です。Auth0 のレート制限とバースト制限は連携して機能し、変動するトラフィック量に対してより適切な制限を実現します。

Auth0 のレート制限では、次の設定を含むトークンバケットアルゴリズムを使用します。

* **制限キー:**

  * 通常、レート制限キーは主に次の 2 つの要素に基づきます。

    * API とエンドポイント
    * テナント種別
  * 場合によっては、追加の要素として次のものが含まれます。

    * 送信元 IP
    * 対象ユーザー ID
* **制限値:**

  * **バケットサイズ:** API またはエンドポイントが通常受け取るリクエスト、または特定のユーザーや IP アドレスから受け取るリクエストの最大数。この上限に達するまでは、新しいリクエストが追加されます。
  * **補充レート:** バケットに新しいリクエストが追加される速度。

Auth0 はこれら 2 つの数値から、バースト制限と持続レート制限を計算します。

* **バースト制限:**  バケットサイズに等しい。
* **持続レート制限:** 1 分あたりまたは 1 秒あたりのリクエスト数で表した補充レート。

持続レート制限が 1 秒あたりのリクエスト数で計算される場合、新しいリクエストはミリ秒単位で追加されます。持続レート制限が 1 分あたりのリクエスト数で計算される場合、新しいリクエストは秒単位で追加されます。

<div id="learn-more">
  ## さらに詳しく
</div>

* [エンティティ制限ポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/entity-limit-policy)
* [レート制限のユースケース](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-use-cases)