Olivares AI とは？

Olivares AI は、あなたが運用する AI を統合・管理・セキュアにします — 1 台のマシンでも環境全体でも、ひとつのグラウンドトゥルース: Claude Code が最も深いレベル、 Codex と Grok Build がその隣、それらと競合するのではなく補完します。より多くのモデル、エージェント、MCP サーバー、ツールを、実物の異種混在インフラ全体で稼働させるにつれ、 2 つのことが同時に難しくなります：AI を本当に有用にすること、そしてそれを制御下に保つことです。これは、セルフホストされた 1 台のマシンでも規制対象の環境でも同じです。違うのは規模であり、性質ではありません。

Olivares AI はその両方を行います。一方で、AI に動作に必要なものを与えます — コンテキスト、適切なリソースへのアクセス、管理されたセッション。他方で、そのすべてを運用するためのきめ細かな権限、ポリシー、予算、監査の証拠をあなたに与えます：どのモデルとエージェントが何に到達できるか、それらが触れるデータ、実行を許可されているもの、支出するもの、そして規制当局に手渡せる証拠です。

すべては、あなた自身のホスト上で 単一のセルフホスト型バイナリとして動きます。必須のテレメトリはなく、デフォルトではコントロールプレーンからのエグレスもありません。あなたの境界を越えるのは、あなたがそのように設定したものだけです。具体的には、あなたのモデル API への呼び出し、接続した SIEM／Webhook 出力、用意した場合の外部埋め込みプロバイダーです。これはアーキテクチャとあなたの設定の性質を説明するものであり、保証ではありません。

1つの能力：read/write アクセスマップ

それらの能力の中に、R/RW アクセスマップがあります。すべての起点（エージェント、非人間 ID、セッション）について、それが触れる各リソースへのエッジを構築し、read、write、 read-write、unknown に分類し、次のタグを付けます：

シグナルがどこから来たか（SignalSource） — 協調的なエージェントからの OpenTelemetry、 Postgres pgAudit の READ/WRITE 分類、AWS CloudTrail のレコード、カーネルレベルの eBPF/Tetragon バックストップ、MCP アノテーション（信頼できないものとして扱われ、裏付けが取られ、単独で信頼されることは決してありません）、宣言されたポリシー付与、または agent-to-agent（A2A）シグナル。そして
attribution をどれだけ信頼するか（Confidence） — エージェントごとの ID に確実に紐づいているときは attributed、推論されているとき（共有サービスアカウント、または lossy なストア）は approximate。

その中心にあるのが差分です：Permitted vs Observed。Permitted なエッジは宣言された付与から来ます。observed なエッジは実物のテレメトリと監査から来ます。両者を比較すると、予期しないアクセス （付与されたことのないテーブルを読むエージェント）、未使用の付与（どのエージェントも一度も行使していない権限）、そして reconciliation-pending なエッジ（システムがまだ確実に attribution できないアクセス）が浮かび上がります。

本製品は忠実度について正直です。カバレッジは段階化されています：ネイティブの監査を持つストア（SQL、オブジェクトストレージ、ウェアハウス）では clean、一部のストア（ドキュメント／ベクトル）では lossy、その他（例えば Redis、SQLite、D1）では受動的に再構成することが不可能です。 read/write の性質が判定できない場合、mode は unknown になります — 本製品は分類を決して捏造しません。

単一機能ではなく、プラットフォーム

アクセスマップは数ある能力の1つです。本製品は モジュラーなプラットフォーム（Grafana や Backstage の精神に近い）です：1つのエンジン + モジュール + コネクター。どのモジュールも、残りを再アーキテクトすることなく取り付けられるよう設計されています。30個のモジュールを備えます — インベントリとライブセッション、R/RW マップ、エージェントオーケストレーション（A2A、開発中）、MCP とスキル管理、identity と非人間 identity、デプロイメント、ナレッジとコンテキスト、セキュリティと guardrails、モデルとプロバイダー管理、コスト/FinOps、evals とテストサンドボックス、 red-teaming、コンプライアンスと証拠、内部カタログ、出力統合と SIEM プッシュ、voice/realtime、 health/SLA — に加えて、30個には数えないプラットフォーム能力（独自の API と manage-as-code、マルチテナンシー、エグゼクティブダッシュボード）があり — 158件の統合に対応します（scripts/check-public-counts.sh によってコードから測定されたカウントです）。いくつかの能力はプロビジョニングされるまでは pre-v1 または deny-closed なシームです。ドキュメントはどれがそうかを明示します。

完全な一覧はモジュールカタログを、エンジンとモジュールがどう組み合わさるかはアーキテクチャ概要を参照してください。

どう観測するか：read-first、minimal-data

Olivares AI は read-first です：エンジンはログ、OpenTelemetry、eBPF を通じて観測します。エージェントのデータパスには座りません。そのため、コレクターの障害が本番トラフィックを壊すことは決してありません。そして設計上 minimal-data です：アクセスグラフは関係を保存します — 起点 → リソース、read/write、ソース、confidence、タイムスタンプ — ペイロード、SQL 本体、シークレット、PII は決して保存しません。保存されないものは漏洩しえません。

これがまた、セルフホスト可能でエアギャップに適している理由でもあります。必須のテレメトリはなく、デフォルトではコントロールプレーンからのエグレスもありません。あなたの境界を越えるのは、 あなたがそのように設定したものだけです。具体的には、あなたのモデル API への呼び出し、接続した SIEM／Webhook 出力、用意した場合の外部埋め込みプロバイダーです。Olivares AI はその一覧に含まれず、ベンダーがデータ経路に入ることはありません。当社に接続するのは、お客様が当社に何かを要求したときだけです——olivares upgrade、または商用アドオンとその更新のサブスクリプション経由のダウンロード—— であり、稼働の副作用として接続することはありません。さらに olivares upgrade --endpoint で、その唯一の外向き通信も自前のミラーに向けられます。これはデータレジデンシー、GDPR、エアギャップ環境に対する強力な論拠です。

次にどこへ

試す： zero-to-graph チュートリアルは単一バイナリを起動し、構築された Permitted-vs-Observed グラフに到達します。
理解する： アーキテクチャ概要とセキュリティと脅威モデル。
運用する： セルフホスティングとエアギャップインストール。