業務データ、リアルタイム分析、AIワークロード——これまでバラバラだったものをひとつのデータベースに。OceanBase AI Database 詳細はこちら ->
業務データ、リアルタイム分析、AIワークロード——これまでバラバラだったものをひとつのデータベースに。OceanBase AI Database 詳細はこちら -> ->
OceanBaseには、AI_COMPLETE、AI_EMBED、AI_RERANK、AI_PROMPT、AI_SPLIT_DOCUMENT という5つのSQL組み込み関数があります。これらを使うと、テキストのチャンキング、ベクトル化、検索結果の再ランキング、テキスト生成といった処理をデータベースの中で扱えます。ベクトル検索やハイブリッド検索と同じエンジン上で動くので、RAGの一連の流れをSQLでそのままつなげて書けます。
OceanBaseでは、LLMの機能をデータベース関数として利用できます。使い方はUPPER()やSUM()に近く、モデルのエンドポイントを登録しておけば、あとはSQLから直接呼び出すだけです。この記事では、各関数でできること、接続方法、エンドツーエンドのパイプライン、それからよくあるユースケースを順に見ていきます。
AI Functionは、OceanBaseのデータベースから外部のLLM APIを呼び出せる仕組みです。イメージとしては、HTTPクライアントがデータベース側に組み込まれていると考えると分かりやすいでしょう。システムテーブルでモデルのURLやAPI Keyなどの情報を格納し、SQLの実行時にOpenAI互換形式のリクエストを組み立てて外部APIを呼び出します。返ってきたレスポンスを解析し、その結果をSQLの呼び出し元に返します。
処理の流れは以下のとおりです。
SQLクエリ → エンドポイントキャッシュからモデル情報を取得 → リクエストを作成 → HTTPでLLMを呼び出し → レスポンスを解析 → 結果を返却
ユーザー側で必要な作業は、2つだけです。
ステップ 1:モデルを登録する(初回のみ)
CALL DBMS_AI_SERVICE.REGISTER_PROVIDER('my_llm', '{
"access_key": "sk-xxxx"
}');
※AI_SPLIT_DOCUMENTやLOAD_FILEで外部文書を読み込むだけであれば、モデルの登録も必要ありません。
ステップ 2:通常のSQL関数と同じように呼び出す
SELECT AI_COMPLETE('my_llm', 'OceanBase を一文で紹介してください') AS answer;
一度登録しておけば、その後は繰り返し呼び出せます。モデルはあとから差し替えられますが、SQL側の呼び出し方は変わりません。OceanBaseはOpenAI、DeepSeek、Alibaba Cloud Bailian、SiliconFlowなど、複数ベンダーのモデルに対応しています。用途やコスト、求める精度に応じて選べます。
OceanBase Cloudを使っている場合は、さらに手軽です。 クラウド環境には、無料で使える3つの組み込みモデル(OB_Complete、OB_Embed、OB_Rerank)が用意されています。インスタンス作成後は、追加設定なしでそのままSQLから利用できます。
OceanBaseのAI Functionサービスでは、テキスト処理、ベクトル埋め込み、検索結果の並べ替え、テキストチャンキングなど、AI活用に必要な処理を支える5つの関数が用意されています。
※利用時の注意点 この章のサンプルで使っているモデル名(my_llm、my_embed、my_rerank)は、いずれも説明用のプレースホルダーです。実際に試すときは、次の点を確認してください。 前述の「ステップ 1:モデルを登録する」に沿って、用途に合ったモデルを登録し、URL と ACCESS_KEY を有効な値に置き換えてください。 サンプルで参照している業務テーブル(reviews、knowledge_base、kb_chunks など)は、あらかじめ作成しておく必要があります。 OceanBase Cloudを使っている場合は、無料の組み込みモデルである OB_Complete、OB_Embed、OB_Rerank をそのまま利用できます。登録は不要で、サンプル中のモデル名を対応する組み込みモデル名に置き換えるだけです。 AI_PROMPT と AI_SPLIT_DOCUMENT はモデル登録に依存しないため、そのまま実行できます。
AI_COMPLETE:生成や分析をSQLから呼び出すAI_PROMPT() と組み合わせることで、プロンプトテンプレートを動的に組み立てられます。例:レビューの感情分析をまとめて実行する
SELECT id, AI_COMPLETE('my_llm',
AI_PROMPT('次のレビューの感情を判定してください:ポジティブ/ネガティブ/中立。レビュー:{0}', content)
) AS sentiment FROM reviews;
このSQLだけで、テーブル内のレビューに感情ラベルをまとめて付けられます。アプリケーション側で個別にバッチ処理のスクリプトを書く必要はありません。
※この例は、my_llm というモデルが登録済みで、有効なエンドポイントが設定されており、reviews テーブルが存在することを前提にしています。登録の手順は、前述の「ステップ 1:モデルを登録する」を参照してください。OceanBase Cloudを使っている場合は、登録なしで組み込みモデル OB_Complete を利用できます。
AI_EMBED:テキストをベクトル化するdim パラメータで出力ベクトルの次元数を指定でき、利用するモデルに合わせて調整できます。FLOAT 配列です。ベクトル列にそのまま保存でき、ハイブリッド検索インデックスと組み合わせれば、登録後すぐに検索対象にできます。例:ドキュメントをDBに登録する際に自動でベクトル化する
INSERT INTO knowledge_base (title, content, embedding)
VALUES (
'OceanBase 概要',
'OceanBase はネイティブ分散データベースです…',
AI_EMBED('my_embed', 'OceanBase はネイティブ分散データベースです…')
);
従来は、Embedding(ベクトル化)処理をアプリケーション側のスクリプトからAPI経由で呼び出し、その結果をデータベースに書き戻す構成になりがちでした。AI_EMBED を使えば、その処理を INSERT 文の中にまとめられます。同じトランザクションの中で元テキストとベクトルを一緒に保存できるので、データの整合性も保ちやすくなります。
AI_RERANK:検索結果を並べ替えるquery と documents 配列を入力すると、並べ替え後のインデックスと関連度スコアを返します。例:検索後に候補を再ランキングする
SELECT AI_RERANK('my_rerank',
'軽量で薄型のノートパソコンのおすすめ',
ARRAY['MacBook Air M3 チップ 13.6 インチ...',
'ThinkPad X1 Carbon 第 12 世代...',
'ROG ゲーミングノート RTX4070 16GB...']
) AS ranked_results;
この例では、「ゲーミングノート」は「ノート」という語を含んでいても、上位には来にくくなります。ユーザーが求めている条件は「軽量」「薄型」であって、「ゲーミング」ではないとモデルが判断するためです。こうした意味レベルでの並べ替えは、キーワード検索だけではうまく扱いにくい部分です。
AI_PROMPT:プロンプトを組み立てる実際のアプリケーションでは、AI関数に渡すプロンプトへ業務データを動的に埋め込むケースがよくあります。AI_PROMPT は、そのための補助関数です。プレースホルダーを使って、プロンプトを整った形で組み立てられます。
-- プレースホルダー {0} にレビュー本文を動的に挿入する
SELECT AI_PROMPT('感情を判定してください:{0}', content) FROM reviews;
戻り値はJSON形式で、そのまま AI_COMPLETE の入力に使えます。プロンプトをアプリケーションコードのあちこちに散らさずに済むので、管理しやすくなります。
AI_SPLIT_DOCUMENT:テキストをチャンクに分けるRAG用のナレッジベースを作るときは、長い文書をまず小さなチャンクに分けてからEmbeddingや検索に回すのが一般的です。AI_SPLIT_DOCUMENT は、その分割処理をデータベース内で行うための関数です。モデルやエンドポイントの登録は不要で、AIモデル権限も必要ありません。
SELECT CHUNK_ID, CHUNK_OFFSET, CHUNK_LENGTH, CHUNK_TEXT
FROM AI_SPLIT_DOCUMENT(
'これは長い Markdown 文書です…',
'{"type": "markdown", "by": "word", "max": 256, "overlap": 32}'
);
単語数または文数ベースで分割でき、隣り合うチャンクに重なりを持たせることもできます。これによって、チャンク分割時に重要なコンテキストが途切れてしまうのを防ぎやすくなります。入力形式はMarkdownとプレーンテキストに対応しています。分割後の CHUNK_TEXT は、そのまま AI_EMBED に渡してベクトル化できます。
外部ファイルから取り込む場合:
企業内の文書は、オンラインストレージ、HDFS、ローカルパスなどに置かれていることがあります。この場合は、まず CREATE LOCATION で外部ストレージを定義し、LOAD_FILE(location, file_name) でファイルをデータベースに読み込みます。戻り値は BLOB です。その後、チャンキングとベクトル化のパイプラインにつなげられます。LOAD_FILE もAIモデルの登録は不要です。
特徴 | AI_COMPLETE | AI_EMBED | AI_RERANK | AI_PROMPT | AI_SPLIT_DOCUMENT |
|---|---|---|---|---|---|
| バッチ処理 | ✅ 行単位 | ✅ バッチ | ✅ バッチ | — | ✅ テーブル関数 |
| 複数ベンダーのモデルに対応 | ✅ | ✅ | ✅ | — | — |
| 次元数の指定 | — | ✅ | — | — | — |
| モデル登録不要 | — | — | — | — | ✅ |
| ハイブリッド検索との連携 | — | ✅ | ✅ | — | ✅ |
| OceanBase Cloudの無料組み込みモデル | ✅ | ✅ | ✅ | — | — |
RAGの構成は、SQLレベルで見ると次の流れに整理できます。
テキストチャンキング → ベクトル埋め込み → ハイブリッド検索で候補取得 → (必要に応じて)再ランキング → 回答生成
データ登録処理と質問応答の処理を分けて書くと、全体像は次のようになります。
-- フェーズ 1:登録(分割 + ベクトル化を同一トランザクション内で実行)
INSERT INTO kb_chunks (doc_id, chunk_text, embedding)
SELECT 1 AS doc_id, s.CHUNK_TEXT,
AI_EMBED('my_embed', s.CHUNK_TEXT) AS embedding
FROM AI_SPLIT_DOCUMENT(
'……長い文書本文……',
'{"type": "markdown", "by": "word", "max": 256, "overlap": 32}'
) s;
-- フェーズ 2:ユーザーの質問に対し、ハイブリッド検索で Top-K を取得する
SELECT id, chunk_text, __score
FROM HYBRID_SEARCH(
TABLE kb_chunks,
'{
"knn": {"field": "embedding", "query_vector": "[...]", "k": 10},
"query": {"match": {"chunk_text": "ユーザー質問のキーワード"}},
"rank": {"rrf": {"rank_constant": 60}},
"size": 5
}'
);
-- フェーズ 3(任意):候補チャンクを再ランキングし、LLMで回答を生成する
SELECT AI_COMPLETE('my_llm',
AI_PROMPT('次の資料をもとに質問に回答してください:{0}', chunk_text)
) AS answer
FROM kb_chunks WHERE id IN (...);
ハイブリッド検索は、まず候補を広めに拾う役割を担います。AI_RERANK は、その候補をさらに並べ替えて精度を上げたいときに使います。AI_COMPLETE は、最終的に選んだコンテキストをもとに自然言語の回答を生成します。ベクトル埋め込みの処理は、OceanBase 独自の VSAG ベクトルライブラリで高速化されています。ハイブリッド検索や通常の列データによるフィルタリングと組み合わせることで、数千万件から億件規模のデータを対象にしたセマンティック検索にも対応できます。
従来構成 | OceanBase AI Function | |
|---|---|---|
| アーキテクチャ | SQL DB + ベクトルDB + 検索エンジン | 1つのデータベース |
| Embedding | Pythonスクリプト + API | SELECT AI_EMBED(...) |
| Rerank | モデルサービスを別途デプロイ | SELECT AI_RERANK(...) |
| 文書分割 | 外部スクリプト | AI_SPLIT_DOCUMENT(...) |
| データ整合性 | アプリケーション側で担保 | トランザクション内で原子的に書き込み |
| 運用の複雑さ | 3つのシステム | 1つのシステム |
従来の構成では、リレーショナルデータベース、ベクトルデータベース、全文検索エンジンを別々に運用することが少なくありません。そうなると、データを複数システム間で同期する必要があり、整合性の管理や運用コストも増えていきます。OceanBaseでは、ベクトル検索、全文検索、AI Functionを1つのシステムで扱えます。ベクトルデータとスカラーデータを同じテーブルに保存でき、整合性も同じトランザクションエンジンで管理できます。
OceanBaseのAI Functionは、Embeddingだけでなく、回答生成、再ランキング、チャンキングまでをSQLから扱えます。検索して終わりではなく、その後の並べ替えや回答生成まで同じ流れでつなげやすいのがポイントです。RAGのような構成でも、処理ごとに周辺サービスを増やしすぎずに組みやすくなります。
これらの関数は、OceanBaseのベクトルエンジン(VSAG)、ハイブリッド検索、全文検索とも連携します。ベクトル検索とキーワード検索を組み合わせた候補取得や、その後の再ランキングまでをデータベース内でつなげられるため、検索パイプライン全体をSQLベースで組み立てやすくなります。多言語対応のEmbedモデルを使えば、日本語で質問して英語の文書をヒットさせる、といった言語横断の検索にも対応できます。
工程 | 使用する関数 | できること |
|---|---|---|
| チャンキング | AI_SPLIT_DOCUMENT | データベース内で処理でき、外部スクリプトが不要 |
| ベクトル埋め込み | AI_EMBED | データ登録時にベクトル化でき、ETLを減らせる |
| セマンティックマッチング | ハイブリッド検索 + AI_EMBED | セマンティック検索とキーワード検索を組み合わせられる |
| 結果の再ランキング | AI_RERANK | 関連度の高い内容を上位に並べられる |
| 回答生成 | AI_COMPLETE | 取得したコンテキストをもとに回答を生成できる |
事例:
※製品として提供したい場合や、ローコードで素早く立ち上げたい場合は、OceanBaseが開発したPowerRAGプラットフォームを使ってRAG/Agentアプリケーションを構築できます。基盤には、同じくベクトル検索とAI機能が使われています。一方、この記事で紹介しているSQLベースの方法は、パイプラインを柔軟に設計したいチームや、処理を細かくカスタマイズしたいチームに向いています。
工程 | 使用する関数 | できること |
|---|---|---|
| ユーザー意図の理解 | AI_COMPLETE | キーワード一致だけでなく、意味を踏まえた判定ができる |
| FAQ検索 | AI_EMBED + ハイブリッド検索 | 「返金したい」と「返品申請の方法」を同じ回答に結び付けられる |
| 回答の並べ替え | AI_RERANK | 最も適切な回答を上位に表示できる |
工程 | 使用する関数 | できること |
|---|---|---|
| セマンティック検索 | AI_EMBED | 「軽量ノート」で、同じ語を含まなくても条件に合う商品を見つけられる |
| 結果の最適化 | AI_RERANK | クリック率やコンバージョン率の改善につなげられる |
事例:
ある小売・EC系の企業では、商品のセマンティックマッチングとカスタマーサポート向けナレッジベースRAGをOceanBase上に構築しています。店頭商品の画像検索による購買支援、DBテナントをまたいだSKUのセマンティックな対応付け、コールセンターFAQの高速検索などに活用しており、従来利用していたMilvusなどの独立したベクトル検索基盤を置き換えています。
工程 | 使用する関数 | できること |
|---|---|---|
| レビューの感情分析 | AI_COMPLETE | 手作業のラベル付けを減らし、まとめて自動化できる |
| コンテンツの自動分類 | AI_COMPLETE | 新しいデータを登録するタイミングで分類できる |
| センシティブ情報の識別 | AI_COMPLETE | コンプライアンス確認の自動化に利用できる |
本番環境で利用する前に、次の制約を確認しておくことをおすすめします。
ENDPOINT は同期されません。スタンバイテナント側では、モデルエンドポイントを別途設定する必要があります。AI_SPLIT_DOCUMENT と LOAD_FILE を除き、Complete/Embed/Rerank を呼び出すには、AIモデル関連の権限とモデル登録が必要です。OceanBaseのAI Functionを使えば、チャンキングから埋め込み、検索、回答生成までの流れをSQLの中で一貫して扱えます。RAGを柔軟に組みたい場合はAI Function、素早くAgentアプリを立ち上げたい場合はPowerRAGと、用途に応じて選べるのも特徴です。既存の検索基盤から段階的に移行しやすい点も含め、OceanBaseは生成AI時代のデータ基盤として有力な選択肢といえるでしょう。

AIアプリ開発でデータ層が分散しやすくなる理由 RAGやAIエージェントを組み込んだアプリケーションを作ると、使うツールは自然と増えていきます。LangChainやLlamaIndexで処理フローを組み立て、OpenAIやローカルモデルで推論を行い、Difyのようなワークフロープラットフォームで業務ロジックをつなぎ、Cursor、Cline、Claude CodeなどのIDEで実装を進める。最近のAI開発では、こうした構成は珍しくありません。 一方で、ツールが増えるほどデータ層は複雑になりがちです。業務データはRDB、ベクトル検索は専用Vector DB、キーワード検索は検索エンジン、エージェ...


前回の記事「AI時代のデータベースはどう進化するのか。ベクトル検索だけでは足りない」では、アーキテクチャと価値の観点から、OceanBase AI がマルチモデル統合アプローチを採用する理由を解説しました。1 つのデータベースで業務データ、ベクトル、全文検索、AI 呼び出しを扱い、SQL によってデータからインテリジェンスまでの流れをつなぐ、という考え方です。 本記事では、このコンセプトを実際の技術フローとして実現する方法を掘り下げます。RAG(Retrieval-Augmented Generation)やハイブリッド検索の導入を検討している開発チームが直面する具体的な課題は、以下のような点...


OceanBaseは、分散データベースから出発し、いまではAI時代に対応する新たな製品群へと進化しつつあります。本記事では、その技術的な歩みをたどります。 OceanBaseの製品進化 OceanBaseは2010年に分散データベースの開発を開始しました。当初はNoSQLデータベースとして位置付けられていましたが、その後は本格的なリレーショナルデータベースへと進化し、MySQLおよびOracleとの互換性も継続的に強化してきました。3.x以降は、トランザクション処理(TP)と分析処理(AP)が混在するワークロードへの対応も強化してきました。実際の基幹業務システムでは、TPとAPを厳密に切り分け...
