ServiceNowのREST APIは何回まで呼べる？ 標準のレート制限をsys_rate_limit_rulesで確認する
連携していた外部システムからのAPI呼び出しが、ある日突然エラーを返すようになった。原因を探ると、どうも「呼びすぎ」で止められているらしい。そんな相談は珍しくありません。ServiceNowには標準でREST APIの呼び出し回数を制限する仕組みがあり、sys_rate_limit_rulesというテーブルにルールとして登録されています。Zurich PDIのOOTBには、この記事を書いている時点で31件のルールが最初から入っていました。標準で何が制限されているのか、しきい値と時間枠はどこで決まるのか、引っかかったらどこに記録が残るのかを、実機で確認します。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：標準の制限は31件、CMDBと添付ファイル系で9割
先に全体像です。
標準のレート制限ルールはsys_rate_limit_rulesに31件登録されており、すべてactiveでした。
カテゴリで見ると、CMDB系（CI Lifecycle Manager・CMDB Push）が14件、ドキュメント・添付ファイル系（Documents API・CSM Attachment API）が15件です。この2グループで31件中29件、9割以上を占めます。
しきい値は1時間あたりの回数で決まり、31件中23件が「500件/時」という同じ値を使っています。最小はCMDB Pushの30件/時、最大はOAuthトークン検証の36,000件/時でした。
超過の記録はsys_rate_limit_violationsに残る仕組みですが、このPDIでは0件です。意図的な負荷テストは行っていません。
まずは実機の一覧画面を見てください。
sys_rate_limit_rulesの一覧画面で31件を確認する
列にはName（ルール名）が並びます。続けてREST API resource（対象のメソッドとパス）、Request limit per hour（しきい値）、Apply to（適用対象）、Role（対象ロール）が横に並びます。1レコードが1行で表示される、ごく普通のリスト画面です。この画面だけでも、CMDBのCI Lifecycle Manager関連が多いことは見て取れます。ただし全31件をカテゴリ別に整理すると、傾向はもっとはっきりします。一覧を上から順に眺めるだけでは、Documents APIやCSM Attachment APIのように名前の付け方が揃っていないカテゴリの存在に気づきにくいためです。名前の並びだけでなく、しきい値そのものを軸に見直すと、また違う発見があります。
標準で何が制限されているのか（カテゴリ別に見る）
sys_rate_limit_rulesのapi（REST API）フィールドでグルーピングすると、31件は6つのカテゴリに分かれました。
内訳の上位2グループが、全体の9割以上を占めています。
CMDB系（14件） … CI Lifecycle Manager（CMDBのポリシー作成・更新・削除・一覧取得など13件）とCMDB Data Ingestion API（CMDB Push、1件）です。対象はいずれも特定のロール（data_manager_userまたはcmdb_import_api_admin）を持つユーザーに限定されています。CI Lifecycle Manager配下の13件は、Create Policy limit・Update policy limit・Delete Policy limitのようなポリシーの作成・更新・削除系と、Policy Count limit・Policy Types limit・Get Policy limitのような参照系に分かれます。作成・更新・削除・参照のいずれもしきい値は同じ500件/時で統一されており、操作の種類による差は付けられていませんでした。
ドキュメント・添付ファイル系（15件） … Documents API（9件）とCSM Attachment API（6件、添付ファイルのアップロード・ダウンロード・削除）です。Documents API側はRate limit document creationのような作成系や、Rate Limit Permalinksのような外部共有リンク発行系まで幅広く、CSM Attachment API側はアップロード・削除が100件/時、参照系が500件/時と、操作の重さに応じて差が付いていました。
残る2件はOAuth APIs（トークン検証系）とUA GCFです。標準のレート制限は、大量データを一括で出し入れするAPIと、ファイルを添付・同期するAPIに集中して仕込まれている、というのが実機から読み取れる傾向です。IncidentやChangeといった業務レコードの一般的なCRUD操作、いわゆるTable APIには、OOTBのレート制限ルールが1件もありませんでした。31件のapiの値を並べても、Table APIやIncident関連は出てきません。ただしこれは「標準では制限が設定されていない」という意味であって、「制限を設定できない」という意味ではありません。
しきい値はどう決まるのか（フィールドと最小・最大の実例）
sys_rate_limit_rulesの固有フィールドをsys_dictionaryで確認すると、しきい値の仕組みが見えてきます。
しきい値を持つフィールドはrequests（ラベルはRequest limit per hour）ただ1つです。日次や分単位のしきい値を別に設定するフィールドは存在せず、ラベルどおり「1時間あたり何回まで」という単位でしか設定できません。実際のフォームでは、しきい値と適用対象がどう組み合わさっているかが一目で分かります。下は、全31件の中で最も低いしきい値のルールです。
CMDB Pushでの一括データ投入は「30件/時」という、31件中もっとも厳しいしきい値が設定されています。CMDB Pushは1回のリクエストでまとまった量のCIデータを送る用途なので、回数そのものより頻度を絞る設計だと読めます。対照的に、もっとも緩いのが次のルールです。
OAuthのトークン発行元情報を取得するGETは「36,000件/時」、秒換算にすると約10件/秒です。CMDB Pushの1,200倍にあたる枠でした。認証まわりの軽いGETリクエストは頻繁に呼ばれる前提で、太い枠が用意されていると考えられます。
適用対象（Apply to）は3択、既定はRole
typeフィールド（ラベルはApply to）の選択肢は3つあります。User（個人単位）・Role（ロールを持つ全ユーザー）・All（全ユーザー）で、既定値はRoleです。実測では31件中、Roleが26件、Allが5件、Userは0件でした。個人を名指しで制限するルールは、このPDIには1つもありません。
自分でルールを追加するときも、この3択のどれを選ぶかで意味合いが変わります。特定の連携アカウント1つだけを絞りたいならUser、特定のロールを持つすべての利用者を対象にするならRole、テナント全体で頭打ちにしたいならAllという使い分けです。今回のOOTBルールの大半がRoleを選んでいるのは、CMDB Data ManagerやCSM Attachmentのような機能単位のロールに対して制限をかける設計思想が表れています。
しきい値の分布を見ると500件/時が標準的な値だと分かる
31件全体のしきい値を集計すると、ばらつきの中に一つの基準値が見えてきます。
31件中23件、実に7割以上が「500件/時」という共通の値を使っています。これがOOTBでの既定的な水準だと考えてよさそうです。100件/時はCSM Attachment APIの削除・アップロード系3件に、3,600件/時はDocuments APIのPermalink取得系2件に付いていました。極端な値は先ほど見た30件/時（CMDB Push）と36,000件/時（OAuth）の2つだけで、それ以外は500件を軸に上下する構成です。
引っかかったらどこに記録されるのか
レート制限は、しきい値を超えたら終わりという単純な仕組みではありません。超過の記録を残す構造も持っています。
フォームにある3つの関連情報
実機でルールのフォームを開くと、フィールドの下に3つの関連情報が並んでいました。
Reset Rate Limit Counts（関連リンク） … カウントを手動でリセットする操作です。今回は読み取り専用の方針のため実行していません。
Rate Limit Counts（関連リスト） … User・Request count・Count Startの3列です。誰が何回、いつからカウント中かを保持します。
Rate Limit Violations（関連リスト） … 超過が起きたときの記録です。
実体は3つのテーブル構成
sys_db_objectでテーブル定義を確認すると、これらの関連リストの実体が次の3テーブルであると分かりました。
sys_rate_limit_rules（31件） … ルールそのもの。しきい値と適用対象を持ちます。
sys_rate_limit_count（0件） … 実行中のカウント。ユーザーとルールごとに、何回使ったかを保持します。
sys_rate_limit_violations（0件） … しきい値を超えたときの記録。rate_limit_ruleとuserへの参照を持つだけの、シンプルな作りです。
以下は、違反記録テーブルの一覧画面です。
「No records to display」、つまりこのPDIでは1件も違反が発生していません。意図的な大量リクエストで再現したわけではなく、通常の検証作業の範囲では標準のしきい値に引っかからなかった、という事実です。31件のうち最小の30件/時（CMDB Push）でも、PDIでの検証作業程度では超えない水準だと分かります。
制限がかかったときの全体の流れを図にすると、次のようになります。
判定は、ルールが一致するかを確かめる段階と、カウントがしきい値未満かを確かめる段階の、2段階に分かれています。超過時にどのようなHTTPステータス・エラーメッセージが返るかは、このPDIでは未発火のため実測できていません。この点は検証範囲外として末尾にまとめます。
実機で気づいたこと
一般論ではなく、今回実機を触っていて意外だった点を3つ書きます。
しきい値の単位が「1時間」しか選べないことが、まず意外でした。てっきり秒・分・時間・日から選べる設計だと思い込んでいましたが、sys_dictionaryを見る限り、requestsフィールド以外にしきい値関連の項目はありません。ラベルに"per hour"と明記されている以上、時間枠は固定の仕様のようです。分単位でバーストを制御したいケースには、この標準機能だけでは足りないと分かります。
tableとimport_set_tableという、使われていないフィールドが用意されていたことにも気づきました。31件のルールをすべて調べても、この2つのフィールドを使っているレコードはゼロでした。用途が明記されたドキュメントには行き着けませんでしたが、フィールド名から見て、特定のテーブルやインポートセットへのアクセスだけを絞るための拡張ポイントとして残されているのだと推測します。標準ルールが使っていない拡張フィールドの存在に気づけたのは、31件全件のフィールドを横断して見たからこそでした。
rest_api_resource（string型）とapi_resource（choice型）という、内容が完全に重複する2つのフィールドが存在することも印象的でした。31件全レコードで、両者の値は文字列としてまったく同じです。たとえばPOST /now/documents/uploadのように一致します。おそらくapi_resourceは選択式の入力用、rest_api_resourceは検索・表示用に複製された値だと考えられますが、最初に見たときはなぜ2つあるのか戸惑いました。ルールを自作するときは、フォーム上の入力欄であるapi_resourceを基準にするのがよさそうです。
連携を設計するとき、レート制限は何から確認すればよいか
ここからは事実と切り離した、実務での使い方の提案です。
外部システムとの連携を新しく設計するときは、まず呼び出し予定のAPIがsys_rate_limit_rulesに登録されているかどうかを確認すると、しきい値超過を未然に防げます。確認手順は次の3ステップです。
sys_rate_limit_rules_list.do?sysparm_query=api_resourceLIKE<パスの一部>で、これから呼ぶAPI（メソッドとパス）に一致するルールがあるか検索する
ヒットしたらrequests（しきい値）とtype（適用対象）を確認する。type=Roleなら、連携に使うユーザーが該当ロールを持っているかも合わせて見る
連携先がCMDB Pushのような一括データ投入や、添付ファイルの一括アップロードを行うAPIであれば、しきい値が低めに設定されている前提でバッチサイズや呼び出し間隔を設計する
具体的な場面で考えてみます。たとえば「CMDB Pushで1万件のCIを一括投入したい」という要件が来たとします。今回の実測ではCMDB Push ingest limitが30件/時でした。1リクエストで何件のCIを送れるかはAPI設計側の話になりますが、1回で何件送れるかを確認せずに、何回送れるか（30回/時）だけで見積もると、投入計画が破綻します。この場合、事前に確認すべきは次の2点です。
1回のPOSTリクエストに含められるCI件数の上限（APIドキュメント側の情報）
30件/時という制限が投入ジョブ全体に対してか、呼び出し元ユーザー単位かの範囲
自分たちで独自のレート制限ルールを追加したい場合は、sys_rate_limit_rulesに新規レコードを作成する形になります。対象を特定のテーブルやインポートセットに絞るtable・import_set_tableフィールドの存在も確認できましたが、現状のOOTBルールはどれも使っていません。特定のカスタムテーブルへのTable APIアクセスだけ絞りたいといった独自要件に対応するためのフィールドだと考えられますが、実機で使用例が確認できたわけではないため、あくまで推測にとどめます。
いずれの場合も、しきい値を決め打ちで書き換える前に、Rate Limit Countsの関連リストで現状の使用状況を確認するのが安全です。既存の連携がどの程度の頻度でAPIを呼んでいるかを把握してから、しきい値を調整する順番をおすすめします。
関連記事
独自エンドポイントを自分で作る（Scripted REST API） — この記事が「検証範囲外」としていたレート制限を、本記事で扱っています
ServiceNowの外部連携が届かないときどこを見る？ ECC Queueに答えが無い理由 — 「連携が急に動かない」を切り分ける入口の記事
外部APIを呼びに行く出口（送信側REST Message） — 逆方向、ServiceNowから外部を呼ぶ側の制限・設計を知りたい人向け
よくある質問
Q1. 429のようなエラーが返ってきたら、まず何を確認しますか
呼び出したAPIのメソッドとパスをそのままsys_rate_limit_rulesで検索します。api_resourceの値に一致するレコードがあれば、requests（しきい値）とtype（適用対象）を確認してください。ヒットしなければ、レート制限以外の原因（認証切れ、ACL、ネットワーク経路など）を疑う段階に移ります。
Q2. type=UserとRoleとAllの違いは何ですか
カウントの単位が変わります。Userは特定の1ユーザーだけの回数を数え、Roleはそのロールを持つ全ユーザーの合計回数を数え、Allはインスタンス全体で1つの回数を数えます。今回のPDIではRoleが26件ともっとも多く、Userは0件でした。
Q3. Table APIやIncidentのREST呼び出しにもレート制限はありますか
今回確認したOOTBの31件には、Table APIやIncidentを対象にしたルールはありませんでした。標準のレート制限は、CMDBの一括投入やドキュメント・添付ファイルの出し入れに集中しています。一般的な業務レコードのCRUD操作を絞りたい場合は、自分でルールを追加する必要があります。
Q4. しきい値を一時的に緩めることはできますか
sys_rate_limit_rulesのレコードを開き、requestsの値を変更すれば反映されます。ただし今回の検証では実際に変更・保存する操作は行っていません。変更前の値を控えておき、必要に応じて元に戻せるようにしておくのが安全です。
Q5. カウントはいつリセットされますか
Rate Limit Counts関連リストのCount Startが、カウントを開始した時刻です。しきい値の単位が1時間であることから、一定時間が経過するとカウントが繰り上がる仕組みだと考えられます。ただし実際にカウントが動いている状態を観測できたわけではありません。正確な切り替わりのタイミングは、この記事の検証範囲外とします。手動でリセットしたい場合は、フォームのReset Rate Limit Countsから操作できます。この操作を行うと、対象ルールのカウントが即座にゼロへ戻る想定ですが、こちらも実行はしていないため、挙動そのものは未確認です。
Q6. IntegrationHubやFlow Designerから呼ぶAPIにも同じ制限は効きますか
sys_rate_limit_rulesはAPIとリソース（メソッドとパス）に対して効く仕組みです。呼び出し元がIntegrationHubのアクションであっても、Scripted REST APIの直接呼び出しであっても、同じルールが適用されると考えられます。呼び出し元の種類によって制限が変わるフィールドは、今回確認した固有フィールドの中には見当たりませんでした。ただし実際にIntegrationHub経由での呼び出しでカウントが増える様子を確認したわけではないため、この点は推測にとどめます。IntegrationHubのスパイクを伴うワークフローを設計する際は、裏側で叩いているAPIのしきい値も一緒に確認しておくと安心です。
まとめ
ServiceNowのREST APIには、標準で31件のレート制限ルールが仕込まれています。9割以上がCMDB系とドキュメント・添付ファイル系に集中しており、IncidentやTable APIのような一般的な業務レコード操作は対象外でした。しきい値は1時間あたりの回数で、500件/時が標準的な水準です。最小は30件/時（CMDB Push）、最大は36,000件/時（OAuth）でした。
超過の記録はsys_rate_limit_violationsに残る仕組みですが、このPDIでは0件です。連携でエラーが増えたときは、まずsys_rate_limit_rulesを対象のAPIで検索し、しきい値と適用対象を確認するところから始めるのが近道です。
用語
sys_rate_limit_rules … レート制限ルールの定義テーブル。しきい値（requests）と適用対象（type）を持つ
sys_rate_limit_count … 実行中のカウントを保持するテーブル。ユーザー・ルールごとに何回使ったかを記録
sys_rate_limit_violations … しきい値を超えたときの記録テーブル
Apply to（type） … 適用対象の3択。User（個人）・Role（ロール）・All（全員）
Request limit per hour（requests） … 1時間あたりのしきい値
自分の環境で確認するときのURL
/sys_rate_limit_rules_list.do?sysparm_query=active=true^ORDERBYname
/sys_rate_limit_rules_list.do?sysparm_query=type=Role
/sys_rate_limit_violations_list.do
/sys_dictionary_list.do?sysparm_query=name=sys_rate_limit_rules^elementISNOTEMPTY参考リンク
検証環境と検証範囲外
確認した範囲は、PDI（Zurich / OOTB / 2026-08-09 確認）の次の内容です。sys_rate_limit_rules31件（すべてactive）のカテゴリ別内訳・しきい値の分布・typeの分布、主要フィールドの定義、sys_rate_limit_violationsとsys_rate_limit_countの件数とフィールド構成、フォーム画面での関連リンク・関連リストの構成です。
確認していない範囲は次のとおりで、断定はしません。しきい値超過時に実際に返るHTTPステータス・エラーメッセージの内容は、意図的な負荷テストを行っていないため未確認です。table・import_set_tableフィールドを使った独自ルールの実際の挙動も確認できていません。sys_one_extend_rate_limit_rulesなど類似名の別テーブル（0件・用途未確認）、本番環境やカスタマイズ済み環境でのルール件数・しきい値も今回は扱っていません。REST APIのペイロードサイズ上限のような、レート制限以外の流量制御の仕組みも検証範囲外です。
