AIアプリ開発でデータ層が分散しやすくなる理由
RAGやAIエージェントを組み込んだアプリケーションを作ると、使うツールは自然と増えていきます。LangChainやLlamaIndexで処理フローを組み立て、OpenAIやローカルモデルで推論を行い、Difyのようなワークフロープラットフォームで業務ロジックをつなぎ、Cursor、Cline、Claude CodeなどのIDEで実装を進める。最近のAI開発では、こうした構成は珍しくありません。
一方で、ツールが増えるほどデータ層は複雑になりがちです。業務データはRDB、ベクトル検索は専用Vector DB、キーワード検索は検索エンジン、エージェントの状態は別のストレージ、というように役割ごとに分かれていくと、接続先や同期処理、運用対象が増えていきます。
OceanBaseは、このデータ層をできるだけ1つに寄せるための選択肢です。通常の業務データに加えて、ベクトル検索、全文検索、トランザクション処理を同じデータベースで扱えます。ベクトル検索と全文検索を組み合わせたハイブリッド検索や、スカラーデータとベクトルデータをまたいだ検索にも対応しています。
すでに60を超えるAIエコシステムのツールと連携しており、そのうち18件以上については、実運用を見据えた検証が完了しています。さらに、OceanBaseが提供するPowerRAGを使うと、RAG、検索、レコメンド、AIエージェントといった用途の開発にもつなげられます。
つまり、LangChainのVectorStoreやDifyのRAGバックエンド、CursorからのMCPアクセスを、別々のデータ基盤に向ける必要はありません。これらを同じOceanBaseインスタンスに集約できます。本記事では、OceanBaseがAI開発ツールチェーンの中でどのように使えるのかを、レイヤーごとに整理します。
OceanBaseがつながるAI開発ツール
まず全体像を見ておきます。OceanBaseはAIアプリケーションのデータ基盤として、フレームワーク、モデル、開発環境、MCP、ローコード基盤など複数のレイヤーと連携します。
| エコシステム層 | 代表ツール |
|---|---|
| Agentフレームワーク | LangChain、LlamaIndex、Dify、DB-GPT、FastGPT、CrewAI、Camel-AI、LangGraph、RAGFlow、AutoGen |
| コードアシスタント | Cursor、Continue、Cline、Trae、Windsurf、Cody |
| 推論エンジン | Ollama、vLLM、Transformers、OpenVINO、LLAMA.cpp |
| モデルサービス | OpenAI、DeepSeek、通義千問、智譜、Anthropic、Google、HuggingFace |
| プロトコル層 | MCP、A2A |
| メモリ層 | mem0、Letta |
| 可観測性 | LangSmith、Arize |
| ツール/プラットフォーム | Open WebUI、Chatbox、Supabase、Vercel |
ここで重要なのは、対応ツールの数そのものよりも、AI開発でよく使う入口から同じデータ基盤にアクセスできることです。アプリケーション側のフレームワーク、モデル側のEmbedding生成、開発環境からのMCPアクセスを、それぞれOceanBaseに向けられます。
フレームワークからは既存のインターフェースで使う
LangChainやLlamaIndexを使っている場合でも、開発者はOceanBase独自の使い方を一から覚える必要はありません。各フレームワークが持つVectorStoreやRetrieverなどの抽象化を通じて、OceanBaseを検索・保存先として利用できます。
| フレームワーク | 接続方法 | 主な用途 |
|---|---|---|
| LangChain | 公式の langchain-oceanbase パッケージにより、VectorStoreとして利用可能 |
RAGベースのQA、ドキュメント検索 |
| LlamaIndex | VectorStore統合に対応 | コンテキストを踏まえた生成、埋め込み検索 |
| LangGraph | OceanBaseのMySQLモードを状態永続化のバックエンドとして利用可能 | ステートフルなAIエージェントワークフロー |
| CrewAI | マルチエージェント協調フレームワークとの連携に対応 | 役割分担型AIエージェントワークフロー |
| CamelAI | マルチエージェント協調フレームワークとの連携に対応 | マルチエージェント型AIワークフロー |
| Spring AI Alibaba | Java向けAIフレームワークから利用可能 | エンタープライズ向けSpringアプリケーションのAI拡張 |
| RAGFlow | OSSのRAGエンジンとの連携に対応 | ドキュメント解析とベクトル検索のパイプライン |
LangChain、LlamaIndex、Spring AI Alibaba、CamelAI、LangGraphの5つについては、本番利用を見据えた検証が完了しています。CrewAIやRAGFlowなども公式のエコシステムに含まれており、すでに連携対象となっています。
たとえばLangChainでは、VectorStore、Retriever、Chainなどのインターフェースをそのまま使いながらRAGアプリケーションを構成できます。ベクトルの保存や検索に関する接続処理はOceanBase側で扱うため、通常は専用のコネクタを個別に実装する必要はありません。
Embedding生成と保存先を分けて考える
OceanBaseはEmbeddingを生成するモデルそのものではなく、生成されたベクトルを保存し、検索するデータ基盤です。そのため、Embedding生成に使うモデルや推論基盤は用途に応じて選べます。
| モデル/推論基盤 | OceanBaseとの組み合わせ方 |
|---|---|
| OpenAI | ベクトルデータをOceanBaseに保存し、類似度検索に利用 |
| Google Gemini | マルチモーダルAIとOceanBaseを組み合わせたデータ基盤構成 |
| Hugging Face | オープンモデルのエコシステムとTransformersベースの推論パイプラインに対応 |
| DeepSeek | オープンモデルによる推論とOceanBaseのベクトルストレージを組み合わせた構成。PowerRAGでもネイティブにサポート |
| Ollama | ローカルのオープンモデルとローカルOceanBaseを組み合わせたベクトル検索構成 |
| vLLM | 高性能な推論基盤とOceanBaseのベクトル検索を組み合わせた構成 |
| Qwen（Tongyi Qianwen） | Alibaba CloudのLLMと組み合わせたエンドツーエンドのRAG構成 |
| GLM（Zhipu AI） | 中国系LLMとOceanBaseを組み合わせたデータ基盤構成 |
| Jina AI | マルチモーダル検索やエンタープライズ向けRAGコンポーネントとの連携 |
OpenAI、Qwen、Jina AIの3つについては、実運用を見据えた検証が完了しています。DeepSeek、GLM、Gemini、Hugging Face、Ollama、vLLMなどについても、すでに接続済みです。
プロトタイプではOpenAIを使い、運用段階でDeepSeekやOllamaに切り替えることもできます。Jina AIを組み合わせて、マルチモーダル検索へ広げることも可能です。その場合でもOceanBase側のベクトルインターフェースは変わらないため、データ層の変更は最小限に抑えられます。
ローコード/ノーコード基盤からも使える
AIアプリケーションが常にPython中心で構築されるとは限りません。業務部門がDifyやFastGPTのようなローコード基盤でQAボットを作るケースも増えています。OceanBaseは、こうしたプラットフォームからもRAG向けのバックエンドとして利用できます。
| プラットフォーム | 利用イメージ |
|---|---|
| DB-GPT | オープンソースのAIデータベースアシスタント。OceanBaseをナレッジベース向けのベクトルバックエンドとして利用可能 |
| FastGPT | オープンソースのナレッジベースQAプラットフォーム。OceanBaseをベクトルバックエンドとして利用可能 |
| Coze Studio | ByteDance系のAIアプリ構築基盤。OceanBaseをベクトルバックエンドおよび構造化データソースとして利用可能 |
| AnythingLLM | オープンソースのLLMデスクトップアプリケーション。OceanBaseのベクトル検索と連携可能 |
| Dify | ローコード型のAIアプリ開発基盤。OceanBaseをRAG向けのベクトルバックエンドとして利用可能 |
| RAGFlow | エンタープライズ向けRAGエンジン。OceanBaseをベクトルバックエンドとして利用可能 |
| MaxKB | ナレッジベースQAプラットフォーム。OceanBaseをベクトルバックエンドとして利用可能 |
| PowerRAG | Agentの開発からデプロイまでを扱うOceanBase提供の基盤 |
DB-GPT、FastGPT、Coze Studio、AnythingLLM、Dify、PowerRAGの6つについては、検証が完了しています。RAGFlowやMaxKBなども、公式のエコシステム全体図に含まれています。
業務部門では、DB-GPTを自然言語によるデータ問い合わせに使ったり、FastGPTやDifyでQAボットを構築したりできます。そのバックエンドにOceanBaseを接続すれば、RAG検索に使うデータも同じ基盤で管理できます。物流、通信、越境ECなどの分野では、OceanBaseとDify、MCPなどの周辺ツールを組み合わせた活用が進んでいます。
MCPで開発環境からデータベースにアクセスする
AI開発では、IDEからデータベースを直接扱いたい場面もあります。MCP（Model Context Protocol）を使うと、CursorやClineなどの開発環境からOceanBaseへアクセスし、自然言語の指示をSQL実行やスキーマ探索につなげられます。
| IDE/ツール | 利用イメージ |
|---|---|
| Cline | オープンソースのMCPネイティブなコーディングアシスタント。対話ベースでバックエンドを構築可能 |
| Continue | VS Code/IntelliJ向けプラグイン。AI支援コーディングとデータベース連携を組み合わせて利用可能 |
| Trae | MCP対応IDE。バックエンドのプロトタイプをすばやく作成可能 |
| Windsurf | AIネイティブIDE。MCP経由でOceanBaseへ直接接続可能 |
| Google GenAI Toolbox | ノーコードでMCP Serverを構成でき、コードを書かずにOceanBaseへのアクセスを設定可能 |
Cursor、Cline、Continue、Trae、Google GenAI Toolboxの5つについては検証が完了しており、Windsurfについても接続はすでに完了しています。
IDE以外でも、OceanBaseのMCP機能はAlibaba CloudのModelScopeコミュニティやanserPACKなどのプラットフォームに取り込まれています。開発者はModelScopeの創空間やClaude DesktopなどのMCPクライアントから、自然言語でデータベースクエリ、クラスタ運用診断、データ分析を行えます。
MCP Serverが共通の入口になる
MCPは、AIツールとデータベースの間に共通の接続ルールを用意する仕組みです。MCP Serverを一度設定しておけば、Cursor、Cline、Continueなどの対応ツールから同じデータアクセス機能を使えます。IDEごとに別々のコネクタを作る必要もありません。
同じOceanBaseインスタンスを、役割の異なる開発者が同時に使うことも可能です。たとえば、データサイエンティストはCursorでデータを探索し、バックエンドエンジニアはClaude Codeでサービスを書き、QAはClineでAPIを検証する、といった使い方です。全員が同じMCP設定を共有しながら、自然言語からSQLへつなぐ一貫した操作感を得られます。
OceanBase MCP Serverで扱えること
awesome-oceanbase-mcp リポジトリでは、OceanBaseエコシステム向けのMCP Server群が提供されています。SQL操作、クラスタ運用、診断、ベクトル検索まで、用途に応じたServerを選べます。
| MCP Server | 主な機能 |
|---|---|
| OceanBase MCP Server | 構造化クエリ実行、スキーマ探索、データCRUD |
| OceanBaseDIAG MCP Server | 自動診断、スロークエリ分析、性能調査 |
| OceanBaseshell MCP Server | クラスタ作成、デプロイ、運用管理 |
| OCP/OceanBaseCloud MCP Server | クラウドおよびプラットフォーム側のクラスタ管理、監視 |
| OKCTL MCP Server | Kubernetes環境のリソース管理とデプロイ |
| seekdb MCP Server | ベクトル操作、コレクション管理、AI関数 |
中核となるMCP Serverは、主に次の操作を扱います。
- 構造化クエリ実行： 自然言語の指示をパラメータ化SQLに変換し、OceanBaseインスタンス上で実行します。結果はAIツールが扱いやすい形で返されます。CRUDに加えて、スキーマ探索やデータ確認にも使えます。
- リアルタイム監視： AIツール側からデータベースの状態、性能指標、ヘルス状況を参照できます。アラートや自動診断の土台として使える機能です。
- インテリジェント診断： OceanBaseの診断ツールチェーンと組み合わせることで、MCP Serverはデータベース障害の切り分け、スロークエリ分析、最適化案の提示まで、自然言語ベースで支援します。
Cursorから5分でAPIを作る流れ
ここでは、検証済みのCursor+OceanBase MCP統合を前提に、実際の開発作業に近い流れを見てみます。
1. MCP Serverを設定する（30秒）
{
"mcpServers": {
"oceanbase": {
"command": "uv",
"args": ["--directory", "/path/to/awesome-oceanbase-mcp", "run", "oceanbase_mcp_server"],
"env": {
"OceanBase_HOST": "ホスト名",
"OceanBase_PORT": "2881",
"OceanBase_USER": "ユーザー名",
"OceanBase_PASSWORD": "パスワード",
"OceanBase_DATABASE": "test"
}
}
}
}
2. 自然言語でテーブルを作る
「主キーをIDにしたcustomerテーブルを作ってください。カラムはname、age、telephone、locationを含めます。」
CursorはMCPツール execute_sql を呼び出してDDLを実行し、「クエリの実行に成功しました。customerテーブルを作成しました」と返します。
3. テストデータを投入する
「顧客のテストデータを10件入れてください。」
AIが10件分のINSERT文を自動生成して実行します。
4. RESTful APIを生成する
「FastAPIプロジェクトを作成し、customerテーブルをもとにRESTful CRUD APIを生成してください。」
Cursorは main.py を自動生成し、FastAPIのコード一式を含めます。SQLAlchemyモデル、CRUD APIエンドポイント、依存関係の設定までそろっており、すべて手元のOceanBaseインスタンスにつながっています。uvicorn main:app --reload を実行すれば、その場で動くAPIが立ち上がります。
この一連の流れは、すべてエディタの中で完結します。途中で別のツールに切り替える必要はありません。
MCP統合によって、データベースを開発環境から直接扱えるようになります。AIツールに自然言語で指示すれば、クエリ実行やテーブル作成、ベクトル書き込みといった操作をそのまま進められます。裏側ではOceanBaseが標準SQLを処理します。
既存のベクトルDBから段階的に移行する
すでにMilvus、Qdrant、PgVector、ElasticSearchを使っている場合でも、ゼロから作り直す必要はありません。OceanBaseはベクトルデータの移行手段を一通り用意しています。ベクトルコレクション、メタデータ、インデックス設定をOceanBaseに移したうえで、RAG、検索、レコメンドのアプリケーションを継続できます。
Huolalaなどでは、既存のMilvusなどのベクトルDBを段階的にOceanBaseへ移行する計画も進んでいます。既存アプリケーションのロジックを保ちながら、検索データと業務データを同じ基盤に寄せていく進め方です。
OceanBaseをAI基盤として使うときのポイント
ここまで見てきた内容を、AI向けデータ基盤という観点で整理すると、ポイントは大きく4つあります。
- 検索機能をデータベース内で扱える： HNSW/IVFベクトルインデックス、ハイブリッド検索、VSAGベクトル計算ライブラリにより、セマンティック検索、キーワード検索、スカラー条件での絞り込みを1つのデータベース内で完結します。RAGやレコメンドアプリケーションを組む際にも、専用のベクトルDBや検索エンジンを別途つなぎ合わせる必要がありません。
- 対応ツールが多く、始め方を追いやすい： 60以上のツールと接続されています。LangChain/LlamaIndexのようなフレームワークから、OpenAI/Ollamaのようなモデル、Dify/FastGPTのようなローコード基盤、Cursor/ClineのようなMCP開発環境まで、各レイヤーにドキュメントと検証事例があります。
- モデルやツールを切り替えやすい： ベクトル保存とEmbedding生成を切り分け、MCP Serverで統一的なデータアクセス手段を提供しているため、フレームワーク、モデル、IDEを入れ替えてもOceanBase側のインターフェースは安定しています。
- 既存構成から移行しやすい： Milvus、Qdrant、PgVector、ElasticSearchなどの専用ベクトルDBから移行でき、統一基盤の上でRAGや検索アプリケーションを継続できます。詳細は前述の「既存のベクトルDBから段階的に移行する」を参照してください。
まとめ
AIアプリケーションの開発では、フレームワーク、モデル、IDE、ワークフロープラットフォームが増えるほど、データ層の設計が複雑になります。OceanBaseは、ベクトル検索、全文検索、トランザクション処理を同じデータベースで扱うことで、この分散を抑えるための選択肢になります。
LangChainやLlamaIndexからRAGアプリケーションを組む場合も、DifyやFastGPTのようなローコード基盤を使う場合も、CursorやClineからMCP経由でデータベースを扱う場合も、同じOceanBaseインスタンスをデータ基盤として使えます。
すでにMilvusやElasticSearchなどを使っているチームでも、段階的に移行しながら、既存アプリケーションのロジックを保ちつつ基盤を一本化していけます。AI向けのデータアーキテクチャを見直すうえで、OceanBaseはストレージ、検索、ツールチェーン連携をまとめて考えられる候補の1つです。