「RAGを作りたいが、ベクトルデータベースが乱立していて、どれを選べばいいのか分からない」——生成AIの社内活用を検討する情シス・DX推進・開発責任者の方から、いま急増している相談です。
pgvector、Pinecone、Qdrant、Milvus、Weaviate……。比較記事を読むほど選択肢が増え、「結局どれが正解なのか」で手が止まってしまう。これは製品を横並びで比べているうちは、いつまでも決まりません。
本記事では、RAG構築におけるベクトルデータベースの選び方を、製品比較の前に押さえるべき「自社の制約」から逆算するやり方で整理します。各製品の公開仕様を評価軸で並べつつ、私たちキュリオシティが生成AIのPoC（概念実証）で実際に選定してきた経験、とくに閉域網要件での選び方の勘所を、守秘の範囲で匿名にしてお伝えします。
結論：選定は「運用形態 × データ規模 × 閉域要件」の3軸でほぼ決まる
先に結論です。ベクトルデータベースは、製品の細かい性能を比べる前に、次の3つの制約でおおよそ絞り込めます。
- 運用形態：自社で運用したいか、丸ごとお任せ（マネージド）にしたいか
- データ規模とレイテンシ：ベクトルは数十万か、数千万か、数億か。応答は何ミリ秒まで許容できるか
- 閉域・セキュリティ要件：外部SaaSを使えるか、それとも社内ネットワークに閉じる必要があるか
この3軸を先に決めると、候補は自然に2〜3個まで絞れます。運用形態は大きく3タイプに分かれ、代表的な製品は次のように整理できます。
| 運用形態 | 特徴 | 代表例 | 向いているケース |
|---|---|---|---|
| 既存DB拡張型 | 使っているRDBに機能を足す | pgvector（PostgreSQL拡張） | すでにPostgreSQLがあり、数百万〜数千万ベクトル規模 |
| フルマネージド型 | 事業者が運用を代行・自動スケール | Pinecone など | 運用負荷をゼロにしたい／大規模でクラウド前提 |
| OSS自前運用型 | オープンソースを自社で運用 | Qdrant・Milvus・Weaviate | 閉域・オンプレ必須／低レイテンシや細かい制御が要る |
※各製品はマネージド版・OSS版の両方を持つものもあり、上表は「もっとも使われる形態」での分類です。そもそもRAG全体のどこにベクトルDBが効くのかを先に押さえたい方は「RAG構築の進め方｜社内文書を生成AIで検索する」を先にご覧ください。以下、選び方の物差しを詳しく見ていきます。
ベクトルデータベースとは：RAGの「検索」を担う土台
ベクトルデータベースは、文章や画像を数値の並び（ベクトル）に変換したデータを格納し、「意味が近いもの」を高速に探し出すためのデータベースです。
RAGでは、社内文書をあらかじめベクトル化して格納しておき、ユーザーの質問もベクトル化して「意味的に近い文書」を検索し、その内容を根拠として生成AIに渡します。つまりベクトルデータベースは、RAGの回答品質を左右する「検索」の土台です。ここが弱いと、どんなに優秀なLLMを使っても的外れな回答になります。RAG全体の組み立て方は「RAG構築の進め方｜社内文書を生成AIで検索する」で解説しています。
選び方の5つの比較ポイント
3軸で候補を絞ったら、次の5つの物差しで最終決定します。
① 運用形態：誰が運用を担うのか
最初に決めるべきは「運用を誰が持つか」です。マネージド型は運用を事業者に丸投げできる代わりに、外部クラウドへデータが出ます。OSS自前型は自由度が高い代わりに、構築・監視・アップデートを自社で背負います。既存DB拡張型は、いま使っているデータベースに乗せるので学習コストが最小です。この選択がその後のコストと運用負荷をほぼ決めるため、最も重視すべき軸です。
② データ規模とレイテンシ要件
必要なベクトル件数と許容レイテンシで、適する製品は変わります。数十万〜数千万件で数十ミリ秒の応答で足りるなら、選択肢は広く、既存DB拡張型でも十分間に合います。数億件規模やミリ秒単位の厳しいレイテンシが要るなら、専用設計のOSS（Qdrant・Milvus）やマネージドの土俵になります。規模を過大に見積もって最初から重い構成を選ぶのは、よくある失敗です。
③ 既存システムとの相性
すでにPostgreSQLを運用しているなら、拡張機能であるpgvectorは有力です。ベクトルと業務データを同じデータベースで扱え、SQLの結合・権限管理・トランザクションをそのまま流用できます。逆に、クラウド基盤（AWS・Azure・GCP）に寄せているなら、その基盤と親和性の高いマネージド／マネージドOSSを選ぶと運用が一貫します。
④ 総コスト（TCO）——「無料」の罠
OSSは「無料」に見えますが、ここに落とし穴があります。本番で可用性を担保しようとすると、冗長化のためのレプリケーション、アイドル時も動き続けるサーバー費用、そして運用を回すDevOps人件費が積み上がり、結果的にマネージドサービスより高くつくことも珍しくありません。ライセンス費だけでなく、運用工数まで含めた総保有コスト（TCO）で比較するのが鉄則です。ベクトルDB単体ではなく、RAG全体の費用感は「生成AI導入の費用相場」も参考にしてください。
⑤ 閉域・セキュリティ要件（ここで選択肢が大きく変わる）
機密情報を扱う企業では、「そもそも外部SaaSにデータを出せるか」が最初の関門です。閉域網（インターネットに接続しない社内ネットワーク）が要件なら、マネージドの選択肢は原則消え、自社サーバに配置できるOSSが前提になります。ここは製品スペック以前の話で、比較記事の多くがマネージド前提で書かれているため、閉域要件の現場では役に立たないことが多い——これが後述する差別化ポイントです。閉域での生成AI活用全般は「閉域網で生成AIを使う方法｜セキュアな社内活用」で詳述しています。
主要製品を評価軸で整理（公開仕様ベース）
代表的な製品を、公開されている仕様と各社の主張で並べます。優劣を断定するものではなく、自社の3軸・5軸に照らして読んでください。まず横並びで全体像を押さえます（◎○△は用途適合の目安、料金は各社の課金体系）。
| 製品 | 運用形態 | 得意な規模 | 閉域・オンプレ | ライセンス／課金 | 向くケース |
|---|---|---|---|---|---|
| pgvector | 既存DB拡張(OSS) | 数十万〜数千万 | ◎（自社Postgresに載る） | 無料（PostgreSQL運用費のみ） | 既存PostgreSQLがある／SQL統合したい |
| Pinecone | フルマネージド | 数千万〜数億 | △（クラウド前提） | 従量課金（要見積） | 運用ゼロ優先／閉域制約なし |
| Qdrant | OSS／マネージド | 数百万〜数億 | ◎（単一コンテナで軽い） | 無料(OSS)／マネージドは従量 | 低レイテンシ・閉域で細かく制御したい |
| Milvus | OSS／マネージド | 数億〜数十億 | ○（オンプレ可・運用重め） | 無料(OSS)／マネージドは従量 | 超大規模・専任運用チームがある |
| Weaviate | OSS／マネージド | 数百万〜数億 | ○（オンプレ可） | 無料(OSS)／マネージドは従量 | ハイブリッド検索を重視したい |
※「得意な規模」は各社ドキュメントで一般に示される目安で、絶対的な上限ではありません。料金も課金体系のみを記載しており、実額は規模・クエリ量で大きく変わるため、必ず自社要件で見積もってください。以下、各製品の要点を補足します。
- pgvector（PostgreSQL拡張・OSS）：既存のPostgreSQLにベクトル検索を足す拡張。公式仕様では、標準の
vector型が最大16,000次元（インデックスは2,000次元まで）、半精度のhalfvec型ならインデックスを4,000次元まで扱え、HNSW／IVFFlatのインデックスとコサイン・L2などの距離関数に対応します。SQLの結合・フィルタ・トランザクションと統合できるのが最大の強みです（出典：pgvector 公式（GitHub））。 - Pinecone（フルマネージド）：インフラ運用が不要で自動スケールするクラウドサービス。運用負荷を最小にしたい、大規模でスケールを気にせず使いたいケースに向きます。一方でクラウド前提のため、閉域要件とは相性が悪い。
- Qdrant（OSS／マネージド）：Rust実装で低レイテンシを打ち出す製品。公式ベンチマークでは「ほぼ全シナリオで最高RPS・最低レイテンシ」を主張しています（自社ベンチのため参考値。出典：Qdrant 公式ベンチマーク）。単一コンテナで軽く動かせるため、オンプレ・閉域でも扱いやすい。
- Milvus（OSS／マネージド）：数億〜数十億規模を想定した分散設計。大規模には強い一方、周辺コンポーネントが多く運用は重め。専任チームがある大規模用途向き。
- Weaviate（OSS／マネージド）：ベクトルとキーワードを組み合わせるハイブリッド検索に定評。GraphQLベースの扱いやすさも特徴です。
数値スペックは埋め込みモデルの次元数（例：text-embedding-3-largeは3,072次元）とも関わります。私たちが実際にこの次元でpgvectorを組んだ際も、標準のvector型ではインデックスの2,000次元上限に引っかかり、halfvecへ切り替えて対応しました。「使う埋め込みモデルの次元数」と「DBのインデックス上限」は、選定時に必ず突き合わせておくべきポイントです。
閉域網要件での選択：自社PoCの所感
ここからは、私たちが閉域・オンプレ要件のRAGを支援して得た、匿名の一次情報です。守秘のため業界・規模・数値はぼかしますが、選定の考え方は共通しています。
まず痛感するのは、閉域要件では「製品比較」より先に「調達・ネットワーク・運用主体」の制約が効くということです。ある機密性の高い現場では、外部SaaSが一切使えず、Pineconeのようなマネージドは検討段階で除外されました。残ったのは自社サーバに置けるOSS。ここで初めて、Qdrant（単一コンテナで軽い）とpgvector（既存PostgreSQLに乗せる）の比較が意味を持ちました。
象徴的だったのは、製品比較そのものより「ネットワーク分離側の承認」がボトルネックになったことです。どのOSSを選ぶかの技術検討は数日で終わったのに、閉域セグメントへサーバを追加する社内承認と調達に、その何倍もの時間がかかりました。「製品を決めれば進む」と思っていた計画が、調達で律速される。閉域案件では、この段取りを最初に見込んでおかないとスケジュールが崩れます。
結論として、すでにPostgreSQLを運用していて、ベクトルが数百万規模なら、pgvectorが最も運用が軽いというのが繰り返し出てくる所感です。新しいミドルウェアを1つ増やさずに済み、SQLの権限管理やバックアップ運用をそのまま流用できる。閉域では「運用要員が限られる」ことが多いため、この”増やさない”効果は想像以上に大きい。逆にOSSを別立てで入れた現場では、マイナーバージョンの差異でインデックスの再構築が必要になり、閉域ゆえに更新手順を手作業で回す負担が地味に効いてきました。実際、ベクトル検索の中核（ベクトル化と近傍探索）はクラウド接続に依存しないため、エアギャップ環境でも問題なく成立します（参考：Milvus 公式リファレンス）。
もう一つの教訓は、「精度が出ない＝DBが悪い」ではないことです。DB乗り換えの相談の多くは、実際には検索側（チャンク設計・メタデータ・ハイブリッド検索）の作り込み不足が原因で、製品を変えても直りません。この論点は「RAGの精度を上げる方法」で詳しく扱っています。
RAG構築での実務：小さく検証して決める
選定を机上で決めきらないことが最大のコツです。次の順序で、小さく検証してから確定するのをおすすめします。
- 3軸で候補を2〜3個に絞る：運用形態・データ規模・閉域要件で足切りする
- 代表質問を20〜30問用意する：現場が実際に聞きたい質問を評価の物差しにする
- 既存資産で試せる候補から検証する：PostgreSQLがあるならpgvector、閉域ならQdrant等、”増やさない”順に試す
- 精度が出なければ、まず検索設計を疑う：DBを変える前にチャンク・メタデータ・ハイブリッド検索を調整
- 撤退・移行基準を決めておく：「規模が◯倍になったら専用DBへ」など、乗り換えの線引きを事前に置く
KPIや撤退基準を含むPoCの回し方は「生成AIのPoCの進め方｜失敗しない設計とKPI・撤退基準」に、社内向けの全体設計は「社内向け生成AIの構築方法」にまとめています。
よくある質問（FAQ）
Q. 結局、最初はどれを選べばいいですか？
A. すでにPostgreSQLがあり数百万規模までなら、まずpgvectorが最短です。運用を増やさず、SQLの資産を流用できます。運用ゼロを最優先し閉域制約がないならマネージド、閉域なら自社サーバに置けるOSSが前提になります。
Q. 最初から大規模用の専用DBを選んだほうが安全では？
A. 多くの場合オーバースペックです。規模を過大に見積もって重い構成を選ぶと、運用負荷とコストだけが先に膨らみます。まず小さく始め、規模が見えてから移行を判断するほうが堅実です。
Q. 閉域網でもベクトル検索は使えますか？
A. 使えます。ベクトル化と近傍探索の中核は外部接続に依存しないため、オンプレ・エアギャップ環境でもOSSで完結できます。ただし製品選定より先に、調達・ネットワーク・運用体制の制約を確認してください。
Q. あとからDBを乗り換えるのは大変ですか？
A. ベクトルの再生成やインデックス再構築が必要になり、相応の工数がかかります。だからこそ最初に3軸で絞り、移行基準を決めておくことが重要です。
まとめ：まず制約で絞り、PoCで確かめる
ベクトルデータベースの選び方は、製品を横並びで比べることではありません。「運用形態 × データ規模 × 閉域要件」の3軸で候補を絞り、TCOと既存システムとの相性を加えた5つの物差しで決め、最後は小さなPoCで自社データを使って確かめる——この順序を守るだけで、多くの遠回りを避けられます。とくに閉域要件では、製品スペックより先に制約が効くことを忘れないでください。
私たちキュリオシティは、”現場主義 × AI”の姿勢で、社内文書活用のRAG構築やベクトルDB選定、閉域環境でのPoC設計を数多く支援しています。サービスの詳細は「生成AI開発・PoC支援」をご覧ください。
生成AIのPoCを、失敗しない設計で始めたい方へ
「どの業務に・どのベクトルDBで・どんなKPIで検証するか」を1枚に落とし込める 生成AI PoC企画テンプレート を無料で配布しています。閉域要件の確認項目や撤退基準の置き方まで含めた、そのまま使える設計フォーマットです。
▶ 生成AI PoC企画テンプレートを無料でダウンロードする
自社のケースで「どのベクトルデータベースが適しているか」を具体的に相談したい方は、無料相談はこちらからお気軽にお問い合わせください。
監修：大槻 伸夫（キュリオシティ株式会社 代表取締役CEO）。”現場主義 × AI”を掲げ、製造業・士業・商社などの社内文書活用に向けたRAG構築・ベクトルDB選定・閉域環境での生成AIのPoC設計を数多く支援。｜出典：pgvector 公式（GitHub）、Qdrant 公式ベンチマーク、Milvus 公式リファレンス（air-gapped/on-prem）
