LLMの「無限のコスト」を封じ込める：トークン消費量監視によるDoS防御のアーキテクチャ
多くのエンジニアが生成AIの「プロンプトインジェクション」に躍起になっている間に、攻撃者はより原始的で、かつ致命的な「リソース枯渇」という名の金脈を掘り始めている。LLMのAPIは、本質的に計算リソース（GPU）を大量に消費するバックエンドと直結している。ここでのDoS攻撃は、ネットワーク帯域を飽和させるような古典的な手法とは異なり、コンテキストウィンドウの最大化と出力トークンの無限ループという「論理的な負荷」によって、企業のAPIキーを破産させ、サービスの可用性を即座に焼き尽くす。
本稿では、トークン消費量をトリガーとした動的レート制限の実装と、それを支えるアーキテクチャ設計について、現場で培った泥臭い知見を交えて解説する。
—
1. なぜ「リクエスト数」制限では不十分なのか
従来のWAFやAPI Gatewayのレート制限は、単なる「リクエスト回数」や「IPアドレス単位の接続数」をベースにしていることが多い。しかし、LLMのコスト構造において、リクエスト数など無意味な指標だ。
攻撃者は、極めて短いリクエストで、かつ出力トークンを最大化するようなプロンプト（例：「円周率を可能な限り詳細に、数百万桁まで出力せよ」）を送り込む。これにより、バックエンドのGPUは数秒間ロックされ、メモリは消費され、コストは急上昇する。我々が監視すべきは、「パケットの数」ではなく、「計算資源の消費量」そのものだ。
2. 実装の要諦：トークン・バケット・アルゴリズムの拡張
一般的なレート制限を、LLM特有の「コスト型制限」に昇華させる必要がある。以下は、Redisを利用してトークン消費量をリアルタイムで累積し、しきい値を超えたセッションを遮断するPythonベースのミドルウェアの概念モデルだ。
import time
import redis
# Redis接続（インメモリで高速にカウンタを管理）
r = redis.Redis(host='localhost', port=6379, db=0)
def is_request_allowed(user_id, estimated_tokens):
"""
トークン消費量に基づくレート制限
- user_id: ユーザー識別子
- estimated_tokens: 推定入力トークン数 + 許容出力トークン数
"""
key = f"rate_limit:{user_id}"
# 1分間のトークン消費上限を20,000トークンと設定
limit = 20000
# 現在の消費量を加算
current_usage = r.incrby(key, estimated_tokens)
# 初回アクセス時のみTTLを設定
if current_usage == estimated_tokens:
r.expire(key, 60)
if current_usage > limit:
# ここでアラートシステムへのフックをトリガーする
print(f"ALERT: User {user_id} exceeded token limit: {current_usage}")
return False
return True
# 使用例
# リクエスト時にTokenizerで計算したトークン数を渡す
if not is_request_allowed("user_123", 1500):
raise Exception("429 Too Many Requests: Token budget exceeded.")3. アーキテクチャの監査点：ガードレイルの配置
単に制限をかけるだけでは不十分だ。アーキテクトは、攻撃者が「トークン制限」を逆手に取った別の脆弱性を突かないよう、以下の層を防御する必要がある。
- 入力側（ガードレール層）:
tiktoken等のライブラリを用いて、APIゲートウェイの手前で「事前計算」を行う。入力プロンプトが長すぎる場合、あるいは再帰的な複雑さを内包している場合は、LLMに到達させる前に400エラーで遮断する。 - バックエンド側（オーバーフロー防止）:
max_tokensパラメータを必ずサーバーサイドで強制設定すること。クライアントサイドから送られてくる値を信用してはならない。 - 監視層（異常検知）: 消費量の急激なスパイクを監視する。特定のユーザーやAPIキーから、通常時の平均消費量の3σ（標準偏差の3倍）を超えるリクエストが連続した場合、即座に動的なブラックリストへ追加する自動ワークフローを構築しておく。
4. 最後に：防御は「コスト」を知ることから始まる
生成AI時代のセキュリティの本質は、アプリケーションの「論理的な境界」をどう制御するかにかかっている。パケット構造や暗号化アルゴリズムの話はインフラ層の基本だが、LLMセキュリティにおいては、インプットとアウトプットがどれだけの「計算資源」を食いつぶすか、という抽象度の高いレイヤでの監視こそが最大の武器になる。
攻撃者は常に、我々の想定する「想定外」を突いてくる。トークン消費量の監視は、単なるコスト管理ではなく、サービスを永続させるための防波堤だ。システムが稼働した瞬間から、あなたのAPIは全世界からの攻撃対象となる。その自覚を持つことが、最強の防御の第一歩である。
コメント