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

プロローグ — 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がオプションでサポート。

選択ガイド

第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+水準(ストレージのみ)。クエリ負荷が大きければ$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万クエリを前提)。

解釈

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

スケールマトリクス

第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公式ドキュメント

• Pinecone — https://docs.pinecone.io/
• Weaviate — https://weaviate.io/developers/weaviate
• Milvus — https://milvus.io/docs
• Zilliz Cloud — https://docs.zilliz.com/
• Qdrant — https://qdrant.tech/documentation/
• Chroma — https://docs.trychroma.com/
• LanceDB — https://lancedb.github.io/lancedb/
• pgvector — https://github.com/pgvector/pgvector
• pg_vectorize — https://github.com/tembo-io/pg_vectorize
• pg_vector_scale — https://github.com/timescale/pgvectorscale
• pgvecto.rs — https://github.com/tensorchord/pgvecto.rs
• Vespa.ai — https://docs.vespa.ai/
• Turbopuffer — https://turbopuffer.com/docs

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

• Elasticsearch dense_vector — https://www.elastic.co/guide/en/elasticsearch/reference/current/dense-vector.html
• OpenSearch k-NN — https://opensearch.org/docs/latest/search-plugins/knn/index/
• MongoDB Atlas Vector Search — https://www.mongodb.com/docs/atlas/atlas-vector-search/
• Redis Vector Search — https://redis.io/docs/latest/develop/interact/search-and-query/advanced-concepts/vectors/
• SingleStore Vector — https://docs.singlestore.com/

コア論文

• HNSW (Malkov and Yashunin, 2016) — https://arxiv.org/abs/1603.09320
• DiskANN (Subramanya et al., 2019) — https://www.microsoft.com/en-us/research/publication/diskann-fast-accurate-billion-point-nearest-neighbor-search-on-a-single-node/
• ScaNN (Guo et al., 2020) — https://arxiv.org/abs/1908.10396
• ColBERT v2 (Santhanam et al., 2022) — https://arxiv.org/abs/2112.01488
• SPLADE (Formal et al., 2021) — https://arxiv.org/abs/2107.05720
• MRL — Matryoshka Representation Learning (Kusupati et al., 2022) — https://arxiv.org/abs/2205.13147
• BitNet b1.58 (Ma et al., 2024) — https://arxiv.org/abs/2402.17764

参考記事

• Anthropic — Contextual Retrieval (2024) — https://www.anthropic.com/news/contextual-retrieval
• Cohere — Binary Embeddings — https://cohere.com/blog/int8-binary-embeddings
• OpenAI — New embedding models — https://openai.com/index/new-embedding-models-and-api-updates/
• Microsoft — DiskANN announcement — https://www.microsoft.com/en-us/research/blog/diskann-billion-scale-similarity-search/

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

この記事の一文要約: ベクトル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、終わり。