필사 모드: ベクターデータベース 2026 完全ガイド - Pinecone · Weaviate · Qdrant · Milvus · pgvector · LanceDB · Chroma · FAISS · DiskANN 徹底解説

はじめに — 2026年5月、ベクターDBは「汎用インフラ」になった

2023年までベクターデータベースは「RAGを作りたいけれどembeddingをどこに入れる?」という問いに答えるための新興カテゴリだった。2026年5月の今、その問いは決着した。RAGは成熟し、ベクター検索はあらゆるOLTP/OLAP DBで標準オプションとなり、ハイブリッド検索(BM25 + dense vector + リランカ)が標準になった。

本稿はマーケティングマトリクスではない。「今のプロダクションでどのベクターDBがどの位置にあるか」を正直に書く。Pinecone Serverless v3、Weaviate 1.30、Qdrant 1.13、Milvus 2.5 + Zilliz Cloud、Chroma、LanceDB、pgvector 0.8 + pgvectorscale 0.6 + ParadeDB、Vespa、OpenSearch k-NN、Redis Vector、MongoDB Atlas Vector、Couchbase、SingleStore、Turbopuffer、Marqo、Vald、NGT、FAISS、ScaNN、DiskANN、Annoy、DuckDB VSS、sqlite-vec、jinaのHnswLib利用まで、実APIと一緒に比較する。

ベクターDB 2026の地形 — 5つのトラックに分解する

まず全体像。2026年のベクターDB市場は次の5トラックに分かれた。

1. **専業(ピュアプレイ)ベクターDB**: Pinecone、Weaviate、Qdrant、Milvus、Chroma、LanceDB、Turbopuffer、Marqo

2. **リレーショナルDBのベクター拡張**: pgvector + pgvectorscale、ParadeDB、SingleStore、Oracle 23ai、SQL Server 2025

3. **検索エンジンのベクター拡張**: Elasticsearch dense_vector、OpenSearch k-NN、Vespa、Solr

4. **汎用NoSQLのベクター拡張**: MongoDB Atlas Vector、Redis Vector、Couchbase、DynamoDB(2025 GA)

5. **組み込み / ライブラリ**: FAISS、ScaNN、DiskANN、Annoy、NGT、HnswLib、Vald、DuckDB VSS、sqlite-vec

同じANNアルゴリズム(多くはHNSW)を使っていても、運用モデル、価格、マルチテナンシ、ハイブリッド検索のサポートで大きく分かれる。下からトラックごとに見る。

ANNアルゴリズム 1 — HNSWが事実上の標準になった理由

ANN(Approximate Nearest Neighbor)の2026年の標準は **HNSW(Hierarchical Navigable Small World)** だ。Yu. Malkov と D. Yashunin による2016年の論文が出発点で、多層グラフ上の貪欲探索を行う。

- **レイヤー0**: すべてのノード。最も密な近傍接続。

- **上位レイヤー**: 確率的にノードを昇格させる。上に行くほどスパースになる。

- **探索**: 最上位レイヤーから始めて貪欲に下る。各レイヤーで `ef` サイズの候補キューを保つ。

長所は **挿入・削除・探索がすべてグラフ操作**なので動的データに強いこと。短所は **メモリ使用量**が大きいこと。1億の768次元float32ベクター + HNSW(M=16)で約350GBのRAMを消費する。

Pinecone、Weaviate、Qdrant、Milvus、pgvector 0.8、Elasticsearch、OpenSearch、Redis、Chroma、LanceDB、Vespaのすべてが既定または選択肢としてHNSWを提供する。

ANNアルゴリズム 2 — IVF · IVF-PQ · DiskANN · ScaNN の居場所

HNSWが標準とはいえ、他のアルゴリズムも生きている。

- **IVF(Inverted File Index)**: k-meansで空間を `nlist` セルに分割し、クエリでは `nprobe` セルだけ見る。MilvusとFAISSのクラシック選択肢。

- **IVF-PQ**: IVF + Product Quantization。ベクターをPQコードに圧縮しメモリを1/8〜1/32に削減。10億超では必須。

- **DiskANN**(Microsoft Research): NVMe SSD向けのグラフインデックス。10億ベクターを単一ノードで配信。pgvectorscaleのStreamingDiskANNが採用。

- **ScaNN**(Google): 非対称量子化 + 木の組み合わせ。TensorFlow親和。精度/速度カーブが優秀。

- **Annoy**(Spotify): 乱択射影フォレスト。mmap親和。静的インデックス向き。

- **NGT**(Yahoo Japan): ONNGグラフ。Valdクラスタの中核。

簡易ピッカーは次の通り。

- **1千万ベクター未満、動的書き込み**: HNSW

- **1億超、メモリ圧迫**: IVF-PQ または DiskANN

- **読み取り専用の大規模**: ScaNN、Annoy

リコール vs レイテンシ vs コスト — ann-benchmarksの現実

ann-benchmarks.com の2026年5月のデータをGIST-960-1Mで圧縮すると次の通り。

- HNSW(M=16、ef=200): recall@10 0.99、p99 1.2ms、RAM 4GB

- IVF-PQ(nlist=4096、nprobe=64、m=32): recall@10 0.93、p99 0.9ms、RAM 0.5GB

- DiskANN(R=64、L=100): recall@10 0.98、p99 4ms、RAM 1GB + SSD

- ScaNN(reorder=200): recall@10 0.99、p99 0.6ms、RAM 3GB

ポイントは「フリーランチはない」こと。リコールを0.95から0.99に引き上げると、レイテンシは2〜5倍、メモリは1.5〜3倍になるのが普通だ。プロダクションでは `recall@10 = 0.95` で十分な場合が多い。

Pinecone Serverless v3 — マネージドのデフォルト

Pineconeは2024年1月にServerlessをGAし、2025年Q4にv3で **ストレージとコンピュートの完全分離**を完成させた。2026年5月時点で最も「とりあえず使える」マネージド選択肢だ。

- インデックス作成にはdimension、metric(cosine/dotproduct/euclidean)、cloud(aws/gcp/azure)、regionだけ指定。

- バックエンドは独自ANN(HNSW亜種 + パーティショニング)。ユーザには見せない。

- 価格は **ストレージ + 読み取り単位(RU) + 書き込み単位(WU)** の3点。コールドインデックスはほぼ無料。

- マルチテナンシは **namespace** 単位。namespaceごとにRU課金が独立。

- 2025年以降、sparse(BM25)+ denseハイブリッドを1級サポート。

- 2026年Q1にColBERT風のlate interactionをベータ追加。

典型的なPython使用は次の通り。

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="pc-...")

pc.create_index(

name="rag-prod-2026",

dimension=1024,

metric="cosine",

spec=ServerlessSpec(cloud="aws", region="us-east-1"),

)

index = pc.Index("rag-prod-2026")

index.upsert(

vectors=[

{"id": "doc-1", "values": [0.01] * 1024, "metadata": {"tenant": "acme", "lang": "ja"}},

],

namespace="tenant-acme",

)

result = index.query(

vector=[0.01] * 1024,

top_k=10,

namespace="tenant-acme",

filter={"lang": {"$eq": "ja"}},

include_metadata=True,

)

Pineconeの最大の強みは「運用負荷ゼロ」、弱みは価格予測の難しさ。RU/WU課金なのでトラフィックが跳ねれば請求書も跳ねる。

Qdrant — Rustベースのセルフホスト王者

QdrantはRustで書かれたOSSベクターDBで、セルフホスティング・トラックで最も人気がある。2026年5月時点の1.13ラインの特徴は次の通り。

- **HNSW + scalar/product quantization**(int8、binary、PQ)の組み合わせ。binary quant + reorderでディスク・メモリを4〜32倍節約。

- **Payloadインデックス**: keyword、integer、float、geo、full-text、datetimeのインデックスを内蔵。pre-filter時はRDBのように動く。

- **Sparse + denseベクターの同時検索** + RRF/DBSFフュージョン。

- **マルチベクター**(ColBERT等のlate interaction)を1級サポート。

- **分散クラスタ**(シャーディング + Raft)と **Qdrant Cloud** マネージドの両方を提供。

コレクション作成とクエリ例。

from qdrant_client import QdrantClient

from qdrant_client.models import (

Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue,

)

client = QdrantClient(url="http://qdrant:6333", api_key="q-...")

client.create_collection(

collection_name="rag_prod",

vectors_config=VectorParams(size=1024, distance=Distance.COSINE),

)

client.upsert(

collection_name="rag_prod",

points=[PointStruct(id=1, vector=[0.01] * 1024, payload={"lang": "ja", "tenant": "acme"})],

)

hits = client.search(

collection_name="rag_prod",

query_vector=[0.01] * 1024,

query_filter=Filter(must=[FieldCondition(key="lang", match=MatchValue(value="ja"))]),

limit=10,

)

Qdrant CloudはGCP/AWS/Azureでマネージドを提供し、メモリ/ディスクベースの価格でPineconeより予測しやすい。セルフホストもHelm chartで提供されK8sに馴染む。

Weaviate — モジュール + ハイブリッドの強者

WeaviateはGoで書かれたOSSベクターDBで、**モジュールシステム**と **1級のハイブリッド検索**が強みだ。2026年5月の1.30ラインで:

- **モジュール**: text2vec-openai、text2vec-cohere、text2vec-jina、multi2vec-clip、generative-openai、reranker-cohereなど多数。embedding生成をDB内で完結。

- **Hybrid search**: BM25 + dense + Reciprocal Rank Fusionを1行で。

- **マルチテナンシ**: テナントごとにインデックスディレクトリを分離。数万〜数十万テナントにスケール。

- **Weaviate Cloud Services(WCS)** がマネージド。Hybrid Cloud(BYOC)は2025年Q4にGA。

- **Generative検索**: 検索結果をLLMに直送してRAG応答を返すワンライン。

スキーマ作成とハイブリッド検索の例。

from weaviate.classes.config import Configure, Property, DataType

client = weaviate.connect_to_local()

client.collections.create(

name="Doc",

properties=[

Property(name="content", data_type=DataType.TEXT),

Property(name="lang", data_type=DataType.TEXT),

],

vectorizer_config=Configure.Vectorizer.text2vec_openai(model="text-embedding-3-large"),

generative_config=Configure.Generative.openai(model="gpt-4.1-mini"),

)

docs = client.collections.get("Doc")

result = docs.query.hybrid(

query="ベクターデータベース比較",

alpha=0.5,

limit=10,

)

Weaviateの強みは「embedding + 検索 + 生成」を1システムで終えられること。短所はモジュール依存が複雑でセルフホスト運用コストが上がること。

Milvus 2.5 + Zilliz Cloud — 大規模 + GPU の王者

MilvusはLF AI & Data Foundation配下の大規模ベクターDBで、十億〜百億ベクター規模で最も検証されている。2026年5月の2.5ライン:

- **分散アーキテクチャ**: query node、data node、index node、coordが分離。K8sネイティブ。

- **インデックス選択肢**: HNSW、IVF、IVF-PQ、DiskANN、GPU-CAGRA、GPU-IVF-PQ。

- **GPUインデックス**: NVIDIA cuVS / RAFTベースのGPU-CAGRA。CPU比10〜100倍のスループット。

- **ハイブリッド検索**: BM25 + dense + RRF、複数ベクターフィールド、partition_keyベースのマルチテナンシ。

- **Zilliz Cloud**: Milvus作者陣によるマネージド。AWS/GCP/Azureの全リージョン。

コレクション作成とハイブリッド検索例は次の通り。

from pymilvus import MilvusClient, DataType

client = MilvusClient(uri="http://milvus:19530", token="root:Milvus")

schema = client.create_schema()

schema.add_field("id", DataType.INT64, is_primary=True, auto_id=True)

schema.add_field("dense", DataType.FLOAT_VECTOR, dim=1024)

schema.add_field("sparse", DataType.SPARSE_FLOAT_VECTOR)

schema.add_field("tenant", DataType.VARCHAR, max_length=64)

idx = client.prepare_index_params()

idx.add_index("dense", index_type="HNSW", metric_type="COSINE", params={"M": 16, "efConstruction": 200})

idx.add_index("sparse", index_type="SPARSE_INVERTED_INDEX", metric_type="IP")

client.create_collection("rag", schema=schema, index_params=idx)

Milvusのアイデンティティは「エンタープライズ大規模」だ。1億未満のワークロードでは運用負荷が大きく、Pinecone / Qdrant / Weaviateの方が向く。

pgvector + pgvectorscale + ParadeDB — Postgresが「十分に良い」陣営

2026年の興味深い潮流は **Postgres + pgvector** が「特殊要件がなければ十分に良い」デフォルトに定着したことだ。

- **pgvector 0.8**: HNSW + IVFFlatインデックス。2025年にbinary quantization、halfvec(16ビット)が追加。

- **pgvectorscale 0.6**(Timescale): StreamingDiskANNインデックス + 統計的binary quantization。pgvector比で10〜100倍速いフィルタ検索。

- **ParadeDB**: Postgres上のBM25(`pg_search`)+ ベクターの結合。ハイブリッド検索がPostgresで完結。

- **Supabase、Neon、Aurora、Cloud SQL**: いずれもpgvectorを既定提供。

典型的な使い方:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE EXTENSION IF NOT EXISTS vectorscale;

CREATE TABLE doc (

id bigserial PRIMARY KEY,

tenant_id uuid NOT NULL,

content text NOT NULL,

embedding vector(1024) NOT NULL

);

CREATE INDEX ON doc USING diskann (embedding vector_cosine_ops);

CREATE INDEX ON doc (tenant_id);

SELECT id, content, 1 - (embedding <=> $1) AS score

FROM doc

WHERE tenant_id = $2

ORDER BY embedding <=> $1

LIMIT 10;

長所は **トランザクション、JOIN、権限、バックアップ**がそのままPostgresであること。短所は1億ベクター超でHNSWメモリ圧迫が厳しく、マルチテナンシをRLSで解くとインデックス効率が落ちる点。

Chroma · LanceDB — 組み込み / ローカル トラック

プロダクション単一ノードまたはノートブックでRAGプロトタイプを作るとき、最もよく使われる2ツール。

- **Chroma**: Python / JS優先。単一プロセス組み込み、またはHTTPサーバ。SQLite + DuckDB + HNSWLibの組み合わせ。2026年Q1にdistributedモードがベータ。

- **LanceDB**: Rust製。Apache Arrow + Lanceファイル形式ベース。S3/GCS上にそのまま乗せても動く。組み込み + サーバ両対応。マルチモーダル親和。

LanceDBの売りは「S3に .lance ファイル1個で完了」。専用マネージドはまだないが、LanceDB Cloud(ベータ)とSageMaker統合が増えている。

db = lancedb.connect("s3://my-bucket/lance-db")

tbl = db.create_table(

"docs",

data=[{"id": 1, "vector": [0.01] * 1024, "lang": "ja"}],

mode="overwrite",

)

tbl.create_index(metric="cosine", index_type="IVF_HNSW_SQ", num_partitions=256)

hits = tbl.search([0.01] * 1024).where("lang = 'ja'").limit(10).to_list()

Elasticsearch · OpenSearch · Vespa — 検索エンジン トラック

既存のBM25検索エンジンがdense vectorを本格サポートし、別途ベクターDBを導入せず同じクラスタでハイブリッド検索する流れが定着した。

- **Elasticsearch 8.x〜9.x**: `dense_vector` フィールド + HNSW。`_search` 内で `knn` + `query`(BM25)結合のハイブリッド。ELSER(Elastic Learned Sparse Encoder)で自社sparse vectorも提供。

- **OpenSearch 2.x〜3.x**: `knn` プラグイン。FAISS / Lucene / NMSLibバックエンドを選択。AWS OpenSearch Serviceでマネージド。

- **Vespa**: Yahoo製でOSS化された検索エンジン。tensor表現が1級。マルチベクター、マルチステージランキングが強み。Spotify Discover Weekly、Yahoo Mailで採用。

既存検索クラスタを持つ組織が最初に試す経路だ。短所は専業ベクターDBに比べてインデックススループット / メモリ効率が劣る点。

NoSQLのベクター拡張 — Mongo · Redis · Couchbase · SingleStore · DuckDB · SQLite

運用データが既に入っているDBがベクター対応すれば運用は最もシンプル。

- **MongoDB Atlas Vector Search**: Atlas専用の検索インデックス(Lucenベース)。`$vectorSearch` aggregationステージ。

- **Redis 8 Vector Search**: HNSW + flat。Redis Stack / Redis Enterprise。インメモリでms未満の応答。

- **Couchbase Vector Search**: 2024 GA。SQL++内でベクタークエリ。

- **SingleStore**: 分散SQL DB + ベクター。分析 / 検索 / トランザクションを1クラスタで。

- **DuckDB VSS拡張**: in-process分析 + HNSW。DataFrame / Parquetにそのままインデックス。

- **sqlite-vec**: Alex GarciaによるSQLite拡張。モバイル / エッジRAG向け。

このトラックの共通点は「ベクター用に別クラスタを作らない」こと。1億未満で本業がOLTPなら最も合理的な選択になることが多い。

新興トラック — Turbopuffer · Marqo · Vald · NGT · Tair Vector

マネージド / 特化市場でも新規参入が増えた。

- **Turbopuffer**: S3に乗せたサーバレスベクターDB。価格が非常に低く(ストレージ + クエリ単位課金)、コールドデータに強い。2025年にNotionが採用して注目。

- **Marqo**: embedding + 検索を1パッケージで提供。マルチモーダル親和。cloud + セルフホスト。

- **Vald**(Yahoo Japan / LY): K8sネイティブのNGTベース分散ベクターDB。LINE検索で使用。

- **NGT**(Yahoo Japan): グラフベースのANNライブラリ。ONNG、PANNG、QGなどの変種。

- **Tair Vector**(Alibaba Cloud): Redis互換 + ベクター。中国市場のデフォルト。

FAISS · ScaNN · DiskANN · Annoy · HnswLib — ライブラリ トラック

DBではなくライブラリとして自前でインデックスを扱うトラック。研究や組み込みでは今も中核。

- **FAISS**(Meta): C++/Python。IVF、HNSW、IVF-PQ、GPU FAISS。Meta内部 + 学術界のデフォルト。

- **ScaNN**(Google): TensorFlow親和。非対称量子化。精度/速度比が優秀。

- **DiskANN**(Microsoft): SSD親和グラフ。pgvectorscale、Milvusが採用。

- **Annoy**(Spotify): 乱択射影。mmap親和。静的インデックス向き。

- **HnswLib**: HNSWアルゴリズム著者によるシンプルなHNSWライブラリ。Chroma、Jina、Weaviateの初期バックエンド。

- **NGT**(Yahoo Japan): グラフベース。日本 / 韓国で採用事例が多い。

ライブラリ直使用例(FAISS):

d = 1024

nb = 100000

xb = np.random.random((nb, d)).astype("float32")

xq = np.random.random((1, d)).astype("float32")

index = faiss.IndexHNSWFlat(d, 32)

index.hnsw.efConstruction = 200

index.add(xb)

index.hnsw.efSearch = 64

D, I = index.search(xq, 10)

print(I, D)

ハイブリッド検索 — BM25 + dense + RRF + リランカが標準になった理由

2024年以降明確になった事実は **dense vector単独では不足**ということだ。キーワード(名前、ID、コード)マッチに弱く、OOD(out-of-domain)クエリで崩れやすい。2026年標準は次の4段パイプラインだ。

1. **BM25検索**(sparse)で top-50〜100。

2. **Dense vector検索**で top-50〜100。

3. **RRF(Reciprocal Rank Fusion)** または重み付き和で候補100〜200を整理。

4. **リランカ**(Cohere Rerank 3.5、Voyage Reranker 2、BGE Reranker v2-m3、Jina Reranker v2)でtop-10。

RRFの式はシンプルだ。

def rrf(rankings: list[list[str]], k: int = 60) -> dict[str, float]:

scores: dict[str, float] = {}

for ranking in rankings:

for rank, doc_id in enumerate(ranking, start=1):

scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)

return scores

リランカはcross-encoder構造でクエリと文書ペアを同時に見る。検索点数比NDCG@10が5〜15%上がるのが普通。Cohere Rerank 3.5は100文書リランキングで約80ms、価格は1,000クエリあたり$2程度。

マルチベクターとColBERT · ColPali — 新しい精度の基準

文書1つを単一ベクターに圧縮すると詳細が失われる。そこで登場したのが **マルチベクター(multi-vector)** アプローチだ。

- **ColBERT v2**(Stanford 2022 → 2024 PLAID最適化): 文書トークンごとのベクターを全保存 + クエリトークンとlate interaction(MaxSim)。dense single-vector比でNDCGが大きく改善。

- **ColPali**(2024): Vision Transformerでページ画像をパッチベクターの束に埋め込み。PDF / スライドRAGに革新的。

- **ColQwen2**: ColPaliのQwen2-VLバックボーン版。

問題はストレージだ。トークンごとにベクターを保存するとデータセットが50〜200倍に膨らむ。Qdrant、Vespa、Weaviate、ParadeDBがマルチベクターをネイティブ対応し、Pineconeは2026年Q1にベータ追加。

フィルタ検索 — pre-filter vs post-filter、そしてメタデータインデックス

ベクター検索はほぼ常にメタデータフィルタと一緒に使う(「tenant_id = X AND lang = ja」)。

- **Post-filter**: ANN検索後にフィルタ。候補不足のリスク。

- **Pre-filter**: フィルタを先に適用してからANN。Qdrant / Weaviate / Milvus / pgvectorが得意。

- **インデックス付きフィルタ**: メタデータ自体にインデックスを作り結合検索。

Pinecone、Weaviate、Qdrant、Milvus、Elasticsearchはメタデータインデックスを自前で作る。pgvectorはPostgresのB-tree / GINインデックス依存。マルチテナンシが大きいワークロードならpre-filter性能を常にベンチマークすべき。

Embeddingモデル選択 — OpenAI vs Cohere vs Voyage vs BGE vs E5 vs Jina

ベクターDBをいくら選んでもembeddingが悪ければ検索品質は崩れる。2026年5月のMTEBリーダーボード上位は次の通り。

- **OpenAI text-embedding-3-large**(3072d、matryoshka 256 / 1024 / 3072)。バランスが良い。

- **Cohere Embed v4**(1024d、マルチモーダル、多言語、matryoshka)。

- **Voyage 3 / Voyage 3-large**(1024d、ドメイン特化 + 一般が優秀)。

- **BGE-M3**(1024d、dense + sparse + ColBERTを同時出力、OSS)。

- **E5-Mistral-7B-instruct**(4096d、OSS)。

- **gte-Qwen2-7B-instruct**(3584d、OSS)。

- **Jina Embeddings v3**(1024d、多言語、late chunking対応)。

選択基準は(1)多言語が必要か、(2)matryoshkaで次元削減が必要か、(3)セルフホストが必要か、(4)コスト上限はどこか。韓国語 / 日本語環境ではBGE-M3、Cohere v4、Jina v3、multilingual-e5-largeが安全な選択。

RAG固有パターン — chunking · contextual retrieval · parent-child

ベクターDBの上にRAGを乗せるとき2026年標準のパターン:

- **Chunking**: トークン300〜800 + 50トークンオーバーラップが最も一般的。意味ベース分割(semantic chunking)も人気。

- **Contextual retrieval**(Anthropic 2024発表): チャンクごとに「このチャンクはどの文書のどこか」をLLMに短く書かせてembedding前にprepend。検索失敗率を半分近く削減。

- **Parent-child**: 小さなチャンクで検索し、親チャンク / 文書をLLMに渡す。

- **Query expansion**: HyDE(仮想応答を生成してembedding)、multi-query、query rewriting。

- **Reranking**: top-100 → top-10のcross-encoderリランキングはほぼすべてのRAGで推奨。

これらはDBに依存しないが、マルチベクター / sparse対応の有無がどのパターンを楽に使えるか決める。

GPUベクターインデックス — RAFT · cuVS · NVIDIA加速

NVIDIA RAPIDSの **cuVS**(RAFTの後継)が2025年にGAし、GPUベクターインデックスが本格化した。

- **CAGRA**: GPU向けグラフANN。HNSW比でビルドが10倍以上速く、クエリもGPUで5〜50倍速い。

- **GPU IVF-PQ**: 十億ベクターのインデックス構築を時間単位から分単位に短縮。

- **Milvus** GPU CAGRA、**FAISS** GPUモジュール、**RAPIDS cuVS**が採用。Pinecone、Weaviate、QdrantはコアエンジンとしてはGPUを使わない(クエリ時はCPUが主流)。

学習ではなく検索段階でもGPUが意味を持つ転換点が2025〜2026年だ。ただしコスト構造上、単一ノード1億ベクター未満ではCPU + HNSWが依然優位。

コスト経済学 — Pinecone vs Weaviate Cloud vs セルフホストQdrant

おおよその月額比較(2026年5月、1億ベクター1024d、p50 50ms目標):

- **Pinecone Serverless**: 約$2,500〜$4,000(ストレージ + 平均トラフィック)。

- **Weaviate Cloud Serverless**: 約$2,000〜$3,500。

- **Zilliz Cloud(Milvus)**: 約$1,500〜$3,000。

- **Qdrant Cloud**: 約$1,200〜$2,500。

- **Turbopuffer**: 約$300〜$800(コールドワークロード)。

- **セルフホストQdrant on K8s**(EKS、4 x r6i.2xlarge): インフラ約$1,200 + 運用人件費。

- **セルフホストpgvector**(Aurora Serverless v2): 約$700〜$1,500。

価格はトラフィック形状で4〜10倍ぶれる。コールドRAGならTurbopuffer / pgvectorが優位、常時ホットならセルフホストQdrantが最安になりがち。

韓国の採用事例 — Naver、Kakao、Toss、Karrot

韓国IT市場の2026年5月のベクターDB状況。

- **Naver Clova**: 独自HyperCLOVA X RAGインフラ。Milvus亜種 + 自社embeddingと推定。

- **Kakao Brain**: pgvector + 自社embeddingモデルでKoGPT応用RAG。

- **Toss**: 検索チームがVespaベースのマルチステージランキングを構築。ベクターは社内インデックス。

- **Karrot(당근)**: マーケットプレイス推薦にFAISS + 自社embedding。Qdrant適用事例も発表。

- **Samsung SDS、LG CNS**: 社内RAGにPineconeまたはWeaviateマネージドの利用事例。

- **韓国スタートアップ(チャットボット / 検索)**: Qdrant、Weaviate、pgvectorが最も一般的。

韓国語embeddingはBGE-M3、Cohere Embed v4、multilingual-e5-largeが事実上の標準候補。韓国語特化モデル(KoSimCSE等)はドメインが狭いときに強み。

日本の採用事例 — Vald(LY)、NGT(Yahoo)、メルカリ、LINE検索

- **Yahoo Japan / LYコーポレーション**: NGTライブラリの開発、Vald分散ベクターDBをOSS化。LINE検索 / 推薦で使用。

- **メルカリ**: セマンティック検索にElasticsearch + 自社embedding、一部ワークロードはVespa。

- **CyberAgent**: 広告推薦にFAISSベース自社システム。

- **楽天**: 商品検索でSolr / Elastic + 自社embeddingを結合。

- **Preferred Networks**: 社内RAGでQdrant導入事例を発表。

NGTは韓国でも知られるライブラリだが、Valdクラスタを直接運用する事例は日本国内でもLY / Naverレベルに限られる。メルカリのVespa採用は検索コミュニティで頻繁に引用される。

意思決定ガイド — ワークロード別の推奨

最後にワークロード別の推奨を単純化する。

- **ノートブック / 単一ノードRAGプロト**: Chroma、LanceDB、DuckDB VSS、sqlite-vec

- **モノリシックSaaS、1億ベクター未満、Postgres運用中**: pgvector + pgvectorscale(+ ParadeDB)

- **K8sセルフホスト、1億〜10億ベクター**: Qdrant、Weaviate、Milvus

- **運用負荷最小化のマネージド**: Pinecone Serverless、Qdrant Cloud、Zilliz Cloud、Weaviate Cloud

- **10億ベクター超、GPUインデックス必須**: Milvus GPU(CAGRA)、Vespa、自社FAISSインフラ

- **コールドワークロード、価格最適化**: Turbopuffer、pgvector、LanceDB on S3

- **検索クラスタがすでにある**: Elasticsearch dense_vector、OpenSearch k-NN、Vespa

- **OLTP DB内で完結させる**: MongoDB Atlas Vector、Redis Vector、Couchbase、SingleStore

- **組み込み / モバイル**: sqlite-vec、LanceDB embedded

- **ハイブリッド検索 + リランキングを1級サポート**: Qdrant、Weaviate、Vespa、Milvus、ParadeDB

- **マルチベクター(ColBERT / ColPali)1級サポート**: Qdrant、Vespa、Weaviate、ParadeDB

「デフォルトを決めて例外だけ動かす」原則を適用すると、2026年5月時点で新規RAGのデフォルトは **(A) Postgres + pgvector + pgvectorscale** または **(B) Qdrantマネージド** が最も安全。

References

- [Pinecone](https://www.pinecone.io/) — Serverless v3 マネージドベクターDB

- [Weaviate](https://weaviate.io/) — モジュール + ハイブリッド + 生成検索

- [Qdrant](https://qdrant.tech/) — Rustベース OSSベクターDB

- [Milvus](https://milvus.io/) — 大規模分散ベクターDB

- [Zilliz Cloud](https://zilliz.com/cloud) — Milvusマネージド

- [Chroma](https://www.trychroma.com/) — 組み込みベクターDB

- [LanceDB](https://lancedb.com/) — Arrowベースのマルチモーダルベクターストア

- [pgvector](https://github.com/pgvector/pgvector) — Postgresベクター拡張

- [pgvectorscale](https://github.com/timescale/pgvectorscale) — StreamingDiskANN

- [ParadeDB](https://www.paradedb.com/) — Postgres BM25 + ベクター

- [Vespa](https://vespa.ai/) — Yahoo検索エンジン

- [OpenSearch k-NN](https://opensearch.org/docs/latest/search-plugins/knn/) — k-NNプラグイン

- [Elasticsearch dense_vector](https://www.elastic.co/guide/en/elasticsearch/reference/current/dense-vector.html) — ベクター検索

- [Redis Vector Search](https://redis.io/docs/latest/develop/interact/search-and-query/advanced-concepts/vectors/) — インメモリベクター検索

- [MongoDB Atlas Vector Search](https://www.mongodb.com/products/platform/atlas-vector-search) — Atlasベクター検索

- [Turbopuffer](https://turbopuffer.com/) — S3上のサーバレスベクターDB

- [Marqo](https://www.marqo.ai/) — embedding + 検索

- [Vald](https://vald.vdaas.org/) — Yahoo Japan分散ベクターDB

- [NGT](https://github.com/yahoojapan/NGT) — Yahoo Japanグラフ ANN

- [FAISS](https://github.com/facebookresearch/faiss) — Metaベクターライブラリ

- [DiskANN](https://github.com/microsoft/DiskANN) — Microsoft SSDグラフインデックス

- [ScaNN](https://github.com/google-research/google-research/tree/master/scann) — Google ANN

- [Annoy](https://github.com/spotify/annoy) — Spotify静的 ANN

- [HnswLib](https://github.com/nmslib/hnswlib) — HNSW参照実装

- [Cohere Rerank](https://cohere.com/rerank) — Rerank 3.5

- [Voyage Reranker](https://docs.voyageai.com/docs/reranker) — Voyage Reranker 2

- [MTEB Leaderboard](https://huggingface.co/spaces/mteb/leaderboard) — embeddingベンチマーク

- [ann-benchmarks](https://ann-benchmarks.com/) — ANNアルゴリズムベンチマーク

- [ColBERT](https://github.com/stanford-futuredata/ColBERT) — late interaction

- [ColPali](https://github.com/illuin-tech/colpali) — ビジョンマルチベクター

- [Anthropic Contextual Retrieval](https://www.anthropic.com/news/contextual-retrieval) — チャンク文脈化