필사 모드: ベクトルデータベース 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がオプションでサポート。
**選択ガイド**
| ワークロード | 推奨 |
| --- | --- |
| 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+水準(ストレージのみ)。クエリ負荷が大きければ$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 Serverless | SaaS | $100 | $200 | $300 |
| Pinecone p1.x1 (pod) | SaaS | $400 | 含む | $400 |
| Weaviate Cloud (sandbox) | SaaS | $50 | $100 | $150 |
| Qdrant Cloud | SaaS | $80 | $80 | $160 |
| Zilliz Cloud (Standard) | SaaS | $120 | $150 | $270 |
| Turbopuffer | SaaS | $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公式ドキュメント**
- 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、終わり。
현재 단락 (1/471)
2023年春、ChatGPTが最初に爆発したとき、「ベクトルデータベース」という言葉はOpenAIのembeddingとセットで登場する新興カテゴリだった。Pineconeがほぼ唯一のマネージドオプシ...