チャットボットのレート制限｜429対策と運用

チャットボット レート制限を設計し、429と混雑時の停止を利用者へ正確に案内する方法を整理します。

対策の要点は、429を無条件に再試行することではありません。LLM API、検索、データベース、外部連携ごとに上限と失敗原因を確認し、再試行できるエラーだけを切り分けます。そのうえで、上限付きのキュー、ジッター付きバックオフ、再試行予算、公平な処理枠、状態表示、有人対応への切替を一つの運用として設計します。

具体的な制限値やヘッダーの仕様は、採用するAPI、モデル、契約、利用状況によって異なります。固定値を流用せず、管理画面、契約書、公開時点の公式資料を確認してください。

チャットボットのレート制限は依存先と単位を分けて把握する

最初に、回答を返すまでに呼び出す依存先を一覧にします。LLM APIだけでなく、検索、ベクトル検索、データベース、認証、CRM、予約システムなども対象です。利用者には一つのチャット画面に見えていても、内部では複数のサービスを順番に呼び出している場合があります。一つでも上限へ達すれば、回答全体が止まる可能性があります。

依存先ごとに、リクエスト数、トークン数、同時実行数、日次クォータ、テナント別上限を確認します。LLM APIでは、一定時間内のリクエスト数を示すRPMと、入力・出力を含むトークン量を示すTPMが別に管理される場合があります。短時間に質問が集中すればRPMへ影響し、商品仕様書を貼り付けるような長文質問が続けば、件数が少なくてもTPMへ達する可能性があります。

棚卸しでは、現在値だけでなく確認日と確認元も残します。上限は変更される場合があるため、「以前はこの値だった」という記憶だけで運用しないことが重要です。APIキーの権限、保管方法、利用上限も併せて整理する場合は、チャットボットのAPIキー管理を確認してください。

429の原因を分類して再試行できる場合だけを切り分ける

HTTP 429が返ったという事実だけでは、同じ処理を待って再送すべきか判断できません。採用APIによっては、一時的なレート超過だけでなく、クォータや請求、使用量に関する問題でも429が返ることがあります。レスポンス本文、エラーコード、ヘッダー、管理画面の使用状況、同時刻の障害情報を組み合わせて原因を分類します。

再試行候補にするのは、待機によって解消する見込みがあり、同じ処理を再実行しても安全な場合です。クォータ不足や認証不備は、短時間で何度再送しても解消しません。むしろ呼び出し回数とログだけが増え、原因調査を難しくします。分類できないエラーも無期限には再試行せず、打切り条件へ進めます。

分類ルールには、参照するレスポンス項目、通知先、処理の停止条件、再開を判断する担当者を記載します。「429なら再試行」の一行で済ませず、運用担当者が同じ判断を再現できる状態にしてください。

キューとバックプレッシャーでリクエスト集中を平準化する

受付と外部APIへの送出を直接つなぐと、営業時間の開始直後などに複数店舗から問い合わせが集中した際、受け付けた件数だけAPI呼び出しが増えます。キューを間に置き、受付量と処理量を分けることで、依存先の上限に合わせて送出できます。

ただし、キューを置くだけでは不十分です。キュー長、最古の待機時間、利用者または会話ごとの保留件数に上限を設けます。上限がなければ、処理できない要求が積み上がり、復旧しても長時間解消しません。待機が許容範囲を超えた場合は、新規受付を抑制し、利用者へ受付できないことと次の選択肢を示します。これがバックプレッシャーです。

受付状態は、少なくとも「未受付」「受付済み」「処理中」「受付停止」に分けます。同じ利用者が送信ボタンを連打した場合は、同じ内容を別々の要求として積み上げないよう、処理ID、会話ID、入力内容、送信時刻を確認します。すでに受け付けた要求があるなら、その状態を返し、新規処理を増やさない設計が必要です。

キューに入った要求を先着順だけで処理すると、一つのテナントによる大量送信が後続を占有することがあります。公平性は後から加える補助機能ではなく、キューの取得順序と同時に設計します。

LLM APIの再試行はRetry-Afterと再試行予算で制御する

採用APIがRetry-Afterを返す場合は、その仕様を確認したうえで待機時間の判断に利用します。Retry-Afterが提供されない場合は、待機時間を試行ごとに延ばす指数バックオフを検討します。ただし、全処理が同じ間隔で再試行すると、待機終了時に要求が再集中します。一定の揺らぎを加えるジッターによって、再送時刻を分散させます。

再試行回数だけを決めても、全体負荷は管理できません。一つの要求に対する最大試行回数、最初の受付からの最大経過時間、システム全体または依存先ごとの再試行量を予算として定めます。いずれかを使い切ったら再試行を止め、失敗状態を確定します。上限値は記事の例を流用せず、採用APIの制限、業務上許容できる待機時間、通常時の処理量を基に決めてください。

SDKが自動再試行を行う場合、アプリ側の処理と重複しないか確認します。たとえばSDKが内部で再送し、その外側でアプリも同じ要求を再送すると、運用担当者が一回の再試行だと考えていても、実際のAPI呼び出しは複数回になります。再試行の責任箇所を一つに集約するか、SDKの試行回数を含めて全体予算を管理します。

再送が成功しても、利用者へ回答を二重に返してはいけません。処理IDや冪等性キーを利用できる依存先では、その仕様に従います。利用できない場合も、会話IDと要求IDに対する最終結果を記録し、完了済みの処理を再度確定しないようにします。外部システムへの書き込みを伴う処理では、送信前に「同じ要求が再実行されても結果が重複しないか」を確認してください。

テナント・利用者・会話単位で処理枠を公平に割り当てる

全体のレート制限だけを守っていても、一つの店舗や利用者が処理枠を使い切れば、ほかの利用者が待たされます。全体上限の内側に、テナント別、利用者別、会話別の受付枠と同時実行枠を設けます。

営業時間の開始直後に一店舗から問い合わせが集中する場面では、その店舗の要求だけで共有キューを埋めないようにします。テナントごとの保留上限を適用し、空いている処理枠をほかの店舗へ割り当てます。一方で、すべてを均等にすると業務上の優先度を反映できない場合があります。優先度や重みを付けるなら、対象、理由、適用時間、見直し担当者を運用ルールへ残します。

会話単位の上限も必要です。同じ会話から追加質問が連続した場合、前の回答が完了する前に後続要求を処理すると、回答順が逆転したり、古い文脈を参照したりするおそれがあります。一会話内では処理順を管理し、保留件数の上限を超えた入力には、先行処理の完了を待つよう案内します。

公平性を確認するときは、平均待機時間だけを見ません。テナント別のキュー長、最古待機時間、打切り件数、処理成功率を比較し、一部だけが継続的に不利になっていないか確認します。優先枠を設けた場合も、通常枠が完全に停止しないことを試験します。

待機・再試行・失敗の状態を利用者へ正確に表示する

混雑時に画面が変化しないと、利用者は送信できたか判断できず、同じ質問を再送しやすくなります。「受付前」「受付済み」「処理中」「再試行中」「打切り済み」を区別し、現在の状態に合う案内を表示します。

待ち時間を確定できない場合は、「まもなく完了します」と断定しません。処理順や依存先の回復状況によって変動することを示し、待機を続ける、取り消す、有人窓口へ進むといった選択肢を案内します。待機時間や停止時の扱いを契約・運用基準へ落とし込む際は、チャットボットのSLAと契約確認も参照できます。

再試行予算を使い切った場合、または業務上の期限を超える場合は、有人対応へ切り替えます。問い合わせ番号、入力内容、受付時刻、実施済みの処理、最終結果を引き継げるようにします。利用者に同じ説明を最初から求めないためです。通知先や一次切り分けを具体化するには、チャットボット障害時のトリアージルールを確認してください。

依存先別の監視で詰まりと再試行増幅を検知する

監視はチャットボット全体の成功・失敗だけでなく、依存先ごとに分けます。LLM API、検索、データベース、外部連携について、429件数、応答時間、タイムアウト、キュー長、最古待機時間、再試行回数、打切り件数を記録します。どこで処理が詰まったか分からなければ、必要のない依存先まで再試行や増枠の対象にしてしまいます。

元の要求数と実際のAPI呼び出し数も比較します。利用者からの一要求に対して呼び出し数が急増している場合は、SDKとアプリの二重再試行、タイムアウト後の重複送信、キューからの重複取得を疑います。平均値だけでなく、依存先、テナント、時間帯、試行回数別に確認できるようにしてください。

ログには、処理ID、会話ID、テナント、依存先、受付時刻、各試行の開始時刻、エラー分類、待機理由、最終結果を関連付けます。APIキーや入力内容を無条件に記録するのではなく、調査に必要な項目と閲覧権限、保存期間を決めます。証跡の設計は、チャットボットの監査ログ設計と併せて確認できます。

バースト・長文・障害・復旧時の負荷試験で完了を判断する

通常時に一件ずつ質問して成功するだけでは、レート制限対策を確認できません。本番前と設定変更後には、短時間の同時送信、長文によるTPMへの負荷、依存先が継続して429を返す状態、タイムアウト、障害復旧後の送出を分けて試験します。

短時間バーストの試験では、キュー上限が守られ、受付済みと受付停止が正しく表示されることを確認します。長文試験では、要求件数だけではなく、入力と出力のトークン傾向を観察します。継続的な429では、再試行が予算内で止まり、クォータや認証の問題を無期限に再送しないことを確認します。

復旧試験は特に重要です。依存先が回復した直後に、待機中のキューを一斉送信すると、再び上限へ達して停止する可能性があります。復旧後は送出速度を段階的に上げ、現在の429件数、応答時間、キューの減少を確認しながら通常状態へ戻します。

試験結果には、入力条件、依存先の状態、期待結果、実際の結果、判定、確認者を残します。リリース判定へ組み込む手順は、チャットボットの公開前テストケースで整理できます。

チャットボットのレート制限対策でよくある質問