解説

このセクションは理解志向です。タスクを順を追って説明するのではなく、Olivares AI がなぜこのような形をしているのか — 設計原則、セキュリティ態勢、そしてライセンスモデル — を説明します。何かを行いたい場合は、チュートリアルまたはハウツーガイドから始めてください。正確な契約が必要な場合はリファレンスを使ってください。各種類のページがどこに存在するかについては、ドキュメントの構成方法を参照してください。

モジュール型プラットフォーム: エンジン + モジュール + コネクタ

Olivares AI は、企業がすでに運用している AI を統合、管理、セキュアにするのを支援します — ひとつのグラウンドトゥルース: Claude Code が最も深いレベル、Codex と Grok Build がその隣、それらと競合するのではなく補完します。web UI が埋め込まれ API と同じオリジンから配信される、単一の静的 Go バイナリ (olivares) として出荷されます。アーキテクチャは単一のツールではなくプラットフォームです。コアエンジンが共有サブシステム — インジェストとインプロセスのイベントバス、コネクタ SDK、モジュールランタイム、マルチテナントのデータモデル、REST/gRPC API、認証と認可、そして追記専用の監査台帳 — を提供し、すべての機能はコアを再アーキテクチャすることなくそれらのサブシステムからぶら下がる 30 モジュールの 1 つです。コネクタは安定した SDK を通じて外部からエンジンに供給します。コネクタはコアからインポートすることが決してなく、これがライセンス境界をクリーンに保ちます。

デフォルトのストアは、シングルノードとエアギャップ用途では SQLite (ピュア Go) であり、マルチテナントとスケールのためには行レベルセキュリティを備えた Postgres に移行します。イベントバスはデフォルトでインプロセスです。NATS はオプションの分散バインディングであり、要件ではありません。プラットフォームは今日 30 モジュールを出荷しており、それぞれが独自の正直な成熟度にあります — ほとんどはライブでエンドツーエンドに配線され、一部は部分的またはオプトインです — 9 つの機能領域にまたがります。自社モデルレジストリとファインチューニングは計画された機能であり、出荷済みのモジュールではありません。

→ 完全なエンジン、データモデル、デプロイトポロジについてはアーキテクチャ概要をお読みください。

アクセスマップ: read-first、minimal-data、Permitted-vs-Observed

30 の機能の中で最も有用なものの 1 つが R/RW access map です。これは、どのエージェントがどのリソースを読み書きするかのグラフを構築し、2 つの意図的な制約のもとでこれを行います。

read-first。 マップはテレメトリ、ネイティブ監査ログ、そして eBPF カーネルバックストップを通じて観測します — データ経路の外側に位置し、決してその中には入りません。ライブトラフィックをプロキシ、傍受、ゲートすることはありません。
minimal-data。 リレーション (エージェント → リソース、読み取りまたは書き込み) のみを、シグナルソースと信頼度レベルとともに保存します。ペイロード、シークレット、PII を保存しません。

そのグラフの上に、最も特徴的なビューが乗ります。Permitted-vs-Observed の差分です。これは、ポリシーが許可するものと、エージェントが実行すると観測されるものを比較することで、least-privilege drift を表面化します。協調的で高忠実度な経路は、OpenTelemetry に加えて MCP イントロスペクションを介した Claude Code であり、ネイティブストア監査によって裏付けられます (例えば、読み取りと書き込みを分類する pgAudit、またはオブジェクトストレージ上の read-only アクセスを公開する CloudTrail)。非協調的なバックストップはカーネルでの eBPF です。MCP 注釈は MCP 仕様に従って信頼できないものとして扱われ、裏付けられ、決して単独で信頼されることはありません。

→ 態勢についてはセキュリティモデルを、前提と限界については脅威モデルをお読みください。

セルフホストとオープンコア

データプレーン — コレクタ — は常に顧客のインフラ上で動作するため、エステートのデータは顧客の境界を出る必要がありません。コントロールプレーンは、単一のセルフホストバイナリとして、分散デプロイメント (mTLS を用いた gRPC で中央コアにプッシュするコレクタ、Postgres に支えられる) として、または完全にエアギャップでエグレスゼロとオフラインライセンスで動作できます。マネージドオプションは将来の作業です。

ライセンシングはオープンコアです。エンジンコア、モジュール、web UI は AGPL-3.0-only です。SDK とコネクタは Apache-2.0 です。エンタープライズティアは商用です。この分割が、コピーレフトの境界が自身のコードに及ぶことなく、サードパーティがコネクタを構築できるようにするものです。

→ ディレクトリごとのライセンスマップと、それが実際に何を意味するかについてはオープンコアとライセンシングをお読みください。

アーキテクチャの決定

要となる選択 — JWT の代わりに不透明なベアラートークン、単一の接合部の背後にあるプラガブルな認可 PDP、SQLite から Postgres へ、ハッシュチェーン化され署名された監査台帳 — の背後にある理由は、Architecture Decision Records として記録されています。

規制、ポジショニング、適合

理解志向のスレッドがあと 2 つ、アーキテクチャと並んで存在します。1 つ目は規制的なものです。コントロールプレーンが、エステートのライブな挙動を、EU AI Act のファイルが必要とする技術的証拠へどう変え、自ら運用するコントロールプレーンに保存するかを説明します。

→ ランタイムデータから得る EU AI Act の証拠をお読みください。

2 つ目は製品が市場のどこに位置するかです — 正直に定義され、すべての統計が一次ソースまで追跡されます。これらのページは、アナリストの語彙 (agent sprawl、guardian agents、AI TRiSM)、Olivares AI が隣接ツール (LLM ゲートウェイ/可観測性、AI コントロールタワー — 私たちは統合するのであって競合しない) とどう関係するか、高等教育の垂直分野、そしてデータと主張がどこから来るかを説明します。

→ ポジショニングと適合を、検証済みの市場の文脈とソースから始めて閲覧してください。