この記事は、AI製品のセキュリティ実装記録シリーズの1本である。受託で開発した相談チャットやシミュレーターなど、複数の体験デモを1つの基盤にまとめて外部公開するにあたり、送信元を区別する仕組みが無ければ何が起きうるかと、2026年9月に敷いたレート制限の設計を記録する。
この記事で分かること
- 複数のデモを1か所にまとめて公開する構成で、何が起きうるか
- 2026年9月にどのようなレート制限を敷いたか
この記事で分からないこと(正直に書く)
- 公開後に実際にこの上限へ到達したリクエストがあったかどうか(一次資料には設計値の記載のみで、到達実績までの記載はない)
何を作っていたか
受託で開発した相談チャットやシミュレーターなど、複数の体験デモをまとめて外部から触れる形にした基盤を、2026年9月に本番公開した。営業や紹介の場で、実際に動くものをその場で触ってもらえるようにする狙いである(出所: 自社の運用記録、確認日2026-09-06)。
どこに穴があったか
複数のデモを1つの基盤にまとめて外部公開する場合、送信元を区別する仕組みが無いと、1つのクライアントが短時間に大量のリクエストを送るだけで、基盤全体の処理能力や外部の生成AI呼び出しの枠が占有されてしまう。結果として、他の閲覧者がデモを試せなくなったり、想定していない呼び出し量によってコストが跳ねたりする可能性がある。これは今回の基盤に限らず、公開エンドポイントを新設する際に一般的に起こりうるリスクである。
どう直したか(2026年9月)
KVストアを使い、送信元IPアドレスごとに1時間あたりの上限と、基盤全体で1日あたりの上限という二段構えの制限を設けたうえで本番公開した。具体的にはIPアドレス単位で30回/時、基盤全体で3,000回/日という上限である(出所: 自社の運用記録、確認日2026-09-06)。IP単位の上限で1クライアントによる占有を防ぎ、全体の上限で想定外の呼び出し量そのものに歯止めをかける、という二段構えにしている。
OWASPの「Denial of Service Cheat Sheet」は、レート制限の基準として送信元IPアドレスやIPのブロックリスト、地理的位置などを挙げている。今回のIPアドレス単位の制限は、この基準のうち最も基本的な形に当たる(出所: OWASP Cheat Sheet Series「Denial of Service Cheat Sheet」https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html、確認日2026-09-06)。
同じ穴を持つ製品の見分け方
公開されているデモや問い合わせフォームに、短時間で連続してリクエストを送ってみて、途中で拒否される、あるいはエラーが返る閾値があるかを確認するのが分かりやすい方法である。何百回送っても普通に応答が返り続けるようであれば、レート制限が入っていない可能性がある。複数の機能を1つの基盤にまとめて公開している場合は、1つの機能への集中アクセスが他の機能にも影響しないか、基盤全体としての上限があるかも確認材料になる。
認証コードまわりの不備はログイン認証コードの記事と試行回数を制限した記事、オリジンの絞り込みはCORSの許可リストの記事、社内向けの監査ログ設計は社内文書RAGの監査ログ設計の記事を参照してほしい。
自社製品の公開基盤の設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. 複数のデモを1つの基盤にまとめると、なぜレート制限が必要になるのか
送信元を区別する仕組みが無いと、1つのクライアントが短時間に大量のリクエストを送るだけで基盤全体の処理能力が占有され、他の閲覧者が使えなくなったり、想定外の呼び出し量でコストが跳ねたりする可能性があるためである。
Q2. 具体的にどのようなレート制限を敷いたのか
IPアドレス単位で1時間あたり30回、基盤全体で1日あたり3,000回という二段構えの上限を設けた。
Q3. なぜIP単位と基盤全体の両方に上限を設けたのか
IP単位の上限は1クライアントによる占有を防ぐためのもので、基盤全体の上限は想定外の呼び出し量そのものに歯止めをかけるためのものである。役割が異なるため、両方を組み合わせている。
Q4. この上限は具体的にいつから運用しているのか
複数の体験デモをまとめて外部公開した2026年9月の本番公開時点から、この二段構えのレート制限を組み込んだ状態で運用している。