API のレート制限は、システムの過負荷や悪用を防ぎつつ、アプリが Apple や Google のガイドラインに準拠することを保証します。リクエスト頻度を制限することで、セキュリティの向上、コスト削減、そしてスムーズなパフォーマンスを実現します。以下に重要なポイントをまとめました:
- なぜ重要か:ブルートフォース攻撃の防止、サーバー負荷の管理、および App Store での審査落ちを回避します。
- 手法:
- Fixed Window: シンプルですが、トラフィックのスパイクが発生する可能性があります。
- Sliding Window: トラフィックを平滑化しますが、より多くのメモリを消費します。
- Token Bucket: バーストに対応できますが、設定が複雑です。
- コンプライアンス: リトライには指数バックオフを使用し、制限を超えた場合は code ステータス 429 を返します。
- ツール: 以下のようなプラットフォームは、 Capgo 分析、エラー追跡、リアルタイムモニタリングにより実装を簡素化します。
クイックヒント: 安定性とコンプライアンスを確保するため、通常時、バースト時、復旧時の各条件下で制限値をテストしてください。
API のレート制限を理解する:目的、種類、および必須事項 …
App Store API ガイドライン
API のレート制限は、App Store の要件を満たす上で極めて重要です。Apple と Google は、ユーザーデータの保護とシステムの安定性を維持するために、それぞれ独自のルールを設けています。以下にそのポリシーの詳細をまとめました。
Apple の API レート制限
Apple は、認証、データリクエスト、パブリックエンドポイントなどの領域に制限を設けています。これらの制限に違反すると、審査プロセスでのアプリリジェクト、App Store からの一時的な削除、あるいは緊急の修正対応が必要になるなどの影響が出る可能性があります。制限を超過した場合の管理策として、開発者は以下の手法の使用が推奨されています。 指数バックオフ(指数バックオフ)など。これは、リトライの間隔を徐々に増やしていく手法です。
Google の API レート制限
Google Play ストア Google は、パブリックデータへのアクセス、認証、ユーザーデータのリクエストに対して制限を設定しています。一時的なスパイク(急増)は許容されますが、システムは使用状況を厳密に追跡しています。閾値に近づくと警告が発行され、即座に停止されるのではなく、段階的に制限が適用されます。
レート制限の実装ステップ
レート制限の手法
API のレート制限を実装する際は、アプリケーションの要件に合ったアプローチを選択してください。以下に、一般的に使用される3つの手法を紹介します。
固定ウィンドウ方式のレート制限: この手法は、一定の間隔でリセットされる制限(例:100リクエスト)を設定します。シンプルですが、各期間の終了時にトラフィックのスパイクが発生する可能性があります。
スライディングウィンドウ方式: このアプローチは、移動する時間枠を使用してトラフィックを平滑化します。例えば、制限が1分間に100リクエストで、ユーザーが午後2:00:30に50リクエストを行った場合、午後2:01:30までにさらに50リクエストを行うことができます。
トークンバケットアルゴリズム: この手法は、一定のレートでトークンを補充することで柔軟性を持たせます。API の呼び出しごとにトークンを1つ消費し、トークンが枯渇している間は補充されるまでリクエストが拒否されます。
| メソッド | メリット | デメリット | 最適な用途 |
|---|---|---|---|
| 固定ウィンドウ方式 | 実装が容易で、メモリ使用量が少ない | トラフィックのスパイクが発生する可能性がある | 基本的なAPIエンドポイント |
| スライディングウィンドウ | トラフィックを平滑化し、精度も向上 | より多くのメモリが必要 | ユーザー認証API |
| トークンバケット | バーストに対応可能で、カスタマイズも容易 | 実装の難易度が高い | 高トラフィックな公開API |
スライディングウィンドウ方式を用いた実践的な例を紹介します。
実装例
以下は、スライディングウィンドウによるレート制限の実装方法を示すcodeスニペットです。
const rateLimit = async (userId, limit, window) => {
const now = Date.now();
const key = `ratelimit:${userId}`;
const multi = redis.multi();
multi.zremrangebyscore(key, 0, now - window); // Remove expired requests
multi.zadd(key, now, now); // Add the current request
multi.zcard(key); // Count requests in the window
const [,, count] = await multi.exec();
return count <= limit; // Return true if within limit
};
レート制限のテスト
実装後は、レート制限の設定が期待通りに動作することを徹底的にテストしてください。特に次の項目に注目しましょう:
- 基本的な制限のテスト: 通常のレートでリクエストを送信し、標準的な機能を確認します。
- バーストテスト: 同時に複数のリクエストを送信するシミュレーションを行い、制限が正しく適用されるか検証します。
- リカバリテスト: 制限がリセットされた後のシステムの挙動を確認します。
async function testRateLimits() {
// Test normal usage
for (let i = 0; i < 5; i++) {
await makeRequest();
await delay(1000); // Wait 1 second between requests
}
// Test burst protection
const requests = Array(10).fill().map(() => makeRequest());
await Promise.all(requests);
// Verify recovery after limit reset
await delay(60000); // Wait for 1 minute
const response = await makeRequest();
assert(response.status === 200); // Ensure the request is accepted
}
パフォーマンスの監視
デプロイ後は、さまざまな条件下でレート制限システムが適切に動作しているか、主要なメトリクスを監視してください:
- 各タイムウィンドウ内で処理された総リクエスト数
- 拒否されたリクエスト数
- 高トラフィック時のレスポンスタイム
- エラー率とその原因
このデータは、システムを最適化し、最高のパフォーマンスを引き出すための微調整に役立ちます。
レート制限の標準
レート制限の設定
ユーザー体験とサーバー保護のバランスを最適化するには、API のトラフィックパターンとエンドポイントの要件を評価してください。固定のしきい値に頼るのではなく、API の具体的なニーズに合わせてレート制限をカスタマイズしましょう。実際の使用データに基づいてこれらの制限を継続的に調整し、常に効果的かつ実用的な状態を維持してください。
エラーレスポンスの設計
クライアントがレート制限を超えた場合は、 429ステータス codeを返してください。総制限数、残りのリクエスト数、リセット時刻、リトライ間隔を指定するヘッダーを含めます。この詳細なフィードバックにより、開発者は API の制限に合わせてアプリケーションを適切に微調整できるようになります。
制限の調整プロセス
パフォーマンスの維持とコンプライアンス要件の遵守には、レート制限の定期的な見直しが不可欠です。ピーク時のトラフィック、エラー率、サーバー負荷などの要因を監視し、必要な調整を特定してください。ユーザーのフィードバックを取り入れ、運用効率とApp Storeのガイドラインの両方を満たす制限を設定しましょう。
Capgoのレート制限ツール

Capgo は、高いパフォーマンスを維持しつつ、アプリストアの要件を遵守しながら API のレート制限を適用するために設計された統合ツールを提供します。
Capgo のコンプライアンス機能
Capgo は、API のレート制限を維持し、アプリストアのガイドラインを満たすためのさまざまなツールを提供します。そのアップデート配信システムは、平均 API レスポンスタイム 434 ms という高速な動作を実現し、82% という驚異的なアップデート成功率を達成しています。 [1]主な機能は以下の通りです:
- リアルタイム分析:アップデートの配信状況と API の使用状況を追跡します。
- エラー追跡:レート制限の問題を迅速に特定し、修正します。
- チャネルシステム: アップデートのロールアウトを効果的に管理します。
- 暗号化: API の通信を保護します。
これらのツールは標準的なレート制限の実装と併用することで、リアルタイムのデータ提供とプロアクティブなエラー解決を実現します。Capgo のシステムは 750 件のプロダクションアプリでテストされており、コンプライアンスと高いパフォーマンスを維持しながら 2,350 万件のアップデートを提供してきました。 [1].
Capgo によるレート制限
Capgo のレート制限ツールは、既存の Capacitor ワークフローにシームレスに統合されます。API のパフォーマンスを安定させつつ、24時間以内に 95% のユーザーにアップデートを届けることを支援します。 [1].
Capgo のアプローチの詳細は以下の通りです:
| 機能 | 実装 | メリット |
|---|---|---|
| グローバルCDN | 5 MBのbundleを114 msでダウンロード | サーバー負荷を軽減 |
| Channel配信 | 段階的なロールアウトとベータテスト | APIのトラフィックフローを制御 |
| Analytics ダッシュボード | リアルタイムモニタリング | レート制限のパフォーマンスを測定 |
| エラー管理 | 問題の自動検知 | レート制限違反を回避 |
「私たちはアジャイル開発を実践しており、ユーザーへ継続的に届ける上で @Capgo はミッションクリティカルな存在です!」
開始するには、以下を実行してください: npx @capgo/cli init。このコマンドは必要なレート制限を設定し、アプリがAppleおよびGoogleのストア要件に準拠することを保証します。
概要
主なポイント
API のレート制限は、アプリストアの要件を満たし、システムを円滑に稼働させるために極めて重要です。概要は以下の通りです:
| 項目 | 要件 | 効果 |
|---|---|---|
| セキュリティ | エンドツーエンド暗号化 | API の通信とユーザーデータを保護 |
| モニタリング | アナリティクス | API の使用状況を追跡し、規約違反を防止します |
以下のチェックリストを使用して、レート制限戦略を App Store のガイドラインに適合させましょう。
実装チェックリスト
堅牢なレート制限戦略を実装するには、以下の手順に従ってください:
-
レート制限の設定
- App Store のルールに基づき、グローバルなレート制限を定義します。
- リトライメカニズムには指数バックオフ(exponential backoff)を使用します。
- 429 ステータスコードなど、適切なエラーレスポンスを設定します。
-
監視と調整
- 詳細な分析機能を使用して API の使用状況を分析します。
- 自動アラートを設定し、違反の兆候を早期に検知しましょう。
- 実際のパフォーマンスに基づき、必要に応じて制限値を更新します。
-
テストと検証
- 負荷テストを実施し、安定性を確保します。
- エラーレスポンスがコンプライアンス要件を満たしているか確認します。
- コンプライアンスへの取り組みについて、詳細なドキュメントを維持してください。
次はこちら:API App Store コンプライアンスのための Rate Limiting
以下を使用している場合: App Store準拠のための API レート制限 セキュリティとコンプライアンスの計画に使う場合は、以下と連携してください: 暗号化 実装の詳細は「暗号化」を参照: コンプライアンス 実装の詳細は「コンプライアンス」を参照: Capgo セキュリティスキャナー Capgo セキュリティスキャナーの製品ワークフローについては: Capgo セキュリティ Capgo Security でのプロダクトワークフロー向け、および Capgo トラストセンター Capgo Trust Center でのプロダクトワークフロー向け。