レート制限とは？アプリ作成者のための平易なガイド

レート制限とは、一定時間内に誰かがシステムへ送れるリクエストの数を制限するルールです。例えば、1分あたりログイン試行5回、または1時間あたりAPI呼び出し100回といった具合です。上限に達すると、時間枠がリセットされるまで以降のリクエストは拒否されます（通常はエラーコード 429 Too Many Requests が返ります）。アプリを悪用から守り、1人の重い利用者がほかの全員の速度を落とすことを防ぎ、コストが際限なく増えるのを止める仕組みです。

レート制限には2つの側面があります。あなたが呼び出すサービスはあなたに制限をかけ、あなた自身のアプリはその利用者に制限をかけるべきです。

AIでアプリを作るときにレート制限が重要な理由

AIで作ったアプリは、AIモデル、メール、SMS、地図など、有料のサービスにつながることが多く、呼び出しのたびに費用がかかります。そのためレート制限は、セキュリティ機能であると同時に、予算管理の機能でもあります。

• 費用の管理。 アプリに「AIに尋ねる」入力欄があり制限がなければ、ボットが一晩で何千ものリクエストを送ることがあります。そのリクエストのすべてに料金がかかります。
• セキュリティ。 ログインフォームに制限がなければ、攻撃者はアカウントに対して何千ものパスワードを試せます。1分あたり数回に制限すれば、現実的に難しくなります。
• オンライン状態の維持。 1つの誤動作したスクリプトでも、場合によっては自分のコードが無限ループに陥るだけで、データベースに過負荷がかかり、アプリ全体が止まることがあります。
• 外部サービスの制限を尊重すること。 アプリが外部APIを頻繁に呼び出しすぎると、あなたのほうが429エラーを受け取り、利用者の機能が壊れます。

AIビルダーは頼まれたものを作ります。制限について言及しなければ、多くの場合そこは作られません。

日常の例え

コーヒーショップの「おかわり無料」のルールを想像してください。「お客様1名、1回の来店につきおかわり1杯まで」というルールです。

• 誰かがコーヒーを楽しむことを妨げるわけではありません。
• ある1人が一日中カウンターに立ち、オフィス全員分のポットに何度も注ぎ続けることを防ぎます。
• 4杯目を頼まれたら、店員は丁寧に「今はできません」と言います。それが 429 です。

良いレート制限は、普通のお客様には見えず、普通でないことをする人にだけ気づかれるものです。

レート制限の仕組み

レート制限には3つの要素が必要です。

リクエストが届くと、アプリはその「誰」の回数を確認します。上限以下なら、リクエストは通り、回数が増えます。上限を超えていれば、リクエストは拒否されます。

数え方にはいくつかの一般的な方法があります。

カウントは、速くて共有可能な場所に保存する必要があります。小さなサーバー1台ならメモリで足ります。アプリが複数のマシンで動くようになると、カウンターは通常RedisなどのKVストアやデータベースに置かれます。そうしないと各マシンが別々に数えてしまい、実際の上限が数倍に膨らんでしまいます。

制限されたときの応答

適切に作られたAPIは、上限を超えたリクエストに対して次のように応答します。

• ステータスコード 429 Too Many Requests。
• 多くの場合、Retry-After ヘッダー。何秒待つべきかが示されます。
• 場合によっては、上限と、この時間枠で残りどれだけリクエストできるかを示すヘッダー（名前はプロバイダーによって異なります）。

アプリは429を受けたら、待ってから再試行すべきです。理想的には指数バックオフを使い、失敗するたびに待ち時間を長くします（1秒、次に2秒、次に4秒）。サービスに連打しないようにするためです。

具体例：AIライティングアシスタント

利用者がテキストを貼り付けると、AIが書き直しを返すアプリを作ったとします。

制限がない場合： 誰かがスクリプトを書き、一晩で20,000回のリクエストを送ります。AIプロバイダーの請求額が跳ね上がり、あなたのアカウントはプロバイダー側のレート制限に達します。その結果、本物の利用者は午前中ずっとエラーを見ることになります。

適切な制限がある場合：

1. サインイン済みのユーザーごと： 無料プランでは1時間あたり30回の書き直し、有料プランでは300回。上限に達すると、利用者には「この1時間の上限に達しました。12分後にもう一度お試しいただくか、アップグレードしてください」と表示されます。
2. サインインフォームのIPアドレスごと： 1時間あたりサインアップ5回。ユーザーごとの制限を回避するために、ボットが無料アカウントを大量に作ることを防ぎます。
3. AIプロバイダーの管理画面で設定する利用上限。 他がすべて失敗した場合の最後の防衛線です。
4. プロバイダー側の制限への対応。 AIプロバイダーが429を返した場合、サーバーは待ってから1〜2回再試行し、それでもだめなら「混雑しています。もう一度お試しください」というわかりやすいメッセージを表示します。

制限はサーバー側で確認されるべきです。ブラウザだけにある制限、例えばボタンを30回クリックした後に無効化する仕組みは、APIを直接呼び出せば誰でも回避できます。

主な用語

よくある誤解

• 「レート制限は大きなアプリだけのもの」。 小さなアプリも標的になります。ボットは、開いているフォームやAIのエンドポイントを求めてインターネット全体を走査しているからです。悪用のコストは、アプリの規模に関係ありません。
• 「ボタンを隠せば十分」。 ブラウザ側の制限は親切心によるものであり、保護にはなりません。本当の制限はサーバーで強制しなければなりません。
• 「IPごとの制限は常に公平」。 1つのIPアドレスを、オフィス、学校、モバイル回線などの多くの人が共有していることがあります。サインインしたあとは、ユーザーごとの制限のほうが公平です。
• 「429は、サービスが壊れていることを意味する」。 それは、あなたが呼び出しすぎていることを意味します。コードにループがないか確認し、頻繁には変わらない結果はキャッシュしましょう。キャッシュとは何かをご覧ください。
• 「レート制限があれば利用上限は要らない」。 両方を使ってください。アプリ内の制限にもバグはありえます。プロバイダーの利用上限があなたの最後の安全網です。

AIビルダーに頼むこと

• 「ログイン、サインアップ、パスワードリセット、AIのエンドポイントに、サーバー側のレート制限を追加してください。妥当な上限を提案してください。」
• 「サインインした各ユーザーのAIリクエストを1時間あたり[N]回に制限し、上限に達したら待ち時間を明確に表示してください。」
• 「外部APIが429を返したら、最大3回まで指数バックオフで再試行し、それでもだめならわかりやすいエラーを表示してください。」
• 「レート制限のカウンターはどこに保存されていますか？ アプリが複数のマシンで動いてもちゃんと機能しますか？」
• 「利用者またはIPが制限に達したときは必ず記録し、悪用を見つけられるようにしてください。」
• 「このアプリはどの外部サービスを呼び出していて、それぞれのレート制限はどれくらいですか？」

Mythexでのレート制限

Mythexのドキュメントは、AI機能についてはっきり述べています。作成したアプリのレート制限、安全対策、費用管理は、あなた自身が設計するものです。詳しくはAIアプリの作成をご覧ください。機能を依頼するのと同じメッセージで、制限も依頼するとよいでしょう。Proプランでは、トラフィックが多いときに公開サービスを最大3台のマシンで動かせます（ホスティングの上限を参照）。そのため、1台のサーバーのメモリではなく、データベースに保存されるカウンターを依頼してください。

関連する記事として、APIとは何か、LLM APIの使い方、AIで作ったアプリのセキュリティチェックリストもあわせてご覧ください。

よくある質問