あなたの最新AI機能に潜む、静かなる「殺し屋」について考えたことがありますか？ スカイネットじゃないですよ。それよりもタチが悪い。請求書です。私が「仕事をした」チーム――仮に「イノセント株式会社」とでも呼びましょう――は、わずか2週間で最初のLLM機能をリリースしました。2週間ですよ！ ところが、その6週間後、ドカン。OpenAIから47,000ドルの請求書が届いたのです。それも無料ティアの製品で。痛い。彼らは非常に高価な教訓を得たわけです。
事後分析は、まさに「やってはいけないこと」の教科書でした。どうやら、あるテナントはリトライロジックを「遅い日のための提案」程度にしか考えておらず、別のテナントはモデルに「1万トークンで応答して」と気前よく要求し（なぜ月を目指さない？）、さらに別の、まあ、熱狂的なユーザーはAPIキーが事実上無制限であることを発見し、バッチ処理ワークロード全体をそれを通して実行することにしたのです。SDKの直接呼び出しだけで。レート制限なし。テナントごとの予算なし。コスト上限なし。監査ログなし。何もなし。共有キーのおかげで、純粋で一切の遠慮のないAPIの乱用です。
もしあなたのチームがLLM機能を同じように――まるで1999年で帯域幅が無料だった頃のように――リリースしているなら、この記事はあなたのためです。なぜなら、あの衝撃的な請求書が届く前に、ガードレールが必要だからです。これは車輪の再発明ではありません。クライアントとLLMプロバイダーの間に置かれる、Spring Bootで作られた機能的なマルチテナントゲートウェイを構築することなのです。あなたのAIパーティーの用心棒のようなものです。
APIキー、レート制限、トークン予算、キャッシング、監査ログを強制します。本番稼働前に必要な、あの退屈で大人びた作業のすべてです。CFOが悪夢を見る後ではなく、その前に行うべきことです。
問題：単一障害点
アプリケーションコードがOpenAIに直接呼び出しを行うと、プロバイダーにとってはすべてのリクエストが同じように見えます。彼らが見るのは、一つのAPIキー、一つのソース、一つの請求書です。満員のアパートの全員が同じ郵便受けを使っているようなものです。カオスです。
これは、以下のことができないことを意味します。
- テナントごとのキーのスコープ設定。 共有キー一つは、一つの悪いテナントが製品全体をダウンさせることを意味します。複数デプロイを連携させずにローテーションすることは不可能です。そんなこと、うまくいくわけがない。
- テナントごとの支出上限設定。 ゲートウェイなしでは、請求書が届いたときに月間予算を使い果たしたことを知るだけです。リアルタイムでスロットリングできません。サプライズ！
- 暴走した応答のブロック。 1万トークンを要求するバグのあるプロンプトが、そのまま実行されます。プロバイダーはそれが間違っていることを知りませんが、あなたは後で知るだけです。高くつく。
- 決定論的な呼び出しのキャッシュ。
temperature=0の同一リクエストが、毎回課金されます。共有キャッシュ層がないということは、何も共有されないことを意味します。 - 監査。 顧客が「AIが間違った情報を提供した」と文句を言っても、送信されたもの、返ってきたもの、使用されたモデルを再構築できません。データはOpenAIのログにありますが、それはクエリできません。探偵ごっこは大変でしょう。
ゲートウェイは標準的な解決策です。問題は、それが実際にどのような制御を強制するか、そしてそれをどのように強制するかです。
ゲートウェイの8段階防御システム
このゲートウェイは単なる通過点ではありません。8つのステージを持つ洗練されたパイプラインであり、各ステージが特定の懸念事項を強制します。あなたのAIリクエストのための、非常に組織化され、非常に厳格なTSAのチェックポイントと考えてください。
クライアント
POST /v1/chat/completions
Authorization: Bearer <テナントAPIキー>
ステージ1：認証 → ハッシュ化キー検索、テナント解決
ステージ2：入力正規化 → モデル/パラメータの正規化、バイト数カウント
ステージ3：ポリシー決定 → 許可/低下/ブロック
ステージ4：クォータ強制 → レート制限 + 予算チェック (Redis)
ステージ5：キャッシュ検索 → temperature=0 かつポリシー許可の場合のみ
ステージ6：プロバイダー呼び出し → タイムアウト制限、サーキットブレーカー
ステージ7：応答フィルタリング → プロバイダーメタデータの削除、PIIの赤字化
ステージ8：監査 + 集計 → PostgreSQLへの書き込み、カウンター増加
クライアントが応答を受け取る
アーキテクチャ自体は、3つのストレージコンポーネントに依存しています。永続的なもの――テナント、キー、ポリシー、監査ログ――のためのPostgreSQL。ホットパス――レート制限カウンター、セマフォ、おそらくキャッシュ――のためのRedis。そして、ロードバランサーの後ろに配置される、ステートレスなゲートウェイインスタンス。水平にスケールします。簡単です。
ポリシーの芸術：すべてのブロックが同等ではない
ゲートウェイの成否を分ける設計上の決定は、ポリシー施行の処理方法です。「制限を超えたものはすべてブロック」または「すべてログに記録するが、決してブロックしない」というどちらかにチームはデフォルトで陥りがちです。どちらも…間違っています。ひどく間違っています。
ゲートウェイは、テナントごと、ポリシーごとに設定可能な3つのモードをサポートしています。これが魔法が起こる場所です。
HARD — 制限に達したらリクエストを拒否します。理由コードとともに429（レート制限）または402（予算超過）を返します。これは従量課金制のテナント向けで、超過は許されません。例外なし。議論なし。
SOFT — リクエストを拒否するのではなく、低下させます。ゲートウェイはリクエストを書き換えます：より安価なモデルに切り替え、max_tokensを減らし、パラメータを絞り込みます。ユーザーは応答を受け取ります――ただし、プレミアム品質のものではありません。ファーストクラスの代わりにエコノミー航空券を手に入れるようなものです。ないよりはましです。
OBSERVE — リクエストを許可しますが、監査ログでフラグを付けます。これは、新しいポリシーをロールアウトする上で重要です。実際に影響を与えることなく、どのテナントがブロックまたは低下させられたであろうかを正確に確認できます。HARDまたはSOFTに切り替える前に、実際のトラフィックでポリシーを検証します。これは変更をロールアウトする唯一の健全な方法です。
OBSERVEモードは実用的です。ポリシーのしきい値が最初から正しく設定されることは決してありません。それらを設定し、2週間OBSERVEモードで実行し、ブロックされたであろうトラフィックを確認してから、HARDまたはSOFTに切り替えるのが、唯一安全なロールアウトパスです。
状態管理：データベースの背骨
永続的な状態には、5つのテーブルがあれば十分です。無駄がなく、効率的です。
tenants
id, name, status (ACTIVE/SUSPENDED), created_at
api_keys — キーはプレーンテキストでは決して保存されません。ありがたいことに。
id, tenant_id, key_hash, scopes, status,
created_at, last_used_at, rotated_at
policies — テナントごとに1行。ルールがここにあります。
tenant_id,
allowed_models (json),
max_prompt_tokens (integer),
max_completion_tokens (integer),
max_requests_per_minute (integer),
max_budget_usd (decimal),
// 他の設定についても同様...
usage_rollups — 日次合計用。大局を見る必要があるからです。
tenant_id, model, date, total_prompt_tokens, total_completion_tokens, total_cost_usd, total_requests
audit_logs — デバッグとコンプライアンスの要です。
id, tenant_id, key_id, request_timestamp, request_body_hash, response_status, response_body_hash, model_used, prompt_tokens, completion_tokens, cost_usd, latency_ms
真のMVP：オブザーバビリティ
顧客がAI出力の誤りを叫んだとき、データが必要です。言い訳ではありません。監査ログはフォレンジックな追跡を提供します。正確なリクエスト、使用されたモデル、受信した応答を再構築できます。これはデバッグのためだけではなく、コンプライアンスと紛争解決に不可欠です。ログなしで47,000ドルの請求書を説明しようと想像してみてください。見栄えは良くありません。
このゲートウェイは単なるコスト制御メカニズムではありません。運用上の必要不可欠なものです。LLM統合を、荒野の無法状態から、構造化され、管理可能で、――敢えて言いますが――収益性の高い事業へと変革します。今これを構築することは、後でその魂を打ち砕くような請求書の電話に対応することになるあなたを避けることを意味します。あなたのCFOはあなたに感謝するでしょう。開発者たちは安眠できるかもしれません。
