---
sourceDocument: Xanadu API リファレンス
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/api-reference

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu API リファレンス

ft:clusterId :

    - crapiref

bundleId :

    - crapiref

workflow :

    - Creator


---

# 受信 REST API のレート制限

# 受信 REST API のレート制限 {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

過剰な受信 REST API 要求を防ぐために、1 時間あたりに処理される受信 REST API 要求の数を制限するルールを設定します。特定のユーザー、特定のロールを持つユーザー、またはすべてのユーザーの要求を制限するルールを作成できます。  
注:  
要求がインスタンスに達したときに、各ノードはユーザーごとのレート制限数を維持します。30 秒ごとに、カウントがデータベースにコミットされます。その結果、レート制限ルールが最大 30 秒間有効にならない場合があります。

## レート制限の優先度 {#inbound-REST-API-rate-limiting__section_isk_1gr_hdb}

受信 REST API 要求が同じリソースの複数のレート制限ルールに一致する場合、レート制限の優先度は次のように強制されます。

* \[単一ユーザー\] 用に設定されたルールは、\[すべてのユーザー\] 用のルールおよび \[ロールを持つユーザー\] 用のルールより優先されます。
* \[ロールを持つユーザー\] 用に設定されたルールは、\[すべてのユーザー\] 用のルールより優先されます。
{#inbound-REST-API-rate-limiting__ul_oy2_xrk_hdb}  
この例では、同じ REST API リソース `GET /now/v2/table/incident` に 4 つのレート制限ルールがあります。  
これらのレート制限ルールは、次の順序で適用されます。

1. \[ユーザーによるインシデントの制限 (Limit Incidents by User)\] は、1 時間あたり最大 10 件の要求を送信できる ITIL ユーザーに適用されます。
2. \[import admin ロールによるインシデントの制限 (Limit Incidents by import admin Role)\] は、import_admin ロールを持つ各ユーザーに適用されます。import_admin ロールを持つ各ユーザーは、1 時間あたり最大 3 件の要求を送信できます。
3. \[itil ロールによるインシデントの制限 (Limit Incidents by itil Role)\] は、itil ロールを持つ各ユーザーに適用されます。itil ロールを持つ各ユーザーは、1 時間あたり最大 5 件の要求を送信できます。
4. \[インシデントの制限 (Limit Incidents)\] はすべてのユーザーに適用されます。各ユーザーは、1 時間あたり最大 2 件の要求を送信できます。
{#inbound-REST-API-rate-limiting__ul_k4q_qjr_hdb}

ITIL ユーザーが要求 `GET /now/v2/table/incident` を行うと、その要求は、\[インシデントの制限 (Limit Incidents)\]、\[itil ロールによるインシデントの制限 (Limit Incidents by itil Role)\]、\[ユーザーによるインシデントの制限 (Limit Incidents by User)\] の 3 つのルールの基準に一致します。\[ユーザーによるインシデントの制限 (Limit Incidents by User)\] ルールは他のルールよりも優先されるため、このルールのみが適用されます。結果として、ITIL ユーザーは 1 時間あたり最大 10 件の要求を送信できます。

ユーザーが REST API リソースの複数のレート制限ルールの基準に一致する 2 つ以上のロールを持っている場合、要求を許可する数が最も少ないルールが、リソースに対するユーザーの要求に適用されます。上の図の例のルールで、ユーザー Abel Tuter が import_admin ロールと itil ロールの両方を持っているとします。Abel Tuter が送信する要求は、\[admin ロールによるインシデントの制限 (Limit Incidents by admin Role)\] ルールと\[itil ロールによるインシデントの制限 (Limit Incidents by itil Role)\] ルールの両方の基準を満たします。最も少ない数の要求を許可するため、\[admin ロールによるインシデントの制限 (Limit Incidents by admin Role)\] ルールのみが適用されます。結果として、Abel Tuter は 1 時間あたり最大 3 件の要求を送信できます。

## REST API 応答ヘッダー {#inbound-REST-API-rate-limiting__section_l5l_5my_hdb}

[REST API エクスプローラーの使用](https://servicenow-prod.fluidtopics.net/TfOv2KiQwHQnMYG4kg9dtg "このチュートリアルでは、REST API エクスプローラーを使用して ServiceNow REST API をテストします。") または HTTP クライアント (Postman など) を使用して、受信 REST API 要求を生成できます。要求がレート制限ルールに一致する場合、いくつかの HTTP 応答ヘッダーがレート制限に関する情報を提供します。

* X-RateLimit-Limit には、1 時間あたりに許可された要求の数が表示されます。
* X-RateLimit-Reset には、次にスケジュールされているリセットまでの Unix 時間が表示されます。
* X-RateLimit-Rule には、適用されているレート制限ルールの sys_id が表示されます。

{#inbound-REST-API-rate-limiting__ul_xpr_w4y_hdb}  
レート制限を超えたために要求が拒否された場合、システムはレート制限に関する応答ヘッダーに加えて、Retry After 応答ヘッダーを返します。Retry After 応答ヘッダーには、何秒経過した後にレート制限の超過を回避するために要求を再試行できるかという秒数が表示されます。次のエラー応答が返されます。

    {
        "error": {
            "message": "Rate limit exceeded",
            "detail": "Rate limit of 10 requests per hour for Table API exceeded"
        },
        "status": "failure"
    }

拒否された要求のステータスは、\[429 要求が多すぎます (429 Too Many Requests)\]です。

* **[受信 REST API レート制限を作成する](https://servicenow-prod.fluidtopics.net/pWVdL4QTE291VbLY6i01JA)**   
  レート制限ルールを作成して、1 時間あたりに処理される受信 REST API 要求の数を制限します。
* **[インバウンド REST API レート制限をリセットする](https://servicenow-prod.fluidtopics.net/Zhz2qMskwTklIgA1n008Ww)**   
  レート制限ルールをリセットしてレート制限数をゼロ (0) にリセットし、現在の時間の違反を削除します。
* **[受信 REST API のレート制限数と違反を監視する](https://servicenow-prod.fluidtopics.net/Iu8tSprc8o7ccZr_UAi16A)**   
  レート制限ルールが適切に設定されているかどうかを判断するには、ルールによって制限される受信 REST API 要求の数と違反を監視します。
* **[受信 REST API レート制限の違反を調べる](https://servicenow-prod.fluidtopics.net/VGT8oijZnFtQIOrolhFHqg)**   
  レート制限違反を調べて、超過のあるレート制限ルールと、それらのレート制限を超えているユーザーを特定します。