Apigeeのレート制限完全ガイド：Quota・Spike Arrest・Adaptive Quota徹底解説（2026年版）

2026年6月13日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 Quota ポリシーの概要
2 Spike Arrest ポリシーの概要
3 KVM を利用した可変上限値の取得例
4 Envoy との連携具体例
5 バースト対応と Spike Arrest の組み合わせ
6 環境別設定サンプル（prod 用）
7 主要指標と推奨閾値
8 キャパシティプランニング手順
9 ポリシーサンプル（JSON/YAML）
10 GitHub Actions を用いた自動デプロイ例
11 トラブルシューティングチェックリスト

スポンサードリンク

Quota ポリシーの概要

Quota は「一定時間内に許容できる総リクエスト数」を管理するポリシーです。期間単位で上限を設定することで、課金モデルや SLA に合わせた安定運用が実現できます。

主なパラメータ
interval : 制御対象となる時間間隔（例: 1 minute, 1 hour, 1 day）
allow : 上限リクエスト数（整数）
identifier: ユーザーやアプリを区別するキー（例: request.header.client-id）
代表的な設定例

使用シーン	interval	allow	コメント
1 分間に最大 500 件	`1 minute`	500	短時間のトラフィック上限
月次で 10,000 件まで	`1 month`	10000	ビジネス単位の課金枠

ポイント：Quota は期間ごとの総量を制御するため、長期的なリソース確保や利用料計算に最適です。

Spike Arrest ポリシーの概要

Spike Arrest は「秒単位」や「ミリ秒単位」で許容できるレートを設定し、瞬間的なトラフィック急増（スパイク）を平滑化します。バックエンドへの過負荷防止に特化した機能です。

主なパラメータ
rate : 許容リクエストレート（例: 100ps＝100 リクエスト/秒、200pm＝200 リクエスト/分）
設定例

使用シーン	rate	コメント
1 秒間に最大 100 件	`100ps`	高スループット API の保護
10 ミリ秒ごとに最大 2 件	`200pm`（＝1200 リクエスト/分）	細かい粒度のレート制御

ポイント：Spike Arrest は瞬間的なバーストを抑えるため、フロントエンド保護層として Quota と併用することが推奨されます。

動的レート制限（Adaptive / Dynamic Quota）の現状と実装上の注意点

2026 年に「Dynamic Quota」や「Adaptive Quota」と呼ばれる概念がコミュニティで議論されていますが、公式ドキュメントに type="adaptive" といった属性は存在しません。そのため、動的な上限を実現したい場合は以下のような代替手段を取ります。

KVM に上限値を格納し、ポリシー実行時に Variable もしくは JavaScript ポリシーで取得。
取得した変数を通常の Quota ポリシーの allow 属性に参照させる（countRef ではなく allow に動的値を代入）。

KVM を利用した可変上限値の取得例

# KVM の作成と上限値登録（gcloud CLI でも可）
curl -X POST &quot;https://apigee.googleapis.com/v1/organizations/${ORG}/environments/${ENV}/keyvaluemaps&quot; \
     -H &quot;Authorization: Bearer $TOKEN&quot; \
     -d '{
           &quot;name&quot;:&quot;dynamic-quota&quot;,
           &quot;entry&quot;:[{&quot;name&quot;:&quot;rateLimit&quot;,&quot;value&quot;:&quot;1200&quot;}]
         }'

# KVM の作成と上限値登録（gcloud CLI でも可）

curl -X POST "https://apigee.googleapis.com/v1/organizations/${ORG}/environments/${ENV}/keyvaluemaps" \

-H "Authorization: Bearer $TOKEN" \

-d '{

"name":"dynamic-quota",

"entry":[{"name":"rateLimit","value":"1200"}]

&lt;!-- JavaScript ポリシーで KVM から上限を取得 --&gt;
&lt;JavaScript name=&quot;GetDynamicQuota&quot;&gt;
  &lt;ResourceURL&gt;jsc://get-dynamic-quota.js&lt;/ResourceURL&gt;
&lt;/JavaScript&gt;

<ResourceURL>jsc://get-dynamic-quota.js</ResourceURL>

</JavaScript>

get-dynamic-quota.js

var kv = context.getVariable('target.kvm.dynamic-quota.rateLimit');
if (kv) {
  // 取得した文字列を数値に変換して変数へ格納
  context.setVariable('dynamic.quota.limit', parseInt(kv, 10));
} else {
  // デフォルト上限（例: 500）を設定
  context.setVariable('dynamic.quota.limit', 500);
}

var kv = context.getVariable('target.kvm.dynamic-quota.rateLimit');

if (kv) {

// 取得した文字列を数値に変換して変数へ格納

context.setVariable('dynamic.quota.limit', parseInt(kv, 10));

} else {

// デフォルト上限（例: 500）を設定

context.setVariable('dynamic.quota.limit', 500);

}

&lt;!-- 通常の Quota ポリシーで動的変数を参照 --&gt;
&lt;Quota name=&quot;DynamicQuota&quot;&gt;
  &lt;Interval&gt;1 minute&lt;/Interval&gt;
  &lt;Allow ref=&quot;dynamic.quota.limit&quot;/&gt;
  &lt;Identifier ref=&quot;request.header.client-id&quot;/&gt;
&lt;/Quota&gt;

<Interval>1 minute</Interval>

</Quota>

注意：上記は「公式にサポートされた」構文ではなく、実装例として広く採用されている手法です。導入前にステージング環境で十分なテストを行ってください。

Envoy との連携具体例

Envoy 側でも同様の上限情報を利用したい場合は、Apigee が提供する HTTP ヘッダー を取得し、local_rate_limit フィルタに反映させます。

# envoy.yaml の filter_chain 例
filters:
- name: envoy.filters.http.router
  typed_config: {}
- name: envoy.filters.http.local_ratelimit
  typed_config:
    &quot;@type&quot;: type.googleapis.com/envoy.extensions.filters.http.local_rate_limit.v3.LocalRateLimit
    stat_prefix: http_local_rate_limiter
    token_bucket:
      max_tokens: 1200            # デフォルト上限（Apigee が返すヘッダーで上書き可能）
      tokens_per_fill: 0          # 動的に更新されるため 0 に設定
      fill_interval: 60s
    filter_enabled:
      runtime_key: local_rate_limit_enabled
      default_value:
        numerator: 100
        denominator: HUNDRED
    request_headers_to_add:
    - header:
        key: x-apigee-dynamic-limit
        value: &quot;%REQ(x-adaptive-limit)%&quot;

# envoy.yaml の filter_chain 例

filters:

- name: envoy.filters.http.router

typed_config: {}

- name: envoy.filters.http.local_ratelimit

typed_config:

"@type": type.googleapis.com/envoy.extensions.filters.http.local_rate_limit.v3.LocalRateLimit

stat_prefix: http_local_rate_limiter

token_bucket:

max_tokens: 1200 # デフォルト上限（Apigee が返すヘッダーで上書き可能）

tokens_per_fill: 0 # 動的に更新されるため 0 に設定

fill_interval: 60s

filter_enabled:

runtime_key: local_rate_limit_enabled

default_value:

numerator: 100

denominator: HUNDRED

request_headers_to_add:

- header:

key: x-apigee-dynamic-limit

value: "%REQ(x-adaptive-limit)%"

ポイント：Apigee 側で x-adaptive-limit ヘッダーを付与し、Envoy の local_rate_limit に動的に反映させることで、エッジ全体で統一したレート制御が可能です。

実践的なレート制限設計パターン

本セクションでは、バースト対応 と Spike Arrest の組み合わせ に焦点を当て、環境別に推奨される設定例とその根拠を示します。

バースト対応と Spike Arrest の組み合わせ

バースト（突発的なピーク）を吸収するための「バッファ」 Quota と、瞬間レートを抑える Spike Arrest を同時に適用します。実務で推奨される比率は バッファ上限の約 70% 程度です。

環境	バッファ (リクエスト/分)	Spike Arrest レート
dev	200 (= 1.5 × 133)	90ps
staging	300 (= 2 × 150)	120ps
prod	600 (= 1.5 × 400)	280ps

ポイント：バッファを余裕持たせることで、Spike Arrest が頻発するリスクを低減しつつ、全体スループットを確保できます。

環境別設定サンプル（prod 用）

以下はプロダクション環境での代表的な XML 設定です。コメントで各要素の意図を示しています。

&lt;!-- Spike Arrest：瞬間レート上限 --&gt;
&lt;SpikeArrest name=&quot;ProdSpikeArrest&quot; async=&quot;false&quot;&gt;
  &lt;Rate&gt;280ps&lt;/Rate&gt;
&lt;/SpikeArrest&gt;

&lt;!-- バッファ用 Quota（Burst） --&gt;
&lt;Quota name=&quot;ProdBurstBuffer&quot; async=&quot;false&quot;&gt;
  &lt;Interval&gt;1 minute&lt;/Interval&gt;
  &lt;Allow count=&quot;600&quot;/&gt;
  &lt;Identifier ref=&quot;request.header.client-id&quot;/&gt;
  &lt;DisplayName&gt;ProdBurstBuffer&lt;/DisplayName&gt;
&lt;/Quota&gt;

</SpikeArrest>

<Interval>1 minute</Interval>

<DisplayName>ProdBurstBuffer</DisplayName>

</Quota>

モニタリング・アラートとキャパシティプランニング

レート制限の有効性は リアルタイムモニタリング と 適切な閾値設定 によってのみ検証できます。以下では Cloud Monitoring へのメトリクスエクスポート例と、推奨アラート条件を示します。

主要指標と推奨閾値

指標	推奨アラート条件
Quota ヒット率（5 分平均）	> 85 % → `warning`、> 95 % → `critical`
Spike Arrest 発火回数（1 時間合計）	> 1,000 回/時 → `warning`、> 2,000 回/時 → `critical`
Edge CPU 使用率	> 75 % → `warning`、> 90 % → `critical`

キャパシティプランニング手順

ベースライン取得
過去 7 日間のリクエストレートと平均処理時間を Cloud Monitoring のクエリで集計します。
上限算出式（経験則）
AllowedRate = (EdgeCPU * 0.8) / AvgProcessingTime
EdgeCPU は割り当てられた CPU コア数
AvgProcessingTime はミリ秒単位の平均処理時間
バッファ追加
想定される突発負荷を考慮し、AllowedRate * 1.2 を上限として Quota と Spike Arrest に反映します。

注意：本式はあくまで目安です。実際のトラフィックパターンに合わせて係数を調整してください。

CI/CD でのポリシー管理とトラブルシューティング

自動デプロイと可視化を組み合わせることで、設定ミスや容量不足による障害を早期に検知できます。

ポリシーサンプル（JSON/YAML）

{
  &quot;name&quot;: &quot;QuotaPolicy&quot;,
  &quot;type&quot;: &quot;Quota&quot;,
  &quot;properties&quot;: {
    &quot;interval&quot;: &quot;1 minute&quot;,
    &quot;allow&quot;: 500,
    &quot;identifier&quot;: &quot;${request.header.client-id}&quot;
  }
}

{

"name": "QuotaPolicy",

"type": "Quota",

"properties": {

"interval": "1 minute",

"allow": 500,

"identifier": "${request.header.client-id}"

}

# Spike Arrest の YAML 表記例（Envoy 用）
apiVersion: apigee.googleapis.com/v1
kind: SpikeArrestPolicy
metadata:
  name: spike-arrest-prod
spec:
  rate: &quot;280ps&quot;

# Spike Arrest の YAML 表記例（Envoy 用）

apiVersion: apigee.googleapis.com/v1

kind: SpikeArrestPolicy

metadata:

name: spike-arrest-prod

spec:

rate: "280ps"

GitHub Actions を用いた自動デプロイ例

name: Deploy Apigee Proxy

on:
  push:
    branches: [ main ]

jobs:
  deploy-proxy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Authenticate to GCP
        uses: google-github-actions/auth@v1
        with:
          credentials_json: ${{ secrets.GCP_SA_KEY }}
      - name: Deploy proxy bundle
        run: |
          curl -X POST &quot;https://apigee.googleapis.com/v1/organizations/${{ env.APIGEE_ORG }}/environments/${{ env.APIGEE_ENV }}/apis&quot; \
               -H &quot;Authorization: Bearer $(gcloud auth print-access-token)&quot; \
               -F &quot;file=@apiproxy.zip&quot;

name: Deploy Apigee Proxy

on:

push:

branches: [ main ]

jobs:

deploy-proxy:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v3

- name: Authenticate to GCP

uses: google-github-actions/auth@v1

with:

credentials_json: ${{ secrets.GCP_SA_KEY }}

- name: Deploy proxy bundle

run: |

curl -X POST "https://apigee.googleapis.com/v1/organizations/${{ env.APIGEE_ORG }}/environments/${{ env.APIGEE_ENV }}/apis" \

-H "Authorization: Bearer $(gcloud auth print-access-token)" \

-F "file=@apiproxy.zip"

トラブルシューティングチェックリスト

項目	確認ポイント	推奨アクション
Quota ヒット数が急増	`Analytics > API Proxy > Quota` の時系列グラフ	上限値再計算、バッファ拡張
Spike Arrest が頻発	Trace で `SpikeArrest` ステップの実行時間確認	レート緩和または Burst Quota 追加
504 エラーが多発	Edge の CPU/メモリ使用率（Monitoring）	インスタンスタイプ拡張、レート制限見直し

ポイント：ポリシー変更後は必ずステージング環境で負荷テストを実施し、トラフィックパターンが期待通りに抑制されていることを確認します。

まとめ

Quota と Spike Arrest の役割分担
Quota は期間ごとの総リクエスト上限を管理し、長期的なリソース確保や課金に最適。
Spike Arrest は瞬間的なバーストを抑制し、フロントエンドの安定性を担保。
動的レート制限の実装指針
公式には type="adaptive" が存在しないため、KVM + JavaScript（または Variable）で上限値を取得し、通常の Quota に組み込む方法が現実的。
設計パターン
バッファ Quota と Spike Arrest の比率を約 70% 前後に設定し、環境別（dev / staging / prod）で上限を調整。
モニタリングとキャパシティプランニング
Cloud Monitoring に主要指標をエクスポートし、Quota ヒット率・Spike Arrest 発火回数の閾値でアラートを構築。
CPU 使用率と平均処理時間から算出した上限式をベースに、1.2 倍のバッファを加えて設定する。
CI/CD とトラブルシューティング
JSON/YAML のポリシー定義をコード管理し、GitHub Actions／Cloud Build で自動デプロイ。
Trace と Analytics による可視化を活用し、障害時は上記チェックリストで迅速に原因切り分け。