ポリシーと閾値の調整

（本機能はExtensionsトライアルで試用可能です）

概要¶

本ページでは、レートリミットの各ポリシーの役割と、閾値（上限値）を調整する際の考え方を説明します。機能全体の概要・動作モード・上限超過時の動作については「レートリミット機能」を、各設定項目の記述方法については パラメータマニュアルRateLimit.jsonを参照してください。

ポリシーごとの説明¶

各ポリシーは、対応する機能カテゴリのリクエストに適用されます。既定値は、一般的な利用で誤って制限が発動しにくい値に設定していますが、利用環境に応じて調整してください。

GlobalLimiter（全経路共通の上位ポリシー）¶

単位：Auto（ログインユーザ、未認証の場合はIP）
アルゴリズム・既定：TokenBucket（容量100 / 毎秒+50）
全リクエストに一律で適用される上位の防壁です。個別ポリシーが設定されていない経路にも適用され、特定の利用者・IPによる極端な集中を最終的に抑制します。「ExcludePaths」に指定したパスはGlobalLimiterの対象外となります。

General（一般的な画面操作）¶

単位：User
アルゴリズム・既定：TokenBucket（容量10 / 毎秒+5）
レコードの編集画面、各種ダイアログ、ダッシュボードのパーツ表示など、一般的な画面操作に適用されます。

調整の観点：
ダッシュボードに多数のパーツを配置している場合、画面表示や再読み込みのたびに短時間で多くのリクエストが発生します。パーツ数の多いダッシュボードを利用する環境では、容量（TokenLimit）に余裕を持たせてください。

List（一覧・検索・集計）¶

単位：User
アルゴリズム・既定：SlidingWindow（直近60秒で30回）
一覧表示、検索、グリッド操作、クロス集計などに適用されます。

調整の観点：
検索条件の入力補助（サジェスト）や、一覧の連続操作が多い業務では、上限に余裕を持たせてください。

Admin（管理操作）¶

単位：User
アルゴリズム・既定：FixedWindow（60秒ごとに30回）
ユーザ管理・組織管理・グループ管理・システムログなどの管理操作に適用されます。

Heavy（画面側の重い処理）¶

単位：User
アルゴリズム・既定：Concurrency（同時1）
エクスポート、インポート、一括更新・一括削除、サイトパッケージ操作など、サーバ負荷の高い処理に適用されます。回数ではなく「同時実行数」を制限します。

調整の観点：
既定（同時1）では、1人の利用者が同時に2つ目の重い処理を実行しようとすると待機・拒否されます。複数タブでの並行操作などを許容したい場合は、同時実行数（PermitLimit）を引き上げてください。

ApiHeavy（API経由の重い処理）¶

単位：ApiKey
アルゴリズム・既定：Concurrency（同時1）
API経由のエクスポート・インポート・一括処理などに適用されます。同一APIキー単位で同時実行数を制限します。

Api（REST API 全般）¶

単位：Auto
アルゴリズム・既定：TokenBucket（容量30 / 毎秒+10）
REST API 全般に適用されます。

調整の観点：
外部システム連携やバッチ処理など、APIを高頻度で呼び出す利用形態では、上限に余裕を持たせてください。連携・監視用のアカウントはRateLimit.jsonの「Exclusions」で対象外にすることもできます。

AnonymousIp（未認証アクセス）¶

単位：Ip
アルゴリズム・既定：FixedWindow（60秒で60回）
ログイン試行など、未認証のアクセスに適用されます。接続元IP単位で制限します。

調整の観点：
社内NATなど、多数の利用者が同一のIPアドレスを共有する環境では、始業時の一斉ログインなどで上限に達しやすくなります。正規の利用者を制限しない値に調整してください。なお、本ポリシーはIP単位の制限であり、アカウントへの不正ログイン（総当り）対策としては、別途アカウントのロックアウト（Security.jsonの「LockoutCount」）の併用を推奨します。

PublicForm（公開フォームの送信）¶

単位：Ip
アルゴリズム・既定：TokenBucket（容量5 / 毎秒+2）
公開フォームの送信に適用されます。接続元IP単位で制限します。

調整の観点：
社内NATなど共有IP環境では、共有規模に応じて閾値の拡大を検討してください（目安は パラメータマニュアルRateLimit.jsonの「PublicFormの調整」を参照）。

閾値調整の考え方¶

1. まず「LogOnly」で観測する¶

本番相当のアクセスをMode: "LogOnly"で観測し、構造化ログ（ratelimitlogs.json）に記録される仮想拒否の発生状況から、誤って制限してしまう箇所を確認します。あわせて、同ログに一定間隔（既定60秒）で記録されるポリシー別の件数集計（「RateLimitMetricsSnapshot」）を用いると、どのポリシーがどの程度発動しているかを数値で把握できます。閾値は、業務ピーク時の実測値の2倍以上を目安に設定すると、誤検知を避けやすくなります。外部の監視基盤へ件数を連携したい場合はレートリミット機能：拒否ログ・メトリクスの出力先設定を参照してください。

2. 利用者単位（User）のポリシーは「1人あたりの最大利用」で決める¶

General / List / Admin / Heavy は利用者ごとに独立した上限です。利用者数（契約プランの人数）に比例して大きくする必要はありません。特に、パーツ数の多いダッシュボードを使う場合の General に注意してください。

3. IP単位（Ip）のポリシーは「共有IPの同時集中」を考慮する¶

AnonymousIp / PublicForm は接続元IP単位です。社内NATなどで多数の利用者が同一IPを共有する場合は、その規模を考慮して引き上げてください。

4. 対象外にしたいアカウントは「Exclusions」へ¶

バッチ処理用アカウントや監視ツールなど、制限の対象としたくないユーザはRateLimit.jsonの「Exclusions」の「LoginIds」にログインIDを登録します。

5. リバースプロキシ／ロードバランサ配下での注意¶

IP単位の制限を正しく機能させるには、接続元IPアドレスを正しく取得できるよう、Security.jsonの「ForwardedHeaders」で信頼するプロキシを必ず設定してください。設定がない場合、すべてのアクセスが同一IPと見なされ、IP単位の制限が意図どおりに機能しないことがあります。

対応バージョン¶

関連情報¶

• レートリミット機能：拒否ログ・メトリクスの出力先設定