SeekDBとは？AIネイティブ検索データベースの使い方をDockerで実機検証【LEANNとの違いも】

SeekDBは、エージェントの「記憶・検索・状態」を丸ごと引き受けるために設計された、AIネイティブな検索データベースです。AIエージェントを作ると、必ず突き当たる地味な問題があります。エージェントが「さっき観測したこと」を書き込んで、その直後に「関連する記憶」を引き出す——この“書いては読む”を高頻度で繰り返す用途に、既存のデータベースは意外と向いていません。ベクトルDBは検索は得意でも継続書き込みで詰まり、全文検索エンジンは意味検索が弱く、RDBはそもそもベクトルを扱えない。結果、複数のストアを貼り合わせて運用する羽目になります。

SeekDB（oceanbase/seekdb・GitHubスター2,830・Apache-2.0）は、この“貼り合わせ”を1つのエンジンに畳み込みます。ベクトル・全文・構造化・半構造化を単一のデータベースに統合し、しかもMySQL互換で扱える。開発元は、Alipayなどで本番稼働する分散DB OceanBase（Ant Group系）のチームです。まずは、公式の30秒デモから。手元にpip installして、エージェントの記憶を書き込み→意味検索する様子が一目で分かります。

RAGそのものの全体像（仕組み・構築・ベクトルDB選定）は RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ にまとめています。本記事はその中でも「エージェントのバックエンドDBをどう選ぶか」という一角を、SeekDBを実際にDockerで立てて深掘りする位置づけです。

SeekDBとは — エージェントの状態を丸ごと持つAIネイティブ検索データベース

SeekDBを一言で言えば、「Write. Search. Fork.（書く・検索する・分岐する）」を1つで担うエージェント用のデータベースです。読者がまず知りたい「①結局これで何ができるのか」から答えると、SeekDBは次の4つを同じSQLエンジン・同じMySQL接続の上で提供します。

・書く（Write）：エージェントの観測・会話・中間結果を継続的に書き込む。埋め込み（ベクトル化）はSeekDB側で自動生成できる
・検索する（Search）：意味の近さ（ベクトル）・キーワード一致（全文）・属性フィルタ（構造化）を、1つのSQL文で同時に効かせる
・分岐する（Fork）：データベース全体を数秒でスナップショット（COW）し、エージェントに“安全な砂場”で試させ、良ければ本体にマージ、ダメなら破棄する
・混ぜる（Multi-model）：ベクトル・テキスト・数値・JSONを別々のストアに散らさず、1つのテーブルに同居させる

次に「②何を解決するのか」。従来、エージェントの記憶層を作ろうとすると、ベクトルDB（意味検索）＋全文検索エンジン（キーワード）＋RDB（メタデータ・トランザクション）を並べ、アプリ側で結果をマージする“N+1”のグルーコードが必要でした。SeekDBは、この3つを単一エンジンのSQLに畳み込むことで、グルーコードとデータ同期の悩みを消します。しかも土台は成熟したSQLエンジンなので、WHERE・JOIN・トランザクションといったRDBの当たり前がそのまま使えます。

そして「③何を代替できるのか」。SeekDBが置き換え候補にするのは、「エージェント用にベクトルDB＋全文検索＋RDBを個別に立てて貼り合わせていた構成」です。単一DBに寄せることで、インフラ点数・データ同期・障害点を減らせます。逆に、後述するように「個人のノートPCで自分のファイルを検索したい」用途は守備範囲外で、そこはLEANNのような別レイヤーのツールが向きます。

なぜエージェントに専用のAIネイティブDBが必要か — 「書いた直後に検索」の難しさ

この記事の技術的な核が、この「書いた直後に検索できるをどう成立させるか」です。エージェントのループは、観測を書き込み、数ミリ秒後に関連文脈を読み出し、行動し、また書く——という「継続書込＋直後読み出し」の連続です。ここで並のベクトルDBが詰まるのは、書き込みのたびにベクトル索引（HNSW等）を再構築する処理が、読み書きの経路と競合してP99レイテンシが跳ねるからです。書いている最中は検索が遅くなり、検索している最中は書き込みが待たされる。

SeekDBの回答は、書き込みの経路と索引構築の経路を分離することです。READMEはこれを「async index pipeline（Change Stream）」と「two-level HNSW（incremental＋snapshot）」と表現します。書き込み（DML）はトランザクションをコミットしてすぐ返り、索引構築を待ちません。裏で Change Stream が redo ログを非同期に消費して差分（delta）HNSW を更新し、検索は「差分HNSW」と「スナップショットHNSW」の両方を細粒度ロックで読む。これが「同時実行でもP99が跳ねにくい」設計の骨子です。

重要なのは、この設計が「書いた瞬間に何もかも即反映」を意味しないことです。編集部の実測（後述）でも、データ自体はコミット直後に永続する一方、ベクトルの近似検索（ANN）が効くまでには単一ノード構成で約0.3秒の非同期ラグがありました。これは欠陥ではなく、「書き込みを速く返すために索引を非同期にした」設計の裏返しです。ミリ秒で読めることと、ANN反映に短い遅延があること——この両方を正しく理解しておくと、エージェントのループ設計で「書いた直後に厳密一致で引くならget、意味検索なら一呼吸置く」といった使い分けができます。

SeekDBの4つの武器 — ストリーミング書込・COWフォーク・単一SQLハイブリッド検索・MySQL互換

SeekDBの価値は、個別機能の寄せ集めではなく、エージェントの1ループに必要なものが1つのDBに揃っている点にあります。READMEが掲げる4つの武器を、読者の「何ができる／何を代替する」に引き付けて整理します。

武器1：ストリーミング書込＋同時検索（P99が跳ねにくい）。 前章の非同期索引パイプラインの成果です。書き込みが索引構築でブロックされないため、「毎ミリ秒書きながら、同時に検索する」というエージェント特有の負荷でレイテンシが安定します。公式ベンチでは、同時実行でP99が直列時の1.1倍にしか増えない（MilvusやElasticsearchは同条件で約10倍に膨らむ）と報告されています。

武器2：コピーオンライト（COW）のサンドボックス。 これがSeekDBの一番の個性です。FORK DATABASEでデータベース全体をデータコピーなしで数秒スナップショットし、エージェントに“壊してもいい砂場”を渡せます。試行が成功したらMERGE TABLEで本体に取り込み（THEIRS/OURS/FAILの戦略を選べる）、失敗したらDROP DATABASEで丸ごと捨てる。アプリ層でのsave/restoreではなく、カーネルレベルのCOWなので軽い。「エージェントに自由に探索させたいが、本番データは汚したくない」という要求に、DBの機能そのもので応えます。

武器3：単一SQLのハイブリッド検索。 ベクトル類似度・全文一致（MATCH ... AGAINST）・スカラー条件（WHERE author_id = 42）を、1つの実行プランに押し込みます。アプリ側で「ベクトル検索の結果と全文検索の結果をマージする」N+1のグルーコードが要りません。意味で近く、かつ特定の著者・期間に限定した文書を、1クエリで取れます。

武器4：MySQL互換・フルACID・埋め込み可能。 成熟したOceanBaseのSQLエンジン上に構築され、MySQLプロトコルとエコシステム（ドライバ・SQLAlchemy・各種ツール）がそのまま使えます。動作形態は、アプリに組み込む埋め込みライブラリ・単一ノードサーバー・OceanBase分散クラスタの3段階。小さく始めて分散まで、コードを大きく変えずにスケールできる設計です。

これら4つの武器は、READMEが挙げる代表ユースケースにそのまま対応します。中心はエージェント基盤（メモリ・サンドボックス・状態管理）で、ほかにRAG・ナレッジ検索（vector＋全文＋スカラーを多段アクセス制御付きで）、セマンティック検索（テキスト・画像などマルチモーダル）、AI支援コーディング（意味的コード検索・マルチプロジェクト分離・タイムトラベルクエリ）、オンデバイス/エッジAI（埋め込み・マイクロサーバー形態）まで守備範囲に入っています。SQLだけでなく、Python SDK側にもcollection.hybrid_search(query=..., knn=..., rank=...)という専用メソッドが用意されており、全文（query）とベクトル（knn）の結果をランク融合（rank）で束ねられます。編集部がpyseekdbのAPIを確認したところ、コレクションはupsert/query/getのほか、このhybrid_searchと、前述のCOWを担うforkをメソッドとして直接持っていました——SQLを書かなくても、Pythonからハイブリッド検索と分岐に手が届きます。

実際にDockerで立てて動かした — 書込から意味検索・COWフォークまで（編集部実測）

当サイトの差別化は「README和訳」ではなく「実際に立てて動かす」ことです。SeekDBをApple SiliconのMacで、Docker版のサーバーを起動して、エージェントの記憶パターン（書込→直後に意味検索）と、目玉のCOWフォークまで実測しました。数字はすべて手元の計測で、加工していません。

まず、つまずいた点を正直に。 公式が推す最も手軽な導入はpip install -U pyseekdbですが、SDKの埋め込み（in-process）モードはLinux専用でした。macOSでpyseekdb.Client(path=...)を叩くと、pylibseekdb is not available. Please install pylibseekdb (Linux only) or use RemoteServerClient (host/port) instead.というエラーで止まります。つまりMacではpip installだけでは完結せず、Docker（またはHomebrew）でサーバーを立て、host/portで接続する必要があります。ここは公式READMEの「30-Second Try」からは読み取りにくい落とし穴なので、Macユーザーは最初からDocker版を選ぶのが早いです。

Docker版は素直に立ち上がりました。 docker run -d -p 2881:2881 -p 2886:2886 oceanbase/seekdb:latestで、イメージ取得後、コンテナ内で「Initialization complete.」までおよそ2分。その後はrootユーザー・パスワードなし・ポート2881で接続できました。サーバーは自身を5.7.25-OceanBase seekdb-v1.3.0.0と名乗り、MySQL 5.7互換プロトコルであることが確認できます。

測った結果を、エージェントの1ループに沿って並べます。

・書き込み（upsert 3件・内部で自動embedding）：約250ms。埋め込みモデルのロードが済んだ2回目以降のコレクション生成は0.06秒と軽い（初回はデフォルト埋め込みモデルのDL/ロードで約50秒かかる点は注意）
・永続の即時性：upsert直後にcount()は3を返し、get(id)（厳密一致）も即座にヒット。データ自体はコミット直後に永続している
・書込→意味検索が効くまで：書いた瞬間（t+0）のANNクエリは0件。約0.3秒後に2件ヒット。これが前章の「非同期索引パイプライン」の実挙動
・意味検索（warm・1クエリ）：約22ms。「UIの好みは？」に対し「ユーザーはダークモードを好む」が距離0.41で最上位——意味ベースの検索が妥当に効いている
・COWフォーク：col.fork('episodic_sandbox')が約433msで完了。フォーク直後のsandboxは本体と同じ3件。sandboxに1件追記するとsandbox=4件／本体=3件（本体は不変）。COWの隔離がその場で確認できた

エージェントのメモリを実装するコードは、驚くほど短く済みます。コレクションにupsertで書き、queryで意味検索する——ChromaライクなAPIなので、既存のRAG実装からの移行も軽いです。以下は、実際に動かしたエージェント記憶パターンの最小形です（サーバー接続版）。

import pyseekdb

# Docker/Homebrew で立てたサーバーに接続（Macは embedded 不可）
client = pyseekdb.Client(host="127.0.0.1", port=2881,
                         user="root", password="", database="test")
memory = client.get_or_create_collection(name="episodic")

# 観測を書き込む（埋め込みは SeekDB 側で自動生成）
memory.upsert(ids=["1","2","3"], documents=[
    "ユーザーはダークモードを好む",
    "ユーザーは英語と日本語を話す",
    "ユーザーのタイムゾーンはUTC+9",
])

# 直後に意味検索（documents/distances を include で受け取る）
hits = memory.query(query_texts="UIの好みは？", n_results=2,
                    include=["documents", "distances"])
# → 「ユーザーはダークモードを好む」が距離0.41で最上位

LEANNと何が違うのか — 個人ローカル索引 vs エージェントの状態ストア

ここは、直前に公開したLEANN徹底解説｜埋め込みを保存しないローカルRAGで最大97%省ストレージ｜仕組み・使い方・実測と必ず区別して読んでほしいセクションです。どちらも「ローカルで動くRAG系OSS」ですが、レイヤーも用途もまったく別物で、競合しません。

結論を先に言うと、LEANNは「あなたのノートPCの上」で動く個人向けの検索クライアント、SeekDBは「エージェント／アプリの裏側」に置くサーバー型の状態ストアです。LEANNは自分のファイル・メール・ブラウザ履歴を、埋め込みを保存しない設計で省ストレージに意味検索する“個人の道具”。SeekDBは、複数のエージェントが継続的に書き込み、即座に検索し、試行を分岐する“バックエンドDB”。片方は単一ユーザーのオフライン索引、もう片方はマルチ書込・トランザクション・MySQL互換のデータベースです。

具体的な違いを、選定に効く軸で並べます。埋め込みの扱い一つ取っても思想が逆で、LEANNは「保存しない（都度再計算）」でストレージを削り、SeekDBは「索引として持つ」で検索速度と同時実行を取ります。

汎用のベクトルDB（Milvus・Qdrant・pgvector等）との比較軸そのものは ベクトルデータベース比較2026｜Qdrant・Milvus・pgvectorをRAG用途で選ぶ完全ガイド に詳しくまとめています。SeekDBはその表の「純粋なベクトルDB」とも設計思想が異なり、「RDBの機能（トランザクション・JOIN・COW）を持ったまま、ベクトルと全文を単一SQLで扱える」点が独自色です。「とにかく大規模ベクトル検索だけを最速で」ならMilvus、「既存のPostgreSQLにベクトルを足すだけ」ならpgvector、「エージェントの状態ストアを1つのDBで」ならSeekDB、という住み分けになります。

SeekDBの使い方 — pip・Docker・Homebrewでの導入手順

読者の「SeekDB 使い方」に、実際に動く手順で答えます。SeekDBには用途別に4つの入り口があり、AI/ML用途で最も手軽なのはPython SDK、動作確認はDocker、macOSはHomebrewという使い分けです。前章の実測どおり、pyseekdbの埋め込みモードはLinux専用なので、Mac/WindowsではDockerかHomebrewでサーバーを立てる前提で選んでください。

主要な3ルートのインストールは、次のとおりです。AI/ML用途で最も手軽なのはPython SDK、Mac/Windowsでの動作確認はDocker、macOSへのネイティブ導入はHomebrewが標準です。

# ① Python SDK（推奨）— Linux なら pyseekdb.Client(path=...) でサーバー不要のin-process動作も可
pip install -U pyseekdb

# ② Docker（Mac/Windowsの標準ルート・arm64/amd64ともイメージあり。初期化まで約2分）
docker run -d --name seekdb -p 2881:2881 -p 2886:2886 \
  -v ./data:/var/lib/oceanbase oceanbase/seekdb:latest

# ③ Homebrew（macOSにネイティブ導入）
brew tap oceanbase/seekdb && brew install seekdb

Linuxならin-processの埋め込みモードが使えますが、macOS/Windowsでは使えません。その場合は上のDocker/Homebrewでサーバーを立て、pyseekdb.Client(host="127.0.0.1", port=2881, user="root", password="", database="test")で接続します。このほか、サインアップ不要のクラウド版（curl -X POST https://d0.seekdb.ai/api/v1/instancesで7日間無料のインスタンスが立つ）や、Linuxワンライン・インストーラも用意されています。SDKのフルガイド（接続モード・埋め込み関数・メタデータフィルタ）は公式のpyseekdb ユーザーガイドにあります。

SQLで直接使う場合、SeekDBの個性が最も出るのが単一SQLのハイブリッド検索とCOWフォークです。ベクトルカラムと全文索引を1つのテーブルに定義し、意味の近さと全文一致とスカラー条件を1クエリで効かせられます。エージェントの探索を分岐したいときは、FORK DATABASEでスナップショットして砂場を作り、MERGEかDROPで締める、という流れです。

-- ベクトル列＋全文索引を1つのテーブルに同居
CREATE TABLE articles (
  id INT PRIMARY KEY, title TEXT, content TEXT,
  embedding VECTOR(384),
  FULLTEXT INDEX idx_fts (content),
  VECTOR INDEX idx_vec (embedding) WITH (DISTANCE=l2, TYPE=hnsw)
);

-- 意味の近さ＋全文一致を1つのSQLで（ハイブリッド検索）
SELECT id, title, l2_distance(embedding, '[0.1, 0.3, ...]') AS dist
FROM articles
WHERE MATCH(content) AGAINST('quarterly report')
ORDER BY dist APPROXIMATE LIMIT 10;

-- エージェントの試行を安全に分岐（COWサンドボックス）
FORK DATABASE agent_state TO agent_sandbox_42;   -- データコピーなしで数秒
-- ...sandbox で自由に試したあと、採用か破棄を選ぶ
MERGE TABLE agent_sandbox_42.memory INTO agent_state.memory STRATEGY THEIRS;
-- あるいは丸ごと破棄： DROP DATABASE agent_sandbox_42;

なお、既存のAIフレームワークからも使えます。READMEによれば LangChain・LlamaIndex・Dify・LangGraph・Coze・HuggingFace などとの連携が用意され、MySQLプロトコル経由でSQLAlchemyや任意のMySQLドライバからも接続できます。「今のRAG構成のベクトルストアだけ差し替える」といった段階的な導入も現実的です。

使えるOSSか — ライセンス・活性度・バス係数・企業バックの正直な評価

最後に「自分のプロジェクトに採用してよいか」を、良い点も懸念も並べて正直に評価します（すべて2026年7月19日時点のGitHub API実測）。

・ライセンスはApache-2.0。 商用・改変・再配布とも自由で、特許条項も含む素直なOSSライセンス。法務上のハードルは低い
・開発は活発。 GitHubスター2,830、フォーク311、オープンissue 414件。最新pushは2026年7月17日（2日前）で、コミット自体は継続している
・リリース間隔はやや空き気味。 タグ付きリリースはv1.0.0（2025-11）〜v1.3.0（2026-05）の5本。最新v1.3.0から約8週間、新しいタグは出ていない一方、mainへのプッシュは活発——「開発は続いているがリリースの節目が空いている」状態
・バス係数は約3。 コントリビューターは28人だが、コミットは上位（hnwyllmm 146・footka 83・ep-12221 69）に集中。純粋な個人プロジェクトではないが、少人数の企業チームが牽引する構図で、コミュニティの厚みはこれから
・企業バックは“母体”に注意。 エンジンのOceanBaseはAlipay等で本番稼働する実績あるDBだが、それはOceanBaseの実績。seekdb自体は2025年10月作成の新しい派生で、v1.x前半。大手での実戦投入済みと誤読しないこと
・バージョンの2系統に注意。 サーバー/エンジンはv1.3.0だが、Python SDK（pyseekdb）は別パッケージで1.1.0.post2（本記事の実測時）。ドキュメントを読むときは「サーバー版」と「SDK版」を混同しない

総じて、SeekDBは「エージェントの状態ストアを1つのDBに寄せたい」という、いま伸びている要求に真正面から応えるプロダクトです。COWフォークや単一SQLハイブリッド検索は、既存のベクトルDBの寄せ集めでは得にくい体験で、実機でもその中核（書込→即検索→分岐）はきちんと動きました。一方で、プロダクトとしてはまだ若く、公称ベンチは自社測定である点は割り引いて読むべきです。「小さくDocker版で立てて、自分のワークロードで実測してから採用を判断する」——本記事の検証もその一例です。まずはdocker runで立てて、あなたのエージェントの“書いては読む”を測ってみてください。

参照ソース

・oceanbase/seekdb（公式リポジトリ） — README・アーキテクチャ図・ベンチマーク図・機能一覧（2026-07-19 実測: ★2,830 / Apache-2.0 / 最終push 2026-07-17 / v1.3.0）
・SeekDB 公式ドキュメント（docs.seekdb.ai） — Quickstart・APIリファレンス・デプロイ手順
・pyseekdb — Python SDK（公式リポジトリ） — 接続モード・埋め込み関数・メタデータフィルタのユーザーガイド
・vdb-streambench — 公式ベンチマークの再現リポジトリ — StreamingPerformanceCase の再現手順（自社測定の再現用）
・GitHub REST API（/repos/oceanbase/seekdb・/contributors・/releases）— スター数・コントリビューター・リリースの実測（2026-07-19 取得）