コンテンツにスキップ

アーキテクチャ概要

このページでは、Olivares AI がどのように構成され、なぜそうなっているのかを説明します。これは 解説 であり、ハウツーではありません。インストール、設定、拡張を行う前に、コントロールプレーンについて推論するために必要なメンタルモデルを提供します。手順ごとの操作については ハウツーガイド に従ってください。正確な契約については API リファレンスイベントリファレンス を参照してください。

アーキテクチャ: エージェント面、監査ソース、MCP および A2A のピア、コンテンツソースが 3 つの方法で、コンソールを組み込んだ単一のセルフホスト Go バイナリへ収集されます。このバイナリは製品モジュール、ポリシーと適用の層、署名済みの証跡台帳を、テナント単位にスコープされたストアの上で保持します。コンソール、REST API、絞り込んだ gRPC サブセット、CLI、Terraform プロバイダーを提供し、クラウド制御プレーン(構築済み・未デプロイ)とライセンスポータル(デプロイ済み・提供は無効)は別のプレーンとして描かれています。 アーキテクチャ: エージェント面、監査ソース、MCP および A2A のピア、コンテンツソースが 3 つの方法で、コンソールを組み込んだ単一のセルフホスト Go バイナリへ収集されます。このバイナリは製品モジュール、ポリシーと適用の層、署名済みの証跡台帳を、テナント単位にスコープされたストアの上で保持します。コンソール、REST API、絞り込んだ gRPC サブセット、CLI、Terraform プロバイダーを提供し、クラウド制御プレーン(構築済み・未デプロイ)とライセンスポータル(デプロイ済み・提供は無効)は別のプレーンとして描かれています。

プラットフォームモデル: 単一エンジン、モジュール、コネクタ

Section titled “プラットフォームモデル: 単一エンジン、モジュール、コネクタ”

Olivares AI は単一目的のツールではありません。Grafana、Backstage、Kubernetes コントロールプレーンの系譜に連なるモジュール型プラットフォームです。単一エンジン (コア) に加えてモジュールとコネクタで構成されます。製品はモジュールのカタログ — インベントリ、セッション、アクセスマップ、ガバナンス、FinOps、評価、ガードレールなど — にまたがりますが、それらはすべて単一の共有エンジンの上に乗っています。

このアーキテクチャを統御する制約は 「再アーキテクチャ不要」のルールです。エンジンは、カタログ内のいかなるモジュールも、コアや他のモジュールに手を加えることなく追加できるように設計されています。具体的には、すべての新しいモジュールは次のように動作します。

  1. エンジンから正規化されたイベントとデータを消費する。
  2. 共有データモデル内に自身のエンティティを宣言する。
  3. 自身の API エンドポイントと UI ビューを公開する。

どのモジュールも他のモジュールの内部に手を伸ばすことはなく、いずれもコアを自身に合わせて作り変えることはありません。エンジンは、後から再設計なしに幅広さを追加できるようにするために、初日からマルチテナント、イベント駆動、API ファーストであるという先行コストを支払っています。同じ原則がビルド順序 — まず CLI エンジン、その上に web — を説明します。CLI がまさにエンジンであり、CLI と API を通じて全機能を公開します。web は同じ API 上のプレゼンテーションレイヤーであり、ロジックの重複はありません。エンジンを構築してからその上に視覚的なフェイスを構築することは、再アーキテクチャではありません。

差別化機能 — permitted-versus-observed の差分を伴う read/write access map — それ自体が共有モデル上のモジュール (モジュール III) であり、専用のパイプラインではありません。これがプラットフォームを誠実に保つものです。看板機能が他のすべてと同じルールに従うのです。

エンジン (コア、「Layer 0」) は、他のすべてがそこからぶら下がる共有サブシステムの集合です。それは 8 つあります。

サブシステム役割コアに存在する理由
インジェスト + イベントバスOTLP とコネクタの入力を受け取り、正規化し、イベントをモジュールに配信するモジュールは互いに結合することなくイベントに反応する
コネクタ SDK安定した入出力コネクタインターフェース — 幅広さの背骨サードパーティはコアをフォークすることなくプラットフォームを拡張する
モジュールランタイムモジュールをロードして実行する: インプロセスにコンパイルされたものに加え、アウトオブプロセスのプラグインコアを再アーキテクチャまたは再コンパイルすることなくモジュールを追加する
汎用データモデルカタログ全体に提供されるマルチテナントのエンティティとリレーションすべてのモジュールが共有し拡張する単一のスキーマ
API (REST/gRPC) + manage-as-codeAPI 経由の全機能、加えて Terraform プロバイダーCLI と web は同じ API を話す。パネルは GitOps 可能
AuthN/Z + マルチテナンシーRBAC/ABAC、組織とテナント、分離権限とテナンシーの後付けは破滅的に高コスト — だから初日に
監査 + 整合性追記専用、ハッシュチェーン化された台帳改ざん検知性は横断的であり、決してオプションではない
ライセンス / エンタイトルメントオフラインの Ed25519 ライセンス検証セルフサーブの商用、エアギャップ環境で動作

特筆すべき具体的な点がいくつかあります。

  • モジュールランタイム。 コアモジュールはバイナリにコンパイルされます。アウトオブプロセスのモジュールとコネクタは hashicorp/go-plugin を使って gRPC 経由でプラグインとして実行されます。これにより障害分離が得られ、コアを再コンパイルすることなくモジュールを追加できます。
  • イベントバス。 デフォルトはインプロセス (Go チャネル) です。NATS 上の分散バインディングはオプションであり必須ではありません。シングルノードのデプロイメントは決してこれに触れません。
  • manage-as-code。 API が記録上の契約です。manage-as-code のサーフェスは Terraform プロバイダーを追加し、コントロールプレーン自体を宣言してバージョン管理できるようにします。
  • 監査 + 整合性。 台帳は追記専用かつハッシュチェーン化されており、Ed25519 で署名されたチェックポイントを伴います。エントリはシーケンス番号、前のハッシュ、現在のハッシュ、そして署名を保持します — そして PII を決して保持しません。台帳がボックスの外に出る経路は 2 つあります。プルのエクスポートエンドポイントが CEF、LEEF、syslog、OTLP(完全で POST 可能なエクスポートリクエスト。otlp_envelope はその厳密なエイリアスで、素の LogRecord 射影は別トークン otlp_log_record です)、OCSF を出力し、プッシュaudit.recorded のイベンティング サブスクリプションを設定すれば実在し、封緘済みの各レコードを永続トランスポートで少なくとも1回配送します。Splunk への監査転送方法 を参照してください。
  • ライセンス。 検証は Ed25519 を使ってオフラインで行われ、エンジンはライセンスのための通信を一切行いません。これがエアギャップ運用を実現可能にしています。外部へ通信する唯一のコマンドは olivares upgrade です。既定では公開リポジトリの GitHub リリースから取得し、--enterprise ではライセンス Worker(licenses.olivares.ai)から取得します——--endpoint で自社ミラーを指定するか、--bundle で持ち込んだバンドルからインストールする場合を除きます。

認証と認可の詳細 (不透明なベアラートークン、初回ブート時のセットアップトークン、policy decision point) については セキュリティモデル を参照してください。アーキテクチャがそれらに依存する箇所でのみ、以下で要約します。

単一のマルチテナントスキーマがカタログ全体に提供されます。すべてのコアエンティティは tenant_id を保持し、分離はクエリ / 行レベルで強制されます。コアエンティティは、組織とテナント、エージェント、セッション、モデルとプロバイダー、MCP サーバー、スキルとツール、リソース (データベース、サーバー、ストア、API)、アイデンティティ、ポリシー、コスト記録、評価結果、検出事項、監査イベント、ヘルスステータス、デプロイメント — そして中心的に AccessEdge をカバーします。

各モジュールは、型レジストリとモジュールごとのテーブルを通じて、コアを壊すことなく自身のエンティティとリレーションを登録します。これがデータレイヤーにおける「再アーキテクチャ不要」ルールを支えるメカニズムです。

ストアはシングルノードのデプロイメントでは SQLite (ピュア Go の modernc ドライバ。そのためバイナリは CGO を必要とせずエアギャップ環境で動作する) として始まり、マルチテナントとスケールのためには行レベルセキュリティを備えた Postgres に移行します。

モジュール III: モデル上のビューとしてのアクセスマップ

Section titled “モジュール III: モデル上のビューとしてのアクセスマップ”

看板モジュールは read/write access map と、その permitted-versus-observed の差分 — least-privilege drift です。アーキテクチャ上の重要な点は、これが汎用データモデル上のビューであり、別個のスキーマではないということです。マップは AccessEdge エンティティからマテリアライズされ、AccessEdge 自体がpermitted 側と observed 側の両方を保持し、シグナルソースと信頼度レベルを併せ持ちます。したがって差分は、他のすべてのモジュールが使うのと同じマルチテナントモデル上のクエリです。

マップは read-first です。ログ、OpenTelemetry、そして (バックストップとして) eBPF から観測します — エージェントの呼び出しのデータ経路に入ることは決してありません。また minimal-data でもあります。リレーション (エージェントがリソースを読み書きする) を保存し、ペイロード、シークレット、PII を決して保存しません。この非対称性は意図的なものです — 高シグナル、低リスク。

ネイティブストア監査と交差させる協調的経路

Section titled “ネイティブストア監査と交差させる協調的経路”

忠実度は、2 種類の独立した証拠を交差させることから生まれます。

  • 協調的経路 — Claude Code とエージェントが OpenTelemetry (OTLP) 経由でテレメトリを発し、サーバーが公開するツールとリソースの MCP イントロスペクションによって補完されます。OTLP レシーバーはコアインジェストの一部であり、デフォルトでループバック上をリッスンします。Claude Code の接続 を参照してください。
  • ネイティブストア監査 — ストアが実際に何が起きたかを教えてくれます。pgAudit は Postgres 上で READWRITE を逐語的に分類します。CloudTrail は S3 について readOnly を表面化します。他のエンジンにも同等のネイティブ監査が存在します。

協調的経路とストア自身の監査があるエッジについて一致するとき、裏付けの取れた read/write リレーションが得られます。

eBPF バックストップ、信頼できない注釈、そして段階的なカバレッジ

Section titled “eBPF バックストップ、信頼できない注釈、そして段階的なカバレッジ”

さらに 3 つの性質が、マップをナイーブではなく信頼できるものにします。

  • eBPF / Tetragon は非協調的なバックストップです。 協調しない経路について、カーネルレベルの観測者がプロセスとホストのレベルで read/write の意図に関するグラウンドトゥルースを提供します。これはエージェントの制御外で実行され (回避対策)、TLS ペイロードには盲目ですが — それで問題ありません。マップは内容ではなくリレーションだけを必要とするからです。
  • MCP 注釈は信頼されません。 MCP の read-only / destructive ヒントは有用なシグナルですが、MCP 仕様自体がクライアントはそれらを信頼できないものとして扱わなければならないと述べています。したがってマップはそれらを他のソースに対して裏付け注釈単独を決して信頼しません
  • カバレッジは段階的であり、製品はそう明言します。 一部のストアは受動的に観測するのがクリーンです (SQL データベース、オブジェクトストア、ウェアハウス)。一部はロスが多く (Mongo、ベクトルデータベース)、一部は受動的に観測することが不可能です (Redis、SQLite、D1)。マップは、持っていない精度を装うのではなく、信頼度レベル (帰属付き versus 近似) を示します。

アクセスグラフの閲覧は特権アクションです。テナントスコープであり、エディターロール以上で利用可能で (最下位のビューアーロールでは決して不可)、すべての読み取りが監査されます。マップのルート — グラフとドリフト結果 — は安定コア契約には含まれず、独立した beta module-route リファレンス/openapi.beta.json で提供)で公開されます。フィールドレベルの形状は型付き Go と TypeScript のインターフェースに存在します。permitted-versus-observed の結果はエンジンの drift ルート (/v1/m/accessmap/drift) で公開されます。別個の diff エンドポイントはありません。安定コア REST サーフェス — 製品独自の OpenAPI 3.1 契約からレンダリングされる 53 のパス — は API リファレンス に文書化されています。モジュールの完全な一覧については モジュールカタログ を参照してください。

同じバイナリが複数のトポロジをサポートします。それらすべてに共通する 1 つの制約があります。データプレーン — コレクタ — は常に顧客のインフラ上で動作するということです。これがプライバシーとエアギャップ運用を可能にします。必須のテレメトリはなく、デフォルトではコントロールプレーンからのエグレスもありません。顧客の境界を越えるのは、顧客がそのように設定したものだけです。具体的には、顧客のモデル API への呼び出し、接続した SIEM/Webhook 出力、用意した場合の外部埋め込みプロバイダーです。

デフォルトです。1 つの静的 Go バイナリが、CLI エンジン、go:embed 経由で埋め込まれた web UI (API と同じオリジンから配信される)、そしてストアとしての SQLite を運びます。1 つのアーティファクトを出荷してセルフホストします。これは zero-to-graph チュートリアルセルフホスティングガイド の背後にあるトポロジです。

マルチホスト、スケール、マルチテナントのエステート向け: エッジのコレクタが相互 TLS を用いた gRPC で中央コアにプッシュし、ストアはPostgres (行レベルセキュリティ付き) になり、イベントバスは NATS 上で動作します。コレクタはインバウンドリスナーを持ちません — プッシュするのであって、サービスを提供するのではありません — これによりエッジの攻撃面が最小限に保たれます。

このトポロジではすべてがエグレスゼロでローカルに動作します。ストアはローカルで、ライセンスはオフラインで検証されます。本来こちらへ接続する唯一のコマンドである olivares upgrade も、ここでは更新チャネルではなく持ち込んだバンドル(--bundle)からインストールします。エアギャップインストール を参照してください。

ホスト型のコントロールプレーンがロードマップにあります。その場合でも制約は保たれます。コレクタは依然として顧客のインフラ上で動作し、ホストされるのはコントロールプレーンだけです。これは設計段階です。

ランタイムトポロジを超えて、2 つの境界がアーキテクチャを形作ります。

  • コネクタ境界。 コネクタはコアからインポートすることが決してありません — SDK のみに依存します。これによりサードパーティのコネクタがコアを汚染することを防ぎ、ライセンス境界をクリーンに保ちます。
  • ライセンス境界。 コア、モジュール、web は AGPL-3.0-only です。SDK とコネクタは Apache-2.0 です。エンタープライズティアは商用です。上記のコネクタ境界が、Apache/AGPL の分割をコード上で強制可能にするものです。オープンコアとライセンシング を参照してください。

アーキテクチャはセキュアバイデザインです。read-first 観測 (低く非対称なリスク)、インバウンドリスナーを持たないプッシュ専用コレクタ、コレクタとコアの間の相互 TLS、最小データ (エッジのみ、ペイロードは決して保存しない)、追記専用のハッシュチェーン化された台帳による改ざん検知性、データモデルに根ざしたマルチテナント分離、そして必須のテレメトリがなく、デフォルトではコントロールプレーンからのエグレスもないセルフホスティング。顧客の境界を越えるのは、顧客がそのように設定したものだけです。具体的には、顧客のモデル API への呼び出し、接続した SIEM/Webhook 出力、用意した場合の外部埋め込みプロバイダーです。各信頼境界がどのように防御され、何が明示的にスコープ外であるかを含む完全な分析は、セキュリティモデル脅威モデル に存在します。