Skip to content
Published on

ベクトルデータベース 2026 完全ガイド - Pinecone・Weaviate・Milvus・Qdrant・Chroma・LanceDB・pgvector・Vespa・Turbopuffer 徹底解剖

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 2026年、ベクトルDBはもはや「AIの付属品」ではない

2023年春、ChatGPTが最初に爆発したとき、「ベクトルデータベース」という言葉はOpenAIのembeddingとセットで登場する新興カテゴリだった。Pineconeがほぼ唯一のマネージドオプションで、「RAG」という略語さえ馴染みがなかった。2024年にはWeaviate・Qdrant・Milvusが本格的に地位を固め、pgvectorがPostgres側から恐ろしい速度で追いかけ始めた。2025年にはTurbopufferのような新興サーバーレス陣営が登場し、2026年現在、この市場は明らかに成熟期に入った。

  • ベクトルDBはもはやオプションではない。 AI製品を構築するなら、何らかの形でベクトル検索を行う必要がある。問題は「どれを使うか」だ。
  • 単一ベクトル検索だけの時代も終わった。 2026年のコアはhybrid retrieval — dense + sparse + lexical + filteringが1クエリに入る。
  • コスト構造が恐ろしいほど多様化した。 Pinecone serverlessの自動スケール、TurbopufferのS3バック、pgvectorの「ほぼ無料」のコストまで — 同じワークロードを100倍の差で運用できる。

この記事で扱うこと:

  1. 2026年ベクトルDBマップ — 誰が作り、誰が使うか
  2. Embeddingとベクトル検索の基礎
  3. HNSW・DiskANN・IVF・PQ — インデックスアルゴリズム比較
  4. Pinecone — マネージド陣営の元祖
  5. Weaviate — モジュラー陣営の強者
  6. Milvus・Zilliz Cloud — 中国・シリコンバレー合作陣営
  7. Qdrant — Rustベースの新星
  8. Chroma — エンベデッドの標準
  9. LanceDB — Arrowネイティブのカラムナ
  10. pgvector — Postgresの逆襲
  11. Vespa.ai — Yahooが作ったベテラン
  12. Turbopuffer — サーバーレスのダークホース
  13. Elasticsearch・OpenSearch — 検索陣営の合流
  14. MongoDB・Redis・SingleStore — 汎用DBのベクトルモード
  15. Sparse vector・BM25・Hybrid retrieval
  16. Quantization — int8・scalar・binary・ternary
  17. Multi-vector retrieval — ColBERT v2とlate interaction
  18. 韓国・日本のベンダーとクラウドリージョン問題
  19. コスト比較とスケールマトリクス
  20. どのワークロードにどのDBを選ぶか
  21. 運用アンチパターン集
  22. 参考資料

第1章 · 2026年ベクトルDBマップ

まず全体像。市場は次の5つの陣営に分かれる。

マネージドSaaS陣営

  • Pinecone。2019年創業、最も古いマネージドベクトルDB。2024年にserverlessが正式GAされ、価格構造が完全に変わった。現在はpodベースとserverlessの2モードを両方提供。
  • Zilliz Cloud。Milvusのマネージド版。Knowhereという独自のベクトルエンジンをコアにする。
  • Turbopuffer。2024年登場。AWS Bedrockのベクトルバックエンド、Cursor、Notionが採用して一気に有名になった。S3の上に乗せたサーバーレス構造がコア。

オープンソース+クラウド陣営(BYOとマネージドの両方)

  • Weaviate。GraphQLが1級、BM25 hybridが最初からデフォルトでサポート。モジュールシステムでembeddingモデルをDB内に統合。
  • Milvus。CNCFグラデュエーションプロジェクト、大規模分散アーキテクチャが強み。DiskANN・IVF・HNSWをすべてサポートするマルチインデックスマシン。
  • Qdrant。Rustベース、メモリ効率とquantizationが強み。payload filteringが1級。

エンベデッド陣営

  • Chroma。最も軽い開始。Pythonでimport chromadbの1行で始める。
  • LanceDB。Lanceというカラムナフォーマットベース、Arrowネイティブ。データがオブジェクトストレージにそのまま住む。

従来DBのベクトルモード陣営

  • pgvector (PostgreSQL extension)。Postgresにベクトル検索を加える。2024年の0.7でhalfvec・sparsevecが追加され、本格的なオプションになった。
  • Elasticsearch 8.18+・OpenSearch 2.18+。既存の検索インデックスの上にANNを乗せた。
  • MongoDB Atlas Vector Search。ドキュメントDBにベクトルを統合。
  • Redis Stack。RediSearchモジュールでベクトル検索。
  • SingleStore・Couchbase Capella・CockroachDB。SQL DB陣営のベクトル合流。

検索エンジン陣営

  • Vespa.ai。Yahooが作った古いエンジン。テンソル・ANN・ランキング表現式が1級。大規模rankingに最強。

このマップが意味するのは単純: 「唯一の正解のベクトルDB」は存在しない。 ワークロードの規模、クエリパターン、運用人員の成熟度によって正解が変わる。

第2章 · Embeddingとベクトル検索の基礎

ベクトルDBを理解するには、まずembeddingの本質をつかむ必要がある。

Embeddingとは? テキスト・画像・音声のような非構造化データを固定長の実数ベクトルにマッピングすること。OpenAI text-embedding-3-largeは3072次元、Cohere embed-v4は1024次元、BGE-M3は1024次元。次元数はモデル設計の決定であって「大きいほど良い」という保証はない。

なぜベクトル検索が必要か? Embeddingは「意味が似ていれば距離が近い」という性質を保証する。だから新しいクエリに対して「最も近いk個のベクトル」を見つけるのがコア演算だ。これを**k-NN (k Nearest Neighbors)**検索と呼ぶ。

問題は次元の呪い。 1億個の1024次元ベクトルから本物のnearest neighborを見つけるには1億回の1024次元dot productが必要。単純なbrute forceはGPUでも秒間1クエリが限界。だから登場したのがANN (Approximate Nearest Neighbors) — 100%の正答を諦めて99%の正答を1000倍速く見つけるアルゴリズム群。

距離関数の選択肢

  • Cosine similarity — 最も一般的。ベクトル長を無視して方向だけ比較。OpenAI embeddingはcosineを前提とする。
  • Inner product (IP) — 長さを含む。一部のembeddingモデルはIPベース。
  • Euclidean (L2) — 絶対距離。一部の画像embeddingで使われる。
  • Hamming — バイナリベクトル用。binary quantization結果に使う。

ほとんどのベクトルDBは上の4つすべてをサポートする。ただし、モデルが学習された距離関数を使うのが正解 — OpenAI embeddingにL2を使うと結果が壊れる。

第3章 · インデックスアルゴリズム — HNSW・DiskANN・IVF・PQ

インデックスがベクトルDBの性格を決める。2026年現在、主流アルゴリズムは4つ。

HNSW (Hierarchical Navigable Small World)

  • 2016年Yury Malkovが提案したグラフベースアルゴリズム。多層グラフを作って上から下に絞り込みながら検索する。
  • 最速のin-memory検索。100万個の1024次元ベクトルで99% recallを1ms台で出せる。
  • 短所: メモリにインデックス全体が乗らねばならない。1億ベクトル × 1024次元ならRAMだけで400GB+。
  • Pinecone pod、Weaviate、Qdrant、Milvus、pgvector(0.5+)、Chromaが全てサポート。

DiskANN (Microsoft Research, 2019)

  • ディスク上でSSD-friendlyなgraphを構築する。10億単位のベクトルを1台のサーバーでサポートできるのがコア。
  • メモリ使用量はHNSWの5%水準、レイテンシは約2〜3倍遅い。
  • Milvus 2.5の推奨アルゴリズム、Turbopufferの内部インデックス、Vespaのオプションの1つ。

IVF (Inverted File Index)

  • 1990年代の情報検索から始まったクラスタリングベースの手法。ベクトル空間をN個のクラスタに分け、クエリに近いm個のクラスタだけ検索する。
  • Faiss(Facebook)で有名になり、MilvusがIVF・IVF-PQ・IVF-SQの多様な派生をサポート。
  • HNSWより構築は速くメモリは少ないが、レイテンシは高い。

PQ (Product Quantization)・SQ (Scalar Quantization)

  • インデックスというより圧縮技法。PQはベクトルをサブベクトルに分割してそれぞれをコードブックにマップし、SQはfloat32をint8に縮める。
  • HNSWやIVFと結合してメモリを4〜32倍減らす。2026年のほぼ全ての大きいインデックスはPQまたはbinary quantizationを使う。

ScaNN (Google, 2020)

  • Googleが自社データセンター用に作ったアルゴリズム。2〜3年間SOTAだった。現在はオープンソース化され、一部のDBがオプションでサポート。

選択ガイド

ワークロード推奨
100万ベクトル未満、レイテンシ最優先HNSW (in-memory)
1億ベクトル以上、コスト最適化DiskANNまたはIVF-PQ
10億ベクトル以上、検索頻度低IVF-PQ + binary quantization
エンベデッド、単一マシンHNSW + SQ

第4章 · Pinecone — マネージド陣営の元祖

Pineconeは2019年Edo Liberty(元AWS・Yahoo)が創業した。「ベクトル検索をマネージドで」というコンセプトを最初に商品化した会社。

2026年現在の2つの運用モード

  • Podベース。伝統的な運用モード。p1・s1・p2のようなpodタイプを選んでインスタンスを立ち上げる。メモリ・ディスク・CPUのトレードオフをユーザーが決める。
  • Serverless。2024年GA。ユーザーはインデックスを作るだけで、データ量に応じて自動スケール。価格は**$0.40/M vectors** + クエリ毎の料金。最も使用量が少ないワークロードに最も魅力的。

コア機能

  • Namespaces。1インデックス内でユーザー別・テナント別の分離。マルチテナンシーRAGの標準パターン。
  • Hybrid search。dense + sparseベクトルを一度に。SPLADEのようなsparse embeddingを一緒にインデックス化。
  • Metadata filtering。任意のJSON metadataで事前フィルタ。ただし選択性が高すぎるフィルタはANNを壊す可能性がある。

Pineconeの強み

  • 運用負担0。インデックスを作れば終わり。
  • AWS・GCP・Azure全リージョン対応。データレジデンシーも明確。
  • 99.99% SLA。エンタープライズが導入しやすいオプション。

Pineconeの弱み

  • 価格が急速に上がる。1億ベクトルをserverlessで運用しても月400+水準(ストレージのみ)。クエリ負荷が大きければ400+水準(ストレージのみ)。クエリ負荷が大きければ1000を簡単に超える。
  • セルフホスティングオプションなし。データ主権が重要な日本・韓国の顧客に制約。
  • 参入後のマイグレーションが難しい — インデックスフォーマットが非公開。

いつ選ぶか? 最初のRAGプロトタイプ、運用人員が少ないスタートアップ、エンタープライズSLAが重要なところ。

第5章 · Weaviate — モジュラー陣営の強者

Weaviateは2019年SeMI Technologies(現Weaviate B.V.)が始めたオープンソースベクトルDB。2026年現在のバージョンは1.27+で、「modules」というコンセプトがコア。

コアコンセプト: Modules

  • text2vec-openai、text2vec-cohere、text2vec-huggingfaceのようなモジュールを有効化すると、DBにデータを入れるときに自動的にembeddingを作る。
  • つまりクライアントでembeddingモデルを直接呼び出す必要がない。「データを入れて → 検索」がそのまま終わる。
  • 短所: embeddingモデルが変わるとインデックスを作り直す必要がある。

Hybrid searchが1級

  • BM25 (lexical) + ベクトル検索を重みで合わせる。このパターンはWeaviateが最初に定着させた。
  • nearTextクエリにhybridオプションを1つ追加するだけ。

Multi-tenancy

  • 1.20から正式サポート。1クラス内でテナント別隔離。SaaS RAGの標準パターン。

Dynamic index (1.25+)

  • インデックスタイプをデータ量に応じて自動切替。小さいときはflat (brute force)、一定サイズを超えるとHNSWに自動切替。

Weaviateの強み

  • GraphQLとRESTの両方のAPI。GraphQL親和的なチームに自然。
  • Embeddingモデル統合。クライアントコードが減る。
  • BM25 hybridが最初からデフォルト。

Weaviateの弱み

  • GraphQL学習曲線。慣れていないと参入が難しい。
  • クラスタ運用が複雑な方。Weaviate Cloud Servicesを使えば解消されるが、コスト上昇。

いつ選ぶか? Hybrid searchが必須のワークロード、embeddingをDBに委任したいとき、GraphQL親和的なチーム。

第6章 · MilvusとZilliz Cloud — 分散陣営の強者

Milvusは2019年Zillizが始めた中国出身のオープンソースベクトルDB。2026年現在2.5+バージョンがメインで、マネージドはZilliz Cloudという名前で提供される。

アーキテクチャ — 最も分散らしい設計

  • Coordinator、Query Node、Data Node、Index Nodeが分離されたmicroservice構造。
  • PulsarまたはKafkaをメッセージキューとして使い、writeを非同期で処理。
  • 結果: 最大規模(10億+ベクトル)でよく動作する設計。

Knowhereエンジン

  • Milvusのコアベクトルエンジン。Faiss(FacebookのANNライブラリ)から始まったが、その後独自に発展。
  • HNSW、IVF-Flat、IVF-PQ、IVF-SQ、DiskANN、ScaNNなどほぼ全てのアルゴリズムをオプションで提供。

マルチインデックスサポート

  • 同じコレクションに複数のインデックスタイプを同時に保持可能。ワークロード別に異なるインデックスを選んで使える。

Milvusの強み

  • 最も多様なインデックスアルゴリズムサポート。研究・実験に最適。
  • 大規模(10億+)ワークロードで最も検証されたオープンソース。
  • CNCFグラデュエーション — ガバナンスが堅実。

Milvusの弱み

  • 運用が最も複雑。Helm chartベースのK8sデプロイが標準だが、コンポーネントが多く学習曲線が急。
  • 小規模(100万未満)にはオーバーキル。

Zilliz Cloud

  • Milvusのマネージド版。AWS・GCP・Azureのマルチクラウド。AWS Tokyoリージョンも正式サポートで日本の顧客に人気。

いつ選ぶか? 10億+ベクトルワークロード、インデックスアルゴリズムを実験したいとき、K8s運用ノウハウがあるチーム。

第7章 · Qdrant — Rustベースの新星

Qdrantは2021年Andrey Vasnetsovが始めたRustベースのベクトルDB。2026年現在1.13+バージョン、マネージドはQdrant Cloudで提供。

なぜRustか?

  • メモリ安全性 + 性能。Go・Pythonベースの競合に対してメモリ使用量が30〜50%少ない。
  • GCがないのでレイテンシ変動が小さい。P99レイテンシが重要なワークロードに有利。

コア機能

  • Payload filtering。全ポイントに任意のJSON payloadをつけてクエリでフィルタリング。他のDBとの違いは「filter-first」インデックス構造 — フィルタ結果が小さくてもANNがよく動作する。
  • Scalar / Binary quantization。1.7から正式サポート。float32 → int8(4倍圧縮)、float32 → binary(32倍圧縮)。2026年binary quantizationはほぼ標準。
  • Multivector。1ポイントに複数のベクトル。ColBERTのようなlate interactionモデルをサポート。
  • Sparse vectors。1.10からSPLADEのようなsparse embeddingをサポート。

Qdrantの強み

  • メモリ効率が最良。
  • フィルタリングとANNの結合が最もクリーン。
  • Rustクライアント、Python・TypeScript・Goすべて豊富。
  • 価格がリーズナブル(Qdrant Cloud基準でPineconeの30〜50%水準)。

Qdrantの弱み

  • 運用者が少ない。PineconeやWeaviateよりコミュニティ規模が小さい。
  • 分散モードの安定性はまだ検証進行中。100億+ではMilvusが優勢。

いつ選ぶか? P99レイテンシが重要なワークロード、payload filtering比重の大きい検索、コスト敏感なところ。

第8章 · Chroma — エンベデッドの標準

Chromaは2022年Jeff HuberとAnton Troynikovが始めたエンベデッドベクトルDB。2026年現在0.5+バージョン。

コンセプト — "AI-native open-source embedding database"

  • Pythonでimport chromadb; client = chromadb.Client()の1行で始める。
  • ローカルディスクモード(PersistentClient)とクライアント-サーバーモードの両方をサポート。

何が違うか

  • 最も軽い開始。最速のプロトタイピング。
  • Embedding関数をコレクションに紐付けできる — データを入れるときに自動でembeddingを作る。
  • Multi-modal collections(テキスト、画像を同じコレクションに)。

Chromaの強み

  • 開始が最も簡単。LangChain・LlamaIndexチュートリアルでは事実上デフォルト。
  • エンベデッドモードが堅実。小さなRAGデモに最適。

Chromaの弱み

  • 大規模(1億+)には不適。単一マシンの限界。
  • 分散運用オプションが弱い。

いつ選ぶか? RAGプロトタイピング、ノートブック単位のデモ、100万以下のエンベデッド使用。

第9章 · LanceDB — Arrowネイティブカラムナ

LanceDBは2023年Eto Labs(現LanceDB Inc.)が始めたエンベデッドベクトルDB。2026年現在0.20+バージョン。

コア — Lanceカラムナフォーマット

  • LanceはParquetの後継を目指したカラムナフォーマット。Arrowネイティブで、ベクトル検索に最適化されている。
  • データがオブジェクトストレージ(S3・GCS)の上にそのまま住む。別のDBインスタンスが必要ない。

なぜカラムナか?

  • Embedding + メタデータ + 元のテキストが1つのファイルに。別のRDBMSと同期する必要がない。
  • Lanceフォーマットはベクトルインデックスをファイルに直接埋め込む。

Blob storageモード (0.18+)

  • オブジェクトストレージにデータが住み、検索時点で必要なpartitionだけfetch。
  • Turbopufferと似たコンセプトだがエンベデッド。

LanceDBの強み

  • データ + ベクトル + メタデータが1つのシステムに。MLパイプラインと自然に統合。
  • Arrowネイティブ — pandas・Polars・DuckDBと直接互換。
  • オープンソース + Rustコア(安定性)。

LanceDBの弱み

  • マネージドSaaSが小さい(LanceDB Cloudはまだ発展中)。
  • 大規模分散運用の事例が少ない。

いつ選ぶか? MLパイプラインがArrowベースのところ、オブジェクトストレージ親和的なワークロード、データ + ベクトルを1つのシステムで管理したいとき。

第10章 · pgvector — Postgresの逆襲

pgvectorは2021年Andrew Kaneが始めたPostgres extension。2026年現在0.8+バージョン。最も衝撃的なトレンドの1つが、「専用ベクトルDBの代わりにただPostgresを使おう」という意見の浮上だ。

なぜpgvectorか?

  • Postgresがすでに運用中なら追加インフラが必要ない。
  • トランザクション・外部キー・JOINをそのまま使いながらベクトル検索を追加。
  • 運用人員がPostgresに慣れているなら学習曲線が0。

0.8の新機能

  • halfvec — float16ベクトルタイプ。メモリ50%削減。
  • sparsevec — sparseベクトルタイプ。SPLADEのようなsparse embeddingをサポート。
  • HNSWとIVFFlatインデックスの両方をサポート。

拡張エコシステム

  • pg_vectorize (Tembo) — Postgres内でembedding生成・検索を自動化するwrapper。
  • pg_vector_scale (TigerData / Timescale) — DiskANNアルゴリズムをPostgresに持ち込む。大規模ワークロードに重要。
  • pgvecto.rs — Rustで書き直した互換extension。性能がより速いとの主張。

pgvectorの強み

  • 運用が最も単純。Postgresがすでにあるから。
  • コストが最安。別のDBライセンスやSaaSコストなし。
  • トランザクション・JOIN・複雑なフィルタリングが自然。

pgvectorの弱み

  • 100万未満ワークロードには完璧だが、1000万以上ではレイテンシが急速に上がる。
  • 書き込みとインデックス構築が同時に起こると負荷が大きい。
  • Postgres運用自体のコスト — バックアップ・HA・チューニング。

いつ選ぶか? すでにPostgresがメインDBのとき、100万未満ベクトルワークロード、トランザクションとベクトル検索を一緒にする必要があるとき。

第11章 · Vespa.ai — Yahooが作ったベテラン

Vespaは2003年Yahooが社内検索エンジンとして始め、2017年にオープンソース化されたベテラン検索エンジン。2026年現在も活発にアップデートされている。

Vespaのアイデンティティ — "ただのベクトルDBではなくフルスタック検索エンジン"

  • ANN (HNSW) + テンソル演算 + ランキング表現式 + 分散インデックス + リアルタイムインデキシングが1システムに。
  • 「ランキング」が1級市民。learned-to-rank、GBDT、ニューラルrankerをインデックスの上で直接評価する。

テンソルモデル

  • Vespaは全てのデータをテンソルとして見る。ベクトルは1次元テンソル、embeddingグループは2次元テンソル。ColBERTのようなmulti-vectorは自然に表現できる。

Vespaの強み

  • 最強のランキング。multi-stage retrieval(sparse → dense → reranker)が最もクリーン。
  • 最大規模の検証。Yahooが数百億文書検索に使用。
  • リアルタイムインデキシングが1級。

Vespaの弱み

  • 学習曲線が最も急。ドキュメントは多いがコアコンセプトが多い。
  • 小さなワークロードにはオーバーキル。
  • 運用複雑度が最も高い。

いつ選ぶか? 検索rankingがコア差別化のところ、10億+文書規模、multi-stage retrievalパイプライン。

第12章 · Turbopuffer — 2024年のダークホース

Turbopufferは2024年に登場した新興サーバーレスベクトルDB。急速に有名になった理由は単純: AWS Bedrock、Cursor、Notionが採用した。

コンセプト — "S3に乗せたベクトル検索"

  • インデックスデータをオブジェクトストレージ(S3)に保存。メモリはキャッシュとしてのみ使う。
  • 結果: 保存コストが圧倒的に安い。1億ベクトルをほぼディスクコストだけで運用できる。
  • 短所: cold queryレイテンシが大きい(最初のクエリはS3からfetch)。

なぜ採用が速かったか

  • AWS BedrockのKnowledge Baseバックエンドの1つとして採用。つまりBedrock顧客は自動的にTurbopufferを使っていることになる。
  • Cursorがコードベースインデキシングに使用。会社あたり数千万〜数億のコードチャンクを効率的に検索。
  • Notionがワークスペース検索に採用。マルチテナンシーがコア。

Turbopufferの強み

  • 価格が最安。使用量の少ないインデックスはほぼ無料に近い。
  • マルチテナンシー親和的 — namespace毎のインデックスが独立にhibernationされる。
  • AWS親和的。

Turbopufferの弱み

  • サーバーレスのcold start。最初のクエリが遅い。
  • 機能がまだ狭い。Multi-vector、sparseのような高度な機能は他の陣営より遅い。
  • セルフホスティングオプションなし。

いつ選ぶか? マルチテナンシーRAG、大量のinactiveインデックスを運用しなければならないとき、AWSリージョン親和的なワークロード。

第13章 · ElasticsearchとOpenSearch — 検索陣営の合流

既存の検索エンジン陣営も急速にベクトル検索を吸収した。

Elasticsearch 8.18+

  • dense_vectorフィールドタイプでembeddingを保存。HNSWインデックスサポート。
  • BM25とhybridクエリが自然(ElasticsearchはBM25の本家)。
  • 8.13からbyte vectorsとquantizationを正式サポート。
  • 最大の強み: 既存のELKスタックとの統合。

OpenSearch 2.18+

  • AWSがフォークしたElasticsearch。AWSリージョンでマネージドが強い。
  • k-NNプラグインが1級。Nmslib、Faiss、Lucenの3つのエンジンオプション。
  • 韓国KT Cloud、日本AWS Tokyoで最も一般的なベクトルDBオプションの1つ。

いつ選ぶか? ELKがすでに運用中のとき、lexicalとベクトルを1クエリで組み合わせたいとき、AWSのOpenSearch Serviceが自然な場合。

弱み

  • ベクトル専用DBに比べてANN性能が若干劣る。
  • インデックス構築時間が長い。
  • 運用複雑度は検索エンジンそのまま付いてくる。

第14章 · MongoDB・Redis・SingleStore — 汎用DBのベクトルモード

MongoDB Atlas Vector Search

  • 2023年発表、2024年GA。MongoDB Atlas(マネージド)でのみ動作。
  • ドキュメントDBなのでembedding + 元のドキュメント + メタデータが1ドキュメントに。
  • HNSWベース。Aggregation pipelineに$vectorSearchステージで統合。
  • 弱点: セルフホスティングMongoDBは未対応。価格が急速に上がる。

Redis Stack (RediSearch + Vector)

  • インメモリ — 最速のレイテンシ。
  • 弱点: データがメモリにあらねばならない。1億ベクトルは非現実的。
  • 強み: 1ms以下のレイテンシが必要なところ(例: 推薦システム)。

SingleStore

  • HTAP DB (OLTP + OLAP)。ベクトル検索をSQLに統合。
  • SQL JOINとベクトル検索が自然に混ざる。
  • 弱点: 運用コスト。マネージドは高い。

Couchbase Capella

  • 7.6からベクトル検索サポート。JSONドキュメントDBのベクトルモード。
  • モバイル親和的(Couchbase Liteと同期)。

CockroachDB・ClickHouse

  • CockroachDBは24.1からベクトルインデックスを実験的にサポート。
  • ClickHouseは24.xからANNインデックスを実験的に。OLAPコンテキストのベクトル検索。

この陣営の共通メッセージ: ベクトル検索は今やデータベースの基本機能だ。

第15章 · Sparse Vector・BM25・Hybrid Retrieval

2026年のRAGはdenseベクトル1つで終わらない。

Sparse vectorとは?

  • ほとんどの次元が0で、一部の次元だけが値を持つ高次元ベクトル。
  • 例: SPLADEは語彙単位(BERTのvocab)で30,000次元のsparseベクトルを作る。
  • 利点: 語彙マッチングと意味マッチングを1つのモデルで — keyword searchの正確性 + embeddingの意味理解。

BM25

  • 1990年代から検索の標準。tf-idf系の整数型lexicalスコア。
  • 依然として強力 — 特にキーワードが明確なクエリではembeddingより上手くいく。

Hybrid retrievalパターン

  1. Reciprocal Rank Fusion (RRF)。denseとsparseの2つの検索結果を順位ベースで融合。最も単純で頻繁にうまく動く。
  2. 重み付き合算。score = alpha · dense_score + (1-alpha) · sparse_score。alphaチューニングが必要。
  3. 2段階 (cascade)。sparseで候補1000個 → denseリランカで100個 → cross-encoderで10個。

どのDBがhybridを得意とするか?

  • Weaviate、Vespa — 最初から1級。
  • Qdrant、Pinecone — sparse vectorサポートを追加。
  • Elasticsearch — BM25の本家、hybridが自然。
  • pgvector — sparsevecタイプで追加されたが、hybrid scoringは自分で書く必要がある。

第16章 · Quantization — int8・scalar・binary・ternary

ベクトル保存コストを1/4〜1/32に減らすコア技法。

Scalar quantization (int8)

  • float32をint8(256段階)にマップ。メモリ4倍削減。
  • recall損失は通常1〜3パーセントポイント。ほとんどのワークロードで最初のオプション。
  • Qdrant・Milvus・pgvector・Weaviateすべて正式サポート。

Product quantization (PQ)

  • ベクトルをsub-vectorに分割してそれぞれをコードブックにマップ。メモリ8〜32倍削減。
  • recall損失が大きい(5〜15パーセントポイント)。大規模インデックスでは不可避。

Binary quantization (1-bit)

  • 各次元を1ビットに。float32比32倍削減。
  • 2024〜2025年のsentence embeddingモデルがbinary-friendly学習でrecall損失が大きく減った。
  • Cohere embed-v4のbinaryモード、OpenAI text-embedding-3のMRL(Matryoshka)は次元削減とquantizationを自然に結合する。

Ternary quantization (1.58-bit)

  • 2024年BitNet論文以降の浮上。各次元を-1、0、+1の3値に。
  • まだベクトルDBの正式サポートは少ないが、実験的オプションが増えている。

MRL (Matryoshka Representation Learning)

  • OpenAI text-embedding-3-largeが導入。同じベクトルから最初のN次元だけ切っても意味が保たれる。
  • 3072次元 → 1024次元に切ると75%メモリ削減 + recall損失最小。

実戦推奨

  • 最初のステップ: float32 → int8 (scalar)。ほぼ無損失。
  • 次: HNSW + int8。
  • 1億+規模: IVF-PQまたはbinary。

第17章 · Multi-vector Retrieval — ColBERT v2とlate interaction

伝統的なdense retrievalは「文書1つ → ベクトル1つ」だった。2024〜2025年の大きな変化はmulti-vector retrievalの浮上だ。

ColBERT v2 (Stanford, 2022)

  • トークン単位でembeddingを保存する。文書1つに100トークンなら100ベクトル。
  • クエリもトークン単位に分解し、max-sim演算でマッチング。
  • 結果: 意味マッチングと語彙マッチングが自然に結合。

なぜ単一ベクトルより強力か?

  • 平均は情報を失う。「machine learning」という文書で「machine」と「learning」がそれぞれ生きている。
  • 意図が分散したクエリに特に強い。

Late interaction

  • ColBERT v2のコアメカニズム。クエリと文書のトークン別interactionを最後に計算。
  • 短所: 保存コスト増加(100倍)。インデックスが巨大になる。

どのDBがmulti-vectorをサポートするか?

  • Vespa — テンソルモデルで最も自然。
  • Qdrant — Multivectorタイプを正式サポート。
  • Weaviate — 1.25からnamed vectorsでサポート。
  • Milvus — 2.4からmulti-vectorコレクションをサポート。

実戦使用

  • コード検索(Cursorがやっていること)。
  • 法律・医療検索 — 正確な用語マッチングが重要なドメイン。
  • 多言語検索 — トークン単位のマッチングが意味を保つ。

第18章 · 韓国・日本のベンダーとクラウドリージョン問題

韓国・日本の企業がベクトルDBを選ぶとき、データレジデンシーとリージョン問題が決定的だ。

韓国

  • Naver Cloud Platform。NCPがMilvusマネージドを正式提供。韓国政府・金融顧客に事実上の標準。
  • KT Cloud。OpenSearchベースのベクトル検索を提供。
  • Kakao i Cloud。独自のembeddingモデルとベクトルDBを合わせたソリューション。
  • KoSearch (Naver Searchチーム分社) — 韓国語特化検索エンジン、ベクトル検索が1級。
  • セルフホスティングオプション — Weaviate、Qdrant、Milvusがよく採用される。

日本

  • AWS Tokyo (ap-northeast-1) — 最も標準。Pinecone・Qdrant・Zillizが全てこのリージョンを正式サポート。
  • AWS Osaka (ap-northeast-3) — DRペアとして活用。
  • GCP Tokyo (asia-northeast1) — Weaviate Cloudの日本リージョン。
  • Azure Japan East — 一部企業(金融・公共)で好まれる。
  • さくらインターネット、IDCフロンティアなど日本独自クラウドはマネージドベクトルDBオプションがほぼない → セルフホスティングが多い。

規制問題

  • 個人情報保護法(韓国)・APPI(日本) — embeddingがPIIに分類される可能性。embedding自体から元のテキストを復元する可能性があり、一部の規制当局はPIIと見る。
  • 医療・金融ドメイン — データレジデンシーがより厳しい。セルフホスティングが自然な選択。

第19章 · コスト比較とスケールマトリクス

価格は急速に変わるので正確な数字は毎回確認が必要。次は2026年5月時点のおおよその比較(1000万ベクトル、1024次元、月1000万クエリを前提)。

DB形態月ストレージコスト月クエリコスト合計(概算)
Pinecone ServerlessSaaS$100$200$300
Pinecone p1.x1 (pod)SaaS$400含む$400
Weaviate Cloud (sandbox)SaaS$50$100$150
Qdrant CloudSaaS$80$80$160
Zilliz Cloud (Standard)SaaS$120$150$270
TurbopufferSaaS$30$50$80
pgvector (AWS RDS r6i.xlarge)self-hosted on cloud$400含む$400
pgvector (Supabase Pro)SaaS$25 + storage含む$80
Self-hosted Qdrant (1 vCPU, 8GB)EC2$50含む$50
MongoDB Atlas (M30 + vector)SaaS$400含む$400
Elasticsearch (Elastic Cloud)SaaS$200含む$200

解釈

  • 最安オプションはTurbopufferまたはself-hosted Qdrant。
  • 最高オプションはPinecone podまたはMongoDB Atlas。
  • 運用人員コストを含めるとSaaSが常に安い。
  • pgvectorはすでにPostgresがある場合のみ有利。新規に立ち上げるとRDSコストが結構かかる。

スケールマトリクス

ベクトル数推奨理由
10万以下Chroma、pgvectorエンベデッド/単一マシンで十分
100万pgvector、Qdrant Cloud単一インスタンスでよく動作
1000万Qdrant、Weaviate、Pinecone Serverless分散インデキシングが必要になる時点
1億Milvus、Pinecone Pod、Vespa本格的な分散運用が必要
10億+Milvus、Vespa、Zilliz Cloud Enterprise数十ノード運用経験が必須

第20章 · どのワークロードにどのDBを選ぶか

シナリオ1: 最初のRAGプロトタイプ(ベクトル10万)

  • 推奨: Chromaまたはpgvector
  • 理由: 最速の開始。意思決定コスト0。

シナリオ2: スタートアップRAG SaaS(ベクトル100万、マルチテナンシー)

  • 推奨: Pinecone ServerlessまたはTurbopuffer
  • 理由: マネージドの運用容易性 + マルチテナンシー親和性。

シナリオ3: エンタープライズRAG(ベクトル1000万、SLA重要)

  • 推奨: Pinecone PodまたはWeaviate Cloud
  • 理由: 99.99% SLA、エンタープライズ契約がよく揃っている。

シナリオ4: 大規模検索システム(ベクトル1億+、rankingコア)

  • 推奨: VespaまたはMilvus
  • 理由: 本格的な分散運用、multi-stage ranking。

シナリオ5: コード検索(ベクトル1000万、multi-vector必要)

  • 推奨: QdrantまたはVespa
  • 理由: multivector・payload filteringが1級。

シナリオ6: コスト最適化(使用量が少ないワークロード)

  • 推奨: Turbopufferまたはself-hosted Qdrant
  • 理由: 使用量ベースの価格または単一EC2で十分。

シナリオ7: Postgresがすでにあってベクトルを追加したい

  • 推奨: pgvector + pg_vector_scale
  • 理由: 別のインフラなしで同じトランザクションで処理。

シナリオ8: 日本データレジデンシー要件

  • 推奨: AWS TokyoのPineconeまたはZilliz Cloud、またはセルフホスティングQdrant
  • 理由: リージョン保証、APPI準拠。

第21章 · 運用アンチパターン集

ベクトルDB運用でよく見るミス。全て実例。

アンチパターン1: embeddingモデルを頻繁に変える

  • embeddingモデルが変わるとインデックスを丸ごと作り直さねばならない。1億ベクトルを再embeddingするコスト = 数千ドル。
  • 対応: モデルを選ぶときに1年単位で決め、バージョンをfrontmatterのように明示する。

アンチパターン2: filter selectivityが高すぎる

  • 「ユーザーAのドキュメントだけ検索」が結果を100個に減らすとANNのグラフが壊れる。
  • 対応: マルチテナンシーならnamespace分離。selectivityが高ければ専用インデックス。

アンチパターン3: ANN recallを測らない

  • 運用中のインデックスのrecall@10が実際にいくらか分からないチームがほとんど。
  • 対応: brute force ground truthを100クエリに対して計算、recall@10を定期測定。

アンチパターン4: hybrid scoreの重みをチューニングしない

  • 0.5 / 0.5で始めた重みをそのまま運用。データ分布に合わない。
  • 対応: ゴールデンデータセットでgrid search。

アンチパターン5: ベクトル次元を任意に切る

  • 「メモリを減らすために1536次元を768に切った」 → MRL学習されていないモデルは意味が壊れる。
  • 対応: モデルカードでMRLサポート可否を確認。OpenAI text-embedding-3はMRL OK。

アンチパターン6: embeddingと元のテキストを分けて保管

  • DBにembeddingだけ、S3に元のテキストだけ。検索結果を人間が見るたびにJOIN。
  • 対応: embedding + 元 + メタデータを1レコードに。またはLanceDB・MongoDBのような統合オプション。

アンチパターン7: インデックス構築とクエリを同じインスタンスで

  • インデックスを作り直す間、クエリレイテンシが5倍になる。
  • 対応: 構築専用インスタンス、blue-greenインデックススワップ。

アンチパターン8: HNSWのM・efパラメータをデフォルトのままにする

  • データ分布によって最適値が違う。デフォルト値(M=16、ef=64)がrecall 90%か99%かが毎回違う。
  • 対応: M・efをデータセットに合わせてチューニング。

第22章 · 参考資料

公式ドキュメント優先、主要学術/公開発表資料のみまとめた。

ベクトルDB公式ドキュメント

既存検索・DB陣営のベクトルドキュメント

コア論文

参考記事

エピローグ — 意見を選ぶということ

この記事の一文要約: ベクトルDBは道具ではなく意見だ。 Pineconeは「ベクトル検索はマネージドが正解」と見る。Milvusは「ベクトルDBは分散システムだ」と見る。Qdrantは「Rust効率が全てだ」と見る。pgvectorは「Postgresがすでにあるのになぜ新しいDBを買うのか」と見る。Vespaは「ベクトル検索はrankingのサブ問題だ」と見る。Turbopufferは「オブジェクトストレージに乗せればコストが100倍安くなる」と見る。

同じ問題でも意見が違えば解法が違う。だから — モデルを選ぶときと同じくらい — ベクトルDBの意見を意識して選ぼう。

次の記事候補: RAG評価システム徹底解剖(Ragas・DeepEval・TruLens)、Embeddingモデル比較(OpenAI vs Cohere vs Voyage vs BGE)、ハイブリッド検索rankingチューニングガイド。

「ベクトルDBはライブラリではなく意見だ。意見を選ぶという自覚が、道具選択の最初のボタンだ。」

— ベクトルデータベース 2026、終わり。

Discuss on Twitter • View on GitHub