pgvectorとは
pgvectorとは、PostgreSQLにベクトル検索機能を追加するオープンソースの拡張モジュール
読み: ピージーベクター
PostgreSQLにベクトル検索機能を追加するオープンソースの拡張モジュール。既存のリレーショナルデータベースにそのまま組み込めるため、専用のベクトルデータベースを別途構築せずにAI向けの類似検索を実現できる。
かんたんに言うと
いつも使っているPostgreSQLに「意味で検索する機能」を後付けするプラグインである。新しいデータベースを増やさずに、RAGのような仕組みを動かせる。
専用DBを別途構築せずにAI類似検索を実現するpgvectorの仕組み
pgvectorの正体はPostgreSQLのEXTENSIONである。CREATE EXTENSION vector;の一行でインストールが完了する。新しいデータ型としてvector型が追加され、通常のテーブルにベクトルカラムを持たせられるようになる。
検索にはコサイン距離、L2距離、内積の3種類が使える。インデックスにはIVFFlatとHNSWの2方式が用意されており、データ量や精度要件に応じて使い分ける。HNSWのほうが検索精度は高い反面、インデックス構築に時間がかかる。
ここが重要なポイントになる。pgvectorはあくまでPostgreSQLの一部として動くため、トランザクション管理もバックアップもPostgreSQLの仕組みがそのまま適用される。運用担当者が新しいツールを覚え直す必要がない。
専用ベクトルDBとの使い分け
PineconeやWeaviateのような専用ベクトルデータベースは、数千万件以上のベクトルを高速に検索する用途に強い。分散アーキテクチャが前提で設計されているからである。
一方、pgvectorの得意領域は数百万件以下の規模で、かつSQLによる条件絞り込みとベクトル検索を組み合わせたい場面にある。たとえば「東京都の顧客のうち、この製品説明に最も関心を持ちそうな人を探す」といったクエリは、WHERE句とベクトル検索を一発で書ける。専用DBだとメタデータフィルタリングの実装に手間がかかる。
とはいえ、pgvectorで1億件のベクトルを捌こうとすると厳しい。検索速度とインデックスサイズの両面で専用DBに軍配が上がる。規模の見極めが選定の分かれ目になる。
RAGパイプラインでの実践的な使い方
社内文書をチャンクに分割し、エンベディングで数値配列に変換してからpgvectorのテーブルに格納する。ユーザーが質問を入力すると、質問文も同じモデルでベクトル化され、pgvector上で最も意味が近いチャンクが返される。これをLLMに渡して回答を生成する。
現場で厄介なのはチャンクとメタデータの管理である。「この文書はどの部署のもので、いつ更新されたか」という情報をベクトルと同じテーブルに持たせ、SQLのJOINで権限チェックまで一貫して処理できる。専用DBでは別途アプリケーション側で実装しなければならない処理が、pgvectorならSQLの世界で完結する。
LangChainやLlamaIndexにはpgvector連携のモジュールが標準で用意されており、コード数行で接続できる。
導入前に確認しておくべきこと
PostgreSQLのバージョンは12以上が必要になる。クラウドのマネージドサービスではAmazon RDSとGoogle Cloud SQLがpgvector対応済みで、Azure Database for PostgreSQLも利用できる。自前でホスティングする場合はソースからビルドするか、パッケージマネージャで導入する。
注意すべきはメモリの消費量である。HNSWインデックスはデータ全体のかなりの割合をメモリに展開する。既存のPostgreSQLインスタンスにpgvectorを追加する場合、メモリの見積もりを誤ると本業のクエリ性能に影響が出る。
データの規模が小さいうちはpgvectorで十分に対応できる。そこから始めて、規模が膨らんだ段階で専用DBへの移行を検討するのが現実的な進め方になる。
当社の見解
当社はOpenAI APIを完全廃止し、EmbeddingもLLMも全てローカルで稼働させている（2026年4月時点）。これにより月額のAPI費用がゼロになっただけでなく、機密情報や顧客データを外部に送信せずにAI処理できるようになった。クライアントのログデータをマスキングなしでそのまま分析に回せるのは、ローカルLLMだからこそ実現できる。2026年4月にはOllama常駐実行（CPU 25%、GPU 30%を常時占有）を廃止し、FastEmbed（ONNX Runtime）による非常駐型推論に移行。処理が必要な瞬間だけプロセスを起動し、完了後に即座に終了する設計で、アイドル時のリソース消費をゼロにした。あえて一般的なデスクトップPC環境で複数のローカルLLMを実機検証した経験から言えることは、ベンチマークスコアと実務での使い勝手、そして常駐時のリソース消費は全て別の指標だということだ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。