ObjectOS
← すべての記事
連携とデータ 一般 公開済み · · 著者 ObjectStack Team

既存の業務システムを移行せずに AI-native にする

すでに動いているデータベースに ObjectOS を接続し、コーディングエージェントでテーブルをオブジェクトとしてモデル化すれば、元のシステムを壊さず、権限の下で実データに AI を載せられます。

  • Data Sources
  • AI-Native
  • Architecture

「業務に AI を入れる」という提案の多くは、暗黙のうちに作り直しを前提にしています。データを新しい基盤へ移し、ワークフローを再実装し、チームを再教育し、移行がうまくいくことを祈る。誰も本当はそこをやりたくありません。CRM、ERP、チケット管理、社内の独自バックオフィスはすでに動いており、データもそこにあります。

ObjectOS の考え方は逆です。移行しない。接続する。

一文でいうと

ObjectOS を既存データベースに向け、必要なテーブルをオブジェクトとして記述すると、AI エージェント、フロー、API、ダッシュボードがそのデータ上で動き始めます。データは適切なシステムへ自動的にルーティングされ、ユーザーがすでに持っている権限で統制されます。

元のアプリケーションは変わりません。行データも移動しません。ObjectOS は、既存システムの上に AI-native で権限を理解する表面を作ります。

具体例

40 テーブルほどある Postgres 製 CRM で営業チームを運営しているとします。取引先、担当者、商談、明細、活動履歴。何年分もの本番データがあり、営業担当は毎日そのアプリを使っています。経営層は、そのデータに自然言語で質問したいと考えています。

「Q2 から滑り落ちたエンタープライズ商談はどれで、誰が担当しているか？」

作り直すなら 6 か月のプロジェクトです。ObjectOS なら、最初の一歩は午後で始められます。

  1. CRM データベースを 読み取り専用 のデータソースとして接続する。
  2. 本当に必要な十数個のテーブルを、コーディングエージェントでオブジェクトとしてモデル化する。
  3. データに質問し、最初の自動化をつなぐ。

CRM には触りません。営業担当も気づきません。同じ行データの上に AI-native レイヤーができます。

概念図

今日どう動くか

1. データベースをデータソースとして接続する

データソースは名前付き接続です。Postgres、MySQL、MongoDB、SQLite などを扱えます。認証情報は環境変数から読み、ソースに直書きしません。最初は分析だけなら、読み取りレプリカや読み取り専用 DB ユーザーを使えば、書き込みは物理的に起きません。

import type { Datasource } from '@objectstack/spec';

export const BusinessDb: Datasource = {
  name: 'business_primary',
  label: 'Business System (Postgres)',
  driver: 'postgres',
  config: {
    connection: {
      host: process.env.BIZ_DB_HOST,
      user: process.env.BIZ_DB_USER,
      password: process.env.BIZ_DB_PASSWORD,
      database: process.env.BIZ_DB_NAME,
    },
  },
  pool: { min: 1, max: 10 },
  active: true,
};

2. コーディングエージェントでテーブルをオブジェクトにする

1 テーブルずつ手で書く必要はありません。Claude Code のようなコーディングエージェントを接続済み schema に向け、実カラム、型、外部キーを読ませ、最初のドラフトを書かせます。

「business_primary に接続し、accounts、contacts、opportunities、line_items から src/objects/<name>.object.ts を生成して。SQL カラムを適切な Field.* 型に対応させ、外部キーは Field.lookup(...) にし、各オブジェクトへ datasource: 'business_primary' を設定して。」

出力はあなたが所有し commit する普通のソースコードです。必要な列を残し、AI に見せたくない列を落とし、ラベル、検証、権限を重ねられます。

3. オブジェクトをデータソースにバインドする

各オブジェクトに datasource を持たせてもよいし、名前空間ごとにルーティングルールを宣言して継承させてもかまいません。

datasourceMapping: [
  { namespace: 'biz', datasource: 'business_primary' },
  { default: true,    datasource: 'default' },
]

データ所在の判断がファイルのあちこちに散らばらず、一か所で管理できます。

4. AI を働かせる

テーブルがオブジェクトになった瞬間、AI レイヤーはそれを扱えます。ObjectOS の list_objects、describe_object、query_records、aggregate_data、data-chat エージェントは ObjectQL を通り、各オブジェクトをバインド先データソースへルーティングします。

ユーザーが「Q2 から滑った商談」を聞くと、エージェントはテーブル全体をプロンプトへ詰めません。biz_opportunity への ObjectQL を作り、ステージやクローズ日の WHERE、担当者への join を使って Postgres 上で実行します。さらに、そのクエリはログイン中ユーザーとして動きます。営業担当が別地域の商談を見られないなら、エージェントも見られません。

なぜ安全か

  • AI はユーザーとして動き、ユーザーを超えない。 オブジェクト、レコード、フィールド単位の権限はプロンプトではなくランタイムで強制されます。
  • 必要なら読み取り専用から始められる。 読み取り専用接続や DB ユーザーにバインドすれば、本番データを安全に分析できます。
  • すべて監査される。 人でもエージェントでも、読み取り、書き込み、昇格は誰が、何を、いつ、なぜ行ったか記録されます。
  • データはあなたのネットワーク内に残る。 ObjectOS はあなたの環境で動きます。

作り直し vs. 接続

新基盤へ作り直すObjectOS で接続する
最初の価値まで数か月午後
記録システムへのリスク高いなし
データの場所移動するそのまま
モデリング手作業で再実装実 schema からエージェントがドラフト
権限作り直し、再監査継承
戻しやすさ難しいデータソースを外すだけ

初日に得られるもの

  • ライブデータに対する自然言語分析。
  • 監査つきの自動化。
  • 同じメタデータから生成される API と Console。
  • 人間と AI に共通する権限モデル。

すでにあるものと、これから来るもの

上の流れは、データソース、オブジェクト別ルーティング、ObjectQL のプッシュダウン、AI エージェント層で今日動きます。オブジェクトモデリングは、接続済み schema に対してコーディングエージェントが行います。

より豊かな turn-key federation、つまり一回の schema import、外部所有 schema へのバインド、組み込みの書き込み安全ゲートは ADR-0015 で設計中です。

よくある質問

すべてのテーブルをモデル化する必要がありますか？ いいえ。AI と自動化に触らせたいテーブルだけで十分です。

本番 DB に書き込みますか？ 許可しない限り書き込みません。読み取り専用接続なら不可能です。

データはモデルプロバイダーへ送られますか？ ObjectOS はあなたの環境で動き、クエリはあなたの DB に対して実行されます。どの AI プロバイダーを使い、何を見せるかはあなたが制御します。

schema が変わったら？ 更新後の schema に対してコーディングエージェントを再実行し、影響を受けるオブジェクトを再生成または diff します。

すでに業務データベースがあるなら、道のりの大半は終わっています。接続し、いくつかのテーブルをモデル化し、データに質問してみてください。