AI向けプロキシ

主要なAIプラットフォームはすべて、送信可能なリクエスト数を制限しています。OpenAI、Anthropic、Google、DeepSeek——いずれもアカウントごと、分単位、日単位で使用量に上限を設けています。プロダクト開発、自動化、大量データ処理を行う場合、1アカウント・1 IPではすぐに上限に達します。429エラーが発生し、キューにリクエストが滞留し、パイプライン全体が停止してしまいます。

AIプロキシサーバーは、お客様のアプリケーションとAIプロバイダーの間に位置します。リクエストをプロキシに送信すると、プロキシが複数のAPIキーに振り分け、それぞれ固有のIPアドレスを経由させます。プロバイダー側からは、1つの過負荷アカウントではなく、別々のユーザーとして認識されます。各キーが安全にリミット内に収まったまま、合計キャパシティが倍増します。実際のところ、適切に設定されたプロキシが追加するレイテンシはリクエストあたりわずか15〜30msで、バッチ処理では無視できるレベルであり、モデル自体の生成時間が500〜3,000msを占めるリアルタイムチャットアプリケーションでもほとんど気になりません。

これが機能するのは、AIプラットフォームがレート制限をIPではなくアカウントに紐付けているためです。ただし、IPパターンは監視されています。1つのアドレスが10個の異なるAPIキーを高速で切り替えると、不審なアクティビティとしてフラグが立ちます。キーごとに個別の専用プロキシを割り当てることで、すべてが自然に見えるようになります。また、フェイルオーバー戦略も必要です。各キーのエラー率を監視し、特定のIPが一貫して429や403を返し始めた場合、自動的にプールから外し、そのキーのトラフィックをバックアップIPにルーティングしてください。キーとIPのペアごとに60秒間隔でヘルスチェックを行うことで、問題が連鎖する前に検知できます。

実際のセットアップ例

ほとんどのAI APIプロキシセットアップは、プロバイダーに関係なく同じパターンに従います。軽量なプロキシサーバー（FastAPI、Node、Go——お使いのスタックに合わせて）を起動し、APIキーのプールを保持します。リクエストが来ると、プロキシは次に使用可能なキーを選択し、そのキーに割り当てられたIPを経由してリクエストをルーティングし、レスポンスを返します。あるキーが429（レート制限エラー）を受けた場合、プロキシは次のキーに切り替えます。以下は、FastAPIと httpx:

import httpx, itertoolsfrom fastapi import FastAPI, Request, Response

@app.post("/v1/chat/completions")async def proxy(request: Request): body = await request.json() slot = next(keys) async with httpx.AsyncClient(proxy=slot["proxy"]) as client: r = await client.post( "https://api.openai.com/v1/chat/completions", json=body, headers={"Authorization": f"Bearer {slot['api_key']}"}, ) # TODO: Add retry logic on 429 — try next key/IP before returning error to caller return Response(content=r.content, status_code=r.status_code)

注意：この最小限のサンプルでは簡略化のためitertools.cycleを使用していますが、429エラー時の自動リトライには対応していません。本番環境では、スロットルされたキーをスキップし、呼び出し元にエラーを返す前に次に利用可能なキーとIPのペアを試すリトライロジックを追加してください。現在、ほぼすべてのAIプロバイダーがOpenAI APIフォーマットに対応しているため、1つのプロキシで各AIプロバイダーが必要とするフォーマット変換を処理できます。適切なプロバイダーにルーティングすれば、アプリケーション側で違いを意識する必要はありません。プロバイダーごとにベースURLとキープールを切り替えるだけで、同じ20行のサーバーでOpenAI、Anthropic、Google、DeepSeekに対応できます。