「社内ドキュメントを使ったChatbotを作りたい」「製品マニュアルでカスタマーサポートを支援したい」。生成AI（LLM）の業務利用が広がる中、必ず登場するのがRAG（Retrieval-Augmented Generation、検索拡張生成）です。RAGの中心技術がベクトルDB、つまり「意味の近さで検索できるデータベース」です。
Pinecone・Weaviate・pgvectorの3つが、選択肢の代表格です。商用SaaSの完成度、OSSの自由度、既存DB拡張のシンプルさ、と性格が違います。選定の判断軸と、既存データ基盤との統合を整理します。
RAGとベクトルDBの基本
RAGは「LLMに質問を答えさせる前に、関連する社内ドキュメントを検索して与える」アプローチです。これにより、LLMが知らない社内情報や最新情報を答えられるようになります。
| 段階 | 役割 |
|---|---|
| 1. Embedding | ドキュメントを「ベクトル（数値配列）」に変換 |
| 2. Indexing | ベクトルDBにベクトルを保存 |
| 3. Retrieval | 質問もベクトル化、近いドキュメントを検索 |
| 4. Generation | LLMに「質問＋関連ドキュメント」を渡して回答生成 |
「意味の近さ」を計算するのがベクトルDBの役割で、これが「キーワード一致」検索では実現できない、本質的に異なる機能です。
3つの選択肢の位置づけ
| Pinecone | Weaviate | pgvector | |
|---|---|---|---|
| カテゴリー | 商用SaaS（マネージド） | OSS＋商用SaaS | PostgreSQL拡張 |
| 主な使い方 | API経由で完全マネージド | OSS自社運用 or Cloud | 既存PostgreSQLに足す |
| 強み | 性能・運用しやすさ | 豊富な機能・GraphQL | シンプル・既存DB活用 |
| 学習コスト | 低 | 中 | 低（PostgreSQL経験者） |
| 価格 | 中〜高 | OSS無料、Cloud有料 | PostgreSQLコストのみ |
商用の完成度を取るならPinecone、OSSと自由度ならWeaviate、シンプルさと既存DB活用ならpgvector、という整理です。
それぞれの強みと弱み
Pinecone
ベクトルDBカテゴリーを商用化したパイオニアです。完全マネージドSaaSで、APIを呼ぶだけで使えます。スケーラビリティと性能で評価が高く、エンタープライズ採用が広がっています。詳細はPinecone とはで扱います。
Weaviate
OSSのベクトルDBで、GraphQL API・モジュール式の拡張（embedding生成、リランク、ハイブリッド検索）が特徴です。自社運用とWeaviate Cloudの両方を選べる柔軟性が強みです。詳細はWeaviate とはで扱います。
pgvector
PostgreSQLの拡張モジュールで、既存PostgreSQLにベクトル検索機能を追加します。専用ベクトルDBを別途立てる必要がなく、「PostgreSQLで完結する」シンプルさが魅力です。詳細はpgvector とはで扱います。
選定の判断軸
| 状況 | 選び方 |
|---|---|
| 運用負担を最小化したい | Pinecone |
| OSSで自社運用したい | Weaviate |
| 既存PostgreSQLを活かしたい・データ量が中規模まで | pgvector |
| 大規模（数億ベクトル超） | Pinecone or Weaviate |
| SQL中心のチーム | pgvector |
| GraphQL運用 | Weaviate |
既存データ基盤との統合
| 段階 | 使われる技術 |
|---|---|
| ドキュメント収集 | 取り込みツール（EL vs ETLとデータ取り込みツール選定） |
| 前処理・チャンキング | dbt + Python（dbt実装ガイド） |
| Embedding生成 | OpenAI / Cohere / オープンモデル（HuggingFace） |
| ベクトル保存 | Pinecone / Weaviate / pgvector |
| 検索＋LLM呼び出し | LangChain / LlamaIndex / 独自実装 |
ベクトルDBはRAGのワンピースで、前後の取り込み・前処理・LLM呼び出しと組み合わせて初めて機能する。既存データ基盤の延長として設計するのが現実的だ。
運用上の現実
- チャンキング戦略が品質を左右：ドキュメントをどう分割するかで検索品質が大きく変わる。文書の構造に合わせた分割が必要。
- Embeddingモデルの選択：OpenAI text-embedding-3、Cohere、オープンモデルなど。コスト・品質・データ持ち出し許可で選ぶ。
- Re-rankingの必要性：ベクトル検索だけだと品質が出ない場合、再ランキングモデルを通す。
- 更新・削除の運用：ドキュメントの更新があったとき、ベクトルDBの整合性をどう保つか設計が要る。
まとめ
- ベクトルDBはRAG（検索拡張生成）の中心技術。「意味の近さ」で検索可能。
- Pinecone＝商用マネージド、Weaviate＝OSS自由度、pgvector＝既存PostgreSQL活用。
- 選定は「運用負担／OSS／規模／既存DB／API好み」の軸で決まる。
- RAGはベクトルDBだけでなく、取り込み・チャンキング・Embedding・LLM呼び出しの組み合わせ。
- チャンキング・Embeddingモデル・Re-ranking・更新運用が品質を左右する。
各ツールの詳細はPinecone とは・Weaviate とは・pgvector とはにまとめています。RAG/ベクトルDB導入の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。
よくある質問（FAQ）
Q. ベクトルDBが本当に必要ですか？
A. シンプルな用途ならOpenAI Assistants APIや、Snowflake/BigQueryの組込みベクトル検索機能で足りる場合もあります。検索性能やカスタマイズが業務上の差別化要因になる場面では、ベクトルDB専用ツールが要ります。PoCではマネージドAPIで簡素に始め、必要になったらベクトルDBを足す進め方が現実的です。
Q. ChromaやQdrantは選択肢ですか？
A. はい、有力な選択肢です。Chromaは個人開発・PoC向けに人気、Qdrantは性能と機能のバランスが良いと評価されています。3つに加えて検討する価値があり、ベクトルDB領域は競争が激しいので最新情報を確認してください。
Q. Snowflakeのベクトル検索はどう？
A. Snowflake Cortex（およびVECTOR型）で、SnowflakeネイティブのベクトルDB機能が使えるようになりつつあります。「DWHとベクトルDBを一元化したい」「データの持ち出しを避けたい」場合は強力な選択肢です。Snowflakeの基本はSnowflakeとはを参照してください。
Q. RAGの品質を上げるコツは？
A. ベクトルDB選定よりも、チャンキング戦略・Embeddingモデル選択・Re-rankingの導入・ハイブリッド検索（ベクトル＋キーワード）の組み合わせの方が品質に与える影響は大きい。「ベクトルDBを変えたら品質が上がる」より、「前処理と後処理を磨くと品質が上がる」が現実だ。