ベクトル DB は、文章や画像を数値の並び（埋め込みベクトル）に変えて保存し、「意味が近いもの」を高速に探すための専用データベースです。RAG（検索拡張生成）や推薦・類似検索の土台になります。本記事は Pinecone / Weaviate / pgvector / Qdrant を軸に、規模・既存スタック・検索方式・コストの 4 観点で「自分の場合どれを選ぶか」を、図とともに具体的に整理します。
FIG.1 文書を埋め込みに変換して索引化し、問い合わせベクトルと「意味が近い」上位を返す
01ベクトル DB が解く問題
普通のデータベースは「完全一致」や「範囲」で探すのが得意です。一方、AI の埋め込みは数百〜数千次元の数値ベクトルで、「意味の近さ」を距離（コサイン類似度や内積など）で測ります。全件と総当たりで距離計算すると遅すぎるため、ベクトル DB は HNSW（グラフ型）や IVF（クラスタ分割）といった索引で近似最近傍探索（ANN）を行い、精度を少し譲る代わりに大幅に高速化します。
「近似」である点が重要です。ANN は必ずしも厳密な正解上位を返すとは限らず、どれだけ取りこぼさないかを示す Recall と速度（QPS・レイテンシ）はトレードオフの関係にあります。索引のパラメータ調整は、この両者のバランス取りそのものです。
024 つの主役と、その立ち位置
選択肢は多いものの、出発点としては次の 4 つを押さえれば十分です。フルマネージドで素早く始めたいか、既存の PostgreSQL に乗せたいか、大規模・低レイテンシを最優先するか——立ち位置が異なります。
| 製品 | 立ち位置と向いている人 |
|---|---|
| Pinecone | フルマネージド・サーバーレス型。インフラを持たず使った分だけ課金。運用を任せて素早く本番化したい場合。 |
| Weaviate | OSS＋マネージドクラウド。キーワード＋ベクトルのハイブリッド検索が 1 クエリで完結。検索体験を作り込みたい場合。 |
| pgvector | PostgreSQL 拡張。既存の DB にテーブル 1 つでベクトル検索を足せる。最小コスト・最小構成で始めたい場合。 |
| Qdrant | Rust 製 OSS。フィルタ付き検索とレイテンシに強い。pgvector で頭打ちになり「次」へ移る定番の移行先。 |
このほか、超大規模向けの Milvus / Zilliz Cloud、軽量で開発用の Chroma や LanceDB、既存検索基盤に足す Elasticsearch / OpenSearch も実務でよく登場します。ただし最初の選定は上記 4 つの軸で考えると迷いません。
03規模で見る現実的なライン
「何件のベクトルを扱うか」で適材は変わります。次は 2026 年時点の感覚的な目安です（埋め込みは 1,536 次元 float を想定。実際は次元数・フィルタ要件・予算で前後します）。
〜10 万件
プロトタイプ帯。Chroma / LanceDB やローカル実装で十分。まず動かして検証する段階。
100 万〜1 億件
本番の主戦場。pgvector・Pinecone・Weaviate・Qdrant がいずれも実用域。要件で選ぶ。
10 億件超
分散前提。Milvus / Zilliz や Pinecone のエンタープライズ構成、Qdrant の分散運用が候補。
注意したいのは、1 万件規模では「専用 DB だから速い」という差はほとんど出ないことです。むしろ 100 万件までなら、HNSW 索引を張った pgvector が専用 DB に匹敵する応答（実運用で数 ms〜十数 ms 程度）を出す報告が増えています。差が効いてくるのは、件数が増え、かつフィルタ付き検索を高い QPS で回し始めてからです。
04選定の決め手は「既存スタック × 検索方式」
規模が同じ帯なら、最後はこの 2 つで決まります。すでに何を運用しているか、そして検索に何を求めるか、です。
既存に PostgreSQL がある
まず pgvector を検討。新しいインフラを増やさず、トランザクションやメタデータ管理を同じ DB で完結できる。コストも運用も最小。
運用を持ちたくない / 立ち上げ最優先
Pinecone のサーバーレス。サーバー管理ゼロで、使った分だけ課金。素早く本番に乗せたいチームに向く。
キーワードと意味の両方で当てたい
Weaviate。BM25（キーワード）とベクトルを 1 クエリで混ぜるハイブリッド検索が組み込み。型番や固有名詞が効く業務に強い。
大量データを低レイテンシで、フィルタ多用
Qdrant。フィルタ用の索引が ANN 探索と統合され、絞り込みつき検索が大規模でも速い。読み取り中心で遅延に厳しい用途の定番。
05ハイブリッド検索が事実上の標準に
純粋なベクトル検索は「言い換え・表記ゆれ」に強い一方、型番・条文番号・固有名詞のような「文字どおり一致してほしい」情報には弱い。そこでキーワード検索（BM25 など）と組み合わせるハイブリッド検索が、2026 年では既定の選択になりつつあります。
| ベクトル検索（密） | キーワード検索（疎・BM25） |
|---|---|
| 言い換え・類義語・表記ゆれに強い | 型番・条文番号など完全一致が重要な語に強い |
| 意味の近さで広く拾う | 該当語を確実に取りこぼさない |
| 固有名詞の細かな違いを見落としがち | 意味は同じだが語が違う文を拾えない |
さらに、広く拾った候補を関連度で並べ直す Reranker（Cohere Rerank、Voyage rerank など）を最終段に挟むと精度が安定します。「広く取って、厳しく絞る」という二段構えです。
FIG.2 密（ベクトル）＋疎（キーワード）で広く拾い、再ランキングで上位だけを残す
06メタデータフィルタと「索引の効き方」
実務では「カテゴリ＝技術書」「公開日 ＞ 2024-01-01」「部署＝経理」のような条件で絞ってから意味検索したい場面が多い。問題は、フィルタとベクトル検索を素朴に組み合わせると、絞り込みで候補が激減し、HNSW グラフをうまく辿れず精度や速度が落ちることです。
製品ごとに対処が異なります。Qdrant はフィルタ対象フィールド専用の索引を持ち、ANN 探索と統合して「絞り込みつき検索」を大規模でも速く保ちます。pgvector は 0.8 で導入された反復インデックススキャン（iterative scan）により、フィルタで結果が足りないとき索引を追加で辿って件数を満たせるようになり、フィルタ併用時の取りこぼしが改善しました。フィルタ要件が重い設計ほど、この「フィルタ × ANN の統合度」が選定の分かれ目になります。
pgvector in 2026
「PostgreSQL だけで足りる」範囲が広がった
pgvector は 0.8 系（最新は 0.8.1、2025 年）で実用性が一段上がりました。覚えておきたい 3 点を線画で。halfvec（16 ビット float）で索引可能な次元上限が拡張され記憶域がほぼ半減、バイナリ量子化で各次元を 0/1 に圧縮して大量ベクトルを軽量化、反復インデックススキャンでフィルタ併用時の Recall を底上げ——既存 PostgreSQL の延長で、かなりの規模まで戦えます。
FIG.3 pgvector 0.8 系の三機能：軽量化（halfvec / 量子化）とフィルタ時の取りこぼし対策
もちろん万能ではありません。極端な大規模・超高 QPS・複雑な分散運用が要るなら、Qdrant や Milvus など専用 DB の出番です。「まず pgvector、頭打ちで専用 DB へ」が現実的な進め方になっています。
07コストは「料金表の額」より「課金モデル」を見る
料金は頻繁に変わるため、具体額は必ず各社の公式料金で確認してください。ここで押さえたいのは金額そのものより、課金モデルの型の違いです。型が分かれば、自分のワークロードでどこが効いてくるかを見積もれます。
| 製品 / 形態 | 課金モデルの型（要点） |
|---|---|
| Pinecone（サーバーレス） | 読み書き量＋記憶域の従量。無料枠あり。エージェント常時稼働など読み書きが多いと積み上がりやすい。 |
| pgvector（セルフホスト） | 追加ライセンス費なし。実質は PostgreSQL の運用費（マネージド PG なら そのインスタンス代）。 |
| Qdrant Cloud | 確保したリソース（メモリ・ディスク時間）課金。無料の小規模クラスタあり。常時稼働で見積もりやすい。 |
| Weaviate Cloud | 保存次元量ベースの従量／プラン制。無料サンドボックスあり。 |
| Zilliz Cloud（Milvus） | 計算（CU 時間）＋記憶域。無料枠あり。超大規模・分散向け。 |
コスト比較の落とし穴は、「保存料」だけ見て「読み書き料」を見落とすこと。
とくにサーバーレス従量型は、保存よりクエリ・書き込みの量が請求を左右します。RAG をエージェントで常時叩く設計だと、見積もりが実費を下回りやすい。逆に、トラフィックが読みやすく常時稼働する用途なら、確保リソース課金（Qdrant Cloud など）やセルフホスト（pgvector）のほうが予測しやすいことが多いです。本番投入前に、想定 QPS・書き込み頻度・保存量で必ず実額を試算しましょう。
08最小構成のコード例
イメージをつかむために、両極の最小例を挙げます。まず既存 PostgreSQL に乗せる pgvector。テーブル 1 つと索引 1 つで始められます。
CREATE EXTENSION vector;
CREATE TABLE docs (
id BIGSERIAL PRIMARY KEY,
content TEXT,
embedding VECTOR(1536)
);
-- HNSW 索引（コサイン距離）
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);
-- 意味が近い上位 10 件
SELECT id, content FROM docs
ORDER BY embedding <=> '[0.1,0.2, ...]'::vector
LIMIT 10;次にフルマネージドの Pinecone。サーバーを持たず、登録（upsert）と検索（query）だけで動きます。
from pinecone import Pinecone
pc = Pinecone(api_key="...")
index = pc.Index("docs")
# 登録：id・ベクトル・メタデータ
index.upsert([(doc_id, vector, {"dept": "sales"})])
# メタデータで絞って意味検索
results = index.query(
vector=query_vec, top_k=10,
filter={"dept": "sales"}, include_metadata=True,
)09運用で効く勘どころ
- 埋め込みモデルを変えたら全再生成：別モデルのベクトルは互いに比較できない。モデル更新＝全件作り直しが前提。
- チャンク戦略を先に決める：分割が後から変わると埋め込みもやり直し。見出し・条項単位で 300〜800 トークン程度を起点に。
- メタデータに出典 URL・更新日・権限を必ず付与：フィルタ・引用・アクセス制御の土台になる。後付けは高くつく。
- Recall を定期測定：ANN は厳密でないため、索引パラメータやデータ増加で精度がドリフトする。評価用 Q&A セットで監視する。
- 権限フィルタは検索段で：「見えてはいけない文書」を根拠にしないよう、ユーザー権限で対象を絞ってから検索する。
102026 年の流れ
- ハイブリッド検索の標準化：密（ベクトル）＋疎（キーワード）併用が既定に。
- Reranker 併用の一般化：Cohere / Voyage などで最終段の精度を底上げ。
- マルチモーダル埋め込み：テキスト・画像・音声を同じ空間で横断検索。
- 量子化・軽量化の普及：バイナリ量子化や halfvec で記憶域とコストを圧縮。
- 「pgvector から専用 DB へ」の経路化：小さく始めて、規模・フィルタ要件で Qdrant 等へ移る型が定着。
11まとめ
ベクトル DB 選びは「規模 × 既存スタック × 検索方式 × 課金モデル」で決めるのが基本です。プロトタイプは Chroma / LanceDB、既存 PostgreSQL があるなら pgvector、運用を任せたいなら Pinecone、ハイブリッド検索なら Weaviate、低レイテンシ・大規模フィルタなら Qdrant、超大規模なら Milvus / Zilliz——という対応づけが 2026 年の実用解です。料金は変動するので公式で実額試算を。そして、どの DB を選んでも ハイブリッド検索＋Reranker＋評価セットを組むことが、精度を底上げする最短ルートになります。
