LanceDBとは？組み込み型ベクトルDBの仕組み・Pythonでの使い方と採用条件

LanceDBは、サーバを立てずにアプリのプロセスの中で動き、ベクトルと元データをLance形式のファイルとしてローカルのディレクトリやS3に書き込むオープンソースのベクトルデータベースです。この記事では2026年10月時点の0.40系を前提に、Lance形式の仕組み、pip installから近傍検索までのPythonコード、4種類のインデックスと日本語の全文検索の設定を順に追います。版管理と同時書き込みで本番前に決める設定を押さえたうえで、Chroma・Milvus Lite・pgvectorとの選び分けを言い切ります。

まとめ：LanceDBはサーバ不要でファイルに書き込む組み込み型のベクトルDB

LanceDBの正体は、Rustで書かれたベクトル検索のライブラリです。lancedb.connect()にディレクトリのパスを渡すだけでデータベースになり、常駐プロセスもポートもありません。保存先をs3://のURIに替えれば、同じコードのままオブジェクトストレージへ書き込めます。

機能はベクトル検索に留まりません。BM25の全文検索、両者を組み合わせるハイブリッド検索、メタデータでの絞り込み、書き込みごとの版管理まで1つのライブラリに入っています。OSS版はApache 2.0で、ライセンス費用はかかりません。

採用してよいのは、1台のサーバに収まる数百万ベクトルまでのRAGや検索機能を、運用の手間を増やさずに組み込みたい場面です。多数のプロセスが同じテーブルへ頻繁に書き込む業務システムや、PostgreSQLの運用体制がすでにある環境では、別の選択肢を取ります。

LanceDBの定義とLanceフォーマット上で動く組み込み型の仕組み

LanceDBを理解する近道は、「データベース」と「ファイル形式」を分けて見ることです。LanceDBはLanceという列指向のファイル形式の上に、インデックスと検索の機能を載せた層にあたります。ベクトルDB全体の中での位置づけは、ベクトルDBの仕組みとインデックス構造の総論で整理しています。

OSS版とEnterprise版の違いとApache 2.0ライセンスの適用範囲

公式のOSS向けFAQによると、LanceDB OSSはApache 2.0で公開された組み込み型の検索ライブラリです。商用製品のLanceDB Enterpriseは、プライベートクラウドか自社クラウドへの持ち込み（BYOC）で展開する分散型の基盤として別に提供されています。

2026年10月29日時点の公式ドキュメントは、この2形態で構成されています。Enterpriseへはdb://で始まるURIとAPIキーで接続し、インデックスの作成や更新はサーバ側が自動で行います。OSSではインデックスを自分で作る点が、運用上の大きな違いです。

ソースはGitHubのlancedb/lancedbリポジトリで公開されています。クライアントはPython・TypeScript・Rustの3言語で、2026年10月時点の最新版はPyPIのlancedb、npmの@lancedb/lancedbとも0.40.0です。

Parquetでなく独自のLance形式を使う理由とランダムアクセス性能

Lance形式が作られた理由は、ベクトルの読み出し方が理由です。近傍検索では、全体を先頭から順に読むよりも、候補になった行だけを飛び飛びに読む処理が多くなります。公式FAQは、Parquetがこのランダムアクセスに弱いことを独自形式を作った理由に挙げ、自社のベンチマークでLanceはParquetより最大1000倍速いと説明しています。数字は開発元の測定である点に注意してください。

もう1つの特徴は、元データとベクトルを同じ行に置けることです。多くのベクトルDBは埋め込みとメタデータだけを持ち、画像や本文は別のストレージに置きます。Lanceはテキストや画像のバイナリも列として保存でき、Apache Arrowを介してpandasやPolarsとの間でデータを受け渡せます。

サーバ型ベクトルDBと比べて構成から消えるプロセスとポート管理

QdrantやMilvusのようなサーバ型では、データベースのプロセスを常駐させ、アプリはネットワーク越しに問い合わせます。コンテナの監視、ポートの開放、認証、バージョンを上げるときの停止計画まで、データベースの運用が1つ増える構成です。

LanceDBにはこの層がありません。アプリのプロセスがファイルを直接読み書きするため、問い合わせにネットワークの往復が挟まらず、バックアップはディレクトリの複製で済みます。代わりに、複数のプロセスからの書き込みをどう調整するかは、アプリ側で考えるべき課題です。この制約は後の章で扱います。

pip install lancedbから近傍検索までを試すPythonの最小手順

ここからは、手元のPCでテーブルを作り、絞り込み付きの近傍検索を実行するまでを追います。コードは公式ドキュメントの0.40系のAPIに沿っています。

Python 3.10以上とAVX2非対応のlancedb-compat導入条件

PyPIのlancedbのページでは、0.40.0の動作条件をPython 3.10以上としています。仮想環境を作り、版を固定してインストールします。

# 仮想環境を作り、版を固定してインストールする
python -m venv .venv
source .venv/bin/activate
pip install "lancedb==0.40.0" pandas

# AVX2 の無い古い x86_64 CPU では、こちらを入れる（lancedb と同時には入れられない）
pip uninstall -y lancedb
pip install lancedb-compat

公式のクイックスタートによると、既定のwheelはAVX2・FMA・F16Cを前提にビルドされています。Sandy BridgeやIvy Bridgeなど古い世代のCPUでは、import lancedbの時点でIllegal instructionで落ちます。古い仮想マシンやCI用のランナーでだけ失敗する場合は、まずここを疑ってください。lancedb-compatは同じimport lancedbで使えます。

connect・create_tableとwhereで行う近傍検索の実装コード

次のコードは、ディレクトリ./lancedb_dataにデータベースを作り、社内文書の見出しと4次元のベクトルを入れて検索します。実際のRAGで使うベクトルは、埋め込みモデルで作るものです。OpenAIとsentence-transformersでの作り方はPythonでembeddingを生成する実装にまとめています。

import lancedb

# ディレクトリを指定するだけで接続できる（無ければ作られる）
db = lancedb.connect("./lancedb_data")

docs = [
    {"id": 1, "dept": "経理", "title": "請求書の締め日と支払サイト", "vector": [0.71, -0.28, 0.60, 0.86]},
    {"id": 2, "dept": "総務", "title": "稟議の承認ルート", "vector": [0.05, 0.88, 0.62, 0.85]},
    {"id": 3, "dept": "経理", "title": "経費精算の差し戻し理由", "vector": [0.68, -0.20, 0.55, 0.80]},
    {"id": 4, "dept": "情シス", "title": "VPN接続の申請手順", "vector": [0.10, 0.75, -0.40, 0.30]},
]

# mode="overwrite" で同名テーブルを作り直す
tbl = db.create_table("docs", data=docs, mode="overwrite")

# 問い合わせベクトルに近い順に、経理の文書だけを2件返す
query = [0.70, -0.25, 0.58, 0.84]
result = (
    tbl.search(query)
    .where("dept = '経理'")
    .select(["id", "title"])
    .limit(2)
    .to_pandas()
)
print(result)  # id・title と距離の列 _distance が返る

whereにはSQLの条件式を文字列で書きます。selectで返す列を絞ると、ベクトルの列を読み出さずに済みます。実行後に./lancedb_data/docs.lanceというディレクトリができ、これがテーブルの実体です。

本番で大量の文書を入れるときは、書き方を変えます。公式FAQは、1行ずつの挿入を避けるよう求めています。挿入のたびにディスク上のフラグメントが1つ増えるためです。空のテーブルを先に作り、tbl.add()にDataFrameやArrowのテーブルをまとめて渡すと、約100万行か2GBごとに自動で並列に書き込まれます。

10万件規模まではインデックス不要とされる根拠とIVF_PQ作成の判断

上のコードはインデックスを作っていません。それでも検索が動くのは、全件との距離計算によるものです。公式FAQは、約10万件までのデータか、100ms程度の遅延を許容できる用途なら、ベクトルインデックスは通常不要としています。根拠として、1000次元のベクトル10万組の距離計算が20ms未満で終わるという自社の測定を挙げています。

100万件を超える場合や、次元が大きい場合はインデックスを作ります。社内規程やマニュアルを数千ファイル入れる程度のRAGなら、チャンクに分けても数万件に収まることが多く、最初はインデックス無しで始めて遅延を測ってから判断する順番で十分です。

インデックス4種と日本語全文検索を本番のデータ量に合わせて選ぶ設定

件数が増えてきたら、ベクトルインデックスと全文検索のインデックスを足します。どちらもOSS版では自分で作成し、データを追加した後は更新も自分で行います。

IVF_PQ・IVF_RQ・IVF_HNSW_SQ・IVF_HNSW_FLATの選定

公式のベクトルインデックスの解説は、4種類のインデックスを次のように整理しています。

実務で最初に効く条件は、絞り込みの有無です。公式は、where付きの検索が多いならIVF_RQかIVF_PQを使うよう警告しています。HNSW系のインデックスは絞り込みと組み合わせると遅延のばらつきが大きくなるためです。部署や文書種別で絞るRAGはこの条件に当たるので、IVF_PQから始めます。

refine_factorとnprobesで再現率と遅延の釣り合いを取る調整

IVF_PQはベクトルを圧縮して距離を計算するため、正解の近傍を取りこぼすことがあります。これを補う値が2つあります。nprobesは探索するクラスタの数、refine_factorは圧縮前のベクトルで距離を計算し直す候補の倍率です。

# 10万件を超えたテーブルに IVF_PQ を作る（コサイン距離）
tbl.create_index(metric="cosine", vector_column_name="vector", index_type="IVF_PQ")

# 上位10件を返すとき、圧縮ベクトルで250件を選び、元のベクトルで並べ直す
result = (
    tbl.search(query)
    .where("dept = '経理'")
    .nprobes(50)
    .refine_factor(25)
    .limit(10)
    .to_pandas()
)

公式FAQはrefine_factorを5〜50の範囲で設定し、遅延への影響を測ってから本番に出すよう勧めています。同じFAQでは、GIST-1Mというデータセットでnprobesを約50、refine_factorを50にしたとき、再現率0.95超を10ms未満で達成したとしています。自社の文書で同じ値になる保証は無いため、正解付きの質問を数十件用意して再現率を測るのが確実です。

日本語全文検索のngramとlindera/ipadicの選定手順

製品の型番や社内の略語は、ベクトル検索よりも全文検索のほうが確実に当たります。LanceDBの全文検索はBM25で、公式の全文検索インデックスの解説によると、文章を語に区切るトークナイザの既定値はsimpleです。空白と句読点で区切る方式のため、日本語の文はほぼ1つの長い語として扱われます。

# 日本語の見出しに全文検索のインデックスを作る（n-gram で区切る）
tbl.create_fts_index("title", base_tokenizer="ngram", replace=True)

hits = tbl.search("差し戻し", query_type="fts").limit(5).to_pandas()

日本語の選択肢は2つです。ngramは辞書が要らず、表記揺れや未知語に強い反面、インデックスが大きくなります。形態素解析で区切るlindera/ipadicは語の単位が自然ですが、辞書のモデルファイルをlance/language_modelsの配下か、環境変数LANCE_LANGUAGE_MODEL_HOMEで指す場所に置く必要があります。コンテナで動かすなら、辞書の配置をイメージのビルド手順に入れてください。フレーズ検索を使う場合はwith_position=Trueも必要で、既定はFalseです。

ベクトル検索と全文検索の結果は、公式のハイブリッド検索の解説のとおり、リランカーで1つの順位にまとめられます。既定の統合方法はRRFです。BM25とベクトル検索を組み合わせる理由と順位の統合式は、ハイブリッド検索とRRFの仕組みで詳しく扱っています。

版管理・同時書き込み・保存先で本番運用の前に決めておく設定項目

手元で動いたコードをそのまま本番に置くと、ディスクの増加と、別プロセスの書き込みが見えない現象で詰まります。どちらも既定値の挙動なので、先に設定を決めておきます。

書き込みごとに増える版をcheckoutで戻しoptimizeで掃除する運用

公式の版管理の解説によると、テーブルの作成・追加・更新・削除・復元はそれぞれ新しい版を作ります。過去の版は消えずに残るため、誤って削除した行を戻せる反面、何もしなければディスクは増え続けます。

from datetime import timedelta

print(tbl.version)                             # 現在の版番号
print([v["version"] for v in tbl.list_versions()])

tbl.checkout(1)          # 版1を読み取り専用で開く
print(tbl.count_rows())
tbl.checkout_latest()    # 最新の版へ戻る

# 版1の内容で新しい版を作って巻き戻す場合
# tbl.restore(1)

# フラグメントを統合し、1日より古い版のファイルを削除する
tbl.optimize(cleanup_older_than=timedelta(days=1))

optimize()は、既定では7日より古い版を削除します。タグを付けた版は削除の対象外です。毎晩の一括投入でテーブルを更新するなら、投入の後にoptimize()を呼ぶ処理をジョブに入れ、何日分の版を残すかを障害時に戻したい日数で決めます。

別プロセスの書き込みが見えないread_consistency_intervalの既定値

Webアプリのプロセスが検索し、別のバッチが文書を追加する構成では、バッチの追加がWebアプリ側に反映されない、という現象が起きます。公式の一貫性の解説によると、read_consistency_intervalは既定で未設定です。未設定のときは、別プロセスの更新を読み取り時に自動で確かめません。

from datetime import timedelta
import lancedb

# 読み取りのたびに最新の版を確かめる（遅延とストレージへの問い合わせは増える）
db = lancedb.connect("./lancedb_data", read_consistency_interval=timedelta(0))

# 5秒ごとに確かめる（多少古い結果を許容する）
# db = lancedb.connect("s3://my-bucket/rag", read_consistency_interval=timedelta(seconds=5))

書き込み側にも制約があります。公式FAQは同時書き込みに対応するとしつつ、書き込むプロセスが多すぎるとコミットの再試行回数を使い切って失敗すると明記しています。Pythonのmultiprocessingでforkを使うことも非推奨です。書き込みは1つのジョブかキューに集め、読み取りだけを並列にする設計が安全です。

ローカルNVMe・EBS・S3の遅延差と保存先ごとの使い分けの目安

保存先は接続URIを替えるだけで切り替えられますが、検索の遅延は大きく変わります。公式のストレージ構成の解説の目安を並べます。

同じ解説によると、S3は原子的な書き込みに対応したため、同じテーブルへの同時書き込みに外部の調整役は要りません。とはいえ数百msの遅延は対話型のチャットで体感に出ます。RAGの検索窓口に使うなら、EBSかローカルディスクにテーブルを置き、S3は原本の保管と災害対策に回す構成が扱いやすい選択です。

LanceDB採用条件とChroma・Milvus Lite・pgvectorの比較基準

組み込み型のベクトルDBは複数あり、どれも数行で動きます。差が出るのは、データ量が増えたときと、書き込む主体が増えたときの扱いです。

1台に数百万ベクトルまでのRAGや手元の検証ならLanceDBを採る基準

LanceDBを選んでよいのは、次の条件がそろうときです。ベクトルの件数が1台のサーバに収まる数百万件までであること。書き込みが夜間バッチなど1つの経路に限られること。そして、データベースのサーバを別に運用する体制を作りたくないことです。公式FAQも、OSS版は単一ノードで数百万ベクトルを扱え、数億件を超える規模ではEnterpriseを勧めると書いています。

社内規程・製品マニュアル・問い合わせ履歴を検索させるRAGは、多くがこの範囲に入る用途です。全文検索と版管理まで同じライブラリで揃うため、型番検索の取りこぼしや、誤投入からの巻き戻しにも追加の部品なしで対応できます。文書の整備から検索精度の評価、本番の構成までを含めたRAGの設計は、RAG構築支援で相談を受け付けています。

多数の同時書き込みや既存PostgreSQL運用で見送る場面と代替手段

反対に、次の場面ではLanceDBを見送ります。多数のユーザーの操作がそのまま同じテーブルへの書き込みになる業務システム。権限や監査をデータベース側で一元管理したい環境。すでにPostgreSQLを運用していて、業務データとベクトルを同じトランザクションで扱いたい場合です。

Milvus Liteは、本番のMilvusへ移す前提の試作に向きますが、同時実行の制約から本番運用には置けません。その理由と移行の手順はMilvus Liteの同時実行の制約とStandalone移行で扱っています。ChromaはSQLiteとHNSWで動き、クライアント・サーバ構成へ同じAPIで移れる点が強みで、Chromaの仕組みと日本語検索の実測と並べると違いがはっきりします。LanceDBの優位は、大きなデータでもディスク上のインデックスで動くことと、全文検索・版管理まで内蔵している点です。

よくある質問

LanceDBの検討でよく出る疑問に、公式ドキュメントとFAQの記述をもとに答えます。

LanceDBは無料で使えますか？

使えます。LanceDB OSSはApache 2.0のライセンスで公開されており、自社のサーバやPCで動かす限りライセンス費用はかかりません。改変したソースの公開義務も無いため、自社製品に組み込む場合も法務の確認は軽く済みます。費用が発生するのは、分散構成や自動のインデックス管理を備えた商用版のLanceDB Enterpriseを使う場合で、こちらは開発元への問い合わせによる見積もりです。

LanceDBとLanceの違いは何ですか？

Lanceは機械学習向けの列指向のファイル形式で、LanceDBはその上に作られたデータベースです。Lanceはデータの保存とランダムアクセスを担い、LanceDBはベクトルインデックス・全文検索・絞り込み・版管理といった検索の機能を加えています。LanceDBのテーブルの実体は.lanceで終わるディレクトリで、PythonのpylanceパッケージやDuckDBのLance拡張から直接読むこともできます。

LanceDBはどのくらいのデータ量まで扱えますか？

公式FAQは、OSS版が単一ノードで数百万ベクトルを無理なく扱えるとしています。約10万件まではインデックス無しでも実用的な速度で検索でき、100万件を超えたらインデックスの作成を勧めています。数億件以上やテラバイト単位のデータでは、分散構成のLanceDB Enterpriseが公式FAQの推奨する選択肢です。件数よりも、書き込む経路の数が先に限界を決める点に注意してください。

LanceDBはJavaScriptやTypeScriptからも使えますか？

使えます。npmの@lancedb/lancedbパッケージがあり、2026年10月時点でPython版と同じ0.40.0が出ています。Node.jsのサーバやElectronのアプリにデータベースを組み込めるのが利点です。ただし公式の解説では、スカラー量子化を使うIVFのインデックスはTypeScriptから作れないなど、Python版と機能差がある箇所が明記されています。採用前に使う機能の対応を確かめてください。

LanceDBをLangChainと組み合わせてRAGを作れますか？

作れます。公式のLangChain連携の解説に、文書を読み込んでLanceDBのベクトルストアに入れ、検索に使うまでの手順が掲載されているので参照してください。ただし掲載例のimportは古い書き方のため、LangChainの現行版の構成に合わせて読み替える必要があります。LangChainでのRAGの全体像と現行版の書き方は、LangChainでRAGを構築する手順を参照してください。

関連記事

• ベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順【2026年版】：ベクトルDB全体の仕組みと製品比較。
• Milvusとは？v3.0の外部コレクション・インデックス選定・デプロイ形態【2026年版】：数億件規模を扱うサーバ型の代表例。
• ベクトルデータベースの価格とおすすめ｜3タイプの料金体系比較とRAG用途の選び方【2026年版】：組み込み型・マネージド型を含む費用の比べ方。
• ベクトル検索とセマンティック検索の違い：目的と手段の関係・仕組みと日本語での実測：検索方式の違いと日本語での挙動。
• Chroma（ChromaDB）とは？読み方・使い方と日本語検索の実測、pgvectorとの違い：組み込み型の比較先。