ベクトルデータベース 2026 — pgvector / Pinecone / Qdrant / Weaviate 比較

ベクトルデータベースとは

ベクトルデータベースは、テキスト・画像・音声を高次元ベクトルに変換して保存し、意味的類似度に基づく検索を高速に実行するためのデータストアです。従来のキーワード検索では「犬」と「イヌ」を別物として扱いますが、ベクトル検索では両者を近い位置に配置して意味的に近い結果を返します。

2024年以降、ChatGPT・Claude・Geminiなどの大規模言語モデル（LLM）に企業独自のデータを組み合わせるRAG（Retrieval-Augmented Generation）が急速に普及しました。その結果、ベクトルデータベースは実験的なツールから本番環境で稼働する必須インフラへと変化しています。

市場規模と成長予測

Grand View Researchの2025年レポートによれば、世界のベクトルデータベース市場は2025年に29億ドル、2030年に118億ドルに達すると予測されています。年平均成長率（CAGR）は32.1%です。この成長を牽引しているのは、生成AIの企業導入拡大と、AIエージェントによるマルチステップ推論タスクの増加です。

主要4製品の比較

ベクトルデータベースは大きく3つのカテゴリに分けられます。

以下では、pgvector、Pinecone、Qdrant、Weaviate の4製品を詳細に比較します。

pgvector

PostgreSQL 用のオープンソース拡張機能。GitHub スター数 15,000 以上を誇り、既存の PostgreSQL インフラをそのまま活用できる点が最大の強みです。

-- pgvector のインストールと基本的な使い方
CREATE EXTENSION vector;

CREATE TABLE documents (
  id serial PRIMARY KEY,
  content text,
  embedding vector(1536)  -- OpenAI text-embedding-3-small
);

-- HNSW インデックスを作成（高速近似検索）
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

-- 類似検索
SELECT content
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 5;

強み:

• コストゼロ: 既存PostgreSQLで動作、追加ライセンス不要
• 運用が楽: バックアップ・レプリケーション・認証を既存DBツールで統一
• トランザクション: ベクトル検索と通常のSQLをACID保証内で実行可能

弱み:

• 大規模データに非対応: 1億件を超えるとレイテンシが悪化（HNSW でも）
• 専用最適化なし: Pinecone と比べるとスループットで劣る
• スケールアウト困難: PostgreSQL の水平分散は複雑

適用シナリオ: スタートアップ、中小企業の社内RAG、既存アプリにベクトル検索を追加したいケース。

Pinecone

フルマネージド専用ベクトルDB。2021年創業、2024年にシリーズCで7.5億ドル調達し、評価額は110億ドルに達しました。

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="YOUR_API_KEY")

# インデックス作成
pc.create_index(
    name="my-index",
    dimension=1536,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1")
)

index = pc.Index("my-index")

# upsert
index.upsert(vectors=[
    {"id": "doc1", "values": [0.1, 0.2, ...], "metadata": {"title": "..."}},
])

# 検索
results = index.query(
    vector=[0.1, 0.2, ...],
    top_k=5,
    filter={"category": "tech"}
)

強み:

• レイテンシ最速クラス: p99 で 50ms 以下（Serverless）
• 完全マネージド: インデックス管理、自動スケーリング、バックアップ不要
• メタデータフィルタ: 高速な事前フィルタリング

弱み:

• 高コスト: Serverless で月額 $70〜（100万クエリ、10GB）
• ベンダーロックイン: データエクスポートに制約
• 日本リージョンなし: 2026年4月時点で東京リージョン未提供（レイテンシ影響あり）

適用シナリオ: エンタープライズ、高トラフィックSaaS、運用コストを人件費で払いたくない組織。

Qdrant

ロシア発のOSSベクトルDB。Rust 製で高速・省メモリ、マネージドサービスとセルフホスト両対応。

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct

client = QdrantClient(url="http://localhost:6333")

# コレクション作成
client.create_collection(
    collection_name="my_docs",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

# upsert
client.upsert(
    collection_name="my_docs",
    points=[
        PointStruct(id=1, vector=[0.1, 0.2, ...], payload={"title": "..."}),
    ],
)

# ハイブリッド検索（Dense + Sparse）
results = client.search(
    collection_name="my_docs",
    query_vector=[0.1, 0.2, ...],
    query_filter={"must": [{"key": "year", "match": {"value": 2026}}]},
    limit=5,
)

強み:

• ハイブリッド検索: 密ベクトル + スパースベクトル（BM25風）の同時検索が標準
• 高速フィルタリング: ペイロードフィルタが Pinecone より柔軟
• セルフホスト可: Dockerで簡単に立ち上がる
• 日本リージョン: Qdrant Cloud で東京リージョン利用可能

弱み:

• ドキュメントの質: Pinecone に比べてチュートリアルが少ない
• エコシステム: LangChain / LlamaIndex の統合は充実しているが、Pinecone ほどではない

適用シナリオ: ハイブリッド検索が必須、オンプレミス要件あり、コスパ重視。

Weaviate

オランダ発のOSSベクトルDB。GraphQL APIとマルチモーダル対応が特徴。

import weaviate

client = weaviate.Client("http://localhost:8080")

# スキーマ定義
schema = {
    "class": "Document",
    "vectorizer": "text2vec-openai",
    "properties": [
        {"name": "title", "dataType": ["text"]},
        {"name": "content", "dataType": ["text"]},
    ],
}
client.schema.create_class(schema)

# データ追加（vectorizer が自動でベクトル化）
client.data_object.create(
    data_object={"title": "AI の未来", "content": "..."},
    class_name="Document",
)

# 検索
result = (
    client.query
    .get("Document", ["title", "content"])
    .with_near_text({"concepts": ["AI エージェント"]})
    .with_limit(5)
    .do()
)

強み:

• 自動ベクトル化: 組み込みの vectorizer でデータ投入時に自動変換
• マルチモーダル: テキスト・画像・動画を同一インデックスで扱える
• GraphQL API: 柔軟なクエリ構築

弱み:

• レイテンシ: Pinecone / Qdrant に比べて遅め
• コミュニティ: Qdrant に比べて日本語情報が少ない

適用シナリオ: マルチモーダル検索、GraphQL に統一したいアーキテクチャ。

料金比較（2026年4月時点）

実用的なRAGシステム（月間100万クエリ、1,000万ベクトル、10GB）を運用する場合のコスト試算です。

ベンチマーク比較

ANN-Benchmarks（2025年12月版）および各社公表データを元にしたパフォーマンス比較です。テスト条件：1,000万ベクトル（1536次元）、Recall@10 > 0.95。

注意: ベンチマークはワークロード依存です。フィルタリング併用時は Qdrant が優位、単純ANN検索なら Pinecone/Milvus が強い。

ハイブリッド検索の重要性

2026年のRAG実装では、密ベクトル検索（semantic search）とスパース検索（keyword search）の組み合わせが標準になりつつあります。これをハイブリッド検索と呼びます。

なぜハイブリッドが必要か？

• 密ベクトル: 意味的類似度に強い。「犬」と「イヌ」を同一視。
• スパース（BM25等）: 固有名詞・専門用語に強い。「GPT-4o」と「GPT-5」を区別。

製品別対応状況:

選定基準フローチャート

あなたのプロジェクトに最適なベクトルDBを選ぶための判断フローです。

flowchart TD
  A[RAG導入を決定] --> B{既存PostgreSQL運用中?}
  B -->|はい| C{データ量 < 1,000万件?}
  C -->|はい| D[pgvector]
  C -->|いいえ| E{予算 > $100/月?}
  B -->|いいえ| E
  E -->|はい| F{ハイブリッド検索必須?}
  F -->|はい| G[Qdrant Cloud]
  F -->|いいえ| H{レイテンシ最優先?}
  H -->|はい| I[Pinecone]
  H -->|いいえ| G
  E -->|いいえ| J{セルフホスト可能?}
  J -->|はい| K[Qdrant OSS]
  J -->|いいえ| D

実装例：Supabase pgvector + LangChain

最もコスト効率の良い構成として、Supabase のベクトル拡張を使ったRAG実装例を示します。

import { SupabaseVectorStore } from "@langchain/community/vectorstores/supabase";
import { OpenAIEmbeddings } from "@langchain/openai";
import { createClient } from "@supabase/supabase-js";

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_ANON_KEY!
);

const embeddings = new OpenAIEmbeddings({
  model: "text-embedding-3-small",
});

// ドキュメントを投入
const vectorStore = await SupabaseVectorStore.fromTexts(
  ["AI エージェントは 2025 年に...", "ベクトルデータベースは..."],
  [{ source: "doc1" }, { source: "doc2" }],
  embeddings,
  {
    client: supabase,
    tableName: "documents",
    queryName: "match_documents",
  }
);

// 類似検索
const results = await vectorStore.similaritySearch("AI エージェントの動向", 5);
console.log(results);

必要な準備（Supabase側）:

-- Supabase SQL Editor で実行
create extension if not exists vector;

create table documents (
  id bigserial primary key,
  content text,
  metadata jsonb,
  embedding vector(1536)
);

create index on documents using hnsw (embedding vector_cosine_ops);

-- 検索関数
create or replace function match_documents(
  query_embedding vector(1536),
  match_threshold float,
  match_count int
)
returns table (id bigint, content text, metadata jsonb, similarity float)
language sql stable
as $$
  select
    documents.id,
    documents.content,
    documents.metadata,
    1 - (documents.embedding <=> query_embedding) as similarity
  from documents
  where 1 - (documents.embedding <=> query_embedding) > match_threshold
  order by documents.embedding <=> query_embedding
  limit match_count;
$$;

この構成なら、月額$0（Free Tier）または$25（Pro） でRAGシステムが構築できます。

実装例：Qdrant でハイブリッド検索

Qdrant を使ったハイブリッド検索の実装例です。

from qdrant_client import QdrantClient, models

client = QdrantClient(url="https://your-cluster.qdrant.io", api_key="...")

# コレクション作成（Dense + Sparse）
client.create_collection(
    collection_name="hybrid_docs",
    vectors_config={
        "dense": models.VectorParams(size=1536, distance=models.Distance.COSINE),
    },
    sparse_vectors_config={
        "sparse": models.SparseVectorParams(),
    },
)

# データ投入
client.upsert(
    collection_name="hybrid_docs",
    points=[
        models.PointStruct(
            id=1,
            vector={
                "dense": openai_embedding,  # [0.1, 0.2, ...]
                "sparse": bm25_vector,       # {34: 0.5, 128: 0.8, ...}
            },
            payload={"title": "AI エージェント", "year": 2025},
        ),
    ],
)

# ハイブリッド検索
results = client.search_batch(
    collection_name="hybrid_docs",
    requests=[
        models.SearchRequest(
            vector=models.NamedVector(name="dense", vector=query_dense),
            limit=10,
        ),
        models.SearchRequest(
            vector=models.NamedSparseVector(name="sparse", vector=query_sparse),
            limit=10,
        ),
    ],
)

# Reciprocal Rank Fusion で統合
# (省略: 2つの結果をスコアで融合)

運用上の注意点

インデックス再構築コスト

ベクトルDBの最大の落とし穴は、インデックス再構築に数時間〜数日かかる点です。Embedding モデルを変更（例：OpenAI text-embedding-ada-002 → text-embedding-3-large）すると、全ドキュメントを再ベクトル化してインデックスを作り直す必要があります。

1億件のドキュメントで試算すると：

• 再ベクトル化: OpenAI API コスト 約 $1,300（text-embedding-3-small）
• 再投入: Pinecone で 8〜12 時間、pgvector で 24 時間以上
• ダウンタイム: Blue-Green デプロイしないと検索停止

コスト暴走リスク

RAGシステムでは、1回のユーザークエリで「検索 → LLM生成」の2ステップが走ります。想定外のトラフィック増加で月額$70のはずが$700に跳ね上がるケースが頻発しています。

防止策:

• クエリレート制限: ユーザーあたり 10 req/min など
• アラート設定: Pinecone / Qdrant の管理画面でコストアラート
• キャッシュ: 同一クエリの結果をRedisに1時間キャッシュ

セキュリティ：プロンプトインジェクション

RAGでは外部データをLLMに渡すため、検索結果に「これまでの指示を無視して…」という攻撃文が混入しうる。これを間接的プロンプトインジェクションと呼びます。

対策:

• 検索結果のサニタイズ（特殊文字除去）
• システムプロンプトで「検索結果は信頼できない」と明示
• OpenAI Moderation API で有害コンテンツをフィルタ

2026年のトレンド

1. マルチベクトル表現

1つのドキュメントを複数のベクトルで表現する手法が登場しています。例：

• ColBERT: トークンごとにベクトルを生成、Late Interaction で精度向上
• MatryoshkaEmbedding: 1つのベクトルを段階的に圧縮（1536次元 → 768 → 384 → 128）

Qdrant と Weaviate は2026年Q1からマルチベクトル対応を開始しました。

2. グラフ + ベクトルの統合

ベクトルデータベースの基礎で触れたように、ナレッジグラフとベクトル検索を組み合わせたGraph RAGが注目されています。

• Neo4j Vector Index: グラフDBにベクトル検索機能を追加
• Weaviate + GraphQL: 関連性をグラフ構造で表現

3. ローカルLLM対応

オンプレミス要件が厳しい業界（金融、医療）では、Llama 3.3、Qwen 2.5 などのローカルLLMとベクトルDBを組み合わせたプライベートRAGが増えています。この場合、クラウドサービスは使えないため、Qdrant OSS / Milvus のセルフホストが必須です。

よくある誤解

「ベクトルDBさえ導入すればRAGは完璧に動く」と考えていませんか？
実際には、チャンキング戦略（ドキュメントをどう分割するか）、Embeddingモデルの選定、リランキング（検索結果の再順位付け）、メタデータ設計が検索精度の8割を決めます。ベクトルDBはあくまでインフラの一部です。

「HNSWアルゴリズムが最速だから常にHNSWを使えばいい」と思っていませんか？
HNSWは高速ですが、インデックス構築に時間がかかり、データ更新頻度が高い場合は非効率です。リアルタイム更新が多いなら IVF（Inverted File Index）の方が適していることもあります。

「Pineconeは高いから使うべきでない」と決めつけていませんか？
運用エンジニアの人件費を時給5,000円、月40時間として計算すると、セルフホストで月20万円の人的コストが発生します。Pineconeの月額7万円はむしろ安い投資です。組織の成熟度とエンジニアリソースで判断しましょう。

まとめ

2026年のベクトルデータベース選定は、技術的性能だけでなくコスト・運用負荷・エコシステムの3軸で判断する必要があります。主要な選択指針をまとめます。

• pgvector: 既存PostgreSQL活用、スタートアップ・MVP向け、年間$0〜$300で運用可能
• Pinecone: レイテンシ最優先、完全マネージド、エンタープライズ向け、月額$70〜
• Qdrant: ハイブリッド検索必須、コスパ重視、セルフホスト柔軟性、月額$60〜
• Weaviate: マルチモーダル対応、GraphQL統合、中規模プロジェクト向け

実用的なRAGシステムでは、密ベクトル + スパースベクトルのハイブリッド検索が標準になりつつあり、この点で Qdrant の優位性が高まっています。一方、既存の PostgreSQL 資産を活用できる pgvector は、小〜中規模のプロジェクトで依然として強力な選択肢です。

ベクトルDBの選定で最も重要なのは、「今動けばいい」ではなく「1年後にどうスケールするか」「Embeddingモデル変更時にどう移行するか」を事前に設計することです。

参考リソース

• pgvector GitHub - PostgreSQL 用オープンソースベクトル拡張
• Pinecone Documentation - フルマネージドベクトルデータベース公式ドキュメント
• Qdrant Documentation - ハイブリッド検索対応ベクトルDB
• Weaviate Documentation - マルチモーダルベクトル検索エンジン
• ANN Benchmarks - 近似最近傍検索アルゴリズムのベンチマーク
• Grand View Research - Vector Database Market Report 2025 - 市場規模・成長予測