SemanticGuard icon

SemanticGuard

SemanticGuardは、OpenAI、Anthropic、GoogleのLLM API向けの自己検証型キャッシュを備えたAI gatewayです。節約効果の測定、意味的に近い応答のキャッシュ、キャッシュ障害時のリクエスト継続を支援します。

SemanticGuard

SemanticGuardとは?

SemanticGuardは、LLM API向けのAI gatewayであり、自己検証型キャッシュです。OpenAI、Anthropic、Googleなどのプロバイダーのリクエスト経路に入り、レスポンスをキャッシュしながら、多層検証でキャッシュ済みの回答がまだ正しいかを確認します。

この製品は、ユーザーにプロンプトの変更やキャッシュオブジェクトの手動管理を強いることなく、LLM API費用の削減を目的としています。また、キャッシュ有効化前に想定削減額を測定するShadow Modeを備え、キャッシュが利用できない場合でもリクエストを上流プロバイダーへ継続するfail-open設計をサポートします。

主な機能

  • AI SDKのfetch: withSemanticGuard()による1行のSDK統合で、アプリケーションロジックを書き直さずにキャッシュを追加可能。
  • 1リクエストごとのコスト、想定削減額、ヒット種別、どのトラフィックがキャッシュ対象になるかを、キャッシュ応答を返す前に示すShadow Mode計測。
  • 多層検証による自己検証型のキャッシュヒット。サンプリングされたヒットはAIでも正当性を判定し、失敗はフラグ付け。
  • OpenAI、Anthropic、Googleに加え、Azure、Bedrock、Mistralなど掲載済みの他プロバイダーまで横断する対応。
  • 意味的な一致に最適化されたキャッシュ動作により、名前、日付、IDが異なっても、実質的に同じ回答ならヒット可能。
  • fail-openのリクエスト処理により、キャッシュ停止時はトラフィックをそのままプロバイダーへ送信。
  • サイト上で示されているセキュリティ制御。通信中および保存時の暗号化、任意のプロンプト保存、リクエスト時に渡され保存されない上流APIキーを含む。

SemanticGuardの使い方

開発者は、withSemanticGuard()でfetchレイヤーをラップし、その後は通常どおりリクエストを送ることで、SemanticGuardをAI SDK設定に追加します。サイトで示されているワークフローは、まずShadow Modeで削減効果を測定し、トラフィックがどう分類されるかを確認するところから始まります。

結果に問題がなければ、キャッシュを有効化できます。その時点でキャッシュヒットは自動的に返され、ダッシュボードで削減額、ヒット率、検証結果を確認できます。

用途

  • 多くのユーザーが重なる質問をし、繰り返し回答を再利用できる高トラフィックなLLMアプリの費用削減。
  • 特に、キャッシュ済み出力をすぐには返さずに削減額を数値化したいチーム向けの、展開前のキャッシュ経済性の測定。
  • 名前、日付、IDなど表層的な要素が異なっても意味が同じで、プロバイダーのバイト一致キャッシュでは外れるような意味的に近いリクエストへの対応。
  • 異なるモデルベンダー間で単一のキャッシュ層を必要とする、マルチプロバイダーのAIスタックのサポート。
  • キャッシュ層が利用できない場合のフォールバック経路を必要とする本番アプリの可用性維持。

FAQ

SemanticGuardにプロンプト変更は必要ですか? いいえ。サイトでは1行のSDK統合を説明しており、プロンプト変更は不要としています。

キャッシュヒットを有効化する前に削減額をテストできますか? はい。SemanticGuardにはShadow Modeがあり、キャッシュ応答を返す前に、どれだけ節約できるかを測定します。

1つ以上のモデルプロバイダーで動作しますか? はい。ページではOpenAI、Anthropic、Googleを挙げており、Azure、Bedrock、Mistralなど他のプロバイダーとの互換性も示しています。

キャッシュが利用できない場合はどうなりますか? この製品はfail-openと説明されており、リクエストは直接プロバイダーへ送られます。

この製品は完全一致キャッシュ専用ですか? いいえ。ページでは、名前、日付、IDのような詳細が変わっても同じ意味を持つリクエスト向けのセマンティックキャッシュとしてSemanticGuardを位置付けています。

代替案

  • OpenAIや同様のベンダーによる組み込みキャッシュなど、プロバイダー純正のprompt caching。通常は各プロバイダーのシステム内での完全一致またはほぼ完全一致のprefix再利用に限定され、静的なプロンプト区間に向いています。
  • アプリケーションやプロキシに組み込む手動キャッシュ層。カスタマイズは可能ですが、通常はキャッシュキーの定義、無効化管理、正当性検証のためにより多くの実装作業が必要です。
  • セマンティック検証のない一般的なAI gateway。ルーティング、可観測性、ポリシー適用は扱えても、正当性チェック付きキャッシュに重点を置いているとは限りません。
  • キャッシュ層を使わない直接のプロバイダー利用。最もシンプルな構成ですが、類似リクエスト間の再利用や、公開前の削減額測定ワークフローは追加されません。