AI ゲートウェイ: ネイティブ プロバイダーと OpenAI 互換プロバイダー

AI ゲートウェイは、アプリケーション側で各 SDK 統合をコーディングするのではなく、外部 LLM プロバイダーへの呼び出しを単一のインターフェイスの背後に集中させます。 API キーはサーバー側に残り、クライアントに公開されることはありません。ゲートウェイは、さまざまな応答形式を持つプロバイダーに加えて、再試行、フェイルオーバー、コスト計算の共通レイヤーを追加します。

Aurabaseのような Postgres バックエンドでは、この選択は直接的な結果をもたらします。同じゲートウェイがアプリケーション チャット、NL2SQL (SQL への自然言語変換)、および RAG (pgvector ベクトル検索) を強化します。プロバイダーの統合が不十分だと、1 つの機能だけではなく、3 つの機能すべてが一度に低下します。これにより、ネイティブ/互換性の区別が実装の詳細以上のものになります。

ネイティブ クライアントは、プロバイダーの API の実際の形式 (要求構造、応答形式、このプロバイダーに固有の使用フィールド) をエンコードします。これは、「メッセージ」 API が OpenAI や Gemini の API に似ていない Anthropic の場合です。Gemini の推論トークン (thoughtsTokenCount) のカウントは、すでに出力カウンターに含まれているのではなく、出力カウンターに追加されています。

OpenAI 互換エンドポイントは、既存の OpenAI クライアントを再利用し、ベース URL のみを変更します。これが機能するのは、サードパーティ プロバイダー (Mistral、Scaleway AI、Ollama) が OpenAI の API コントラクトを模倣することを選択したためですが、多くの場合、逸脱が伴います。つまり、別個の推論トークン フィールドがなく、エラーの正確な形式が保証されていません。模倣が終わると互換性も終わります。

aura-ai のプロバイダーを整理するファイルには、あいまいさの余地がありません。ネイティブ プロバイダーごとに 1 つずつ、合計 3 つのモジュールがあり、他には何も宣言されていません。

pub mod anthropic;
pub mod gemini;
pub mod openai;

各モジュールは ChatProvider トレイト (完了、ストリーミング、モデル名) を実装します。そのうちの 2 つ、OpenAI と Gemini は、さらに EmbeddingProviderを実装します。 Anthropic にはそれは必要ありません。Claude は、Aurabase コードの欠点ではなく、Anthropic 自体の製品事実であるベンダー側の埋め込み API を公開していません。

Mistral、Scaleway AI、または Ollama の構成には新しいモジュールは必要ありません。同じ OPENAI_BASE_URL 変数が openai.rs クライアントを別の互換性のあるエンドポイントにリダイレクトします。これは構成の切り替えであり、開発ではありません。

# デフォルトのプロバイダー: ネイティブ OpenAI
OPENAI_API_KEY=sk-...

# OpenAI 互換プロバイダー (Mistral、Scaleway AI、Ollama...) に切り替える
OPENAI_API_KEY=<clé du fournisseur choisi>
OPENAI_BASE_URL=<URL de base compatible OpenAI du fournisseur>
# 例:ミストラル: https://api.mistral.ai/v1

それに応じて行動も変わります。 HTTP エラーは、分類がプロバイダー固有の解析ではなく HTTP トランスポート レベルで行われるため、同じメカニズム (429 → レート制限、5xx → 一時的および再試行可能、404 → 不明なモデル) によって分類されたままになります。これに従わないもの: 専用の Gemini クライアントに固有の推論トークンの正確なカウント。

Aurabase ゲートウェイは、3 つのネイティブ クライアントに加えて 3 つの復元メカニズムを追加します。ペア (プロジェクト、プロバイダー) ごとのサーキット ブレーカーは、繰り返し失敗するプロバイダーへの呼び出しを切断し、プローブ トークンをセミオープン状態にしてから再度オープンします。ジッターを伴う指数バックオフ再試行は、外部乱数ライブラリに依存せずに、一時的なエラー (タイムアウト、5xx、429) を再開します。

各プロバイダーは、応答を停止する理由にも異なる名前を付けています。同じ現実 (切り捨て) に対して、OpenAI では length、Gemini では MAX_TOKENS、Anthropic では max_tokens です。コードは、これら 3 つの語彙を共通のセット (stop、 length、 content_filter、 tool_use、 other) に向かって正規化します。この標準化がなければ、マルチベンダーのクライアントは、切り捨てられた応答を検出するために 3 つの語彙をすべて知っている必要があります。

請求も同様のリスクを示します。 OpenAI と Anthropic では、モデルの推論は、チャージされる出力トークンのカウンターにすでに含まれています。 Gemini では、 thoughtsTokenCount が candidatesTokenCountに個別に追加されます。これを無視すると、クエリの実際のコストが過小評価されます。汎用の OpenAI 互換アダプターは、Gemini のネイティブ応答形式に特有のこの特殊性を知る理由がありません。

市場は、AI ゲートウェイが孤立したマーケティング上の議論ではなく、期待されるレンガになったことを確認しています。 Neon は、「AI ゲートウェイ」と「AI エージェント用バックエンド」という 2 つの専用製品ページを公開しており、どちらも Postgres 開発者向けです。 LiteLLM は、OpenAI に近い形式の背後にある多数のプロバイダーへの呼び出しを統合するためのリファレンス オープン ソース プロジェクトとしての地位を確立しています。 Braintrust は、このテーマに関する独自の比較を公開しています。これは、このカテゴリが専用の編集コンテンツを正当化するのに十分な強さを持っていることを示しています。

これらのプレーヤーは、アプリケーション コードと特定の LLM プロバイダーの間の結合を減らすという実際のニーズに応えます。 Aurabase との違いは統合です。ゲートウェイはバックエンドの隣に存在しません。同じ Postgres データベース上で、NL2SQL および RAG と同じサービスを共有します。逆の妥協案も存在します。LiteLLM のような専用プロキシは、通常、アプリケーション バックエンドに統合されたゲートウェイよりも多くのプロバイダーをカバーします。

Aurabase のようなネイティブ ゲートウェイは、バックエンドと AI を同じシステム内に維持する必要がある場合に大きな利点があります。NL2SQL、RAG、およびアプリケーション チャットは、追加のサービスを運用することなく、同じ復元ポリシーと同じ請求を共有します。

逆の妥協案も存在します。非常に多数のプロバイダーをカバーすることを優先する場合、またはゲートウェイが Postgres プロジェクトだけでなく複数の独立したバックエンドにサービスを提供する必要がある場合、多くの場合、LiteLLM のような一般的なプロキシが正しい選択となります。 Aurabase は、この範囲の広さで競合しようとはしていません。重要なのは、バックエンドの残りの部分と統合された 3 つの主要プロバイダーにわたる深さです。

この統合により、Supabase が選択した外部コネクタを使用するアプローチと比較して NL2SQL の使用がどのように具体的に変わるかを理解するには、 Supabase はネイティブ NL2SQL ではなくコネクタに依存するを参照してください。

価値判断を行わずに 2 つのアプローチを実際に区別する基準の概要: それぞれが異なるニーズに対応します。

具体的なケースでこのゲートウェイが動作していることを確認するには、Postgres の NL2SQL チュートリアル を参照してください。 Aurabase のネイティブ AI 機能の詳細については、ネイティブ AIページを参照してください。