ObjectOS既存システムの拡張
すでに運用しているデータベースを外部データソースとして ObjectOS にフェデレーションし（デフォルトで読み取り専用、まだ初期段階）、マイグレーションなしでそのテーブルをオブジェクトとしてモデル化します。
ObjectOS を評価しているチームの多くは、すでに記録システムを持っています。CRM、ERP、チケット管理ツール、本番の SQL や MongoDB データベース上で動く自社製のバックオフィスなどです。問われるのは「捨てて作り直すべきか？」であることはまれです。「危険なマイグレーションなしで、すでにあるものと一緒に使えるか？」です。
まずひとつの境界を示します。このページが約束できる範囲を決めるものだからです。ObjectOS が実行するオントロジーは既存システムの上に載るセマンティックレイヤーではありません。それ自体がシステムであり、データベース、API、UI、エージェントのツールはそこから導出されます。すでに運用しているシステムに対して提供できるものはそれより狭く、ObjectStack の README が述べるとおりに表現すると、外部データソースのフェデレーションはデフォルトで読み取り専用で、まだ初期段階です。 データベースをデータソースとして接続し、関心のあるテーブルをオブジェクトとしてモデル化すると、ObjectOS は他のすべてと同じ権限モデルを通じてそれを読み取ります。記録システムは記録システムのままです。
移行の形
業務システムを置き換えるのではありません。ObjectOS をその隣に置き、同じデータベースに向けます。
- 既存のデータベースを外部データソースとして接続します（
schemaMode: 'external'）。ObjectOS はそれに対して DDL を実行せず、オプトインするまで書き込みはオフのままです。パスワードはシークレットストアに保存され、データソースには決して置かれません。読み取りしかできないデータベースユーザーで接続し、書き込みは意図して有効にしてください。 - テーブルをオブジェクトとしてモデル化します。手で行うか、コーディングエージェントにスキーマをスキャンさせ、ソースレベルのオブジェクトファイルを生成させます。
- 各オブジェクトをデータソースにバインドします（オブジェクトごと、または名前空間全体のルーティングルールで）。
- 読み取ります。テーブルがオブジェクトになった瞬間から、すべてのビュー、ダッシュボード、フロー、エージェントのツールがそれを読み取れ、正しいデータベースに自動的にルーティングされ、同じ権限で制御されます。
レガシーアプリケーションは何も変わりません。行は元の場所にとどまり、レガシーアプリケーションはそれを書き込み続けます。
書き直しなしで機能する理由
| 懸念 | ObjectOS の対応 |
|---|---|
| 「データを移動できない」 | データは決して移動しません。ObjectOS はデータベースにその場で接続します。 |
| 「本番への書き込みのリスクは取れない」 | フェデレーションはデフォルトで読み取り専用です。書き込みには、データソースでのオプトイン（external.allowWrites: true）と各オブジェクトでのオプトイン（external.writable: true）が必要です。SELECT だけを許可されたデータベースユーザーは、ObjectOS の内外を問わず、すべての経路でそのとおりに保たれます。 |
| 「すべてのテーブルのモデル化には何週間もかかる」 | コーディングエージェントがスキーマをスキャンし、テーブルごとにオブジェクトファイルを 1 つ生成します。あなたは確認して仕上げるだけで、手で打ち込む必要はありません。 |
| 「AI にデータを任せられない」 | エージェントはサインインしたユーザーとして実行され、オブジェクトレベル、レコードレベル、フィールドレベルの権限に従います。背後にいる人以上のものを見ることはありません。 |
| 「データをネットワークの外に出せない」 | ObjectOS Enterprise では、ObjectOS はあなたの環境で動作します。業務データとプロンプトは境界の内側にとどまります。 |
コーディングエージェントでオブジェクトを生成する
既存のスキーマを取り込む最速の方法は、コーディングエージェント（Claude Code など）を使って業務テーブルをスキャンし、ソースレベルのオブジェクト定義を生成することです。テーブルごとに *.object.ts ファイルを 1 つ作ります。
hotcrm リファレンスアプリは、その出力が取るべき正確な形を示しています。各テーブルは src/objects/<name>.object.ts になり、型付きの Field.* 定義と外部キー用の Field.lookup(...) を使った ObjectSchema.create({ … }) で表され、defineStack で組み立てられます。エージェントは接続されたデータベースをイントロスペクトし、列をフィールドの型に対応付け、あなたが所有しコミットするオブジェクトを書きます。合うものは残し、公開したくない列は削除し、その上にラベル、検証、権限を追加します。
完全な手順の作成ガイドはデータソースを参照してください。
初日から得られるもの
テーブルが既存のデータベースにバインドされたオブジェクトとしてモデル化されると、次のものが得られます。
- 自然言語による分析。 ユーザーは実際のレコードについて質問します。「今四半期に遅れた商談はどれで、担当者は誰か？」。答えは ObjectQL を通じてライブデータに対して計算されます。
- ガバナンスの効いた自動化。 フローとアクションは同じデータを読み取り、書き込みを有効にしている場合は書き込みます。すべてのステップが監査されます。
- 生成された API と UI。 REST エンドポイントと管理画面は同じメタデータから生まれます。
- ひとつの権限モデル。 人に適用される境界が、AI のトラフィックにもまったく同じように適用されます。
まだできないこと
フェデレーションは初期段階です。成熟しているのは読み取りの経路だと考え、各データソースプロトコルが現在何をサポートしているかは、データソースとフレームワーク自身の External Datasources ガイドで確認してください。多くのシステムを、そのどれも実行せずに記述するセマンティックレイヤーが必要なら、それは別の種類の製品です。
ここから始める
- データソース：データベースを接続し、オブジェクトをバインドし、クエリをルーティングする
- AI エージェント：オブジェクトの上の宣言的なエージェント
- 権限：AI が継承するモデル
- ObjectOS Community をローカルで実行する：オープンなランタイムを数分で立ち上げる