比較: AI ゲートウェイとエージェントガバナンス

AIゲートウェイまたはハイパースケーラーのGuardrailsにすでに投資されている場合、 最初に正直にお伝えすべきことは、そのまま維持してください。Olivares AIはそれらを 置き換えようとしていません。 ゲートウェイの役割はモデル呼び出しです — ルーティング、 キャッシュ、ロードバランシング、予算管理。Guardrailsの役割はその呼び出しに対する コンテンツセーフティです。どちらも実際に機能しており、それぞれの領域で優れています。 そして、どちらもOlivaresが提供するものとは異なります。

TL;DR: Olivares AI は汎用の AI ゲートウェイではありません。モデルトラフィックのキャッシュやロードバランシングは行わず、プロバイダー・モデル・ルーティングの普遍的なマトリクスは主張しません。ルーティングポリシーを順序付きフォールバック連鎖に解決し、測定済みの実行経路を一つ持ちます。deny-closed で、お客様が設定した Claude Messages 互換クライアントを通じてのみ動作します（直接、またはお使いのゲートウェイのエンドポイントを Messages のベース URL として）。その経路の外ではガバナンスと証跡のプレーンです。エージェントランタイム内のインプロセス強制、改ざん検知可能な台帳、非人間アイデンティティのライフサイクル、そして稼働中セッションに対する human-in-the-loop / break-glass / kill-switch。すでに運用しているゲートウェイを置き換えるのではなく、組み合わせて使います。

このページは以前、二つのカテゴリーがまったく重ならないと述べていました。現在はどちらの方向でも正確ではありません。複数のゲートウェイが独自のエージェントサーフェスを文書化しており、Olivares にも狭く測定された実行経路があります。製品ごとの詳細は、引用と読み取り日とともに英語版が正本です。

ゲートウェイとGuardrailsの優れている点（これらの用途にお使いください）

以下はコモディティ化された、十分に理解されている機能であり、各ベンダーが明確に 説明しています：

• AIゲートウェイはモデル呼び出しに対するリクエストパスマネージャーです。LiteLLMは “OpenAI Proxy Server (LLM Gateway) to call 100+ LLMs in a unified interface & track spend, set budgets per virtual key/user” (LiteLLM)、Cloudflare AI Gatewayは “Connect to any model, dynamically route requests, and manage usage, billing, and logs from one unified gateway” (Cloudflare)、Portkeyは “records real-time API requests, including cost” (Portkey)と説明しています。ルーティング、 フォールバック、キャッシュ、仮想キー、キーごとの予算管理、リクエストログ — これが ゲートウェイの領域です。
• ハイパースケーラーのGuardrailsはコンテンツセーフティフィルターです。Bedrock Guardrailsは*“provides configurable safeguards to help you build safe generative AI applications”であり、“detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses”* — コンテンツフィルター、禁止トピック、ワードフィルター、PIIリダクション、 コンテキストグラウンディングおよび自動推論チェックを提供します (AWS)。

お客様の課題が*「アプリケーションに多数のモデルへの単一エンドポイントを提供し、 予算管理、キャッシュ、コンテンツフィルタリングを実現する」*というものであれば、 そのスタックで解決でき、コントロールプレーンは不要です。私たちはそのパターンと 統合します。再実装はいたしません。

各製品が現在文書化している内容

2026-09-12 に各ベンダー自身のページで確認しました。これは読み取ったページの範囲であり、製品全体についての主張ではなく、順位付けでもありません。

したがって従来の説明は誤りでした。「ゲートウェイはエージェントを見ない」は上記のページに照らして成り立ちません。LiteLLM と Portkey はエージェントと MCP の面を文書化しており、Cloudflare は自社ゲートウェイをコントロールプレーンと呼んでいます。異なるのはどこで強制が行われ、どのような記録が残るかであり、これは不在の主張ではなくアーキテクチャの比較です。

アーキテクチャの違いが残る箇所

普遍的ではなく条件付きです。各行は左の条件が成り立つときに当てはまります。

Olivares の実行経路と実際の限界

Olivares は推論に触れます。ただし測定された一箇所のみで、正直な説明は現在の測定そのものが示すとおりです。

• ルート POST /routing-policies/{id}/execute は構造上 deny-closed であり、Claude Messages 互換クライアントを通じてのみ動作します。直接、または解決されたゲートウェイのエンドポイントを Messages のベース URL として利用できます。つまり既存のゲートウェイをそのエンドポイントにできます。
• ポリシーの解決は順序付きフォールバック連鎖を生成します。モジュールは常にルートを解決し、executor ポートを通じてのみ動作します。既定の executor は未接続であるため、運用者が構成するまでプロバイダー呼び出しなしでルーティングが解決されます。
• 二つの deny-closed スコープゲートと kill-switch の停止ゲートは、FinOps の予算ゲートの前に実行され、予算ゲートは executor の前に実行されます。

そして同じ記録の言葉で、明示的に成立させないことは次のとおりです。

• プロバイダーやモデルの普遍的なマトリクスはありません — Claude Messages プロトコルが定めるのは構成済みの一経路であり、マトリクスではありません。
• 鍵の集中保管はありません — プロバイダーの鍵フィールドは参照です。
• コンソールからの実行はありません — コンソールはポリシーの解決とテストを行い、実行呼び出しを持ちません。

これは現在のソースの測定であり、機能の受理ではありません。現行のクレーム記録は、この機能を含むすべての機能を実装済みかつ未受理として扱い、実行の証跡はありません。認証された機能ではなく、経路の形として読んでください。

Guardrailsについて具体的に：コンテンツセーフティはフックであり、競合ではありません

Bedrock Guardrailsは2つの方法で適用できます — Bedrock推論呼び出し中にインラインで 適用するか、*“directly through the ApplyGuardrail API without invoking the foundation models”を通じて適用するかです。後者は”with any foundation model whether hosted on Amazon Bedrock or self-hosted models”*で動作します (AWS)。これは真に有用であり、 Olivaresはコンテンツセーフティを接続するディテクターとして扱います。Guardrailsの 代わりに選択することを求める壁ではありません。正直かつ明確な2つの事実があります：

• インライン推論プロキシはコンテンツインスペクションシームを公開します — コンテンツ / DLPディテクターが判定を返し、deny-closedデサイダーがそれに基づいて 行動するプラグイン可能なポイントです。コンテンツセーフティは競合するフィルターとして 再実装するのではなく、パイプライン内のそこに属します。
• OlivaresはGuardrailsの判定結果そのものをread-firstで読み取ります。AWSコネクタは BedrockのGuardrail判定をCloudWatch / S3ログからポスチャーおよび証跡として 取り込みます。有料のApplyGuardrailランタイムを自ら呼び出すことは意図的に 行いません。お客様のコンテンツ判定は改ざん不可能な記録の一部となります。

このようにコンテンツセーフティは既存の仕組みと連携します。Guardrailsが文書化して いないこと — そしてガバナンスのギャップが残る部分 — はエージェントの残りの ライフサイクルです：Bedrockのページにはエージェントアイデンティティ、セッション管理、 人間のアプルーバル、コストガバナンスは文書化されていません（これらのページで未文書化、 2026-09-12確認）。Olivaresはまさにその補完です：アイデンティティ、セッションコントロール、 アプルーバル、証跡を担います。コンテンツフィルターは既に存在する場所にとどまります。

連携方法

健全な構成では各ツールがそれぞれの領域を担当します：

• ゲートウェイを維持してください（LiteLLM / Portkey / Kong / Cloudflare）。 モデル呼び出しプレーンとして — ルーティング、キャッシュ、仮想キー、リクエストに 対する予算管理を担います。
• Guardrailsを維持してください（Bedrock / Azure Content Safety）。コンテンツ セーフティディテクターとして — OlivaresのPEPはコンテンツインスペクションシームで プラグイン可能なディテクターを実行し、Guardrailsの判定結果をread-firstで証跡として 読み取ります。ApplyGuardrailを自ら呼び出すことはありません。
• Olivaresをそれらの隣に追加してください。ガバナンスと証跡のプレーンとして： ゲートウェイを経由しないエージェント上のインプロセスPEP、インフラ全体のアクセスマップ、 改ざん不可能な台帳、そしてライブHITL/break-glass/killコントロールを提供します。

Olivaresが推論に関与する唯一のポイントは限定的かつ明示的です — SDK直接呼び出しや curl利用者向けのAPIキー専用ゲートウェイパスであり、 サブスクリプション認証エージェントのガバナンス で説明されています。他のツールでは到達できないトラフィックをガバナンスするために 存在し、ルーティングで競合することは決してなく、サブスクリプション資格情報を一切 搬送しません。

ゲートウェイで十分な場合

正直さは双方向に機能します。お客様のエージェントがすべてゲートウェイ経由でのみ モデルを呼び出し、コンテンツセーフティのニーズがGuardrailsで満たされ、データベース / オブジェクトストア / MCPに直接アクセスするセルフホストまたはラップトップ常駐の エージェントがなく、主権要件や改ざん不可能な証跡の要件もない — のであれば、 ゲートウェイとそのログおよびGuardrailsで十分かもしれません。コントロールプレーンを 目的なく追加すべきではありません。

Olivaresが真価を発揮するのは、問いがインフラ全体にわたり、かつ敵対的になった ときです：どのエージェントが存在し、各エージェントが実際に何にアクセスしたか、 誤った操作をdeny-closedでエージェント上で停止できるか、リスクのある操作を誰が 承認したか、そして監査人に不変の証拠を提出できるか — そのすべてを他社のクラウドに 送信することなく実現する必要がある場合です。 2つの関連する比較の詳細な分析については、 vs AIコントロールタワーおよび vs LLMオブザーバビリティをご覧ください。