アーキテクチャ

ObjectOS をデプロイしたときにマシン上で何が動くのか、どのデータがネットワークの外へ出て、どのデータが出ないのかを実践的な視点で解説します。

メンタルモデルは、薄い 2 つのレイヤーです。

1. メタデータ — objects / views / actions / flows / agents のパッケージ。多くは AI Builder がサンドボックス化されたツール API に対して記述します。手作業で編集される場合もありますが、常にバージョン管理され監査されます。
2. 単一の Node.js ランタイム が、そのメタデータを解釈して動作するアプリケーション — REST API、Console UI、権限、ジョブ、AI ツール — に変換します。これらはすべて 1 つのプロセス内で、あなたのデータベースと通信しながら動作します。

コード生成のステップはなく、「ユーザーが望むものを記述した」状態と「それが稼働している」状態の間にデプロイパイプラインはありません。ランタイムは HITL の承認後に新しいメタデータをホットロードします。

デプロイするもの

ObjectOS インスタンスごとに 1 つの Node.js プロセス。それだけです。

┌─────────────────────────────────────────────────────┐
│                  ObjectOS process                   │
│  ┌───────────────────────────────────────────────┐  │
│  │   HTTP dispatcher  (/ · /api · /_console …)    │  │
│  ├───────────────────────────────────────────────┤  │
│  │   Per-project ObjectKernel (LRU cached)       │  │
│  │   ├─ Auth (Better Auth)                       │  │
│  │   ├─ Security (RBAC + row-level + field)      │  │
│  │   ├─ ObjectQL (data engine, generates SQL)    │  │
│  │   ├─ REST API generator                       │  │
│  │   └─ Capabilities loaded per artifact         │  │
│  │      (audit, storage, jobs, queue, AI …)      │  │
│  └───────────────────────────────────────────────┘  │
└──────────┬──────────────────────────────────────────┘
           │
           ▼
   Your business database
   (Postgres / MySQL / SQLite / Turso / MongoDB)

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

データはどこにあるのか

ObjectOS はホームへ通信しません。テレメトリーもライセンスチェックもありません。インターネットアクセスを完全に遮断しても、無期限に動作し続けます。Air-gapped を参照してください。

リクエストはどのように処理されるか

1. Ingress / TLS termination     (your load balancer)
2. HTTP dispatcher               (security headers, request id)
3. Hostname → project resolution (cached, TTL configurable)
4. Get or build per-project kernel from LRU
5. AuthPlugin    — session cookie, bearer token, or API key
6. SecurityPlugin — RBAC + row-level + field-level checks
7. Route handler — generated REST, declarative action, or custom
8. Data driver   — ObjectQL compiles to SQL / Mongo query
9. Response with X-Request-Id propagated

ステップ 4〜8 は、カーネルがウォームな状態であれば通常 5ms 未満で実行されます。

3 つのレイヤー（統合する場合のみ重要）

ほとんどの顧客は ObjectOS のみをデプロイします。残りの 2 つのレイヤーは、アーティファクトがどこから来るのかを知りたい場合に存在します。

単一のアプリを出荷するだけなら、コントロールプレーンは不要です。CI で objectstack.config.ts → dist/objectstack.json をコンパイルし、その JSON をイメージに含めて出荷します。多数のテナントやアプリを抱える社内アプリ marketplace を運用する場合は、コントロールプレーンがカタログの置き場所になります。

ブートモード

モードは環境変数から自動検出されます。

パフォーマンス特性

なぜこの形なのか

• サイドカーなしの単一 Node プロセス → docker run に収まり、systemd ユニットに収まり、Lambda のような環境に収まる。
• プロジェクトごとのカーネル、LRU キャッシュ → 1 つのインスタンスで多数の小さなアプリを、リクエストごとにウォームアップコストを払うことなく処理できる。
• 宣言されたメタデータの上に生成される API → CI にコード生成のステップはなく、公開すべきクライアント SDK もない。API は構造的にあなたのデータモデルと一致する。
• すべての capabilities は任意のプラグイン → イメージサイズは実際に使うものに応じてスケールする。

次に読むもの

• Production Readiness — 実トラフィックにさらす前のチェックリスト。
• Runtime Configuration — データベース、キャッシュ、シークレットの接続。
• Runtime Capabilities — どの任意パッケージが存在し、何を有効にするか。