フォームとボットのためのレート制限・キュー・アンチスパム
レート制限、キュー、アンチスパムは3層の防御です - これらがないと、フォームや Telegram/Discord ボットはすぐスパム・洪水・DoS の入り口になります。CAPTCHA だけでは足りません。頻度制限、非同期処理、内容と評判のフィルタが必要です。以下 - 余計な複雑さなしに、サイトとボット向けの実務的な構成を組み立てる方法です。
- レート制限 - 1つの IP・アカウント・トークンから、時間窓あたり何回まで許可するか
- キュー - 受付と重い処理（メール、CRM、LLM、webhook）のあいだのバッファ
- アンチスパム - honeypot、CAPTCHA、ヒューリスティック、ブロックリスト、内容検査
- 原則 - まず頻度を切り非同期で処理し、その後フィルタを強化する
- 目的 - 本物のリードを残し、ボットネット下でもサービスを落とさない
なぜフォームとボットが最初に狙われるか
公開エンドポイントは鍵のかかっていないドアです。スパムボットは /contact、/api/lead、ボット webhook を探し、フィッシング、SEO スパム、クレデンシャルスタッフィング、クーポン総当たりを大量送信します。制限がないとメール/SMS/LLM の請求が増え、CRM がゴミで埋まり、本物のリードがノイズに埋もれます。
典型的な症状：
- フォームへの POST 急増なのに売上コンバージョンがゼロ
- 別 IP から同一文面 - または同一レンジから「一見ユニーク」なゴミ
- メールや webhook のキューがプロバイダ上限にぶつかる
- メッセンジャーボットの応答が遅くなったりタイムアウトする
レート制限：何をどう制限するか
レート制限は「このエンドポイントを N 秒で何回叩いてよいか」に答えます。制限のキーが重要です。
| キー | 向いている場面 | リスク |
|---|---|---|
| IP | 匿名フォーム、認証なし webhook | NAT や社内網で善良ユーザーを切る |
| User / chat_id | 認証済み API とボット | ログイン前は守れない |
| API トークン / セッション | パートナー連携 | 盗まれたトークンで枠を使い切られる |
| Fingerprint + IP | 厳しいフォーム悪用対策 | 実装とユーザーへの説明が難しい |
実務的な窓：
- リードフォーム： IP あたり 10 分で成功送信 3-5 回、失敗（検証失敗、CAPTCHA fail）はより厳しく
- ログイン / OTP： 別枠で厳しめ - でないとブルートフォース
- ボットコマンド： ユーザーあたり数秒に重い応答（生成・検索）1 回；軽いコマンドは緩め
- プロセス / ワーカーの全体上限 - キーが違ってもスパイクを防ぐ
超過時：HTTP 429 と Retry-After；ボットでは短い「N 秒お待ちください」。内部しきい値は明かさない。発火ログを取る：制限が緩すぎる／厳しすぎるかが見えます。
キュー：受付と処理を分ける理由
フォームは同期で CRM 書き込み、PDF 生成、外部 API 呼び出しをすべきではありません。キュー（Redis、RabbitMQ、SQS、Celery、BullMQ）は検証直後にジョブを受け、すぐ「受付済み」を返します。
キューの効果：
- ピーク平滑化 - スパムやキャンペーンでも Web プロセスを落とさない
- 失敗時リトライ - リード消失の代わりに backoff 付き retry
- 優先度 - 有料注文を「PDF ダウンロード」より上に
- 分離 - LLM/メールワーカーをフロントと別にスケール
フォームの流れ：
- CSRF / origin、honeypot、フィールド基本検証
- レート制限
- DB にリードを
queuedで保存 - キューへ push
- ユーザーへ HTTP 200/202
- ワーカー：アンチスパムスコア → CRM / メール / 通知
ボットも同様：Telegram の更新は素早く受付；重い応答（RAG、画像、パース）はキューへ。でないと long polling / webhook の遅延が積み上がります。
アンチスパム：一項目ではなく層
reCAPTCHA 一つでは終わりません。多層防御を組んでください。
1. 入口の安いフィルタ
- Honeypot フィールド（人には隠れ、ボットが埋める）
- 最短入力時間（速すぎ = ボット）
Referer/Originと CSRF トークン確認- ボディサイズと添付数の上限
2. CAPTCHA とチャレンジ
チャレンジはシグナル時に出す：N 回試行後、怪しい IP、高スコア時。常時 CAPTCHA はコンバージョンを傷つける；狙った表示はほぼ傷つけない。
3. 内容と評判
- 文中のドメイン/URL ブロックリスト
- 反復テンプレと言語非依存スパムの検出
- メール検査（MX、使い捨てドメイン）
- ボット：リンクフィルタ、ストップワード、メディア上限
4. 行動シグナル
履歴：この端末からの送信が何件、購入や意味ある会話になったか。新規 IP が1分で何十件も「buy seo」なら、営業 CRM 直行ではなく隔離か人手レビューへ。
3層をつなぐ順番
本番の推奨順：
- 検証と安いアンチスパム（honeypot、サイズ、CSRF）
- IP + ユーザー/chat id のレート制限
- クライアント / メッセンジャーへの即応答
- ワーカーあたり同時ジョブ上限付きキュー
- ワーカーでの重いアンチスパムと連携（スコア、CRM、メール）
- 429 急増・拒否ジョブ増加のアラート
こうすると、本来レート制限で切るべきリクエストに CPU とプロバイダ費用を浪費しません。
導入チェックリスト
- [ ] フォームとボットでリスクに応じた別制限がある
- [ ] 送信メール/SMS/LLM に全体サーキットブレーカがある
- [ ] 429 とボット文言は人に分かり、回避方法は示さない
- [ ] キューに DLQ（デッドレター）と長さ監視がある
- [ ] 怪しいリードは黙って削除せず隔離へ
- [ ] レート制限・スパムスコアのログが完全な個人情報なしでも使える
- [ ] 負荷試験：
/contactに 100 RPS で何が起きるか
まとめ
レート制限は頻度を切り、キューはバックエンドと連携予算を守り、アンチスパムはゴミとリードを分けます。三つはセットで初めて効きます。制限だけでキューがないと同期ハンドラが落ち、キューだけでフィルタがないと CRM にスパムが広がり、フィルタだけで制限がないと DDoS 下で高コストになります。
フォームとボットの防御をスタックに合わせて設計したい場合（制限、キュー、隔離、監視）- ご連絡ください。サポートと改善の目安は料金ページにあります。
よくある質問
レート制限とアンチスパムの違いは？
レート制限は試行回数を数え、アンチスパムは内容と行動を評価します。 制限は「きれいな」リクエストの洪水も止め、アンチスパムは枠内に収まる稀で有害なスパムを拾います。
リードが少なくてもキューは必要？
外部 API・メール・LLM があるなら必要です。 低トラフィックでも同期 CRM タイムアウトはフォーム UX を壊します。キューはアイドル時は安く、ピークで助かります。
すべてのフォームに CAPTCHA は必須？
いいえ。 リスクに応じたチャレンジがよいです：エラー連続後、悪い IP 評判、異常スコア時。人への妨げを減らしつつボットは切れます。
ボットは chat_id と IP のどちらの制限？
両方です。 chat_id は一ユーザーの洪水を止め、IP/webhook トークンは偽更新とスキャンから守ります。グループは DM より厳しい制限が一般的です。
スパムっぽいリードはどうする？
隔離して人手確認または遅延配信し、痕跡なく捨てないでください。稀な本物リードを失い、攻撃パターンの変化も見えなくなります。
この記事の用語
CRM — Customer Relationship Management — 顧客関係管理
webhook — HTTP callback when an event happens — イベント発生時に飛ぶHTTPコールバック
LLM — Large Language Model — 大規模言語モデル
Celery — Python task queue for background jobs — Pythonのバックグラウンドジョブ用キュー
RAG — Retrieval-Augmented Generation — 検索拡張生成
DDoS — Distributed Denial of Service — 分散型サービス拒否攻撃