要約

  • draft-ietf-httpapi-ratelimit-headers-11 では、外部の中継者はオリジンの値を勝手に緩めるべきではなく、単位を理解して自ら執行するときには、より厳しい制限を示し得る。
  • それでも、通知した方針を執行する責任はサービスにあり、後続要求を受理するかどうかもサービスが決める。ゲートウェイの予測は、オリジンの許可証ではない。

API ゲートウェイは、オリジンから返った r=40;t=20 を r=10;t=20 に狭めた。自身のキューを守るための正当な判断だった。ところが運用画面は、その十件を「オリジンが予約した実行枠」と表示した。

ゲートウェイが止めた要求はオリジンに届かなかった。通した要求の一部は別の認可条件で拒否された。接続障害の後、ゲートウェイが透過的に再試行した一件は、クライアントの帳簿にない二つ目の単位を消費した。

制限は実在した。表示された権限だけが実在しなかった。

IETF HTTPAPI ワーキンググループは、2026 年 5 月 23 日に RateLimit header fields for HTTP の改訂 11 を公開した。これは Standards Track を意図する現役の Internet-Draft で、2026 年 11 月 24 日に期限を迎える。RFC でも、実装や普及を示す資料でもない。本稿は、この作業中の仕様が明示する責任境界だけを扱う。

方針の説明と現在値は別の記録である

RateLimit-Policy は名前付きのクォータ方針を表す。q は割り当て量、qu は単位、w は時間窓、pk は区画を示す。初期の単位には要求数、コンテンツバイト数、同時要求数がある。ある要求が実際に一単位を消費するかは、要求数で数える場合にも実装依存である。

RateLimit は、その方針と区画について現在のサービス限界を知らせる。r が利用可能量、t が有効窓である。前者は方針、後者は観測であり、寿命が違う。一つの remaining 値に上書きすると、名前、単位、区画、時刻を失う。

一つの要求に複数の方針が作用することもある。日次と時間単位の制限が同時に存在し、サービスが枯渇に近い方だけを返すこともできる。表示されなかった方針が存在しないとは言えない。

監査可能な証跡には、発信サービス、受信時刻、方針名、単位、区画、q、w、r、t、状態コード、要求の性質が必要だ。それは当時の通知を再現するが、将来の判定式を複製するものではない。

中継者が緩めてはいけない理由

オリジンの基盤に属さず、方針の意味も知らない中継者が値をより寛容に変えると、クライアントはオリジンが約束していない負荷を送る。フィールドを消して制約を見えなくすることも、同じ方向の改変になり得る。

一方、中継者が単位を理解し、自分の制約を実際に執行するなら、より厳しい値を示せる。例えばオリジンには余裕があっても、地域ゲートウェイの同時接続数が少なければ、経路全体を守るために狭める意味がある。

ただし、この厳格化は「経路上でこれ以上通さない」という中継者自身の決定である。「オリジンが十件を受理する」という肯定的な約束ではない。厳しい境界を示す権限と、最終受理を保証する権限を混同してはならない。

予測しても、通常は転送する

草案は、中継者が要求は処理されないだろうと考えても、通常は転送するべきだとする。通知したクォータ方針を執行する責任はサービス側にあり、サービスは受理する自由も持つからである。

この規則は、r=0 が絶対的拒否ではないことを示す。値と応答状態には必須の相関がない。ゼロでもサービスが要求を処理し得るし、正でも拒否し得る。

ゲートウェイが推測で遮断する設計を選ぶ場合、それは独自の方針として明示し、オリジンの判断を代弁してはならない。利用者に見える結果も「上流が拒否した」ではなく「このゲートウェイの保護規則が転送しなかった」と記録すべきだ。

正の r は通行証ではない

改訂 11 は、正の利用可能量が後続要求の処理を保証しないと明記する。セキュリティ節では、利用可能単位はヒントであり、付与済み要求でもサービスレベル契約でもないとさらに限定する。

応答から次の要求までに負荷は変わる。別の方針が先に限界へ達する。防御機構が値を下げる。認証、認可、アプリケーション検証が別の理由で失敗する。レート制限はそれらを包含しない。

クライアントはヒントを使って無駄なスロットリングを減らせる。しかし、仕事を「最後の観測範囲内」と分類することと、「受理済み」と分類することは違う。受理は後続応答、実行はアプリケーションの受領証、利用者への結果はさらに別の証拠を必要とする。

t が終わっても補充は確定しない

t は、クライアントが r を超えて使わない有効期間を相対秒で示す。絶対時計の同期を避け、同じリセット時刻に大勢が起きる問題を弱める。

しかし、終了時に全量が戻るという意味ではない。サーバーは、スライディングウィンドウ、飽和、自適応制御などによって、次の応答で r と t を変えられる。t がさらに伸びることもある。

したがって期限切れは、古い観測を失効させる時点であり、ローカルバケットの満杯時刻ではない。安全なクライアントはジッターを入れ、小さく確認し、新しい応答を得てから、自身の最大レートと同時数の範囲で増加する。

Retry-After が併記される場合、草案は有効窓より早い時点を示さないよう勧める。それでも、再試行の助言、有効窓、補充、受理は別々の状態である。

透過的な再試行は見えない消費を生む

中継者は、ユーザーエージェントに知らせず要求を再送できる。オリジン側では二回の試行が二単位を消費しても、クライアント側の業務記録は一件のままである。

この差は直ちに不正を意味しない。接続の切断、応答の損失、再送規則、実際に適用された方針を確認する必要がある。要求 ID だけでなく、試行 ID、中継ホップ、再送理由、サービス応答を結び付けなければならない。

逆に、クライアントが準備した要求が中継者で止まり、オリジンの単位を全く消費しないこともある。二つのカウンターの差から原因を推定するのではなく、経路の受領証で追跡する。

区画は識別や認可を証明しない

pk は要求が属するクォータ区画を示す。利用者、アプリケーション、メソッド、資源、その組み合わせで生成できる。規則が文書化されていれば、将来の要求が同じプールを使うか予測しやすい。

しかし同じ区画が同じ人を意味するとは限らない。一人が複数区画を使い、複数人が共有資格情報で一つの区画に入ることもある。草案は機密情報を避け、識別情報を含むキーのなりすましに注意するよう求める。

認可は明示的に対象外である。クォータが残っていても禁止され得る。権限があっても枯渇し得る。401 や 403 が単位を消費するかも実装次第である。区画、主体、権限、受理を一列の状態に潰してはいけない。

大きな値は加速命令ではない

大きな r と短い t を単純に割ると、方針の q/w が示す平均よりはるかに速い送信になる場合がある。善意のヒントが、自動化によって負荷の引き金になる。

過大値は設定ミス、悪意ある中継者、あるいは本物の一時的余裕かもしれない。動機を確定できなくても、クライアントは安全に動ける。最大レート、同時数、メモリ、費用、依存先負荷をローカルで制限し、段階的に増やし、外れ値を切る。

遠隔の観測はローカル方針を補助する。ローカルの安全責任を解除しない。

問題タイプはサービス側の分類である

草案は、クォータ超過、一時的超過、異常利用検出の問題タイプを提案する。違反した方針名を機械可読にし、停止、減速、レビューなどを分けやすくする。

それでも「異常利用」は応答サービスの判定である。悪意、人物、因果を独立に証明しない。可逆的な保護動作には使えても、単独で永久停止や公的な帰責を正当化しない。

RFC 9457 は問題詳細、RFC 6585 は 429、RFC 9110 は HTTP 一般、RFC 9651 は構造化フィールドを定める。構文の正しさは証跡を読みやすくするが、発信者の権限を増やさない。

情報源と限界

凍結した資料は、改訂 11、その Datatracker 状態・履歴・参照、HTTPAPI の活動とプライバシー草案、RFC 9110、9651、6585、9457、9205、IANA のフィールドおよび問題タイプ登録簿である。提案中の仕組みと限界は示すが、実装、製品、事故、普及、性能、相互運用性は示さない。

出典