OceanBaseには、AI_COMPLETE、AI_EMBED、AI_RERANK、AI_PROMPT、AI_SPLIT_DOCUMENT という5つのSQL組み込み関数があります。これらを使うと、テキストのチャンキング、ベクトル化、検索結果の再ランキング、テキスト生成といった処理をデータベースの中で扱えます。ベクトル検索やハイブリッド検索と同じエンジン上で動くので、RAGの一連の流れをSQLでそのままつなげて書けます。
OceanBaseでは、LLMの機能をデータベース関数として利用できます。使い方はUPPER()やSUM()に近く、モデルのエンドポイントを登録しておけば、あとはSQLから直接呼び出すだけです。この記事では、各関数でできること、接続方法、エンドツーエンドのパイプライン、それからよくあるユースケースを順に見ていきます。
AI Functionとは
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から利用できます。
5つのAI関数をざっと見る
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から呼び出す
- できること：LLMを呼び出して、対話、要約、分類、情報抽出、翻訳などを行えます。いわばChatGPTのような処理を、データベースから直接使えるようにする関数です。
- 特長：
- 6社以上のモデルに対応しており、SQLの呼び出し方を共通化できます。モデルを切り替えても、SQL側の変更は最小限で済みます。
- 補助関数
AI_PROMPT()と組み合わせることで、プロンプトテンプレートを動的に組み立てられます。 - 複数行に対する一括処理にも向いています。SQLを使ってテーブル内の複数レコードに一気に適用し、その結果をそのままテーブルへ書き戻せます。
例：レビューの感情分析をまとめて実行する
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：テキストをベクトル化する
- できること：テキストを高次元ベクトルに変換します。たとえば1024次元や1536次元の浮動小数点配列に変換し、セマンティック検索に使える形にします。これによって、2つのテキストが意味的に近いかどうかをデータベース上で扱えるようになります。
- 特長：
-
dimパラメータで出力ベクトルの次元数を指定でき、利用するモデルに合わせて調整できます。 - バッチ入力に対応しているため、1回のHTTPリクエストで複数のテキストを処理できます。大量データを扱うときにも使いやすい構成です。
- 戻り値は
FLOAT配列です。ベクトル列にそのまま保存でき、ハイブリッド検索インデックスと組み合わせれば、登録後すぐに検索対象にできます。
例：ドキュメントをDBに登録する際に自動でベクトル化する
INSERT INTO knowledge_base (title, content, embedding)
VALUES (
'OceanBase 概要',
'OceanBase はネイティブ分散データベースです…',
AI_EMBED('my_embed', 'OceanBase はネイティブ分散データベースです…')
);
従来は、Embedding（ベクトル化）処理をアプリケーション側のスクリプトからAPI経由で呼び出し、その結果をデータベースに書き戻す構成になりがちでした。AI_EMBED を使えば、その処理を INSERT 文の中にまとめられます。同じトランザクションの中で元テキストとベクトルを一緒に保存できるので、データの整合性も保ちやすくなります。
AI_RERANK：検索結果を並べ替える
- できること：一次検索で得た候補を、クエリとの関連度に基づいて再スコアリングし、並べ替えます。検索品質を上げるうえで重要な処理です。ベクトル検索は意味的に近い候補を広めに拾うのが得意ですが、最終的にどれを上位に出すかは、より細かな判断が必要になることがあります。
- 特長：
- SQLからそのまま利用できるため、Rerank用のサービスを別に立てる必要がありません。
- OceanBaseのハイブリッド検索と組み合わせて使えます。まずハイブリッド検索で候補を取り、その後に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の無料組み込みモデル | ✅ | ✅ | ✅ | — | — |
SQLで組むRAGの流れ
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に寄せると何が楽になるか
構成をシンプルにしやすい
| 従来構成 | 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つのシステムで扱えます。ベクトルデータとスカラーデータを同じテーブルに保存でき、整合性も同じトランザクションエンジンで管理できます。
AI関数をまとめて使える
OceanBaseのAI Functionは、Embeddingだけでなく、回答生成、再ランキング、チャンキングまでをSQLから扱えます。検索して終わりではなく、その後の並べ替えや回答生成まで同じ流れでつなげやすいのがポイントです。RAGのような構成でも、処理ごとに周辺サービスを増やしすぎずに組みやすくなります。
これらの関数は、OceanBaseのベクトルエンジン（VSAG）、ハイブリッド検索、全文検索とも連携します。ベクトル検索とキーワード検索を組み合わせた候補取得や、その後の再ランキングまでをデータベース内でつなげられるため、検索パイプライン全体をSQLベースで組み立てやすくなります。多言語対応のEmbedモデルを使えば、日本語で質問して英語の文書をヒットさせる、といった言語横断の検索にも対応できます。
どんな場面で使いやすいか
RAGのナレッジベース
| 工程 | 使用する関数 | できること |
|---|---|---|
| チャンキング | AI_SPLIT_DOCUMENT |
データベース内で処理でき、外部スクリプトが不要 |
| ベクトル埋め込み | AI_EMBED |
データ登録時にベクトル化でき、ETLを減らせる |
| セマンティックマッチング | ハイブリッド検索 + AI_EMBED
|
セマンティック検索とキーワード検索を組み合わせられる |
| 結果の再ランキング | AI_RERANK |
関連度の高い内容を上位に並べられる |
| 回答生成 | AI_COMPLETE |
取得したコンテキストをもとに回答を生成できる |
事例：
- 通信業界における運用支援：MySQLとElasticsearchの2システム構成から、OceanBaseの統合アーキテクチャへ移行。ベクトル検索とハイブリッドフィルタリングを活用して運用向けRAGを構築し、データベースの一般知識や機能ドキュメントに関する自然言語Q&Aを支えています。
- 物流・データ分析領域での活用：ベクトル検索を、業務上の損失原因の分類やデータウェアハウス向けAI Q&Aに活用。大規模言語モデルと組み合わせることで、リスク分析やデータ問い合わせ支援に利用しています。
- 教育・学習端末での活用：絵本の問題データをベクトルデータベースに保存し、類似問題の検索や絵本 Q&A などに活用しています。
※製品として提供したい場合や、ローコードで素早く立ち上げたい場合は、OceanBaseが開発したPowerRAGプラットフォームを使ってRAG/Agentアプリケーションを構築できます。基盤には、同じくベクトル検索とAI機能が使われています。一方、この記事で紹介しているSQLベースの方法は、パイプラインを柔軟に設計したいチームや、処理を細かくカスタマイズしたいチームに向いています。
カスタマーサポート
| 工程 | 使用する関数 | できること |
|---|---|---|
| ユーザー意図の理解 | AI_COMPLETE |
キーワード一致だけでなく、意味を踏まえた判定ができる |
| FAQ検索 |
AI_EMBED + ハイブリッド検索 |
「返金したい」と「返品申請の方法」を同じ回答に結び付けられる |
| 回答の並べ替え | AI_RERANK |
最も適切な回答を上位に表示できる |
EC検索
| 工程 | 使用する関数 | できること |
|---|---|---|
| セマンティック検索 | AI_EMBED |
「軽量ノート」で、同じ語を含まなくても条件に合う商品を見つけられる |
| 結果の最適化 | AI_RERANK |
クリック率やコンバージョン率の改善につなげられる |
事例：
ある小売・EC系の企業では、商品のセマンティックマッチングとカスタマーサポート向けナレッジベースRAGをOceanBase上に構築しています。店頭商品の画像検索による購買支援、DBテナントをまたいだSKUのセマンティックな対応付け、コールセンターFAQの高速検索などに活用しており、従来利用していたMilvusなどの独立したベクトル検索基盤を置き換えています。
データ処理への応用
| 工程 | 使用する関数 | できること |
|---|---|---|
| レビューの感情分析 | AI_COMPLETE |
手作業のラベル付けを減らし、まとめて自動化できる |
| コンテンツの自動分類 | AI_COMPLETE |
新しいデータを登録するタイミングで分類できる |
| センシティブ情報の識別 | AI_COMPLETE |
コンプライアンス確認の自動化に利用できる |
使う前に見ておきたいポイント
本番環境で利用する前に、次の制約を確認しておくことをおすすめします。
-
スタンバイテナントのエンドポイント：モデルの登録はプライマリテナントとスタンバイテナント間で同期されますが、
ENDPOINTは同期されません。スタンバイテナント側では、モデルエンドポイントを別途設定する必要があります。 - モデルの削除：ハイブリッド検索はAI関数の埋め込み機能に依存します。AIモデルを削除する前に、ハイブリッド検索から参照されていないことを確認してください。
- 呼び出しの監視：システムビューを使って、AIモデルの設定や呼び出し状況を確認できます。運用監査にも使えます。
-
権限：
AI_SPLIT_DOCUMENTとLOAD_FILEを除き、Complete/Embed/Rerankを呼び出すには、AIモデル関連の権限とモデル登録が必要です。
おわりに
OceanBaseのAI Functionを使えば、チャンキングから埋め込み、検索、回答生成までの流れをSQLの中で一貫して扱えます。RAGを柔軟に組みたい場合はAI Function、素早くAgentアプリを立ち上げたい場合はPowerRAGと、用途に応じて選べるのも特徴です。既存の検索基盤から段階的に移行しやすい点も含め、OceanBaseは生成AI時代のデータ基盤として有力な選択肢といえるでしょう。