AIゲートウェイまたはハイパースケーラーのGuardrailsにすでに投資されている場合、 最初に正直にお伝えすべきことは、そのまま維持してください。Olivares AIはそれらを 置き換えようとしていません。 ゲートウェイの役割はモデル呼び出しです — ルーティング、 キャッシュ、ロードバランシング、予算管理。Guardrailsの役割はその呼び出しに対する コンテンツセーフティです。どちらも実際に機能しており、それぞれの領域で優れています。 そして、どちらもOlivaresが提供するものとは異なります。
TL;DR: Olivares AIはAIゲートウェイではありません。 モデルトラフィックの ルーティング、キャッシュ、ロードバランシングを行わず、ホットパス上に位置することも 決してありません。ゲートウェイの隣と後ろにガバナンスと証跡のプレーンとして 配置されます：エージェントランタイム内でのインプロセスエンフォースメント、改ざん不可能な 証跡台帳、非人間アイデンティティのライフサイクル管理、そしてライブセッションに対する 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)。
お客様の課題が*「アプリケーションに多数のモデルへの単一エンドポイントを提供し、 予算管理、キャッシュ、コンテンツフィルタリングを実現する」*というものであれば、 そのスタックで解決でき、コントロールプレーンは不要です。私たちはそのパターンと 統合します。再実装はいたしません。
ゲートウェイとGuardrailsが残すガバナンスのギャップ
ゲートウェイはリクエストを見ます。Guardrailsはコンテンツを見ます。 どちらもエージェント — 時間を通じたその身元、データプレーン上で何にアクセスしたか、 誰がリスクのある操作を承認したか、そしてそれを後で証明できるかどうか — は見ていません。 これがOlivaresが埋めるギャップです。
| ゲートウェイ / Guardrailsが残すギャップ | 重要である理由 | Olivares AIが提供するもの |
|---|---|---|
| エージェントランタイムでのエンフォースメント | ゲートウェイはリクエスト境界でエンフォースします。ゲートウェイを経由しないClaude Codeのローカルtool-callは停止できません | エージェント上のdeny-closedインプロセスPEP：確実なアイデンティティゲート、ポリシーディスポジション、ライブポリシーオーバーレイ、すべてツール実行前に適用 |
| 改ざん不可能な証跡 | ゲートウェイとGuardrailsはログ（ミュータブルなリクエスト記録）を出力します。監査人は不変の証拠を求めます | append-only、ハッシュチェーン、Ed25519署名付き台帳、オフボックス検証可能、OSCALエビデンスとしてエクスポート可能 |
| 非人間アイデンティティのライフサイクル | ゲートウェイの「仮想キー」は予算バケットであり、プロビジョニング、帰属、ローテーション、オフボーディングされるアイデンティティではありません | NHIライフサイクル：陳腐化→ブロック、オフボーディングカスケード、ローテーション時のデュアルコントロール、アクセスマップに紐付け |
| ライブセッション介入 | ログと予算は事後的なもの。評価対象のどのツールも実行中のセッションを停止できません | HITLアプルーバル、break-glass、そしてデュアルコントロールによる再有効化まで全ガバナンス対象のアクチュエーションを拒否するキルスイッチ |
| インフラ全体のグラウンドトゥルース | ゲートウェイはそれを通過する呼び出しのみを見ます。エージェントはDB、オブジェクトストア、MCP、ファイルにも直接アクセスします | read-first R/RWアクセスマップとPermitted-vs-Observedドリフト、ネイティブ監査との照合 |
| 主権 | SaaSゲートウェイとクラウドGuardrailsはそのトラフィックを自社クラウドで処理します | セルフホスト / エアギャップ対応。データプレーンがお客様の境界外に出ることはありません |
これらはルーティング機能ではありません。ここが重要なポイントです：ギャップはより良い ルーティングではなく、リクエストパスが提供するよう設計されていないガバナンス なのです。
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-06-21確認）。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オブザーバビリティをご覧ください。