一般的かつ合理的なセルフホストスタックは、LLMゲートウェイ（例：LiteLLM）と LLMオブザーバビリティプラットフォーム（例：Langfuse）を組み合わせます。すでに 導入されている場合、コントロールプレーンが本当に必要かどうかを合理的に疑問に思われる かもしれません。このページはその疑問に正直にお答えします — 答えが不要となる ケースも含めて。
TL;DR: LiteLLMとLangfuseはアプリケーションが行うモデル呼び出しに関するものです： ルーティング、トレース、プロンプト管理、呼び出しごとのコスト追跡。Olivares AIは インフラ全体のすべてのエージェントとその読み書き — データベース、オブジェクト ストア、MCPサーバー、ツール、ファイル — に関するものであり、それがポリシーで 許可されていることと一致するかどうかを検証します。異なる高度です。連携して使用します。 当社はこれらが出力するものと同じOpenTelemetry GenAIシグナルを取り込みます。
そのスタックの優れている点（これらの用途にお使いください）
- LiteLLM — 多数のプロバイダーに対する統一されたOpenAI互換ゲートウェイ： ルーティング、フォールバック、リトライ、仮想キー、キーごとの予算とレートリミット、 そして通過するモデル呼び出しのコスト計算。
- Langfuse — LLMエンジニアリングとオブザーバビリティ：リクエスト/レスポンスの トレース、プロンプト管理とバージョニング、評価、データセット、チェーン デバッグ用の開発者向けUI。
お客様の課題が*「アプリケーションのLLM呼び出しを計装し、プロンプトをデバッグし、 単一エンドポイントからモデルアクセスを管理する」*というものであれば、このスタックは 優秀でセルフホスト可能です。そのためにコントロールプレーンは不要であり、当社もそうで あるかのように装うつもりはありません。
Olivares AIが構造的に異なる点
| 次元 | LLMゲートウェイ + オブザーバビリティ | Olivares AI |
|---|---|---|
| 関心の単位 | モデル呼び出し（プロンプト→コンプリーション） | エージェントとそれが読み書きするすべてのリソース — DB、オブジェクトストア、MCP、ツール、ファイル |
| 視点 | リクエストパス内（プロキシ/SDK）。アプリが送信するものを見る | 帯域外、read-first。テレメトリ、ネイティブ監査、カーネルバックストップを観測 — データパスに介在しない |
| 真実のソース | アプリ/プロキシが報告するもの | 自己報告テレメトリをシステム自身の台帳と照合 — pgAudit（read vs write）、CloudTrail（オブジェクトアクセス）、eBPFバックストップ |
| 核心的な問い | 「このプロンプトは何をし、コストはいくらか？」 | 「このエージェントは誰も付与していないアクセスを使用しているか？」 — Permitted-vs-Observedドリフト |
| エンフォースメント | ゲートウェイはモデル呼び出しをゲートできる（キー、予算） | 操作とリソースアクセスに対するdeny-closedゲート：アプルーバル、Claude Code hooks PEP、MCPツールゲーティング、キルスイッチ |
| 監査アーティファクト | デバッグ用のトレース / ログ | append-only、ハッシュチェーン、Ed25519署名付き台帳、オフボックス検証可能、OSCALエビデンスパッケージとしてエクスポート可能 |
| デプロイポスチャー | セルフホスト可能 | セルフホストまたはエアギャップ対応。データプレーンがお客様の境界外に出ることはありません。AGPL、ソース公開 |
決定的な差異はグラウンドトゥルースです。オブザーバビリティトレースは、 アプリケーションが行ったと自己申告したことを示します。しかし、トレースに記載されて いないテーブルにエージェントがアクセスしたことを検出することはできません。Olivares AI は協調的シグナルをデータプレーンとクロスチェックするため、「エージェントが接触したもの」 は自己申告ではなく、照合された事実となります。
「どちらか」ではなく「両方」 — テレメトリを取り込みます
Olivares AIはゲートウェイやトレーシングツールの代替品ではなく、それらが占める リクエストパスに介在することも望みません。同じシグナルを消費します：コントロール プレーンはOpenTelemetry GenAIセマンティックコンベンションスパンを取り込みます。 これはこれらのツールが出力し消費するものと同じgenAIテレメトリです。したがって、 健全な構成は以下の通りです：
- LiteLLMをモデルゲートウェイとして、Langfuseを開発者向けのトレーシングおよび プロンプトワークとして維持する。
- OTel GenAIストリームをOlivares AIに照合ソースの1つとして向け、アクセスマップ、 ドリフト検出、台帳がインフラ全体のガバナンスレイヤーとして機能するようにする。
Olivares AIを導入すべきでない場合
正直さは双方向に機能します。以下の場合、このコントロールプレーンはおそらく不要です：
- 目的が1つまたは2つのアプリケーションにおけるLLM呼び出しのトレースとデバッグのみで、 プロンプトプレイグラウンドが必要な場合 — Langfuse単体のほうが適しています。
- 予算管理とフェイルオーバーを備えたマルチプロバイダーゲートウェイのみが必要な場合 — それはLiteLLMの役割であり、当社はそのパターンと統合しますが再実装はしません。
- ガバナンス対象のインフラがない場合：単一のサービス、単一のモデル、データベース / オブジェクトストア / MCPに接触するエージェントがなく、監査や規制上の義務もない場合。
Olivares AIが真価を発揮するのは、問いがインフラ全体にわたり、かつ敵対的になった ときです：どのエージェントが存在し、各エージェントが実際に何にアクセスでき、 アクセスがポリシーからどこでドリフトしているか、監査人にそれを証明できるか、 誤った操作をdeny-closedで停止できるか — そのすべてを他社のクラウドに送信することなく 実現する必要がある場合です。