アーキテクチャ概要
このページでは、Olivares AI がどのように構成され、なぜそうなっているのかを説明します。これは 解説 であり、ハウツーではありません。インストール、設定、拡張を行う前に、コントロールプレーンについて推論するために必要なメンタルモデルを提供します。手順ごとの操作については ハウツーガイド に従ってください。正確な契約については API リファレンス と イベントリファレンス を参照してください。
プラットフォームモデル: 単一エンジン、モジュール、コネクタ
Section titled “プラットフォームモデル: 単一エンジン、モジュール、コネクタ”Olivares AI は単一目的のツールではありません。Grafana、Backstage、Kubernetes コントロールプレーンの系譜に連なるモジュール型プラットフォームです。単一エンジン (コア) に加えてモジュールとコネクタで構成されます。製品はモジュールのカタログ — インベントリ、セッション、アクセスマップ、ガバナンス、FinOps、評価、ガードレールなど — にまたがりますが、それらはすべて単一の共有エンジンの上に乗っています。
このアーキテクチャを統御する制約は 「再アーキテクチャ不要」のルールです。エンジンは、カタログ内のいかなるモジュールも、コアや他のモジュールに手を加えることなく追加できるように設計されています。具体的には、すべての新しいモジュールは次のように動作します。
- エンジンから正規化されたイベントとデータを消費する。
- 共有データモデル内に自身のエンティティを宣言する。
- 自身の API エンドポイントと UI ビューを公開する。
どのモジュールも他のモジュールの内部に手を伸ばすことはなく、いずれもコアを自身に合わせて作り変えることはありません。エンジンは、後から再設計なしに幅広さを追加できるようにするために、初日からマルチテナント、イベント駆動、API ファーストであるという先行コストを支払っています。同じ原則がビルド順序 — まず CLI エンジン、その上に web — を説明します。CLI がまさにエンジンであり、CLI と API を通じて全機能を公開します。web は同じ API 上のプレゼンテーションレイヤーであり、ロジックの重複はありません。エンジンを構築してからその上に視覚的なフェイスを構築することは、再アーキテクチャではありません。
差別化機能 — permitted-versus-observed の差分を伴う read/write access map — それ自体が共有モデル上のモジュール (モジュール III) であり、専用のパイプラインではありません。これがプラットフォームを誠実に保つものです。看板機能が他のすべてと同じルールに従うのです。
8 つのエンジンサブシステム
Section titled “8 つのエンジンサブシステム”エンジン (コア、「Layer 0」) は、他のすべてがそこからぶら下がる共有サブシステムの集合です。それは 8 つあります。
| サブシステム | 役割 | コアに存在する理由 |
|---|---|---|
| インジェスト + イベントバス | OTLP とコネクタの入力を受け取り、正規化し、イベントをモジュールに配信する | モジュールは互いに結合することなくイベントに反応する |
| コネクタ SDK | 安定した入出力コネクタインターフェース — 幅広さの背骨 | サードパーティはコアをフォークすることなくプラットフォームを拡張する |
| モジュールランタイム | モジュールをロードして実行する: インプロセスにコンパイルされたものに加え、アウトオブプロセスのプラグイン | コアを再アーキテクチャまたは再コンパイルすることなくモジュールを追加する |
| 汎用データモデル | カタログ全体に提供されるマルチテナントのエンティティとリレーション | すべてのモジュールが共有し拡張する単一のスキーマ |
| API (REST/gRPC) + manage-as-code | API 経由の全機能、加えて 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) については セキュリティモデル を参照してください。アーキテクチャがそれらに依存する箇所でのみ、以下で要約します。
汎用データモデル
Section titled “汎用データモデル”単一のマルチテナントスキーマがカタログ全体に提供されます。すべてのコアエンティティは 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 と minimal-data
Section titled “read-first と minimal-data”マップは read-first です。ログ、OpenTelemetry、そして (バックストップとして) eBPF から観測します — エージェントの呼び出しのデータ経路に入ることは決してありません。また minimal-data でもあります。リレーション (エージェントがリソースを読み書きする) を保存し、ペイロード、シークレット、PII を決して保存しません。この非対称性は意図的なものです — 高シグナル、低リスク。
ネイティブストア監査と交差させる協調的経路
Section titled “ネイティブストア監査と交差させる協調的経路”忠実度は、2 種類の独立した証拠を交差させることから生まれます。
- 協調的経路 — Claude Code とエージェントが OpenTelemetry (OTLP) 経由でテレメトリを発し、サーバーが公開するツールとリソースの MCP イントロスペクションによって補完されます。OTLP レシーバーはコアインジェストの一部であり、デフォルトでループバック上をリッスンします。Claude Code の接続 を参照してください。
- ネイティブストア監査 — ストアが実際に何が起きたかを教えてくれます。pgAudit は Postgres 上で
READとWRITEを逐語的に分類します。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 近似) を示します。
マップへの到達
Section titled “マップへの到達”アクセスグラフの閲覧は特権アクションです。テナントスコープであり、エディターロール以上で利用可能で (最下位のビューアーロールでは決して不可)、すべての読み取りが監査されます。マップのルート — グラフとドリフト結果 — は安定コア契約には含まれず、独立した beta module-route リファレンス(/openapi.beta.json で提供)で公開されます。フィールドレベルの形状は型付き Go と TypeScript のインターフェースに存在します。permitted-versus-observed の結果はエンジンの drift ルート (/v1/m/accessmap/drift) で公開されます。別個の diff エンドポイントはありません。安定コア REST サーフェス — 製品独自の OpenAPI 3.1 契約からレンダリングされる 53 のパス — は API リファレンス に文書化されています。モジュールの完全な一覧については モジュールカタログ を参照してください。
デプロイトポロジ
Section titled “デプロイトポロジ”同じバイナリが複数のトポロジをサポートします。それらすべてに共通する 1 つの制約があります。データプレーン — コレクタ — は常に顧客のインフラ上で動作するということです。これがプライバシーとエアギャップ運用を可能にします。必須のテレメトリはなく、デフォルトではコントロールプレーンからのエグレスもありません。顧客の境界を越えるのは、顧客がそのように設定したものだけです。具体的には、顧客のモデル API への呼び出し、接続した SIEM/Webhook 出力、用意した場合の外部埋め込みプロバイダーです。
単一バイナリ
Section titled “単一バイナリ”デフォルトです。1 つの静的 Go バイナリが、CLI エンジン、go:embed 経由で埋め込まれた web UI (API と同じオリジンから配信される)、そしてストアとしての SQLite を運びます。1 つのアーティファクトを出荷してセルフホストします。これは zero-to-graph チュートリアル と セルフホスティングガイド の背後にあるトポロジです。
マルチホスト、スケール、マルチテナントのエステート向け: エッジのコレクタが相互 TLS を用いた gRPC で中央コアにプッシュし、ストアはPostgres (行レベルセキュリティ付き) になり、イベントバスは NATS 上で動作します。コレクタはインバウンドリスナーを持ちません — プッシュするのであって、サービスを提供するのではありません — これによりエッジの攻撃面が最小限に保たれます。
エアギャップ
Section titled “エアギャップ”このトポロジではすべてがエグレスゼロでローカルに動作します。ストアはローカルで、ライセンスはオフラインで検証されます。本来こちらへ接続する唯一のコマンドである olivares upgrade も、ここでは更新チャネルではなく持ち込んだバンドル(--bundle)からインストールします。エアギャップインストール を参照してください。
マネージド (将来)
Section titled “マネージド (将来)”ホスト型のコントロールプレーンがロードマップにあります。その場合でも制約は保たれます。コレクタは依然として顧客のインフラ上で動作し、ホストされるのはコントロールプレーンだけです。これは設計段階です。
信頼境界とライセンシング
Section titled “信頼境界とライセンシング”ランタイムトポロジを超えて、2 つの境界がアーキテクチャを形作ります。
- コネクタ境界。 コネクタはコアからインポートすることが決してありません — SDK のみに依存します。これによりサードパーティのコネクタがコアを汚染することを防ぎ、ライセンス境界をクリーンに保ちます。
- ライセンス境界。 コア、モジュール、web は AGPL-3.0-only です。SDK とコネクタは Apache-2.0 です。エンタープライズティアは商用です。上記のコネクタ境界が、Apache/AGPL の分割をコード上で強制可能にするものです。オープンコアとライセンシング を参照してください。
セキュリティ態勢、手短に
Section titled “セキュリティ態勢、手短に”アーキテクチャはセキュアバイデザインです。read-first 観測 (低く非対称なリスク)、インバウンドリスナーを持たないプッシュ専用コレクタ、コレクタとコアの間の相互 TLS、最小データ (エッジのみ、ペイロードは決して保存しない)、追記専用のハッシュチェーン化された台帳による改ざん検知性、データモデルに根ざしたマルチテナント分離、そして必須のテレメトリがなく、デフォルトではコントロールプレーンからのエグレスもないセルフホスティング。顧客の境界を越えるのは、顧客がそのように設定したものだけです。具体的には、顧客のモデル API への呼び出し、接続した SIEM/Webhook 出力、用意した場合の外部埋め込みプロバイダーです。各信頼境界がどのように防御され、何が明示的にスコープ外であるかを含む完全な分析は、セキュリティモデル と 脅威モデル に存在します。
- モジュールカタログ — モジュールの全集合と、それらが上記のレイヤーにどう対応するか。
- イベントリファレンス — インジェストレイヤーがモジュールに配信する正規化されたイベント。
- 脅威モデル — 敵対者、信頼境界、緩和策。
- 誠実さと限界 — 今日動作するものと計画されているもの。