アーキテクチャ

ObjectOS をデプロイしたときに何が動くのか（ObjectOS Enterprise で自社のマシン上で動かす場合も、ObjectOS Cloud で私たちが運用する場合も）、どのデータがネットワークの外に出て、どのデータが出ないのかを、実践的な視点から説明します。

メンタルモデルは、ひとつの定義と、それを実行するひとつのランタイムです。

1. あなたのオントロジー：ビジネスの定義です。オブジェクトとフィールド、リレーション、アクション、権限、フロー、そしてエージェントとツールの定義。ビュー、ダッシュボード、アプリ、翻訳は、そのプロジェクションとして横で作成されます。ほとんどはサンドボックス化されたツール API を通じて AI Builder が書き、ときには手で編集されます。実行される前に必ず検証され、バージョン管理され、監査されます。
2. 単一の Node.js ランタイム：そこから動作するアプリケーション（データベーススキーマ、REST API、Console の UI、エージェントが呼び出す MCP サーバー）を導出し、すべての呼び出しでそれを強制します。RBAC、行レベルとフィールドレベルのセキュリティ、共有、監査は、REST のリクエストにも、Console でのクリックにも、エージェントのツール呼び出しにも同じように適用されます。すべてがひとつのプロセスの中で、あなたのデータベースと通信します。

your ontology
  objects · relations · actions
  permissions · flows · agents
  + projections: views · dashboards
    apps · translations
      │
      ▼
ObjectOS runtime
  derives the app, enforces it
      │
      ├──▶ database    its schema
      ├──▶ REST API    /api/v1/*
      ├──▶ Console     /_console/
      └──▶ MCP server  /api/v1/mcp

「ユーザーが望むものを説明した」と「それが稼働している」の間に、コード生成の手順もデプロイのパイプラインもありません。ランタイムは、ヒューマンインザループ（HITL）の承認の後に新しいメタデータをホットロードします。

デプロイするもの

ひとつのアプリを提供する、ひとつの Node.js プロセス。それだけです。ObjectOS Community では、オープンソースのイメージからそのプロセスを自分で実行します（os start）。ObjectOS Cloud では私たちが実行します。ObjectOS Enterprise では、デプロイで説明しているライセンスされた Enterprise イメージからデプロイします。

┌─────────────────────────────────────────────────────┐
│                  ObjectOS process                   │
│  ┌───────────────────────────────────────────────┐  │
│  │   HTTP dispatcher  (/ · /api · /_console …)   │  │
│  ├───────────────────────────────────────────────┤  │
│  │   ObjectKernel — this deployment's app        │  │
│  │   ├─ Auth (Better Auth)                       │  │
│  │   ├─ Security (RBAC + row-level + field)      │  │
│  │   ├─ ObjectQL (data engine, generates SQL)    │  │
│  │   ├─ REST API generator                       │  │
│  │   ├─ MCP server  (/api/v1/mcp, on by default) │  │
│  │   └─ Capabilities loaded per artifact         │  │
│  │      (audit, storage, jobs, queue, AI …)      │  │
│  └───────────────────────────────────────────────┘  │
└──────────┬──────────────────────────────────────────┘
           │
           ▼
   Your business database
   (Postgres / MySQL / SQLite / Turso / MongoDB)

複雑さは、静的にリンクされた単一のバイナリ程度です。サイドカーも、Kafka も、別のキャッシュレイヤーも必要ありません。必要になったときに追加すればよく、初日からそのコストを払う必要はありません。

デプロイメントはひとつのアプリを提供します。 どのアプリかはデプロイメントレベルの判断であり（起動モードを参照）、デプロイメントが提供するすべての人にとって同じアプリです。複数の組織が共有する、壁で区切られたデプロイメントでも同様です。デプロイメントを拡張するには、ひとつのプロセスに多くのアプリを詰め込むのではなく、同じプロセスの同一のレプリカを増やします。Docker を参照してください。

データの置き場所

ObjectOS Enterprise（この表が記述するセルフマネージドのエディション）では、以下のものはどれもネットワークの外に出ません。ObjectOS Cloud では、同じプロセスが代わりに私たちのインフラストラクチャで動作します。どちらのエディションでも、オントロジー自体は通常の ObjectStack メタデータです。エクスポートしてオープンソースの ObjectStack ランタイムで実行する機能は計画中です。データレジデンシーには、データの各分類について、どこに保存され、ネットワークの外に出るかどうかが記載されています。

セルフマネージドの ObjectOS はライセンスをオンラインで検証します。Enterprise のエアギャップライセンスはオフラインで検証します。したがって、インターネットにまったくアクセスできないデプロイメントも動作し続けます。サポートされるライセンスとクラウドの姿勢の組み合わせについては、エアギャップを参照してください。

リクエストの処理

1. Ingress / TLS termination      (your load balancer)
2. HTTP dispatcher                (security headers, request id)
3. AuthPlugin     — session cookie, bearer token, or API key
4. SecurityPlugin — RBAC + row-level + field-level checks
5. Route handler  — generated REST, MCP tool call, declarative action,
                    or custom
6. Data driver    — ObjectQL compiles to SQL / Mongo query
7. Response with X-Request-Id propagated

エージェントの呼び出しも同じ経路をたどります。MCP クライアントは OAuth または API キーでユーザーとして認証し、同じ権限のチェックが、そのツール呼び出しが読み書きできる範囲を制限します。AI ツールを接続する（MCP）を参照してください。

アプリは最初のリクエストが届く前にすでに解決されています。カーネルは起動時に構築され、それが終わるまでプロセスは準備完了を報告しません。そのため、提供されるリクエストには、それがどのアプリに属するかを決める手順がなく、読み手が考慮すべきアプリごとのウォームアップもありません。リクエストのコストは、認証、権限のチェック、そしてコンパイル済みのクエリ 1 つです。

3 つの層（連携する場合にのみ重要）

ほとんどの顧客は ObjectOS だけを実行します。他の 2 つの層は、アーティファクトがどこから来るのかを知りたい場合のためにあります。

単一のアプリを出荷するなら、コントロールプレーンは不要です。CI で objectstack.config.ts → dist/objectstack.json をコンパイルし、その JSON をイメージに入れて出荷します。複数のデプロイメントがインストールするアプリを公開する場合は、コントロールプレーンがそのカタログの置き場所になります。

起動モード

実行中のアプリがどこから来るかはひとつの判断であり、デプロイメントがそれを宣言します。提供されるデフォルトは設定が不要です。その他の各モードは公開済みのアーティファクトを指定することで選択され、それぞれの正確な契約は環境変数のリファレンスにあります。

デプロイメントがコントロールプレーンとも通信するかどうかは別の判断であり、クラウドの姿勢の変数で決まります。接続されたデプロイメントは、上記のどのモードでもかまいません。セルフマネージドのランタイムは、ファイルに貼り付けたキーではなく、デプロイメントがコントロールプレーンにバインドされたときに発行されたトークンで認証します。間違ったライセンスモードと間違ったクラウドの姿勢の組み合わせは、起動時に拒否されます。

性能の特性

このページはレイテンシやメモリの数値を掲載しません。 実行するのは、あなたのデータベースに対してあなたのアプリを提供する、ダイジェストで固定したイメージであり、デプロイメントのサイジングに使う価値のある数値は、それを実際に計測したものだけです。このページが示せるのはその形です。各コストがどこから来るか、そしてそれを何として計測すべきかです。

なぜこの形なのか

• ひとつの Node プロセス、サイドカーなし → docker run に収まり、systemd のユニットに収まり、長時間動作するコンテナや VM に収まります。
• デプロイメントごとにひとつのアプリ → メタデータはリクエストごとではなく起動時に一度だけ解決されるため、正しく設定すべきキャッシュのサイズがありません。複数の組織がデプロイメントを共有する場合も、組織はそのアプリを共有し、組織間の分離の壁はランタイムの内部で強制されます。
• 宣言されたメタデータの上に生成される API → CI にコード生成の手順はなく、公開すべきクライアント SDK もありません。API は構造上、データモデルと一致します。
• すべての機能はオプションのプラグイン → イメージのサイズは、実際に使うものに応じて増減します。

次に進む

• 本番環境への準備：実際のトラフィックに公開する前のチェックリスト。
• ランタイム設定：データベース、キャッシュ、シークレットの接続。
• ランタイムの機能：どのオプションのパッケージがあり、何を有効にするか。