---
sourceDocument: オーストラリア API リファレンス
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/api-reference

 Release :

    - australia

ft:locale :

    - ja-JP

ft:publication_title :

    - オーストラリア API リファレンス

ft:clusterId :

    - crapiref

bundleId :

    - crapiref

workflow :

    - Creator


---

# 受信 REST API レート制限

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

* リリースバージョン: Australia
* 
* 更新日 2026年03月12日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：3分

過剰な受信 REST API 要求を防ぐために、1 時間あたりに処理される受信 REST API 要求の数を制限するルールを設定します。特定のユーザー、特定のロールを持つユーザー、またはすべてのユーザーに対する要求を制限するルールを作成できます。

レート制限ルールは、レート制限ルール \[sys_rate_limit_rules\] テーブルで作成されます。  
注:  
要求がインスタンスに到達すると、各ノードでユーザーごとのレート制限カウントが維持されます。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. ユーザーによるインシデントの制限は 、1 時間あたり最大 200 件の要求を送信できる ITIL ユーザーに適用されます。
2. インポートアドミニ ストレーターは、import_admin ロールを持つすべてのユーザーに適用されます。import_adminロールを持つ各ユーザーは、1 時間あたり最大 500 件の要求を送信できます。
3. itil によるインシデントの制限 は、itil ロールを持つすべてのユーザーに適用されます。itil ロールを持つ各ユーザーは、1 時間あたり最大 100 件の要求を送信できます。
4. インシデントの制限は すべてのユーザーに適用されます。各ユーザーは、1 時間あたり最大 100 件の要求を送信できます。
{#inbound-REST-API-rate-limiting__ul_k4q_qjr_hdb}

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

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

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

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

* X-RateLimit-Limit は 、1 時間あたりに許可される要求の数を表示します。
* X-RateLimit-Reset は、レート制限ウィンドウの次回スケジュールされたリセットの UNIX タイムスタンプを表示します。
* X-RateLimit-Rule は、適用されているレート制限ルール \[sys_rate_limit_rules\] のsys_idを表示します。
{#inbound-REST-API-rate-limiting__ul_xpr_w4y_hdb}  
要求がレート制限を超えて拒否された場合、システムはレート制限に関する応答ヘッダーに加えて、 Retry-After 応答ヘッダーを返します。Retry-After 応答ヘッダーには、レート制限を超えないように要求を再試行できるまでの秒数が表示されます。次のエラー応答が返されます。

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

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