LangChainからCursorまで、AI開発のデータ基盤をOceanBaseに集約する

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、ローコード基盤など複数のレイヤーと連携します。

ここで重要なのは、対応ツールの数そのものよりも、AI開発でよく使う入口から同じデータ基盤にアクセスできることです。アプリケーション側のフレームワーク、モデル側のEmbedding生成、開発環境からのMCPアクセスを、それぞれOceanBaseに向けられます。

フレームワークからは既存のインターフェースで使う

LangChainやLlamaIndexを使っている場合でも、開発者はOceanBase独自の使い方を一から覚える必要はありません。各フレームワークが持つVectorStoreやRetrieverなどの抽象化を通じて、OceanBaseを検索・保存先として利用できます。

LangChain、LlamaIndex、Spring AI Alibaba、CamelAI、LangGraphの5つについては、本番利用を見据えた検証が完了しています。CrewAIやRAGFlowなども公式のエコシステムに含まれており、すでに連携対象となっています。

たとえばLangChainでは、VectorStore、Retriever、Chainなどのインターフェースをそのまま使いながらRAGアプリケーションを構成できます。ベクトルの保存や検索に関する接続処理はOceanBase側で扱うため、通常は専用のコネクタを個別に実装する必要はありません。

Embedding生成と保存先を分けて考える

OceanBaseはEmbeddingを生成するモデルそのものではなく、生成されたベクトルを保存し、検索するデータ基盤です。そのため、Embedding生成に使うモデルや推論基盤は用途に応じて選べます。

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、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実行やスキーマ探索につなげられます。

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は、主に次の操作を扱います。

• 構造化クエリ実行： 自然言語の指示をパラメータ化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つです。