モジュールカタログ
Olivares AI は、ひとつのグラウンドトゥルース（Claude Code が最も深いレベル、Codex と Grok Build がその隣）で エンタープライズにおける AI を統合・管理・保護する。これは モジュール型プラットフォーム であり——1 つの エンジン、1 つのコンソール、そしてカタログ内の 35 個の選択可能なモジュール—— エージェントがどこで稼働しているかを観測し、何を許可されるかをガバナンスし、 （拡大中のサブセットにおいて）実際のインフラに対して作用する。すべてのモジュールは、 (a) コアから正規化されたイベント／データを消費し、(b) 自身のエンティティを共有データ モデルで宣言し、(c) 自身の API エンドポイントと UI ビューを公開する——コアや他の モジュールに一切触れることなく。
35 個の選択可能なモジュールは 32 個のモジュールパッケージで実装され、governance パッケージが 4 つの独立して選択可能なモジュールを提供する。これらは、以下の 9 つの能力領域 で整理される。各モジュールのステータスは
2 つの半分 として読むこと。すなわち Govern/Observe（カタログ化・観測・ゲート・
レポート）は今日すでに構築・配線済みである。一方 Actuate（実際のインフラに対して作用
する——deploy・dispatch・send・enforce・run）は率直な状態に分かれる——サブセットでは
デフォルトバイナリにおいて live、いくつかでは on-demand（バックエンドは構築・
配線済みで注入ポイントに接続されているが、オペレータが env 設定でプロビジョニングする
までは deny-closed あるいは縮退状態にとどまる）、サーフェスがゲート／オプトインのところ
では PARTIAL、残りについては宣言された deny-closed seam。特に deploy は
デプロイメントを計画・ガバナンスするが、エグゼキュータがプロビジョニングされるまでは
ライブインフラに 適用しない。すなわち apply／retire は明確な 503 を返す。deploy は Business の機能で、Community はすべての deploy ルートに 501 を返す。
深さはモジュールによって異なり、製品の多くは注記のとおり pre-1.0／設計段階にある
（誠実さと限界 を参照）。
access map（iii-access-map）——各エージェントが何に触れることができ、実際に何に
触れているかの read/read-write グラフであり、最小権限ドリフト = Permitted ≠ Observed——
は、35 個のうち最も有用な能力のひとつ であって、製品の全体ではない。広がりこそが
要点である。すなわち 9 つの領域、1 つのエンジン、1 つのコンソールである。
35 個の選択可能なモジュール、能力領域別
Section titled “35 個の選択可能なモジュール、能力領域別”各行はそのモジュールのページ（/reference/modules/<slug>/）にリンクする。Actuate
列は作用する半分の率直な状態であり、— はそのモジュールが本質的にガバナンス／観測を
行い、アクチュエーション・サーフェスを持たないことを意味する。
Observe
Section titled “Observe”| モジュール | Actuate | 目的 |
|---|---|---|
| インベントリと発見 | — | コネクタが観察したエージェント、セッション、MCP サーバー、ツール、モデル、アイデンティティを発見しカタログ化する。 |
| ライブ運用とセッション | — | 各エージェントとセッションのリアルタイム状態。ガバナンス対象の Claude Code セッションランタイムもホストする。 |
| アクセスとリソースマップ（R/RW） | — | 各エージェントが何にアクセスするか、そして読むのか書くのか。最小権限ドリフト = Permitted ≠ Observed。 |
| オーケストレーションと A2A | on-demand | ライブの委任／通信グラフを観測しガバナンスする。dispatch は on-demand で配線され、プロビジョニングされるまで deny-closed。 |
| MCP、スキル、ケイパビリティ | — | エージェントのツールとケイパビリティを視覚的にガバナンスする。 |
| Health、SLA、稼働時間 | — | estate のエージェントと MCP サーバーの信頼性。チェック、インシデント、依存関係マップ。 |
| オブザーバビリティ read-model | — | エンジン自身を表す read-model。ピン留めされた相互運用標準、W3C 相関の台帳／トレースビュー、サプライチェーン・アテステーション。 |
| Claude Code アダプション | — | Claude Code のアダプション／生産性の read-model。セッション、コード行数、コミット、PR、ツールの accept-reject、モデル別トークンを、チーム／開発者／日ごとに集計。デフォルトはチーム単位、開発者単位のドリルダウンは opt-in。Claude-API のみの境界。コストは決して持たない。 |
| Live-ingest | PARTIAL | コネクタが発行できない detective イベントのインプロセス・プロデューサー。env ゲート、deny-closed、最小データ。 |
Govern & enforce
Section titled “Govern & enforce”| モジュール | Actuate | 目的 |
|---|---|---|
| アイデンティティ、権限、ガバナンス | — | 誰が・何が・何をできるかを粒度高く。Cedar RBAC + deny-overlay + scoped grants、ロスター調整、scoped admin／カスタムロール、break-glass、kill-switch。 |
アイデンティティ（identity） |
— | 読み取り専用のワークロードアイデンティティフェデレーション、SSO、外部キー、レジデンシーのポスチャ。 |
| ソースと資格情報のスコーピング | — | ソースをワークスペース／エージェントグループにバインドする。解決時の deny-closed scoped resolver + scoped 資格情報。 |
| デプロイメントと統合 | Business、on-demand (503) | Business の機能。Community は 501 を返す。実際のインフラへのデプロイメントを計画・ガバナンスする。エグゼキュータは on-demand —— ライブの apply／retire はプロビジョニングされるまで 503 を返す。 |
| 管理された Git 公開 | on-demand | 承認済みの Git ホスト設定と現在の権限に基づき、コミットの push、プルリクエストの作成とマージを行い、結果を記録します。 |
Identity は、読み取り専用のアイデンティティポスチャコンソールのための、独立して選択可能なモジュールである。governance パッケージを共有し、認可モデルとアイデンティティのライフサイクルを所有する governance を必要とする。同じパッケージでもモジュールスイッチは別である。
Claude & エージェントエコシステム
Section titled “Claude & エージェントエコシステム”| モジュール | Actuate | 目的 |
|---|---|---|
Claude Code 管理ポリシー（claude-policy） |
— | 管理ポリシーを検証・プレビューする。Business ではフリート全体に公開し、配布と観測されたドリフトを確認する。 |
Claude エージェントの確認（claude-agents） |
— | 管理エージェントのスレッドイベントを読み、保留中のツール確認を承認または拒否する。 |
| スキルカタログと割り当て | — | 不変のスキルカタログと固定された割り当て：ダイジェスト検証済みパックを /v1/m/skills/packs 配下にインストールし、ターゲットごとにピン留めし、その場で編集されることはない。 |
| モデルとプロバイダの管理 | on-demand (503) | モデル／プロバイダのスタック全体にわたってガバナンスする。model-access、サーフェスごとの context-window、model-group ゲート。モデルの 実行 は on-demand —— 推論資格情報がプロビジョニングされるまで 503。 |
| インライン推論プロキシ | PARTIAL | インラインの /v1/messages PEP プロキシ向けのテナント単位の inference-egress 設定 + DLP。モジュール設定は live、リスナーは opt-in、loopback デフォルト、fail-CLOSED。 |
| 内部カタログとマーケットプレイス | — | 承認済み／署名済みのエージェント、MCP サーバー、スキルのキュレーション済みマーケットプレイス。 |
| ボイスとリアルタイム・エージェント | on-demand | 会話型／リアルタイム・エージェントを観測しガバナンスする（default-DENY、two-phase HITL）。メディアストリームを開くことはない。dispatch は on-demand。 |
セキュリティとデータ保護
Section titled “セキュリティとデータ保護”| モジュール | Actuate | 目的 |
|---|---|---|
| セキュリティ、ガードレール、監査 | live | ガードレール（PII／インジェクション／ジェイルブレイク）、アノマリー、インシデント・タイムライン。BYOK/DLP/RTBF/retention/WORM/residency はこのプレーンに存在する。 |
| 特権セッションの記録 | live | PAM 準拠の特権セッション記録。hash-chained フレーム、書き込み時の秘匿化、ledger-anchored。 |
| データ、ナレッジ、コンテキスト | on-demand | ガバナンス対象のデータプレーン。KB + RAG、ガバナンス対象のリトリーバル、リネージ、プロンプトレジストリ、エージェントメモリ。モデルベースの意味的エンベディングは on-demand。 |
コンプライアンスと証跡
Section titled “コンプライアンスと証跡”| モジュール | Actuate | 目的 |
|---|---|---|
| コンプライアンスと規制 | — | 26 のフレームワーク・カタログ + 封印された台帳由来の証跡。ライブのチェーン検証付き。 |
| SIEM/ITSM フォワーダー | live | 封印された台帳 + findings を SIEM タワーに送出する（OCSF 1.8/CEF/LEEF/syslog/OTLP）。leader-gated なカーソルウォーク、at-least-once。 |
| Posture export | PARTIAL | コントロールタワー向けの読み取り専用の posture／インベントリ・プル（ニュートラル JSON）。検証済みのダウンストリーム・プッシュを主張 しない。 |
| Reporting | — | プラットフォームのコンプライアンス、監査、FinOps データからプロフェッショナルな PDF/HTML レポートを生成する。5 種類を内蔵し、監査担当者は JSON をコピー＆ペーストせず文書をダウンロードできる。 |
FinOps
Section titled “FinOps”| モジュール | Actuate | 目的 |
|---|---|---|
| コストと AI FinOps | live | 上限で deny／throttle する作用型予算、cost-per-outcome、キャンセルリスク。予算はアイデンティティに固定される。 |
Evals & safety
Section titled “Evals & safety”| モジュール | Actuate | 目的 |
|---|---|---|
| 品質、evals、テスト | — | キャリブレーション済みの LLM-judge + ブロッキングな CI 回帰ゲート。オフラインの judge → SKIPPED であり、決して暗黙のパスにはならない。 |
| エージェント・サンドボックス | on-demand | 本番投入前にエージェントをテストする安全な環境。実際の OS 分離（gVisor/Firecracker）は on-demand。 |
| レッドチーミングと敵対的テスト | on-demand | 同意ゲート付きの敵対的バッテリー。サンドボックス・ランタイムがプロビジョニングされるまで DEGRADED —— 決して偽のパスにはならない。 |
プラットフォームと統合
Section titled “プラットフォームと統合”| モジュール | Actuate | 目的 |
|---|---|---|
| 出力統合と通知 | live | 企業がすでに運用しているシステムへの通知ルーター。dispatch はライブで配線され、宛先はオペレータがプロビジョニングする。 |
| Eventing | live | バス上の外部サブスクリプション・サーフェス。型付きサブスクリプション、durable な at-least-once 配信、retry/backoff、DLQ、カーソルリプレイ。 |
| 保存済みコンソールビュー | — | コンソールビューの状態（フィルター、範囲）に名前を付けて共有できるスナップショット。テナントごとにサーバー側に保存される。調査を保存し、チームと共有する。ビューパラメータ用の JSON オブジェクト（上限 4096 バイト）を受け付けます——機密データやクエリ結果は保存しないでください。作成・更新はオーナーのみ。テナントの管理者/オーナーとスーパー管理者はクリーンアップのため削除できます。すべての変更は監査されます。 |
Actuate 列：live = アクチュエーションが配線され、デフォルトバイナリでライブで動作し、
プロビジョニング不要（例：FinOps の予算強制は上限で deny し、通知ルーターは dispatch する）。
on-demand／on-demand (503) = バックエンドは構築・配線済みで注入ポイントに接続されている
が、オペレータが env 設定でプロビジョニングするまでは deny-closed あるいは縮退状態に
とどまる（deploy は Business の機能で、Community では 501、エグゼキュータが存在するまでは 503 を返す。orchestration／voice の
dispatch は設定されるまで deny-closed。red-team はサンドボックス・ランタイムがプロビジョ
ニングされるまで DEGRADED で動作する。モデル実行と意味的エンベディングは資格情報が
プロビジョニングされるまで 503 を返す）。PARTIAL = サーフェスは実在するがゲート／
オプトインであるか、検証済みのダウンストリームを主張しない（inference-proxy リスナーは
opt-in かつ loopback デフォルト。live-ingest は env ゲート。posture-export はニュートラルな
読み取り専用の射影である）。— = そのモジュールは本質的にガバナンス／観測を行い、
アクチュエーション・サーフェスを持たない。この分割こそが率直な契約である。すなわち製品は
今日、広範に観測しガバナンスし、拡大中の——大部分がプロビジョニング・ゲート付きの——
サブセットに対して作用する——誠実さと限界 を参照。選択可能なカタログは core/modulespec/modules.json から導出され、olivares modules ls とコンソールのエディションとモジュール一覧も同じソースを使う。npm run test:modules は各選択可能な名前空間に参照ページがリンクされていることと、その数を検証する。
エディションの可用性継ぎ目（35 個の選択可能なモジュールには数えられない）
Section titled “エディションの可用性継ぎ目（35 個の選択可能なモジュールには数えられない）”上のカタログは、共有モジュール仕様にある 35 個の選択可能なモジュールを網羅する。それとは別に、Community は session-cockpit API 名前空間の下に可用性ディスクリプタを登録する。それら 35 のひとつではない。
- セッションコックピット（可用性） —
Community ではハンドラなし。
/v1/m/session-cockpitは欠如による 404 を 返す。この成果物に対話型コックピットはない。ライブセッション、AgentOps、 公式 CLI ライフサイクルはオープン製品に残る —— ライブ運用とセッション および Olivares で Claude Code を実行する を参照。
プラットフォームとコアのケイパビリティ（35 個の選択可能なモジュールには数えられない）
Section titled “プラットフォームとコアのケイパビリティ（35 個の選択可能なモジュールには数えられない）”これらは実在し、出荷済みのケイパビリティであるが、エンジン／コア／Web のケイパビリティであって、独立して選択可能なモジュールではない——したがって 35 には数えられない。
- 独自 API + manage-as-code —— エンジン／コアのケイパビリティ。 エンジン自身のバージョン管理された REST/gRPC API に 加えて Terraform プロバイダ。プラットフォーム自体を API と IaC で管理する。
- マルチテナンシーと組織管理 —— エンジン／コアのケイパビリティ。 組織階層と委任された管理。Postgres の行レベル セキュリティによるテナント分離付き。
- エグゼクティブ・ダッシュボード —— Web のケイパビリティ。 技術系 UI と並ぶリーダーシップ向けコンソールビュー。 （レポート生成バックエンドは reporting モジュールであり、 35 のひとつとして数えられる。）
- モデルオペレーション（自社モデル） —— models モジュールのケイパビリティ（モジュール X の行を通じて数えられ、独立した 行ではない）：自社モデルの統治されたレジストリ、署名済みモデルのアドミッション、 データセット／ファインチューニングジョブのリネージ記録、ローカル推論デプロイメントの 統治、AIBOM／モデルカード証跡。
計画中： 自社モデルのファインチューニングとローカル推論の実行 （xxiii-fine-tuning）—— プラットフォームは 今日その作業を統治し記録する（上記のモデルオペレーション参照）が、自ら訓練を実行したり 推論を提供したりはしない。実行する側の半分は文書化された計画中の作業であり、 未出荷で、35 のひとつでもない。
モジュールが API とバスにどう現れるか
Section titled “モジュールが API とバスにどう現れるか”- REST。 API リファレンス は、製品の OpenAPI 3.1 契約から安定コアの
REST サーフェスを描画する。モジュールルート（
/v1/m/<ns>/…）は、独立した beta ドキュメントとして module-route リファレンス で公開される。 そのフィールドレベルの契約は製品の型付きインターフェイスに存在する。 - イベント。 モジュールは イベントバス に反応する。すなわち
access map は
edge.observedを消費し、FinOps はcost.sampledを消費し、security はfinding.reportedとguardrail.observedを消費する。
35 個の選択可能なモジュールは、上記のエンジン／コアおよび Web のケイパビリティと並んで、エンジン上の レイヤーの上に構築される。
- Engine（layer 0） —— 独自 API／manage-as-code とマルチテナンシーのケイパビリティ （コアであり、35 には数えない）。
- Core（layer 1） —— inventory、sessions、access-map、models、health、observability。
- Management（layer 2） —— capabilities、governance、identity、claude-policy、claude-agents、skills、sourcescope、deploy、gitpublish、knowledge。
- Intelligence（layer 3） —— orchestration、security、recording、inference proxy、 finops、evals、compliance、reporting、siemforward、posture-export、catalog、notify、eventing、 voice、sandbox、redteam、live-ingest、consoleviews。
- Web（layer 4） —— UI とエグゼクティブ・ダッシュボードのケイパビリティ。
エンジンとこれらのレイヤーがどう構成されるかは アーキテクチャ概要 を参照。