この参考モデルの位置づけ
業務ナレッジを扱う AI エージェントを構築するとき、多くのプロジェクトで最初にぶつかるのがベクトルストアの選定と、精度をどう担保するかの 2 つです。Pinecone、pgvector、Cloudflare Vectorize、Weaviate、Qdrant といった選択肢がある中で、どれを選ぶかは規模・運用要件・コスト・チームのスキルセットで大きく変わります。加えて、選定が終わった後の「精度を継続改善する仕組み」がないと、リリース直後は動いていても数ヶ月で品質が劣化します。
本記事は、AI エージェント RAG の中核となるベクトルストア選定と評価ハーネスの設計を、AI 駆動開発のクリエイティブスタジオが参考実装モデルとして整理したものです。RAG そのものの汎用構築ガイドは RAG 構築の実践ガイド にまとめており、本記事は「ベクトルストアと評価」という技術判断に絞って掘り下げます。
ベクトルストア 3 系統の選定判断軸
主要なベクトルストアを 3 系統に整理し、それぞれの向き不向きを比較します。
| 系統 | 代表製品 | 規模の目安 | 運用モデル | 向く状況 |
|---|---|---|---|---|
| SaaS 型 | Pinecone | 100 万〜1 億ベクトル | フルマネージド | スケール優先、運用工数を抑えたい |
| RDB 拡張型 | pgvector | 10 万〜1 千万ベクトル | 自前運用 | 既存 DB との一体運用、コスト重視 |
| エッジ / サーバレス | Cloudflare Vectorize | 100 万〜1 千万ベクトル | フルマネージド | エッジ配信、Workers との相性、低レイテンシ |
Pinecone は、100 万ベクトルを超えるスケールで最初に検討する系統です。運用工数がほぼゼロで済み、ハイブリッド検索 (ベクトル + キーワード) や名前空間 (namespace) 機能が充実しています。ただし月額課金が発生し、10 万ベクトル未満の小規模案件では割高です。
pgvector は、既存の PostgreSQL や Amazon Aurora に PostgreSQL 拡張として乗せるパターンです。10 万〜1 千万ベクトル程度なら十分な性能で、業務データと同じ DB でトランザクション整合性が取れるのが強みです。コストは既存 DB のインフラ費に埋め込めるため、規模が小さいうちは最も安く済みます。
Cloudflare Vectorize は、Cloudflare Workers + Vectorize でエッジで動く RAG を組むときの選択肢です。認証・レート制限・キャッシュも Workers に寄せられるため、フロント側と RAG を統一したエッジアーキテクチャに向きます。マルチリージョンの低レイテンシが要る場合の第一候補です。
PoC 段階と本格運用の使い分け
実務では、PoC 段階と本格運用で異なるベクトルストアを使うことがあります。
PoC 段階 (数千〜数万ベクトル): pgvector で軽量に始めます。既存の PostgreSQL があれば拡張を有効にするだけで動き、コストゼロで検証を回せます。この段階ではベクトルストアの性能差は精度に対して支配的ではないため、選定に時間をかけません。
本格運用への移行判断: 次の 3 つのいずれかが顕在化したら、Pinecone または Vectorize への切り替えを検討します。
- ベクトル数が 100 万を超え、pgvector の検索レイテンシが 500ms を超え始めた
- 検索リクエストが 10 QPS を超え、PostgreSQL の CPU 使用率が上がり続けている
- マルチリージョン配信が必要になり、DB のレプリケーションで遅延が問題化した
移行はデータ移行だけでなく、埋め込みモデル (Embeddings) の互換性も確認します。同じモデルなら移行はシンプルですが、モデルを切り替える場合はベクトル空間が変わるため、全ドキュメントを再エンベディングします。
評価ハーネスの設計
RAG のリリース後、精度が劣化する原因は 3 つあります。
- 元ドキュメントの追加・改訂が反映されず、古い情報を返す
- モデル (Embeddings と LLM) のアップデートで挙動が変わる
- 想定外の質問パターンが業務で発生し、既存の検索設計で対応できない
これらを検知するには、評価ハーネスを継続運用します。参考設計は次の 4 要素です。
1. 評価データセットの自動抽出
業務ログ (問い合わせと回答の履歴) から、代表的な質問と正解ペアを自動抽出します。オペレーターが手動で「良い回答」「悪い回答」をラベル付けした履歴を、日次で評価データセットに追加します。ラベル付けは業務の副産物として発生させ、AI 用の別作業として発生させない設計が定着の鍵です。
2. 評価指標の定義
RAG の評価には 3 つの指標を組み合わせて使います。
- Retrieval Precision — 質問に対して検索されたドキュメントのうち、正解を含む割合
- Answer Quality — LLM の回答が正解と意味的に一致する割合 (LLM as a judge で自動評価)
- Hallucination Rate — 回答が元ドキュメントに存在しない情報を含む割合 (LLM as a judge で自動評価)
これらを週次でトラッキングし、閾値を下回ったらアラート運用に乗せます。
3. 継続改善サイクル
閾値割れが発生したら、次の順で切り分けます。
- Retrieval Precision が低下 → 検索クエリの前処理、埋め込みモデルの見直し、ハイブリッド検索の重み調整
- Answer Quality が低下 → プロンプトの調整、Few-shot 例の追加、モデルの切り替え
- Hallucination Rate 上昇 → 検索結果の確信度による回答制御、「答えられません」判定の追加
改善アクションと結果は評価ダッシュボードに記録し、次回の劣化時に「以前どう対応したか」がすぐ参照できるようにします。
4. モデル切り替え時の回帰テスト
新しい Embeddings モデルや LLM モデルへの切り替えは、評価ハーネスの回帰テストを通してから本番反映します。同じ評価データセットで新旧モデルを並列に走らせ、3 指標が全て同水準以上であることを確認してからカットオーバーします。
ベンダーロックインを避ける設計の一環として、モデルを切り替えられるアーキテクチャは重要です。この点は ベンダーロックインを避ける発注設計 にもまとめています。
参考期間と費用レンジ
RAG のベクトルストア選定と評価ハーネス構築を含む本格運用構築の参考レンジは次のとおりです。
- PoC — 300 万〜600 万円 / 3〜6 週間
- 本格運用構築 — 800 万〜1,800 万円 / 3〜4 ヶ月
- リリース後の継続改善 — 月 50 万〜150 万円 (伴走型)
規模を左右する変動要因は次のとおりです。
- ナレッジソースの数とボリューム (単一 CMS vs 複数システム、数千ドキュメント vs 数万)
- 検索対象の複雑さ (テキストのみ vs 図表・画像・PDF レイアウトを含む)
- 評価データの初期整備状況 (業務ログが既に構造化されている vs これから整備)
- 外部システム連携 (Salesforce / Zendesk / Notion への双方向同期の有無)
AI エージェント開発のご相談
「業務ナレッジを扱う AI エージェントを構築したいが、ベクトルストアの選定と精度担保の設計が分からない」「PoC は動いたが本格運用に上げるための評価ハーネスをどう組むか判断したい」といった状況こそ、AI 駆動開発で設計と実装を加速できる領域です。まずは AI エージェント開発のサービス内容 をご覧いただき、お問い合わせ からお気軽にご相談ください。