LLM APIゲートウェイが実キーをマスク

ゲートウェイは Cloudflare Worker であり、クライアントからの API リクエストをインターセプトして DeepSeek、OpenAI、または Anthropic にユーザーに代わってルーティングし、実際の API 認証情報をクライアント側から隠します。

クライアントは管理者が作成し D1 データベースに保存している不透明なトークンを使用して認証します。各トークンは厳密に 1 つのプロバイダーにスコープされ、3 つの制約を適用します：有効期限（Unix エポック以降のミリ秒として保存）、IP 許可リスト（Cloudflare の CF-Connecting-IP ヘッダーに対して確認）、および USD でのプロビジョニング予算。受信リクエストごとに、ゲートウェイはトークンを検索し、期限切れでないこと、許可された IP から発信されていること、および予算の全額をまだ使用していないことを確認します。すべてのチェックが成功すると、ゲートウェイは実際の上流 API キー（Worker のシークレットに保存）に置き換えてリクエストを転送します。チェックが失敗した場合、リクエストは拒否されます。

実装は 3 つのプロバイダーにわたる 5 つの API エンドポイントをサポートし、@er91 が 2026-07-14 に検証しています：DeepSeek の /deepseek/chat/completions および /deepseek/v1/messages エンドポイント、OpenAI の /openai/v1/responses エンドポイント、Anthropic の /anthropic/v1/messages エンドポイント。ゲートウェイは OpenCode、Claude Code CLI、Codex CLI を含むエージェント的コーディングツールと連携します。

デプロイメントには、新しい Cloudflare Worker の作成、提供されたスキーマを使用した D1 データベースのセットアップ、および Rust ツールチェーン（wasm32-unknown-unknown ターゲットをビルドするため）のインストールが必要です。管理者は Worker のシークレットを使用して上流 API キーを構成し、トークンテーブルに行を挿入してテストトークンを発行します。例えば、トークンは USD で最大 $1.00 の支出を許可し、指定された Unix タイムスタンプで期限切れになり、単一クライアント IP に制限されるか、または ["*"] を使用してすべての IP に開放される場合があります。

ゲートウェイには 2 つの記録された制限があります。第 1 に、予算強制は厳密ではありません。ゲートウェイはリクエスト開始時のみトークンが予算を超えたかどうかを確認するため、1 つの大規模なリクエストまたは複数の並行リクエストが拒否される前に予算を超える場合があります。第 2 に、コスト追跡は完全には信頼できません。クライアント接続または上流接続が急に失敗した場合、またはゲートウェイがコスト計算または永続化中にクラッシュした場合、リクエストは引き続き提供されますが、請求されない場合があります。著者はこれらのギャップに注意し、強化案（利用可能な予算に基づいて max_tokens を動的に設定する、または請求の失敗を検出するための監視を実装するなど）を提案していますが、ゲートウェイをシンプルに保ち、リクエストを変更しないようにするため、初期バージョンではこれらを実装しないことを選択しています。

このゲートウェイは実践的なセキュリティ上の懸念に対応しています。複数の開発者またはツールに API アクセスを配布するチームは、利便性と認証情報のセキュリティの間でジレンマに直面しています。実際の API キーを広く共有するとリーク のリスクが増加し、ユーザーまたはアプリケーションごとの支出監査と制限が困難になります。トークンベースのレイヤーを導入することで、ゲートウェイは認証情報配布の問題と支出管理の問題を分離します。

設計スコープは狭く意図的です。ゲートウェイは静的認証情報（API キーと長期間有効なアクセストークン）のみをサポートし、リフレッシュトークンフローはサポートしていません。ゲートウェイ内でトークンリフレッシュを実装すると、不安定な内部 API へのアクセスか、変更するトークン間でユーザーを確実に識別する方法が必要になりますが、どちらも 3 つのプロバイダーすべてで実行不可能です。ゲートウェイは Cloudflare Workers と D1 データベース向けに構築されており、デプロイメントは Cloudflare のインフラストラクチャに密結合されていることを意味します。

記録されている 2 つの制限（厳密でない予算強制と障害中の信頼できないコスト追跡）は、意図的なトレードオフを表しています。著者は意図的にリクエスト（例えば max_tokens を固定化）を変更せず、完全な監視と再試行ロジックを実装しないことを選択し、リクエストをそのまま転送するシンプルなゲートウェイを優先しています。厳密な支出制限または完全な請求精度に依存するユーザーは、外部監視を追加するか、リクエスト変更を自分で実装する必要があります。

まだコメントがありません。最初のコメントを投稿しましょう！