APIセキュリティとレートリミット（えーぴーあいせきゅりてぃとれーとりみっと）

2025年11月17日

APIセキュリティとレートリミット（えーぴーあいせきゅりてぃとれーとりみっと）

英語表記: API Security and Rate Limiting

概要

APIセキュリティとレートリミットは、特にパブリックに公開されることが多いRESTful APIにおいて、システムの可用性（アベイラビリティ）と安定性を維持するために必須とされる設計原則の一つです。レートリミットとは、特定のクライアントやユーザーが、一定の時間枠内でAPIを呼び出すことができる回数を制限する仕組みを指します。これは、API設計原則の中でも「安定性の確保」という観点から非常に重要であり、悪意のある攻撃（DoS攻撃など）や、単なるクライアント側の実装ミスによる過剰なリクエスト集中からサーバーリソースを保護する役割を果たします。

詳細解説

API設計とマイクロサービスにおける「API設計原則」を考える際、APIが持つべき最も重要な特性の一つは「信頼性」です。APIセキュリティとレートリミットは、この信頼性を物理的に担保するための具体的な手段となります。RESTful APIは、そのステートレスな特性上、リクエストごとに認証や処理を完結させるため、リクエスト数の増加がサーバー負荷に直結しやすいという特徴を持っています。そのため、適切なレートリミットの設定は、優れたRESTful API設計の試金石とも言えるでしょう。

レートリミットの目的と設計原則との関連

レートリミットの主な目的は以下の通りです。

可用性の確保（Availability）: 多数のユーザーが公平にサービスを利用できるようにするため、特定の利用者によるリソースの独占を防ぎます。これは、API設計原則の根幹をなす要素です。
コスト管理: APIの処理能力にはサーバーやデータベースのコストが伴います。レートリミットを設定することで、予期せぬトラフィック急増によるインフラコストの爆発的な増加を防ぎます。
セキュリティ対策: ブルートフォース攻撃（総当たり攻撃）や、大量のリクエストを送りつけることによるサービス妨害（DoS/DDoS）攻撃を未然に防ぎます。特にログインAPIや機密情報を扱うエンドポイントでは、厳格な制限が求められます。

レートリミットの仕組みと種類

レートリミットは、通常、クライアントを識別する情報（IPアドレス、APIキー、認証トークンなど）に基づいて実行されます。識別されたクライアントからのリクエスト数を計測し、設定された上限を超えた場合に、サーバーは処理を拒否します。

サーバーがリクエストを拒否する際には、クライアントに対して標準的なHTTPステータスコード 429 Too Many Requests を返却するのが一般的です。このレスポンスには、多くの場合、次にいつリクエストを再試行すべきかを示す情報（Retry-After ヘッダーなど）が含まれます。これは、クライアント側がサーバーの負荷を考慮して設計されているかを確認するための重要なRESTful API設計の要素です。

レートリミットの実装方式には、主に以下の3種類があります。

固定ウィンドウ（Fixed Window）カウンター:
- 最もシンプルで実装しやすい方式です。例えば、「毎時0分から60分までで1,000回」といったように、厳密な時間枠（ウィンドウ）を設定します。
- 欠点: ウィンドウの境界（例：59分59秒と00分00秒の境目）で大量のリクエストが集中すると、短時間に設定された制限の2倍近くのリクエストが処理されてしまう「バースト問題」が発生しやすいです。
スライディングログ（Sliding Log）:
- 各リクエストのタイムスタンプをログとして記録し、現在の時間から遡って過去N秒間のログ数をカウントする方式です。
- 利点: 非常に正確で、バースト問題を効果的に防げます。
- 欠点: ログの保存と検索に高いメモリと計算リソースが必要となり、大規模なマイクロサービス環境ではコストが高くなりがちです。
スライディングウィンドウ（Sliding Window）カウンター:
- 固定ウィンドウ方式のシンプルさとスライディングログの精度を組み合わせた、最も一般的に利用される方式です。現在のウィンドウの使用量と前のウィンドウの使用量を加重平均して計算します。
- 利点: 計算効率が高く、バーストをある程度抑制できるため、多くのRESTful API設計で採用されています。

これらの機構をAPIゲートウェイや専用のミドルウェア（例えば、EnvoyやNGINXなど）に組み込むことで、バックエンドのマイクロサービスが直接レートリミットの処理を行う必要がなくなり、各サービスの関心事が分離され、よりクリーンなAPI設計が実現します。

タクソノミへの結びつき

この概念は「API設計とマイクロサービス → API設計原則 → RESTful API 設計」という文脈で非常に重要です。なぜなら、RESTful APIの哲学は「リソースへのアクセス」を前提としていますが、無制限なアクセスはリソースの枯渇を招き、結果としてサービス品質の低下、つまりは設計原則の失敗を意味するからです。レートリミットは、API提供者がリソースの利用に対して責任を持ち、継続的なサービス提供を保証するための、運用面とセキュリティ面を兼ね備えた「設計原則」の実践例なのです。特にマイクロサービス環境では、一つのサービスへの過負荷が全体の障害につながるため、入口でのレートリミット（APIゲートウェイでの実施など）は必須の防御策となります。

具体例・活用シーン

レートリミットがどのように機能し、なぜAPI設計に不可欠なのかを理解するために、身近な例を考えてみましょう。

活用シーン

公開データAPI: 天気予報や株価情報を提供するAPIでは、「無料プランのユーザーは1分間に5回まで」「有料のエンタープライズプランのユーザーは1分間に300回まで」といった形で、プランに応じた制限が設けられます。これは公平なリソース配分を実現する典型的な例です。
認証エンドポイントの保護: ログイン（POST /login）エンドポイントに対して、特定のIPアドレスからのリクエストが1分間に10回を超えた場合、そのIPからのリクエストを一時的にブロックします。これにより、自動化されたブルートフォース攻撃によるパスワード推測を効果的に阻止できます。
大規模なデータ取得: ユーザーが過去1年分の取引履歴を一括で取得するAPI（例：GET /transactions?period=annual）は、一度の呼び出しでデータベースに大きな負荷をかけるため、レートリミットとは別に、呼び出し頻度を極端に低く設定したり（例：1日1回まで）、ページネーションを厳しく適用したりすることが推奨されます。

アナロジー：高速道路の料金所

レートリミットの役割は、高速道路の料金所（ETCレーン）の役割に非常によく似ています。

APIサーバーは、都市の中心部に向かう「高速道路」そのものだと想像してください。この高速道路は非常に便利ですが、同時に処理できる車の数（リクエスト）には物理的な限界があります。

もし料金所（レートリミット機構）がなければ、朝のラッシュアワー時に誰もが同時に高速道路に突入しようとし、すぐに大渋滞（サーバーダウンまたは極端な遅延）が発生し、誰も目的地にたどり着けなくなります。

ここで料金所（レートリミット）が登場します。料金所は、ETCカード（APIキーやトークン）を確認し、「このレーンでは1分間に100台までしか通過させません」というルールを適用します。

もし1分間に101台目が押し寄せた場合、料金所の係員（APIゲートウェイ）は「申し訳ありませんが、今は制限を超えています。次の1分まで待機してください」と伝えます。これがHTTP 429レスポンスです。

この仕組みにより、全体の交通量が管理され、高速道路（API）がパンクすることを防ぎ、すでに高速道路を利用している車（処理中のリクエスト）の速度と信頼性が保証されるのです。この交通整理こそが、API設計における可用性維持のための最も重要なセキュリティ対策の一つだと考えられます。

資格試験向けチェックポイント

APIセキュリティとレートリミットは、IT Passport試験や基本情報技術者試験、応用情報技術者試験において、主に「セキュリティ」「ネットワーク」「システムアーキテクチャ」の分野で出題される可能性があります。特に、API設計原則やマイクロサービス設計に関連する文脈で問われることが多いです。

| 項目 | 出題パターンと対策 |
| :— | :— |
| 可用性（Availability） | レートリミットの導入目的として、システムの「可用性」を維持することが最も重要であることを理解しましょう。DoS攻撃対策やリソース枯渇防止と結びつけて問われます。 |
| HTTPステータスコード | レートリミット超過時に返却される標準的なHTTP応答コードは何か？ → 429 Too Many Requests です。このコードの意味と、クライアント側が取るべき行動（Retry-Afterヘッダーの確認）をセットで覚えましょう。 |
| 攻撃手法 | レートリミットが防御対象とする攻撃は何か？ → DoS/DDoS攻撃、ブルートフォース攻撃です。これらの攻撃がシステムに与える影響（リソースの枯渇、サービス停止）を理解してください。 |
| APIゲートウェイの役割 | マイクロサービスアーキテクチャにおいて、レートリミットの機能はどこで実装されるのが効率的か？ → APIゲートウェイやロードバランサの機能として実装されることが多いです。バックエンドサービスへの負荷分散と関心の分離という設計原則を理解しましょう。 |
| スロットリングとの違い | レートリミット（回数制限）とスロットリング（帯域制限や処理速度の調整）の違いについて問われることがあります。レートリミットは厳密な回数制限であるのに対し、スロットリングは負荷に応じて動的に制限を調整するより柔軟な手法として区別されることがあります。 |