トークン予算とBYOKを備えた本番AI SaaSの設計方法は？
課金モデルやユーザー階層によりますが、本番AI基盤には4つの要素が必須です：自動再接続を備えたSSEエッジストリーミング、PostgreSQLでのAES-256-GCM暗号化BYOK保管、API呼び出し前の2段階トランザクション予算仮押さえ、OpenAIとAnthropic間の自動フェイルオーバーです。supastackはこのアーキテクチャを標準装備し、ワークスペースごとの利用制限とリアルタイムコスト追跡を可能にしています。
Server-Sent Events (SSE) によるストリーミングとハートビート
商用AIアプリの構築において、従来の単一JSONレスポンスは適していません。LLMが回答全体を出力するまで数秒から数十秒かかるため、体感速度と離脱防止にはストリーミングが不可欠です。
HTTP/2上のServer-Sent Events (SSE) は最適な手段です。WebSocketに比べてファイアウォールを問題なく通過し、標準の認証ヘッダーが使え、ネットワーク切断時もブラウザが自動再接続します。Next.jsのエッジルートでTransformStreamを使いつつ、定期的に空のハートビート（: ping\n\n）を送出することで、ロードバランサーによる接続切断を防ぎます。
AES-256-GCMによる暗号化BYOK (Bring-Your-Own-Key) 保管庫
大口顧客やヘビーユーザーは、自身が契約しているOpenAIやAnthropicのAPIキーをそのまま使えるBYOK機能を求めることが多くあります。
顧客のAPIキーを平文で保存するのは重大なセキュリティリスクです。専用テーブルにて、AES-256-GCMと初期化ベクトル（IV）、認証タグを用いて暗号化して保存します。キーはAIモデル呼び出しの直前にサーバーメモリ上でのみ復号され、ログやクライアント側には一切露出させません。
2段階トークン予約による請求事故・過剰消費の防止
AI SaaS運営において最大の財務リスクは未払いによる損失です。バグによる無限ループや悪意あるスクレイピングによって、気付かないうちに高額なAPI利用料が発生する恐れがあります。
これを防ぐため、2段階のトークン予約プロトコルを採用します。LLM呼び出し前に最大想定トークン数を算出し、DBトランザクションで月間予算から枠を仮押さえします。上限を超える場合は即座にHTTP 429でリクエストを遮断します。ストリーミング完了後に実際のトークン消費数を確定し、余剰枠を解放します。
マルチプロバイダーフェイルオーバー：OpenAIとAnthropicの自動切り替え
単一のAIプロバイダーだけに依存すると、障害時のダウンタイムを回避できません。OpenAIやAnthropicはピーク時にレート制限（HTTP 429）や一時的なサーバーエラー（HTTP 503）を起こすことがあります。
本番アーキテクチャでは、モデルプロバイダーを統合インターフェースで抽象化します。gpt-4oへのリクエストが制限やタイムアウトに達した場合、指数バックオフで再試行しつつ、自動的にclaude-3-5-sonnetなどの代替モデルへフェイルオーバーします。ユーザーにエラーを見せることなく、高可用性を維持できます。