ユーザーのすべてのデータを、
ひとつのインターフェースで。移行なしに。
UDBはエージェントが扱うデータプレーンです。DDL不要のランタイム定義テーブルに加え、ユーザーが既に使っているPostgres、MySQL、HTTP API、ファイルストレージへつながる統合アダプター層を備えています — 自然言語で問い合わせでき、すべてのクエリから学習するセマンティックマッピングを持っています。
ドキュメントを読むエージェントには状態を保持する場所が必要です。データベースの移行はその答えではありません。
推論はできても何も永続化できないエージェントは、毎ターン同じ事実を導き直すだけです。プロダクションデータベースへの生の接続を渡せば、言語モデルにシステムオブレコードへの無制御な書き込み権限を与えることになります。代わりにベクトルストアを渡せば、構造を近似的な検索と引き換えにすることになります。UDBはその中間の選択肢です：リクエスト時にDDLなしで定義できるテーブルに、既に使っているシステムへの統制されたアダプターを組み合わせています — データを一切移動させることなく、エージェントに作業できる場所を与えます。
ランタイム定義テーブル
エージェントはリクエスト時にテーブルを作成・拡張します — マイグレーションファイルも、デプロイも、スキーマレビューも不要です。すべてのテーブルは最初の書き込みからテナント単位で分離されています。
既存システムへつながるアダプター
Postgres、MySQL、HTTP API、ファイルストレージが統制されたアダプターを通じて接続されます。データが複製されることはありません — UDBは設定された接続を通じて直接読み書きします。
自然言語クエリ
平易な言葉で質問すれば、UDBが既知のテーブルとアダプターに照らして解釈し、型付きの結果を返します — エージェントが誤りやすいSQL文字列ではありません。
学習するセマンティックマッピング
解決に成功したクエリは意図とスキーマの対応関係を強化します。次に似た質問が来たとき、より速く、より正確に解決されます。
多数のバックエンドを、ひとつのインターフェースで
ランタイムテーブルと外部アダプターは同じクエリインターフェースで応答します。エージェントはどのバックエンドが答えを持っているかを知る必要も、気にする必要もありません。
デフォルトで適用されるテナント分離
すべてのテーブル、アダプター接続、キャッシュされたマッピングはアカウント単位でスコープされます。テナント間アクセスは慣習ではなく構造として不可能です。
ひとつのクエリインターフェース。その先のすべてのバックエンドが同じ方法で応答する。
解決ループ
質問 — クエリが自然言語で届きます — 作業中のエージェントからでも、アプリからの直接呼び出しからでも。SQLもテーブル名も不要です。
解決 — セマンティックマッピングが既知のランタイムテーブルとアダプターのスキーマに照らして確認します。似た形のクエリを過去に解決した実績すべてを活用します。
ルーティング — マッチ結果がバックエンドを決定します：ランタイムテーブルか、Postgres・MySQL・HTTP API・ファイルストレージへのアダプターです。
取得 — バックエンドを直接クエリします — UDBに事前にコピーされるデータはなく、結果はひとつの型付きの形に正規化されます。
返却 — どのバックエンドが実際に応答したかにかかわらず、結果は単一のインターフェースを通じて返されます。
強化 — マッピングが強化されます：これと似た形の次のクエリは、あいまいさが減った状態でより速く解決されます。
テーブルを定義し、自然言語で問い合わせ、アダプターを接続する。
データの複製ではなく、アクセス層です。
設計段階からDDLなし — ランタイムテーブルはマイグレーションファイルではなくAPIを通じて作成・変更されます — エージェントが必要とした瞬間にスキーマ変更が反映されます。
常にテナント分離 — すべてのテーブル、アダプター接続、キャッシュされたマッピングはアカウント単位でスコープされます。テナント間アクセスは構造として不可能です。
データは移動しません — アダプターはPostgres、MySQL、HTTP API、ファイルストレージをそのまま、その場でライブに問い合わせます — UDBが保持するのはマッピングとキャッシュされた結果だけで、システムオブレコードの複製は持ちません。
アダプターは静かに失敗しません — 接続状態はアダプターごとに監視されます。認証情報の破損や接続不能はエラーとして表面化し、古い答えを黙って返すことはありません。
マッピングは検査可能です — 学習されたすべてのセマンティックマッピングは照会・修正が可能です — クエリ解決の過程が ブラックボックスになることはありません。
保持ポリシーは元のシステムに従う — ランタイムテーブルとキャッシュされた結果は設定された保持ポリシーに従い、アダプターはクエリの実行後もソースシステムのデータを複製保持することはありません。
多数のバックエンドをひとつのクエリインターフェースで扱うとはどういうことか。
エージェントが会話の途中でアカウントごとのescalation_ownerを追跡する必要に迫られます。同じターンの中でフィールドを定義し、書き込みます — チケットもデプロイも不要です。
「延滞中で、かつ直近のメールを開いていない顧客は？」という質問は、ランタイムテーブル（メール開封記録）とPostgresアダプター（請求書）の結合として解決されます — エージェントはバックエンドがふたつあったことすら知りません。
注文履歴を抱える10年前のMySQLインスタンスが、アダプターを接続したその日から自然言語で問い合わせ可能になります — ORMもエクスポートも不要です。
ファイルストレージ内のCSVエクスポートのフォルダが、テーブルと同じように応答します — UDBはこれを要約すべき文書としてではなく、問い合わせ可能なソースとして索引化します。
エージェントが初めて「アクティブなエンタープライズアカウント」を尋ねたとき、UDBがスキーマを確認する間わずかな遅延があります。50回目には、直接ヒットします。
エージェントに必要なのはデータ移行ではなく、データプレーンです。
ランタイムテーブル、統制されたアダプター、既に使っているすべてのシステムの上にあるひとつのインターフェース — UDBは邪魔をしません。